> >> The third option I see is to completely ditch this, stating that
> >> although We obviously CAN set the non-volatile memory we CAN'T do it
> >> with the regular API, and to move into doing this via some
> >> proprietary API such as debugfs.
>
> > Why go to debugfs rather than gracefully exten
>> The third option I see is to completely ditch this, stating that although
>> We obviously CAN set the non-volatile memory we CAN'T do it with the
>> regular API, and to move into doing this via some proprietary API such
>> as debugfs.
> Why go to debugfs rather than gracefully extending the eth
> > There's quite a bit of `magic' here [based on the ethtool `magic'
> > field] which is retained by the user application responsible for
> > interacting with the driver for the purpose of upgrading the nvram
> > image.
>
> This is not how the 'magic' value of the eeprom structure is specified to
From: Yuval Mintz
Date: Mon, 18 Apr 2016 03:59:42 +
> The third option I see is to completely ditch this, stating that although
> We obviously CAN set the non-volatile memory we CAN'T do it with the
> regular API, and to move into doing this via some proprietary API such
> as debugfs.
Why go
From: Yuval Mintz
Date: Sun, 17 Apr 2016 22:26:35 +0300
> There's quite a bit of `magic' here [based on the ethtool `magic'
> field] which is retained by the user application responsible for
> interacting with the driver for the purpose of upgrading the nvram
> image.
This is not how the 'magic'
From: Sudarsana Reddy Kalluru
Add the driver logic needed for supporting the ethtool APIs for reading
and writing from the interface's eeprom.
There's quite a bit of `magic' here [based on the ethtool `magic' field]
which is retained by the user application responsible for interacting
with the d
