[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dc0531a3-b9b9-4b51-8ce7-f03e23ea0877@bootlin.com>
Date: Fri, 16 Jan 2026 15:00:49 +0100
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: Jonas Jelonek <jelonek.jonas@...il.com>,
Russell King <linux@...linux.org.uk>, Andrew Lunn <andrew@...n.ch>,
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>
Cc: 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
On 16/01/2026 14:43, Jonas Jelonek wrote:
> Hi,
>
> On 16.01.26 14:23, Maxime Chevallier wrote:
>> I think Russell pointed it out, but I was also wondering the same.
>> How do we deal with controllers that cannot do neither block nor
>> single-byte, i.e. that can only do word access ?
>>
>> We can't do transfers that have an odd length. And there are some,
>> see sfp_cotsworks_fixup_check() for example.
>>
>> Maybe these smbus controller don't even exist, but I think we should
>> anyway have some log saying that this doesn't work, either at SFP
>> access time, or at init time.
>
> I tried to guard that in the sfp_i2c_configure() right now. The whole path
> to allow SMBus transfers is only allowed if there's at least byte access. For
> exactly the reason that we need byte access in case of odd lengths. Then,
> it can upgrade to word or block access if available. Or did I miss anything in
> the conditions?
Ah true, true. Should you need to respin, maybe add a comment for
clueless people like myself :)
I'll see if I can give this a test today then
Thanks
Maxime
Powered by blists - more mailing lists