what determines how firmware is loaded? (Q. on request_firmware details)

what determines how firmware is loaded? (Q. on request_firmware details)

[George Nychis]

Hi all,

I notice in an older version of Ubuntu that when I plugin a USB
wireless device its firmware is loaded via sysfs.  For example, this
would pop up in sysfs:
/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1/compat_firmware/2-1/loading

In newer versions, I'm now seeing that the firmware seems to be loaded
directly via a Kernel thread that is spawned.  It checks for the
firmware in some firmware directory (e.g., /lib/firmware) and loads it
to the device.

I see in documentation that one method is referred to as asynchronous.
 Is this the  former or latter?

Has the former method of loading firmware been removed as the default?
 Is there any way to request that the firmware load be done manually
(the former method)?

It seems as though instead of calling request_firmware(), I could call
_request_firmware() with "uevent" set to 0?  This would force for
former behavior?

Does "nowait" also have to be 0?  I don't quite understand the
separation between uevent and nowait.

Thanks!
George

Re: what determines how firmware is loaded? (Q. on request_firmware details)

[Greg KH]

On Mon, Apr 23, 2012 at 04:18:56PM -0400, George Nychis wrote:
> Hi all,
> 
> I notice in an older version of Ubuntu that when I plugin a USB
> wireless device its firmware is loaded via sysfs.  For example, this
> would pop up in sysfs:
> /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1/compat_firmware/2-1/loading

How old are we talking about here?  What version of the kernel?

> In newer versions, I'm now seeing that the firmware seems to be loaded
> directly via a Kernel thread that is spawned.  It checks for the
> firmware in some firmware directory (e.g., /lib/firmware) and loads it
> to the device.

Yes.

> I see in documentation that one method is referred to as asynchronous.
>  Is this the  former or latter?

Depends on the device.

> Has the former method of loading firmware been removed as the default?
>  Is there any way to request that the firmware load be done manually
> (the former method)?

Why?  In the end, they do the same thing, right?

> It seems as though instead of calling request_firmware(), I could call
> _request_firmware() with "uevent" set to 0?  This would force for
> former behavior?
> 
> Does "nowait" also have to be 0?  I don't quite understand the
> separation between uevent and nowait.

I don't understand the problem here, isn't the end-result the same?
What is wrong with newer kernels?

thanks,

greg k-h

Re: what determines how firmware is loaded? (Q. on request_firmware details)

[George Nychis]

Hi Greg,

On Mon, Apr 23, 2012 at 5:21 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Mon, Apr 23, 2012 at 04:18:56PM -0400, George Nychis wrote:
>> Hi all,
>>
>> I notice in an older version of Ubuntu that when I plugin a USB
>> wireless device its firmware is loaded via sysfs.  For example, this
>> would pop up in sysfs:
>> /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1/compat_firmware/2-1/loading
>
> How old are we talking about here?  What version of the kernel?

This was on a 2.6.32-21 Kernel.  Ubuntu 10.04 LTS.

>
>> Has the former method of loading firmware been removed as the default?
>>  Is there any way to request that the firmware load be done manually
>> (the former method)?
>
> Why?  In the end, they do the same thing, right?

I am having issues with the automatic load on an embedded device
running a 3.0.8 kernel.  I get USB URB related errors like this:
<7>[  708.739241] ath9k_htc 1-1.1:1.0: usb_probe_interface - got id
<3>[  708.999596] otg_err: in s5pc110_otghcd_urb_dequeue()::00508
<3>[  709.000670] => fail to cancel_transfer()
<7>[  709.002489] usb 1-1.1: hcd_unlink_urb d2f7c780 fail -1
<7>[  709.004372] usb 1-1.1: khubd timed out on ep0out len=0/4096
<3>[  709.005181] usb 1-1.1: ath9k_htc: Firmware - htc_7010.fw download failed

So I was hoping to try the manual method of sending the firmware to
see if it is related to the automatic process, or if I'm really going
to need to debug the firmware transfer.

>
>> It seems as though instead of calling request_firmware(), I could call
>> _request_firmware() with "uevent" set to 0?  This would force for
>> former behavior?
>>
>> Does "nowait" also have to be 0?  I don't quite understand the
>> separation between uevent and nowait.
>
> I don't understand the problem here, isn't the end-result the same?
> What is wrong with newer kernels?

This is likely strictly related to the embedded device, and possibly
some bugs related to it.  But I was hoping to force manual mode to
narrow down the issue and see if that is at least a possible solution.

Thanks for the response!

- George

Re: what determines how firmware is loaded? (Q. on request_firmware details)

[George Nychis]

Well, I managed to get the "manual" way going by calling
_request_firmware() directly, but I get the same error.  Looks like
this will required some USB debugging.

Thanks!
George

