| Message ID | 20240311041412.3858710-1-chris.packham@alliedtelesis.co.nz |
|---|---|
| State | Superseded |
| Headers | show |
| Series | i2c: muxes: pca954x: Allow sharing reset GPIO | expand |
On 11/03/2024 05: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. > > Signed-off-by: Chris Packham <chris.packham@alliedtelesis.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/ > Where is the changelog? It was v3 or v4 already? Where are the tags? It looks like you received a tag and forgot to add it. If you do not know the process, here is a short explanation: Please add Acked-by/Reviewed-by/Tested-by tags when posting new versions, under or above your Signed-off-by tag. Tag is "received", when provided in a message replied to you on the mailing list. Tools like b4 can help here. However, there's no need to repost patches *only* to add the tags. The upstream maintainer will do that for tags received on the version they apply. https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L577 If a tag was not added on purpose, please state why and what changed. Best regards, Krzysztof
On 11/03/24 19:25, Krzysztof Kozlowski wrote: > On 11/03/2024 05: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. >> >> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.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/ >> > Where is the changelog? It was v3 or v4 already? Where are the tags? Since this was spun off the original series I figured it would be best to treat it as v1 of a new series. It's unchanged since https://lore.kernel.org/lkml/20240112163608.528453-6-krzysztof.kozlowski@linaro.org/ so technically this is '[PATCH resend v3]'. I did rebase it on top of linux-next just to make sure it still worked. > It looks like you received a tag and forgot to add it. > > If you do not know the process, here is a short explanation: > Please add Acked-by/Reviewed-by/Tested-by tags when posting new > versions, under or above your Signed-off-by tag. Tag is "received", when > provided in a message replied to you on the mailing list. Tools like b4 > can help here. However, there's no need to repost patches *only* to add > the tags. The upstream maintainer will do that for tags received on the > version they apply. > > https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L577 > > If a tag was not added on purpose, please state why and what changed. Oops my bad. I think because by the time v3 rolled round it was part of your series I never added the Ack from Peter or your R-by to my local commit which is what I sent out. I've added it now if I send a v4 (or is it v2 of this?) I'll include the tags.
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); }
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> --- 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(-)