linux-kernel - Re: [PATCH] regulator: core: Set the fwnode for regulator

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: <CAGETcx-ioF=jTbyQMeD2fsYKz8q5vw_TWYWS9m8H5=pCo5KFYA@mail.gmail.com>
Date: Thu, 11 Jul 2024 17:13:01 -0700
From: Saravana Kannan <saravanak@...gle.com>
To: Yoann Congal <yoann.congal@...le.fr>
Cc: Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] regulator: core: Set the fwnode for regulator_dev

On Thu, Jul 11, 2024 at 3:19 PM Yoann Congal <yoann.congal@...le.fr> wrote:
>
> Le 11/07/2024 à 23:29, Saravana Kannan a écrit :
> > On Thu, Jul 11, 2024 at 2:25 PM Yoann Congal <yoann.congal@...le.fr> wrote:
> >>
> >> From: Yoann Congal <yoann.congal@...le.fr>
> >>
> >> After commit 3fb16866b51d ("driver core: fw_devlink: Make cycle
> >> detection more robust"), fw_devlink prints an error when consumer
> >> devices don't have their fwnode set. This used to be ignored silently.
> >>
> >> Set the fwnode in regulator_dev so fw_devlink can find them and properly
> >> track their dependencies.
> >>
> >> This fixes errors like this:
> >>   stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Failed to create device link (0x180) with 2-0033
> >>
> >> NB: This is similar to the commit a26cc2934331 ("drm/mipi-dsi: Set the
> >> fwnode for mipi_dsi_device") applied to the regulator framework.
> >>
> >> Cc: Saravana Kannan <saravanak@...gle.com>
> >> Cc: stable@...r.kernel.org # 5.13.x
> >> Fixes: 63c7c9e16c8e ("regulator: core: Get and put regulator of_node")
> >> Signed-off-by: Yoann Congal <yoann.congal@...le.fr>
> >
> > The change is valid but the problem is that managed device links don't
> > work correctly for "class" type devices. So, we can't merge this
> > change yet.
>
> I was totally unaware of that.

Yeah, it's not obvious. The TL;DR of the problem is that your consumer
will end up waiting for ever for the supplier to probe but a "class"
device never probes.

And the fix is non-trivial. So, it's been on my todo list for a bit.

> > So, for now, we shouldn't land this. Are you not seeing probing issues
> > when you do this? Or significant changes/delays in probing?
>
> I just checked my logs : No probing issue nor noticeable delay.

With your change, I'm guessing you see more links under /sys/class/devlink

Are all the consumers in these new links "class" type consumers too
(like other regulator devices, etc)?

> Thanks for your answer, I'll drop this for now.

Thanks.

-Saravana