On 05/05/2016 03:20 PM, Jason Gunthorpe wrote:
> On Thu, May 05, 2016 at 02:57:01PM -0400, Doug Ledford wrote:
>
>> and the eeprom is written with the new data. If you need to do special
>> things, like Mellanox, in terms of recovering burned data like GIDs
>> or
>
> The 'eeprom' and device firmware are very different things. hfi1 has
> both, and uses request_firmware too.
>
> I've never heard of a driver using ethtool eeprom to deal with nv
> firmware like mlx has.
There's no reason it couldn't. Since you can pass offset and length
parameters and write things in multiple chunks, you can actually set up
access to eeprom, nv ram, and firmware all through the one interface
simply by defining the start/stop points of each to be at specific, well
known locations for your device. Then your routine could write to the
correct device based upon the location.
And in truth, whether you are talking about firmware, some sort of
eeprom, or nv ram, it's all the same basic principle: read from or write
to this non-volatile memory of arbitrary size (ok, depending on the
device, firmware might be different...it might not be non-volatile, or
there might be a non-volatile version for boot and a running copy that
can be downloaded by the kernel where the running copy and the boot time
non-volatile copy are not necessarily the same). Only the the nitty
gritty of the access varies based upon the device in question. Aside
from making sure to get the right device, user space couldn't care less
about the distinction of the hardware type used to implement it.
> AFAIK there is no kernel convention for that
> stuff. It is more common for storage than network drivers.
You're right, it is more common for storage devices (raid hardware in
particular). And a lot of that hardware doesn't have a good means for
doing this. Different vendors have rolled their own solutions (Dell for
instance uses their own kernel driver to allow updated the firmware on
all of the devices they ship, including raid storage controllers,
onboard Ethernet and PXE booters, etc). But since we have a netdevice
on everything, I see no reason not to use the eeprom routines already
present.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: 0E572FDD
Attachment:
signature.asc
Description: OpenPGP digital signature
