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
