[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <3cd2ef19-f902-4493-ad90-00c410aca176@app.fastmail.com>
Date: Thu, 30 Mar 2023 18:00:41 +1000
From: Alistair <alistair@...stair23.me>
To: "Sebastian Reichel" <sebastian.reichel@...labora.com>,
"Linus Walleij" <linus.walleij@...aro.org>
Cc: ye.xingchen@....com.cn, pali@...nel.org, sravanhome@...il.com,
linux-pm@...r.kernel.org,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: power_supply_show_property Kernel Oops
On Thu, 30 Mar 2023, at 8:47 AM, Sebastian Reichel wrote:
> Hi,
>
> On Wed, Mar 29, 2023 at 04:43:19PM +0200, Linus Walleij wrote:
> > On Wed, Mar 29, 2023 at 1:16 PM Alistair <alistair@...stair23.me> wrote:
> >
> > > [ 2.466136] string from vsnprintf+0x158/0x424
> > > [ 2.470603] vsnprintf from vscnprintf+0x10/0x24
> > > [ 2.475241] vscnprintf from sysfs_emit+0x50/0xac
> > > [ 2.479975] sysfs_emit from power_supply_show_property+0x1d0/0x26c
> > > [ 2.486269] power_supply_show_property from add_prop_uevent+0x30/0x8c
> > > [ 2.492815] add_prop_uevent from power_supply_uevent+0xb4/0xe4
> > > [ 2.498753] power_supply_uevent from dev_uevent+0xc4/0x21c
> > > [ 2.504352] dev_uevent from kobject_uevent_env+0x1cc/0x510
> > > [ 2.509953] kobject_uevent_env from power_supply_changed_work+0x7c/0xb4
> > > [ 2.516675] power_supply_changed_work from process_one_work+0x1e8/0x3e8
> > > [ 2.523396] process_one_work from worker_thread+0x2c/0x504
> > > [ 2.528986] worker_thread from kthread+0xcc/0xec
> > > [ 2.533716] kthread from ret_from_fork+0x14/0x24
> > > [ 2.538443] Exception stack(0xf0dadfb0 to 0xf0dadff8)
> >
> > This looks like running a worker before something this worker is
> > accessing has been set up.
> >
> > > As it's on a consumer device I don't have a way to connect a debugger. So I'm
> > > a little stuck on what the problem is. The only related change I see between
> > > 6.2 and 6.3-rc4 is commit a441f3b90a340e5c94df36c33fb7000193ee0aa7
> > > "power: supply: use sysfs_emit() instead of sprintf() for sysfs show()", but
> > > that doesn't look like it would cause this oops.
> >
> > Did you try reverting it?
>
> Does not look like a race condition with a worker to me. The patch
> adds a couple of properties to the power-supply in an incorrect way.
Thanks for that.
It appears that these two drivers cause the problem:
https://github.com/alistair23/linux/blob/rM2-mainline/drivers/power/supply/max77818-charger.c
https://github.com/alistair23/linux/blob/rM2-mainline/drivers/regulator/max77818-regulator.c
as removing those two fixes the oops.
> I did not look deeply, but it's at least missing an update to
> power_supply_attrs. I guess you were 'lucky' that it did not crash
> with v6.2.
Do you mind pointing to an example that does this correctly? I don't see
anything obviously wrong compared to the in-tree max* drivers.
Anything to help point me in the right direction would be greatly
appreciated :)
>
> None of the extra properties are acceptable upstream btw.:
>
> POWER_SUPPLY_PROP_CURRENT_MAX2:
> The driver seems to use CURRENT_MAX2 for input current;
> POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT should be used for that
>
> POWER_SUPPLY_PROP_CHARGER_MODE:
> OTG should be handled via a regulator
>
> POWER_SUPPLY_PROP_STATUS_EX:
> Use extcon for connectors
Thanks! I figured as much. These are just taken from the vendor tree, I need to
clean everything up for upstreaming. I just wanted to have a working base point
to start.
>
> Greetings,
>
> -- Sebastian
>
>
> *Attachments:*
> • signature.asc
Powered by blists - more mailing lists