Hi y’all!
-Miklos Szeredi has fuse updates for 3.3, Takashi Iwai
has sound updates for -rc1(“Some highlights:
– The new core infrastructure for compressed data streams is merged.
No real device driver is implemented yet in this merge window.
– A new jack-control interface is provided for some HD-audio codec
drivers
– Further reworks of Realtek HD-audio driver to reduce the static
quirks
– The update of asihpi driver
– ibool module parameter changes by Rusty
– A few driver fixes for au88x0, hdspm, virtuoso, and usb-audio
– Many ASoC updates:
– Conversion of a number of CODEC drivers to use regmap directly. This is
especially beneficial for drivers for devices which are part of MFDs as
they can use a central cache for all operations and means that the
process of factoring out the more complex register management code in
ASoC can begin.
– As a result of the move of drivers to regmap the rbtree and LZO cache
types have been removed, leaving only the the basic flat cache in ASoC.
Drivers which need the more complex cache types should use regmap
directly.
– Lots of cleanups and fixes from Axel Lin.
– New CODEC drivers for Cirrus CS42L73, Realtek ALC5632.
“), Sage Weil updates ceph and John W. Linville has
wireless updates:
Here is a quick batch of wireless fixes intended for 3.3!
On the Bluetooth patches, Gustavo says this:
“A couple of fixes for the 3.3 release. The majority of the fixes are
related to the change from tasklets to workqueue in the Bluetooth
Core. The rest are important fixes over the tree. Exception is
‘Bluetooth: Rename extfeatures’, as the name says it is just a rename
and no harm, but it is a preparation for a following fix.”Also included is a fix from Jesper Juhl for a potential memory leak in
brcm80211, a one-line comment fix (plus a couple of lines of removing
unused code) from Mohammed Shafi Shajakhan in ath9k, a fix from Larry
Finger to prevent hitting a BUG in rtl8192se when an skb allocation
fails, a fix from Stanislaw Gruszka for a NULL pointer dereference
in mac80211, a fix from Rajkumar Manoharan for an ath9k regression
relating to channel noisefloor readings, and a fix from Johannes Berg
for a regression related to parsing station flags.Hopefully all of these are fine for the merge window. Please let me
know if there are problems!
-Greg KH announces the release of kernels 2.6.32.54, 3.0.17, 3.19
and 3.2.1, J. Bruce Fields has nfsd updates for 3.3, Rusty Russell
has module and param updates and David Miller has fixes for the
networking tree:
1) Bug fixes in HCI extended features parsing, from Andre Guedes.
2) Many fixed MDIO drivers don’t use a unique device name, resulting
in conflicts. Generalize to ${PLATFORM_DEVICE_NAME}-${INDEX}.
From Florian Fainelli.3) ksz884x driver doesn’t handle VLAN properly. From Doug Kehn.
4) Conversion to rcu_assign_pointer() converted not just NULL cases,
it converted non-NULL cases too which is wrong. Partial revert
from Eric Dumazet.5) IRQ masking and NAPI handling in via-rhine was buggy and could
wedge the device, fix this and suspend/resume as well. From
Francois Romieu.6) Jump label optimization of memcg socket memory code was buggy and
wouldn’t actually turn the jump label back on when the feature
was turned off. Fix from Glauber Costa.7) Missing iounmap() calls from Julia Lawall.
8) Fix TX timestamping in gianfar, from Manfred Rudigier.
9) Fix local BH enabling in wrong context when netconsole is used
over bond_alb, from Maxim Uvarov.10) Revert accidental user visible datastructure name changes in inet
diag, from Pavel Emelyanov.11) Support RED over SFQ, from Eric Dumazet.
Please pull, thanks a lot!
-Benjamin Herrenschmidt has important powerpc bugfixes,
Chris Ball has MMC updates for -rc1, Samuel Ortiz has
a MFD pull request, Florian Tobias Schandinat
updates fbdev, James Morris updates SELinux and
Jens Axboe has some small block IO bits for -rc:
It has the following changes:
– The big io context cleanup from Tejun.
– Remove duplicated block plug in mpage_readpages(). read_pages()
already does the plugging, and it’s the only call path to
mpage_readpages().– ioctl to query rotational nature of a device from Martin.
– Getting rid of the bio integrity macros, use proper functions instead.
– Recursive merging was added and then disabled, it’s suspected to be
our cause for empty cfqq crashes. It’ll be re-enabled once we get to
the bottom of this.
-Ingo Molnar has x86 and perf fixes, Steven Rostedt has updates
for the linux-trace tree, Vinod Koul updates slave-dma, Rafael J. Wysocki
has fixes for linux-pm and Daniel Vetter announces a new tree, namely
drm-intel-next:
Because Keith is routinely really busy with all kinds of things, notably
gathering fixes for drm-intel-fixes, the patch merge process for the next
release cycle sometimes falls behind. To support him and improve things I’ve
been volunteered to take over handling the -next tree.The main aim is to shift the drm/i915 -next merge process massively ahead with
the goals to:
– Reduce pressure to merge questionable patches into -rc kernels because the
-next tree is not yet open for patches.
– Allow our QA at Intel and also the community to actually test things before
they land in mainline. The lack of such testing has severly bitten us in the
past few releases.
– Refocus -fixes on handling regressions with absolute top priority (as it
should).
– And generally get a steady and predictable patch-flow towards mainline back
into gears.I plan to run this -next tree with a few simple rules:
– I’ll open the drm/i915 -next tree around -rc1 (maybe earlier in the future)
and cut regular new trees about every 2nd week or so. 2 weeks should be enough
for both our qa and the community to give it some decent testing.– I intend to send out the previous -next to Dave Airlie (assuming it tests ok)
so that he has a good check on the stuff that’s going on in i915-land. A few
other people also asked for a better overview of what’s going on on drm/i915 –
I’ll plan to announce every new -next tree with a short mail (maybe together
with the pull request to Dave for the old one).– -next will close about 1-2 weeks before the merge opens. No new features after
that point for a given release cycle.– To make this really work we also need to cut down on what can go into -fixes.
drm/i915 unfortunately has the reputation that deserves it a bunch of
draconian rules (which are stricter than drm/* in general):– Only fixes for serious issues and regressions after the -next tree went to
Dave.
– After -rc2 regression fixes only. It simply happend why too often that an
“obvious” patch blew up late in the -rc release cycle, my patches included.
– After -rc4/5 only reverts and disable patches. Imo it’s way too late to play
games by then, the real fix should go straight to -next (which will close
only a few weeks afterwards already).– Regressions have top priority, if they get neglected due to ongoing work
headed for -next I’ll refuse to merge the patches.– We have a test-suite in the intel-gpu-tools package for the kernel. Expect me
to be annoying about patches that should have testcases for them but don’t.
This includes new features, but also bugs that can be reproduced with a
reasonable amount of effort.– To avoid me pushing utter crack I will only merge my own patches after they
have gathered sufficient review on intel-gfx. Please yell at me at the top of
your voice (and in public) if I violate this.– The main discussion list for patches to drm/i915 is
intel-gfx@lists.freedesktop.org – I don’t keep up with lkml usually.– I’ll reserve my human right to act like an incompetent arrogant fool once in a
while.Last but not least, the new tree is available at
http://cgit.freedesktop.org/~danvet/drm-intel
git://people.freedesktop.org/~danvet/drm-inteldrm-intel-next is the main branch, but I expect at least a for-airlied branch
for pull requests and maybe other branches with proposed patches to show up.Comments, flames and suggestions highly welcome.
Yours, Daniel
PS: Quick version for people with too short attentation spans:
– -next will open around -rc1, a new tree should show up about every second
week. -next trees that are tested will regurarly be forwarded to Dave.– No stuff in -fixes that should go into -next instead.
– -next will close for features about 1-2 weeks ahead of the upstream merge window.
– Regressions have top priority.
– Implementing proper tests is required.
– Hit me hard if I break these rules for my own patches.
– Sometimes I’ll screw things up badly.
Now grab the tree from
git://people.freedesktop.org/~danvet/drm-intel
-Michal Marek updates kbuild and kconfig for -rc1,
Trond Myklebust announces more NFS client changes,
John W. Linville has wireless fixes, Ben Myers has
a XFS update for 3.3 and James Morris has security updates.
-Al Viro has lots of things to share for the audit tree,
Jeff Garzik has libata bugfixes, David Miller has networking
fixes and Len Brown has ACPI updates.
-James Bottomley has SCSI ups, Greg KH announces the release
of kernel 3.1.10, Mauro Carvalho Chehab has media fixes and
John W. Linville has a wireless pull request:
Here is another small group of fixes intended for 3.3. Included is
a fix from Javier Cardona to make the mesh code always use the right
headroom size for mesh management frames, a fix from Johannes Berg to
point a debugfs link to the right place, another fix from Johannes that
properly cleans-up some state in mac80211 after a deauth request,
and a fix from Stanislaw Gruszka to avoid a potential infinite
loop in brcmsmac. Also included is a small Kconfig fix from me to
discourage configurations with overlapping hardware support between
b43 and brcmsmac.
-H. Peter Anvin announces x86, perf and sched fixes for -rc1,
David Howells has an interesting patchset for linux-headers,
aaaaaaaand….
So the subject says it all. It’s been two weeks(+a day), and 3.3-rc1 is now out.
There are a couple of trees I haven’t merged on purpose, and there may
be a few trees I overlooked by mistake. The “on purpose” ones were
things that looked unfamiliar and I felt I didn’t have the bandwidth
to check. The “mistake” ones would just be things I missed due to
being busy.And it really was a pretty busy merge window. I don’t know *why* it
felt so busy, though. In pure numbers, the merge window seems to have
been pretty normal – the number of merges and regular commits are
right where you’d expect them. Part of it was spending what felt like
(and I think was) a couple of days chasing down two independent
suspend/resume regressions on my laptop, part of it was a couple of
just bad pull requests, and some of it was some of the independent
discussions that were on-going. But none of that is unheard of, so
what do I know..Anyway, it’s out now, and I’m taking off early for a weekend of beer,
skiing and poker (not necessarily in that order: “don’t drink and
ski”). No email.So if you felt that your pull request was overlooked by mistake (or
intentionally, but really not so scary that you think I should have a
really easy time checking it), you have a couple of days to marshal
your arguments for why I should pull it after all.And if you didn’t send your pull request in time: “Phhhthrthtpt!”. No
arguments for that one.(Stats for those that like them: 20% arch updates (arm, power, mips,
x86), 60% drivers (networking – wireless in particular, staging,
media, dri, sound, misc – including getting rid of ‘struct sysdev’),
and 20% random stuff: filesystems, networking, perf etc)Linus
Schaiba's Blog 