Hi,
I'm working for a company which is manufacturing a new pci card. The
details are probably irrelevant at this stage, but for those who might
be concerned the driver will be covered by the GPL and submitted
upstream at or before the launch of the card.
Currently I'm investigating how to provide firmware upgrades for the
card, and I've been looking at the request_firmware api. All of the
documentation (and mails that I've read from lkml archives) suggest that
request_firmware is for use with devices without firmware stored in
flash or eeprom, and to load it in to memory at initialisation of the
device.
However our device will have flash to store the firmware in and, whilst
it looks as though it would be possible for us to use request_firmware
to provide occasional firmware upgrades from userspace, I can't find any
reference as to whether this is an accepted method for doing so. Could
someone please confirm for me whether or not it's a good idea to use
request_firmware for this, or perhaps point me at another standard
method for doing firmware updates from userspace?
Please note that I am not subscribed to this mailing list, so could
anyone responding please CC me in their response.
Philip Downer
On Friday 13 November 2009, Philip Downer wrote:
> However our device will have flash to store the firmware in and, whilst
> it looks as though it would be possible for us to use request_firmware
> to provide occasional firmware upgrades from userspace, I can't find any
> reference as to whether this is an accepted method for doing so. Could
> someone please confirm for me whether or not it's a good idea to use
> request_firmware for this, or perhaps point me at another standard
> method for doing firmware updates from userspace?
The idea of request_firmware is that it helps you load the firmware
into the device at initialization time so you can use it directly,
without making the firmware blob a part of the kernel driver.
If I understand you correctly, you never need a firmware in user space
in order to use the device, but only for flashing a new version into
the nonvolatile memory.
The easiest way to do that would be an ioctl operation, if you are
implementing a character or block device interface anyway. Just load
the firmware into the RAM of a user application and call an ioctl
with the pointer to the firmware as an argument, but don't use
a data structure with a pointer in it, which would mess up 32 bit
compatibility operation.
If you don't implement a character or block device, the chances are
that you need something else besides an ioctl, depending on how
an application would communicate with your hardware.
Arnd <><
> However our device will have flash to store the firmware in and, whilst
> it looks as though it would be possible for us to use request_firmware
> to provide occasional firmware upgrades from userspace, I can't find any
> reference as to whether this is an accepted method for doing so. Could
> someone please confirm for me whether or not it's a good idea to use
> request_firmware for this, or perhaps point me at another standard
> method for doing firmware updates from userspace?
I think request_firmware() is fine for this... you could have a look at
drivers/net/cxgb3 to see a device that writes new firmware to flash when
it detects a version mismatch between driver and device.
- R.
On 11/13/2009 06:35 PM, Roland Dreier wrote:
>
> > However our device will have flash to store the firmware in and, whilst
> > it looks as though it would be possible for us to use request_firmware
> > to provide occasional firmware upgrades from userspace, I can't find any
> > reference as to whether this is an accepted method for doing so. Could
> > someone please confirm for me whether or not it's a good idea to use
> > request_firmware for this, or perhaps point me at another standard
> > method for doing firmware updates from userspace?
>
> I think request_firmware() is fine for this... you could have a look at
> drivers/net/cxgb3 to see a device that writes new firmware to flash when
> it detects a version mismatch between driver and device.
It depends on the consequences of a failed flash due to losing power,
crash, etc - if it has the potential to brick the device then I don't
think that should happen without the user triggering it explicitly..
On Saturday 14 November 2009, venu wrote:
> Hi Arnd,
>
> When the driver calls the request_firmware during initialization where is
> the firmware stored. What mean to ask is where the path it picks th firmware
> from ?
See Documentation/firmware_class/README. The file name is hardcoded
in the device driver. The path is part of the hotplug implementation,
typicaly /lib/firmware.
Arnd <><
On Sat, Nov 14, 2009 at 10:55 AM, venu <[email protected]> wrote:
> ?who triggers this upgrade from userspace ? I understand it is a naivee /
> beginers questions but i hope somebody explains me how ?
The request_firmware interface probably isn't suitable for that..
using an ioctl or read/write-based interface, possibly on a separate
device node, would likely be the way to go..
>
> On Sat, Nov 14, 2009 at 9:38 PM, Robert Hancoctk <[email protected] tom>
> wrote:
>>
>> On 11/13/2009 06:35 PM, Roland Dreier wrote:
>>>
>>> ?> ?However our device will have flash to store the firmware in and,
>>> whilst
>>> ?> ?it looks as though it would be possible for us to use
>>> request_firmware
>>> ?> ?to provide occasional firmware upgrades from userspace, I can't find
>>> any
>>> ?> ?reference as to whether this is an accepted method for doing so.
>>> Could
>>> ?> ?someone please confirm for me whether or not it's a good idea to use
>>> ?> ?request_firmware for this, or perhaps point me at another standard
>>> ?> ?method for doing firmware updates from userspace?
>>>
>>> I think request_firmware() is fine for this... you could have a look at
>>> drivers/net/cxgb3 to see a device that writes new firmware to flash when
>>> it detects a version mismatch between driver and device.
>>
>> It depends on the consequences of a failed flash due to losing power,
>> crash, etc - if it has the potential to brick the device then I don't think
>> that should happen without the user triggering it explicitly..
On Sat, 14 Nov 2009 12:19:13 -0600
Robert Hancock <[email protected]> wrote:
> On Sat, Nov 14, 2009 at 10:55 AM, venu <[email protected]> wrote:
> > who triggers this upgrade from userspace ? I understand it is a
> > naivee / beginers questions but i hope somebody explains me how ?
>
> The request_firmware interface probably isn't suitable for that..
> using an ioctl or read/write-based interface, possibly on a separate
> device node, would likely be the way to go..
>
it's not unusual to have a sysfs attribute that, when written to, will
just do a request_firmware().
It's not pretty, but it's cleaner than the alternatives....
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
Arnd Bergmann wrote:
> On Friday 13 November 2009, Philip Downer wrote:
>
>> However our device will have flash to store the firmware in and, whilst
>> it looks as though it would be possible for us to use request_firmware
>> to provide occasional firmware upgrades from userspace, I can't find any
>> reference as to whether this is an accepted method for doing so. Could
>> someone please confirm for me whether or not it's a good idea to use
>> request_firmware for this, or perhaps point me at another standard
>> method for doing firmware updates from userspace?
>>
>
> The idea of request_firmware is that it helps you load the firmware
> into the device at initialization time so you can use it directly,
> without making the firmware blob a part of the kernel driver.
>
> If I understand you correctly, you never need a firmware in user space
> in order to use the device, but only for flashing a new version into
> the nonvolatile memory.
>
Thats correct.
> The easiest way to do that would be an ioctl operation, if you are
> implementing a character or block device interface anyway. Just load
> the firmware into the RAM of a user application and call an ioctl
> with the pointer to the firmware as an argument, but don't use
> a data structure with a pointer in it, which would mess up 32 bit
> compatibility operation.
Thank you for this suggestion and for the warning about 32bit, we are in
fact implementing a character device and could use this method.
Thanks,
Philip Downer
Arjan van de Ven wrote:
> it's not unusual to have a sysfs attribute that, when written to, will
> just do a request_firmware().
> It's not pretty, but it's cleaner than the alternatives....
>
This was in fact what I was considering when making my initial post, but
couldn't find any examples or drivers which do use sysfs and request
firmware in this way and as you say, it's not pretty. However if it's
considered to be cleaner by others (I certainly think it to be so) then
I am inclined to use this method as opposed to the ioctl method
suggested by Arnd earlier in the thread.
Arjan, could you possibly point me at any drivers which already work in
this way?
Thanks,
Philip Downer
On Fri, Nov 13, 2009 at 04:35:01PM -0800, Roland Dreier wrote:
>
> > However our device will have flash to store the firmware in and, whilst
> > it looks as though it would be possible for us to use request_firmware
> > to provide occasional firmware upgrades from userspace, I can't find any
> > reference as to whether this is an accepted method for doing so. Could
> > someone please confirm for me whether or not it's a good idea to use
> > request_firmware for this, or perhaps point me at another standard
> > method for doing firmware updates from userspace?
>
> I think request_firmware() is fine for this... you could have a look at
> drivers/net/cxgb3 to see a device that writes new firmware to flash when
> it detects a version mismatch between driver and device.
>
Doesn't dell_rbu also uses request-firmware for flashing BIOS?
--
Dmitry