netdev - Re: [PATCH RFC v2 0/2] Add I2C fwnode lookup/get interfaces

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:   Tue, 3 Jan 2023 12:20:38 +0000
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>, Wolfram Sang <wsa@...nel.org>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        linux-acpi@...r.kernel.org, linux-i2c@...r.kernel.org,
        netdev@...r.kernel.org
Subject: Re: [PATCH RFC v2 0/2] Add I2C fwnode lookup/get interfaces

Hi Wolfram, David, Eric, Paolo,

How would you like to handle merging these patches? I'm not expecting
any changes during this cycle which would conflict with the sfp.c
changes in this series, so the series could be merged through the i2c
tree. However, I am intending to send additional sfp.c changes which
are independent of this.

Thanks.

On Mon, Dec 19, 2022 at 09:50:19AM +0000, Russell King (Oracle) wrote:
> Hi,
> 
> This RFC series is intended for the next merge window, but we will need
> to decide how to merge it as it is split across two subsystems. These
> patches have been generated against the net-next, since patch 2 depends
> on a recently merged patch in that tree (which is now in mainline.)
> 
> Currently, the SFP code attempts to work out what kind of fwnode we
> found when looking up the I2C bus for the SFP cage, converts the fwnode
> to the appropriate firmware specific representation to then call the
> appropriate I2C layer function. This is inefficient, since the device
> model provides a way to locate items on a bus_type by fwnode.
> 
> In order to reduce this complexity, this series adds fwnode interfaces
> to the I2C subsystem to allow I2C adapters to be looked up. I also
> accidentally also converted the I2C clients to also be looked up, so
> I've left that in patch 1 if people think that could be useful - if
> not, I'll remove it.
> 
> We could also convert the of_* functions to be inline in i2c.h and
> remove the stub of_* functions and exports.
> 
> Do we want these to live in i2c-core-fwnode.c ? I don't see a Kconfig
> symbol that indicates whether we want fwnode support, and I know there
> are people looking to use software nodes to lookup the SFP I2C bus
> (which is why the manual firmware-specific code in sfp.c is a problem.)
> 
> Thanks!
> 
> v2: updated patch 1 with docbook comments.
> 
>  drivers/i2c/i2c-core-acpi.c | 13 +-----
>  drivers/i2c/i2c-core-base.c | 98 +++++++++++++++++++++++++++++++++++++++++++++
>  drivers/i2c/i2c-core-of.c   | 51 ++---------------------
>  drivers/net/phy/sfp.c       | 13 +-----
>  include/linux/i2c.h         |  9 +++++
>  5 files changed, 112 insertions(+), 72 deletions(-)
> 
> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
> 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!