[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220228155027.GA16152@axis.com>
Date: Mon, 28 Feb 2022 16:50:27 +0100
From: Vincent Whitchurch <vincent.whitchurch@...s.com>
To: Mark Brown <broonie@...nel.org>
CC: Liam Girdwood <lgirdwood@...il.com>, <kernel@...s.com>,
<devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] regulator: virtual: add devicetree support
On Wed, Feb 23, 2022 at 02:23:16PM +0000, Mark Brown wrote:
> On Fri, Feb 18, 2022 at 12:06:03PM +0100, Vincent Whitchurch wrote:
>
> > The reg-virt-consumer is very useful for development and testing of
> > regulator drivers since it allows voltages and modes to be set from
> > userspace. However, it currently requires platform data so it cannot be
> > used on modern platforms. Add support for probing it from the
> > devicetree to remedy this.
>
> Meh, you can add a bit of code on module_init() to register a platform
> device or something.
Something like that could work during manual testing, but I'm hoping to
use this from a test framework where it's rather impractical to patch
individual drivers in that way.
> > Since this driver is only meant for testing and is a purely software
> > construct, no binding documentation is added.
>
> That's not going to stop anyone. We should at the very least be
> printing very loud warnings if anyone tries to intantiate this.
I can add a warning. Maybe something like this, following the style of
kernel/trace/trace.c?
pr_warn("**********************************************************\n");
pr_warn("** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **\n");
pr_warn("** **\n");
pr_warn("** regulator-virtual-consumer is only for testing and **\n");
pr_warn("** debugging. Do not use it in a production kernel. **\n");
pr_warn("** **\n");
pr_warn("** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **\n");
pr_warn("**********************************************************\n");
>
> > + if (!reg_id)
> > + reg_id = "default";
> > +
>
> Oh?
As you know, this results in looking for the regulator phandle in a
property named "default-supply". I wasn't sure what supply name to use
for this virtual client. Getting the name from another property seemed
unnecessary. Would you prefer that, or would you suggest some other
name than "default"?
Powered by blists - more mailing lists