[v3,0/9] introduce fwnode in the I2C subsystem

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

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.