[PATCH] of: Overlay manager

[PATCH] of: Overlay manager

[dimitrysh]

 From e14eb45fa5a93c1bff8a6dfe7b6756e4ad72c579 Mon Sep 17 00:00:00 2001
From: Dmitry Shmidt <dimitrysh@google.com>
Date: Wed, 24 Aug 2016 13:25:52 -0700
Subject: [PATCH] of: Overlay manager

Overlay manager processes DT entries on demand.
It is chosen by CONFIG_OF_OVERLAY_MGR option.
These entries can be chosen from kernel command line:
overlay_mgr.overlay_dt_entry=hardware_cfg_0
DT contains main overlay_mng entry with all possible
HW config setups. And then kernel command line option
will allow to choose between them.

   Kernel DT entry:
     overlay_mgr {
         compatible = "linux,overlay_manager";
         hardware_cfg_0 {
             overlay@0 {
                     fragment@0 {
                             __overlay__ {
                             };
                     };
             };
             overlay@1 {
                     fragment@0 {
                             __overlay__ {
                             };
                     };
             };
         };
     };

Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
Tested-by: John Stultz <john.stultz@linaro.org>
Acked-by: John Stultz <john.stultz@linaro.org>
---
  .../devicetree/bindings/of/overlay_mgr.txt         | 32 ++++++++
  drivers/of/Kconfig                                 | 10 +++
  drivers/of/Makefile                                |  1 +
  drivers/of/overlay_mgr.c                           | 90  
++++++++++++++++++++++
  4 files changed, 133 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/of/overlay_mgr.txt
  create mode 100644 drivers/of/overlay_mgr.c

diff --git a/Documentation/devicetree/bindings/of/overlay_mgr.txt  
b/Documentation/devicetree/bindings/of/overlay_mgr.txt
new file mode 100644
index 0000000..5f3ce4c
--- /dev/null
+++ b/Documentation/devicetree/bindings/of/overlay_mgr.txt
@@ -0,0 +1,32 @@
+overlay_mgr
+
+Required properties:
+- compatible: "linux,overlay_manager";
+
+Optional properties:
+- starts from the word "hardware": hardware_cfg_0
+
+These properties can be chosen from kernel command line:
+overlay_mgr.overlay_dt_entry=hardware_cfg_0
+DT contains main overlay_mng entry with all possible
+HW config setups. And then kernel command line option
+will allow to choose between them.
+
+Example:
+    overlay_mgr {
+        compatible = "linux,overlay_manager";
+        hardware_cfg_0 {
+            overlay@0 {
+                    fragment@0 {
+                            __overlay__ {
+                            };
+                    };
+            };
+            overlay@1 {
+                    fragment@0 {
+                            __overlay__ {
+                            };
+                    };
+            };
+        };
+    };
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index e2a4841..e3eb06d 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -112,4 +112,14 @@ config OF_OVERLAY
  	  While this option is selected automatically when needed, you can
  	  enable it manually to improve device tree unit test coverage.

+config OF_OVERLAY_MGR
+	bool "Enable Overlay manager"
+	default n
+	depends on OF_OVERLAY
+	help
+	  Enables Overlay manager - it accepts DT entry from command line
+	  overlay_mgr.overlay_dt_entry=<name> and applies all overlays in
+	  it to current DT. It is also possible to apply predefined DT
+	  entry on the fly by writing it to 'current_overlay' sysfs entry.
+
  endif # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index 156c072..3bddd19 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -14,5 +14,6 @@ obj-$(CONFIG_OF_MTD)	+= of_mtd.o
  obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
  obj-$(CONFIG_OF_RESOLVE)  += resolver.o
  obj-$(CONFIG_OF_OVERLAY) += overlay.o
+obj-$(CONFIG_OF_OVERLAY_MGR) += overlay_mgr.o

  obj-$(CONFIG_OF_UNITTEST) += unittest-data/
