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: Tue, 16 Jan 2024 19:58:12 +0000
From: Chris Packham <Chris.Packham@...iedtelesis.co.nz>
To: Philipp Zabel <p.zabel@...gutronix.de>, Krzysztof Kozlowski
	<krzysztof.kozlowski@...aro.org>, Bjorn Andersson <andersson@...nel.org>,
	Konrad Dybcio <konrad.dybcio@...aro.org>, Srinivas Kandagatla
	<srinivas.kandagatla@...aro.org>, Banajit Goswami <bgoswami@...cinc.com>,
	Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>, "Rob
 Herring" <robh+dt@...nel.org>, Krzysztof Kozlowski
	<krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>,
	Peter Rosin <peda@...ntia.se>, Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai
	<tiwai@...e.com>, "linux-arm-msm@...r.kernel.org"
	<linux-arm-msm@...r.kernel.org>, "alsa-devel@...a-project.org"
	<alsa-devel@...a-project.org>, "linux-sound@...r.kernel.org"
	<linux-sound@...r.kernel.org>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-i2c@...r.kernel.org"
	<linux-i2c@...r.kernel.org>
CC: Bartosz Golaszewski <brgl@...ev.pl>, Sean Anderson
	<sean.anderson@...o.com>
Subject: Re: [PATCH v3 5/5] i2c: muxes: pca954x: Allow sharing reset GPIO


On 17/01/24 04:18, Philipp Zabel wrote:
> On Fr, 2024-01-12 at 17:36 +0100, Krzysztof Kozlowski wrote:
>> From: Chris Packham <chris.packham@...iedtelesis.co.nz>
>>
>> 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.
>>
>> Signed-off-by: Chris Packham <chris.packham@...iedtelesis.co.nz>
>> Acked-by: Peter Rosin <peda@...ntia.se>
>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
>> Link: https://scanmail.trustwave.com/?c=20988&d=8p6m5Tfi2yYJWYV9xYGcYnz7UYxB6WTGTPkmGu7b8A&u=https%3a%2f%2flore%2ekernel%2eorg%2fr%2f20240108041913%2e7078-1-chris%2epackham%40alliedtelesis%2eco%2enz
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
>>
>> ---
>>
>> If previous patches are fine, then this commit is independent and could
>> be taken via I2C.
>>
>> Cc: Chris Packham <chris.packham@...iedtelesis.co.nz>
>> Cc: Bartosz Golaszewski <brgl@...ev.pl>
>> Cc: Sean Anderson <sean.anderson@...o.com>
>> ---
>>   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 2219062104fb..1702e8d49b91 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>
>> @@ -102,6 +103,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 */
>> @@ -477,6 +481,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
>> +	 */
> devm_reset_control_get_optional_shared() won't return NULL if the
> "reset-gpios" property is found in the device tree, so the GPIO
> fallback is dead code.

Hmm, I was attempting to handle the case where CONFIG_RESET_GPIO wasn't 
set or the reset core wasn't enabled. It doesn't appear that the latter 
is even possible so no need to worry about that. For the former it looks 
like we'd get -EPROBE_DEFER. I could change to check for that or just 
remove the GPIO fallback entirely. Any preference?

>
>> +	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;
>> +}
>> +
> regards
> Philipp

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