On 17.04.23 13:25, Linux regression tracking (Thorsten Leemhuis) wrote:
[adding Matthias to the list of recipients, who back then applied to culprit]
Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting for once, to make this easily accessible to everyone.
AngeloGioacchino, Has any progress been made to fix below regression? It doesn't look like it from here, hence I wondered if it fall through the cracks.
Hmmm, nobody replied. Does nobody (including the reporters!) care anymore for valid reasons? Then I'd drop this from the tracking.
Or was progress made and I just missed it?
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 If I did something stupid, please tell me, as explained on that page.
#regzbot poke
On 27.03.23 10:23, AngeloGioacchino Del Regno wrote:
Il 26/03/23 15:23, Bagas Sanjaya ha scritto:
On 3/26/23 02:20, Tobias Dahms wrote:
Hello,
the bisection gives following result:
18c7deca2b812537aa4d928900e208710f1300aa is the first bad commit commit 18c7deca2b812537aa4d928900e208710f1300aa Author: AngeloGioacchino Del Regno angelogioacchino.delregno@collabora.com Date: Tue May 17 12:47:08 2022 +0200
soc: mediatek: pwrap: Use readx_poll_timeout() instead of custom function
Function pwrap_wait_for_state() is a function that polls an address through a helper function, but this is the very same operation that the readx_poll_timeout macro means to do. Convert all instances of calling pwrap_wait_for_state() to instead use the read_poll_timeout macro.
Signed-off-by: AngeloGioacchino Del Regno angelogioacchino.delregno@collabora.com Reviewed-by: Nícolas F. R. A. Prado nfraprado@collabora.com Tested-by: Nícolas F. R. A. Prado nfraprado@collabora.com Link: https://lore.kernel.org/r/20220517104712.24579-2-angelogioacchino.delregno@c... Signed-off-by: Matthias Brugger matthias.bgg@gmail.com
drivers/soc/mediatek/mtk-pmic-wrap.c | 60 ++++++++++++++++++++---------------- 1 file changed, 33 insertions(+), 27 deletions(-)
OK, I'm updating the regression status:
#regzbot introduced: 18c7deca2b8125
And for replying, don't top-post, but rather reply inline with appropriate context instead; hence I cut the replied context.
There are two possible solutions to that, specifically, either: 1. Change readx_poll_timeout() to readx_poll_timeout_atomic(); or 2. Fix the mt6323-led driver so that this operation gets done out of atomic context, which is IMO the option to prefer.
Ideas?
Regards, Angelo