linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] regulator: virtual: add devicetree support
@ 2022-02-18 11:06 Vincent Whitchurch
  2022-02-23 14:23 ` Mark Brown
  0 siblings, 1 reply; 4+ messages in thread
From: Vincent Whitchurch @ 2022-02-18 11:06 UTC (permalink / raw)
  To: Liam Girdwood, Mark Brown
  Cc: kernel, devicetree, Vincent Whitchurch, linux-kernel

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.

Since this driver is only meant for testing and is a purely software
construct, no binding documentation is added.

Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
---
 drivers/regulator/virtual.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/regulator/virtual.c b/drivers/regulator/virtual.c
index 52c5a0e0acd8..c4d56b484ed5 100644
--- a/drivers/regulator/virtual.c
+++ b/drivers/regulator/virtual.c
@@ -13,6 +13,7 @@
 #include <linux/regulator/consumer.h>
 #include <linux/slab.h>
 #include <linux/module.h>
+#include <linux/of.h>
 
 struct virtual_consumer_data {
 	struct mutex lock;
@@ -281,6 +282,14 @@ static const struct attribute_group regulator_virtual_attr_group = {
 	.attrs	= regulator_virtual_attributes,
 };
 
+#ifdef CONFIG_OF
+static const struct of_device_id regulator_virtual_consumer_of_match[] = {
+	{ .compatible = "regulator-virtual-consumer" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, regulator_virtual_consumer_of_match);
+#endif
+
 static int regulator_virtual_probe(struct platform_device *pdev)
 {
 	char *reg_id = dev_get_platdata(&pdev->dev);
@@ -292,6 +301,9 @@ static int regulator_virtual_probe(struct platform_device *pdev)
 	if (drvdata == NULL)
 		return -ENOMEM;
 
+	if (!reg_id)
+		reg_id = "default";
+
 	mutex_init(&drvdata->lock);
 
 	drvdata->regulator = devm_regulator_get(&pdev->dev, reg_id);
@@ -334,6 +346,7 @@ static struct platform_driver regulator_virtual_consumer_driver = {
 	.remove		= regulator_virtual_remove,
 	.driver		= {
 		.name		= "reg-virt-consumer",
+		.of_match_table = of_match_ptr(regulator_virtual_consumer_of_match),
 	},
 };
 
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] regulator: virtual: add devicetree support
  2022-02-18 11:06 [PATCH] regulator: virtual: add devicetree support Vincent Whitchurch
@ 2022-02-23 14:23 ` Mark Brown
  2022-02-28 15:50   ` Vincent Whitchurch
  0 siblings, 1 reply; 4+ messages in thread
From: Mark Brown @ 2022-02-23 14:23 UTC (permalink / raw)
  To: Vincent Whitchurch; +Cc: Liam Girdwood, kernel, devicetree, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 773 bytes --]

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.

> 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.

> +	if (!reg_id)
> +		reg_id = "default";
> +

Oh?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] regulator: virtual: add devicetree support
  2022-02-23 14:23 ` Mark Brown
@ 2022-02-28 15:50   ` Vincent Whitchurch
  2022-02-28 15:55     ` Mark Brown
  0 siblings, 1 reply; 4+ messages in thread
From: Vincent Whitchurch @ 2022-02-28 15:50 UTC (permalink / raw)
  To: Mark Brown; +Cc: Liam Girdwood, kernel, devicetree, linux-kernel

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"?

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] regulator: virtual: add devicetree support
  2022-02-28 15:50   ` Vincent Whitchurch
@ 2022-02-28 15:55     ` Mark Brown
  0 siblings, 0 replies; 4+ messages in thread
From: Mark Brown @ 2022-02-28 15:55 UTC (permalink / raw)
  To: Vincent Whitchurch; +Cc: Liam Girdwood, kernel, devicetree, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]

On Mon, Feb 28, 2022 at 04:50:27PM +0100, Vincent Whitchurch wrote:
> On Wed, Feb 23, 2022 at 02:23:16PM +0000, Mark Brown wrote:

> > 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");

Something along those lines would do it, yes.

> > > +	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"?

I'd suggest adding a comment.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-02-28 15:55 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-18 11:06 [PATCH] regulator: virtual: add devicetree support Vincent Whitchurch
2022-02-23 14:23 ` Mark Brown
2022-02-28 15:50   ` Vincent Whitchurch
2022-02-28 15:55     ` Mark Brown

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).