From: Robert Hancock <hancockrwd@gmail.com>
To: venu <vjosyula@gmail.com>
Cc: Roland Dreier <rdreier@cisco.com>,
Philip Downer <phil@csldevices.co.uk>,
linux-kernel@vger.kernel.org
Subject: Re: firmware loading interface
Date: Sat, 14 Nov 2009 12:19:13 -0600 [thread overview]
Message-ID: <51f3faa70911141019y1248fb27k5f7edb3729f72375@mail.gmail.com> (raw)
In-Reply-To: <53ea87da0911140855u7993989aod746bcaf18ee4c31@mail.gmail.com>
On Sat, Nov 14, 2009 at 10:55 AM, venu <vjosyula@gmail.com> 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 <hancockrwd@gmail.cr 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..
next prev parent reply other threads:[~2009-11-14 18:19 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 ` 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
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 [this message]
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=51f3faa70911141019y1248fb27k5f7edb3729f72375@mail.gmail.com \
--to=hancockrwd@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=phil@csldevices.co.uk \
--cc=rdreier@cisco.com \
--cc=vjosyula@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®