linux-kernel - Re: Linux 2.6.34 (rt2860 regression)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20100518201337.GE20223@kroah.com>
Date:	Tue, 18 May 2010 13:13:37 -0700
From:	Greg KH <greg@...ah.com>
To:	Ben Hutchings <ben@...adent.org.uk>
Cc:	Bill Davidsen <davidsen@....com>, CaT <cat@....com.au>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	bzolnier@...il.com, stable@...nel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 2.6.34 (rt2860 regression)

On Tue, May 18, 2010 at 07:37:14PM +0100, Ben Hutchings wrote:
> On Tue, May 18, 2010 at 12:59:54PM -0400, Bill Davidsen wrote:
> > 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.
> 
> New firmware should not be added to the kernel.  This rule has been
> documented since v2.6.30.  Now this rule (like many others) is relaxed for
> staging, but you can expect that firmware will be removed as part of the
> cleanup process to make staging drivers follow the rules.

Yes, that is why these firmware blobs are being moved out.  They
originally came in with the initial import of the driver to the staging
tree.  And then, as part of the cleanup process, move out to the correct
interfaces that we have in the kernel for such things.

> > Obviously firmware needs to be in the kernel image, or the building of 
> > initram becomes really nasty for NFS root systems.
> 
> Modules that load firmware should have modinfo giving the filenames they
> may requested.  Initramfs builders use that to find the files to include.

Yes, this should "just work" already for this driver.  If not, please
let us know and we will be glad to fix it.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/