All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Hutchings <ben@decadent.org.uk>
To: Bill Davidsen <davidsen@tmr.com>
Cc: Greg KH <greg@kroah.com>, CaT <cat@zip.com.au>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	bzolnier@gmail.com, stable@kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Linux 2.6.34 (rt2860 regression)
Date: Tue, 18 May 2010 19:37:14 +0100	[thread overview]
Message-ID: <20100518183713.GS16821@decadent.org.uk> (raw)
In-Reply-To: <4BF2C78A.7090903@tmr.com>

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.

>>> 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.
[...]

The firmware and driver are separate works, often written by different
people and usually released on a separate schedule under different licences.

> 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.

Modules that load firmware should have modinfo giving the filenames they
may requested.  Initramfs builders use that to find the files to include.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
                                                              - Albert Camus

  reply	other threads:[~2010-05-18 18:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-16 21:39 Linux 2.6.34 Linus Torvalds
2010-05-17  3:00 ` Bill Davidsen
2010-05-18 11:44 ` Linux 2.6.34 (rt2860 regression) CaT
2010-05-18 12:55   ` Greg KH
2010-05-18 13:17     ` CaT
2010-05-18 13:33       ` Greg KH
2010-05-18 14:13         ` CaT
2010-05-18 14:43           ` Greg KH
2010-05-18 15:06           ` Nick Bowler
2010-05-18 16:59         ` Bill Davidsen
2010-05-18 18:37           ` Ben Hutchings [this message]
2010-05-18 20:13             ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100518183713.GS16821@decadent.org.uk \
    --to=ben@decadent.org.uk \
    --cc=bzolnier@gmail.com \
    --cc=cat@zip.com.au \
    --cc=davidsen@tmr.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.