[Letux-kernel] [PATCH v3 0/8] OMAP3: convert opp-v1 to opp-v2 and read speed binned / 720MHz grade bits

H. Nikolaus Schaller hns at goldelico.com
Sat Nov 9 07:12:22 CET 2019

Hi Adam,

> Am 08.11.2019 um 21:08 schrieb Adam Ford <aford173 at gmail.com>:
> Nikolaus,
> I am getting some notices sent to me when I apply your series.  It
> works, but I want to clean up the notice.  Can you suggest what might
> cause this:
>     debugfs: Directory 'cpu0-cpu0' with parent
> '48070000.i2c:twl at 48:regulator-vdd1-VDD1' already present!
> It wasn't present before your series.  It's not a big deal, but I'd
> like to quiet down the messages if I can.
> Thanks.

I have checked and can also see this message - and it should be removed.

There is a debugfs node at:

/sys/kernel/debug/regulator/48070000.i2c:twl at 48:regulator-vdd1-VDD1/cpu0-cpu0

OMAP5 also has a similar node but no such debugfs warning:


So what I suspect is some bug in the twl4030 regulator driver which is
just revealed by my patch series for the first time.

Could it be that the debugfs node is created and not cleaned up by deferred

But this is not explicitly done in drivers/regulator/twl-regulator.c

BTW: twl6030 and palmas (twl6037) have separate driver, so that mentioning
twl6030 in the comments in drivers/regulator/twl-regulator.c may be wrong.
It also mentions some "TW5030" which I have never heard of.

To find out the call sequence I added a dump_stack to start_creating()
after the error message is printed:

[    2.289947] debugfs: Directory 'cpu0-cpu0' with parent '48070000.i2c:twl at 48:regulator-vdd1-VDD1' already present!
[    2.301727] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.4.0-rc6-letux+ #1329
[    2.309112] Hardware name: Generic OMAP36xx (Flattened Device Tree)
[    2.315734] [<c0110028>] (unwind_backtrace) from [<c010b60c>] (show_stack+0x10/0x14)
[    2.323852] [<c010b60c>] (show_stack) from [<c07b9b60>] (dump_stack+0x7c/0x9c)
[    2.331420] [<c07b9b60>] (dump_stack) from [<c0373588>] (start_creating+0xa8/0x104)
[    2.339477] [<c0373588>] (start_creating) from [<c0373fb0>] (debugfs_create_dir+0xc/0xc0)
[    2.348052] [<c0373fb0>] (debugfs_create_dir) from [<c04e96e0>] (create_regulator+0xd0/0x1c8)
[    2.356994] [<c04e96e0>] (create_regulator) from [<c04ec608>] (_regulator_get+0x190/0x224)
[    2.365661] [<c04ec608>] (_regulator_get) from [<c06653d0>] (dt_cpufreq_probe+0x80/0x108)
[    2.374237] [<c06653d0>] (dt_cpufreq_probe) from [<c053e018>] (platform_drv_probe+0x48/0x98)
[    2.383087] [<c053e018>] (platform_drv_probe) from [<c053c3a8>] (really_probe+0x164/0x324)
[    2.391754] [<c053c3a8>] (really_probe) from [<c053c7b8>] (driver_probe_device+0x10c/0x154)
[    2.400512] [<c053c7b8>] (driver_probe_device) from [<c053a9f4>] (bus_for_each_drv+0x90/0xb8)
[    2.409423] [<c053a9f4>] (bus_for_each_drv) from [<c053c5f8>] (__device_attach+0x90/0x120)
[    2.418090] [<c053c5f8>] (__device_attach) from [<c053b628>] (bus_probe_device+0x28/0x80)
[    2.426666] [<c053b628>] (bus_probe_device) from [<c05393ec>] (device_add+0x2f0/0x55c)
[    2.434967] [<c05393ec>] (device_add) from [<c053decc>] (platform_device_add+0x12c/0x1b8)
[    2.443542] [<c053decc>] (platform_device_add) from [<c053e954>] (platform_device_register_full+0xec/0x13c)
[    2.453765] [<c053e954>] (platform_device_register_full) from [<c0665ff4>] (ti_cpufreq_probe+0x298/0x2fc)
[    2.463775] [<c0665ff4>] (ti_cpufreq_probe) from [<c053e018>] (platform_drv_probe+0x48/0x98)
[    2.472625] [<c053e018>] (platform_drv_probe) from [<c053c3a8>] (really_probe+0x164/0x324)
[    2.481292] [<c053c3a8>] (really_probe) from [<c053c7b8>] (driver_probe_device+0x10c/0x154)
[    2.490051] [<c053c7b8>] (driver_probe_device) from [<c053a9f4>] (bus_for_each_drv+0x90/0xb8)
[    2.498992] [<c053a9f4>] (bus_for_each_drv) from [<c053c5f8>] (__device_attach+0x90/0x120)
[    2.507629] [<c053c5f8>] (__device_attach) from [<c053b628>] (bus_probe_device+0x28/0x80)
[    2.516204] [<c053b628>] (bus_probe_device) from [<c05393ec>] (device_add+0x2f0/0x55c)
[    2.524505] [<c05393ec>] (device_add) from [<c053decc>] (platform_device_add+0x12c/0x1b8)
[    2.533081] [<c053decc>] (platform_device_add) from [<c053e954>] (platform_device_register_full+0xec/0x13c)
[    2.543304] [<c053e954>] (platform_device_register_full) from [<c0665d2c>] (ti_cpufreq_init+0x78/0xa8)
[    2.553039] [<c0665d2c>] (ti_cpufreq_init) from [<c0102ed8>] (do_one_initcall+0xb4/0x268)
[    2.561645] [<c0102ed8>] (do_one_initcall) from [<c0b00fe4>] (kernel_init_freeable+0x11c/0x1ec)
[    2.570770] [<c0b00fe4>] (kernel_init_freeable) from [<c07cf1c8>] (kernel_init+0x8/0x110)
[    2.579345] [<c07cf1c8>] (kernel_init) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
[    2.587249] Exception stack(0xde0b1fb0 to 0xde0b1ff8)
[    2.592559] 1fa0:                                     00000000 00000000 00000000 00000000
[    2.601135] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    2.609680] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000

So the problem seems to be that ti_cpufreq_probe() tries to register the regulators
"vdd" and "vbb" without properly checking if they have been registered elsewhere.

The second attempt to create the debugfs directory seems to come from resources_available()
which thinks that it has to create the regulator (again) [around line 1935 in drivers/regulator/core.c].

Hope this helps, although I have no idea why the vdd regulator already exists at that point.


More information about the Letux-kernel mailing list