archive mirror
 help / color / mirror / Atom feed
From: Thorsten Leemhuis <>
To: Linus Torvalds <>,
	Marcelo Roberto Jimenez <>
Cc: Guenter Roeck <>,
	Thierry Reding <>,
	Linus Walleij <>,
	Vidya Sagar <>,
	Edmond Chung <>,
	Andrew Chant <>,
	Will McVicker <>,
	Linux Kernel Mailing List <>,
	Bartosz Golaszewski <>,
	"" <>,
	Michael Walle <>
Subject: Re: Linux 5.17-rc8
Date: Tue, 15 Mar 2022 06:42:39 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[CCing regressions list and Michael Walle]

FWIW, I was a bit surprised to see this, I had assumed the revert that
causing trouble (fc328a7d1fcc) would go in the next merge window. Seems
my regression tracking work did more harm then good here. :-/ Whatever:

On 15.03.22 02:47, Linus Torvalds wrote:
> On Mon, Mar 14, 2022 at 5:45 PM Marcelo Roberto Jimenez
> <> wrote:
>> At a certain point, I tried Thorsten's suggestion to add a gpio-ranges
>> property in a way similar to another patch, but the kernel went into
>> an EPROBE_DEFER deadlock. Thierry Reding made some comments about this
>> in the sequence.
> Hmm. The problem does sound like that particular driver doesn't use
> the pin_ranges thing, so then the tests for an empty pin_ranges will
> always be true.
> [...]
> IOW, it looks like either a gpio controller has to implement that
> 'add_pin_ranges()' function (only tegra), or it needs to always add
> the pin ranges at probe time.
> Am I guessing right that the driver that you use does neither?
> LinusW/Bartoz - this all really sounds strange to me. Maybe I'm
> misreading the situation entirely. Should there be some sanity-test
> that any gpio/pinctrl driver that uses gpiochip_generic_request()
> would either have to have that add_pin_ranges() callback, or a
> successful probe needs to always populate that 'gpiodev->pin_ranges'
> list?
> Or maybe I'm misreading the situation entirely. I don't know the code
> - I'm just grepping for things and trying to make sense of how that
> '->pin_ranges' list is supposed to work.
> But for now, I think that patch has to be reverted.

There is a another reason to do so: Michael Walle reported that the
revert is causing a regression for him:

To quote:

> This breaks the pinctrl-microchip-sgpio driver as far as I can see.
> I tried to debug it and this is what I have discovered so far:
>  (1) the sgpio driver will use the gpio_stub_drv for its child nodes.
>      Looks like a workaround, see [1].
>  (2) these will have an empty gpio range
>  (3) with the changes of this patch, pinctrl_gpio_request() will now
>      be called and will fail with -EPROBE_DEFER.
> I'm not exactly sure what to do here. Saravana Kannan once suggested
> to use devm_of_platform_populate() to probe the child nodes [2]. But
> I haven't found any other driver doing that.
> Also, I'm not sure if there are any other other driver which get
> broken by this. I.e. ones falling into the gpio_stub_drv category.
> [1]
> [2]
> -michael
> NB. this patch doesn't contain a Fixes tag. Was this on purpose?

Ciao, Thorsten

  reply	other threads:[~2022-03-15  5:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-13 20:43 Linux 5.17-rc8 Linus Torvalds
2022-03-14  7:55 ` Build regressions/improvements in v5.17-rc8 Geert Uytterhoeven
2022-03-14 19:25 ` Linux 5.17-rc8 Guenter Roeck
2022-03-14 20:13   ` Linus Torvalds
2022-03-15  0:45     ` Marcelo Roberto Jimenez
2022-03-15  1:13       ` Guenter Roeck
2022-03-15  1:47       ` Linus Torvalds
2022-03-15  5:42         ` Thorsten Leemhuis [this message]
2022-03-15 16:48         ` Bartosz Golaszewski
2022-03-15  9:05     ` Geert Uytterhoeven

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).