Linux 2.6.34 (rt2860 regression)
in [Kernel]
|
From: Greg KH on 18 May 2010 09:00 On Tue, May 18, 2010 at 09:44:26PM +1000, CaT wrote: > On Sun, May 16, 2010 at 02:39:36PM -0700, Linus Torvalds wrote: > > So 2.6.34 is out, and the merge window is thus officially open. As usual, > > I probably won't do any real pulls for a day or two, in the (probably > > futile) hope that we'll have more people running plain 2.6.34 for a while. > > But you can certainly start sending me pull requests. > > > > Go forth and test, > > Whilst I realise this is for a staging driver... On 2010/3/4 the firmware > for the rt2860 driver (amongst others) was removed as part of a patch > to get the driver to use request_firmware(). See: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c22202faade08b6b45f14fd86bfb57f79d73464c > > The firmware is in the linux-firmware.git repository and has been for a > while (at least I think that's the right firmware): > > http://git.kernel.org/?p=linux/kernel/git/airlied/linux-firmware.git;a=history;f=rt2860.bin;h=778a771716aff389c79fec3b245ed00beba23a67;hb=HEAD > > Is there any chance of this making it into 2.6.34.1/35 so that the driver > works again as it once did? I do not understand. The firmware is now part of the linux-firmware tree, and if you install that, it is working just fine, right? We moved the firmware out of the kernel tree on purpose. So what is the problem here? confused, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Greg KH on 18 May 2010 09:40 On Tue, May 18, 2010 at 11:17:06PM +1000, CaT wrote: > On Tue, May 18, 2010 at 05:55:39AM -0700, Greg KH wrote: > > I do not understand. The firmware is now part of the linux-firmware > > tree, and if you install that, it is working just fine, right? We moved > > the firmware out of the kernel tree on purpose. > > > > So what is the problem here? > > Well, the driver used to work and appears to be useless without it. I guess > I'm wondering why it was kept out of the firmware directory where all the > other firmware lives (and so allow the driver to simply continue to work > and allow it to be compiled in). Because we are not adding new firmware to the kernel tree wherever possible, but instead, putting it in the separate linux-firmware tree. > At the moment all the change appears to have done is break things that have > been working without issue since before the driver was even in staging. Just update the linux-firmware package and all will be working again. We've been moving the firmware out of the staging drivers for a while now, as they don't belong in the kernel tree. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Greg KH on 18 May 2010 10:50 On Wed, May 19, 2010 at 12:13:15AM +1000, CaT wrote: > On Tue, May 18, 2010 at 06:33:36AM -0700, Greg KH wrote: > > Just update the linux-firmware package and all will be working again. > > We've been moving the firmware out of the staging drivers for a while > > now, as they don't belong in the kernel tree. > > Curses. Ok. Is there any chance of being able to include these in the > vmlinuz file (for the sake of tidyness) or are, after 12 years or so, > my monolithic days over? For hardware with firmware packages like this, yes, sorry, it is. Welcome to the new century :) greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Nick Bowler on 18 May 2010 11:10 On 00:13 Wed 19 May , CaT wrote: > On Tue, May 18, 2010 at 06:33:36AM -0700, Greg KH wrote: > > Just update the linux-firmware package and all will be working again. > > We've been moving the firmware out of the staging drivers for a while > > now, as they don't belong in the kernel tree. > > Curses. Ok. Is there any chance of being able to include these in the > vmlinuz file (for the sake of tidyness) or are, after 12 years or so, > my monolithic days over? Yes, you can do this: see the CONFIG_EXTRA_FIRMWARE option. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Bill Davidsen on 18 May 2010 13:10 Greg KH wrote: > On Tue, May 18, 2010 at 11:17:06PM +1000, CaT wrote: >> On Tue, May 18, 2010 at 05:55:39AM -0700, Greg KH wrote: >>> I do not understand. The firmware is now part of the linux-firmware >>> tree, and if you install that, it is working just fine, right? We moved >>> the firmware out of the kernel tree on purpose. >>> >>> So what is the problem here? >> Well, the driver used to work and appears to be useless without it. I guess >> I'm wondering why it was kept out of the firmware directory where all the >> other firmware lives (and so allow the driver to simply continue to work >> and allow it to be compiled in). > > Because we are not adding new firmware to the kernel tree wherever > possible, but instead, putting it in the separate linux-firmware tree. > I don't think that's the case here, he's not asking that new firmware be put in the kernel, just that existing firmware not be taken out. >> At the moment all the change appears to have done is break things that have >> been working without issue since before the driver was even in staging. > > Just update the linux-firmware package and all will be working again. > We've been moving the firmware out of the staging drivers for a while > now, as they don't belong in the kernel tree. > I'm not sure that I see the logic of having a kernel with a driver which doesn't work without the firmware, and a firmware tree which is equally useless on it's own. At the least I would expect the kernel build system to refuse to build the driver unless the firmware was present, and then build the firmware from wherever it's been hidden and put the whole thing into a bootable kernel. Obviously firmware needs to be in the kernel image, or the building of initram becomes really nasty for NFS root systems. -- Bill Davidsen <davidsen(a)tmr.com> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|
Next
|
Last
Pages: 1 2 Prev: Kjære Student / Medarbeidere Next: About Schedule && Request Materials |