[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160407235431.788dc24a@bbrezillon>
Date: Thu, 7 Apr 2016 23:54:31 +0200
From: Boris Brezillon <boris.brezillon@...e-electrons.com>
To: Mark Brown <broonie@...nel.org>
Cc: Thierry Reding <thierry.reding@...il.com>,
linux-pwm@...r.kernel.org,
Mike Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...eaurora.org>, linux-clk@...r.kernel.org,
Liam Girdwood <lgirdwood@...il.com>,
Kamil Debski <k.debski@...sung.com>, lm-sensors@...sensors.org,
Jean Delvare <jdelvare@...e.com>,
Guenter Roeck <linux@...ck-us.net>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
linux-input@...r.kernel.org, Bryan Wu <cooloney@...il.com>,
Richard Purdie <rpurdie@...ys.net>,
Jacek Anaszewski <j.anaszewski@...sung.com>,
linux-leds@...r.kernel.org,
Maxime Ripard <maxime.ripard@...e-electrons.com>,
Chen-Yu Tsai <wens@...e.org>, linux-sunxi@...glegroups.com,
Joachim Eastwood <manabian@...il.com>,
Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
Heiko Stuebner <heiko@...ech.de>,
linux-rockchip@...ts.infradead.org,
Jingoo Han <jingoohan1@...il.com>,
Lee Jones <lee.jones@...aro.org>, linux-fbdev@...r.kernel.org,
Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>,
Tomi Valkeinen <tomi.valkeinen@...com>,
Robert Jarzmik <robert.jarzmik@...e.fr>,
Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
Kukjin Kim <kgene@...nel.org>,
Krzysztof Kozlowski <k.kozlowski@...sung.com>,
linux-samsung-soc@...r.kernel.org, intel-gfx@...ts.freedesktop.org,
Daniel Vetter <daniel.vetter@...el.com>,
Jani Nikula <jani.nikula@...ux.intel.com>,
Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org,
David Airlie <airlied@...ux.ie>,
Daniel Vetter <daniel@...ll.ch>,
dri-devel@...ts.freedesktop.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Hartley Sweeten <hsweeten@...ionengravers.com>,
Ryan Mallon <rmallon@...il.com>,
Alexander Shiyan <shc_work@...l.ru>,
Milo Kim <milo.kim@...com>,
Stephen Barber <smbarber@...omium.org>
Subject: Re: [PATCH v5 30/46] regulator: pwm: retrieve correct voltage
Hi Mark,
On Wed, 30 Mar 2016 14:24:10 -0700
Mark Brown <broonie@...nel.org> wrote:
> On Wed, Mar 30, 2016 at 10:03:53PM +0200, Boris Brezillon wrote:
> > The continuous PWM voltage regulator is caching the voltage value in
> > the ->volt_uV field. While most of the time this value should reflect the
> > real voltage, sometime it can be sightly different if the PWM device
> > rounded the set_duty_cycle request.
> > Moreover, this value is not valid until someone has modified the regulator
> > output.
>
> Acked-by: Mark Brown <broonie@...nel.org>
Actually this patch introduces a bug (reported by Stephen):
"
I applied your patch series [PATCH v5 00/46] pwm: add support for
atomic update and found a null pointer dereference when probing a
pwm-regulator at boot. See the below stack trace:
[ 4.282374] [<ffffffc000399088>] pwm_regulator_get_voltage+0x78/0xa0
[ 4.289344] [<ffffffc000390740>] regulator_attr_is_visible+0x7c/0x264
[ 4.296408] [<ffffffc0001f75a0>] internal_create_group+0x14c/0x280
[ 4.303184] [<ffffffc0001f76e8>] sysfs_create_group+0x14/0x1c
[ 4.309483] [<ffffffc0001f77c8>] sysfs_create_groups+0x30/0x78
[ 4.315881] [<ffffffc00043631c>] device_add+0x224/0x4d8
[ 4.321609] [<ffffffc0004365ec>] device_register+0x1c/0x28
[ 4.327623] [<ffffffc0003952a4>] regulator_register+0x2e4/0xc14
[ 4.334112] [<ffffffc000396844>] devm_regulator_register+0x54/0x94
[ 4.340887] [<ffffffc000399328>] pwm_regulator_probe+0x278/0x2b8
[ 4.347473] [<ffffffc000439fe4>] platform_drv_probe+0x58/0xa4
[ 4.353772] [<ffffffc0004387a8>] driver_probe_device+0x114/0x2ac
[ 4.360358] [<ffffffc0004389a4>] __driver_attach+0x64/0x90
[ 4.366371] [<ffffffc000436f50>] bus_for_each_dev+0x74/0x90
[ 4.372478] [<ffffffc000438bd4>] driver_attach+0x20/0x28
[ 4.378299] [<ffffffc00043778c>] bus_add_driver+0xe8/0x1e0
[ 4.384312] [<ffffffc00043959c>] driver_register+0x98/0xe4
[ 4.390326] [<ffffffc00043aa04>] __platform_driver_register+0x48/0x50
[ 4.397388] [<ffffffc000cb2710>] pwm_regulator_driver_init+0x18/0x20
[ 4.404356] [<ffffffc000c8ca7c>] do_one_initcall+0xf8/0x180
[ 4.410466] [<ffffffc000c8cc58>] kernel_init_freeable+0x154/0x1f4
[ 4.417148] [<ffffffc000929cf4>] kernel_init+0x10/0xf8
[ 4.422782] [<ffffffc000084450>] ret_from_fork+0x10/0x40
It looks like the root cause is that regulator_attr_is_visible will
try to get the voltage, but at this point in regulator_register,
rdev->constraints is still null. So
pwm_duty_cycle_percentage_to_voltage will dereference a null
rdev->constraints pointer.
"
The problem is that we need to know the min and max voltage constraints
to calculate the current voltage. ->get_voltage() is called when the
sysfs attributes are created (part of device registration), and
set_machine_constraints() is called after device_register(), thus
leading to the NULL pointer dereference.
Is there any reason for calling set_machine_constraints() after
device_register() in regulator_register()?
Best Regards,
Boris
Powered by blists - more mailing lists