Re: what determines how firmware is loaded? (Q. on request_firmware details)

[Greg KH]

On Mon, Apr 23, 2012 at 05:28:51PM -0400, George Nychis wrote:
> Hi Greg,
> 
> On Mon, Apr 23, 2012 at 5:21 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Mon, Apr 23, 2012 at 04:18:56PM -0400, George Nychis wrote:
> >> Hi all,
> >>
> >> I notice in an older version of Ubuntu that when I plugin a USB
> >> wireless device its firmware is loaded via sysfs.  For example, this
> >> would pop up in sysfs:
> >> /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1/compat_firmware/2-1/loading
> >
> > How old are we talking about here?  What version of the kernel?
> 
> This was on a 2.6.32-21 Kernel.  Ubuntu 10.04 LTS.
> 
> >
> >> Has the former method of loading firmware been removed as the default?
> >>  Is there any way to request that the firmware load be done manually
> >> (the former method)?
> >
> > Why?  In the end, they do the same thing, right?
> 
> I am having issues with the automatic load on an embedded device
> running a 3.0.8 kernel.  I get USB URB related errors like this:
> <7>[  708.739241] ath9k_htc 1-1.1:1.0: usb_probe_interface - got id
> <3>[  708.999596] otg_err: in s5pc110_otghcd_urb_dequeue()::00508
> <3>[  709.000670] => fail to cancel_transfer()
> <7>[  709.002489] usb 1-1.1: hcd_unlink_urb d2f7c780 fail -1
> <7>[  709.004372] usb 1-1.1: khubd timed out on ep0out len=0/4096
> <3>[  709.005181] usb 1-1.1: ath9k_htc: Firmware - htc_7010.fw download failed

You do realize just how old and obsolete your 3.0.8 kernel is, right?  I
suggest you update to the latest version, or, if you are stuck with this
kernel, go ask the vendor who provided it to you for support, as they
are the best ones to help you out.

Either way, it looks like this is a USB issue in your usb controller,
not a firmware issue, so I don't think the firmware portion of the
interaction is the problem.

best of luck,

greg k-h

Re: what determines how firmware is loaded? (Q. on request_firmware details)

[Mark Brown]

On Mon, Apr 23, 2012 at 03:56:03PM -0700, Greg KH wrote:

> You do realize just how old and obsolete your 3.0.8 kernel is, right?  I
> suggest you update to the latest version, or, if you are stuck with this
> kernel, go ask the vendor who provided it to you for support, as they
> are the best ones to help you out.

Unfortunately 3.0 is what ICS is based off so the overwhelming majority
of vendor code is going to be based on it until the next Android
release.  With my vendor hat on I have to say that we find our upstream
first policy extremely effective so we shouldn't be part of the issue.

Re: what determines how firmware is loaded? (Q. on request_firmware details)

[Greg KH]

On Thu, Apr 26, 2012 at 04:23:10PM +0100, Mark Brown wrote:
> On Mon, Apr 23, 2012 at 03:56:03PM -0700, Greg KH wrote:
> 
> > You do realize just how old and obsolete your 3.0.8 kernel is, right?  I
> > suggest you update to the latest version, or, if you are stuck with this
> > kernel, go ask the vendor who provided it to you for support, as they
> > are the best ones to help you out.
> 
> Unfortunately 3.0 is what ICS is based off so the overwhelming majority
> of vendor code is going to be based on it until the next Android
> release.  With my vendor hat on I have to say that we find our upstream
> first policy extremely effective so we shouldn't be part of the issue.

That's great, and understandable, but the original poster said they were
using an old Ubuntu release, and the ability for the community to
support bugs in older kernel releases like this is very difficult as you
well know.

The next Android release should be "any day now" so hopefully we move on
from 3.0 soon...

thanks,

greg k-h

Re: what determines how firmware is loaded? (Q. on request_firmware details)

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]

On Thu, Apr 26, 2012 at 08:27:42AM -0700, Greg KH wrote:
> On Thu, Apr 26, 2012 at 04:23:10PM +0100, Mark Brown wrote:

> > Unfortunately 3.0 is what ICS is based off so the overwhelming majority
> > of vendor code is going to be based on it until the next Android
> > release.  With my vendor hat on I have to say that we find our upstream
> > first policy extremely effective so we shouldn't be part of the issue.

> That's great, and understandable, but the original poster said they were
> using an old Ubuntu release, and the ability for the community to
> support bugs in older kernel releases like this is very difficult as you
> well know.

Oh, I missed that bit of the thread - if they're using a desktop distro 
then upgrading should be much less painful than it would be with a
typical vendor kernel.

> The next Android release should be "any day now" so hopefully we move on
> from 3.0 soon...

Well, by the end of the summer or something - even when the release
drops there's always lag while the releases propagate out to the wider
market.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]