netdev - RE: [PATCH net-next 5/5] qed*: Add support for read/write of eeprom

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<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