[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250921183536.5368d634@kemnade.info>
Date: Sun, 21 Sep 2025 18:35:36 +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 23:18:59 +0100
Mark Brown <broonie@...nel.org> wrote:
> > 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).
>
> I assume this is using the regulator API because someone might use an
> external regulator in a system design for some reason (better quality,
> power efficiency or a shared reference between multiple devices I
> guess?), or because the supply might also be used by external devices?
So just what is behind enabling the regulator:
a bit controlling two boost convertes, two ldos behind tham,
and the name-giving vcom regulator.
Enabling this bit is also required to have the temperature register
working, althogh none of the regulators is used for measurenig the
temperature.
All these regulator are designed for powering EPDs. So the
regulator API is needed. The only question is whether it might be bypassed
for internal usage (which of course needs some locking, etc.)
Regards,
Andreas
Powered by blists - more mailing lists