| Message ID | 20220325113148.588163-1-clement.leger@bootlin.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | introduce fwnode in the I2C subsystem | expand |
O > This series is a subset of the one that was first submitted as a larger > series to add swnode support [1]. In this one, it will be focused on > fwnode support only since it seems to have reach a consensus that > adding fwnode to subsystems makes sense. From a high level view, I like this series. Though, it will need Peter's ack on the I2C mux patches as he is the I2C mux maintainer. Still, I wonder about the way to upstream the series. Feels like the first 5 patches should not go via I2C but seperately?
2022-05-14 at 16:47, Wolfram Sang wrote: > O >> This series is a subset of the one that was first submitted as a larger >> series to add swnode support [1]. In this one, it will be focused on >> fwnode support only since it seems to have reach a consensus that >> adding fwnode to subsystems makes sense. > > From a high level view, I like this series. Though, it will need Peter's > ack on the I2C mux patches as he is the I2C mux maintainer. Still, I > wonder about the way to upstream the series. Feels like the first 5 > patches should not go via I2C but seperately? Hi Wolfram, I also think it looks basically sane. However, there are a couple of comments plus promises to adjust accordingly. I guess I filed it under "wait for the next iteration"... Cheers, Peter
Le Sun, 15 May 2022 23:34:16 +0200, Peter Rosin <peda@axentia.se> a écrit : > 2022-05-14 at 16:47, Wolfram Sang wrote: > > O > >> This series is a subset of the one that was first submitted as a larger > >> series to add swnode support [1]. In this one, it will be focused on > >> fwnode support only since it seems to have reach a consensus that > >> adding fwnode to subsystems makes sense. > > > > From a high level view, I like this series. Though, it will need Peter's > > ack on the I2C mux patches as he is the I2C mux maintainer. Still, I > > wonder about the way to upstream the series. Feels like the first 5 > > patches should not go via I2C but seperately? > > Hi Wolfram, > > I also think it looks basically sane. However, there are a couple of > comments plus promises to adjust accordingly. I guess I filed it under > "wait for the next iteration"... > > Cheers, > Peter Hi Wolfram & Peter, While doing the same conversion on the reset subsystem, Rob Herring stepped in and mention the fact that this could be done using device-tree overlay (even on system with ACPI) . The result was that a new serie [1] which add support to create the PCI devices of_node if not existing, and then allow drivers to applies an overlay which describe the tree of devices as a child of a specific PCI device of_node. There are a lot of advantages to this approach (small patchset working for all susbystems, easier to use, description is using already existing device-tree). There are still some concerns about the viability of dynamic overlay but this might be settled soon. Regards, [1] https://lore.kernel.org/all/20220509141634.16158c38@xps-bootlin/T/
> While doing the same conversion on the reset subsystem, Rob Herring > stepped in and mention the fact that this could be done using > device-tree overlay (even on system with ACPI) . Thanks for the heads up, I'll drop this series then.
In order to allow the I2C subsystem to be usable with fwnode, add some functions to retrieve an i2c_adapter from a fwnode and use these functions in both i2c mux and sfp. ACPI and device-tree are handled to allow these modifications to work with both descriptions. I2C mux support has also been modified to support fwnode based descriptions. This series is a subset of the one that was first submitted as a larger series to add swnode support [1]. In this one, it will be focused on fwnode support only since it seems to have reach a consensus that adding fwnode to subsystems makes sense. [1] https://lore.kernel.org/netdev/YhPSkz8+BIcdb72R@smile.fi.intel.com/T/ --------------- Changes in V3: - Add index parameter to property_read_string_array() - Implement support for devbice-tree and software nodes - Restrict index support for ACPI to 0 - Add unittests for of_property_read_string_array_index() - Add unittests for fwnode_property_read_string_index() Changes in V2: - Remove sfp modifications - Add property_read_string_index fwnode_operation callback - Implement .property_read_string_index for of and swnode - Renamed np variable to fwnode Clément Léger (9): of: add of_property_read_string_array_index() of: unittests: add tests for of_property_read_string_array_index() device property: add index argument to property_read_string_array() callback device property: add fwnode_property_read_string_index() device property: add tests for fwnode_property_read_string_index() i2c: fwnode: add fwnode_find_i2c_adapter_by_node() i2c: of: use fwnode_get_i2c_adapter_by_node() i2c: mux: pinctrl: remove CONFIG_OF dependency and use fwnode API i2c: mux: add support for fwnode drivers/acpi/property.c | 5 ++- drivers/base/property.c | 37 ++++++++++++++++++-- drivers/base/swnode.c | 21 ++++++++---- drivers/base/test/property-entry-test.c | 18 ++++++++++ drivers/i2c/Makefile | 1 + drivers/i2c/i2c-core-fwnode.c | 45 +++++++++++++++++++++++++ drivers/i2c/i2c-core-of.c | 30 ----------------- drivers/i2c/i2c-mux.c | 39 ++++++++++----------- drivers/i2c/muxes/Kconfig | 1 - drivers/i2c/muxes/i2c-mux-pinctrl.c | 23 +++++++------ drivers/of/property.c | 5 +-- drivers/of/unittest.c | 20 +++++++++++ include/linux/fwnode.h | 7 ++-- include/linux/i2c.h | 8 ++++- include/linux/of.h | 22 ++++++++++++ include/linux/property.h | 3 ++ 16 files changed, 207 insertions(+), 78 deletions(-) create mode 100644 drivers/i2c/i2c-core-fwnode.c