All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philip Downer <phil@csldevices.co.uk>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: firmware loading interface
Date: Mon, 16 Nov 2009 10:57:00 +0000	[thread overview]
Message-ID: <4B012FFC.1080600@csldevices.co.uk> (raw)
In-Reply-To: <200911132029.01432.arnd@arndb.de>

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

  parent reply	other threads:[~2009-11-16 10:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4AFD971C.3090204@csldevices.co.uk>
2009-11-13 17:47 ` firmware loading interface Philip Downer
2009-11-13 19:29   ` Arnd Bergmann
     [not found]     ` <53ea87da0911140951q1050212fwe9f5839b900b3804@mail.gmail.com>
2009-11-14 17:54       ` Arnd Bergmann
2009-11-16 10:57     ` Philip Downer [this message]
2009-11-14  0:35   ` Roland Dreier
2009-11-14 16:08     ` Robert Hancock
     [not found]       ` <53ea87da0911140855u7993989aod746bcaf18ee4c31@mail.gmail.com>
2009-11-14 18:19         ` Robert Hancock
2009-11-14 18:29           ` Arjan van de Ven
2009-11-16 11:16             ` Philip Downer
2009-12-01  9:14     ` Dmitry Torokhov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B012FFC.1080600@csldevices.co.uk \
    --to=phil@csldevices.co.uk \
    --cc=arnd@arndb.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.