From: Andreas Kemnade <andreas@kemnade.info>
To: Mark Brown <broonie@kernel.org>
Cc: jdelvare@suse.com, linux@roeck-us.net, lgirdwood@gmail.com,
linux-hwmon@vger.kernel.org, linux-kernel@vger.kernel.org,
Alistair Francis <alistair@alistair23.me>
Subject: Re: [PATCH RFC 1/2] hwmon: (sy7636a) fix races during probe of mfd subdevices
Date: Sat, 20 Sep 2025 23:33:07 +0200 [thread overview]
Message-ID: <20250920233307.0c425863@kemnade.info> (raw)
In-Reply-To: <79aa98fe-b9b6-4210-a556-d33863f0129a@sirena.org.uk>
On Sat, 20 Sep 2025 20:58:07 +0100
Mark Brown <broonie@kernel.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
next prev parent reply other threads:[~2025-09-20 21:33 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-20 11:43 [PATCH 0/2] hmwon: (sy7636a) fix regulator handling Andreas Kemnade
2025-09-20 11:43 ` [PATCH RFC 1/2] hwmon: (sy7636a) fix races during probe of mfd subdevices Andreas Kemnade
2025-09-20 19:58 ` Mark Brown
2025-09-20 21:33 ` Andreas Kemnade [this message]
2025-09-20 22:18 ` Mark Brown
2025-09-21 16:35 ` Andreas Kemnade
2025-09-24 7:00 ` Andreas Kemnade
2025-09-24 7:17 ` Guenter Roeck
2025-09-24 17:53 ` Andreas Kemnade
2025-09-24 19:16 ` Guenter Roeck
2025-09-27 18:39 ` Jonathan Cameron
2025-10-27 20:12 ` Andreas Kemnade
2026-01-22 14:23 ` In-kernel hwmon read: (was: Re: [PATCH RFC 1/2] hwmon: (sy7636a) fix races during probe of mfd subdevices) Andreas Kemnade
2026-01-31 18:42 ` Jonathan Cameron
2026-02-01 16:29 ` In-kernel hwmon read: Guenter Roeck
2025-09-24 8:44 ` [PATCH RFC 1/2] hwmon: (sy7636a) fix races during probe of mfd subdevices Mark Brown
2025-10-27 11:30 ` Andreas Kemnade
2025-09-20 11:43 ` [PATCH 2/2] hwmon: (sy7636a) enable regulator only if needed Andreas Kemnade
2025-09-24 16:06 ` Guenter Roeck
2025-09-24 20:40 ` Andreas Kemnade
2025-09-24 21:06 ` Guenter Roeck
2025-09-24 21:58 ` Andreas Kemnade
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=20250920233307.0c425863@kemnade.info \
--to=andreas@kemnade.info \
--cc=alistair@alistair23.me \
--cc=broonie@kernel.org \
--cc=jdelvare@suse.com \
--cc=lgirdwood@gmail.com \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
/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
all inboxes | Powered by JetHome®