[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<DM6PR12MB451687F0408B3114DCAA7DC9D87D2@DM6PR12MB4516.namprd12.prod.outlook.com>
Date: Tue, 30 Jan 2024 07:43:01 +0000
From: Danielle Ratson <danieller@...dia.com>
To: Andrew Lunn <andrew@...n.ch>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "davem@...emloft.net"
<davem@...emloft.net>, "edumazet@...gle.com" <edumazet@...gle.com>,
"kuba@...nel.org" <kuba@...nel.org>, "pabeni@...hat.com" <pabeni@...hat.com>,
"corbet@....net" <corbet@....net>, "linux@...linux.org.uk"
<linux@...linux.org.uk>, "sdf@...gle.com" <sdf@...gle.com>,
"kory.maincent@...tlin.com" <kory.maincent@...tlin.com>,
"maxime.chevallier@...tlin.com" <maxime.chevallier@...tlin.com>,
"vladimir.oltean@....com" <vladimir.oltean@....com>,
"przemyslaw.kitszel@...el.com" <przemyslaw.kitszel@...el.com>,
"ahmed.zaki@...el.com" <ahmed.zaki@...el.com>, "richardcochran@...il.com"
<richardcochran@...il.com>, "shayagr@...zon.com" <shayagr@...zon.com>,
"paul.greenwalt@...el.com" <paul.greenwalt@...el.com>, "jiri@...nulli.us"
<jiri@...nulli.us>, "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, mlxsw
<mlxsw@...dia.com>, Petr Machata <petrm@...dia.com>, Ido Schimmel
<idosch@...dia.com>
Subject: RE: [RFC PATCH net-next 1/9] ethtool: Add ethtool operation to write
to a transceiver module EEPROM
> > On Mon, Jan 22, 2024 at 10:45:22AM +0200, Danielle Ratson wrote:
> > > From: Ido Schimmel <idosch@...dia.com>
> > >
> > > Ethtool can already retrieve information from a transceiver module
> > > EEPROM by invoking the ethtool_ops::get_module_eeprom_by_page
> operation.
> > > Add a corresponding operation that allows ethtool to write to a
> > > transceiver module EEPROM.
> > >
> > > The purpose of this operation is not to enable arbitrary read /
> > > write access, but to allow the kernel to write to specific addresses
> > > as part of transceiver module firmware flashing. In the future, more
> > > functionality can be implemented on top of these read / write
> > > operations.
> >
> > My memory is dim, but i thought we decided that since the algorithm to
> > program these modules is defined in the standard, all we need to do is
> > pass the firmware blob, and have an in kernel implementation of the
> > algorithm. There is no need to have an arbitrary write blob to module,
> > which might, or might not be abused in the future.
>
> O.K, back after reading more of the patches.
>
> If i'm understanding the code correctly, this is never exposed to userspace? Its
> purely an in kernel API? It would be good to make that clear in the commit
> message, and document that in the ethtool ops structure.
>
> Thanks
> Andrew
Hi Andrew,
Yes, that is correct.
Will add a clarification.
Thanks.
Powered by blists - more mailing lists