linux-kernel - Re: [PATCH RFC 1/2] hwmon: (sy7636a) fix races during probe of mfd subdevices

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]

Message-ID: <20250920233307.0c425863@kemnade.info>
Date: Sat, 20 Sep 2025 23:33:07 +0200
From: Andreas Kemnade <andreas@...nade.info>
To: Mark Brown <broonie@...nel.org>
Cc: jdelvare@...e.com, linux@...ck-us.net, lgirdwood@...il.com,
 linux-hwmon@...r.kernel.org, linux-kernel@...r.kernel.org, Alistair Francis
 <alistair@...stair23.me>
Subject: Re: [PATCH RFC 1/2] hwmon: (sy7636a) fix races during probe of mfd
 subdevices

On Sat, 20 Sep 2025 20:58:07 +0100
Mark Brown <broonie@...nel.org> wrote:

> On Sat, Sep 20, 2025 at 01:43:10PM +0200, Andreas Kemnade wrote:
> > If regulator subdevice is not ready early enough, devm_regulator_get will
> > get a dummy regulator device, not the real one needed from the regulator
> > subdevice, so defer probe in such case.
> > devm_regulator_get_optional returns an error in that case.
> > 
> > That fixes things, but looks odd, therefore RFC.  
> 
> No, this is buggy and broken.  You should only use _optional for
> supplies that are optional, the clue is in the name.  You need to fix
> whatever is causing the device to be instantiated to ensure that the
> regulators for the device are described before it tries to instnatiate
> the device.  Normally this is all part of a unified firmware
> description.

Just for learning, yes, it is an abuse of the _optional for non-optional
things, so a dirty hack which should not go in, therefore RFC. But what
happens more than having the hwmon device endlessly deferred at worst?

The wanted regulator is the one defined in sy7636a-regulator.c. So it
is all an issue internal to the sy7636a.
  
Both subdevices are instantiated via drivers/simple-mfd-i2c.c.
I see several other solutions:
a) call device_is_bound() on every other children of dev->parent, if not
bound defer.
b) do not care about the regulator api at all, just check whether
   the corresponding bit is set before reading temperature, return
   -ENODATA if not, some mutex is probably needed.
c) do not care about the regulator api at all, just set the
   corresponding bit (together with some mutex locking and counting).
d) copy the of_node pointer from the parent, add a regulator phandle property
   to the node pointing to the regulator in the node itself.
   That sounds like your idea but is against the current dt binding for
   this device and afaik it is uncommon to have mfd-internal things wired
   up this way

e) something clean, simple I miss

Regards,
Andreas