linux-kernel - RE: [RFC PATCH net-next 9/9] ethtool: Add ability to flash transceiver modules' firmware

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]

Date: Mon, 8 Apr 2024 12:50:23 +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 9/9] ethtool: Add ability to flash
 transceiver modules' firmware



> -----Original Message-----
> From: Danielle Ratson
> Sent: Wednesday, 31 January 2024 17:53
> To: Andrew Lunn <andrew@...n.ch>
> Cc: netdev@...r.kernel.org; davem@...emloft.net; edumazet@...gle.com;
> kuba@...nel.org; pabeni@...hat.com; corbet@....net;
> linux@...linux.org.uk; sdf@...gle.com; kory.maincent@...tlin.com;
> maxime.chevallier@...tlin.com; vladimir.oltean@....com;
> przemyslaw.kitszel@...el.com; ahmed.zaki@...el.com;
> richardcochran@...il.com; shayagr@...zon.com;
> paul.greenwalt@...el.com; jiri@...nulli.us; linux-doc@...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 9/9] ethtool: Add ability to flash transceiver
> modules' firmware
> 
> > > Subject: Re: [RFC PATCH net-next 9/9] ethtool: Add ability to flash
> > > transceiver modules' firmware
> > >
> > > > +static int
> > > > +module_flash_fw_schedule(struct net_device *dev,
> > > > +			 struct ethtool_module_fw_flash_params *params,
> > > > +			 struct netlink_ext_ack *extack) {
> > > > +	const struct ethtool_ops *ops = dev->ethtool_ops;
> > > > +	struct ethtool_module_fw_flash *module_fw;
> > > > +	int err;
> > > > +
> > > > +	if (!ops->set_module_eeprom_by_page ||
> > > > +	    !ops->get_module_eeprom_by_page) {
> > > > +		NL_SET_ERR_MSG(extack,
> > > > +			       "Flashing module firmware is not supported by
> > > this device");
> > > > +		return -EOPNOTSUPP;
> > > > +	}
> > > > +
> > > > +	if (dev->module_fw_flash_in_progress) {
> > > > +		NL_SET_ERR_MSG(extack, "Module firmware flashing already
> > > in progress");
> > > > +		return -EBUSY;
> > > > +	}
> > > > +
> > > > +	module_fw = kzalloc(sizeof(*module_fw), GFP_KERNEL);
> > > > +	if (!module_fw)
> > > > +		return -ENOMEM;
> > > > +
> > > > +	module_fw->params = *params;
> > > > +	err = request_firmware(&module_fw->fw, module_fw-
> > > >params.file_name,
> > > > +			       &dev->dev);
> > >
> > > How big are these firmware blobs?
> > >
> 
> The largest file I came across is 400K.
> 
> > > Ideally we want to be able to use the same API to upgrade things
> > > like GPON modules, which often run an openwrt image, and they are
> > > plugged into a cable modem which does not have too much RAM.
> > >
> > > Given that the interface to the EEPROM is using 128 byte 1/2 pages,
> > > would it be possible to use request_partial_firmware_into_buf() to
> > > read it on demand, rather than all at once?
> > >
> > >      Andrew
> >
> > OK, Ill handle that in the actual version.
> > Thanks.

Hi Andrew,

Thanks again for your feedback.
I thought again about you comment, and this patchset adds support for flashing CMIS compliant modules only.
Later on, if it will be expanded to more modules, it will be more reasonable to add support like you have suggested to fit the new supported standard.
So, currently I think it is better to not add it to this specific patchset.

Thanks,
Danielle