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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CO2PR11MB00888E4DBF49BE0A98ACB381976B0@CO2PR11MB0088.namprd11.prod.outlook.com>
Date:	Mon, 18 Apr 2016 05:50:05 +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.