Here are the patches for Secure Digital support that I've been sitting on for a while. I tried to get some feedback on inclusion of this previously but since I didn't get any I'll just submit the thing. It was originally diffed against 2.6.10 but it applies to 2.6.11 just fine (only minor fuzz).

Change summary:

• Detects if connected card is SD or MMC. Marks host as in SD mode if SD is detected (since SD isn't a bus system).
• Reads extra registers from SD cards (SCR) and parses CSD differently depending on SD/MMC mode.
• Support for 4-bit mode. This has been design to be fairly isolated from the SD bit so that it can (hopefully) be reused with MMC.
• New callback added for reading the read-only switch on SD cards.

Changed files:

mmc.c : SD detection and register parsing.
mmc_block.c : Checks read-only flag for cards (not SD-specific).
mmc_sysfs.c : Exposes SCR register.
card.h : Added flags to determine card type, RO and new register.
host.h : Added flags for bus width, RO test and mode (SD/MMC).
mmc.h : Added R6 define and new defines.
protocol.h : Added needed SD commands.

This patch is backwards compatible and only needs updated drivers to take advantage of 4-bit bus and reading the RO switch (unmodified drivers will default to 1-bit bus and write enable).

There might be new bugs that surface with this though. With my own drivers I discovered that very small transfers (< 16 bytes) always failed. Testing is needed but I do not have access to do it myself. MMC should not break with this since MMC is detected before SD.

Can we please come to a consensus about GEN_FL_REMOVABLE. After talking to other kernel developers, particularly in the block interface area, I am convinced that it is fundamentally incorrect to set this flag for MMC/SD devices.

Unfortunately, it appears that you're not convinced. This needs resolving since it is an interface issue.

I'd rather not just apply this patch - there's rather a lot there to just apply on top of what's already merged.

Is there any chance you can split it up into a smaller set of changes so it's more obvious what's going on at each stage please?

We'll also need to run this by Linus first, explaining why you believe it's now ok to merge this.

First of, I can't really back up the claim that it isn't ok. The SDA has a paragraph about non-disclosure in their "IP Policy" (http://www.sdcard.org/membership/images/ippolicy.pdf) but it also states that exceptions can be granted.

Against this stands the new information that the SDA is changing its policy and making the specs public. This information comes from some of the guys at HP research and hasn't been confirmed by any public statement from SDA. The SDA have, however, already released the SDIO specs. Presumably as part of this new policy.

It was also pointed out in the previous thread by myself, Alan Cox and Ian Molton that SD specs have been publically available from different companies for quite some time. As such it is difficult for anyone to claim that these are secret and can be regulated by a NDA. The only part that hasn't been found in the wild is the spec for the 'secure' parts of the cards. But that also means that it isn't included in this patch so it shouldn't pose a problem.

As always, IANAL so I can't give any definite answer. But from my point of view they would have a very weak case if they tried to claim that the information in this patch is a trade secret.

This patch implements the architecture independent portion of the time of day subsystem. For a brief description on the rework, see here: http://lwn.net/Articles/120850/ (Many thanks to the LWN team for that clear writeup!)

The exciting new changes are ntp_scale() has been removed, speeding up gettimeofday(), and the periodically run timekeeping code is now called via soft-timer rather then at interrupt time. So timekeeping can now be done every tick or every 10 ticks or whatever!

Included below is timeofday.c (which includes all the time of day management and accessor functions), ntp.c (which includes the ntp scaling calculation code, leapsecond processing, and ntp kernel state machine code), timesource.c (for timesource specific management functions), interface definition .h files, the example jiffies timesource (lowest common denominator time source, mainly for use as example code) and minimal hooks into arch independent code.

The patch does not function without minimal architecture specific hooks (i386, x86-64, ppc32, ppc64, and ia64 examples to follow), and it should be able to be applied to a tree without affecting the code.

New in this version:

• ntp_scale has been removed from the gettimeofday fastpath
• ntp_advance now pre-calculates the ntp scaling factor for the next interval
• timeofday_periodic_hook is now called by a soft-timer and runs outside of interrupt context
• comment cleanups

Items still on the TODO list:

• cyc2ns needs better remainder code
• Infrastructure for exporting time values for vsyscall/fsyscall
• finer grianed ntp adjustments in ppb instead of ppm
• more flexible timesource management interface
• Testing, performance and cleanup work

Please apply the following two patches which adds SquashFS to the kernel. SquashFS is self contained compressed filesystem, and it has been used by a large amount of projects over the last few years without problems.

A number of people have started to ask me to submit it to the kernel. Please consider adding it.

The SquashFS patch has been split into two. This email contains inode.c, the next email contains everything else.

squashfs is an *excellent* filesystem with very high compression ratios and high speed on slow I/O devices such as CDs. I now use it to store my root FS in initrd, and frankly, having a fully functionnal OS in an image as small as 7 MB is "a good enough improvement over cramfs".

If the 4 GB limit goes away one day, I hope it will not increase overall image size significantly, because *this* would then become a regression. Perhaps it would simply need to be a different version and different format (eg: squashfs v3) just as we had ext, then ext2, or jffs then jffs2, etc...

Although I've only been following things with half an eye, I don't think there's a lot of resistance. It's just that squashfs's proponents are being asked to explain the reasons why the kernel needs this filesystem. That's something into which no effort was made in the initial patch release (there's a lesson there).

Hopefully when the patches are reissued, all of these concerns will be described and addressed within the covering email.

AFAICT the most substantial issue is the 4GB filesytem limit, and it seems that the answer there is "this fs is for embedded systems and 4GB is already insanely large". If that is indeed the argument then please, make that argument and we'll dutifully evaluate it.

We shouldn't have to drag out such important and relevant information with torture-via-email-thread. You guys are the squashfs exports. Tell us stuff.

It is not so much selling, in my view, as putting in context.

If one can simply explain to others what is before them, so that they can quickly understand its purposes, scope, architecture, limitations, alternatives, and such, then others can quickly evaluate what it is, and whether such seems like a good idea.

It doesn't necessarily mean they buy it any quicker. Sometimes it just means it gets shot down quicker ;). That's ok.

There's a _lot_ of stuff that flows by here ... be gentle and helpfully informative to the poor reader ... as best you can.

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11/2.6.11-mm4/

• fbdev update
• percfctr updates
• Lots of ppc32/ppc64 things
• Broken on some ia64 machines. We're still working through fallout from the recent pagetable walking consolidation patches.

take a look at this: http://www.bitkeeper.com/press/2005-03-17.html which is a link to a very simple open source BK client. It doesn't do much except track the head of the tree but it does that well. It's slightly better than that, it puts all the checkin comments in BK/ChangeLog so you don't have to go over the wire to get those.

It's intended for someone who just wants the latest and greatest snapshot, knows how to do cp -rp and diff -Nur, it's pretty basic. It's not a CVS gateway replacement but it does work for every tree on bkbits.net. Just to be clear, we are not dropping the CVS gateway, this is "in addition to" not "instead of".

it's open source, I'm hoping that people will take that code and evolve it do whatever they need. We're willing to do what we can on this end if people need protocol changes to support new features, time permitting. Think of that code as a prototype. It's really simple, you can hack it trivially.

If you want us to distribute your changes then send a patch, if not that's cool too. You can take that and evolve it to your heart's content. If you need a different license to start hacking let me know what you want, I really don't care, you can have that code as public domain if you like.

The following URL is link to a large patch for a possible integration of a new filesystem implementation in the misc section of the kernel tree. It features a reverse engineered implementation of the so called VXEXT1.0 DOS filesystem which is commonly used on VxWorks RTOS systems from Wind River Inc., where the "extended DOS filesystem" mode is enabled.

The VXEXT filesystem is more or less a FAT16 based filesystem which was slightly modified by Wind River to allow the storage of more than 2GB data on a partition, as well as storing filenames with a maximum of 40 characters length. To achieve that, VxWorks uses a dynamic cluster size calculation which is based on the partition size where clusters can be larger than 32K. In addition, it uses a slightly modified directroy entry structure to allow to store filenames larger than 8+3 characters.

Please find the patch file accessible through the following URL: http://www.jens-langner.de/vxext_fs/vxext_fs_1_0-linux-2.6.11.4.patch

In addition, refer the detailed technical documentation on my implementation and the root directory of my distribution as well: http://www.jens-langner.de/vxext_fs/Documentation/vxext.txt, http://www.jens-langner.de/vxext_fs/

Please note that large portions of the implementation are based on the already existing FAT16 (msdos) implementation in the kernel tree. However, instead of patching/drilling the original FAT16 implementation, an "outsourced" rework for developing the VEXT implementation was considered.

Sure it can. But I thought that as the VXEXT1.0 filesystem is per definition not a vfat filesystem it might be better to have it separated and not drill it into the IMHO anyway overly mixed up vfat/fat code already in the linux kernel tree. Even if that means that some parts in the code of the vxext filesystem are probably equal to the msdos implementation, please note that large parts which were not needed by the vxext implementation was dropped by me for clarifications.

So I still hope that my implementation is going to be considered for a future kernel tree integration as it may be quite usefull for embeeded systems wanting to access VxWorks partitions.

Yes, you are missing something. The dm9000 is definetly not an ne2k compatible, for a start it only uses two ports (address and data), manages it's own transmit/receive queues, etc.

As the person who did the updates to Sacha's original driver port, he should have really checked with me for up-to-date version first, and to collect a Signed-off-by: line.

Signed-off-by: Ben Dooks <ben-linux@fluff.org>

The changelog states that the patches for the AMD8111e and VIA-Rhine originated from dilinger<at>debian.org although I was the one who they originated from.

http://article.gmane.org/gmane.linux.kernel/282245
http://article.gmane.org/gmane.linux.kernel/282263

<dilinger:debian.org>>

• Possible AMD8111e free irq issue
• o Possible VIA-Rhine free irq issue

Here are a set of patches that makes it possible to autogenerate kernel command line documentation from the source code. The approach is rather straightforward - the parameter name, the type and the description are stored in a section called __param_strings. After vmlinux is built this section is extracted using objcopy and a script is used to generate a primitive - but up to date - document.

Right now the section is left in the kernel binary. The document is currently not generated from the Makefile, so the curious user should perform:

$ objcopy -j __param_strings vmlinux -O binary foo
$ chmod a+x scripts/section2text.rb
$ cat foo | ./scripts/section2text.rb

And yeah, you need to install ruby to run the script.

The ruby script section2text.rb does some checks to see if MODULE_PARM_DESC() is used without module_param(). You will find interesting typos.

Future work that extends this idea could include replacing __setup(name) with __setup(name, descr). And storing the documentation somewhere to make it easy for the end user to look up the generated parameter list from the boot loader.