[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1216082213.27455.109.camel@shinybook.infradead.org>
Date: Mon, 14 Jul 2008 17:36:53 -0700
From: David Woodhouse <dwmw2@...radead.org>
To: david@...g.hm
Cc: Arjan van de Ven <arjan@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
torvalds@...ux-foundation.org, alan@...rguk.ukuu.org.uk,
linux-kernel@...r.kernel.org
Subject: Re: [GIT *] Allow request_firmware() to be satisfied from
in-kernel, use it in more drivers.
On Mon, 2008-07-14 at 17:06 -0700, david@...g.hm wrote:
> On Mon, 14 Jul 2008, Arjan van de Ven wrote:
>
> > On Mon, 14 Jul 2008 16:41:19 -0700
> > Andrew Morton <akpm@...ux-foundation.org> wrote:
> >
> >> On Mon, 14 Jul 2008 16:23:26 -0700
> >> David Woodhouse <dwmw2@...radead.org> wrote:
> >>
> >>> Linus, please pull from the for-2.6.27 branch of:
> >>> git://git.infradead.org/users/dwmw2/firmware-2.6.git
> >>> for-2.6.27
> >>
> >> The firmware flamewars seem to have subsided lately. Is everyone
> >> happy with this now?
> >>
> >
> > this seems to have left the contentious pieces out....
>
> almost, the one thing that this could have done would be to offer an
> option to bundle the firmware with the module. currently it offers the
> option to load the firmware at the same time as the module, not _quite_
> the same thing.
I see no real point in that. If you have userspace to load modules, then
you have userspace to load firmware.
We made 'make modules_install' install the firmware in /lib/firmware for
you at the same time as it installs the modules, to avoid problems if
people forgot to run 'make firmware_install'. That really ought to be
enough.
I know Jeff complained that it wasn't, and insisted that he _needed_ to
be able to scp a single .ko file around which contained both, and the
world was broken if he could not -- but I disagree with him.
But since I wanted this tree to be uncontentious and obviously the
correct thing to do, I've dropped the drivers/net changes for now
anyway.
It's odd that this request has suddenly come out of the blue when we've
been using request_firmware() from modules for years already.
> there was also the issue that was raised about how to handle firmware
> during suspend/resume. I don't remember seeing a happy solution to that
> one.
My b43 seems to work fine on suspend/resume, as do most other modern
drivers which use request_firmware(). There is certainly no fundamental,
generic problem with suspend/resume vs. the firmware loader.
If you see a problem with a specific driver which we've converted, do
please point it out.
--
dwmw2
--
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/
Powered by blists - more mailing lists