Message ID | 20240112163608.528453-6-krzysztof.kozlowski@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-24867-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:693c:2614:b0:101:6a76:bbe3 with SMTP id mm20csp295146dyc; Fri, 12 Jan 2024 08:38:31 -0800 (PST) X-Google-Smtp-Source: AGHT+IEu6FjhYqTdS7ZQaygsL4LZqMj0jnuJx65iAUpwolNdj3ars3iNE5haDZwN3rU1RTmtYZFj X-Received: by 2002:a05:6871:6289:b0:206:32c:e984 with SMTP id re9-20020a056871628900b00206032ce984mr1750326oab.9.1705077511151; Fri, 12 Jan 2024 08:38:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1705077511; cv=none; d=google.com; s=arc-20160816; b=jg27lfrH8J/K/PJLWGuuOUuQI7bb1IeWZDjqw103FpQn63DdHPWq98sK/IxsWvgTEI UDcGX4yhRCXn4OnmyF3KjjtnuyQGEL2CBMXlcxq+uqFqc9iGffYztL7pa6JsvlxulCcv RH68xUR4XHAkWmyl0TOQ+CMmT52y09v/YP2YzNCjUu8U8iGTfw8fxyLF6gmxjUlZ2SEr qnUmdIBDXfBGGk1NcRLa+0aiCdxA8ed0CSXGob7WFZg8Cwxk3QjSCK/bU7HspEPfuTak dXi2RR8aX4sXIDOKCrGchN3t8y793csmEjvZDht8JwTrzmPzm7K2Q9zoTPnZKhj5Iz+2 MdJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=+tAwGTFBvrjSR+D7qo0JkBwlnmAMUSdISzHDQJb3VJ8=; fh=1uhmN9+TkwIK7+W3IRxzy43JZJH7koq07cxoiS8OF+E=; b=EU5a4rgL6eDEK5kHCJW6Xk8GkMwNw1hJnqIfCE0H/Q+mHxSZvN0ktfSTC7V9eDgyLP XSxVnTUJutKEbkMyeoCe1JVKLPyefU2zrB7h5BxSM50iqDdUAADiytAIyneM9jBz5kVc Ftx6X/G2BIluaa3eRsFl8tddVm6ht8sND570DNDTmaUC1B6Tl20eQUlJ2ADS7Kq0as77 aUZXy6hN3P9Z9oO8Hludf+mYlfstuHZKwjV2mx4uG+rwLHo+QICQ3ougyKQ/Da3k66G4 Ps5r2jVTW2EzJcUH5nUF/YuXm9Kl0jee2thq2eBoV87WW3q3Cxi6Wfl+iEwG4Yv7qbKr qLBA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=SJAM6Zhq; spf=pass (google.com: domain of linux-kernel+bounces-24867-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-24867-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id 75-20020a63014e000000b005c600ffa335si3568377pgb.217.2024.01.12.08.38.30 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Jan 2024 08:38:31 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-24867-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=SJAM6Zhq; spf=pass (google.com: domain of linux-kernel+bounces-24867-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-24867-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id D69ECB229B6 for <ouuuleilei@gmail.com>; Fri, 12 Jan 2024 16:38:22 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 047637FBB9; Fri, 12 Jan 2024 16:36:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="SJAM6Zhq" Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6FFEA7E76A for <linux-kernel@vger.kernel.org>; Fri, 12 Jan 2024 16:36:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-40e490c2115so32730485e9.0 for <linux-kernel@vger.kernel.org>; Fri, 12 Jan 2024 08:36:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1705077390; x=1705682190; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=+tAwGTFBvrjSR+D7qo0JkBwlnmAMUSdISzHDQJb3VJ8=; b=SJAM6ZhqX5sQrxdeKesiLB2E7w0LvCgHKx799uY5OLzvjo4NxuzDGrBLhPq9BPHVdI Z++P/Rah05n4B9lWwAR2+RA1/j9dKLQ1Yu74L6X+sx6eighuBIgINITPXCwGUqZycIAv b7NUMuNA+hnOTUNoJz+xNwvfechsPnBh3M4vdYxOAF5q8mzeT0VYXxOsy+fjApbmvzy1 4TW3mGl7GGzcrqpfQM1hWEKqP8OjOYKPUmhKevd/XPabFaYHDDOnc/GCo9rvvvddM176 CKWfvGzBtaAk9txmeG+//CrjiT96qxRt1mZv78RjSMdfNlToQXQLHtt5cBc89f4W/s6a ZFzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705077390; x=1705682190; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+tAwGTFBvrjSR+D7qo0JkBwlnmAMUSdISzHDQJb3VJ8=; b=PbKU5S73D7ZsIxy0hWiUWv1ESVd9wFNgFzMyUnjrIsuwpIzgVLIDdzDhK9DdVPfngi CO/vmYWjsHv55sN8rG26sXKwc2Ddf7EpyzkpGhNwKmQB1IevX53TYDMNSHIFXSt/k3oV n54646MAdNT5DL07x9a6zZCHE5VnlvDn4Y2zpyljjZHkIVi2PljSS/kl/FjpazM9EKSh xkSm6RZtBFRH+rw1RC0Ex8O22EiQhM2wh2087RoLj0m8l39wsLpbFnNvQBHTG6rb9WMV sCaqCLKpe05F9aD6g1Ir5bHMOIzjZp6VpJKdXjqI8kt/K2V8CJdDO1ZzD5dM0T4haa9/ eC9g== X-Gm-Message-State: AOJu0YxfcsdTY38QmNYZRVQQ4ZGGe7iUbxNPu2OsTksD9ytICKX2Pqz3 GgDXPmnmbIuQeFxXjTdhgWG/pJ842CW07w== X-Received: by 2002:a05:600c:1c25:b0:40e:4613:daae with SMTP id j37-20020a05600c1c2500b0040e4613daaemr1033231wms.30.1705077389852; Fri, 12 Jan 2024 08:36:29 -0800 (PST) Received: from krzk-bin.. ([178.197.223.112]) by smtp.gmail.com with ESMTPSA id bd16-20020a05600c1f1000b0040e5a93ae53sm6573195wmb.22.2024.01.12.08.36.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Jan 2024 08:36:29 -0800 (PST) From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> To: Bjorn Andersson <andersson@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, Srinivas Kandagatla <srinivas.kandagatla@linaro.org>, Banajit Goswami <bgoswami@quicinc.com>, Liam Girdwood <lgirdwood@gmail.com>, Mark Brown <broonie@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Peter Rosin <peda@axentia.se>, Philipp Zabel <p.zabel@pengutronix.de>, Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>, linux-arm-msm@vger.kernel.org, alsa-devel@alsa-project.org, linux-sound@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-i2c@vger.kernel.org Cc: Chris Packham <chris.packham@alliedtelesis.co.nz>, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>, Bartosz Golaszewski <brgl@bgdev.pl>, Sean Anderson <sean.anderson@seco.com> Subject: [PATCH v3 5/5] i2c: muxes: pca954x: Allow sharing reset GPIO Date: Fri, 12 Jan 2024 17:36:08 +0100 Message-Id: <20240112163608.528453-6-krzysztof.kozlowski@linaro.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240112163608.528453-1-krzysztof.kozlowski@linaro.org> References: <20240112163608.528453-1-krzysztof.kozlowski@linaro.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1787903356043679990 X-GMAIL-MSGID: 1787903356043679990 |
Series |
reset: gpio: ASoC: shared GPIO resets
|
|
Commit Message
Krzysztof Kozlowski
Jan. 12, 2024, 4:36 p.m. UTC
From: Chris Packham <chris.packham@alliedtelesis.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@alliedtelesis.co.nz> Acked-by: Peter Rosin <peda@axentia.se> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240108041913.7078-1-chris.packham@alliedtelesis.co.nz Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> --- If previous patches are fine, then this commit is independent and could be taken via I2C. Cc: Chris Packham <chris.packham@alliedtelesis.co.nz> Cc: Bartosz Golaszewski <brgl@bgdev.pl> Cc: Sean Anderson <sean.anderson@seco.com> --- drivers/i2c/muxes/i2c-mux-pca954x.c | 46 ++++++++++++++++++++++++----- 1 file changed, 38 insertions(+), 8 deletions(-)
Comments
On Fr, 2024-01-12 at 17:36 +0100, Krzysztof Kozlowski wrote: > From: Chris Packham <chris.packham@alliedtelesis.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@alliedtelesis.co.nz> > Acked-by: Peter Rosin <peda@axentia.se> > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > Link: https://lore.kernel.org/r/20240108041913.7078-1-chris.packham@alliedtelesis.co.nz > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > > --- > > If previous patches are fine, then this commit is independent and could > be taken via I2C. > > Cc: Chris Packham <chris.packham@alliedtelesis.co.nz> > Cc: Bartosz Golaszewski <brgl@bgdev.pl> > Cc: Sean Anderson <sean.anderson@seco.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. > + 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
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@alliedtelesis.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@alliedtelesis.co.nz> >> Acked-by: Peter Rosin <peda@axentia.se> >> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.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@linaro.org> >> >> --- >> >> If previous patches are fine, then this commit is independent and could >> be taken via I2C. >> >> Cc: Chris Packham <chris.packham@alliedtelesis.co.nz> >> Cc: Bartosz Golaszewski <brgl@bgdev.pl> >> Cc: Sean Anderson <sean.anderson@seco.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
On Di, 2024-01-16 at 19:58 +0000, Chris Packham wrote: > 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@alliedtelesis.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@alliedtelesis.co.nz> > > > Acked-by: Peter Rosin <peda@axentia.se> > > > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.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@linaro.org> > > > > > > --- > > > > > > If previous patches are fine, then this commit is independent and could > > > be taken via I2C. > > > > > > Cc: Chris Packham <chris.packham@alliedtelesis.co.nz> > > > Cc: Bartosz Golaszewski <brgl@bgdev.pl> > > > Cc: Sean Anderson <sean.anderson@seco.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 [...] > [...] it looks like we'd get -EPROBE_DEFER. I could change to check > for that or just remove the GPIO fallback entirely. Any preference? I hadn't considered this. If CONFIG_RESET_GPIO=n, devm_reset_control_get_optional_shared() probably shouldn't return -EPROBE_DEFER. If we change that, the GPIO fallback here can stay as is. The alternative would be to drop the fallback and select RESET_GPIO. Using -EPROBE_DEFER for fallback detection is no good, as there could be a valid probe deferral if reset-gpio is compiled as a module that will be loaded later. regards Philipp
On 18/01/24 00:16, Philipp Zabel wrote: > On Di, 2024-01-16 at 19:58 +0000, Chris Packham wrote: >> 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@alliedtelesis.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@alliedtelesis.co.nz> >>>> Acked-by: Peter Rosin <peda@axentia.se> >>>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> >>>> Link: https://scanmail.trustwave.com/?c=20988&d=_ban5W3xRzKSimJ9ijTJ74p10otfq8ZONfjVnBr6Fw&u=https%3a%2f%2flore%2ekernel%2eorg%2fr%2f20240108041913%2e7078-1-chris%2epackham%40alliedtelesis%2eco%2enz >>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> >>>> >>>> --- >>>> >>>> If previous patches are fine, then this commit is independent and could >>>> be taken via I2C. >>>> >>>> Cc: Chris Packham <chris.packham@alliedtelesis.co.nz> >>>> Cc: Bartosz Golaszewski <brgl@bgdev.pl> >>>> Cc: Sean Anderson <sean.anderson@seco.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 [...] >> [...] it looks like we'd get -EPROBE_DEFER. I could change to check >> for that or just remove the GPIO fallback entirely. Any preference? > I hadn't considered this. > > If CONFIG_RESET_GPIO=n, devm_reset_control_get_optional_shared() > probably shouldn't return -EPROBE_DEFER. If we change that, the GPIO > fallback here can stay as is. > > The alternative would be to drop the fallback and select RESET_GPIO. > Using -EPROBE_DEFER for fallback detection is no good, as there could > be a valid probe deferral if reset-gpio is compiled as a module that > will be loaded later. I did consider adding `select RESET_GPIO` (or maybe just `imply RESET_GPIO`) initially but decided on the fallback as a way of avoiding surprises for existing users. I'll see if anyone else has a different suggestion but assuming nothing else changes I'll work with Krzystof to get an updated patch for this series.
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 + */ + 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 */ @@ -485,7 +518,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; @@ -513,15 +545,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); }