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] [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

Powered by Openwall GNU/*/Linux Powered by OpenVZ