The following patch enables the use of the Au1x00 AMD SoC UARTs through the standard 8250 serial driver.

The Au1x00 UARTs are weird in the following two ways:

1) The registers are not present at the normal offsets, so a mapping function is used to transform them.

b) Modem status signals are not supported on all the members of the Au1x00 family, so the modem status change interrupts must not be enabled, or we die in an irq storm.

In order to not affect any standard 8250 parts, the code in question is #ifdef'ed on CONFIG_SERIAL_8250_AU1X00. If you deem the readability of the code is more important you may removed them, without any effect on the functionality.

I've also considered abstracting the register mapping to a couple of extra fields on plat_serial8250_port, but wasn't sure how that would go.

One issue is that I actually worry that Andrew will at some point be where I was a couple of years ago - overworked and stressed out by just tons and tons of patches.

Yes, he's written/modified tons of patch-tracking tools, and the git merging hopefully avoids some of the pressures, but it still worries me. If Andrew burns out, we'll all suffer hugely.

I'm wondering what we can do to offset those kinds of issues. I _do_ like having -mm as a staging area and catching some problems there, so going through andrew is wonderful in that sense, but it has downsides.

Andrew?

I'm doin OK.

Patch volume isn't a problem wrt the simple mechanics of handling them. The problem we have at present is lack of patch reviewing bandwidth. I'll be tightening things up in that area. Relatively few developers seem to have the stomach to do a line-by-line through large patches, and it would be nice to refocus people a bit on that. Christoph's work is hugely appreciated, thanks.

Famous last words, but the actual patch volume _has_ to drop off one day. In fact there doesn't seem to much happening out there wrt 2.6.15.

Bugs are a big problem - it takes 4 hours minimum to get a -mm out the door and a single bug can cause it to slip to the next day in which case I have to start again. A couple of times it has taken over two days just to get together a tree which boots on four architectures and compiles on seven.

I'm spending more and more time on bugs now. We have hundreds of bugs which people have taken the time to report, which the relevant developers know about and NOTHING IS HAPPENING. "I can't reproduce it" is not an adequate reason when there are nice testers out there who are available to work through the diagnosis process. We have hundreds of machines out there which we are known to have broken and developers just need to reapportion some of their time to getting these things fixed.

The -mm tree does prevent a large amount of crap from hitting mainline - I'd guess the bug leakthrough rate is ~10%, although that 90% tends to be the easy stuff - often compile errors. I'd like to release -mm's more often and I'd like -mm to have less of a wild-and-crappy reputation. Both of these would happen if originators were to test ther stuff more carefully.

Yup. And MAINTAINERS has quite a few omissions. I generally know who should be poked and if there's nobody obvious I have 26000 patches to grep through to find out who might know a bit about that code. Low-level x86 is a bit of a problem really because it has many cooks and no obvious chef.

Individual maintainers have differing response times, differing attentiveness and differing patchloss ratios.

There's also confusion once I've cc'ed a maintainer on a patch over whether I'll be sending it to Linus or whether I want them to.

If a maintainer has a tree in -mm then I'll autodrop the patch if they merge it, so there's no confusion there.

If the maintainer says "thanks, merged" and I don't have their tree in -mm then I'll tend to hang onto the patch indefinitely until it finally hits -linus. Or I'll eventually forget and merge it up anyway ;)

If the maintainer just acks the patch I'll send it in to Linus.

If the maintainer nacks the patch I'll either drop it or I'll mark it not-for-merging and hang onto it anwyay, as a reminder that we have some bug which needs fixing.

If the maintainer has a tree in -mm and doesn't merge the patch I'll hang onto it and periodically resend to the maintainer until some definite response comes back.

Yes, kernel bugmeister is a completely separate function from patchmonkeying. It is something which a separate person can and should do.

My current thinking is that I'll develop the processes, find out what works and then look to hand it off to some other sucker. I wouldn't claim that this is going very well at present, perhaps because I'm just not putting enough time into the bugmeistering to be able to demonstrate what works and what does not.

