[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fe1bf7b6-d024-447c-a672-e84f4e77f8d7@lunn.ch>
Date: Fri, 16 Jan 2026 15:25:50 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Maxime Chevallier <maxime.chevallier@...tlin.com>
Cc: Jonas Jelonek <jelonek.jonas@...il.com>,
Russell King <linux@...linux.org.uk>,
Heiner Kallweit <hkallweit1@...il.com>,
"David S . Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
Bjørn Mork <bjorn@...k.no>
Subject: Re: [PATCH net-next v5] net: sfp: extend SMBus support
> > Is there a use case for odd lengths? Apart from 1.
>
> There's sfp_cotsworks_fixup_check() that does a 3-byte access :
>
> id->base.phys_id = SFF8024_ID_SFF_8472;
> id->base.phys_ext_id = SFP_PHYS_EXT_ID_SFP;
> id->base.connector = SFF8024_CONNECTOR_LC;
> sfp_write(sfp, false, SFP_PHYS_ID, &id->base, 3);
Ah, fixing those broken cotsworks PHYs.
> It may be possible to turn that into 2 2-byte accesses if we write
>
> id->base.phys_id = SFF8024_ID_SFF_8472;
> id->base.phys_ext_id = SFP_PHYS_EXT_ID_SFP;
>
> and then
>
> id->base.phys_ext_id = SFP_PHYS_EXT_ID_SFP;
> id->base.connector = SFF8024_CONNECTOR_LC;
Or just don't bother fixing the EEPROM, leave it broken, but use the
corrected values internally.
> But let's first figure-out if word-only smbus are really a thing
Some grep foo on /drivers/i2c/busses might answer that.
Andrew
Powered by blists - more mailing lists