linux-kernel - Re: [PATCH] i2c: muxes: pca954x: Allow sharing reset GPIO

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]

Date: Thu, 6 Jun 2024 16:58:39 -0500
From: Eddie James <eajames@...ux.ibm.com>
To: Chris Packham <chris.packham@...iedtelesis.co.nz>, peda@...ntia.se,
        p.zabel@...gutronix.de, krzysztof.kozlowski@...aro.org
Cc: linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] i2c: muxes: pca954x: Allow sharing reset GPIO


On 3/10/24 23:14, Chris Packham wrote:
> Some hardware designs with multiple PCA954x devices use a reset GPIO
> connected to all the muxes. Support this configuration by making use of
> the reset controller framework which can deal with the shared reset
> GPIOs. Fall back to the old GPIO descriptor method if the reset
> controller framework is not enabled.


Hello Chris, Krzysztof,


This change makes it so that the reset subsystem reset doesn't behave in 
the same way as the fallback gpio reset. The gpio, as part of acquiring 
it, gets set high, and then set low in the mux driver. So, the device 
reset is toggled. In the case of the reset subsystem option, the reset 
is only de-asserted (so the device is taken out of reset).


I'm interested in preserving the previous behavior but with the shared 
reset line. This can't be done just by doing "assert" first because the 
shared reset subsystem doesn't allow that. So the reset-gpio driver 
would have to implement the reset operation - no problem. However, how 
to specify the wait time for the reset-gpio driver here? Something like 
the simple reset driver maybe? Or a function call from the reset 
consumer driver to specify the wait time for that reset?


Thanks,

Eddie


>
> Signed-off-by: Chris Packham <chris.packham@...iedtelesis.co.nz>
> ---
>
> Notes:
>      This patch goes on top of Krzysztof's series adding the GPIO based reset
>      controller[1] which will be in linux-6.9. With this I'm able to
>      correctly describe my hardware platform in the DTS and have the resets
>      appropriately controlled.
>      
>      [1] - https://lore.kernel.org/all/20240129115216.96479-1-krzysztof.kozlowski@linaro.org/
>
>   drivers/i2c/muxes/i2c-mux-pca954x.c | 46 ++++++++++++++++++++++++-----
>   1 file changed, 38 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c b/drivers/i2c/muxes/i2c-mux-pca954x.c
> index f5dfc33b97c0..c3f4ff08ac38 100644
> --- a/drivers/i2c/muxes/i2c-mux-pca954x.c
> +++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
> @@ -49,6 +49,7 @@
>   #include <linux/pm.h>
>   #include <linux/property.h>
>   #include <linux/regulator/consumer.h>
> +#include <linux/reset.h>
>   #include <linux/slab.h>
>   #include <linux/spinlock.h>
>   #include <dt-bindings/mux/mux.h>
> @@ -116,6 +117,9 @@ struct pca954x {
>   	unsigned int irq_mask;
>   	raw_spinlock_t lock;
>   	struct regulator *supply;
> +
> +	struct gpio_desc *reset_gpio;
> +	struct reset_control *reset_cont;
>   };
>   
>   /* Provide specs for the MAX735x, PCA954x and PCA984x types we know about */
> @@ -518,6 +522,35 @@ static int pca954x_init(struct i2c_client *client, struct pca954x *data)
>   	return ret;
>   }
>   
> +static int pca954x_get_reset(struct device *dev, struct pca954x *data)
> +{
> +	data->reset_cont = devm_reset_control_get_optional_shared(dev, NULL);
> +	if (IS_ERR(data->reset_cont))
> +		return dev_err_probe(dev, PTR_ERR(data->reset_cont),
> +				     "Failed to get reset\n");
> +	else if (data->reset_cont)
> +		return 0;
> +
> +	/*
> +	 * fallback to legacy reset-gpios
> +	 */
> +	data->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
> +	if (IS_ERR(data->reset_gpio)) {
> +		return dev_err_probe(dev, PTR_ERR(data->reset_gpio),
> +				     "Failed to get reset gpio");
> +	}
> +
> +	return 0;
> +}
> +
> +static void pca954x_reset_deassert(struct pca954x *data)
> +{
> +	if (data->reset_cont)
> +		reset_control_deassert(data->reset_cont);
> +	else
> +		gpiod_set_value_cansleep(data->reset_gpio, 0);
> +}
> +
>   /*
>    * I2C init/probing/exit functions
>    */
> @@ -526,7 +559,6 @@ static int pca954x_probe(struct i2c_client *client)
>   	const struct i2c_device_id *id = i2c_client_get_device_id(client);
>   	struct i2c_adapter *adap = client->adapter;
>   	struct device *dev = &client->dev;
> -	struct gpio_desc *gpio;
>   	struct i2c_mux_core *muxc;
>   	struct pca954x *data;
>   	int num;
> @@ -554,15 +586,13 @@ static int pca954x_probe(struct i2c_client *client)
>   		return dev_err_probe(dev, ret,
>   				     "Failed to enable vdd supply\n");
>   
> -	/* Reset the mux if a reset GPIO is specified. */
> -	gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
> -	if (IS_ERR(gpio)) {
> -		ret = PTR_ERR(gpio);
> +	ret = pca954x_get_reset(dev, data);
> +	if (ret)
>   		goto fail_cleanup;
> -	}
> -	if (gpio) {
> +
> +	if (data->reset_cont || data->reset_gpio) {
>   		udelay(1);
> -		gpiod_set_value_cansleep(gpio, 0);
> +		pca954x_reset_deassert(data);
>   		/* Give the chip some time to recover. */
>   		udelay(1);
>   	}