linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>, Wolfram Sang <wsa@kernel.org>
Cc: Andrew Lunn <andrew@lunn.ch>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Jakub Kicinski <kuba@kernel.org>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	linux-acpi@vger.kernel.org, linux-i2c@vger.kernel.org,
	netdev@vger.kernel.org
Subject: Re: [PATCH RFC v2 0/2] Add I2C fwnode lookup/get interfaces
Date: Tue, 3 Jan 2023 12:20:38 +0000	[thread overview]
Message-ID: <Y7QdlkLcN73f1Drh@shell.armlinux.org.uk> (raw)
In-Reply-To: <Y6Az235wsnRWFYWA@shell.armlinux.org.uk>

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!

  parent reply	other threads:[~2023-01-03 12:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-19  9:50 [PATCH RFC v2 0/2] Add I2C fwnode lookup/get interfaces Russell King (Oracle)
2022-12-19  9:52 ` [PATCH RFC net-next v2 1/2] i2c: add fwnode APIs Russell King (Oracle)
2022-12-19 10:55   ` Mika Westerberg
2022-12-19  9:52 ` [PATCH RFC net-next v2 2/2] net: sfp: use i2c_get_adapter_by_fwnode() Russell King (Oracle)
2022-12-19 10:55   ` Mika Westerberg
2023-01-03 12:20 ` Russell King (Oracle) [this message]
2023-01-09 11:48 ` [PATCH RFC v2 0/2] Add I2C fwnode lookup/get interfaces Wolfram Sang
2023-01-10 13:02   ` Russell King (Oracle)
2023-01-10 17:36     ` Jakub Kicinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y7QdlkLcN73f1Drh@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=wsa@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).