| Message ID | Y6Az235wsnRWFYWA@shell.armlinux.org.uk |
|---|---|
| Headers | show |
| Series | Add I2C fwnode lookup/get interfaces | expand |
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! >
Hi Russell, thank you for this series! > 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. > 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. > We could also convert the of_* functions to be inline in i2c.h and > remove the stub of_* functions and exports. I'd like that. > Do we want these to live in i2c-core-fwnode.c ? I don't see a Kconfig 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. > 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.) All the best, Wolfram
On Mon, Jan 09, 2023 at 12:48:37PM +0100, Wolfram Sang wrote: > > 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.
On Tue, 10 Jan 2023 13:02:36 +0000 Russell King (Oracle) wrote: > On Mon, Jan 09, 2023 at 12:48:37PM +0100, Wolfram Sang wrote: > > > 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? 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.