linux-kernel - Re: Probe regression of efuse@...10000 on mt8183-kukui-jacuzzi-juniper-sku16 running next-20240202

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 8 Mar 2024 09:31:52 -0500
From: Nícolas F. R. A. Prado <nfraprado@...labora.com>
To: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
	Matthias Brugger <matthias.bgg@...il.com>,
	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
	Chen-Yu Tsai <wenst@...omium.org>
Cc: regressions@...ts.linux.dev, linux-mediatek@...ts.infradead.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	kernel@...labora.com
Subject: Re: Probe regression of efuse@...10000 on
 mt8183-kukui-jacuzzi-juniper-sku16 running next-20240202

On Tue, Feb 06, 2024 at 11:11:00AM -0500, Nícolas F. R. A. Prado wrote:
> Hi,
> 
> KernelCI has identified a regression [1] on the
> mt8183-kukui-jacuzzi-juniper-sku16 machine running on next-20240202 compared to
> next-20240118:
> 
> <4>[    0.627077] sysfs: cannot create duplicate filename '/bus/nvmem/devices/mtk-efuse0'
> <4>[    0.634945] CPU: 7 PID: 1 Comm: swapper/0 Not tainted 6.8.0-rc2-next-20240202 #1
> <4>[    0.642542] Hardware name: Google juniper sku16 board (DT)
> <4>[    0.648237] Call trace:
> <4>[    0.650917]  dump_backtrace+0x94/0xec
> <4>[    0.654815]  show_stack+0x18/0x24
> <4>[    0.658359]  dump_stack_lvl+0x48/0x60
> <4>[    0.662252]  dump_stack+0x18/0x24
> <4>[    0.665796]  sysfs_warn_dup+0x64/0x80
> <4>[    0.669688]  sysfs_do_create_link_sd+0xf0/0xf8
> <4>[    0.674353]  sysfs_create_link+0x20/0x40
> <4>[    0.678500]  bus_add_device+0x64/0x104
> <4>[    0.682475]  device_add+0x33c/0x778
> <4>[    0.686193]  nvmem_register+0x514/0x714
> <4>[    0.690256]  devm_nvmem_register+0x1c/0x6c
> <4>[    0.694577]  mtk_efuse_probe+0xe8/0x170
> <4>[    0.698637]  platform_probe+0x68/0xd8
> <4>[    0.702525]  really_probe+0x148/0x2b4
> <4>[    0.706413]  __driver_probe_device+0x78/0x12c
> <4>[    0.710990]  driver_probe_device+0xdc/0x160
> <4>[    0.715394]  __driver_attach+0x94/0x19c
> <4>[    0.719453]  bus_for_each_dev+0x74/0xd4
> <4>[    0.723512]  driver_attach+0x24/0x30
> <4>[    0.727312]  bus_add_driver+0xe4/0x1e8
> <4>[    0.731284]  driver_register+0x60/0x128
> <4>[    0.735343]  __platform_driver_register+0x28/0x34
> <4>[    0.740265]  mtk_efuse_init+0x20/0x5c
> <4>[    0.744155]  do_one_initcall+0x6c/0x1b0
> <4>[    0.748214]  kernel_init_freeable+0x1c8/0x290
> <4>[    0.752795]  kernel_init+0x20/0x1dc
> <4>[    0.756512]  ret_from_fork+0x10/0x20
> <4>[    0.760353] mediatek,efuse: probe of 11f10000.efuse failed with error -17
> 
> This efuse probe failure causes the probe failure of other components that
> depend on it, including the display pipeline:
> 
> /soc/dsi-phy@...50000
> /soc/dsi@...14000
> /soc/efuse@...10000
> /soc/i2c@...08000/anx7625@58
> /soc/i2c@...08000/anx7625@...aux-bus/panel
> /soc/thermal@...0b000
> 
> There is a series already addressing the issue [2]. The first two patches have
> been merged into the mediatek tree, but that tree isn't currently being
> integrated into linux-next. Besides that, patch 3 hasn't been merged into the
> nvmem tree yet, and it is required in order to solve the issue.
> 
> I'm sending this regression report so we can properly track the regression while
> the fixes don't land on linux-next.
> 
> Thanks,
> Nícolas
> 
> [1] https://linux.kernelci.org/test/plan/id/65bd63c3f12d8a95e200a225/
> [2] https://lore.kernel.org/linux-mediatek/20240130095656.3712469-1-wenst@chromium.org/
> 
> #regzbot introduced next-20240118..next-20240202

Not sure why this got filed by regzbot under the mainline tab rather than next.
Maybe it was the missing collon? Let me try again:

#regzbot introduced: next-20240118..next-20240202

In any case, the fix has already made it to linux-next, so this should close the
regression:

#regzbot fix: nvmem: mtk-efuse: Drop NVMEM device name

Thanks,
Nícolas