Re: [PATCH 3/7] i2c: muxes: add support for mule i2c multiplexer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Krzysztof,

On 29.04.24 08:33, Krzysztof Kozlowski wrote:
[You don't often get email from krzysztof.kozlowski@xxxxxxxxxx. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

On 26/04/2024 18:49, Farouk Bouabid wrote:
Mule is an mcu that emulates a set of i2c devices which are reacheable
through an i2c-mux.

The emulated devices share a single i2c address with the mux itself where
the requested register is what determines which logic is executed (mux or
device):

1- The devices on the mux can be selected (mux function) by writing the
appropriate device number to an i2c config register (0xff) that is not
used by any device logic.

2- Any access to a register other than the config register will be
handled by the previously selected device.

Signed-off-by: Farouk Bouabid <farouk.bouabid@xxxxxxxxxxxxxxxxxxxxx>
---
  drivers/i2c/muxes/Kconfig        |  11 +++
  drivers/i2c/muxes/Makefile       |   1 +
  drivers/i2c/muxes/i2c-mux-mule.c | 157 +++++++++++++++++++++++++++++++++++++++
  3 files changed, 169 insertions(+)

diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index db1b9057612a..593a20a6ac51 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@ -119,4 +119,15 @@ config I2C_MUX_MLXCPLD
         This driver can also be built as a module.  If so, the module
         will be called i2c-mux-mlxcpld.

+config I2C_MUX_MULE
+     tristate "Mule I2C device multiplexer"
+     depends on OF
+     help
+       If you say yes to this option, support will be included for a
+       Mule I2C device multiplexer. This driver provides access to
+       I2C devices connected on the Mule I2C mux.
Describe what is Mule. Here and in bindings documentation.


Is the description in bindings documentation good enough to be copied here ? If not, any suggestions?


[snip]


+     if (!muxc)
+             return -ENOMEM;
+
+     muxc->share_addr_with_children = 1;
+     priv = i2c_mux_priv(muxc);
+
+     priv->regmap = devm_regmap_init_i2c(client, &mule_regmap_config);
+     if (IS_ERR(priv->regmap))
+             return dev_err_probe(&client->dev, PTR_ERR(priv->regmap),
+                                                      "Failed to allocate i2c register map\n");
+
+     i2c_set_clientdata(client, muxc);
+
+     /*
+      * Mux 0 is guaranteed to exist on all old and new mule fw.
+      * mule fw without mux support will accept write ops to the
+      * config register, but readback returns 0xff (register not updated).
+      */
+     ret = mux_select(muxc, 0);
+     if (ret)
+             return ret;
+
+     ret = regmap_read(priv->regmap, MUX_CONFIG_REG, &readback);
+     if (ret)
+             return ret;
+
+     old_fw = (readback == 0);
+
+     ret = devm_add_action_or_reset(&client->dev, mux_remove, muxc);
This is really odd. Why do you call remove callback as devm action?

I have serious doubts this was really tested.


This was tested in both scenarios where the probe fails and while removing the driver. The remove function is added as devm action to the unwinding path, which will basically be called when removing the driver OR when the probe fails after this call.

https://elixir.bootlin.com/linux/latest/source/drivers/base/devres.c#L734


[snip]


Anyway, all this looks like i2c-mux-reg. Please provide rationale in
commit msg WHY you need one more driver.


We are basically using an i2c device (mux) and an i2c register to handle the devices behind the mux which is not what the "i2c-mux-reg" offers, where the mux is a platform device and the register used is part of the io-memory.

Also to check that backward compatibility is valid on older Mule versions, we perform some tests in the probe function that are specific to Mule.

Did I miss something?


Best regards

Farouk





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux