[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <584090e3-6833-4ec5-8c6f-ea9b2752abf7@sirena.org.uk>
Date: Thu, 23 Mar 2023 16:57:36 +0000
From: Mark Brown <broonie@...nel.org>
To: Doug Anderson <dianders@...omium.org>
Cc: Charles Keepax <ckeepax@...nsource.cirrus.com>,
Marek Szyprowski <m.szyprowski@...sung.com>,
linux-kernel@...r.kernel.org, linux-samsung-soc@...r.kernel.org,
Liam Girdwood <lgirdwood@...il.com>,
patches@...nsource.cirrus.com
Subject: Re: [PATCH] regulator: wm8994: Use PROBE_FORCE_SYNCHRONOUS
On Thu, Mar 23, 2023 at 09:53:18AM -0700, Doug Anderson wrote:
> Sorry for the breakage and thank you for the fix.
Mostly my fault, it was me asked you to do all the drivers.
> No question that a quick switch back to PROBE_FORCE_SYNCHRONOUS is the
> right first step here, but I'm wondering if there are any further
> steps we want to take.
> If my analysis is correct, there's still potential to run into similar
> problems even with PROBE_FORCE_SYNCHRONOUS. I don't think that
> mfd_add_devices() is _guaranteed_ to finish probing all the
> sub-devices by the time it returns. Specifically, imagine that
> wm8994_ldo_probe() tries to get a GPIO that that system hasn't made
> available yet. Potentially the system could return -EPROBE_DEFER there
Yes, the code isn't 100% robust. The driver was written on the basis
that we know the target systems for practical deployments are very
unlikely to have such issues and we'd deal with the potential issues if
they ever actually cropped up.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists