linux-kernel - Re: [PATCH v7 2/8] i2c: muxes: add support for tsd,mule-i2c multiplexer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5d2ab1fe-bcfd-6760-85d0-145787ea5cc6@axentia.se>
Date: Tue, 3 Sep 2024 17:44:27 +0200
From: Peter Rosin <peda@...ntia.se>
To: Andi Shyti <andi.shyti@...nel.org>,
 Farouk Bouabid <farouk.bouabid@...rry.de>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Quentin Schulz
 <quentin.schulz@...rry.de>, Jean Delvare <jdelvare@...e.com>,
 Guenter Roeck <linux@...ck-us.net>, Heiko Stuebner <heiko@...ech.de>,
 linux-i2c@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-hwmon@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org,
 Wolfram Sang <wsa+renesas@...g-engineering.com>
Subject: Re: [PATCH v7 2/8] i2c: muxes: add support for tsd,mule-i2c
 multiplexer

Hi!

2024-09-03 at 17:13, Andi Shyti wrote:
> Hi Farouk,
> 
> Before jumping into the review, who is going to take this and the
> previous patch?
> 
> Peter shall I take it?

Please do. Thanks, and as always, sorry for my low bandwidth...

> 
> Now to the review :-)
> 
> On Mon, Sep 02, 2024 at 06:38:15PM GMT, Farouk Bouabid wrote:
>> Theobroma Systems Mule is an MCU that emulates a set of I2C devices,
>> among which an amc6821 and devices that are reachable through an I2C-mux.
>> The devices on the mux can be selected by writing the appropriate device
>> number to an I2C config register (amc6821 reg 0xff).
>>
>> This driver is expected to be probed as a platform device with amc6821
>> as its parent i2c device.
>>
>> Add support for the mule-i2c-mux platform driver. The amc6821 driver
> 
> Along the driver I expressed some concern about the prefixes.
> 
> You should avoid prefixes such as mux_* or MUX_* because they
> don't belong to your driver. You should always use your driver's
> name:
> 
>  1. mule_*
>  2. mule_mux_*
>  3. mule_i2c_mux_*
> 
> You have used the 3rd, I'd rather prefer the 1st. Because when
> you are in i2c/muxex/ it's implied that you are an i2c mux
> device. But it's a matter of personal taste.
> 
> Other than this, there is still, one major error down below.
> 
>> support for the mux will be added in a later commit.
>>
>> Reviewed-by: Wolfram Sang <wsa+renesas@...g-engineering.com>
>> Signed-off-by: Farouk Bouabid <farouk.bouabid@...rry.de>
> 
> ...
> 
>> +#include <linux/i2c-mux.h>
>> +#include <linux/i2c.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/property.h>
>> +#include <linux/regmap.h>
>> +
>> +#define MUX_CONFIG_REG  0xff
>> +#define MUX_DEFAULT_DEV 0x0
> 
> Please define these as MULE_I2C_MUX_*
> 
>> +
>> +struct mule_i2c_reg_mux {
>> +	struct regmap *regmap;
>> +};
>> +
>> +static int mux_select(struct i2c_mux_core *muxc, u32 dev)
>> +{
>> +	struct mule_i2c_reg_mux *mux = muxc->priv;
>> +
>> +	return regmap_write(mux->regmap, MUX_CONFIG_REG, dev);
>> +}
>> +
>> +static int mux_deselect(struct i2c_mux_core *muxc, u32 dev)
>> +{
>> +	return mux_select(muxc, MUX_DEFAULT_DEV);
>> +}
>> +
>> +static void mux_remove(void *data)
> 
> Please call these mule_i2c_mux_*(), the mux_ prefix doesn't
> belong to this driver.
> 
>> +{
>> +	struct i2c_mux_core *muxc = data;
>> +
>> +	i2c_mux_del_adapters(muxc);
>> +
>> +	mux_deselect(muxc, MUX_DEFAULT_DEV);
>> +}
> 
> ...
> 
>> +	/* Create device adapters */
>> +	for_each_child_of_node(mux_dev->of_node, dev) {
>> +		u32 reg;
>> +
>> +		ret = of_property_read_u32(dev, "reg", &reg);
>> +		if (ret)
>> +			return dev_err_probe(mux_dev, ret,
>> +					     "No reg property found for %s\n",
>> +					     of_node_full_name(dev));
>> +
>> +		if (old_fw && reg != 0) {
>> +			dev_warn(mux_dev,
>> +				 "Mux is not supported, please update Mule FW\n");
>> +			continue;
>> +		}
>> +
>> +		ret = mux_select(muxc, reg);
>> +		if (ret) {
>> +			dev_warn(mux_dev,
>> +				 "Device %d not supported, please update Mule FW\n", reg);
>> +			continue;
>> +		}
>> +
>> +		ret = i2c_mux_add_adapter(muxc, 0, reg);
>> +		if (ret)
>> +			return ret;
> 
> do we need to delete the adapters we added in previous cycles?

Yes, nicely spotted. A call to i2c_mux_del_adapters(muxc) is needed
on failure if any i2c_mux_add_adapter() call has succeeded (but it's
safe to call it on any i2c_mux_add_adapter() failure).

Cheers,
Peter

> 
>> +	}
>> +
>> +	mux_deselect(muxc, MUX_DEFAULT_DEV);
>> +
>> +	return 0;
>> +}
>> +
>> +static const struct of_device_id mule_i2c_mux_of_match[] = {
>> +	{.compatible = "tsd,mule-i2c-mux",},
> 
> if you are going to resend, can you leave one space after the
> '{' and before the '}'
> 
>> +	{},
>> +};
>> +MODULE_DEVICE_TABLE(of, mule_i2c_mux_of_match);
>> +
>> +static struct platform_driver mule_i2c_mux_driver = {
>> +	.driver		= {
> 
> I don't see the need for this '\t' here, the alignment is too
> far. It just looks bad. Your choice, though.
> 
> Thanks,
> Andi
> 
>> +		.name	= "mule-i2c-mux",
>> +		.of_match_table = mule_i2c_mux_of_match,
>> +	},
>> +	.probe		= mule_i2c_mux_probe,
>> +};
>> +
>> +module_platform_driver(mule_i2c_mux_driver);
>> +
>> +MODULE_AUTHOR("Farouk Bouabid <farouk.bouabid@...rry.de>");
>> +MODULE_DESCRIPTION("I2C mux driver for Theobroma Systems Mule");
>> +MODULE_LICENSE("GPL");
>>
>> -- 
>> 2.34.1
>>