[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4945392.OV4Wx5bFTl@zbook-studio-g3>
Date: Mon, 10 Mar 2025 19:22:24 +0100
From: Christian Eggers <ceggers@....de>
To: Christian Eggers <ceggers@...i.de>, Mark Brown <broonie@...nel.org>
Cc: Liam Girdwood <lgirdwood@...il.com>,
Douglas Anderson <dianders@...omium.org>, linux-kernel@...r.kernel.org,
stable@...r.kernel.org
Subject:
Re: [PATCH 2/2] regulator: assert that dummy regulator has been probed before
using it
Am Montag, 10. März 2025, 18:23:02 CET schrieb Mark Brown:
> On Mon, Mar 10, 2025 at 05:33:02PM +0100, Christian Eggers wrote:
> > Due to asynchronous driver probing there is a chance that the dummy
> > regulator hasn't already been probed when first accessing it.
> >
> > if (have_full_constraints()) {
> >
> > r = dummy_regulator_rdev;
> >
> > + BUG_ON(!r);
> >
> > get_device(&r->dev);
> >
> > } else {
> >
> > dev_err(dev, "Failed to resolve %s-supply for
%s\n",
> >
> > @@ -2086,6 +2087,7 @@ static int regulator_resolve_supply(struct
> > regulator_dev *rdev)>
> > goto out;
> >
> > }
> > r = dummy_regulator_rdev;
> >
> > + BUG_ON(!r);
>
> This doesn't actually help anything
My idea was to help identifying the problem (if it is reintroduced again
later).
> I'd expect this to trigger probe deferral.
I can check for this tomorrow. But is it worth to use deferred probing
for a shared "NOP" driver which doesn't access any hardware? Or would this
only introduce overhead for nothing?
regards,
Christian
Powered by blists - more mailing lists