Re: kernel error at led trigger "phy0tpt"

Re: kernel error at led trigger "phy0tpt"

[Linux regression tracking (Thorsten Leemhuis)]

[adding the maintainer for drivers/leds/leds-mt6323.c as well as the LED
subsystem maintainers to the list of recipients]

Note, I first thought this might have been a vendor kernel, but it's
not, as Tobias clarified (thx!):
https://lore.kernel.org/all/f8f7d7ae-7e4b-e0fb-6a21-1d4fdcc22035@web.de/

[TLDR for the rest of this mail: I'm adding below 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.]

On 20.03.23 20:44, Tobias Dahms wrote:
> Hello,
> 
> since some kernel versions I get a kernel errror while setting led
> trigger to phy0tpt.
> 
> command to reproduce:
> echo phy0tpt > /sys/class/leds/bpi-r2\:isink\:blue/trigger
> 
> same trigger, other led location => no error:
> echo phy0tpt > /sys/class/leds/bpi-r2\:pio\:blue/trigger
> 
> other trigger, same led location => no error:
> echo phy0tx > /sys/class/leds/bpi-r2\:isink\:blue/trigger
> 
> last good kernel:
> bpi-r2 5.19.17-bpi-r2
> 
> error at kernel versions:
> bpi-r2 6.0.19-bpi-r2
> up to
> bpi-r2 6.3.0-rc1-bpi-r2+
> 
> wireless lan card:
> 01:00.0 Network controller: MEDIATEK Corp. MT7612E 802.11acbgn PCI
> Express Wireless Network Adapter
> 
> distribution:
> Arch-Linux-ARM (with vanilla kernel instead of original distribution
> kernel)
> 
> board:
> BananaPi-R2
> 
> log messages:
> Mär 12 12:54:55 bpi-r2 kernel: BUG: scheduling while atomic:
> swapper/0/0/0x00000100
> Mär 12 12:54:55 bpi-r2 kernel: Modules linked in: aes_arm_bs crypto_simd
> cryptd nft_masq nft_ct nf_log_syslog nft_log nft_chain_nat nf_nat
> nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink mt76x2e
> mt76x2_common mt76x02_lib mt76 spi_mt65xx pwm_mediatek mt6577_auxadc
> sch_fq_codel fuse configfs ip_tables x_tables
> Mär 12 12:54:55 bpi-r2 kernel: CPU: 0 PID: 0 Comm: swapper/0 Not tainted
> 6.3.0-rc1-bpi-r2+ #1
> Mär 12 12:54:55 bpi-r2 kernel: Hardware name: Mediatek Cortex-A7 (Device
> Tree)
> Mär 12 12:54:55 bpi-r2 kernel: Backtrace:
> Mär 12 12:54:55 bpi-r2 kernel:  dump_backtrace from show_stack+0x20/0x24
> Mär 12 12:54:55 bpi-r2 kernel:  r7:c14ab340 r6:00000000 r5:c12507fc
> r4:600f0113
> Mär 12 12:54:55 bpi-r2 kernel:  show_stack from dump_stack_lvl+0x48/0x54
> Mär 12 12:54:55 bpi-r2 kernel:  dump_stack_lvl from dump_stack+0x18/0x1c
> Mär 12 12:54:55 bpi-r2 kernel:  r5:c1508fc0 r4:00000000
> Mär 12 12:54:55 bpi-r2 kernel:  dump_stack from __schedule_bug+0x60/0x70
> Mär 12 12:54:55 bpi-r2 kernel:  __schedule_bug from __schedule+0x6b0/0x904
> Mär 12 12:54:55 bpi-r2 kernel:  r5:c1508fc0 r4:eed9d340
> Mär 12 12:54:55 bpi-r2 kernel:  __schedule from schedule+0x6c/0xe8
> Mär 12 12:54:55 bpi-r2 kernel:  r10:c1501ba0 r9:00000000 r8:00001b58
> r7:c1508fc0 r6:00001b58 r5:0000004a
> Mär 12 12:54:55 bpi-r2 kernel:  r4:c1508fc0
> Mär 12 12:54:55 bpi-r2 kernel:  schedule from
> schedule_hrtimeout_range_clock+0xec/0x14c
> Mär 12 12:54:55 bpi-r2 kernel:  r5:0000004a r4:47ac1837
> Mär 12 12:54:55 bpi-r2 kernel:  schedule_hrtimeout_range_clock from
> schedule_hrtimeout_range+0x28/0x30
> Mär 12 12:54:55 bpi-r2 kernel:  r10:c1501c50 r9:c1508fc0 r8:00000002
> r7:00000000 r6:c1501ba0 r5:00000000
> Mär 12 12:54:55 bpi-r2 kernel:  r4:00001b58
> Mär 12 12:54:55 bpi-r2 kernel:  schedule_hrtimeout_range from
> usleep_range_state+0x6c/0x90
> Mär 12 12:54:55 bpi-r2 kernel:  usleep_range_state from
> pwrap_read16+0xfc/0x2a0
> Mär 12 12:54:55 bpi-r2 kernel:  r9:0000004a r8:4844840c r7:0000004a
> r6:48447f8a r5:01980000 r4:c2703940
> Mär 12 12:54:55 bpi-r2 kernel:  pwrap_read16 from
> pwrap_regmap_read+0x24/0x28
> Mär 12 12:54:55 bpi-r2 kernel:  r10:00001f00 r9:00000000 r8:00000f00
> r7:c2703940 r6:c1501c50 r5:00000330
> Mär 12 12:54:55 bpi-r2 kernel:  r4:c196e000 r3:c06f3fbc
> Mär 12 12:54:55 bpi-r2 kernel:  pwrap_regmap_read from
> _regmap_read+0x70/0x160
> Mär 12 12:54:55 bpi-r2 kernel:  _regmap_read from
> _regmap_update_bits+0xc8/0x108
> Mär 12 12:54:55 bpi-r2 kernel:  r10:00001f00 r9:00000000 r8:00000f00
> r7:c1508fc0 r6:00000330 r5:00000000
> Mär 12 12:54:55 bpi-r2 kernel:  r4:c196e000 r3:00000000
> Mär 12 12:54:55 bpi-r2 kernel:  _regmap_update_bits from
> regmap_update_bits_base+0x60/0x84
> Mär 12 12:54:55 bpi-r2 kernel:  r10:00000000 r9:00000f00 r8:00000000
> r7:00001f00 r6:00000000 r5:00000330
> Mär 12 12:54:55 bpi-r2 kernel:  r4:c196e000
> Mär 12 12:54:55 bpi-r2 kernel:  regmap_update_bits_base from
> mt6323_led_set_blink+0xf0/0x148
> Mär 12 12:54:55 bpi-r2 kernel:  r10:eed94800 r9:c16998c0 r8:c196e000
> r7:c31f0c48 r6:c2456f48 r5:00000000
> Mär 12 12:54:55 bpi-r2 kernel:  r4:0000014e
> Mär 12 12:54:55 bpi-r2 kernel:  mt6323_led_set_blink from
> led_blink_setup+0x3c/0x110
> Mär 12 12:54:55 bpi-r2 kernel:  r9:c16998c0 r8:00000770 r7:c1501d60
> r6:c1501d5c r5:c1501d60 r4:c31f0c48
> Mär 12 12:54:55 bpi-r2 kernel:  led_blink_setup from
> led_blink_set+0x60/0x64
> Mär 12 12:54:55 bpi-r2 kernel:  r7:c1501d60 r6:c1501d5c r5:c31f0c58
> r4:c31f0c48
> Mär 12 12:54:55 bpi-r2 kernel:  led_blink_set from
> led_trigger_blink+0x44/0x58
> Mär 12 12:54:55 bpi-r2 kernel:  r7:c1501d60 r6:c1501d5c r5:c5b69740
> r4:c31f0c48
> Mär 12 12:54:55 bpi-r2 kernel:  led_trigger_blink from
> tpt_trig_timer+0x10c/0x130
> Mär 12 12:54:55 bpi-r2 kernel:  r7:c0df71f0 r6:c1508fc0 r5:c5b685a0
> r4:c597b628
> Mär 12 12:54:55 bpi-r2 kernel:  tpt_trig_timer from
> call_timer_fn+0x48/0x168
> Mär 12 12:54:55 bpi-r2 kernel:  r6:c597b628 r5:00000100 r4:c16998c0
> Mär 12 12:54:55 bpi-r2 kernel:  call_timer_fn from
> run_timer_softirq+0x600/0x6c8
> Mär 12 12:54:55 bpi-r2 kernel:  r9:c16998c0 r8:00000000 r7:00000770
> r6:00000000 r5:c1501de4 r4:c597b628
> Mär 12 12:54:55 bpi-r2 kernel:  run_timer_softirq from
> __do_softirq+0x140/0x34c
> Mär 12 12:54:55 bpi-r2 kernel:  r10:00000082 r9:00000100 r8:c1698481
> r7:c1698f60 r6:00000001 r5:00000002
> Mär 12 12:54:55 bpi-r2 kernel:  r4:c1503084
> Mär 12 12:54:55 bpi-r2 kernel:  __do_softirq from irq_exit+0xb8/0xe8
> Mär 12 12:54:55 bpi-r2 kernel:  r10:10c5387d r9:c1508fc0 r8:c1698481
> r7:c1501f0c r6:00000000 r5:c1501ed8
> Mär 12 12:54:55 bpi-r2 kernel:  r4:c14aaf58
> Mär 12 12:54:55 bpi-r2 kernel:  irq_exit from
> generic_handle_arch_irq+0x48/0x4c
> Mär 12 12:54:55 bpi-r2 kernel:  r5:c1501ed8 r4:c14aaf58
> Mär 12 12:54:55 bpi-r2 kernel:  generic_handle_arch_irq from
> __irq_svc+0x88/0xb0
> Mär 12 12:54:55 bpi-r2 kernel: Exception stack(0xc1501ed8 to 0xc1501f20)
> Mär 12 12:54:55 bpi-r2 kernel: 1ec0:
>                   000862f4 2d8f2000
> Mär 12 12:54:55 bpi-r2 kernel: 1ee0: c1508fc0 00000000 c1699cc0 c1504f10
> c1504f70 00000001 c1698481 c123a9b4
> Mär 12 12:54:55 bpi-r2 kernel: 1f00: 10c5387d c1501f3c 00000001 c1501f28
> c0e36fa0 c0e3767c 600f0013 ffffffff
> Mär 12 12:54:55 bpi-r2 kernel:  r7:c1501f0c r6:ffffffff r5:600f0013
> r4:c0e3767c
> Mär 12 12:54:55 bpi-r2 kernel:  default_idle_call from do_idle+0xc4/0x124
> Mär 12 12:54:55 bpi-r2 kernel:  r5:c1504f10 r4:00000001
> Mär 12 12:54:55 bpi-r2 kernel:  do_idle from cpu_startup_entry+0x28/0x2c
> Mär 12 12:54:55 bpi-r2 kernel:  r9:efffcd40 r8:00000000 r7:00000045
> r6:c1326068 r5:c16fb9b8 r4:000000ec
> Mär 12 12:54:55 bpi-r2 kernel:  cpu_startup_entry from rest_init+0xc0/0xc4
> Mär 12 12:54:55 bpi-r2 kernel:  rest_init from
> arch_post_acpi_subsys_init+0x0/0x30
> Mär 12 12:54:55 bpi-r2 kernel:  r5:c16fb9b8 r4:c16cc038
> Mär 12 12:54:55 bpi-r2 kernel:  arch_call_rest_init from
> start_kernel+0x6c0/0x704
> Mär 12 12:54:55 bpi-r2 kernel:  start_kernel from 0x0
> Mär 12 12:54:55 bpi-r2 kernel: bad: scheduling from the idle thread!
> Mär 12 12:54:55 bpi-r2 kernel: CPU: 0 PID: 0 Comm: swapper/0 Tainted: G
>       W          6.3.0-rc1-bpi-r2+ #1
> Mär 12 12:54:55 bpi-r2 kernel: Hardware name: Mediatek Cortex-A7 (Device
> Tree)
> Mär 12 12:54:55 bpi-r2 kernel: Backtrace:
> Mär 12 12:54:55 bpi-r2 kernel:  dump_backtrace from show_stack+0x20/0x24
> Mär 12 12:54:55 bpi-r2 kernel:  r7:c14ab340 r6:00000001 r5:c12507fc
> r4:60070013
> Mär 12 12:54:55 bpi-r2 kernel:  show_stack from dump_stack_lvl+0x48/0x54
> Mär 12 12:54:55 bpi-r2 kernel:  dump_stack_lvl from dump_stack+0x18/0x1c
> Mär 12 12:54:55 bpi-r2 kernel:  r5:c1508fc0 r4:eed9d340
> Mär 12 12:54:55 bpi-r2 kernel:  dump_stack from dequeue_task_idle+0x30/0x44
> Mär 12 12:54:55 bpi-r2 kernel:  dequeue_task_idle from
> __schedule+0x4bc/0x904
> Mär 12 12:54:55 bpi-r2 kernel:  r5:c1508fc0 r4:eed9d340
> Mär 12 12:54:55 bpi-r2 kernel:  __schedule from schedule+0x6c/0xe8
> Mär 12 12:54:55 bpi-r2 kernel:  r10:c1501ba0 r9:00000000 r8:00001b58
> r7:c1508fc0 r6:00001b58 r5:0000004a
> Mär 12 12:54:55 bpi-r2 kernel:  r4:c1508fc0
> Mär 12 12:54:55 bpi-r2 kernel:  schedule from
> schedule_hrtimeout_range_clock+0xec/0x14c
> Mär 12 12:54:55 bpi-r2 kernel:  r5:0000004a r4:492d8817
> Mär 12 12:54:55 bpi-r2 kernel:  schedule_hrtimeout_range_clock from
> schedule_hrtimeout_range+0x28/0x30
> Mär 12 12:54:55 bpi-r2 kernel:  r10:c1501c50 r9:c1508fc0 r8:00000002
> r7:00000000 r6:c1501ba0 r5:00000000
> Mär 12 12:54:55 bpi-r2 kernel:  r4:00001b58
> Mär 12 12:54:55 bpi-r2 kernel:  schedule_hrtimeout_range from
> usleep_range_state+0x6c/0x90
> Mär 12 12:54:55 bpi-r2 kernel:  usleep_range_state from
> pwrap_read16+0xfc/0x2a0
> Mär 12 12:54:55 bpi-r2 kernel:  r9:0000004a r8:49c5f439 r7:0000004a
> r6:49c5f0eb r5:01990000 r4:c2703940
> Mär 12 12:54:55 bpi-r2 kernel:  pwrap_read16 from
> pwrap_regmap_read+0x24/0x28
> Mär 12 12:54:55 bpi-r2 kernel:  r10:0000ffff r9:00000000 r8:0000014d
> r7:c2703940 r6:c1501c50 r5:00000332
> Mär 12 12:54:55 bpi-r2 kernel:  r4:c196e000 r3:c06f3fbc
> Mär 12 12:54:55 bpi-r2 kernel:  pwrap_regmap_read from
> _regmap_read+0x70/0x160
> Mär 12 12:54:55 bpi-r2 kernel:  _regmap_read from
> _regmap_update_bits+0xc8/0x108
> Mär 12 12:54:55 bpi-r2 kernel:  r10:0000ffff r9:00000000 r8:0000014d
> r7:c1508fc0 r6:00000332 r5:00000000
> Mär 12 12:54:55 bpi-r2 kernel:  r4:c196e000 r3:00000000
> Mär 12 12:54:55 bpi-r2 kernel:  _regmap_update_bits from
> regmap_update_bits_base+0x60/0x84
> Mär 12 12:54:55 bpi-r2 kernel:  r10:00000000 r9:0000014d r8:00000000
> r7:0000ffff r6:00000000 r5:00000332
> Mär 12 12:54:55 bpi-r2 kernel:  r4:c196e000
> Mär 12 12:54:55 bpi-r2 kernel:  regmap_update_bits_base from
> mt6323_led_set_blink+0x138/0x148
> Mär 12 12:54:55 bpi-r2 kernel:  r10:eed94800 r9:00000000 r8:c196e000
> r7:c31f0c48 r6:c2456f48 r5:00000000
> Mär 12 12:54:55 bpi-r2 kernel:  r4:0000014e
> Mär 12 12:54:55 bpi-r2 kernel:  mt6323_led_set_blink from
> led_blink_setup+0x3c/0x110
> Mär 12 12:54:55 bpi-r2 kernel:  r9:c16998c0 r8:00000770 r7:c1501d60
> r6:c1501d5c r5:c1501d60 r4:c31f0c48
> Mär 12 12:54:55 bpi-r2 kernel:  led_blink_setup from
> led_blink_set+0x60/0x64
> Mär 12 12:54:55 bpi-r2 kernel:  r7:c1501d60 r6:c1501d5c r5:c31f0c58
> r4:c31f0c48
> Mär 12 12:54:55 bpi-r2 kernel:  led_blink_set from
> led_trigger_blink+0x44/0x58
> Mär 12 12:54:55 bpi-r2 kernel:  r7:c1501d60 r6:c1501d5c r5:c5b69740
> r4:c31f0c48
> Mär 12 12:54:55 bpi-r2 kernel:  led_trigger_blink from
> tpt_trig_timer+0x10c/0x130
> Mär 12 12:54:55 bpi-r2 kernel:  r7:c0df71f0 r6:c1508fc0 r5:c5b685a0
> r4:c597b628
> Mär 12 12:54:55 bpi-r2 kernel:  tpt_trig_timer from
> call_timer_fn+0x48/0x168
> Mär 12 12:54:55 bpi-r2 kernel:  r6:c597b628 r5:00000100 r4:c16998c0
> Mär 12 12:54:55 bpi-r2 kernel:  call_timer_fn from
> run_timer_softirq+0x600/0x6c8
> Mär 12 12:54:55 bpi-r2 kernel:  r9:c16998c0 r8:00000000 r7:00000770
> r6:00000000 r5:c1501de4 r4:c597b628
> Mär 12 12:54:55 bpi-r2 kernel:  run_timer_softirq from
> __do_softirq+0x140/0x34c
> Mär 12 12:54:55 bpi-r2 kernel:  r10:00000082 r9:00000100 r8:c1698481
> r7:c1698f60 r6:00000001 r5:00000002
> Mär 12 12:54:55 bpi-r2 kernel:  r4:c1503084
> Mär 12 12:54:55 bpi-r2 kernel:  __do_softirq from irq_exit+0xb8/0xe8
> Mär 12 12:54:55 bpi-r2 kernel:  r10:10c5387d r9:c1508fc0 r8:c1698481
> r7:c1501f0c r6:00000000 r5:c1501ed8
> Mär 12 12:54:55 bpi-r2 kernel:  r4:c14aaf58
> Mär 12 12:54:55 bpi-r2 kernel:  irq_exit from
> generic_handle_arch_irq+0x48/0x4c
> Mär 12 12:54:55 bpi-r2 kernel:  r5:c1501ed8 r4:c14aaf58
> Mär 12 12:54:55 bpi-r2 kernel:  generic_handle_arch_irq from
> __irq_svc+0x88/0xb0
> Mär 12 12:54:55 bpi-r2 kernel: Exception stack(0xc1501ed8 to 0xc1501f20)
> Mär 12 12:54:55 bpi-r2 kernel: 1ec0:
>                   000862f4 2d8f2000
> Mär 12 12:54:55 bpi-r2 kernel: 1ee0: c1508fc0 00000000 c1699cc0 c1504f10
> c1504f70 00000001 c1698481 c123a9b4
> Mär 12 12:54:55 bpi-r2 kernel: 1f00: 10c5387d c1501f3c 00000001 c1501f28
> c0e36fa0 c0e3767c 600f0013 ffffffff
> Mär 12 12:54:55 bpi-r2 kernel:  r7:c1501f0c r6:ffffffff r5:600f0013
> r4:c0e3767c
> Mär 12 12:54:55 bpi-r2 kernel:  default_idle_call from do_idle+0xc4/0x124
> Mär 12 12:54:55 bpi-r2 kernel:  r5:c1504f10 r4:00000001
> Mär 12 12:54:55 bpi-r2 kernel:  do_idle from cpu_startup_entry+0x28/0x2c
> Mär 12 12:54:55 bpi-r2 kernel:  r9:efffcd40 r8:00000000 r7:00000045
> r6:c1326068 r5:c16fb9b8 r4:000000ec
> Mär 12 12:54:55 bpi-r2 kernel:  cpu_startup_entry from rest_init+0xc0/0xc4
> Mär 12 12:54:55 bpi-r2 kernel:  rest_init from
> arch_post_acpi_subsys_init+0x0/0x30
> Mär 12 12:54:55 bpi-r2 kernel:  r5:c16fb9b8 r4:c16cc038
> Mär 12 12:54:55 bpi-r2 kernel:  arch_call_rest_init from
> start_kernel+0x6c0/0x704
> Mär 12 12:54:55 bpi-r2 kernel:  start_kernel from 0x0
> Mär 12 12:54:55 bpi-r2 kernel: ------------[ cut here ]------------

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 v5.19..v6.0
#regzbot title led: kernel bug when setting trigger to "phy0tpt"
#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.

Re: kernel error at led trigger "phy0tpt"

[Tobias Dahms]

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@collabora.com
     Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>

  drivers/soc/mediatek/mtk-pmic-wrap.c | 60
++++++++++++++++++++----------------
  1 file changed, 33 insertions(+), 27 deletions(-)
--------------------------------------------------------------------

regards
Tobias


Am 22.03.23 um 17:59 schrieb Linux regression tracking (Thorsten Leemhuis):
> [adding the maintainer for drivers/leds/leds-mt6323.c as well as the LED
> subsystem maintainers to the list of recipients]
>
> Note, I first thought this might have been a vendor kernel, but it's
> not, as Tobias clarified (thx!):
> https://lore.kernel.org/all/f8f7d7ae-7e4b-e0fb-6a21-1d4fdcc22035@web.de/
>
> [TLDR for the rest of this mail: I'm adding below 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.]
>
> On 20.03.23 20:44, Tobias Dahms wrote:
>> Hello,
>>
>> since some kernel versions I get a kernel errror while setting led
>> trigger to phy0tpt.
>>
>> command to reproduce:
>> echo phy0tpt > /sys/class/leds/bpi-r2\:isink\:blue/trigger
>>
>> same trigger, other led location => no error:
>> echo phy0tpt > /sys/class/leds/bpi-r2\:pio\:blue/trigger
>>
>> other trigger, same led location => no error:
>> echo phy0tx > /sys/class/leds/bpi-r2\:isink\:blue/trigger
>>
>> last good kernel:
>> bpi-r2 5.19.17-bpi-r2
>>
>> error at kernel versions:
>> bpi-r2 6.0.19-bpi-r2
>> up to
>> bpi-r2 6.3.0-rc1-bpi-r2+
>>
>> wireless lan card:
>> 01:00.0 Network controller: MEDIATEK Corp. MT7612E 802.11acbgn PCI
>> Express Wireless Network Adapter
>>
>> distribution:
>> Arch-Linux-ARM (with vanilla kernel instead of original distribution
>> kernel)
>>
>> board:
>> BananaPi-R2
>>
>> log messages:
>> Mär 12 12:54:55 bpi-r2 kernel: BUG: scheduling while atomic:
>> swapper/0/0/0x00000100
>> Mär 12 12:54:55 bpi-r2 kernel: Modules linked in: aes_arm_bs crypto_simd
>> cryptd nft_masq nft_ct nf_log_syslog nft_log nft_chain_nat nf_nat
>> nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink mt76x2e
>> mt76x2_common mt76x02_lib mt76 spi_mt65xx pwm_mediatek mt6577_auxadc
>> sch_fq_codel fuse configfs ip_tables x_tables
>> Mär 12 12:54:55 bpi-r2 kernel: CPU: 0 PID: 0 Comm: swapper/0 Not tainted
>> 6.3.0-rc1-bpi-r2+ #1
>> Mär 12 12:54:55 bpi-r2 kernel: Hardware name: Mediatek Cortex-A7 (Device
>> Tree)
>> Mär 12 12:54:55 bpi-r2 kernel: Backtrace:
>> Mär 12 12:54:55 bpi-r2 kernel:  dump_backtrace from show_stack+0x20/0x24
>> Mär 12 12:54:55 bpi-r2 kernel:  r7:c14ab340 r6:00000000 r5:c12507fc
>> r4:600f0113
>> Mär 12 12:54:55 bpi-r2 kernel:  show_stack from dump_stack_lvl+0x48/0x54
>> Mär 12 12:54:55 bpi-r2 kernel:  dump_stack_lvl from dump_stack+0x18/0x1c
>> Mär 12 12:54:55 bpi-r2 kernel:  r5:c1508fc0 r4:00000000
>> Mär 12 12:54:55 bpi-r2 kernel:  dump_stack from __schedule_bug+0x60/0x70
>> Mär 12 12:54:55 bpi-r2 kernel:  __schedule_bug from __schedule+0x6b0/0x904
>> Mär 12 12:54:55 bpi-r2 kernel:  r5:c1508fc0 r4:eed9d340
>> Mär 12 12:54:55 bpi-r2 kernel:  __schedule from schedule+0x6c/0xe8
>> Mär 12 12:54:55 bpi-r2 kernel:  r10:c1501ba0 r9:00000000 r8:00001b58
>> r7:c1508fc0 r6:00001b58 r5:0000004a
>> Mär 12 12:54:55 bpi-r2 kernel:  r4:c1508fc0
>> Mär 12 12:54:55 bpi-r2 kernel:  schedule from
>> schedule_hrtimeout_range_clock+0xec/0x14c
>> Mär 12 12:54:55 bpi-r2 kernel:  r5:0000004a r4:47ac1837
>> Mär 12 12:54:55 bpi-r2 kernel:  schedule_hrtimeout_range_clock from
>> schedule_hrtimeout_range+0x28/0x30
>> Mär 12 12:54:55 bpi-r2 kernel:  r10:c1501c50 r9:c1508fc0 r8:00000002
>> r7:00000000 r6:c1501ba0 r5:00000000
>> Mär 12 12:54:55 bpi-r2 kernel:  r4:00001b58
>> Mär 12 12:54:55 bpi-r2 kernel:  schedule_hrtimeout_range from
>> usleep_range_state+0x6c/0x90
>> Mär 12 12:54:55 bpi-r2 kernel:  usleep_range_state from
>> pwrap_read16+0xfc/0x2a0
>> Mär 12 12:54:55 bpi-r2 kernel:  r9:0000004a r8:4844840c r7:0000004a
>> r6:48447f8a r5:01980000 r4:c2703940
>> Mär 12 12:54:55 bpi-r2 kernel:  pwrap_read16 from
>> pwrap_regmap_read+0x24/0x28
>> Mär 12 12:54:55 bpi-r2 kernel:  r10:00001f00 r9:00000000 r8:00000f00
>> r7:c2703940 r6:c1501c50 r5:00000330
>> Mär 12 12:54:55 bpi-r2 kernel:  r4:c196e000 r3:c06f3fbc
>> Mär 12 12:54:55 bpi-r2 kernel:  pwrap_regmap_read from
>> _regmap_read+0x70/0x160
>> Mär 12 12:54:55 bpi-r2 kernel:  _regmap_read from
>> _regmap_update_bits+0xc8/0x108
>> Mär 12 12:54:55 bpi-r2 kernel:  r10:00001f00 r9:00000000 r8:00000f00
>> r7:c1508fc0 r6:00000330 r5:00000000
>> Mär 12 12:54:55 bpi-r2 kernel:  r4:c196e000 r3:00000000
>> Mär 12 12:54:55 bpi-r2 kernel:  _regmap_update_bits from
>> regmap_update_bits_base+0x60/0x84
>> Mär 12 12:54:55 bpi-r2 kernel:  r10:00000000 r9:00000f00 r8:00000000
>> r7:00001f00 r6:00000000 r5:00000330
>> Mär 12 12:54:55 bpi-r2 kernel:  r4:c196e000
>> Mär 12 12:54:55 bpi-r2 kernel:  regmap_update_bits_base from
>> mt6323_led_set_blink+0xf0/0x148
>> Mär 12 12:54:55 bpi-r2 kernel:  r10:eed94800 r9:c16998c0 r8:c196e000
>> r7:c31f0c48 r6:c2456f48 r5:00000000
>> Mär 12 12:54:55 bpi-r2 kernel:  r4:0000014e
>> Mär 12 12:54:55 bpi-r2 kernel:  mt6323_led_set_blink from
>> led_blink_setup+0x3c/0x110
>> Mär 12 12:54:55 bpi-r2 kernel:  r9:c16998c0 r8:00000770 r7:c1501d60
>> r6:c1501d5c r5:c1501d60 r4:c31f0c48
>> Mär 12 12:54:55 bpi-r2 kernel:  led_blink_setup from
>> led_blink_set+0x60/0x64
>> Mär 12 12:54:55 bpi-r2 kernel:  r7:c1501d60 r6:c1501d5c r5:c31f0c58
>> r4:c31f0c48
>> Mär 12 12:54:55 bpi-r2 kernel:  led_blink_set from
>> led_trigger_blink+0x44/0x58
>> Mär 12 12:54:55 bpi-r2 kernel:  r7:c1501d60 r6:c1501d5c r5:c5b69740
>> r4:c31f0c48
>> Mär 12 12:54:55 bpi-r2 kernel:  led_trigger_blink from
>> tpt_trig_timer+0x10c/0x130
>> Mär 12 12:54:55 bpi-r2 kernel:  r7:c0df71f0 r6:c1508fc0 r5:c5b685a0
>> r4:c597b628
>> Mär 12 12:54:55 bpi-r2 kernel:  tpt_trig_timer from
>> call_timer_fn+0x48/0x168
>> Mär 12 12:54:55 bpi-r2 kernel:  r6:c597b628 r5:00000100 r4:c16998c0
>> Mär 12 12:54:55 bpi-r2 kernel:  call_timer_fn from
>> run_timer_softirq+0x600/0x6c8
>> Mär 12 12:54:55 bpi-r2 kernel:  r9:c16998c0 r8:00000000 r7:00000770
>> r6:00000000 r5:c1501de4 r4:c597b628
>> Mär 12 12:54:55 bpi-r2 kernel:  run_timer_softirq from
>> __do_softirq+0x140/0x34c
>> Mär 12 12:54:55 bpi-r2 kernel:  r10:00000082 r9:00000100 r8:c1698481
>> r7:c1698f60 r6:00000001 r5:00000002
>> Mär 12 12:54:55 bpi-r2 kernel:  r4:c1503084
>> Mär 12 12:54:55 bpi-r2 kernel:  __do_softirq from irq_exit+0xb8/0xe8
>> Mär 12 12:54:55 bpi-r2 kernel:  r10:10c5387d r9:c1508fc0 r8:c1698481
>> r7:c1501f0c r6:00000000 r5:c1501ed8
>> Mär 12 12:54:55 bpi-r2 kernel:  r4:c14aaf58
>> Mär 12 12:54:55 bpi-r2 kernel:  irq_exit from
>> generic_handle_arch_irq+0x48/0x4c
>> Mär 12 12:54:55 bpi-r2 kernel:  r5:c1501ed8 r4:c14aaf58
>> Mär 12 12:54:55 bpi-r2 kernel:  generic_handle_arch_irq from
>> __irq_svc+0x88/0xb0
>> Mär 12 12:54:55 bpi-r2 kernel: Exception stack(0xc1501ed8 to 0xc1501f20)
>> Mär 12 12:54:55 bpi-r2 kernel: 1ec0:
>>                    000862f4 2d8f2000
>> Mär 12 12:54:55 bpi-r2 kernel: 1ee0: c1508fc0 00000000 c1699cc0 c1504f10
>> c1504f70 00000001 c1698481 c123a9b4
>> Mär 12 12:54:55 bpi-r2 kernel: 1f00: 10c5387d c1501f3c 00000001 c1501f28
>> c0e36fa0 c0e3767c 600f0013 ffffffff
>> Mär 12 12:54:55 bpi-r2 kernel:  r7:c1501f0c r6:ffffffff r5:600f0013
>> r4:c0e3767c
>> Mär 12 12:54:55 bpi-r2 kernel:  default_idle_call from do_idle+0xc4/0x124
>> Mär 12 12:54:55 bpi-r2 kernel:  r5:c1504f10 r4:00000001
>> Mär 12 12:54:55 bpi-r2 kernel:  do_idle from cpu_startup_entry+0x28/0x2c
>> Mär 12 12:54:55 bpi-r2 kernel:  r9:efffcd40 r8:00000000 r7:00000045
>> r6:c1326068 r5:c16fb9b8 r4:000000ec
>> Mär 12 12:54:55 bpi-r2 kernel:  cpu_startup_entry from rest_init+0xc0/0xc4
>> Mär 12 12:54:55 bpi-r2 kernel:  rest_init from
>> arch_post_acpi_subsys_init+0x0/0x30
>> Mär 12 12:54:55 bpi-r2 kernel:  r5:c16fb9b8 r4:c16cc038
>> Mär 12 12:54:55 bpi-r2 kernel:  arch_call_rest_init from
>> start_kernel+0x6c0/0x704
>> Mär 12 12:54:55 bpi-r2 kernel:  start_kernel from 0x0
>> Mär 12 12:54:55 bpi-r2 kernel: bad: scheduling from the idle thread!
>> Mär 12 12:54:55 bpi-r2 kernel: CPU: 0 PID: 0 Comm: swapper/0 Tainted: G
>>        W          6.3.0-rc1-bpi-r2+ #1
>> Mär 12 12:54:55 bpi-r2 kernel: Hardware name: Mediatek Cortex-A7 (Device
>> Tree)
>> Mär 12 12:54:55 bpi-r2 kernel: Backtrace:
>> Mär 12 12:54:55 bpi-r2 kernel:  dump_backtrace from show_stack+0x20/0x24
>> Mär 12 12:54:55 bpi-r2 kernel:  r7:c14ab340 r6:00000001 r5:c12507fc
>> r4:60070013
>> Mär 12 12:54:55 bpi-r2 kernel:  show_stack from dump_stack_lvl+0x48/0x54
>> Mär 12 12:54:55 bpi-r2 kernel:  dump_stack_lvl from dump_stack+0x18/0x1c
>> Mär 12 12:54:55 bpi-r2 kernel:  r5:c1508fc0 r4:eed9d340
>> Mär 12 12:54:55 bpi-r2 kernel:  dump_stack from dequeue_task_idle+0x30/0x44
>> Mär 12 12:54:55 bpi-r2 kernel:  dequeue_task_idle from
>> __schedule+0x4bc/0x904
>> Mär 12 12:54:55 bpi-r2 kernel:  r5:c1508fc0 r4:eed9d340
>> Mär 12 12:54:55 bpi-r2 kernel:  __schedule from schedule+0x6c/0xe8
>> Mär 12 12:54:55 bpi-r2 kernel:  r10:c1501ba0 r9:00000000 r8:00001b58
>> r7:c1508fc0 r6:00001b58 r5:0000004a
>> Mär 12 12:54:55 bpi-r2 kernel:  r4:c1508fc0
>> Mär 12 12:54:55 bpi-r2 kernel:  schedule from
>> schedule_hrtimeout_range_clock+0xec/0x14c
>> Mär 12 12:54:55 bpi-r2 kernel:  r5:0000004a r4:492d8817
>> Mär 12 12:54:55 bpi-r2 kernel:  schedule_hrtimeout_range_clock from
>> schedule_hrtimeout_range+0x28/0x30
>> Mär 12 12:54:55 bpi-r2 kernel:  r10:c1501c50 r9:c1508fc0 r8:00000002
>> r7:00000000 r6:c1501ba0 r5:00000000
>> Mär 12 12:54:55 bpi-r2 kernel:  r4:00001b58
>> Mär 12 12:54:55 bpi-r2 kernel:  schedule_hrtimeout_range from
>> usleep_range_state+0x6c/0x90
>> Mär 12 12:54:55 bpi-r2 kernel:  usleep_range_state from
>> pwrap_read16+0xfc/0x2a0
>> Mär 12 12:54:55 bpi-r2 kernel:  r9:0000004a r8:49c5f439 r7:0000004a
>> r6:49c5f0eb r5:01990000 r4:c2703940
>> Mär 12 12:54:55 bpi-r2 kernel:  pwrap_read16 from
>> pwrap_regmap_read+0x24/0x28
>> Mär 12 12:54:55 bpi-r2 kernel:  r10:0000ffff r9:00000000 r8:0000014d
>> r7:c2703940 r6:c1501c50 r5:00000332
>> Mär 12 12:54:55 bpi-r2 kernel:  r4:c196e000 r3:c06f3fbc
>> Mär 12 12:54:55 bpi-r2 kernel:  pwrap_regmap_read from
>> _regmap_read+0x70/0x160
>> Mär 12 12:54:55 bpi-r2 kernel:  _regmap_read from
>> _regmap_update_bits+0xc8/0x108
>> Mär 12 12:54:55 bpi-r2 kernel:  r10:0000ffff r9:00000000 r8:0000014d
>> r7:c1508fc0 r6:00000332 r5:00000000
>> Mär 12 12:54:55 bpi-r2 kernel:  r4:c196e000 r3:00000000
>> Mär 12 12:54:55 bpi-r2 kernel:  _regmap_update_bits from
>> regmap_update_bits_base+0x60/0x84
>> Mär 12 12:54:55 bpi-r2 kernel:  r10:00000000 r9:0000014d r8:00000000
>> r7:0000ffff r6:00000000 r5:00000332
>> Mär 12 12:54:55 bpi-r2 kernel:  r4:c196e000
>> Mär 12 12:54:55 bpi-r2 kernel:  regmap_update_bits_base from
>> mt6323_led_set_blink+0x138/0x148
>> Mär 12 12:54:55 bpi-r2 kernel:  r10:eed94800 r9:00000000 r8:c196e000
>> r7:c31f0c48 r6:c2456f48 r5:00000000
>> Mär 12 12:54:55 bpi-r2 kernel:  r4:0000014e
>> Mär 12 12:54:55 bpi-r2 kernel:  mt6323_led_set_blink from
>> led_blink_setup+0x3c/0x110
>> Mär 12 12:54:55 bpi-r2 kernel:  r9:c16998c0 r8:00000770 r7:c1501d60
>> r6:c1501d5c r5:c1501d60 r4:c31f0c48
>> Mär 12 12:54:55 bpi-r2 kernel:  led_blink_setup from
>> led_blink_set+0x60/0x64
>> Mär 12 12:54:55 bpi-r2 kernel:  r7:c1501d60 r6:c1501d5c r5:c31f0c58
>> r4:c31f0c48
>> Mär 12 12:54:55 bpi-r2 kernel:  led_blink_set from
>> led_trigger_blink+0x44/0x58
>> Mär 12 12:54:55 bpi-r2 kernel:  r7:c1501d60 r6:c1501d5c r5:c5b69740
>> r4:c31f0c48
>> Mär 12 12:54:55 bpi-r2 kernel:  led_trigger_blink from
>> tpt_trig_timer+0x10c/0x130
>> Mär 12 12:54:55 bpi-r2 kernel:  r7:c0df71f0 r6:c1508fc0 r5:c5b685a0
>> r4:c597b628
>> Mär 12 12:54:55 bpi-r2 kernel:  tpt_trig_timer from
>> call_timer_fn+0x48/0x168
>> Mär 12 12:54:55 bpi-r2 kernel:  r6:c597b628 r5:00000100 r4:c16998c0
>> Mär 12 12:54:55 bpi-r2 kernel:  call_timer_fn from
>> run_timer_softirq+0x600/0x6c8
>> Mär 12 12:54:55 bpi-r2 kernel:  r9:c16998c0 r8:00000000 r7:00000770
>> r6:00000000 r5:c1501de4 r4:c597b628
>> Mär 12 12:54:55 bpi-r2 kernel:  run_timer_softirq from
>> __do_softirq+0x140/0x34c
>> Mär 12 12:54:55 bpi-r2 kernel:  r10:00000082 r9:00000100 r8:c1698481
>> r7:c1698f60 r6:00000001 r5:00000002
>> Mär 12 12:54:55 bpi-r2 kernel:  r4:c1503084
>> Mär 12 12:54:55 bpi-r2 kernel:  __do_softirq from irq_exit+0xb8/0xe8
>> Mär 12 12:54:55 bpi-r2 kernel:  r10:10c5387d r9:c1508fc0 r8:c1698481
>> r7:c1501f0c r6:00000000 r5:c1501ed8
>> Mär 12 12:54:55 bpi-r2 kernel:  r4:c14aaf58
>> Mär 12 12:54:55 bpi-r2 kernel:  irq_exit from
>> generic_handle_arch_irq+0x48/0x4c
>> Mär 12 12:54:55 bpi-r2 kernel:  r5:c1501ed8 r4:c14aaf58
>> Mär 12 12:54:55 bpi-r2 kernel:  generic_handle_arch_irq from
>> __irq_svc+0x88/0xb0
>> Mär 12 12:54:55 bpi-r2 kernel: Exception stack(0xc1501ed8 to 0xc1501f20)
>> Mär 12 12:54:55 bpi-r2 kernel: 1ec0:
>>                    000862f4 2d8f2000
>> Mär 12 12:54:55 bpi-r2 kernel: 1ee0: c1508fc0 00000000 c1699cc0 c1504f10
>> c1504f70 00000001 c1698481 c123a9b4
>> Mär 12 12:54:55 bpi-r2 kernel: 1f00: 10c5387d c1501f3c 00000001 c1501f28
>> c0e36fa0 c0e3767c 600f0013 ffffffff
>> Mär 12 12:54:55 bpi-r2 kernel:  r7:c1501f0c r6:ffffffff r5:600f0013
>> r4:c0e3767c
>> Mär 12 12:54:55 bpi-r2 kernel:  default_idle_call from do_idle+0xc4/0x124
>> Mär 12 12:54:55 bpi-r2 kernel:  r5:c1504f10 r4:00000001
>> Mär 12 12:54:55 bpi-r2 kernel:  do_idle from cpu_startup_entry+0x28/0x2c
>> Mär 12 12:54:55 bpi-r2 kernel:  r9:efffcd40 r8:00000000 r7:00000045
>> r6:c1326068 r5:c16fb9b8 r4:000000ec
>> Mär 12 12:54:55 bpi-r2 kernel:  cpu_startup_entry from rest_init+0xc0/0xc4
>> Mär 12 12:54:55 bpi-r2 kernel:  rest_init from
>> arch_post_acpi_subsys_init+0x0/0x30
>> Mär 12 12:54:55 bpi-r2 kernel:  r5:c16fb9b8 r4:c16cc038
>> Mär 12 12:54:55 bpi-r2 kernel:  arch_call_rest_init from
>> start_kernel+0x6c0/0x704
>> Mär 12 12:54:55 bpi-r2 kernel:  start_kernel from 0x0
>> Mär 12 12:54:55 bpi-r2 kernel: ------------[ cut here ]------------
>
> 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 v5.19..v6.0
> #regzbot title led: kernel bug when setting trigger to "phy0tpt"
> #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.

Re: kernel error at led trigger "phy0tpt"

[Bagas Sanjaya]

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@collabora.com
>     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.

-- 
An old man doll... just what I always wanted! - Clara

Re: kernel error at led trigger "phy0tpt"

[AngeloGioacchino Del Regno]

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@collabora.com
>>      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

Re: kernel error at led trigger "phy0tpt"

[Linux regression tracking (Thorsten Leemhuis)]

[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.

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@collabora.com
>>>      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
> 
> 

Re: kernel error at led trigger "phy0tpt"

[Thorsten Leemhuis]

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@collabora.com
>>>>      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
>>
>>

Re: kernel error at led trigger "phy0tpt"

[Thorsten Leemhuis]

On 22.05.23 10:17, Thorsten Leemhuis wrote:
> 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.

#regzbot inconclusive: it seems nobody (including the reporters) does
care anymore
#regzbot ignore-activity

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.

> Or was progress made and I just missed it?
> 
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>
>> 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@collabora.com
>>>>>      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
>>>
>>>