linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "H. Nikolaus Schaller" <hns@goldelico.com>
To: Adam Ford <aford173@gmail.com>
Cc: "Benoît Cousson" <bcousson@baylibre.com>,
	"Tony Lindgren" <tony@atomide.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"André Roth" <neolynx@gmail.com>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	"Viresh Kumar" <viresh.kumar@linaro.org>,
	"Enric Balletbo i Serra" <eballetbo@gmail.com>,
	"Javier Martinez Canillas" <javier@dowhile0.org>,
	"Roger Quadros" <rogerq@ti.com>,
	"Teresa Remmet" <t.remmet@phytec.de>,
	Linux-OMAP <linux-omap@vger.kernel.org>,
	devicetree <devicetree@vger.kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	linux-pm@vger.kernel.org,
	"Discussions about the Letux Kernel"
	<letux-kernel@openphoenux.org>,
	kernel@pyra-handheld.com,
	arm-soc <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v3 0/8] OMAP3: convert opp-v1 to opp-v2 and read speed binned / 720MHz grade bits
Date: Sat, 9 Nov 2019 07:12:22 +0100	[thread overview]
Message-ID: <4F6078BD-0759-4B47-933E-E29EE1D8AD18@goldelico.com> (raw)
In-Reply-To: <CAHCN7xLvuj_LkvOV3YG5=0MZYsohbQArE0UCZx6pcRPwM5pkYg@mail.gmail.com>

Hi Adam,

> Am 08.11.2019 um 21:08 schrieb Adam Ford <aford173@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@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@48:regulator-vdd1-VDD1/cpu0-cpu0

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

/sys/kernel/debug/regulator/smps123/cpu0-cpu0

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
probing?

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

BR,
Nikolaus




  reply	other threads:[~2019-11-09  6:12 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-11 17:47 [PATCH v3 0/8] OMAP3: convert opp-v1 to opp-v2 and read speed binned / 720MHz grade bits H. Nikolaus Schaller
2019-09-11 17:47 ` [PATCH v3 1/8] cpufreq: ti-cpufreq: add support for omap34xx and omap36xx H. Nikolaus Schaller
2019-09-11 19:05   ` Adam Ford
2019-09-11 17:47 ` [PATCH v3 2/8] ARM: dts: omap34xx & omap36xx: replace opp-v1 tables by opp-v2 for H. Nikolaus Schaller
2019-09-11 17:47 ` [PATCH v3 3/8] DTS: bindings: omap: update bindings documentation H. Nikolaus Schaller
2019-09-11 17:47 ` [PATCH v3 4/8] ARM: dts: omap3: bulk convert compatible to be explicitly ti,omap3430 or ti,omap3630 or ti,am3517 H. Nikolaus Schaller
2019-09-11 17:47 ` [PATCH v3 5/8] cpufreq: ti-cpufreq: omap36xx use "cpu0","vbb" if run in multi_regulator mode H. Nikolaus Schaller
2019-09-16 16:24   ` Tony Lindgren
2019-09-17 19:22   ` Rob Herring
2019-09-11 17:47 ` [PATCH v3 6/8] ARM: dts: omap36xx: using OPP1G needs to control the abb_ldo H. Nikolaus Schaller
2019-09-13 21:13   ` Adam Ford
2019-09-16 16:25   ` Tony Lindgren
2019-09-11 17:47 ` [PATCH v3 7/8] cpufreq: ti-cpufreq: Add support for AM3517 H. Nikolaus Schaller
2019-09-16 16:26   ` Tony Lindgren
2019-09-11 17:47 ` [PATCH v3 8/8] ARM: dts: Add OPP-V2 table " H. Nikolaus Schaller
2019-09-16 16:26   ` Tony Lindgren
2019-09-16 16:28 ` [PATCH v3 0/8] OMAP3: convert opp-v1 to opp-v2 and read speed binned / 720MHz grade bits Tony Lindgren
2019-09-17 14:35   ` H. Nikolaus Schaller
2019-10-02  5:47     ` H. Nikolaus Schaller
2019-10-02  9:00     ` Viresh Kumar
2019-10-10 10:45 ` Viresh Kumar
2019-11-08 20:08 ` Adam Ford
2019-11-09  6:12   ` H. Nikolaus Schaller [this message]
2019-11-09 10:02     ` Adam Ford

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=4F6078BD-0759-4B47-933E-E29EE1D8AD18@goldelico.com \
    --to=hns@goldelico.com \
    --cc=aford173@gmail.com \
    --cc=bcousson@baylibre.com \
    --cc=devicetree@vger.kernel.org \
    --cc=eballetbo@gmail.com \
    --cc=javier@dowhile0.org \
    --cc=kernel@pyra-handheld.com \
    --cc=letux-kernel@openphoenux.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=neolynx@gmail.com \
    --cc=rjw@rjwysocki.net \
    --cc=robh+dt@kernel.org \
    --cc=rogerq@ti.com \
    --cc=t.remmet@phytec.de \
    --cc=tony@atomide.com \
    --cc=viresh.kumar@linaro.org \
    /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).