ftp://ftp.kernel.org/pub/linux/kernel/v2.6/testing...

Atsushi Nemoto ~
Hidetoshi Seto ~
Kuninori Morimoto ~
SUGIOKA Toshinobu ~
Takashi Iwai ~

2.6.29-rc3_shortlog01 ~

List: linux-kernel
Subject: Linux 2.6.29-rc3
From: Linus Torvalds <torvalds () linux-foundation ! org>
Date: 2009-01-28 19:41:40

It's out there, and while it's a bit larger than I'd wish for, that size
is pretty understandable considering that it's closer to two weeks than
one in between -rc2 and -rc3 (due to LCA, obviously).

And it isn't really _that_ big: part of the reason it looks bigger as a
traditional patch (which is what I upload when I upload patches) than it
really is due to a lot of m68k include file renames, so if you look at the
git rename-aware patches it all actually looks much smaller.

About a quarter of it is arch updates (of which a third is ppc defconfig
updates): mainly sh, arm and m68k. Almost another quarter is some
filesystem updates, but the bulk of that is literally just splitting up
the core fs Kconfig file and moving out the filesystem config information
into the individual filesystems. With some xfs updates to round it all up.

And half (which is pretty much "the rest" for you guys keeping count) is
driver updates. As usual. USB and the dmaengine code dominates in pure
lines, but there's a couple of new drivers like the i.MX31 framebuffer
thing etc.

But the most interesting part (at least for me) of the driver update is
likely the continued fixing of the PCI suspend/resume handling, which for
me now finally results in a _reliable_ suspend/resume on one of my laptops
(admittedly I still have an X problem, but the discussions on the exact
way to fix that are still on-going, and it's technically a userlevel
problem that will likely result in a kernel change just to make the DRI
interfaces not be as fragile).

We have historically been in a situation where suspend/resume often works,
but may not be reliable due to interrupt timings, especially if there are
any shared interrupts going on between drivers. We already had some parts
of the suspend/resume changes in -rc1, but I hope it's approaching more
stability now.

[ In the longer run, the changes will also allow us to simplify a lot of
device drivers thanks to the code PCI driver code doing more of it for
us, but that's a largely independent later cleanup issue. ]

The thing about suspend/resume though is that partly exactly _because_
it's been very fragile historically (a driver may have been totally solid
on one machine for example, but flaky on another due to different
interrupt configuration), I'm not going out on much of a limb when I say
that we'll really need user feedback on any drivers that now don't
suspend/resume cleanly.

So please, people - especially if you use suspend/resume, we want to hear
about regressions, and will need to know what hardware and drivers you
have active. Hearing about success stories is obviously always fun, but
it's the regressions that we really want to track.

　　　　　　　　　　　　　　　Linus