diff --git a/drivers/of/overlay_mgr.c b/drivers/of/overlay_mgr.c
new file mode 100644
index 0000000..1fdeb0a
--- /dev/null
+++ b/drivers/of/overlay_mgr.c
@@ -0,0 +1,90 @@
+/*
+ * Overlay manager that allows to apply list of overlays from DT entry
+ *
+ * Copyright (C) 2016 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/kernel.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+
+static char *of_overlay_dt_entry;
+module_param_named(overlay_dt_entry, of_overlay_dt_entry, charp, 0644);
+
+static int of_overlay_mgr_apply_overlay(struct device_node *onp)
+{
+	int ret;
+
+	ret = of_overlay_create(onp);
+	if (ret < 0) {
+		pr_err("overlay_mgr: fail to create overlay: %d\n", ret);
+		of_node_put(onp);
+		return ret;
+	}
+	pr_info("overlay_mgr: %s overlay applied\n", onp->name);
+	return 0;
+}
+
+static int of_overlay_mgr_apply_dt(struct device *dev, char *dt_entry)
+{
+	struct device_node *enp = dev->of_node;
+	struct device_node *next;
+	struct device_node *prev = NULL;
+
+	if (!enp) {
+		pr_err("overlay_mgr: no dt entry\n");
+		return -ENODEV;
+	}
+
+	enp = of_get_child_by_name(enp, dt_entry);
+	if (!enp) {
+		pr_err("overlay_mgr: dt entry %s not found\n", dt_entry);
+		return -ENODEV;
+	}
+	pr_info("overlay_mgr: apply %s dt entry\n", enp->name);
+	while ((next = of_get_next_available_child(enp, prev)) != NULL) {
+		if (strncmp(next->name, "overlay", 7) == 0)
+			of_overlay_mgr_apply_overlay(next);
+		prev = next;
+	}
+	return 0;
+}
+
+static int of_overlay_mgr_probe(struct platform_device *pdev)
+{
+	if (!of_overlay_dt_entry)
+		return 0;
+	of_overlay_mgr_apply_dt(&pdev->dev, of_overlay_dt_entry);
+	return 0;
+}
+
+static const struct of_device_id of_overlay_mgr_match[] = {
+	{ .compatible = "linux,overlay_manager", },
+	{}
+};
+
+static struct platform_driver of_overlay_mgr_driver = {
+	.probe	= of_overlay_mgr_probe,
+	.driver	= {
+		.name = "overlay_manager",
+		.of_match_table = of_match_ptr(of_overlay_mgr_match),
+	},
+};
+
+static int __init of_overlay_mgr_init(void)
+{
+	return platform_driver_register(&of_overlay_mgr_driver);
+}
+
+postcore_initcall(of_overlay_mgr_init);
-- 
2.8.0.rc3.226.g39d4020

Re: [PATCH] of: Overlay manager

[Frank Rowand]

On 09/08/16 13:35, dimitrysh@google.com wrote:
> From e14eb45fa5a93c1bff8a6dfe7b6756e4ad72c579 Mon Sep 17 00:00:00 2001
> From: Dmitry Shmidt <dimitrysh@google.com>
> Date: Wed, 24 Aug 2016 13:25:52 -0700
> Subject: [PATCH] of: Overlay manager
> 
> Overlay manager processes DT entries on demand.
> It is chosen by CONFIG_OF_OVERLAY_MGR option.
> These entries can be chosen from kernel command line:
> overlay_mgr.overlay_dt_entry=hardware_cfg_0
> DT contains main overlay_mng entry with all possible
> HW config setups. And then kernel command line option
> will allow to choose between them.
> 
>   Kernel DT entry:
>     overlay_mgr {
>         compatible = "linux,overlay_manager";
>         hardware_cfg_0 {
>             overlay@0 {
>                     fragment@0 {
>                             __overlay__ {
>                             };
>                     };
>             };
>             overlay@1 {
>                     fragment@0 {
>                             __overlay__ {
>                             };
>                     };
>             };
>         };
>     };

What problem(s) are you trying to solve with this?

What is the use case?

-Frank

> 
> Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
> Tested-by: John Stultz <john.stultz@linaro.org>
> Acked-by: John Stultz <john.stultz@linaro.org>
> ---
>  .../devicetree/bindings/of/overlay_mgr.txt         | 32 ++++++++
>  drivers/of/Kconfig                                 | 10 +++
>  drivers/of/Makefile                                |  1 +
>  drivers/of/overlay_mgr.c                           | 90 ++++++++++++++++++++++
>  4 files changed, 133 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/of/overlay_mgr.txt
>  create mode 100644 drivers/of/overlay_mgr.c
> 
> diff --git a/Documentation/devicetree/bindings/of/overlay_mgr.txt b/Documentation/devicetree/bindings/of/overlay_mgr.txt
> new file mode 100644
> index 0000000..5f3ce4c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/of/overlay_mgr.txt
> @@ -0,0 +1,32 @@
> +overlay_mgr
> +
> +Required properties:
> +- compatible: "linux,overlay_manager";
> +
> +Optional properties:
> +- starts from the word "hardware": hardware_cfg_0
> +
> +These properties can be chosen from kernel command line:
> +overlay_mgr.overlay_dt_entry=hardware_cfg_0
> +DT contains main overlay_mng entry with all possible
> +HW config setups. And then kernel command line option
> +will allow to choose between them.
> +
> +Example:
> +    overlay_mgr {
> +        compatible = "linux,overlay_manager";
> +        hardware_cfg_0 {
> +            overlay@0 {
> +                    fragment@0 {
> +                            __overlay__ {
> +                            };
> +                    };
> +            };
> +            overlay@1 {
> +                    fragment@0 {
> +                            __overlay__ {
> +                            };
> +                    };
> +            };
> +        };
> +    };
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index e2a4841..e3eb06d 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -112,4 +112,14 @@ config OF_OVERLAY
>        While this option is selected automatically when needed, you can
>        enable it manually to improve device tree unit test coverage.
> 
> +config OF_OVERLAY_MGR
> +    bool "Enable Overlay manager"
> +    default n
> +    depends on OF_OVERLAY
> +    help
> +      Enables Overlay manager - it accepts DT entry from command line
> +      overlay_mgr.overlay_dt_entry=<name> and applies all overlays in
> +      it to current DT. It is also possible to apply predefined DT
> +      entry on the fly by writing it to 'current_overlay' sysfs entry.
> +
>  endif # OF
> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
> index 156c072..3bddd19 100644
> --- a/drivers/of/Makefile
> +++ b/drivers/of/Makefile
> @@ -14,5 +14,6 @@ obj-$(CONFIG_OF_MTD)    += of_mtd.o
>  obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
>  obj-$(CONFIG_OF_RESOLVE)  += resolver.o
>  obj-$(CONFIG_OF_OVERLAY) += overlay.o
> +obj-$(CONFIG_OF_OVERLAY_MGR) += overlay_mgr.o
> 
>  obj-$(CONFIG_OF_UNITTEST) += unittest-data/
> diff --git a/drivers/of/overlay_mgr.c b/drivers/of/overlay_mgr.c
> new file mode 100644
> index 0000000..1fdeb0a
> --- /dev/null
> +++ b/drivers/of/overlay_mgr.c
> @@ -0,0 +1,90 @@
> +/*
> + * Overlay manager that allows to apply list of overlays from DT entry
> + *
> + * Copyright (C) 2016 Google, Inc.
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/moduleparam.h>
> +#include <linux/kernel.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +
> +static char *of_overlay_dt_entry;
> +module_param_named(overlay_dt_entry, of_overlay_dt_entry, charp, 0644);
> +
> +static int of_overlay_mgr_apply_overlay(struct device_node *onp)
> +{
> +    int ret;
> +
> +    ret = of_overlay_create(onp);
> +    if (ret < 0) {
> +        pr_err("overlay_mgr: fail to create overlay: %d\n", ret);
> +        of_node_put(onp);
> +        return ret;
> +    }
> +    pr_info("overlay_mgr: %s overlay applied\n", onp->name);
> +    return 0;
> +}
> +
> +static int of_overlay_mgr_apply_dt(struct device *dev, char *dt_entry)
> +{
> +    struct device_node *enp = dev->of_node;
> +    struct device_node *next;
> +    struct device_node *prev = NULL;
> +
> +    if (!enp) {
> +        pr_err("overlay_mgr: no dt entry\n");
> +        return -ENODEV;
> +    }
> +
> +    enp = of_get_child_by_name(enp, dt_entry);
> +    if (!enp) {
> +        pr_err("overlay_mgr: dt entry %s not found\n", dt_entry);
> +        return -ENODEV;
> +    }
> +    pr_info("overlay_mgr: apply %s dt entry\n", enp->name);
> +    while ((next = of_get_next_available_child(enp, prev)) != NULL) {
> +        if (strncmp(next->name, "overlay", 7) == 0)
> +            of_overlay_mgr_apply_overlay(next);
> +        prev = next;
> +    }
> +    return 0;
> +}
> +
> +static int of_overlay_mgr_probe(struct platform_device *pdev)
> +{
> +    if (!of_overlay_dt_entry)
> +        return 0;
> +    of_overlay_mgr_apply_dt(&pdev->dev, of_overlay_dt_entry);
> +    return 0;
> +}
> +
> +static const struct of_device_id of_overlay_mgr_match[] = {
> +    { .compatible = "linux,overlay_manager", },
> +    {}
> +};
> +
> +static struct platform_driver of_overlay_mgr_driver = {
> +    .probe    = of_overlay_mgr_probe,
> +    .driver    = {
> +        .name = "overlay_manager",
> +        .of_match_table = of_match_ptr(of_overlay_mgr_match),
> +    },
> +};
> +
> +static int __init of_overlay_mgr_init(void)
> +{
> +    return platform_driver_register(&of_overlay_mgr_driver);
> +}
> +
> +postcore_initcall(of_overlay_mgr_init);

Re: [PATCH] of: Overlay manager

[Dmitry Shmidt]

On Thu, Sep 8, 2016 at 2:08 PM, Frank Rowand <frowand.list@gmail.com> wrote:
> On 09/08/16 13:35, dimitrysh@google.com wrote:
>> From e14eb45fa5a93c1bff8a6dfe7b6756e4ad72c579 Mon Sep 17 00:00:00 2001
>> From: Dmitry Shmidt <dimitrysh@google.com>
>> Date: Wed, 24 Aug 2016 13:25:52 -0700
>> Subject: [PATCH] of: Overlay manager
>>
>> Overlay manager processes DT entries on demand.
>> It is chosen by CONFIG_OF_OVERLAY_MGR option.
>> These entries can be chosen from kernel command line:
>> overlay_mgr.overlay_dt_entry=hardware_cfg_0
>> DT contains main overlay_mng entry with all possible
>> HW config setups. And then kernel command line option
>> will allow to choose between them.
>>
>>   Kernel DT entry:
>>     overlay_mgr {
>>         compatible = "linux,overlay_manager";
>>         hardware_cfg_0 {
>>             overlay@0 {
>>                     fragment@0 {
>>                             __overlay__ {
>>                             };
>>                     };
>>             };
>>             overlay@1 {
>>                     fragment@0 {
>>                             __overlay__ {
>>                             };
>>                     };
>>             };
>>         };
>>     };
>
> What problem(s) are you trying to solve with this?

Currently the Linux kernel doesn't provide a way for boot time
selection of different possible board configurations, when the board
peripherals are specified via Device Tree.

Thus, this patch provides a driver which takes a boot option to
apply pre-defined device-tree overlay fragments on bootup. This
allows a single kernel/devicetree to be able to support a number of
different configurations by only changing a boot argument.

> What is the use case?

It is usually useful for development board when you can use
different peripherals. For example you want to use special
LCD panel. Using it will go on account of other stuff like GPIOs,
so you don't want it all the time. And it is not convenient to
apply new patches and to recompile the kernel. And this code
allows to choose LCD panel configuration from command line.

> -Frank
>
>>
>> Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
>> Tested-by: John Stultz <john.stultz@linaro.org>
>> Acked-by: John Stultz <john.stultz@linaro.org>
>> ---
>>  .../devicetree/bindings/of/overlay_mgr.txt         | 32 ++++++++
>>  drivers/of/Kconfig                                 | 10 +++
>>  drivers/of/Makefile                                |  1 +
>>  drivers/of/overlay_mgr.c                           | 90 ++++++++++++++++++++++
>>  4 files changed, 133 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/of/overlay_mgr.txt
>>  create mode 100644 drivers/of/overlay_mgr.c
>>
>> diff --git a/Documentation/devicetree/bindings/of/overlay_mgr.txt b/Documentation/devicetree/bindings/of/overlay_mgr.txt
>> new file mode 100644
>> index 0000000..5f3ce4c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/of/overlay_mgr.txt
>> @@ -0,0 +1,32 @@
>> +overlay_mgr
>> +
>> +Required properties:
>> +- compatible: "linux,overlay_manager";
>> +
>> +Optional properties:
>> +- starts from the word "hardware": hardware_cfg_0
>> +
>> +These properties can be chosen from kernel command line:
>> +overlay_mgr.overlay_dt_entry=hardware_cfg_0
>> +DT contains main overlay_mng entry with all possible
>> +HW config setups. And then kernel command line option
>> +will allow to choose between them.
>> +
>> +Example:
>> +    overlay_mgr {
>> +        compatible = "linux,overlay_manager";
>> +        hardware_cfg_0 {
>> +            overlay@0 {
>> +                    fragment@0 {
>> +                            __overlay__ {
>> +                            };
>> +                    };
>> +            };
>> +            overlay@1 {
>> +                    fragment@0 {
>> +                            __overlay__ {
>> +                            };
>> +                    };
>> +            };
>> +        };
>> +    };
>> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
>> index e2a4841..e3eb06d 100644
>> --- a/drivers/of/Kconfig
>> +++ b/drivers/of/Kconfig
>> @@ -112,4 +112,14 @@ config OF_OVERLAY
>>        While this option is selected automatically when needed, you can
>>        enable it manually to improve device tree unit test coverage.
>>
>> +config OF_OVERLAY_MGR
>> +    bool "Enable Overlay manager"
>> +    default n
>> +    depends on OF_OVERLAY
>> +    help
>> +      Enables Overlay manager - it accepts DT entry from command line
>> +      overlay_mgr.overlay_dt_entry=<name> and applies all overlays in
>> +      it to current DT. It is also possible to apply predefined DT
>> +      entry on the fly by writing it to 'current_overlay' sysfs entry.
>> +
>>  endif # OF
>> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
>> index 156c072..3bddd19 100644
>> --- a/drivers/of/Makefile
>> +++ b/drivers/of/Makefile
>> @@ -14,5 +14,6 @@ obj-$(CONFIG_OF_MTD)    += of_mtd.o
>>  obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
>>  obj-$(CONFIG_OF_RESOLVE)  += resolver.o
>>  obj-$(CONFIG_OF_OVERLAY) += overlay.o
>> +obj-$(CONFIG_OF_OVERLAY_MGR) += overlay_mgr.o
>>
>>  obj-$(CONFIG_OF_UNITTEST) += unittest-data/
>> diff --git a/drivers/of/overlay_mgr.c b/drivers/of/overlay_mgr.c
>> new file mode 100644
>> index 0000000..1fdeb0a
>> --- /dev/null
>> +++ b/drivers/of/overlay_mgr.c
>> @@ -0,0 +1,90 @@
>> +/*
>> + * Overlay manager that allows to apply list of overlays from DT entry
>> + *
>> + * Copyright (C) 2016 Google, Inc.
>> + *
>> + * This software is licensed under the terms of the GNU General Public
>> + * License version 2, as published by the Free Software Foundation, and
>> + * may be copied, distributed, and modified under those terms.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include <linux/module.h>
>> +#include <linux/moduleparam.h>
>> +#include <linux/kernel.h>
>> +#include <linux/of.h>
>> +#include <linux/platform_device.h>
>> +
>> +static char *of_overlay_dt_entry;
>> +module_param_named(overlay_dt_entry, of_overlay_dt_entry, charp, 0644);
>> +
>> +static int of_overlay_mgr_apply_overlay(struct device_node *onp)
>> +{
>> +    int ret;
>> +
>> +    ret = of_overlay_create(onp);
>> +    if (ret < 0) {
>> +        pr_err("overlay_mgr: fail to create overlay: %d\n", ret);
>> +        of_node_put(onp);
>> +        return ret;
>> +    }
>> +    pr_info("overlay_mgr: %s overlay applied\n", onp->name);
>> +    return 0;
>> +}
>> +
>> +static int of_overlay_mgr_apply_dt(struct device *dev, char *dt_entry)
>> +{
>> +    struct device_node *enp = dev->of_node;
>> +    struct device_node *next;
>> +    struct device_node *prev = NULL;
>> +
>> +    if (!enp) {
>> +        pr_err("overlay_mgr: no dt entry\n");
>> +        return -ENODEV;
>> +    }
>> +
>> +    enp = of_get_child_by_name(enp, dt_entry);
>> +    if (!enp) {
>> +        pr_err("overlay_mgr: dt entry %s not found\n", dt_entry);
>> +        return -ENODEV;
>> +    }
>> +    pr_info("overlay_mgr: apply %s dt entry\n", enp->name);
>> +    while ((next = of_get_next_available_child(enp, prev)) != NULL) {
>> +        if (strncmp(next->name, "overlay", 7) == 0)
>> +            of_overlay_mgr_apply_overlay(next);
>> +        prev = next;
>> +    }
>> +    return 0;
>> +}
>> +
>> +static int of_overlay_mgr_probe(struct platform_device *pdev)
>> +{
>> +    if (!of_overlay_dt_entry)
>> +        return 0;
>> +    of_overlay_mgr_apply_dt(&pdev->dev, of_overlay_dt_entry);
>> +    return 0;
>> +}
>> +
>> +static const struct of_device_id of_overlay_mgr_match[] = {
>> +    { .compatible = "linux,overlay_manager", },
>> +    {}
>> +};
>> +
>> +static struct platform_driver of_overlay_mgr_driver = {
>> +    .probe    = of_overlay_mgr_probe,
>> +    .driver    = {
>> +        .name = "overlay_manager",
>> +        .of_match_table = of_match_ptr(of_overlay_mgr_match),
>> +    },
>> +};
>> +
>> +static int __init of_overlay_mgr_init(void)
>> +{
>> +    return platform_driver_register(&of_overlay_mgr_driver);
>> +}
>> +
>> +postcore_initcall(of_overlay_mgr_init);
>

Re: [PATCH] of: Overlay manager

[Frank Rowand]

On 09/08/16 14:15, Dmitry Shmidt wrote:
> On Thu, Sep 8, 2016 at 2:08 PM, Frank Rowand <frowand.list@gmail.com> wrote:
>> On 09/08/16 13:35, dimitrysh@google.com wrote:
>>> From e14eb45fa5a93c1bff8a6dfe7b6756e4ad72c579 Mon Sep 17 00:00:00 2001
>>> From: Dmitry Shmidt <dimitrysh@google.com>
>>> Date: Wed, 24 Aug 2016 13:25:52 -0700
>>> Subject: [PATCH] of: Overlay manager
>>>
>>> Overlay manager processes DT entries on demand.
>>> It is chosen by CONFIG_OF_OVERLAY_MGR option.
>>> These entries can be chosen from kernel command line:
>>> overlay_mgr.overlay_dt_entry=hardware_cfg_0
>>> DT contains main overlay_mng entry with all possible
>>> HW config setups. And then kernel command line option
>>> will allow to choose between them.
>>>
>>>   Kernel DT entry:
>>>     overlay_mgr {
>>>         compatible = "linux,overlay_manager";
>>>         hardware_cfg_0 {
>>>             overlay@0 {
>>>                     fragment@0 {
>>>                             __overlay__ {
>>>                             };
>>>                     };
>>>             };
>>>             overlay@1 {
>>>                     fragment@0 {
>>>                             __overlay__ {
>>>                             };
>>>                     };
>>>             };
>>>         };
>>>     };
>>
>> What problem(s) are you trying to solve with this?
> 
> Currently the Linux kernel doesn't provide a way for boot time
> selection of different possible board configurations, when the board
> peripherals are specified via Device Tree.
> 
> Thus, this patch provides a driver which takes a boot option to
> apply pre-defined device-tree overlay fragments on bootup. This
> allows a single kernel/devicetree to be able to support a number of
> different configurations by only changing a boot argument.
> 
>> What is the use case?
> 
> It is usually useful for development board when you can use
> different peripherals. For example you want to use special
> LCD panel. Using it will go on account of other stuff like GPIOs,
> so you don't want it all the time. And it is not convenient to
> apply new patches and to recompile the kernel. And this code
> allows to choose LCD panel configuration from command line.

In other words, you want to be able to make configuration choices
at boot time.

The hardware is not different between boots, but you may want to use
it in different ways, with a boot time selection.

Did I get that right?

-Frank

< snip >

Re: [PATCH] of: Overlay manager

[John Stultz]

On Thu, Sep 8, 2016 at 4:33 PM, Frank Rowand <frowand.list@gmail.com> wrote:
> On 09/08/16 14:15, Dmitry Shmidt wrote:
>> On Thu, Sep 8, 2016 at 2:08 PM, Frank Rowand <frowand.list@gmail.com> wrote:
>>> On 09/08/16 13:35, dimitrysh@google.com wrote:
>>>> From e14eb45fa5a93c1bff8a6dfe7b6756e4ad72c579 Mon Sep 17 00:00:00 2001
>>>> From: Dmitry Shmidt <dimitrysh@google.com>
>>>> Date: Wed, 24 Aug 2016 13:25:52 -0700
>>>> Subject: [PATCH] of: Overlay manager
>>>>
>>>> Overlay manager processes DT entries on demand.
>>>> It is chosen by CONFIG_OF_OVERLAY_MGR option.
>>>> These entries can be chosen from kernel command line:
>>>> overlay_mgr.overlay_dt_entry=hardware_cfg_0
>>>> DT contains main overlay_mng entry with all possible
>>>> HW config setups. And then kernel command line option
>>>> will allow to choose between them.
>>>>
>>>>   Kernel DT entry:
>>>>     overlay_mgr {
>>>>         compatible = "linux,overlay_manager";
>>>>         hardware_cfg_0 {
>>>>             overlay@0 {
>>>>                     fragment@0 {
>>>>                             __overlay__ {
>>>>                             };
>>>>                     };
>>>>             };
>>>>             overlay@1 {
>>>>                     fragment@0 {
>>>>                             __overlay__ {
>>>>                             };
>>>>                     };
>>>>             };
>>>>         };
>>>>     };
>>>
>>> What problem(s) are you trying to solve with this?
>>
>> Currently the Linux kernel doesn't provide a way for boot time
>> selection of different possible board configurations, when the board
>> peripherals are specified via Device Tree.
>>
>> Thus, this patch provides a driver which takes a boot option to
>> apply pre-defined device-tree overlay fragments on bootup. This
>> allows a single kernel/devicetree to be able to support a number of
>> different configurations by only changing a boot argument.
>>
>>> What is the use case?
>>
>> It is usually useful for development board when you can use
>> different peripherals. For example you want to use special
>> LCD panel. Using it will go on account of other stuff like GPIOs,
>> so you don't want it all the time. And it is not convenient to
>> apply new patches and to recompile the kernel. And this code
>> allows to choose LCD panel configuration from command line.
>
> In other words, you want to be able to make configuration choices
> at boot time.
>
> The hardware is not different between boots, but you may want to use
> it in different ways, with a boot time selection.

The hardware may actually be different between boots, as different
mezzanine or shields might be attached.

The idea is to have a single kernel/dts that can function with an
array of plug-able (but unfortunately not probe-able attachments).

thanks
-john

Re: [PATCH] of: Overlay manager

[Rob Herring]

On Thu, Sep 8, 2016 at 4:15 PM, Dmitry Shmidt <dimitrysh@google.com> wrote:
> On Thu, Sep 8, 2016 at 2:08 PM, Frank Rowand <frowand.list@gmail.com> wrote:
>> On 09/08/16 13:35, dimitrysh@google.com wrote:
>>> From e14eb45fa5a93c1bff8a6dfe7b6756e4ad72c579 Mon Sep 17 00:00:00 2001
>>> From: Dmitry Shmidt <dimitrysh@google.com>
>>> Date: Wed, 24 Aug 2016 13:25:52 -0700
>>> Subject: [PATCH] of: Overlay manager
>>>
>>> Overlay manager processes DT entries on demand.
>>> It is chosen by CONFIG_OF_OVERLAY_MGR option.
>>> These entries can be chosen from kernel command line:
>>> overlay_mgr.overlay_dt_entry=hardware_cfg_0
>>> DT contains main overlay_mng entry with all possible
>>> HW config setups. And then kernel command line option
>>> will allow to choose between them.

There's 2 new things this patch does that should be separated:
sources/locations of overlays and selecting which ones to apply.

We could have several sources of overlays (just talking at boot time).
They could be built into the kernel. We've also discussed being about
to append overlays to the dtb (not just cat, but extending the FDT
format). This would make bootloaders' job applying overlays trivial.
The kernel command line option should not care what is the source. As
part of that, I don't think overlay manager should be a separate
thing.

The second part is how do we select overlays to apply. This could be
some platform quirk code, could be set in /chosen in DT, or the kernel
command line. These all need a way to identify the overlays. It also
needs to be independent of the location. I don't have a good answer
ATM. Is hardware_cfg_X just an example or convention? I don't really
like it as convention, but haven't come up with an alternative.
Perhaps overlays should have compatible strings.

>>>
>>>   Kernel DT entry:
>>>     overlay_mgr {
>>>         compatible = "linux,overlay_manager";

This is really just "a set of overlays in a base DT". That's not
really a Linux thing, but we do need to define a standard way to
include them (unless there is some reason not to, but I don't see one
ATM).

>>>         hardware_cfg_0 {

These 2 levels could be collapsed to 1 or maybe removed completely.
Not necessarily how I think things should look, but grouping them
could be the user's problem and you just say:

dt-overlays=overlay@0,overlay@1

>>>             overlay@0 {
>>>                     fragment@0 {
>>>                             __overlay__ {
>>>                             };
>>>                     };
>>>             };
>>>             overlay@1 {
>>>                     fragment@0 {
>>>                             __overlay__ {
>>>                             };
>>>                     };
>>>             };
>>>         };
>>>     };
>>
>> What problem(s) are you trying to solve with this?
>
> Currently the Linux kernel doesn't provide a way for boot time
> selection of different possible board configurations, when the board
> peripherals are specified via Device Tree.

Well, the kernel does provide a way. For different h/w you give it a
different h/w description (i.e. dtb). The issue is having multiple
dtbs for mostly similar h/w is a PIA.

Also, it can be argued this should remain a bootloader problem. For
the LCD case, the bootloader is going to need that information to
support a splash screen. libfdt is learning how to apply overlays on
flat trees.

> Thus, this patch provides a driver which takes a boot option to
> apply pre-defined device-tree overlay fragments on bootup. This
> allows a single kernel/devicetree to be able to support a number of
> different configurations by only changing a boot argument.
>
>> What is the use case?
>
> It is usually useful for development board when you can use
> different peripherals. For example you want to use special
> LCD panel. Using it will go on account of other stuff like GPIOs,
> so you don't want it all the time. And it is not convenient to
> apply new patches and to recompile the kernel. And this code
> allows to choose LCD panel configuration from command line.

If you can figure out how to change the command line, then you can
just change the dtb. At least for how Android boot works, those aren't
really changed separately.

Rob

Re: [PATCH] of: Overlay manager

[John Stultz]

On Thu, Sep 8, 2016 at 5:33 PM, Rob Herring <robh+dt@kernel.org> wrote:
> On Thu, Sep 8, 2016 at 4:15 PM, Dmitry Shmidt <dimitrysh@google.com> wrote:
>> On Thu, Sep 8, 2016 at 2:08 PM, Frank Rowand <frowand.list@gmail.com> wrote:
>>> What problem(s) are you trying to solve with this?
>>
>> Currently the Linux kernel doesn't provide a way for boot time
>> selection of different possible board configurations, when the board
>> peripherals are specified via Device Tree.
>
> Well, the kernel does provide a way. For different h/w you give it a
> different h/w description (i.e. dtb). The issue is having multiple
> dtbs for mostly similar h/w is a PIA.

Agreed.

> Also, it can be argued this should remain a bootloader problem. For
> the LCD case, the bootloader is going to need that information to
> support a splash screen. libfdt is learning how to apply overlays on
> flat trees.

I can imagine in many cases like devboards with various attached
shields/mezzanines the bootloader doesn't (and likely can't) have this
ability.


>>> What is the use case?
>>
>> It is usually useful for development board when you can use
>> different peripherals. For example you want to use special
>> LCD panel. Using it will go on account of other stuff like GPIOs,
>> so you don't want it all the time. And it is not convenient to
>> apply new patches and to recompile the kernel. And this code
>> allows to choose LCD panel configuration from command line.
>
> If you can figure out how to change the command line, then you can
> just change the dtb. At least for how Android boot works, those aren't
> really changed separately.

Ehh.. that's not so simple. The dtb is often appended to the kernel on
Android devices. Changing the boot arguments is much simpler to do.

thanks
-john

Re: [PATCH] of: Overlay manager

[Rob Herring]

On Thu, Sep 8, 2016 at 7:39 PM, John Stultz <john.stultz@linaro.org> wrote:
> On Thu, Sep 8, 2016 at 5:33 PM, Rob Herring <robh+dt@kernel.org> wrote:
>> On Thu, Sep 8, 2016 at 4:15 PM, Dmitry Shmidt <dimitrysh@google.com> wrote:
>>> On Thu, Sep 8, 2016 at 2:08 PM, Frank Rowand <frowand.list@gmail.com> wrote:
>>>> What problem(s) are you trying to solve with this?
>>>
>>> Currently the Linux kernel doesn't provide a way for boot time
>>> selection of different possible board configurations, when the board
>>> peripherals are specified via Device Tree.
>>
>> Well, the kernel does provide a way. For different h/w you give it a
>> different h/w description (i.e. dtb). The issue is having multiple
>> dtbs for mostly similar h/w is a PIA.
>
> Agreed.
>
>> Also, it can be argued this should remain a bootloader problem. For
>> the LCD case, the bootloader is going to need that information to
>> support a splash screen. libfdt is learning how to apply overlays on
>> flat trees.
>
> I can imagine in many cases like devboards with various attached
> shields/mezzanines the bootloader doesn't (and likely can't) have this
> ability.

Yes. That's the main reason overlays exist. There's a big blocker for
a major subset of this case that is needing to define a connector
binding. 96board mezzanine boards for example should have 1 overlay
independent of the base board and that means we need some indirection
for things like what i2c controller goes to I2C0 bus on the low speed
connector. All that is being worked on (slowly).

>>>> What is the use case?
>>>
>>> It is usually useful for development board when you can use
>>> different peripherals. For example you want to use special
>>> LCD panel. Using it will go on account of other stuff like GPIOs,
>>> so you don't want it all the time. And it is not convenient to
>>> apply new patches and to recompile the kernel. And this code
>>> allows to choose LCD panel configuration from command line.
>>
>> If you can figure out how to change the command line, then you can
>> just change the dtb. At least for how Android boot works, those aren't
>> really changed separately.
>
> Ehh.. that's not so simple. The dtb is often appended to the kernel on
> Android devices. Changing the boot arguments is much simpler to do.

How? You typically make a new bootimage assembling the kernel/dtb,
ramdisk and kernel command-line. If things were done differently such
that the dtb is part of the bootloader (how it is supposed to be
done), then I would buy the argument that we can't update the dtb and
need to either have a way to add and/or select overlays. But Android
folks like to update *everything*, so I don't buy that here.

Rob

Re: [PATCH] of: Overlay manager

[John Stultz]

On Thu, Sep 8, 2016 at 7:27 PM, Rob Herring <robh+dt@kernel.org> wrote:
> On Thu, Sep 8, 2016 at 7:39 PM, John Stultz <john.stultz@linaro.org> wrote:
>> On Thu, Sep 8, 2016 at 5:33 PM, Rob Herring <robh+dt@kernel.org> wrote:
>>> If you can figure out how to change the command line, then you can
>>> just change the dtb. At least for how Android boot works, those aren't
>>> really changed separately.
>>
>> Ehh.. that's not so simple. The dtb is often appended to the kernel on
>> Android devices. Changing the boot arguments is much simpler to do.
>
> How? You typically make a new bootimage assembling the kernel/dtb,
> ramdisk and kernel command-line. If things were done differently such
> that the dtb is part of the bootloader (how it is supposed to be
> done), then I would buy the argument that we can't update the dtb and
> need to either have a way to add and/or select overlays. But Android
> folks like to update *everything*, so I don't buy that here.

So in many cases the dtb is appended when the kernel is built, not
when the abootimg is assembled.

So its much easier to use abootimg -u to update a prebuilt boot.img in
place and reflash. That way users don't need to regenerate the kernel
w/ appended dtb.

thanks
-john

Re: [PATCH] of: Overlay manager

[Pantelis Antoniou]

Hi John,

> On Sep 9, 2016, at 06:06 , John Stultz <john.stultz@linaro.org> wrote:
> 
> On Thu, Sep 8, 2016 at 7:27 PM, Rob Herring <robh+dt@kernel.org> wrote:
>> On Thu, Sep 8, 2016 at 7:39 PM, John Stultz <john.stultz@linaro.org> wrote:
>>> On Thu, Sep 8, 2016 at 5:33 PM, Rob Herring <robh+dt@kernel.org> wrote:
>>>> If you can figure out how to change the command line, then you can
>>>> just change the dtb. At least for how Android boot works, those aren't
>>>> really changed separately.
>>> 
>>> Ehh.. that's not so simple. The dtb is often appended to the kernel on
>>> Android devices. Changing the boot arguments is much simpler to do.
>> 
>> How? You typically make a new bootimage assembling the kernel/dtb,
>> ramdisk and kernel command-line. If things were done differently such
>> that the dtb is part of the bootloader (how it is supposed to be
>> done), then I would buy the argument that we can't update the dtb and
>> need to either have a way to add and/or select overlays. But Android
>> folks like to update *everything*, so I don't buy that here.
> 
> So in many cases the dtb is appended when the kernel is built, not
> when the abootimg is assembled.
> 
> So its much easier to use abootimg -u to update a prebuilt boot.img in
> place and reflash. That way users don't need to regenerate the kernel
> w/ appended dtb.
> 

I understand what you’re trying to do, but it’s not going to work.

It will only work for a very small subset of overlays since you can’t
have more than a single phandle label.

For instance this will not work:

overlays {
	overlay_0 {
		opt: opt_0 { bar; };
	};
	overlay_1 {
		opt: opt_1 { baz; };
	};
};


frob_device {
	compatible = “frob”;
	use = <&opt>;
};

If your use case is simple enough you’ll never hit this, but it does happen in
more complex examples.

> thanks
> -john

Regards

— Pantelis

Re: [PATCH] of: Overlay manager

[John Stultz]

On Fri, Sep 9, 2016 at 12:26 PM, Pantelis Antoniou
<pantelis.antoniou@konsulko.com> wrote:
>> On Sep 9, 2016, at 06:06 , John Stultz <john.stultz@linaro.org> wrote:
>>
>> So in many cases the dtb is appended when the kernel is built, not
>> when the abootimg is assembled.
>>
>> So its much easier to use abootimg -u to update a prebuilt boot.img in
>> place and reflash. That way users don't need to regenerate the kernel
>> w/ appended dtb.
>>
>
> I understand what you’re trying to do, but it’s not going to work.
>
> It will only work for a very small subset of overlays since you can’t
> have more than a single phandle label.
>
> For instance this will not work:
>
> overlays {
>         overlay_0 {
>                 opt: opt_0 { bar; };
>         };
>         overlay_1 {
>                 opt: opt_1 { baz; };
>         };
> };
>
>
> frob_device {
>         compatible = “frob”;
>         use = <&opt>;
> };
>
> If your use case is simple enough you’ll never hit this, but it does happen in
> more complex examples.

Why not then put the frob_device in the overlays?

And even so, just saying "its not going to work" isn't particularly
helpful since this *does* work for the use cases we currently have, so
lets not let perfect be the enemy of good.

I'm no dts expert (Dmitry wrote the patch), but we'd welcome ideas for
allowing a set of pre-determined dts configurations be boot-time
selectable. It doesn't have to be this solution, but we need something
and this is what we have right now.

Should we revisit multi-appended dtbs w/ a boot argument selector?
(Though this seems less ideal, as generating the various dtbs and the
duplicate waste would be a bit annoying).  Other ideas?

thanks
-john

Re: [PATCH] of: Overlay manager

[Rob Herring]

On Fri, Sep 9, 2016 at 2:26 PM, Pantelis Antoniou
<pantelis.antoniou@konsulko.com> wrote:
> Hi John,
>
>> On Sep 9, 2016, at 06:06 , John Stultz <john.stultz@linaro.org> wrote:
>>
>> On Thu, Sep 8, 2016 at 7:27 PM, Rob Herring <robh+dt@kernel.org> wrote:
>>> On Thu, Sep 8, 2016 at 7:39 PM, John Stultz <john.stultz@linaro.org> wrote:
>>>> On Thu, Sep 8, 2016 at 5:33 PM, Rob Herring <robh+dt@kernel.org> wrote:
>>>>> If you can figure out how to change the command line, then you can
>>>>> just change the dtb. At least for how Android boot works, those aren't
>>>>> really changed separately.
>>>>
>>>> Ehh.. that's not so simple. The dtb is often appended to the kernel on
>>>> Android devices. Changing the boot arguments is much simpler to do.
>>>
>>> How? You typically make a new bootimage assembling the kernel/dtb,
>>> ramdisk and kernel command-line. If things were done differently such
>>> that the dtb is part of the bootloader (how it is supposed to be
>>> done), then I would buy the argument that we can't update the dtb and
>>> need to either have a way to add and/or select overlays. But Android
>>> folks like to update *everything*, so I don't buy that here.
>>
>> So in many cases the dtb is appended when the kernel is built, not
>> when the abootimg is assembled.
>>
>> So its much easier to use abootimg -u to update a prebuilt boot.img in
>> place and reflash. That way users don't need to regenerate the kernel
>> w/ appended dtb.
>>
>
> I understand what you’re trying to do, but it’s not going to work.
>
> It will only work for a very small subset of overlays since you can’t
> have more than a single phandle label.

labels are just shortcuts that have no bearing on the actual dtb. The
only problem here is if you take 2 standalone overlays and include or
move them into a single source, then you may have to fixup any label
collisions.

>
> For instance this will not work:
>
> overlays {
>         overlay_0 {
>                 opt: opt_0 { bar; };
>         };
>         overlay_1 {
>                 opt: opt_1 { baz; };
>         };
> };
>
>
> frob_device {
>         compatible = “frob”;
>         use = <&opt>;
> };

I'm trying to think of a real example where we would want the base dt
point to a phandle in an overlay. If that works, I think we should
make it not work.

We need to back up and decide at what stage/level do we support
combining base DT and overlays? Doing this at the source level is just
making me more worried what kind of abuses there could be if the base
dt and overlays are in the same source and the inability to enforce
what's supported/allowed. I'm thinking we should require the source be
separate and let dtc figure out how to merge them. Then we have the
same source syntax whether the overlay remains separate or combined.
Maybe it ends up merged like this or we extend the FDT format to
append overlays.

Rob