Message-ID: <20120103001851.3530f99d@pyramind.ukuu.org.uk>
Date:	Tue, 3 Jan 2012 00:18:51 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Jack Stone <jwjstone@...tmail.fm>
Cc:	Matthew Garrett <mjg@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	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.

> You mensioned earlier about not being able to tell the difference
> between a device that needs firmware and one that needs flash (e.g. they
> use exactly the same ids). It doesn't really matter - we just assume
> that it might need firmware and load it anyway. It uses more memory but
> is robust.

We only need to do that for the devices where order and not blocking
matters. There are a few (and some are video) where the firmware sizes is
megabytes, which on an embedded controlling device is not acceptable. I
don't believe any of them are things where simply delaying the
restoration will cause problems however - its video, and DVB and the like
not wireless or serial.

Thankfully most of the firmwares for controllers like wireless are in the
Kb range although this is going to change dramatically as people start
putting things with more brains than an 8051 or AVR into their devices.

And there an awful lot of devices with tiny 8K or so firmware where if we
have get/put firmware nobody is going to *care* if we just cache it on
module load. 40K driver, 16K of buffers, 2K firmware.... 

> Also, as Linus mensioned, for some devices we just don't care. For
> example, if we drop a video call over suspend it's not ideal but it
> doesn't prevent the system from resuming.

Doesn't work generically though. Some ARM platforms (and Moorestown in the
x86 world) can suspend/resume as a power state. So while it's probably
true for USB it's not generically a property of suspend/resume that you
can assume in any kind of firmware and ordering model.

The world is heading this way more and more. It's moving from the old PC
model of 'user closes lid, clunk for 15 seconds, enter suspend, user
opens lid, churn churn, video, churn clunk. resume' to suspend/resume
being so fast it happens between keystrokes.

(There is a whole other can of pending worms there where 'suspend' isn't
 a single state as Linux and ACPI like to pretend. There are devices that
 can show the display while the machine is "suspended", devices that can
 play back mp3 files while the machine is "suspended" and so on. Imagine
 a world where you are listening to music on your phone without
 interruption, typing on the display which is showing all the time, and
 with the CPU and at the Linux level your device is suspended between
 keystrokes)

> Lets concentrate on fixing all the cases that could prevent resume (the "99%")
> and fix the other devices later.

The rules on regressions as stated by Linus are clear - no regressions. So
we need to make it work again, then fix it nicely.

Quite honestly the ugly cases with massive firmware files and the like
really want deferring, and some do that anyway with a userspace loader
for obvious reasons. Request_firmware really isn't very good for
'request bits of firmware one by one' either. Thankfully there are not
many of them.

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