headers
Larry Finger | 1 Jan 2012 04:49
Favicon

Re: loading firmware while usermodehelper disabled.

On 12/30/2011 06:22 PM, Linus Torvalds wrote:
> On Fri, Dec 30, 2011 at 3:54 PM, Dave Jones<davej@...>  wrote:
>> We're getting a bunch of reports against Fedora 16
>> (still using 3.1) which look like some drivers are trying to
>> load firmware on resume from suspend, while usermodehelper
>> is disabled.
>
> Ok, buggy drivers. You *must*not* load firmware in your resume path,
> since there is no actual guarantee that any particular device will be
> resumed after the disk that contains the firmware images.
>
> So it's very simple: drivers that load firmware at resume time are
> buggy. No ifs, buts, or maybes about it.
>
>> Here are some example traces:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=746411
>
> It's isight_firmware_load(), in the isight_firmware driver. The driver
> doesn't actually do anything but load the firmware, and is apparently
> not very good at that either.
>
> It should either fake a disconnect and reconnect of the device (and
> let the reconnect then load the firmware through udev or something) or
> it should just save the firmware image in memory from the original
> load, and make the resume just re-initialize it - not load it.
>
> It's also possible that it could be considered a USB layer bug, and
> the USB layer should just not rebind the devices directly in the
> resume function, but do it somehow later. HOWEVER, that would only
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Stern | 1 Jan 2012 05:01
Picon
Favicon

Re: On the 19th Dec I reported an OOPS when attaching a BeagleBone

On Sat, 31 Dec 2011, David Goodenough wrote:

> > It appears that the bug was triggered by the udev rule containing the
> > new_id attribute, but exactly what went wrong is not clear -- at least,
> > not to me.  You could try commenting out that rule and see if that
> > helps.
> > 
> > Is this bug fully repeatable?
> Yes and no.  It only happens when I insert the USB cable from the 
> BeagleBone, but it does not happen every time - sounds like a timing
> problem to me.

To me too.

>  The host I am using is an elderly (and therefore not
> very fast) laptop, the processor is not SMP.
> 
> There are 4 rules:-
> 
> ACTION=="add", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_interface", 
> ATTRS{idVendor}=="0403", ATTRS{idProduct}=="a6d0", DRIVER=="", 
> RUN+="/sbin/modprobe -b ftdi_sio"
> 
> ACTION=="add", SUBSYSTEM=="drivers", ENV{DEVPATH}=="/bus/usb-
> serial/drivers/ftdi_sio", ATTR{new_id}="0403 a6d0"
> 
> ACTION=="add", KERNEL=="ttyUSB*", ATTRS{interface}=="BeagleBone", 
> ATTRS{bInterfaceNumber}=="00", SYMLINK+="beaglebone-jtag"
> 
> ACTION=="add", KERNEL=="ttyUSB*", ATTRS{interface}=="BeagleBone",
(Continue reading)

Permalink | Reply | 7 comments |
headers
Oliver Neukum | 1 Jan 2012 10:48

Re: loading firmware while usermodehelper disabled.

Am Samstag, 31. Dezember 2011, 19:39:18 schrieb Marek Vasut:

> maybe we should implement such thing into the firmware loader itself? Allow it 
> -- for example via some node in /dev -- to force loading firmware into some 
> buffer in kernel just before suspend so it'll certainly be readily available at 
> resume time?

This is difficult. We don't know at suspend time which firmware we will
need at resume time. We could keep a record of firmware we needed
to get to the state we are, but this is a very complex scheme.

	Regards
		Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 8 comments |
headers
Oliver Neukum | 1 Jan 2012 13:28

Re: loading firmware while usermodehelper disabled.

Am Sonntag, 1. Januar 2012, 10:54:47 schrieb Marek Vasut:
> > Am Samstag, 31. Dezember 2011, 19:39:18 schrieb Marek Vasut:
> > > maybe we should implement such thing into the firmware loader itself?
> > > Allow it -- for example via some node in /dev -- to force loading
> > > firmware into some buffer in kernel just before suspend so it'll
> > > certainly be readily available at resume time?
> > 
> > This is difficult. We don't know at suspend time which firmware we will
> > need at resume time.
> 
> That's not actually true ... you can ask the drivers if they need to load 
> firmware after resume ... that can be implemented and udev can handle it. The 
> driver should know if the hardware it's controlling is stupid or not.

Device IDs can morph due to a power loss. After resumption another driver
would bind.

	Regards
		Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 6 comments |
headers
Marek Vasut | 1 Jan 2012 18:06
Picon

Re: loading firmware while usermodehelper disabled.

> > Am Sonntag, 1. Januar 2012, 10:54:47 schrieb Marek Vasut:
> > > > Am Samstag, 31. Dezember 2011, 19:39:18 schrieb Marek Vasut:
> > > > > maybe we should implement such thing into the firmware loader
> > > > > itself? Allow it -- for example via some node in /dev -- to force
> > > > > loading firmware into some buffer in kernel just before suspend so
> > > > > it'll certainly be readily available at resume time?
> > > > 
> > > > This is difficult. We don't know at suspend time which firmware we
> > > > will need at resume time.
> > > 
> > > That's not actually true ... you can ask the drivers if they need to
> > > load firmware after resume ... that can be implemented and udev can
> > > handle it. The driver should know if the hardware it's controlling is
> > > stupid or not.
> > 
> > Device IDs can morph due to a power loss. After resumption another driver
> > would bind.
> 
> What do you mean? I don't think I quite follow.

