All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gabriel Krisman Bertazi <krisman@collabora.com>
To: Shreeya Patel <shreeya.patel@collabora.com>, brgl@bgdev.pl
Cc: linus.walleij@linaro.org, andy.shevchenko@gmail.com,
	bgolaszewski@baylibre.com, wsa@kernel.org, kernel@collabora.com,
	linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-i2c@vger.kernel.org, lkp@intel.com
Subject: Re: [PATCH v4] gpio: Return EPROBE_DEFER if gc->to_irq is NULL
Date: Thu, 10 Feb 2022 11:36:54 -0500	[thread overview]
Message-ID: <874k56znix.fsf@collabora.com> (raw)
In-Reply-To: <20211116093833.245542-1-shreeya.patel@collabora.com> (Shreeya Patel's message of "Tue, 16 Nov 2021 15:08:33 +0530")

Shreeya Patel <shreeya.patel@collabora.com> writes:

> We are racing the registering of .to_irq when probing the
> i2c driver. This results in random failure of touchscreen
> devices.
>
> Following errors could be seen in dmesg logs when gc->to_irq is NULL
>
> [2.101857] i2c_hid i2c-FTS3528:00: HID over i2c has not been provided an Int IRQ
> [2.101953] i2c_hid: probe of i2c-FTS3528:00 failed with error -22
>
> To avoid this situation, defer probing until to_irq is registered.
>
> This issue has been reported many times in past and people have been
> using workarounds like changing the pinctrl_amd to built-in instead
> of loading it as a module or by adding a softdep for pinctrl_amd into
> the config file.
>
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=209413
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Reported-by: kernel test robot <lkp@intel.com>
> Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com>

Hi guys,

This seems to not have reached the Linus tree on 5.17.  If I'm not
mistaken, it also hasn't reached linux-next as of today. Is there
anything I'm missing here?

This is required to prevent spurious probe crashes of devices like this
FocalTech touchscreen, FT3528, when using pinctrl-amd. We've been
carrying it downstream for quite a while.

Thanks,

-- 
Gabriel Krisman Bertazi

  reply	other threads:[~2022-02-10 16:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-16  9:38 [PATCH v4] gpio: Return EPROBE_DEFER if gc->to_irq is NULL Shreeya Patel
2022-02-10 16:36 ` Gabriel Krisman Bertazi [this message]
2022-02-10 18:00   ` Bartosz Golaszewski
2022-02-11  1:26     ` Gabriel Krisman Bertazi
2022-02-11 10:03       ` Shreeya Patel
2022-02-17 20:10     ` Shreeya Patel

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=874k56znix.fsf@collabora.com \
    --to=krisman@collabora.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=brgl@bgdev.pl \
    --cc=kernel@collabora.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=shreeya.patel@collabora.com \
    --cc=wsa@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.