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

[Farouk Bouabid]

Hi Krzysztof,

On 29.04.24 08:33, Krzysztof Kozlowski wrote:
> [You don't often get email from krzysztof.kozlowski at linaro.org. 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 at theobroma-systems.com>
>> ---
>>   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