Message-Id: <201201030817.53203.marek.vasut@gmail.com>
Date:	Tue, 3 Jan 2012 08:17:52 +0100
From:	Marek Vasut <marek.vasut@...il.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Jack Stone <jwjstone@...tmail.fm>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Oliver Neukum <oliver@...kum.org>,
	Matthew Garrett <mjg@...hat.com>,
	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.

> > >Hm ... and we can't have memory type that "can be swapped-out, but must
> > >be
> > >loaded back before suspend" in kernel, right?
> > 
> > Nope. Kernel swapping is a big headache and Linux doesn't do it. The only
> > thing we can do is drop any clean cache pages, but that has performance
> > implications.
> 
> You could however have an arrangement where the firmware refmanager does
> a list of request_firmware()s at the very start of the suspend process. It
> cannot be done during suspend for obvious reasons (sorry I already
> suspended the hard disk) but it can be done just before.

Yep, that sounds sane.
> 
> In that case with get/put_firmware you'd just need to extend the API to
> 
> 	get_firmware()
> 	put_firmware()
> 	get_for_suspend_firmware()
> 
> and a driver might do something like
> 
> 
> module_init
> 
> 	fw = get_for_suspend_firmware("wombatdepolariser.fw");
> 
> 
> open:  /* just optimising */
> 	kref_get(&fw->kref);
> 
> close:
> 	put_firmware(fw);
> 
> 
> module_unload:
> 	put_firmware(fw);
> 
> 
> Now the uglier side of that is how you make sure that if
> get_for_suspend_firmware() works that when we suspend the firmware is
> present. We could keep the file handle open but that might block unmounts

Nope, not like this.

> or we could assume that as its superuser stuff that the distro authors
> don't screw up - in which case we'd refuse to suspend with a nasty
> complaint if the firmware turned out to have been deleted behind our back.

No, we should just emit a warning after resume (or even before suspend) with 
something like "Couldn't reload firmware, you are an idiot for deleting it, your 
hardware won't work anymore, sorry".

> 
> You'd also have to be in situation where new device probes were not
> processed but userspace (eg the fw loader helper) were still running.

Yes, I think it'd help not only usb to have a state of userland where fw loader 
and a few similar things would still be operational. Aka. we'd need a way for 
the kernel to tell userland part of FW loader "ok, now we're going zzz, do your 
job quickly" and bump it's priority to highest (so other processes won't 
interfere). Then wait till fw loader confirms that all FW was passed to the 
kernel and suspend.

> 
> That seems to me to be a useful optimisation project for bigger firmwares
> but not something to implement on day 1 ?

For me on PalmTX, with 32MB of RAM, every kb is good. The wifi firmware there 
has 120kb or so, so I'd like to avoid having it in kernel all the time. But that 
might be a bit of an extreme case.

> 
> Alan

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