netdev - Re: [PATCH net-next v4] net: sfp: add SMBus I2C block support

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] [day] [month] [year] [list]

Message-ID: <0b411424-27a4-4b10-b4ab-b2c42f0a70da@lunn.ch>
Date: Fri, 16 Jan 2026 14:15:06 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Jonas Jelonek <jelonek.jonas@...il.com>
Cc: Maxime Chevallier <maxime.chevallier@...tlin.com>,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	Bjørn Mork <bjorn@...k.no>,
	Paolo Abeni <pabeni@...hat.com>, Jakub Kicinski <kuba@...nel.org>,
	Eric Dumazet <edumazet@...gle.com>,
	"David S . Miller" <davem@...emloft.net>,
	Russell King <linux@...linux.org.uk>,
	Heiner Kallweit <hkallweit1@...il.com>
Subject: Re: [PATCH net-next v4] net: sfp: add SMBus I2C block support

> When I come to trying to work on that, should that all be kept in
> mdio-i2c.c? I'm asking because we have a downstream implementation
> moving that SMbus stuff to mdio-smbus.c. This covers quite a lot right
> now, C22/C45 and Rollball, but just with byte access [1].

It really should be that the I2C access mechanism, and the protocol
running on top of these accesses are orthogonal. So i could see the
code split it mdio-i2c.c, mdio-smbus.c, mdio-rollaball.c,
mdio-marvell.c. But only if there is no replicated between these
files. And i'm not sure we have reached the complexity level to make
such a split.

> Because that isn't my work, I'll need to check with the original
> authors and adapt this for an upstream patch, trying to add word +
> block access.

The code should be GPL, so you should be able to just take it and
adapt it. However, i've always had a good experience asking the
authors, they either say yes, or point out issues with the code that
need addressing. BTW: IANAL.

     Andrew