I wouldn't say that bugmeister is a fulltime job, but it'll be a lot-of-time job. It needs someone who isn't shy and who has a good understanding of the kernel code-wise, of the processes (hah) and of the people.

The ability to maintain an overall view of where we're at, which bugs are serious and which aren't. The ability to succinctly communicate that overview to everyone else. Able to tell Linus "you can't release a kernel until bugs A, B and C are fixed". The skills and gut-feel to know when a patch is some once-off which can be ignored unless it reoccurs, etc. It's one of those things which can consume as much effort as one is able to put into it.

Kernel development is more professional than we like to pretend nowadays, and developers will react well to someone who is doing this for us. It's pretty boring tho.

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14-rc2/2.6.14-rc2-mm1/

• Added git tree `git-sas.patch': Luben Tuikov's SAS driver and its support.
• Various random other things - nothing major.

Andrey J. Melnikoff:
Remove isofs useless unsigned " < 0" comparison

Assar:
nfs client: handle long symlinks properly

Chuck Ebbert:
i386: fix incorrect FP signal delivery

Dave Johnson:
[IPV4]: Fix negative timer loop with lots of ipv4 peers.

Gustavo Zacarias:
[SPARC64]: Use vmalloc() in do_netfilter_replace()

Hasso Tepper:
[IPV6]: Route events reported with wrong netlink PID and seq number

Horms:
CAN-2005-0204: AMD64, allows local users to write to privileged IO ports via OUTS instruction
isofs driver ignore parameters

Jean Delvare:
update lm_sensors mailing list address

Kirill Korotaev:
Lost sockfd_put() in routing_ioctl()
lost fput in 32bit ioctl on x86-64

Kiyoshi Ueda:
IA64: page_not_present fault in region 5 is normal

M.Baris Demiray:
Update PPPoE's configuration documentation

Marcelo Tosatti:
NFS: dprintk on -ENAMETOOLONG error handling
Update VERSION to 2.4.32-rc1
Andrea Arcangeli: avoid size_buffers_type overflow
Merge master.kernel.org:/.../davem/net-2.4
Revert unnecessary arch/ppc64/boot/zlib.c
Revert unnecessary zlib_inflate/inftress.c fix

mikem:
cciss 2.4.60

Patrick McHardy:
[NETFILTER]: Handle NAT module load race

I'm announcing the release of 0.15.1 of Cogito, the human-friendly UI for Linus' GIT. You can find it at

http://www.kernel.org/pub/software/scm/cogito/

when kernel.org mirroring will go through another short period of actually working. ;-)

I'm cc'ing the Linux Kernel mailing list since this release contains a bugfix for an ugly potential data loss bug, which actually probably covers nearly all Cogito users (it was introduced in cogito-0.11.2). If you had some local uncommitted changes and merge new stuff (either using cg-update or cg-merge), in some cases it would silently trash your local changes. It was caused by a bogus git-checkout-cache invocation pointed out by Linus.

Other interesting stuff:

• cg-clean -d would remove the arch/ and include/ subdirs in Linux kernel - just any directories containing only subdirectories (this isn't as horrible as it sounds since you didn't lose anything precious you didn't want to lose - you can recover by just doing cg-restore)
• Support for fetching from URLs of the 'git' protocol scheme
• cg-log -d filters based on date
• cg-diff works on BSD now
• Merge cg-(commit|parent|tree)-id to cg-object-id
• Some significant documentation enhancements
• Some new tests in the testsuite (for cg-merge ;-)
• Usual squad of minor bugfixes

If people hadn't noticed anymore, I've passed on the full I2C subsystem maintainership to Jean Delvare <khali@linux-fr.org>. He and I had been "sharing" it for the past months, but now he's more than capable of handling the whole thing, and I know it is in good hands now.

So, for any I2C driver questions or patches, please feel free to let him know, don't send them to me anymore, please :)

I'll still be paying attention to the I2C core work, especially where it touches the driver core interfaces, and have some pending work to clean up in that area. I'll also remain the conduit for sending I2C and hwmon stuff on to Andrew for the -mm tree, and Linus for the mainline tree, so nothing will change there.