Add I2C fwnode lookup/get interfaces
Subsystems (8)
Russell King (Oracle)
maintainerv2 cover Add I2C fwnode lookup/get interfaces
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(-)
Signature · 2 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
RFC PATCH v2 1/2 i2c: add fwnode APIs
Add fwnode APIs for finding and getting I2C adapters, which will be used by the SFP code. These are passed the fwnode corresponding to the adapter, and return the I2C adapter. It is the responsibility of the caller to find the appropriate fwnode.
We keep the DT and ACPI interfaces, but where appropriate, recode them to use the fwnode interfaces internally.
---
v2: update docbook comments
drivers/i2c/i2c-core-acpi.c | 13 +---- drivers/i2c/i2c-core-base.c | 98 +++++++++++++++++++++++++++++++++++++ drivers/i2c/i2c-core-of.c | 51 ++----------------- include/linux/i2c.h | 9 ++++ 4 files changed, 111 insertions(+), 60 deletions(-)
drivers/i2c/i2c-core-acpi.c +1 -12
@@ -442,18 +442,7 @@ EXPORT_SYMBOL_GPL(i2c_acpi_find_adapter_by_handle);static struct i2c_client *i2c_acpi_find_client_by_adev (struct acpi_device *adev) { -struct device *dev; -struct i2c_client *client; - - dev =bus_find_device_by_acpi_dev (&i2c_bus_type, adev); -if (!dev) -return NULL ; - - client =i2c_verify_client (dev); -if (!client) -put_device (dev); - -return client; +return i2c_find_device_by_fwnode (acpi_fwnode_handle (adev)); } static int i2c_acpi_notify(struct notifier_block *nb, unsigned long value,
drivers/i2c/i2c-core-base.c +98 -0
110 lines not on this page · raw message
drivers/i2c/i2c-core-of.c +3 -48
72 lines not on this page · raw message
include/linux/i2c.h +9 -0
@@ -965,6 +965,15 @@ int i2c_handle_smbus_host_notify(struct i2c_adapter *adap, unsigned short addr);#endif /* I2C */ +/* must call put_device() when done with returned i2c_client device */ +struct i2c_client *i2c_find_device_by_fwnode (struct fwnode_handle *fwnode); + +/* must call put_device() when done with returned i2c_adapter device */ +struct i2c_adapter *i2c_find_adapter_by_fwnode (struct fwnode_handle *fwnode); + +/* must call i2c_put_adapter() when done with returned i2c_adapter device */ +struct i2c_adapter *i2c_get_adapter_by_fwnode (struct fwnode_handle *fwnode); +#if IS_ENABLED (CONFIG_OF )/* must call put_device() when done with returned i2c_client device */ struct i2c_client *of_find_i2c_device_by_node (struct device_node *node);
Signature · 1 line
2.30.2
Re: [PATCH RFC net-next v2 1/2] i2c: add fwnode APIs
Quoted 9 lines · Russell King (Oracle)
Add fwnode APIs for finding and getting I2C adapters, which will be used by the SFP code. These are passed the fwnode corresponding to the adapter, and return the I2C adapter. It is the responsibility of the caller to find the appropriate fwnode.
We keep the DT and ACPI interfaces, but where appropriate, recode them to use the fwnode interfaces internally.
Signed-off-by Russell King (Oracle) <[email protected]>
RFC PATCH v2 2/2 net: sfp: use i2c_get_adapter_by_fwnode()
In reply to Russell King (Oracle)Use the newly introduced i2c_get_adapter_by_fwnode() API, so that we can retrieve the I2C adapter in a firmware independent manner once we have the fwnode handle for the adapter.
--- drivers/net/phy/sfp.c | 13 +------------ 1 file changed, 1 insertion(+), 12 deletions(-)
drivers/net/phy/sfp.c +1 -12
@@ -2644,10 +2644,8 @@ static void sfp_cleanup(void *data)static int sfp_i2c_get (struct sfp *sfp) { -struct acpi_handle *acpi_handle;struct fwnode_handle *h;struct i2c_adapter *i2c; -struct device_node *np;int err; h =fwnode_find_reference (dev_fwnode (sfp->dev),"i2c-bus" ,0 );
@@ -2656,16 +2654,7 @@ static int sfp_i2c_get(struct sfp *sfp)return -ENODEV ; } -if (is_acpi_device_node (h)) { - acpi_handle =ACPI_HANDLE_FWNODE (h); - i2c =i2c_acpi_find_adapter_by_handle (acpi_handle); - }else if ((np =to_of_node (h)) !=NULL ) { - i2c =of_find_i2c_adapter_by_node (np); - }else { - err = -EINVAL ; - goto put; - } - + i2c =i2c_get_adapter_by_fwnode (h);if (!i2c) { err = -EPROBE_DEFER ; goto put;
Signature · 1 line
2.30.2
Re: [PATCH RFC net-next v2 2/2] net: sfp: use i2c_get_adapter_by_fwnode()
Quoted 5 lines · Russell King (Oracle)
Use the newly introduced
i2c_get_adapter_by_fwnode()API, so that we can retrieve the I2C adapter in a firmware independent manner once we have the fwnode handle for the adapter.Signed-off-by Russell King (Oracle) <[email protected]>
Russell King (Oracle)
maintainerHi 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.
Quoted 42 lines · Russell King (Oracle)
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_typeby 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.hand remove the stub of_* functions and exports.Do we want these to live in
i2c-core-fwnode.c? I don't see aKconfigsymbol 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 insfp.cis 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(-)Signature · 2 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Signature · 2 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Hi Russell,
thank you for this series!
Quoted 4 lines
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.)
I'd prefer to apply it all to my I2C tree then. I can also provide an immutable branch for net if that is helpful.
Quoted 5 lines
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.
Because you also converted I2C ACPI to use the new function, I'd say let's keep it.
Quoted 2 lines
We could also convert the of_* functions to be inline in
i2c.hand remove the stub of_* functions and exports.
I'd like that.
Quoted 1 line
Do we want these to live in
i2c-core-fwnode.c? I don't see aKconfig
I don't think this is enough fwnode-specific code yet for a seperate source file. I also don't think the helper functions are so large that there should be an option to compile them out. I am open for other opinions, but IMHO that part looks good as it is.
Quoted 3 lines
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.cis a problem.)
All the best,
Wolfram
Russell King (Oracle)
maintainerQuoted 7 lines · Wolfram Sang
Quoted 4 lines
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.)
I'd prefer to apply it all to my I2C tree then. I can also provide an immutable branch for net if that is helpful.
If we go for the immutable branch, then patch 2 might as well be merged via the net tree, if net-next is willing to pull your immutable branch.
Dave? Jakub? Paolo? Do you have any preferences how you'd like to handle this?
Thanks.
Signature · 2 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Jakub Kicinski
maintainerQuoted 9 lines · On Tue, 10 Jan 2023 13:02:36 +0000 Russell King (Oracle) wrote:
Quoted 7 lines · Wolfram Sang
Quoted 4 lines
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.)
I'd prefer to apply it all to my I2C tree then. I can also provide an immutable branch for net if that is helpful.
Quoted 6 lines
If we go for the immutable branch, then patch 2 might as well be merged via the net tree, if net-next is willing to pull your immutable branch.
Dave? Jakub? Paolo? Do you have any preferences how you'd like to handle this?
No strong preference here. Immutable branch works.
Patch 2 will stick out in the diffstat for i2c so may indeed be better to apply it to net-next only, then again perhaps Wolfram prefers to have the user merged with the API? We're fine either way.