Ah I see ... you mean like you can swap the devices (eg. usb devices) when the 
computer is asleep. Yea, that's an issue.

On the other hand, you'd expect those to keep pestering udev to load firmware 
later in the wakeup process (maybe it can be somehow defered?). But if we 
actually implemented some pre-suspend FW cache, it might help the speed of 
resume a bit, right ?

M
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Greg KH | 1 Jan 2012 20:44
Gravatar

Re: Wrong product ID for webcam Hercules Dualpix Exchange in drivers/usb/core/quirks.c file

On Fri, Dec 30, 2011 at 01:03:46PM +0000, Serge Guibert wrote:
> Good morning,
> 
> I noticed that the product ID for Hercules Dualpix Exchange webcam is not
> correct in the patch for drivers/usb/core/quirks.c posted at
> kernel.opensuse.org /cgit/kernel/commit/?id=2394d67e446bf616a0885167d5f0d397bdacfdfc
> 
> It should reads, at least for webcams sold since 2010 :
> + /* Guillemot Webcam Hercules Dualpix Exchange*/
> + { USB_DEVICE(0x06f8, *0x3005*), .driver_info = USB_QUIRK_RESET_RESUME },
> 
> 
> I think this patch has been included for 3.1 and/or 3.2 linux kernel releases.
> It has also been merged in 3.0.0-14 and 3.0.0-15 kernel for ubuntu-like distributions (oneiric).
> (see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/843431)
> 
> Could you create a patch to update product ID for the Hercules DE
> webcam, or at least tell me how to write it and to submit it (I never
> did this) ?

Please read the file, Documentation/SubmittingPatches for how to create
a patch and send it to us.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Linus Torvalds | 1 Jan 2012 21:30
Gravatar

Re: loading firmware while usermodehelper disabled.

On Sun, Jan 1, 2012 at 8:17 AM, Alan Stern <stern@...> wrote:
>
> As Linus pointed out, the real problem here is the firmware loader.
> The way it is now, a driver can't always depend on the data being
> available, even during a normal boot.  It ought to use an asynchronous
> approach; then none of these problems would arise.

WRONG.

Alan, you're not getting it. Loading firmware as part of
suspend/resume is WRONG.

It would not be made any better by an asynchronous approach, and that
isn't the problem with request_firmware().

Suspend/resume is *special*, and it's special for a very simple
reason: unlike bootup or attaching a new device, suspend/resume
happens WHILE THE USER IS ACTIVE.

Loading firmware at that time is wrong. It's impossible. You have to
have the firmware available *before* any processes might need it, but
at the same time actually loading the firmware may need help from user
space and/or other devices. It's a chicken-and-egg problem.

So let me repeat one more time: Loading firmware at resume time is a
device driver bug. Seriously. How many times do I have to say it?

And making it asynchronous doesn't make it *any* less of a bug. It
doesn't change anything but timing, but the problem was never about
timing in the first place! The problem was about dependencies. User
(Continue reading)

Permalink | Reply | 68 comments |
headers
Alan Cox | 1 Jan 2012 21:39
Face
Picon

Re: loading firmware while usermodehelper disabled.

> > Device IDs can morph due to a power loss. After resumption another driver
> > would bind.
> 
> What do you mean? I don't think I quite follow.

Lots of USB hardware appears as one device id when powered on, then when
the firmware is loaded turns into something else that becomes relevant to
the user.

So on powerup your wireless card goes

	'I've no idea what I am, feed me firmware for this id"

when it gets the firmware it disconnects, reconnects and says

	"I am a USB wireless card with this id"

When you suspend the power gets killed so the device loses its firmware
and goes back to being a firmware requesting thing on resume.

Worse still - you don't easily know if the device is in fact new and was
added while suspended, or was always there.

So for those devices you do need to load the firmware into them
automatically after the resume to work out what they are and get the MAC
to see if its the same wireless card or not.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
(Continue reading)

Permalink | Reply | 3 comments |
headers
idos | 1 Jan 2012 21:44

OTG2.0 support for SNPS DWC3 core

Hi Felipe, all,

I wonder if there is a work being done for OTG2.0 driver support over the
Synopsys dwc3 core? If so, which git/branch contain this driver?

Thanks,
Ido.

Consultant for Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 7 comments |
headers
Michael Büsch | 1 Jan 2012 21:50
Picon
Favicon

Re: loading firmware while usermodehelper disabled.

On Sun, 1 Jan 2012 20:39:45 +0000
Alan Cox <alan@...> wrote:

> When you suspend the power gets killed so the device loses its firmware
> and goes back to being a firmware requesting thing on resume.
> 
> Worse still - you don't easily know if the device is in fact new and was
> added while suspended, or was always there.
> 
> So for those devices you do need to load the firmware into them
> automatically after the resume to work out what they are and get the MAC
> to see if its the same wireless card or not.

Well, that does not prevent you from caching the firmware once you
got it from userspace and keep it until module unload (or probably device
close), so that it is already available on resume.

--

-- 
Greetings, Michael.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |

Gmane