linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Linux kernel regression tracking (#adding)"  <regressions@leemhuis.info>
To: Joel Stanley <joel@jms.id.au>, Andrew Jeffery <andrew@aj.id.au>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Billy Tsai <billy_tsai@aspeedtech.com>,
	linux-aspeed@lists.ozlabs.org, openbmc@lists.ozlabs.org,
	linux-gpio@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Linux kernel regressions list <regressions@lists.linux.dev>
Subject: Re: [PATCH] pinctrl: aspeed: Force to disable the function's signal
Date: Sat, 21 Jan 2023 13:32:30 +0100	[thread overview]
Message-ID: <3af98200-7240-9e93-bd6a-d0e2f71ab1c4@leemhuis.info> (raw)
In-Reply-To: <CACPK8XfQ=uarsOgJ7LaXqLyGG2vSF-47RkAEV=T2gruapx-yfg@mail.gmail.com>

[TLDR: I'm adding this report to the list of tracked Linux kernel
regressions; the text you find below is based on a few templates
paragraphs you might have encountered already in similar form.
See link in footer if these mails annoy you.]

[CCing the regression list, as it should be in the loop for regressions:
https://docs.kernel.org/admin-guide/reporting-regressions.html]

On 19.01.23 02:54, Joel Stanley wrote:
> On Fri, 26 Aug 2022 at 22:48, Andrew Jeffery <andrew@aj.id.au> wrote:
>> On Sat, 27 Aug 2022, at 07:26, Linus Walleij wrote:
>>> On Thu, Aug 18, 2022 at 12:18 PM Billy Tsai <billy_tsai@aspeedtech.com> wrote:
>>>
>>>> When the driver want to disable the signal of the function, it doesn't
>>>> need to query the state of the mux function's signal on a pin. The
>>>> condition below will miss the disable of the signal:
> 
>>> I can't see the verdict for this patch? Will there be a new
>>> version, or are we in the middle of a discussion?
>>> I'd really like Andrew's ACK on the result before merging.
>>
>> Apologies, it's been a bit of A Week :)
>>
>> Given the approach has been discussed with the IP designer and solves a bug I'm okay for it to be merged. If we run into issues it is easy enough to back it out.
> 
> As foreseen by Andrew, this caused a regression. On the Romulus
> machine the device tree contains a gpio hog for GPIO S7. With the
> patch applied:
> 
> [    0.384796] aspeed-g5-pinctrl 1e6e2080.pinctrl: request pin 151
> (AA20) for 1e780000.gpio:943
> [    0.385009] Muxing pin 151 for GPIO
> [    0.385081] Disabling signal VPOB9 for VPO
> [    0.402291] aspeed-g5-pinctrl 1e6e2080.pinctrl: Failed to acquire
> regmap for IP block 1
> [    0.402521] aspeed-g5-pinctrl 1e6e2080.pinctrl: request() failed for pin 151
> 
> The code path is aspeed-gpio -> pinmux-g5 -> regmap -> clk, and the
> of_clock code returns an error as it doesn't have a valid struct
> clk_hw pointer. The regmap call happens because pinmux wants to check
> the GFX node (IP block 1) to query bits there.
> 
> For reference, reverting the patch gives us this trace:
> 
> [    0.393160] Muxing pin 151 for GPIO
> [    0.393267] Disabling signal VPOB9 for VPO
> [    0.393383] Want SCU8C[0x00000080]=0x1, got 0x0 from 0x00000000
> [    0.393552] Disabling signal VPOB9 for VPOOFF1
> [    0.393681] Want SCU8C[0x00000080]=0x1, got 0x0 from 0x00000000
> [    0.393835] Disabling signal VPOB9 for VPOOFF2
> [    0.393965] Want SCU8C[0x00000080]=0x1, got 0x0 from 0x00000000
> [    0.394097] Enabling signal GPIOS7 for GPIOS7
> [    0.394217] Muxed pin 151 as GPIOS7
> [    0.394411] gpio-943 (seq_cont): hogged as output/low
> 
> This can be reproduced in qemu without userspace:
> 
> qemu-system-arm -M romulus-bmc -nographic -kernel arch/arm/boot/zImage
> -dtb arch/arm/boot/dts/aspeed-bmc-opp-romulus.dtb -no-reboot
> 
> Billy, do you have any suggestions?

Thanks for the report. To be sure the issue doesn't fall through the
cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression
tracking bot:

#regzbot ^introduced cf517fef601b
#regzbot title pinctrl: aspeed-g5-pinctrl 1e6e2080.pinctrl: Failed to
acquire regmap for IP block 1
#regzbot ignore-activity

This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply and tell me -- ideally
while also telling regzbot about it, as explained by the page listed in
the footer of this mail.

Developers: When fixing the issue, remember to add 'Link:' tags pointing
to the report (the parent of this mail). See page linked in footer for
details.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
That page also explains what to do if mails like this annoy you.

  reply	other threads:[~2023-01-21 12:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-18 10:18 [PATCH] pinctrl: aspeed: Force to disable the function's signal Billy Tsai
2022-08-19  0:40 ` Andrew Jeffery
2022-08-23 10:51   ` Billy Tsai
2022-08-26 21:56 ` Linus Walleij
2022-08-26 22:48   ` Andrew Jeffery
2023-01-19  1:54     ` Joel Stanley
2023-01-21 12:32       ` Linux kernel regression tracking (#adding) [this message]
2023-02-15 14:52         ` Linux regression tracking #update (Thorsten Leemhuis)
2023-01-27 12:38       ` Linus Walleij
2023-01-30  3:06         ` Joel Stanley
2023-01-30  4:33           ` Andrew Jeffery
2022-08-31 12:15 ` Linus Walleij

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=3af98200-7240-9e93-bd6a-d0e2f71ab1c4@leemhuis.info \
    --to=regressions@leemhuis.info \
    --cc=andrew@aj.id.au \
    --cc=billy_tsai@aspeedtech.com \
    --cc=joel@jms.id.au \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-aspeed@lists.ozlabs.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=openbmc@lists.ozlabs.org \
    --cc=regressions@lists.linux.dev \
    /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;
as well as URLs for NNTP newsgroup(s).