This series adds devicetree support for drivers/regulator/virtual.c which is
useful for development and testing of regulator drivers.
v2:
- Only use the "default" supply name if dt
- Add a comment explaining the "default" supply name
- Add patch which warns against production use of this driver
- Add patch to use dev_err_probe
Vincent Whitchurch (3):
regulator: virtual: use dev_err_probe()
regulator: virtual: warn against production use
regulator: virtual: add devicetree support
drivers/regulator/virtual.c | 41 +++++++++++++++++++++++++++++++------
1 file changed, 35 insertions(+), 6 deletions(-)
--
2.34.1
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 without patching the kernel. 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 <[email protected]>
---
Notes:
v2:
- Only use the "default" supply name if dt
- Add a comment explaining the "default" supply name
drivers/regulator/virtual.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/regulator/virtual.c b/drivers/regulator/virtual.c
index 9e0abbee1df5..5d32628a5011 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);
@@ -305,6 +314,14 @@ static int regulator_virtual_probe(struct platform_device *pdev)
if (drvdata == NULL)
return -ENOMEM;
+ /*
+ * This virtual consumer does not have any hardware-defined supply
+ * name, so just allow the regulator to be specified in a property
+ * named "default-supply" when we're being probed from devicetree.
+ */
+ if (!reg_id && pdev->dev.of_node)
+ reg_id = "default";
+
mutex_init(&drvdata->lock);
drvdata->regulator = devm_regulator_get(&pdev->dev, reg_id);
@@ -345,6 +362,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
On Tue, 1 Mar 2022 12:18:28 +0100, Vincent Whitchurch wrote:
> This series adds devicetree support for drivers/regulator/virtual.c which is
> useful for development and testing of regulator drivers.
>
> v2:
> - Only use the "default" supply name if dt
> - Add a comment explaining the "default" supply name
> - Add patch which warns against production use of this driver
> - Add patch to use dev_err_probe
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
Thanks!
[1/3] regulator: virtual: use dev_err_probe()
commit: 75c3543e39f0c94644eac5965b3efe50c2c5c39d
[2/3] regulator: virtual: warn against production use
commit: d2fb5487ecb2a28b61ff261ae18488afc98d24a6
[3/3] regulator: virtual: add devicetree support
commit: 80c056656d46ffbece6125dee3f25adbc36d1486
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark