[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9c2c52a9de5fdcc1a3a76f564da4c20db098e9a2.camel@camlingroup.com>
Date: Fri, 19 Aug 2022 10:58:19 +0200
From: Tomasz Moń <tomasz.mon@...lingroup.com>
To: Michal Kubecek <mkubecek@...e.cz>
CC: netdev@...r.kernel.org, Andrew Lunn <andrew@...n.ch>,
Krzysztof Drobiński
<k.drobinski@...lintechnologies.com>
Subject: Re: [PATCH ethtool] ethtool: fix EEPROM byte write
On Fri, 2022-08-19 at 10:27 +0200, Michal Kubecek wrote:
> On Fri, Aug 19, 2022 at 08:29:33AM +0200, Tomasz Moń wrote:
> > @@ -3531,8 +3531,7 @@ static int do_seeprom(struct cmd_context *ctx)
> >
> > if (seeprom_value_seen)
> > seeprom_length = 1;
> > -
> > - if (!seeprom_length_seen)
> > + else if (!seeprom_length_seen)
> > seeprom_length = drvinfo.eedump_len;
> >
> > if (drvinfo.eedump_len < seeprom_offset + seeprom_length) {
>
> I don't like the idea of silently ignoring the length parameter if value
> is used. We should rather issue an error for invalid combination of
> parameters, i.e. value present and length different from 1.
This patch simply restores the way ethtool 2.6.33 - 5.8 worked.
Setting length to 1 matches ethtool man page description:
> If value is specified, changes EEPROM byte for the specified network device.
> offset and value specify which byte and it's new value.
What about changing the code to default to length 1 if value is
provided without length (so scripts relying on the way ethtool 1.8 up
to 5.8 works without any change), but report error if user provides
both value and length other than 1?
Best Regards,
Tomasz Moń
Powered by blists - more mailing lists