[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CO2PR11MB0088C92F46E6186231B901DC976D0@CO2PR11MB0088.namprd11.prod.outlook.com>
Date: Wed, 20 Apr 2016 05:25:22 +0000
From: Yuval Mintz <Yuval.Mintz@...gic.com>
To: David Miller <davem@...emloft.net>
CC: netdev <netdev@...r.kernel.org>,
Sudarsana Kalluru <Sudarsana.Kalluru@...gic.com>
Subject: RE: [PATCH net-next 5/5] qed*: Add support for read/write of eeprom
> >> 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 ethtool stuff
> > to explicitly support what you need?
>
> Gracefully extend it to where?
>
> The most I can learn from this is that some adapters are in need of additional
> metadata for doing this sort of stuff.
> The state-machine itself is propriety and I don't think anyone would gain from
> trying to formalize anything else from it.
> If by 'graceful extension' of ethtool API you mean adding an additional field or
> two for metadata - sure, I can do that, I just don't think of it as graceful. ;-)
>
> And if this is actually the way we want to take this, I would still [don't get upset
> ;-)] argue in favor of overloading the 'magic' field for this purpose, as bnx2x and
> bnxt are already doing.
> Basically if the 'magic' would also contain metadata that could be verified as
> appropriate [I.e., by having valid ranges], it would still fit as a safety measure for
> guaranteeing the correctness of the write request.
Hi Dave,
I'll probably send V2 [relatively] shortly, and it looks like I'll drop this one out
as I don't yet understand the expected direction through which to solve this.
I'd appreciate any suggested pointers here.
Thanks,
Yuval
Powered by blists - more mailing lists