[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFz73GuHiOW1NoAuJLea_GKLepiZjrnrgpOKdQizPgnhoA@mail.gmail.com>
Date: Mon, 2 Jan 2012 14:03:27 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Matthew Garrett <mjg@...hat.com>
Cc: Jack Stone <jwjstone@...tmail.fm>,
Alan Stern <stern@...land.harvard.edu>,
Oliver Neukum <oliver@...kum.org>,
Dave Jones <davej@...hat.com>,
Linux Kernel <linux-kernel@...r.kernel.org>,
Larry Finger <Larry.Finger@...inger.net>,
Chaoming Li <chaoming_li@...lsil.com.cn>,
"John W. Linville" <linville@...driver.com>,
Greg Kroah-Hartman <gregkh@...e.de>,
USB list <linux-usb@...r.kernel.org>,
Linux Wireless List <linux-wireless@...r.kernel.org>
Subject: Re: loading firmware while usermodehelper disabled.
On Mon, Jan 2, 2012 at 1:50 PM, Matthew Garrett <mjg@...hat.com> wrote:
> On Mon, Jan 02, 2012 at 01:27:03PM -0800, Linus Torvalds wrote:
>
>> If we didn't load the firmware before the suspend, then the resume
>> function of a device sure as hell had better not load it at resume
>> time either.
>
> If the hardware has lost its state then refusing to load the firmware at
> resume time isn't going to leave you with a working device.
What the heck is your problem?
Go back and read it.
If it wasn't loaded before, THEN IT WASN'T WORKING BEFORE EITHER! And
if it was loaded before, then it would be cached (and thus trivially
reloaded without having to invoke user-space or disk devices that may
not be running) and thus loading it would work.
So regardless of the state before, it would resume "correctly" - in
the same state it was suspended. In other words: a caching firmware
loader would have done EXACTLY THE RIGHT THING.
Why the hell do you keep on harping on idiotic issues? Stop being a
moron, just repeat after me:
A caching firmware loader fixes all these issues
and is simple to boot. Stop the idiotic blathering already.
Linus
--
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