From: Jonathan Cameron <jic23@kernel.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Josef Bacik" <josef@toxicpanda.com>,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
stable <stable@kernel.org>,
"David Lechner" <dlechner@baylibre.com>,
"Nuno Sá" <nuno.sa@analog.com>,
"Andy Shevchenko" <andy@kernel.org>,
"Uwe Kleine-König (The Capable Hub)"
<u.kleine-koenig@baylibre.com>, "Siratul Islam" <email@sirat.me>,
"Vlad Dogaru" <ddvlad@gmail.com>,
"Mika Westerberg" <mika.westerberg@linux.intel.com>
Subject: Re: [PATCH 13/15] iio: proximity: sx9500: hand on probe deferral of GPIOs
Date: Wed, 28 Oct 2026 02:09:05 +0000 [thread overview]
Message-ID: <20261028020905.7e0e86f0@jic23-hlaptop> (raw)
In-Reply-To: <20261027-llm-char-misc-iio-v1-13-0d818334f6c7@linuxfoundation.org>
On Tue, 27 Oct 2026 17:19:17 +0100
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> From: Josef Bacik <josef@toxicpanda.com>
>
> sx9500_gpio_probe() treats every failure of devm_gpiod_get() as "the
> line does not exist".
>
> If the GPIO controller has not been probed yet,
> the lookup fails with -EPROBE_DEFER, and the driver binds for good
> without the line:
>
> - without the "interrupt" GPIO client->irq stays 0, so no interrupt is
> requested and no trigger is registered: the device has no events and
> no data-ready trigger until it is unbound and bound again;
> - without the "reset" GPIO the chip is not reset in
> sx9500_init_device().
>
> Which of the two happens depends only on the order in which the drivers
> are probed. Return -EPROBE_DEFER so that the probe is repeated once the
> controller is there. All other errors are handled as before. The i2c
> core sets client->irq again at the start of every probe, so a deferral
> on the second line leaves nothing behind.
>
> A system that describes one of the lines but never gets a driver for its
> GPIO controller now keeps the sensor in the deferred list instead of
> binding it without the line.
That's all a bit long winded though accurate.
The original code is rather odd. If the intent is to actually have
these as optional gpios, why not use devm_gpiod_get_optional()
which documents that intent?
Anyhow, I suggest a bit more radical surgery given the driver
is fine without the irq and the code being fixes smells like it is
papering over ancient firmware. It definitely shouldn't run on
a modern system.
>
> Fixes: 45fd5f8e10d3 ("iio: sx9500: add GPIO reset pin")
> Fixes: e53111ad5dea ("iio: proximity: sx9500: Assign interrupt from GpioIo()")
> Cc: stable <stable@kernel.org>
> Cc: David Lechner <dlechner@baylibre.com>
> Cc: "Nuno Sá" <nuno.sa@analog.com>
> Cc: Andy Shevchenko <andy@kernel.org>
> Cc: Josef Bacik <josef@toxicpanda.com>
> Cc: "Uwe Kleine-König (The Capable Hub)" <u.kleine-koenig@baylibre.com>
> Cc: Siratul Islam <email@sirat.me>
> Cc: Vlad Dogaru <ddvlad@gmail.com>
> Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> drivers/iio/proximity/sx9500.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/iio/proximity/sx9500.c b/drivers/iio/proximity/sx9500.c
> index dadce9b44227..94cc577f4404 100644
> --- a/drivers/iio/proximity/sx9500.c
> +++ b/drivers/iio/proximity/sx9500.c
> @@ -853,15 +853,15 @@ static const struct acpi_gpio_mapping acpi_sx9500_gpios[] = {
> { }
> };
>
> -static void sx9500_gpio_probe(struct i2c_client *client,
> - struct sx9500_data *data)
> +static int sx9500_gpio_probe(struct i2c_client *client,
> + struct sx9500_data *data)
> {
> struct gpio_desc *gpiod_int;
> struct device *dev;
> int ret;
>
> if (!client)
> - return;
> + return 0;
>
> dev = &client->dev;
>
> @@ -871,6 +871,8 @@ static void sx9500_gpio_probe(struct i2c_client *client,
>
> if (client->irq <= 0) {
> gpiod_int = devm_gpiod_get(dev, "interrupt", GPIOD_IN);
> + if (PTR_ERR(gpiod_int) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> if (IS_ERR(gpiod_int))
> dev_err(dev, "gpio get irq failed\n");
This is 'novel'. I did some archaeology. Goes back almost 11 years
and at the time the driver only had ACPI and i2c_device_id. So
assuming we weren't talking board files I suppose this is papering over
a broken ACPI firmware.
Given the driver works fine without the interrupt (despite that print
implying it is an error).
Shall we just rip this out? The irq from any modern firmware will
be in client->irq anyway so this section doesn't run.
> else
> @@ -878,10 +880,14 @@ static void sx9500_gpio_probe(struct i2c_client *client,
> }
The next bit is valid, though with the above gone, I'd be tempted
to flatten this helper and just get the gpio inline.
>
> data->gpiod_rst = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
data->gpiod_rst = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
if (PTR_ERR(data->gpiod_rst))
return dev_err_probe(dev, "gpio get reset failed\n");
if (!data->gpiod_rst)
dev_warn(dev, "gpio reset not available\n:);
return 0;
> + if (PTR_ERR(data->gpiod_rst) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> if (IS_ERR(data->gpiod_rst)) {
> dev_warn(dev, "gpio get reset pin failed\n");
> data->gpiod_rst = NULL;
> }
> +
> + return 0;
> }
>
> static int sx9500_probe(struct i2c_client *client)
> @@ -911,7 +917,9 @@ static int sx9500_probe(struct i2c_client *client)
> indio_dev->modes = INDIO_DIRECT_MODE;
> i2c_set_clientdata(client, indio_dev);
>
> - sx9500_gpio_probe(client, data);
> + ret = sx9500_gpio_probe(client, data);
> + if (ret)
> + return ret;
>
> ret = sx9500_init_device(indio_dev);
> if (ret < 0)
>
next prev parent reply other threads:[~2026-10-28 2:09 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-27 16:19 [PATCH 00/15] IIO: a bunch of llm-found fixes Greg Kroah-Hartman
2026-10-27 16:19 ` [PATCH 01/15] iio: buffer: let the block keep its DMA fence Greg Kroah-Hartman
2026-10-28 9:30 ` Nuno Sá
2026-10-27 16:19 ` [PATCH 02/15] iio: trigger: fail the attach if no sub-IRQ is left Greg Kroah-Hartman
2026-10-28 9:38 ` Nuno Sá
2026-10-27 16:19 ` [PATCH 03/15] iio: accel: adxl367: don't stay in standby on -EINVAL Greg Kroah-Hartman
2026-10-28 10:01 ` Nuno Sá
2026-10-27 16:19 ` [PATCH 04/15] iio: accel: adxl380: " Greg Kroah-Hartman
2026-10-28 10:02 ` Nuno Sá
2026-10-27 16:19 ` [PATCH 05/15] iio: adc: check the result of ad_sd_init() Greg Kroah-Hartman
2026-10-28 9:40 ` Nuno Sá
2026-10-27 16:19 ` [PATCH 06/15] iio: adc: ad7923: add the AD7927 to the SPI ID table Greg Kroah-Hartman
2026-10-28 9:35 ` Nuno Sá
2026-10-27 16:19 ` [PATCH 07/15] iio: addac: ad74413r: fix the values of set_multiple Greg Kroah-Hartman
2026-10-28 9:38 ` Nuno Sá
2026-10-27 16:19 ` [PATCH 08/15] iio: light: apds9306: push events to the IIO device Greg Kroah-Hartman
2026-10-27 16:19 ` [PATCH 09/15] iio: light: tsl2591: don't divide by zero in the dark Greg Kroah-Hartman
2026-10-27 16:19 ` [PATCH 10/15] iio: light: tsl2591: don't divide by zero with low gain Greg Kroah-Hartman
2026-10-28 2:13 ` Jonathan Cameron
2026-10-28 4:16 ` Greg Kroah-Hartman
2026-10-27 16:19 ` [PATCH 11/15] iio: hid-sensors: fix a division by zero Greg Kroah-Hartman
2026-10-27 16:19 ` [PATCH 12/15] iio: imu: inv_mpu6050: don't disable the IRQ under lock Greg Kroah-Hartman
2026-10-27 16:19 ` [PATCH 13/15] iio: proximity: sx9500: hand on probe deferral of GPIOs Greg Kroah-Hartman
2026-10-28 2:09 ` Jonathan Cameron [this message]
2026-10-27 16:19 ` [PATCH 14/15] iio: scmi: use 64-bit divisions for rates and intervals Greg Kroah-Hartman
2026-10-28 1:46 ` Jonathan Cameron
2026-10-27 16:19 ` [PATCH 15/15] iio: sx9310: use the data of the I2C table Greg Kroah-Hartman
2026-10-27 16:25 ` Biju Das
2026-10-27 16:38 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261028020905.7e0e86f0@jic23-hlaptop \
--to=jic23@kernel.org \
--cc=andy@kernel.org \
--cc=ddvlad@gmail.com \
--cc=dlechner@baylibre.com \
--cc=email@sirat.me \
--cc=gregkh@linuxfoundation.org \
--cc=josef@toxicpanda.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=nuno.sa@analog.com \
--cc=stable@kernel.org \
--cc=u.kleine-koenig@baylibre.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®