[PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Tony Lindgren]

Currently we get the following kind of errors if we try to use
interrupt phandles to irqchips that have not yet initialized:

irq: no irq domain found for /ocp/pinmux@48002030 !
WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
(show_stack+0x14/0x1c)
(dump_stack+0x6c/0xa0)
(warn_slowpath_common+0x64/0x84)
(warn_slowpath_null+0x1c/0x24)
(of_device_alloc+0x144/0x184)
(of_platform_device_create_pdata+0x44/0x9c)
(of_platform_bus_create+0xd0/0x170)
(of_platform_bus_create+0x12c/0x170)
(of_platform_populate+0x60/0x98)
...

This is because we're wrongly trying to populate resources that are not
yet available. It's perfectly valid to create irqchips dynamically,
so let's fix up the issue by populating the interrupt resources based
on a notifier call instead.

Signed-off-by: Tony Lindgren <tony@atomide.com>

---

Rob & Grant, care to merge this for the -rc if this looks OK to you?

These happen for example when using interrupts-extended for omap
wake-up interrupts where the irq domain is created by pinctrl-single.c
at module_init time.

--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -130,6 +130,56 @@ void of_device_make_bus_id(struct device *dev)
 	dev_set_name(dev, "%s.%d", node->name, magic - 1);
 }
 
+/*
+ * The device interrupts are not necessarily available for all
+ * irqdomains initially so we need to populate them using a
+ * notifier.
+ */
+static int of_device_resource_notify(struct notifier_block *nb,
+				     unsigned long event, void *dev)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct device_node *np = pdev->dev.of_node;
+	struct resource *res = pdev->resource;
+	struct resource *irqr = NULL;
+	int num_irq, i, found = 0;
+
+	if (event != BUS_NOTIFY_BIND_DRIVER)
+		return 0;
+
+	if (!np)
+		goto out;
+
+	num_irq = of_irq_count(np);
+	if (!num_irq)
+		goto out;
+
+	for (i = 0; i < pdev->num_resources; i++, res++) {
+		if (res->flags != IORESOURCE_IRQ ||
+		    res->start != -EPROBE_DEFER ||
+		    res->end != -EPROBE_DEFER)
+			continue;
+
+		if (!irqr)
+			irqr = res;
+		found++;
+	}
+
+	if (!found)
+		goto out;
+
+	if (found != num_irq) {
+		dev_WARN(dev, "error populating irq resources: %i != %i\n",
+			 found, num_irq);
+		goto out;
+	}
+
+	WARN_ON(of_irq_to_resource_table(np, irqr, num_irq) != num_irq);
+
+out:
+	return NOTIFY_DONE;
+}
+
 /**
  * of_device_alloc - Allocate and initialize an of_device
  * @np: device node to assign to device
@@ -168,7 +218,13 @@ struct platform_device *of_device_alloc(struct device_node *np,
 			rc = of_address_to_resource(np, i, res);
 			WARN_ON(rc);
 		}
-		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
+
+		/* See of_device_resource_notify for populating interrupts */
+		for (i = 0; i < num_irq; i++, res++) {
+			res->flags = IORESOURCE_IRQ;
+			res->start = -EPROBE_DEFER;
+			res->end = -EPROBE_DEFER;
+		}
 	}
 
 	dev->dev.of_node = of_node_get(np);
@@ -447,6 +503,8 @@ int of_platform_bus_probe(struct device_node *root,
 }
 EXPORT_SYMBOL(of_platform_bus_probe);
 
+static struct notifier_block resource_nb;
+
 /**
  * of_platform_populate() - Populate platform_devices from device tree data
  * @root: parent of the first level to probe or NULL for the root of the tree
@@ -478,6 +536,11 @@ int of_platform_populate(struct device_node *root,
 	if (!root)
 		return -EINVAL;
 
+	if (!resource_nb.notifier_call) {
+		resource_nb.notifier_call = of_device_resource_notify,
+			bus_register_notifier(&platform_bus_type, &resource_nb);
+	}
+
 	for_each_child_of_node(root, child) {
 		rc = of_platform_bus_create(child, matches, lookup, parent, true);
 		if (rc)

[PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Tony Lindgren]

Currently we get the following kind of errors if we try to use
interrupt phandles to irqchips that have not yet initialized:

irq: no irq domain found for /ocp/pinmux at 48002030 !
WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
(show_stack+0x14/0x1c)
(dump_stack+0x6c/0xa0)
(warn_slowpath_common+0x64/0x84)
(warn_slowpath_null+0x1c/0x24)
(of_device_alloc+0x144/0x184)
(of_platform_device_create_pdata+0x44/0x9c)
(of_platform_bus_create+0xd0/0x170)
(of_platform_bus_create+0x12c/0x170)
(of_platform_populate+0x60/0x98)
...

This is because we're wrongly trying to populate resources that are not
yet available. It's perfectly valid to create irqchips dynamically,
so let's fix up the issue by populating the interrupt resources based
on a notifier call instead.

Signed-off-by: Tony Lindgren <tony@atomide.com>

---

Rob & Grant, care to merge this for the -rc if this looks OK to you?

These happen for example when using interrupts-extended for omap
wake-up interrupts where the irq domain is created by pinctrl-single.c
at module_init time.

--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -130,6 +130,56 @@ void of_device_make_bus_id(struct device *dev)
 	dev_set_name(dev, "%s.%d", node->name, magic - 1);
 }
 
+/*
+ * The device interrupts are not necessarily available for all
+ * irqdomains initially so we need to populate them using a
+ * notifier.
+ */
+static int of_device_resource_notify(struct notifier_block *nb,
+				     unsigned long event, void *dev)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct device_node *np = pdev->dev.of_node;
+	struct resource *res = pdev->resource;
+	struct resource *irqr = NULL;
+	int num_irq, i, found = 0;
+
+	if (event != BUS_NOTIFY_BIND_DRIVER)
+		return 0;
+
+	if (!np)
+		goto out;
+
+	num_irq = of_irq_count(np);
+	if (!num_irq)
+		goto out;
+
+	for (i = 0; i < pdev->num_resources; i++, res++) {
+		if (res->flags != IORESOURCE_IRQ ||
+		    res->start != -EPROBE_DEFER ||
+		    res->end != -EPROBE_DEFER)
+			continue;
+
+		if (!irqr)
+			irqr = res;
+		found++;
+	}
+
+	if (!found)
+		goto out;
+
+	if (found != num_irq) {
+		dev_WARN(dev, "error populating irq resources: %i != %i\n",
+			 found, num_irq);
+		goto out;
+	}
+
+	WARN_ON(of_irq_to_resource_table(np, irqr, num_irq) != num_irq);
+
+out:
+	return NOTIFY_DONE;
+}
+
 /**
  * of_device_alloc - Allocate and initialize an of_device
  * @np: device node to assign to device
@@ -168,7 +218,13 @@ struct platform_device *of_device_alloc(struct device_node *np,
 			rc = of_address_to_resource(np, i, res);
 			WARN_ON(rc);
 		}
-		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
+
+		/* See of_device_resource_notify for populating interrupts */
+		for (i = 0; i < num_irq; i++, res++) {
+			res->flags = IORESOURCE_IRQ;
+			res->start = -EPROBE_DEFER;
+			res->end = -EPROBE_DEFER;
+		}
 	}
 
 	dev->dev.of_node = of_node_get(np);
@@ -447,6 +503,8 @@ int of_platform_bus_probe(struct device_node *root,
 }
 EXPORT_SYMBOL(of_platform_bus_probe);
 
+static struct notifier_block resource_nb;
+
 /**
  * of_platform_populate() - Populate platform_devices from device tree data
  * @root: parent of the first level to probe or NULL for the root of the tree
@@ -478,6 +536,11 @@ int of_platform_populate(struct device_node *root,
 	if (!root)
 		return -EINVAL;
 
+	if (!resource_nb.notifier_call) {
+		resource_nb.notifier_call = of_device_resource_notify,
+			bus_register_notifier(&platform_bus_type, &resource_nb);
+	}
+
 	for_each_child_of_node(root, child) {
 		rc = of_platform_bus_create(child, matches, lookup, parent, true);
 		if (rc)

[PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Tony Lindgren]

Currently we get the following kind of errors if we try to use
interrupt phandles to irqchips that have not yet initialized:

irq: no irq domain found for /ocp/pinmux@48002030 !
WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
(show_stack+0x14/0x1c)
(dump_stack+0x6c/0xa0)
(warn_slowpath_common+0x64/0x84)
(warn_slowpath_null+0x1c/0x24)
(of_device_alloc+0x144/0x184)
(of_platform_device_create_pdata+0x44/0x9c)
(of_platform_bus_create+0xd0/0x170)
(of_platform_bus_create+0x12c/0x170)
(of_platform_populate+0x60/0x98)
...

This is because we're wrongly trying to populate resources that are not
yet available. It's perfectly valid to create irqchips dynamically,
so let's fix up the issue by populating the interrupt resources based
on a notifier call instead.

Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>

---

Rob & Grant, care to merge this for the -rc if this looks OK to you?

These happen for example when using interrupts-extended for omap
wake-up interrupts where the irq domain is created by pinctrl-single.c
at module_init time.

--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -130,6 +130,56 @@ void of_device_make_bus_id(struct device *dev)
 	dev_set_name(dev, "%s.%d", node->name, magic - 1);
 }
 
+/*
+ * The device interrupts are not necessarily available for all
+ * irqdomains initially so we need to populate them using a
+ * notifier.
+ */
+static int of_device_resource_notify(struct notifier_block *nb,
+				     unsigned long event, void *dev)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct device_node *np = pdev->dev.of_node;
+	struct resource *res = pdev->resource;
+	struct resource *irqr = NULL;
+	int num_irq, i, found = 0;
+
+	if (event != BUS_NOTIFY_BIND_DRIVER)
+		return 0;
+
+	if (!np)
+		goto out;
+
+	num_irq = of_irq_count(np);
+	if (!num_irq)
+		goto out;
+
+	for (i = 0; i < pdev->num_resources; i++, res++) {
+		if (res->flags != IORESOURCE_IRQ ||
+		    res->start != -EPROBE_DEFER ||
+		    res->end != -EPROBE_DEFER)
+			continue;
+
+		if (!irqr)
+			irqr = res;
+		found++;
+	}
+
+	if (!found)
+		goto out;
+
+	if (found != num_irq) {
+		dev_WARN(dev, "error populating irq resources: %i != %i\n",
+			 found, num_irq);
+		goto out;
+	}
+
+	WARN_ON(of_irq_to_resource_table(np, irqr, num_irq) != num_irq);
+
+out:
+	return NOTIFY_DONE;
+}
+
 /**
  * of_device_alloc - Allocate and initialize an of_device
  * @np: device node to assign to device
@@ -168,7 +218,13 @@ struct platform_device *of_device_alloc(struct device_node *np,
 			rc = of_address_to_resource(np, i, res);
 			WARN_ON(rc);
 		}
-		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
+
+		/* See of_device_resource_notify for populating interrupts */
+		for (i = 0; i < num_irq; i++, res++) {
+			res->flags = IORESOURCE_IRQ;
+			res->start = -EPROBE_DEFER;
+			res->end = -EPROBE_DEFER;
+		}
 	}
 
 	dev->dev.of_node = of_node_get(np);
@@ -447,6 +503,8 @@ int of_platform_bus_probe(struct device_node *root,
 }
 EXPORT_SYMBOL(of_platform_bus_probe);
 
+static struct notifier_block resource_nb;
+
 /**
  * of_platform_populate() - Populate platform_devices from device tree data
  * @root: parent of the first level to probe or NULL for the root of the tree
@@ -478,6 +536,11 @@ int of_platform_populate(struct device_node *root,
 	if (!root)
 		return -EINVAL;
 
+	if (!resource_nb.notifier_call) {
+		resource_nb.notifier_call = of_device_resource_notify,
+			bus_register_notifier(&platform_bus_type, &resource_nb);
+	}
+
 	for_each_child_of_node(root, child) {
 		rc = of_platform_bus_create(child, matches, lookup, parent, true);
 		if (rc)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Russell King - ARM Linux]

On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
> +		/* See of_device_resource_notify for populating interrupts */
> +		for (i = 0; i < num_irq; i++, res++) {
> +			res->flags = IORESOURCE_IRQ;
> +			res->start = -EPROBE_DEFER;
> +			res->end = -EPROBE_DEFER;

NAK.  Definitely a bad idea to start introducing magic values other into
resources.  Please don't do this.

[PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Russell King - ARM Linux]

On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
> +		/* See of_device_resource_notify for populating interrupts */
> +		for (i = 0; i < num_irq; i++, res++) {
> +			res->flags = IORESOURCE_IRQ;
> +			res->start = -EPROBE_DEFER;
> +			res->end = -EPROBE_DEFER;

NAK.  Definitely a bad idea to start introducing magic values other into
resources.  Please don't do this.

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Russell King - ARM Linux]

On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
> +		/* See of_device_resource_notify for populating interrupts */
> +		for (i = 0; i < num_irq; i++, res++) {
> +			res->flags = IORESOURCE_IRQ;
> +			res->start = -EPROBE_DEFER;
> +			res->end = -EPROBE_DEFER;

NAK.  Definitely a bad idea to start introducing magic values other into
resources.  Please don't do this.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [131122 16:56]:
> On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
> > +		/* See of_device_resource_notify for populating interrupts */
> > +		for (i = 0; i < num_irq; i++, res++) {
> > +			res->flags = IORESOURCE_IRQ;
> > +			res->start = -EPROBE_DEFER;
> > +			res->end = -EPROBE_DEFER;
> 
> NAK.  Definitely a bad idea to start introducing magic values other into
> resources.  Please don't do this.

Do you have any better ideas on how to sort out this issue then?

Tony

[PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [131122 16:56]:
> On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
> > +		/* See of_device_resource_notify for populating interrupts */
> > +		for (i = 0; i < num_irq; i++, res++) {
> > +			res->flags = IORESOURCE_IRQ;
> > +			res->start = -EPROBE_DEFER;
> > +			res->end = -EPROBE_DEFER;
> 
> NAK.  Definitely a bad idea to start introducing magic values other into
> resources.  Please don't do this.

Do you have any better ideas on how to sort out this issue then?

Tony

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [131122 17:09]:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [131122 16:56]:
> > On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
> > > +		/* See of_device_resource_notify for populating interrupts */
> > > +		for (i = 0; i < num_irq; i++, res++) {
> > > +			res->flags = IORESOURCE_IRQ;
> > > +			res->start = -EPROBE_DEFER;
> > > +			res->end = -EPROBE_DEFER;
> > 
> > NAK.  Definitely a bad idea to start introducing magic values other into
> > resources.  Please don't do this.
> 
> Do you have any better ideas on how to sort out this issue then?

I guess we could allocate all the resources lazily here, I'll take a look
at that.

Tony

[PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [131122 17:09]:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [131122 16:56]:
> > On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
> > > +		/* See of_device_resource_notify for populating interrupts */
> > > +		for (i = 0; i < num_irq; i++, res++) {
> > > +			res->flags = IORESOURCE_IRQ;
> > > +			res->start = -EPROBE_DEFER;
> > > +			res->end = -EPROBE_DEFER;
> > 
> > NAK.  Definitely a bad idea to start introducing magic values other into
> > resources.  Please don't do this.
> 
> Do you have any better ideas on how to sort out this issue then?

I guess we could allocate all the resources lazily here, I'll take a look
at that.

Tony

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [131122 17:16]:
> * Tony Lindgren <tony@atomide.com> [131122 17:09]:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [131122 16:56]:
> > > On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
> > > > +		/* See of_device_resource_notify for populating interrupts */
> > > > +		for (i = 0; i < num_irq; i++, res++) {
> > > > +			res->flags = IORESOURCE_IRQ;
> > > > +			res->start = -EPROBE_DEFER;
> > > > +			res->end = -EPROBE_DEFER;
> > > 
> > > NAK.  Definitely a bad idea to start introducing magic values other into
> > > resources.  Please don't do this.
> > 
> > Do you have any better ideas on how to sort out this issue then?
> 
> I guess we could allocate all the resources lazily here, I'll take a look
> at that.

Here's a version that allocates the resources lazily with the notifier.
Seems to boot, need to play with it a bit more though to make sure we're
not overwriting resources for any legacy devices.

Regards,

Tony


--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -141,13 +141,47 @@ struct platform_device *of_device_alloc(struct device_node *np,
 				  struct device *parent)
 {
 	struct platform_device *dev;
-	int rc, i, num_reg = 0, num_irq;
-	struct resource *res, temp_res;
 
 	dev = platform_device_alloc("", -1);
 	if (!dev)
 		return NULL;
 
+	dev->dev.of_node = of_node_get(np);
+#if defined(CONFIG_MICROBLAZE)
+	dev->dev.dma_mask = &dev->archdata.dma_mask;
+#endif
+	dev->dev.parent = parent;
+
+	if (bus_id)
+		dev_set_name(&dev->dev, "%s", bus_id);
+	else
+		of_device_make_bus_id(&dev->dev);
+
+	/* See of_device_resource_notify for populating the resources */
+
+	return dev;
+}
+EXPORT_SYMBOL(of_device_alloc);
+
+/*
+ * The device interrupts are not necessarily available for all
+ * irqdomains initially so we need to populate them using a
+ * notifier.
+ */
+static int of_device_resource_notify(struct notifier_block *nb,
+				     unsigned long event, void *dev)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct device_node *np = pdev->dev.of_node;
+	int rc, i, num_reg = 0, num_irq;
+	struct resource *res, temp_res;
+
+	if (event != BUS_NOTIFY_BIND_DRIVER)
+		return 0;
+
+	if (!np)
+		goto out;
+
 	/* count the io and irq resources */
 	if (of_can_translate_address(np))
 		while (of_address_to_resource(np, num_reg, &temp_res) == 0)
@@ -158,12 +192,12 @@ struct platform_device *of_device_alloc(struct device_node *np,
 	if (num_irq || num_reg) {
 		res = kzalloc(sizeof(*res) * (num_irq + num_reg), GFP_KERNEL);
 		if (!res) {
-			platform_device_put(dev);
-			return NULL;
+			platform_device_put(pdev);
+			goto out;
 		}
 
-		dev->num_resources = num_reg + num_irq;
-		dev->resource = res;
+		pdev->num_resources = num_reg + num_irq;
+		pdev->resource = res;
 		for (i = 0; i < num_reg; i++, res++) {
 			rc = of_address_to_resource(np, i, res);
 			WARN_ON(rc);
@@ -171,20 +205,9 @@ struct platform_device *of_device_alloc(struct device_node *np,
 		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
 	}
 
-	dev->dev.of_node = of_node_get(np);
-#if defined(CONFIG_MICROBLAZE)
-	dev->dev.dma_mask = &dev->archdata.dma_mask;
-#endif
-	dev->dev.parent = parent;
-
-	if (bus_id)
-		dev_set_name(&dev->dev, "%s", bus_id);
-	else
-		of_device_make_bus_id(&dev->dev);
-
-	return dev;
+out:
+	return NOTIFY_DONE;
 }
-EXPORT_SYMBOL(of_device_alloc);
 
 /**
  * of_platform_device_create_pdata - Alloc, initialize and register an of_device
@@ -447,6 +470,8 @@ int of_platform_bus_probe(struct device_node *root,
 }
 EXPORT_SYMBOL(of_platform_bus_probe);
 
+static struct notifier_block resource_nb;
+
 /**
  * of_platform_populate() - Populate platform_devices from device tree data
  * @root: parent of the first level to probe or NULL for the root of the tree
@@ -478,6 +503,11 @@ int of_platform_populate(struct device_node *root,
 	if (!root)
 		return -EINVAL;
 
+	if (!resource_nb.notifier_call) {
+		resource_nb.notifier_call = of_device_resource_notify,
+			bus_register_notifier(&platform_bus_type, &resource_nb);
+	}
+
 	for_each_child_of_node(root, child) {
 		rc = of_platform_bus_create(child, matches, lookup, parent, true);
 		if (rc)

[PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [131122 17:16]:
> * Tony Lindgren <tony@atomide.com> [131122 17:09]:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [131122 16:56]:
> > > On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
> > > > +		/* See of_device_resource_notify for populating interrupts */
> > > > +		for (i = 0; i < num_irq; i++, res++) {
> > > > +			res->flags = IORESOURCE_IRQ;
> > > > +			res->start = -EPROBE_DEFER;
> > > > +			res->end = -EPROBE_DEFER;
> > > 
> > > NAK.  Definitely a bad idea to start introducing magic values other into
> > > resources.  Please don't do this.
> > 
> > Do you have any better ideas on how to sort out this issue then?
> 
> I guess we could allocate all the resources lazily here, I'll take a look
> at that.

Here's a version that allocates the resources lazily with the notifier.
Seems to boot, need to play with it a bit more though to make sure we're
not overwriting resources for any legacy devices.

Regards,

Tony


--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -141,13 +141,47 @@ struct platform_device *of_device_alloc(struct device_node *np,
 				  struct device *parent)
 {
 	struct platform_device *dev;
-	int rc, i, num_reg = 0, num_irq;
-	struct resource *res, temp_res;
 
 	dev = platform_device_alloc("", -1);
 	if (!dev)
 		return NULL;
 
+	dev->dev.of_node = of_node_get(np);
+#if defined(CONFIG_MICROBLAZE)
+	dev->dev.dma_mask = &dev->archdata.dma_mask;
+#endif
+	dev->dev.parent = parent;
+
+	if (bus_id)
+		dev_set_name(&dev->dev, "%s", bus_id);
+	else
+		of_device_make_bus_id(&dev->dev);
+
+	/* See of_device_resource_notify for populating the resources */
+
+	return dev;
+}
+EXPORT_SYMBOL(of_device_alloc);
+
+/*
+ * The device interrupts are not necessarily available for all
+ * irqdomains initially so we need to populate them using a
+ * notifier.
+ */
+static int of_device_resource_notify(struct notifier_block *nb,
+				     unsigned long event, void *dev)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct device_node *np = pdev->dev.of_node;
+	int rc, i, num_reg = 0, num_irq;
+	struct resource *res, temp_res;
+
+	if (event != BUS_NOTIFY_BIND_DRIVER)
+		return 0;
+
+	if (!np)
+		goto out;
+
 	/* count the io and irq resources */
 	if (of_can_translate_address(np))
 		while (of_address_to_resource(np, num_reg, &temp_res) == 0)
@@ -158,12 +192,12 @@ struct platform_device *of_device_alloc(struct device_node *np,
 	if (num_irq || num_reg) {
 		res = kzalloc(sizeof(*res) * (num_irq + num_reg), GFP_KERNEL);
 		if (!res) {
-			platform_device_put(dev);
-			return NULL;
+			platform_device_put(pdev);
+			goto out;
 		}
 
-		dev->num_resources = num_reg + num_irq;
-		dev->resource = res;
+		pdev->num_resources = num_reg + num_irq;
+		pdev->resource = res;
 		for (i = 0; i < num_reg; i++, res++) {
 			rc = of_address_to_resource(np, i, res);
 			WARN_ON(rc);
@@ -171,20 +205,9 @@ struct platform_device *of_device_alloc(struct device_node *np,
 		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
 	}
 
-	dev->dev.of_node = of_node_get(np);
-#if defined(CONFIG_MICROBLAZE)
-	dev->dev.dma_mask = &dev->archdata.dma_mask;
-#endif
-	dev->dev.parent = parent;
-
-	if (bus_id)
-		dev_set_name(&dev->dev, "%s", bus_id);
-	else
-		of_device_make_bus_id(&dev->dev);
-
-	return dev;
+out:
+	return NOTIFY_DONE;
 }
-EXPORT_SYMBOL(of_device_alloc);
 
 /**
  * of_platform_device_create_pdata - Alloc, initialize and register an of_device
@@ -447,6 +470,8 @@ int of_platform_bus_probe(struct device_node *root,
 }
 EXPORT_SYMBOL(of_platform_bus_probe);
 
+static struct notifier_block resource_nb;
+
 /**
  * of_platform_populate() - Populate platform_devices from device tree data
  * @root: parent of the first level to probe or NULL for the root of the tree
@@ -478,6 +503,11 @@ int of_platform_populate(struct device_node *root,
 	if (!root)
 		return -EINVAL;
 
+	if (!resource_nb.notifier_call) {
+		resource_nb.notifier_call = of_device_resource_notify,
+			bus_register_notifier(&platform_bus_type, &resource_nb);
+	}
+
 	for_each_child_of_node(root, child) {
 		rc = of_platform_bus_create(child, matches, lookup, parent, true);
 		if (rc)

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Tony Lindgren]

* Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [131122 17:16]:
> * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [131122 17:09]:
> > * Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> [131122 16:56]:
> > > On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
> > > > +		/* See of_device_resource_notify for populating interrupts */
> > > > +		for (i = 0; i < num_irq; i++, res++) {
> > > > +			res->flags = IORESOURCE_IRQ;
> > > > +			res->start = -EPROBE_DEFER;
> > > > +			res->end = -EPROBE_DEFER;
> > > 
> > > NAK.  Definitely a bad idea to start introducing magic values other into
> > > resources.  Please don't do this.
> > 
> > Do you have any better ideas on how to sort out this issue then?
> 
> I guess we could allocate all the resources lazily here, I'll take a look
> at that.

Here's a version that allocates the resources lazily with the notifier.
Seems to boot, need to play with it a bit more though to make sure we're
not overwriting resources for any legacy devices.

Regards,

Tony


--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -141,13 +141,47 @@ struct platform_device *of_device_alloc(struct device_node *np,
 				  struct device *parent)
 {
 	struct platform_device *dev;
-	int rc, i, num_reg = 0, num_irq;
-	struct resource *res, temp_res;
 
 	dev = platform_device_alloc("", -1);
 	if (!dev)
 		return NULL;
 
+	dev->dev.of_node = of_node_get(np);
+#if defined(CONFIG_MICROBLAZE)
+	dev->dev.dma_mask = &dev->archdata.dma_mask;
+#endif
+	dev->dev.parent = parent;
+
+	if (bus_id)
+		dev_set_name(&dev->dev, "%s", bus_id);
+	else
+		of_device_make_bus_id(&dev->dev);
+
+	/* See of_device_resource_notify for populating the resources */
+
+	return dev;
+}
+EXPORT_SYMBOL(of_device_alloc);
+
+/*
+ * The device interrupts are not necessarily available for all
+ * irqdomains initially so we need to populate them using a
+ * notifier.
+ */
+static int of_device_resource_notify(struct notifier_block *nb,
+				     unsigned long event, void *dev)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct device_node *np = pdev->dev.of_node;
+	int rc, i, num_reg = 0, num_irq;
+	struct resource *res, temp_res;
+
+	if (event != BUS_NOTIFY_BIND_DRIVER)
+		return 0;
+
+	if (!np)
+		goto out;
+
 	/* count the io and irq resources */
 	if (of_can_translate_address(np))
 		while (of_address_to_resource(np, num_reg, &temp_res) == 0)
@@ -158,12 +192,12 @@ struct platform_device *of_device_alloc(struct device_node *np,
 	if (num_irq || num_reg) {
 		res = kzalloc(sizeof(*res) * (num_irq + num_reg), GFP_KERNEL);
 		if (!res) {
-			platform_device_put(dev);
-			return NULL;
+			platform_device_put(pdev);
+			goto out;
 		}
 
-		dev->num_resources = num_reg + num_irq;
-		dev->resource = res;
+		pdev->num_resources = num_reg + num_irq;
+		pdev->resource = res;
 		for (i = 0; i < num_reg; i++, res++) {
 			rc = of_address_to_resource(np, i, res);
 			WARN_ON(rc);
@@ -171,20 +205,9 @@ struct platform_device *of_device_alloc(struct device_node *np,
 		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
 	}
 
-	dev->dev.of_node = of_node_get(np);
-#if defined(CONFIG_MICROBLAZE)
-	dev->dev.dma_mask = &dev->archdata.dma_mask;
-#endif
-	dev->dev.parent = parent;
-
-	if (bus_id)
-		dev_set_name(&dev->dev, "%s", bus_id);
-	else
-		of_device_make_bus_id(&dev->dev);
-
-	return dev;
+out:
+	return NOTIFY_DONE;
 }
-EXPORT_SYMBOL(of_device_alloc);
 
 /**
  * of_platform_device_create_pdata - Alloc, initialize and register an of_device
@@ -447,6 +470,8 @@ int of_platform_bus_probe(struct device_node *root,
 }
 EXPORT_SYMBOL(of_platform_bus_probe);
 
+static struct notifier_block resource_nb;
+
 /**
  * of_platform_populate() - Populate platform_devices from device tree data
  * @root: parent of the first level to probe or NULL for the root of the tree
@@ -478,6 +503,11 @@ int of_platform_populate(struct device_node *root,
 	if (!root)
 		return -EINVAL;
 
+	if (!resource_nb.notifier_call) {
+		resource_nb.notifier_call = of_device_resource_notify,
+			bus_register_notifier(&platform_bus_type, &resource_nb);
+	}
+
 	for_each_child_of_node(root, child) {
 		rc = of_platform_bus_create(child, matches, lookup, parent, true);
 		if (rc)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Rob Herring]

On Fri, Nov 22, 2013 at 7:50 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Tony Lindgren <tony@atomide.com> [131122 17:16]:
>> * Tony Lindgren <tony@atomide.com> [131122 17:09]:
>> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [131122 16:56]:
>> > > On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
>> > > > +               /* See of_device_resource_notify for populating interrupts */
>> > > > +               for (i = 0; i < num_irq; i++, res++) {
>> > > > +                       res->flags = IORESOURCE_IRQ;
>> > > > +                       res->start = -EPROBE_DEFER;
>> > > > +                       res->end = -EPROBE_DEFER;
>> > >
>> > > NAK.  Definitely a bad idea to start introducing magic values other into
>> > > resources.  Please don't do this.
>> >
>> > Do you have any better ideas on how to sort out this issue then?
>>
>> I guess we could allocate all the resources lazily here, I'll take a look
>> at that.
>
> Here's a version that allocates the resources lazily with the notifier.
> Seems to boot, need to play with it a bit more though to make sure we're
> not overwriting resources for any legacy devices.

Have you seen Thierry's series[1]? While your approach is certainly
more concise, it seems like a work-around for the problem. I don't
think a notifier is the right long term solution.

Rob

[1] http://www.spinics.net/lists/arm-kernel/msg274110.html

[PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Rob Herring]

On Fri, Nov 22, 2013 at 7:50 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Tony Lindgren <tony@atomide.com> [131122 17:16]:
>> * Tony Lindgren <tony@atomide.com> [131122 17:09]:
>> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [131122 16:56]:
>> > > On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
>> > > > +               /* See of_device_resource_notify for populating interrupts */
>> > > > +               for (i = 0; i < num_irq; i++, res++) {
>> > > > +                       res->flags = IORESOURCE_IRQ;
>> > > > +                       res->start = -EPROBE_DEFER;
>> > > > +                       res->end = -EPROBE_DEFER;
>> > >
>> > > NAK.  Definitely a bad idea to start introducing magic values other into
>> > > resources.  Please don't do this.
>> >
>> > Do you have any better ideas on how to sort out this issue then?
>>
>> I guess we could allocate all the resources lazily here, I'll take a look
>> at that.
>
> Here's a version that allocates the resources lazily with the notifier.
> Seems to boot, need to play with it a bit more though to make sure we're
> not overwriting resources for any legacy devices.

Have you seen Thierry's series[1]? While your approach is certainly
more concise, it seems like a work-around for the problem. I don't
think a notifier is the right long term solution.

Rob

[1] http://www.spinics.net/lists/arm-kernel/msg274110.html

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Rob Herring]

On Fri, Nov 22, 2013 at 7:50 PM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [131122 17:16]:
>> * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [131122 17:09]:
>> > * Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> [131122 16:56]:
>> > > On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
>> > > > +               /* See of_device_resource_notify for populating interrupts */
>> > > > +               for (i = 0; i < num_irq; i++, res++) {
>> > > > +                       res->flags = IORESOURCE_IRQ;
>> > > > +                       res->start = -EPROBE_DEFER;
>> > > > +                       res->end = -EPROBE_DEFER;
>> > >
>> > > NAK.  Definitely a bad idea to start introducing magic values other into
>> > > resources.  Please don't do this.
>> >
>> > Do you have any better ideas on how to sort out this issue then?
>>
>> I guess we could allocate all the resources lazily here, I'll take a look
>> at that.
>
> Here's a version that allocates the resources lazily with the notifier.
> Seems to boot, need to play with it a bit more though to make sure we're
> not overwriting resources for any legacy devices.

Have you seen Thierry's series[1]? While your approach is certainly
more concise, it seems like a work-around for the problem. I don't
think a notifier is the right long term solution.

Rob

[1] http://www.spinics.net/lists/arm-kernel/msg274110.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Tony Lindgren]

* Rob Herring <robherring2@gmail.com> [131123 07:43]:
> On Fri, Nov 22, 2013 at 7:50 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Tony Lindgren <tony@atomide.com> [131122 17:16]:
> >> * Tony Lindgren <tony@atomide.com> [131122 17:09]:
> >> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [131122 16:56]:
> >> > > On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
> >> > > > +               /* See of_device_resource_notify for populating interrupts */
> >> > > > +               for (i = 0; i < num_irq; i++, res++) {
> >> > > > +                       res->flags = IORESOURCE_IRQ;
> >> > > > +                       res->start = -EPROBE_DEFER;
> >> > > > +                       res->end = -EPROBE_DEFER;
> >> > >
> >> > > NAK.  Definitely a bad idea to start introducing magic values other into
> >> > > resources.  Please don't do this.
> >> >
> >> > Do you have any better ideas on how to sort out this issue then?
> >>
> >> I guess we could allocate all the resources lazily here, I'll take a look
> >> at that.
> >
> > Here's a version that allocates the resources lazily with the notifier.
> > Seems to boot, need to play with it a bit more though to make sure we're
> > not overwriting resources for any legacy devices.
> 
> Have you seen Thierry's series[1]? While your approach is certainly
> more concise, it seems like a work-around for the problem. I don't
> think a notifier is the right long term solution.

OK cool. I think we can fix the $Subject bug first without making all
those changes, then do the rest of the reorg for v3.14.

The bug is that we try to populate IRQ resources at a wrong time
when they may not exist.

Based on a quick look it seems we could combine Thierry's addition
of the new function of_platform_probe(struct platform_device *pdev)
and use that to allocate all resources at driver probe time like my
patch is doing. And then there's no need for the notifier.

Regards,

Tony

 
> [1] http://www.spinics.net/lists/arm-kernel/msg274110.html

[PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Tony Lindgren]

* Rob Herring <robherring2@gmail.com> [131123 07:43]:
> On Fri, Nov 22, 2013 at 7:50 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Tony Lindgren <tony@atomide.com> [131122 17:16]:
> >> * Tony Lindgren <tony@atomide.com> [131122 17:09]:
> >> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [131122 16:56]:
> >> > > On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
> >> > > > +               /* See of_device_resource_notify for populating interrupts */
> >> > > > +               for (i = 0; i < num_irq; i++, res++) {
> >> > > > +                       res->flags = IORESOURCE_IRQ;
> >> > > > +                       res->start = -EPROBE_DEFER;
> >> > > > +                       res->end = -EPROBE_DEFER;
> >> > >
> >> > > NAK.  Definitely a bad idea to start introducing magic values other into
> >> > > resources.  Please don't do this.
> >> >
> >> > Do you have any better ideas on how to sort out this issue then?
> >>
> >> I guess we could allocate all the resources lazily here, I'll take a look
> >> at that.
> >
> > Here's a version that allocates the resources lazily with the notifier.
> > Seems to boot, need to play with it a bit more though to make sure we're
> > not overwriting resources for any legacy devices.
> 
> Have you seen Thierry's series[1]? While your approach is certainly
> more concise, it seems like a work-around for the problem. I don't
> think a notifier is the right long term solution.

OK cool. I think we can fix the $Subject bug first without making all
those changes, then do the rest of the reorg for v3.14.

The bug is that we try to populate IRQ resources at a wrong time
when they may not exist.

Based on a quick look it seems we could combine Thierry's addition
of the new function of_platform_probe(struct platform_device *pdev)
and use that to allocate all resources at driver probe time like my
patch is doing. And then there's no need for the notifier.

Regards,

Tony

 
> [1] http://www.spinics.net/lists/arm-kernel/msg274110.html

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Tony Lindgren]

* Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [131123 07:43]:
> On Fri, Nov 22, 2013 at 7:50 PM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> > * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [131122 17:16]:
> >> * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [131122 17:09]:
> >> > * Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> [131122 16:56]:
> >> > > On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
> >> > > > +               /* See of_device_resource_notify for populating interrupts */
> >> > > > +               for (i = 0; i < num_irq; i++, res++) {
> >> > > > +                       res->flags = IORESOURCE_IRQ;
> >> > > > +                       res->start = -EPROBE_DEFER;
> >> > > > +                       res->end = -EPROBE_DEFER;
> >> > >
> >> > > NAK.  Definitely a bad idea to start introducing magic values other into
> >> > > resources.  Please don't do this.
> >> >
> >> > Do you have any better ideas on how to sort out this issue then?
> >>
> >> I guess we could allocate all the resources lazily here, I'll take a look
> >> at that.
> >
> > Here's a version that allocates the resources lazily with the notifier.
> > Seems to boot, need to play with it a bit more though to make sure we're
> > not overwriting resources for any legacy devices.
> 
> Have you seen Thierry's series[1]? While your approach is certainly
> more concise, it seems like a work-around for the problem. I don't
> think a notifier is the right long term solution.

OK cool. I think we can fix the $Subject bug first without making all
those changes, then do the rest of the reorg for v3.14.

The bug is that we try to populate IRQ resources at a wrong time
when they may not exist.

Based on a quick look it seems we could combine Thierry's addition
of the new function of_platform_probe(struct platform_device *pdev)
and use that to allocate all resources at driver probe time like my
patch is doing. And then there's no need for the notifier.

Regards,

Tony

 
> [1] http://www.spinics.net/lists/arm-kernel/msg274110.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Thierry Reding]

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

On Sat, Nov 23, 2013 at 08:32:40AM -0800, Tony Lindgren wrote:
> * Rob Herring <robherring2@gmail.com> [131123 07:43]:
> > On Fri, Nov 22, 2013 at 7:50 PM, Tony Lindgren <tony@atomide.com> wrote:
> > > * Tony Lindgren <tony@atomide.com> [131122 17:16]:
> > >> * Tony Lindgren <tony@atomide.com> [131122 17:09]:
> > >> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [131122 16:56]:
> > >> > > On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
> > >> > > > +               /* See of_device_resource_notify for populating interrupts */
> > >> > > > +               for (i = 0; i < num_irq; i++, res++) {
> > >> > > > +                       res->flags = IORESOURCE_IRQ;
> > >> > > > +                       res->start = -EPROBE_DEFER;
> > >> > > > +                       res->end = -EPROBE_DEFER;
> > >> > >
> > >> > > NAK.  Definitely a bad idea to start introducing magic values other into
> > >> > > resources.  Please don't do this.
> > >> >
> > >> > Do you have any better ideas on how to sort out this issue then?
> > >>
> > >> I guess we could allocate all the resources lazily here, I'll take a look
> > >> at that.
> > >
> > > Here's a version that allocates the resources lazily with the notifier.
> > > Seems to boot, need to play with it a bit more though to make sure we're
> > > not overwriting resources for any legacy devices.
> > 
> > Have you seen Thierry's series[1]? While your approach is certainly
> > more concise, it seems like a work-around for the problem. I don't
> > think a notifier is the right long term solution.
> 
> OK cool. I think we can fix the $Subject bug first without making all
> those changes, then do the rest of the reorg for v3.14.
> 
> The bug is that we try to populate IRQ resources at a wrong time
> when they may not exist.
> 
> Based on a quick look it seems we could combine Thierry's addition
> of the new function of_platform_probe(struct platform_device *pdev)
> and use that to allocate all resources at driver probe time like my
> patch is doing. And then there's no need for the notifier.

My series already does the allocation at probe time as well. That was
the whole point. The reason why I added of_platform_probe() is because I
think we'll be needing this for other types of resources in the future
as well, so it could serve as a central place to do all of that.

There was also a proposal[0] by Arnd a few weeks ago that solved this in
a more generic way. I've said it before, and I'll say again that the
idea scares me somewhat, but it does solve some interesting aspects and
has the potential to get rid of a whole lot of boilerplate code. While
the original purpose was to handle all things devm_*(), I suspect that
same mechanism could be used to resolve DT references at probe time.

Thierry

[0]: http://www.spinics.net/lists/devicetree/msg10684.html

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

[PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Thierry Reding]

On Sat, Nov 23, 2013 at 08:32:40AM -0800, Tony Lindgren wrote:
> * Rob Herring <robherring2@gmail.com> [131123 07:43]:
> > On Fri, Nov 22, 2013 at 7:50 PM, Tony Lindgren <tony@atomide.com> wrote:
> > > * Tony Lindgren <tony@atomide.com> [131122 17:16]:
> > >> * Tony Lindgren <tony@atomide.com> [131122 17:09]:
> > >> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [131122 16:56]:
> > >> > > On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
> > >> > > > +               /* See of_device_resource_notify for populating interrupts */
> > >> > > > +               for (i = 0; i < num_irq; i++, res++) {
> > >> > > > +                       res->flags = IORESOURCE_IRQ;
> > >> > > > +                       res->start = -EPROBE_DEFER;
> > >> > > > +                       res->end = -EPROBE_DEFER;
> > >> > >
> > >> > > NAK.  Definitely a bad idea to start introducing magic values other into
> > >> > > resources.  Please don't do this.
> > >> >
> > >> > Do you have any better ideas on how to sort out this issue then?
> > >>
> > >> I guess we could allocate all the resources lazily here, I'll take a look
> > >> at that.
> > >
> > > Here's a version that allocates the resources lazily with the notifier.
> > > Seems to boot, need to play with it a bit more though to make sure we're
> > > not overwriting resources for any legacy devices.
> > 
> > Have you seen Thierry's series[1]? While your approach is certainly
> > more concise, it seems like a work-around for the problem. I don't
> > think a notifier is the right long term solution.
> 
> OK cool. I think we can fix the $Subject bug first without making all
> those changes, then do the rest of the reorg for v3.14.
> 
> The bug is that we try to populate IRQ resources at a wrong time
> when they may not exist.
> 
> Based on a quick look it seems we could combine Thierry's addition
> of the new function of_platform_probe(struct platform_device *pdev)
> and use that to allocate all resources at driver probe time like my
> patch is doing. And then there's no need for the notifier.

My series already does the allocation at probe time as well. That was
the whole point. The reason why I added of_platform_probe() is because I
think we'll be needing this for other types of resources in the future
as well, so it could serve as a central place to do all of that.

There was also a proposal[0] by Arnd a few weeks ago that solved this in
a more generic way. I've said it before, and I'll say again that the
idea scares me somewhat, but it does solve some interesting aspects and
has the potential to get rid of a whole lot of boilerplate code. While
the original purpose was to handle all things devm_*(), I suspect that
same mechanism could be used to resolve DT references at probe time.

Thierry

[0]: http://www.spinics.net/lists/devicetree/msg10684.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131125/dced6001/attachment.sig>

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Thierry Reding]

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

On Sat, Nov 23, 2013 at 08:32:40AM -0800, Tony Lindgren wrote:
> * Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [131123 07:43]:
> > On Fri, Nov 22, 2013 at 7:50 PM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> > > * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [131122 17:16]:
> > >> * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [131122 17:09]:
> > >> > * Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> [131122 16:56]:
> > >> > > On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
> > >> > > > +               /* See of_device_resource_notify for populating interrupts */
> > >> > > > +               for (i = 0; i < num_irq; i++, res++) {
> > >> > > > +                       res->flags = IORESOURCE_IRQ;
> > >> > > > +                       res->start = -EPROBE_DEFER;
> > >> > > > +                       res->end = -EPROBE_DEFER;
> > >> > >
> > >> > > NAK.  Definitely a bad idea to start introducing magic values other into
> > >> > > resources.  Please don't do this.
> > >> >
> > >> > Do you have any better ideas on how to sort out this issue then?
> > >>
> > >> I guess we could allocate all the resources lazily here, I'll take a look
> > >> at that.
> > >
> > > Here's a version that allocates the resources lazily with the notifier.
> > > Seems to boot, need to play with it a bit more though to make sure we're
> > > not overwriting resources for any legacy devices.
> > 
> > Have you seen Thierry's series[1]? While your approach is certainly
> > more concise, it seems like a work-around for the problem. I don't
> > think a notifier is the right long term solution.
> 
> OK cool. I think we can fix the $Subject bug first without making all
> those changes, then do the rest of the reorg for v3.14.
> 
> The bug is that we try to populate IRQ resources at a wrong time
> when they may not exist.
> 
> Based on a quick look it seems we could combine Thierry's addition
> of the new function of_platform_probe(struct platform_device *pdev)
> and use that to allocate all resources at driver probe time like my
> patch is doing. And then there's no need for the notifier.

My series already does the allocation at probe time as well. That was
the whole point. The reason why I added of_platform_probe() is because I
think we'll be needing this for other types of resources in the future
as well, so it could serve as a central place to do all of that.

There was also a proposal[0] by Arnd a few weeks ago that solved this in
a more generic way. I've said it before, and I'll say again that the
idea scares me somewhat, but it does solve some interesting aspects and
has the potential to get rid of a whole lot of boilerplate code. While
the original purpose was to handle all things devm_*(), I suspect that
same mechanism could be used to resolve DT references at probe time.

Thierry

[0]: http://www.spinics.net/lists/devicetree/msg10684.html

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Tony Lindgren]

* Thierry Reding <thierry.reding@gmail.com> [131125 01:36]:
> On Sat, Nov 23, 2013 at 08:32:40AM -0800, Tony Lindgren wrote:
> > * Rob Herring <robherring2@gmail.com> [131123 07:43]:
> > > On Fri, Nov 22, 2013 at 7:50 PM, Tony Lindgren <tony@atomide.com> wrote:
> > > > * Tony Lindgren <tony@atomide.com> [131122 17:16]:
> > > >> * Tony Lindgren <tony@atomide.com> [131122 17:09]:
> > > >> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [131122 16:56]:
> > > >> > > On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
> > > >> > > > +               /* See of_device_resource_notify for populating interrupts */
> > > >> > > > +               for (i = 0; i < num_irq; i++, res++) {
> > > >> > > > +                       res->flags = IORESOURCE_IRQ;
> > > >> > > > +                       res->start = -EPROBE_DEFER;
> > > >> > > > +                       res->end = -EPROBE_DEFER;
> > > >> > >
> > > >> > > NAK.  Definitely a bad idea to start introducing magic values other into
> > > >> > > resources.  Please don't do this.
> > > >> >
> > > >> > Do you have any better ideas on how to sort out this issue then?
> > > >>
> > > >> I guess we could allocate all the resources lazily here, I'll take a look
> > > >> at that.
> > > >
> > > > Here's a version that allocates the resources lazily with the notifier.
> > > > Seems to boot, need to play with it a bit more though to make sure we're
> > > > not overwriting resources for any legacy devices.
> > > 
> > > Have you seen Thierry's series[1]? While your approach is certainly
> > > more concise, it seems like a work-around for the problem. I don't
> > > think a notifier is the right long term solution.
> > 
> > OK cool. I think we can fix the $Subject bug first without making all
> > those changes, then do the rest of the reorg for v3.14.
> > 
> > The bug is that we try to populate IRQ resources at a wrong time
> > when they may not exist.
> > 
> > Based on a quick look it seems we could combine Thierry's addition
> > of the new function of_platform_probe(struct platform_device *pdev)
> > and use that to allocate all resources at driver probe time like my
> > patch is doing. And then there's no need for the notifier.
> 
> My series already does the allocation at probe time as well. That was
> the whole point. The reason why I added of_platform_probe() is because I
> think we'll be needing this for other types of resources in the future
> as well, so it could serve as a central place to do all of that.

Yeah, that's the way to go in the long run. However, we currently do have
some dependencies to that data being there and bus specific code may
add legacy resources to it with platform_device_add_resources(). At least
omap_device_alloc() depends on that until v3.14 when mach-omap2 is booting
in DT only mode.
 
> There was also a proposal[0] by Arnd a few weeks ago that solved this in
> a more generic way. I've said it before, and I'll say again that the
> idea scares me somewhat, but it does solve some interesting aspects and
> has the potential to get rid of a whole lot of boilerplate code. While
> the original purpose was to handle all things devm_*(), I suspect that
> same mechanism could be used to resolve DT references at probe time.

Yes devm_alloc() should work once the legacy dependencies are out of the
way. We would need to audit where pdev->num_resources or pdev->resource is
being relied on, and where platform_device_add_resources() is being called
before the device probe. So I doubt we can do that all as a fix for the
-rc cycle.

Below is what I think might be limited enough to fix the $Subject bug for
the -rc cycle. I took the of_platform_probe() from your patch 08/10 to
avoid the notifier. Also added Greg to Cc as it's now touching
drivers/base/platform.c too.

Seems to work for my test cases, does this work for you guys?

Regards,

Tony
 
> [0]: http://www.spinics.net/lists/devicetree/msg10684.html

8< ---------------------

From: Tony Lindgren <tony@atomide.com>
Date: Mon, 25 Nov 2013 11:12:52 -0800
Subject: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

Currently we get the following kind of errors if we try to use interrupt
phandles to irqchips that have not yet initialized:

irq: no irq domain found for /ocp/pinmux@48002030 !
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
(show_stack+0x14/0x1c)
(dump_stack+0x6c/0xa0)
(warn_slowpath_common+0x64/0x84)
(warn_slowpath_null+0x1c/0x24)
(of_device_alloc+0x144/0x184)
(of_platform_device_create_pdata+0x44/0x9c)
(of_platform_bus_create+0xd0/0x170)
(of_platform_bus_create+0x12c/0x170)
(of_platform_populate+0x60/0x98)

This is because we're wrongly trying to populate resources that are not yet
available. It's perfectly valid to create irqchips dynamically, so let's
fix up the issue by populating the interrupt resources at the driver probe
time instead.

Note that at least currently we cannot dynamically allocate the resources as bus
specific code may add legacy resources with platform_device_add_resources()
before the driver probe. At least omap_device_alloc() currently relies on
num_resources to determine if legacy resources should be added. This issue
will get fixed automatically when mach-omap2 boots with DT only, but there
are probably other places too where platform_device_add_resources() modifies
things before driver probe.

The addition of of_platform_probe() is based on patches posted earlier by
Thierry Reding <thierry.reding@gmail.com>.

Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -481,6 +481,10 @@ static int platform_drv_probe(struct device *_dev)
 	struct platform_device *dev = to_platform_device(_dev);
 	int ret;
 
+	ret = of_platform_probe(dev);
+	if (ret)
+		return ret;
+
 	if (ACPI_HANDLE(_dev))
 		acpi_dev_pm_attach(_dev, true);
 
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -141,7 +141,7 @@ struct platform_device *of_device_alloc(struct device_node *np,
 				  struct device *parent)
 {
 	struct platform_device *dev;
-	int rc, i, num_reg = 0, num_irq;
+	int num_reg = 0, num_irq;
 	struct resource *res, temp_res;
 
 	dev = platform_device_alloc("", -1);
@@ -154,7 +154,14 @@ struct platform_device *of_device_alloc(struct device_node *np,
 			num_reg++;
 	num_irq = of_irq_count(np);
 
-	/* Populate the resource table */
+	/*
+	 * Only allocate the resources for us to use later on. Note that bus
+	 * specific code may also add in additional legacy resources using
+	 * platform_device_add_resources(), and may even rely on us allocating
+	 * the basic resources here to do so. So we cannot allocate the
+	 * resources lazily until the legacy code has been fixed to not rely
+	 * on allocating resources here.
+	 */
 	if (num_irq || num_reg) {
 		res = kzalloc(sizeof(*res) * (num_irq + num_reg), GFP_KERNEL);
 		if (!res) {
@@ -164,11 +171,7 @@ struct platform_device *of_device_alloc(struct device_node *np,
 
 		dev->num_resources = num_reg + num_irq;
 		dev->resource = res;
-		for (i = 0; i < num_reg; i++, res++) {
-			rc = of_address_to_resource(np, i, res);
-			WARN_ON(rc);
-		}
-		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
+		/* See of_device_resource_populate for populating the data */
 	}
 
 	dev->dev.of_node = of_node_get(np);
@@ -187,6 +190,50 @@ struct platform_device *of_device_alloc(struct device_node *np,
 EXPORT_SYMBOL(of_device_alloc);
 
 /**
+ * of_device_resource_populate - Populate device resources from device tree
+ * @dev: pointer to platform device
+ *
+ * The device interrupts are not necessarily available for all
+ * irqdomains initially so we need to populate them lazily at
+ * device probe time from of_platform_populate.
+ */
+static int of_device_resource_populate(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	int rc, i, num_reg = 0, num_irq;
+	struct resource *res, temp_res;
+
+	res = pdev->resource;
+
+	/*
+	 * Count the io and irq resources again. Currently we cannot rely on
+	 * pdev->num_resources as bus specific code may have changed that
+	 * with platform_device_add_resources(). But the resources we allocated
+	 * earlier are still there and available for us to populate.
+	 */
+	if (of_can_translate_address(np))
+		while (of_address_to_resource(np, num_reg, &temp_res) == 0)
+			num_reg++;
+	num_irq = of_irq_count(np);
+
+	if (pdev->num_resources < num_reg + num_irq) {
+		dev_WARN(&pdev->dev, "not enough resources %i < %i\n",
+			 pdev->num_resources, num_reg + num_irq);
+		return -EINVAL;
+	}
+
+	for (i = 0; i < num_reg; i++, res++) {
+		rc = of_address_to_resource(np, i, res);
+		WARN_ON(rc);
+	}
+
+	if (num_irq)
+		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
+
+	return 0;
+}
+
+/**
  * of_platform_device_create_pdata - Alloc, initialize and register an of_device
  * @np: pointer to node to create device for
  * @bus_id: name to assign device
@@ -488,4 +535,35 @@ int of_platform_populate(struct device_node *root,
 	return rc;
 }
 EXPORT_SYMBOL_GPL(of_platform_populate);
+
+/**
+ * of_platform_probe() - OF specific initialization at probe time
+ * @pdev: pointer to a platform device
+ *
+ * This function is called by the driver core to perform devicetree-specific
+ * setup for a given platform device at probe time. If a device's resources
+ * as specified in the device tree are not available yet, this function can
+ * return -EPROBE_DEFER and cause the device to be probed again later, when
+ * other drivers that potentially provide the missing resources have been
+ * probed in turn.
+ *
+ * Note that because of the above, all code executed by this function must
+ * be prepared to be run multiple times on the same device (i.e. it must be
+ * idempotent).
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int of_platform_probe(struct platform_device *pdev)
+{
+	int ret;
+
+	if (!pdev->dev.of_node)
+		return 0;
+
+	ret = of_device_resource_populate(pdev);
+	if (ret < 0)
+		return ret;
+
+	return 0;
+}
 #endif /* CONFIG_OF_ADDRESS */
--- a/include/linux/of_platform.h
+++ b/include/linux/of_platform.h
@@ -72,6 +72,8 @@ extern int of_platform_populate(struct device_node *root,
 				const struct of_device_id *matches,
 				const struct of_dev_auxdata *lookup,
 				struct device *parent);
+
+extern int of_platform_probe(struct platform_device *pdev);
 #else
 static inline int of_platform_populate(struct device_node *root,
 					const struct of_device_id *matches,
@@ -80,6 +82,11 @@ static inline int of_platform_populate(struct device_node *root,
 {
 	return -ENODEV;
 }
+
+static inline int of_platform_probe(struct platform_device *pdev)
+{
+	return 0;
+}
 #endif
 
 #endif	/* _LINUX_OF_PLATFORM_H */

[PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Tony Lindgren]

* Thierry Reding <thierry.reding@gmail.com> [131125 01:36]:
> On Sat, Nov 23, 2013 at 08:32:40AM -0800, Tony Lindgren wrote:
> > * Rob Herring <robherring2@gmail.com> [131123 07:43]:
> > > On Fri, Nov 22, 2013 at 7:50 PM, Tony Lindgren <tony@atomide.com> wrote:
> > > > * Tony Lindgren <tony@atomide.com> [131122 17:16]:
> > > >> * Tony Lindgren <tony@atomide.com> [131122 17:09]:
> > > >> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [131122 16:56]:
> > > >> > > On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
> > > >> > > > +               /* See of_device_resource_notify for populating interrupts */
> > > >> > > > +               for (i = 0; i < num_irq; i++, res++) {
> > > >> > > > +                       res->flags = IORESOURCE_IRQ;
> > > >> > > > +                       res->start = -EPROBE_DEFER;
> > > >> > > > +                       res->end = -EPROBE_DEFER;
> > > >> > >
> > > >> > > NAK.  Definitely a bad idea to start introducing magic values other into
> > > >> > > resources.  Please don't do this.
> > > >> >
> > > >> > Do you have any better ideas on how to sort out this issue then?
> > > >>
> > > >> I guess we could allocate all the resources lazily here, I'll take a look
> > > >> at that.
> > > >
> > > > Here's a version that allocates the resources lazily with the notifier.
> > > > Seems to boot, need to play with it a bit more though to make sure we're
> > > > not overwriting resources for any legacy devices.
> > > 
> > > Have you seen Thierry's series[1]? While your approach is certainly
> > > more concise, it seems like a work-around for the problem. I don't
> > > think a notifier is the right long term solution.
> > 
> > OK cool. I think we can fix the $Subject bug first without making all
> > those changes, then do the rest of the reorg for v3.14.
> > 
> > The bug is that we try to populate IRQ resources at a wrong time
> > when they may not exist.
> > 
> > Based on a quick look it seems we could combine Thierry's addition
> > of the new function of_platform_probe(struct platform_device *pdev)
> > and use that to allocate all resources at driver probe time like my
> > patch is doing. And then there's no need for the notifier.
> 
> My series already does the allocation at probe time as well. That was
> the whole point. The reason why I added of_platform_probe() is because I
> think we'll be needing this for other types of resources in the future
> as well, so it could serve as a central place to do all of that.

Yeah, that's the way to go in the long run. However, we currently do have
some dependencies to that data being there and bus specific code may
add legacy resources to it with platform_device_add_resources(). At least
omap_device_alloc() depends on that until v3.14 when mach-omap2 is booting
in DT only mode.
 
> There was also a proposal[0] by Arnd a few weeks ago that solved this in
> a more generic way. I've said it before, and I'll say again that the
> idea scares me somewhat, but it does solve some interesting aspects and
> has the potential to get rid of a whole lot of boilerplate code. While
> the original purpose was to handle all things devm_*(), I suspect that
> same mechanism could be used to resolve DT references at probe time.

Yes devm_alloc() should work once the legacy dependencies are out of the
way. We would need to audit where pdev->num_resources or pdev->resource is
being relied on, and where platform_device_add_resources() is being called
before the device probe. So I doubt we can do that all as a fix for the
-rc cycle.

Below is what I think might be limited enough to fix the $Subject bug for
the -rc cycle. I took the of_platform_probe() from your patch 08/10 to
avoid the notifier. Also added Greg to Cc as it's now touching
drivers/base/platform.c too.

Seems to work for my test cases, does this work for you guys?

Regards,

Tony
 
> [0]: http://www.spinics.net/lists/devicetree/msg10684.html

8< ---------------------

From: Tony Lindgren <tony@atomide.com>
Date: Mon, 25 Nov 2013 11:12:52 -0800
Subject: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

Currently we get the following kind of errors if we try to use interrupt
phandles to irqchips that have not yet initialized:

irq: no irq domain found for /ocp/pinmux at 48002030 !
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
(show_stack+0x14/0x1c)
(dump_stack+0x6c/0xa0)
(warn_slowpath_common+0x64/0x84)
(warn_slowpath_null+0x1c/0x24)
(of_device_alloc+0x144/0x184)
(of_platform_device_create_pdata+0x44/0x9c)
(of_platform_bus_create+0xd0/0x170)
(of_platform_bus_create+0x12c/0x170)
(of_platform_populate+0x60/0x98)

This is because we're wrongly trying to populate resources that are not yet
available. It's perfectly valid to create irqchips dynamically, so let's
fix up the issue by populating the interrupt resources at the driver probe
time instead.

Note that at least currently we cannot dynamically allocate the resources as bus
specific code may add legacy resources with platform_device_add_resources()
before the driver probe. At least omap_device_alloc() currently relies on
num_resources to determine if legacy resources should be added. This issue
will get fixed automatically when mach-omap2 boots with DT only, but there
are probably other places too where platform_device_add_resources() modifies
things before driver probe.

The addition of of_platform_probe() is based on patches posted earlier by
Thierry Reding <thierry.reding@gmail.com>.

Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -481,6 +481,10 @@ static int platform_drv_probe(struct device *_dev)
 	struct platform_device *dev = to_platform_device(_dev);
 	int ret;
 
+	ret = of_platform_probe(dev);
+	if (ret)
+		return ret;
+
 	if (ACPI_HANDLE(_dev))
 		acpi_dev_pm_attach(_dev, true);
 
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -141,7 +141,7 @@ struct platform_device *of_device_alloc(struct device_node *np,
 				  struct device *parent)
 {
 	struct platform_device *dev;
-	int rc, i, num_reg = 0, num_irq;
+	int num_reg = 0, num_irq;
 	struct resource *res, temp_res;
 
 	dev = platform_device_alloc("", -1);
@@ -154,7 +154,14 @@ struct platform_device *of_device_alloc(struct device_node *np,
 			num_reg++;
 	num_irq = of_irq_count(np);
 
-	/* Populate the resource table */
+	/*
+	 * Only allocate the resources for us to use later on. Note that bus
+	 * specific code may also add in additional legacy resources using
+	 * platform_device_add_resources(), and may even rely on us allocating
+	 * the basic resources here to do so. So we cannot allocate the
+	 * resources lazily until the legacy code has been fixed to not rely
+	 * on allocating resources here.
+	 */
 	if (num_irq || num_reg) {
 		res = kzalloc(sizeof(*res) * (num_irq + num_reg), GFP_KERNEL);
 		if (!res) {
@@ -164,11 +171,7 @@ struct platform_device *of_device_alloc(struct device_node *np,
 
 		dev->num_resources = num_reg + num_irq;
 		dev->resource = res;
-		for (i = 0; i < num_reg; i++, res++) {
-			rc = of_address_to_resource(np, i, res);
-			WARN_ON(rc);
-		}
-		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
+		/* See of_device_resource_populate for populating the data */
 	}
 
 	dev->dev.of_node = of_node_get(np);
@@ -187,6 +190,50 @@ struct platform_device *of_device_alloc(struct device_node *np,
 EXPORT_SYMBOL(of_device_alloc);
 
 /**
+ * of_device_resource_populate - Populate device resources from device tree
+ * @dev: pointer to platform device
+ *
+ * The device interrupts are not necessarily available for all
+ * irqdomains initially so we need to populate them lazily at
+ * device probe time from of_platform_populate.
+ */
+static int of_device_resource_populate(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	int rc, i, num_reg = 0, num_irq;
+	struct resource *res, temp_res;
+
+	res = pdev->resource;
+
+	/*
+	 * Count the io and irq resources again. Currently we cannot rely on
+	 * pdev->num_resources as bus specific code may have changed that
+	 * with platform_device_add_resources(). But the resources we allocated
+	 * earlier are still there and available for us to populate.
+	 */
+	if (of_can_translate_address(np))
+		while (of_address_to_resource(np, num_reg, &temp_res) == 0)
+			num_reg++;
+	num_irq = of_irq_count(np);
+
+	if (pdev->num_resources < num_reg + num_irq) {
+		dev_WARN(&pdev->dev, "not enough resources %i < %i\n",
+			 pdev->num_resources, num_reg + num_irq);
+		return -EINVAL;
+	}
+
+	for (i = 0; i < num_reg; i++, res++) {
+		rc = of_address_to_resource(np, i, res);
+		WARN_ON(rc);
+	}
+
+	if (num_irq)
+		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
+
+	return 0;
+}
+
+/**
  * of_platform_device_create_pdata - Alloc, initialize and register an of_device
  * @np: pointer to node to create device for
  * @bus_id: name to assign device
@@ -488,4 +535,35 @@ int of_platform_populate(struct device_node *root,
 	return rc;
 }
 EXPORT_SYMBOL_GPL(of_platform_populate);
+
+/**
+ * of_platform_probe() - OF specific initialization at probe time
+ * @pdev: pointer to a platform device
+ *
+ * This function is called by the driver core to perform devicetree-specific
+ * setup for a given platform device@probe time. If a device's resources
+ * as specified in the device tree are not available yet, this function can
+ * return -EPROBE_DEFER and cause the device to be probed again later, when
+ * other drivers that potentially provide the missing resources have been
+ * probed in turn.
+ *
+ * Note that because of the above, all code executed by this function must
+ * be prepared to be run multiple times on the same device (i.e. it must be
+ * idempotent).
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int of_platform_probe(struct platform_device *pdev)
+{
+	int ret;
+
+	if (!pdev->dev.of_node)
+		return 0;
+
+	ret = of_device_resource_populate(pdev);
+	if (ret < 0)
+		return ret;
+
+	return 0;
+}
 #endif /* CONFIG_OF_ADDRESS */
--- a/include/linux/of_platform.h
+++ b/include/linux/of_platform.h
@@ -72,6 +72,8 @@ extern int of_platform_populate(struct device_node *root,
 				const struct of_device_id *matches,
 				const struct of_dev_auxdata *lookup,
 				struct device *parent);
+
+extern int of_platform_probe(struct platform_device *pdev);
 #else
 static inline int of_platform_populate(struct device_node *root,
 					const struct of_device_id *matches,
@@ -80,6 +82,11 @@ static inline int of_platform_populate(struct device_node *root,
 {
 	return -ENODEV;
 }
+
+static inline int of_platform_probe(struct platform_device *pdev)
+{
+	return 0;
+}
 #endif
 
 #endif	/* _LINUX_OF_PLATFORM_H */

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Tony Lindgren]

* Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [131125 01:36]:
> On Sat, Nov 23, 2013 at 08:32:40AM -0800, Tony Lindgren wrote:
> > * Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [131123 07:43]:
> > > On Fri, Nov 22, 2013 at 7:50 PM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> > > > * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [131122 17:16]:
> > > >> * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [131122 17:09]:
> > > >> > * Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> [131122 16:56]:
> > > >> > > On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
> > > >> > > > +               /* See of_device_resource_notify for populating interrupts */
> > > >> > > > +               for (i = 0; i < num_irq; i++, res++) {
> > > >> > > > +                       res->flags = IORESOURCE_IRQ;
> > > >> > > > +                       res->start = -EPROBE_DEFER;
> > > >> > > > +                       res->end = -EPROBE_DEFER;
> > > >> > >
> > > >> > > NAK.  Definitely a bad idea to start introducing magic values other into
> > > >> > > resources.  Please don't do this.
> > > >> >
> > > >> > Do you have any better ideas on how to sort out this issue then?
> > > >>
> > > >> I guess we could allocate all the resources lazily here, I'll take a look
> > > >> at that.
> > > >
> > > > Here's a version that allocates the resources lazily with the notifier.
> > > > Seems to boot, need to play with it a bit more though to make sure we're
> > > > not overwriting resources for any legacy devices.
> > > 
> > > Have you seen Thierry's series[1]? While your approach is certainly
> > > more concise, it seems like a work-around for the problem. I don't
> > > think a notifier is the right long term solution.
> > 
> > OK cool. I think we can fix the $Subject bug first without making all
> > those changes, then do the rest of the reorg for v3.14.
> > 
> > The bug is that we try to populate IRQ resources at a wrong time
> > when they may not exist.
> > 
> > Based on a quick look it seems we could combine Thierry's addition
> > of the new function of_platform_probe(struct platform_device *pdev)
> > and use that to allocate all resources at driver probe time like my
> > patch is doing. And then there's no need for the notifier.
> 
> My series already does the allocation at probe time as well. That was
> the whole point. The reason why I added of_platform_probe() is because I
> think we'll be needing this for other types of resources in the future
> as well, so it could serve as a central place to do all of that.

Yeah, that's the way to go in the long run. However, we currently do have
some dependencies to that data being there and bus specific code may
add legacy resources to it with platform_device_add_resources(). At least
omap_device_alloc() depends on that until v3.14 when mach-omap2 is booting
in DT only mode.
 
> There was also a proposal[0] by Arnd a few weeks ago that solved this in
> a more generic way. I've said it before, and I'll say again that the
> idea scares me somewhat, but it does solve some interesting aspects and
> has the potential to get rid of a whole lot of boilerplate code. While
> the original purpose was to handle all things devm_*(), I suspect that
> same mechanism could be used to resolve DT references at probe time.

Yes devm_alloc() should work once the legacy dependencies are out of the
way. We would need to audit where pdev->num_resources or pdev->resource is
being relied on, and where platform_device_add_resources() is being called
before the device probe. So I doubt we can do that all as a fix for the
-rc cycle.

Below is what I think might be limited enough to fix the $Subject bug for
the -rc cycle. I took the of_platform_probe() from your patch 08/10 to
avoid the notifier. Also added Greg to Cc as it's now touching
drivers/base/platform.c too.

Seems to work for my test cases, does this work for you guys?

Regards,

Tony
 
> [0]: http://www.spinics.net/lists/devicetree/msg10684.html

8< ---------------------

From: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Date: Mon, 25 Nov 2013 11:12:52 -0800
Subject: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

Currently we get the following kind of errors if we try to use interrupt
phandles to irqchips that have not yet initialized:

irq: no irq domain found for /ocp/pinmux@48002030 !
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
(show_stack+0x14/0x1c)
(dump_stack+0x6c/0xa0)
(warn_slowpath_common+0x64/0x84)
(warn_slowpath_null+0x1c/0x24)
(of_device_alloc+0x144/0x184)
(of_platform_device_create_pdata+0x44/0x9c)
(of_platform_bus_create+0xd0/0x170)
(of_platform_bus_create+0x12c/0x170)
(of_platform_populate+0x60/0x98)

This is because we're wrongly trying to populate resources that are not yet
available. It's perfectly valid to create irqchips dynamically, so let's
fix up the issue by populating the interrupt resources at the driver probe
time instead.

Note that at least currently we cannot dynamically allocate the resources as bus
specific code may add legacy resources with platform_device_add_resources()
before the driver probe. At least omap_device_alloc() currently relies on
num_resources to determine if legacy resources should be added. This issue
will get fixed automatically when mach-omap2 boots with DT only, but there
are probably other places too where platform_device_add_resources() modifies
things before driver probe.

The addition of of_platform_probe() is based on patches posted earlier by
Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>.

Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>

--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -481,6 +481,10 @@ static int platform_drv_probe(struct device *_dev)
 	struct platform_device *dev = to_platform_device(_dev);
 	int ret;
 
+	ret = of_platform_probe(dev);
+	if (ret)
+		return ret;
+
 	if (ACPI_HANDLE(_dev))
 		acpi_dev_pm_attach(_dev, true);
 
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -141,7 +141,7 @@ struct platform_device *of_device_alloc(struct device_node *np,
 				  struct device *parent)
 {
 	struct platform_device *dev;
-	int rc, i, num_reg = 0, num_irq;
+	int num_reg = 0, num_irq;
 	struct resource *res, temp_res;
 
 	dev = platform_device_alloc("", -1);
@@ -154,7 +154,14 @@ struct platform_device *of_device_alloc(struct device_node *np,
 			num_reg++;
 	num_irq = of_irq_count(np);
 
-	/* Populate the resource table */
+	/*
+	 * Only allocate the resources for us to use later on. Note that bus
+	 * specific code may also add in additional legacy resources using
+	 * platform_device_add_resources(), and may even rely on us allocating
+	 * the basic resources here to do so. So we cannot allocate the
+	 * resources lazily until the legacy code has been fixed to not rely
+	 * on allocating resources here.
+	 */
 	if (num_irq || num_reg) {
 		res = kzalloc(sizeof(*res) * (num_irq + num_reg), GFP_KERNEL);
 		if (!res) {
@@ -164,11 +171,7 @@ struct platform_device *of_device_alloc(struct device_node *np,
 
 		dev->num_resources = num_reg + num_irq;
 		dev->resource = res;
-		for (i = 0; i < num_reg; i++, res++) {
-			rc = of_address_to_resource(np, i, res);
-			WARN_ON(rc);
-		}
-		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
+		/* See of_device_resource_populate for populating the data */
 	}
 
 	dev->dev.of_node = of_node_get(np);
@@ -187,6 +190,50 @@ struct platform_device *of_device_alloc(struct device_node *np,
 EXPORT_SYMBOL(of_device_alloc);
 
 /**
+ * of_device_resource_populate - Populate device resources from device tree
+ * @dev: pointer to platform device
+ *
+ * The device interrupts are not necessarily available for all
+ * irqdomains initially so we need to populate them lazily at
+ * device probe time from of_platform_populate.
+ */
+static int of_device_resource_populate(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	int rc, i, num_reg = 0, num_irq;
+	struct resource *res, temp_res;
+
+	res = pdev->resource;
+
+	/*
+	 * Count the io and irq resources again. Currently we cannot rely on
+	 * pdev->num_resources as bus specific code may have changed that
+	 * with platform_device_add_resources(). But the resources we allocated
+	 * earlier are still there and available for us to populate.
+	 */
+	if (of_can_translate_address(np))
+		while (of_address_to_resource(np, num_reg, &temp_res) == 0)
+			num_reg++;
+	num_irq = of_irq_count(np);
+
+	if (pdev->num_resources < num_reg + num_irq) {
+		dev_WARN(&pdev->dev, "not enough resources %i < %i\n",
+			 pdev->num_resources, num_reg + num_irq);
+		return -EINVAL;
+	}
+
+	for (i = 0; i < num_reg; i++, res++) {
+		rc = of_address_to_resource(np, i, res);
+		WARN_ON(rc);
+	}
+
+	if (num_irq)
+		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
+
+	return 0;
+}
+
+/**
  * of_platform_device_create_pdata - Alloc, initialize and register an of_device
  * @np: pointer to node to create device for
  * @bus_id: name to assign device
@@ -488,4 +535,35 @@ int of_platform_populate(struct device_node *root,
 	return rc;
 }
 EXPORT_SYMBOL_GPL(of_platform_populate);
+
+/**
+ * of_platform_probe() - OF specific initialization at probe time
+ * @pdev: pointer to a platform device
+ *
+ * This function is called by the driver core to perform devicetree-specific
+ * setup for a given platform device at probe time. If a device's resources
+ * as specified in the device tree are not available yet, this function can
+ * return -EPROBE_DEFER and cause the device to be probed again later, when
+ * other drivers that potentially provide the missing resources have been
+ * probed in turn.
+ *
+ * Note that because of the above, all code executed by this function must
+ * be prepared to be run multiple times on the same device (i.e. it must be
+ * idempotent).
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int of_platform_probe(struct platform_device *pdev)
+{
+	int ret;
+
+	if (!pdev->dev.of_node)
+		return 0;
+
+	ret = of_device_resource_populate(pdev);
+	if (ret < 0)
+		return ret;
+
+	return 0;
+}
 #endif /* CONFIG_OF_ADDRESS */
--- a/include/linux/of_platform.h
+++ b/include/linux/of_platform.h
@@ -72,6 +72,8 @@ extern int of_platform_populate(struct device_node *root,
 				const struct of_device_id *matches,
 				const struct of_dev_auxdata *lookup,
 				struct device *parent);
+
+extern int of_platform_probe(struct platform_device *pdev);
 #else
 static inline int of_platform_populate(struct device_node *root,
 					const struct of_device_id *matches,
@@ -80,6 +82,11 @@ static inline int of_platform_populate(struct device_node *root,
 {
 	return -ENODEV;
 }
+
+static inline int of_platform_probe(struct platform_device *pdev)
+{
+	return 0;
+}
 #endif
 
 #endif	/* _LINUX_OF_PLATFORM_H */
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Grant Likely]

On Fri, 22 Nov 2013 17:50:35 -0800, Tony Lindgren <tony@atomide.com> wrote:
> * Tony Lindgren <tony@atomide.com> [131122 17:16]:
> > * Tony Lindgren <tony@atomide.com> [131122 17:09]:
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [131122 16:56]:
> > > > On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
> > > > > +		/* See of_device_resource_notify for populating interrupts */
> > > > > +		for (i = 0; i < num_irq; i++, res++) {
> > > > > +			res->flags = IORESOURCE_IRQ;
> > > > > +			res->start = -EPROBE_DEFER;
> > > > > +			res->end = -EPROBE_DEFER;
> > > > 
> > > > NAK.  Definitely a bad idea to start introducing magic values other into
> > > > resources.  Please don't do this.
> > > 
> > > Do you have any better ideas on how to sort out this issue then?
> > 
> > I guess we could allocate all the resources lazily here, I'll take a look
> > at that.
> 
> Here's a version that allocates the resources lazily with the notifier.
> Seems to boot, need to play with it a bit more though to make sure we're
> not overwriting resources for any legacy devices.

Blurg. Using a notifier really feels like we don't have a good handle on
a reasonable solution yet. Basically it means we're hooking into the
driver core without /looking/ like we're hooking into the driver core. I
don't think this is any better, but I don't have a better suggestion at
the moment.   :-(

g.

[PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Grant Likely]

On Fri, 22 Nov 2013 17:50:35 -0800, Tony Lindgren <tony@atomide.com> wrote:
> * Tony Lindgren <tony@atomide.com> [131122 17:16]:
> > * Tony Lindgren <tony@atomide.com> [131122 17:09]:
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [131122 16:56]:
> > > > On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
> > > > > +		/* See of_device_resource_notify for populating interrupts */
> > > > > +		for (i = 0; i < num_irq; i++, res++) {
> > > > > +			res->flags = IORESOURCE_IRQ;
> > > > > +			res->start = -EPROBE_DEFER;
> > > > > +			res->end = -EPROBE_DEFER;
> > > > 
> > > > NAK.  Definitely a bad idea to start introducing magic values other into
> > > > resources.  Please don't do this.
> > > 
> > > Do you have any better ideas on how to sort out this issue then?
> > 
> > I guess we could allocate all the resources lazily here, I'll take a look
> > at that.
> 
> Here's a version that allocates the resources lazily with the notifier.
> Seems to boot, need to play with it a bit more though to make sure we're
> not overwriting resources for any legacy devices.

Blurg. Using a notifier really feels like we don't have a good handle on
a reasonable solution yet. Basically it means we're hooking into the
driver core without /looking/ like we're hooking into the driver core. I
don't think this is any better, but I don't have a better suggestion at
the moment.   :-(

g.

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Paul Walmsley]

Hi Grant, Rob,

On Sun, 24 Nov 2013, Grant Likely wrote:

> On Fri, 22 Nov 2013 17:50:35 -0800, Tony Lindgren <tony@atomide.com> wrote:
> > * Tony Lindgren <tony@atomide.com> [131122 17:16]:
> > > * Tony Lindgren <tony@atomide.com> [131122 17:09]:
> > > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [131122 16:56]:
> > > > > On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
> > > > > > +		/* See of_device_resource_notify for populating interrupts */
> > > > > > +		for (i = 0; i < num_irq; i++, res++) {
> > > > > > +			res->flags = IORESOURCE_IRQ;
> > > > > > +			res->start = -EPROBE_DEFER;
> > > > > > +			res->end = -EPROBE_DEFER;
> > > > > 
> > > > > NAK.  Definitely a bad idea to start introducing magic values other into
> > > > > resources.  Please don't do this.
> > > > 
> > > > Do you have any better ideas on how to sort out this issue then?
> > > 
> > > I guess we could allocate all the resources lazily here, I'll take a look
> > > at that.
> > 
> > Here's a version that allocates the resources lazily with the notifier.
> > Seems to boot, need to play with it a bit more though to make sure we're
> > not overwriting resources for any legacy devices.
> 
> Blurg. Using a notifier really feels like we don't have a good handle on
> a reasonable solution yet. Basically it means we're hooking into the
> driver core without /looking/ like we're hooking into the driver core. I
> don't think this is any better, but I don't have a better suggestion at
> the moment.   :-(

Unfortunately this patch, or something that accomplishes the same results, 
is somewhat high-priority for us on OMAP.  OMAP37xx got prematurely 
converted to DT booting, and now dynamic power management is broken:

    http://marc.info/?l=linux-arm-kernel&m=138658294830408&w=2

Tony writes that this patch is one of the two patches needed to get things 
working again:

    http://marc.info/?l=linux-arm-kernel&m=138660942506846&w=2

Is it possible to get this patch, or something similar, merged for 
v3.13-rc?

Once something like PM is broken, it's pretty easy for other broken 
patches to make it into the tree, since it becomes very difficult to test 
without turning into a maintainer denial-of-service attack.


- Paul

[PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Paul Walmsley]

Hi Grant, Rob,

On Sun, 24 Nov 2013, Grant Likely wrote:

> On Fri, 22 Nov 2013 17:50:35 -0800, Tony Lindgren <tony@atomide.com> wrote:
> > * Tony Lindgren <tony@atomide.com> [131122 17:16]:
> > > * Tony Lindgren <tony@atomide.com> [131122 17:09]:
> > > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [131122 16:56]:
> > > > > On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
> > > > > > +		/* See of_device_resource_notify for populating interrupts */
> > > > > > +		for (i = 0; i < num_irq; i++, res++) {
> > > > > > +			res->flags = IORESOURCE_IRQ;
> > > > > > +			res->start = -EPROBE_DEFER;
> > > > > > +			res->end = -EPROBE_DEFER;
> > > > > 
> > > > > NAK.  Definitely a bad idea to start introducing magic values other into
> > > > > resources.  Please don't do this.
> > > > 
> > > > Do you have any better ideas on how to sort out this issue then?
> > > 
> > > I guess we could allocate all the resources lazily here, I'll take a look
> > > at that.
> > 
> > Here's a version that allocates the resources lazily with the notifier.
> > Seems to boot, need to play with it a bit more though to make sure we're
> > not overwriting resources for any legacy devices.
> 
> Blurg. Using a notifier really feels like we don't have a good handle on
> a reasonable solution yet. Basically it means we're hooking into the
> driver core without /looking/ like we're hooking into the driver core. I
> don't think this is any better, but I don't have a better suggestion at
> the moment.   :-(

Unfortunately this patch, or something that accomplishes the same results, 
is somewhat high-priority for us on OMAP.  OMAP37xx got prematurely 
converted to DT booting, and now dynamic power management is broken:

    http://marc.info/?l=linux-arm-kernel&m=138658294830408&w=2

Tony writes that this patch is one of the two patches needed to get things 
working again:

    http://marc.info/?l=linux-arm-kernel&m=138660942506846&w=2

Is it possible to get this patch, or something similar, merged for 
v3.13-rc?

Once something like PM is broken, it's pretty easy for other broken 
patches to make it into the tree, since it becomes very difficult to test 
without turning into a maintainer denial-of-service attack.


- Paul

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Paul Walmsley]

Hi Grant, Rob,

On Tue, 10 Dec 2013, Paul Walmsley wrote:

> On Sun, 24 Nov 2013, Grant Likely wrote:
> 
> > On Fri, 22 Nov 2013 17:50:35 -0800, Tony Lindgren <tony@atomide.com> wrote:
> > > * Tony Lindgren <tony@atomide.com> [131122 17:16]:
> > > > * Tony Lindgren <tony@atomide.com> [131122 17:09]:
> > > > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [131122 16:56]:
> > > > > > On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
> > > > > > > +		/* See of_device_resource_notify for populating interrupts */
> > > > > > > +		for (i = 0; i < num_irq; i++, res++) {
> > > > > > > +			res->flags = IORESOURCE_IRQ;
> > > > > > > +			res->start = -EPROBE_DEFER;
> > > > > > > +			res->end = -EPROBE_DEFER;
> > > > > > 
> > > > > > NAK.  Definitely a bad idea to start introducing magic values other into
> > > > > > resources.  Please don't do this.
> > > > > 
> > > > > Do you have any better ideas on how to sort out this issue then?
> > > > 
> > > > I guess we could allocate all the resources lazily here, I'll take a look
> > > > at that.
> > > 
> > > Here's a version that allocates the resources lazily with the notifier.
> > > Seems to boot, need to play with it a bit more though to make sure we're
> > > not overwriting resources for any legacy devices.
> > 
> > Blurg. Using a notifier really feels like we don't have a good handle on
> > a reasonable solution yet. Basically it means we're hooking into the
> > driver core without /looking/ like we're hooking into the driver core. I
> > don't think this is any better, but I don't have a better suggestion at
> > the moment.   :-(
> 
> Unfortunately this patch, or something that accomplishes the same results, 
> is somewhat high-priority for us on OMAP.  OMAP37xx got prematurely 
> converted to DT booting, and now dynamic power management is broken:
> 
>     http://marc.info/?l=linux-arm-kernel&m=138658294830408&w=2
> 
> Tony writes that this patch is one of the two patches needed to get things 
> working again:
> 
>     http://marc.info/?l=linux-arm-kernel&m=138660942506846&w=2
> 
> Is it possible to get this patch, or something similar, merged for 
> v3.13-rc?
> 
> Once something like PM is broken, it's pretty easy for other broken 
> patches to make it into the tree, since it becomes very difficult to test 
> without turning into a maintainer denial-of-service attack.

Ping.  Could you please provide some guidance here about what you'd need 
to get this solved for v3.13-rc?



- Paul

[PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Paul Walmsley]

Hi Grant, Rob,

On Tue, 10 Dec 2013, Paul Walmsley wrote:

> On Sun, 24 Nov 2013, Grant Likely wrote:
> 
> > On Fri, 22 Nov 2013 17:50:35 -0800, Tony Lindgren <tony@atomide.com> wrote:
> > > * Tony Lindgren <tony@atomide.com> [131122 17:16]:
> > > > * Tony Lindgren <tony@atomide.com> [131122 17:09]:
> > > > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [131122 16:56]:
> > > > > > On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
> > > > > > > +		/* See of_device_resource_notify for populating interrupts */
> > > > > > > +		for (i = 0; i < num_irq; i++, res++) {
> > > > > > > +			res->flags = IORESOURCE_IRQ;
> > > > > > > +			res->start = -EPROBE_DEFER;
> > > > > > > +			res->end = -EPROBE_DEFER;
> > > > > > 
> > > > > > NAK.  Definitely a bad idea to start introducing magic values other into
> > > > > > resources.  Please don't do this.
> > > > > 
> > > > > Do you have any better ideas on how to sort out this issue then?
> > > > 
> > > > I guess we could allocate all the resources lazily here, I'll take a look
> > > > at that.
> > > 
> > > Here's a version that allocates the resources lazily with the notifier.
> > > Seems to boot, need to play with it a bit more though to make sure we're
> > > not overwriting resources for any legacy devices.
> > 
> > Blurg. Using a notifier really feels like we don't have a good handle on
> > a reasonable solution yet. Basically it means we're hooking into the
> > driver core without /looking/ like we're hooking into the driver core. I
> > don't think this is any better, but I don't have a better suggestion at
> > the moment.   :-(
> 
> Unfortunately this patch, or something that accomplishes the same results, 
> is somewhat high-priority for us on OMAP.  OMAP37xx got prematurely 
> converted to DT booting, and now dynamic power management is broken:
> 
>     http://marc.info/?l=linux-arm-kernel&m=138658294830408&w=2
> 
> Tony writes that this patch is one of the two patches needed to get things 
> working again:
> 
>     http://marc.info/?l=linux-arm-kernel&m=138660942506846&w=2
> 
> Is it possible to get this patch, or something similar, merged for 
> v3.13-rc?
> 
> Once something like PM is broken, it's pretty easy for other broken 
> patches to make it into the tree, since it becomes very difficult to test 
> without turning into a maintainer denial-of-service attack.

Ping.  Could you please provide some guidance here about what you'd need 
to get this solved for v3.13-rc?



- Paul

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Paul Walmsley]

Hi Grant, Rob,

On Tue, 10 Dec 2013, Paul Walmsley wrote:

> On Sun, 24 Nov 2013, Grant Likely wrote:
> 
> > On Fri, 22 Nov 2013 17:50:35 -0800, Tony Lindgren <tony@atomide.com> wrote:
> > > * Tony Lindgren <tony@atomide.com> [131122 17:16]:
> > > > * Tony Lindgren <tony@atomide.com> [131122 17:09]:
> > > > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [131122 16:56]:
> > > > > > On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
> > > > > > > +		/* See of_device_resource_notify for populating interrupts */
> > > > > > > +		for (i = 0; i < num_irq; i++, res++) {
> > > > > > > +			res->flags = IORESOURCE_IRQ;
> > > > > > > +			res->start = -EPROBE_DEFER;
> > > > > > > +			res->end = -EPROBE_DEFER;
> > > > > > 
> > > > > > NAK.  Definitely a bad idea to start introducing magic values other into
> > > > > > resources.  Please don't do this.
> > > > > 
> > > > > Do you have any better ideas on how to sort out this issue then?
> > > > 
> > > > I guess we could allocate all the resources lazily here, I'll take a look
> > > > at that.
> > > 
> > > Here's a version that allocates the resources lazily with the notifier.
> > > Seems to boot, need to play with it a bit more though to make sure we're
> > > not overwriting resources for any legacy devices.
> > 
> > Blurg. Using a notifier really feels like we don't have a good handle on
> > a reasonable solution yet. Basically it means we're hooking into the
> > driver core without /looking/ like we're hooking into the driver core. I
> > don't think this is any better, but I don't have a better suggestion at
> > the moment.   :-(
> 
> Unfortunately this patch, or something that accomplishes the same results, 
> is somewhat high-priority for us on OMAP.  OMAP37xx got prematurely 
> converted to DT booting, and now dynamic power management is broken:
> 
>     http://marc.info/?l=linux-arm-kernel&m=138658294830408&w=2
> 
> Tony writes that this patch is one of the two patches needed to get things 
> working again:
> 
>     http://marc.info/?l=linux-arm-kernel&m=138660942506846&w=2
> 
> Is it possible to get this patch, or something similar, merged for 
> v3.13-rc?
> 
> Once something like PM is broken, it's pretty easy for other broken 
> patches to make it into the tree, since it becomes very difficult to test 
> without turning into a maintainer denial-of-service attack.

Ping.  Could you please provide some guidance here about what you'd need 
to get this solved for v3.13-rc?



- Paul

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Rob Herring]

On Mon, Dec 30, 2013 at 4:10 PM, Paul Walmsley <paul@pwsan.com> wrote:
> Hi Grant, Rob,
>
> On Tue, 10 Dec 2013, Paul Walmsley wrote:
>
>> On Sun, 24 Nov 2013, Grant Likely wrote:
>>
>> > On Fri, 22 Nov 2013 17:50:35 -0800, Tony Lindgren <tony@atomide.com> wrote:
>> > > * Tony Lindgren <tony@atomide.com> [131122 17:16]:
>> > > > * Tony Lindgren <tony@atomide.com> [131122 17:09]:
>> > > > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [131122 16:56]:
>> > > > > > On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
>> > > > > > > +         /* See of_device_resource_notify for populating interrupts */
>> > > > > > > +         for (i = 0; i < num_irq; i++, res++) {
>> > > > > > > +                 res->flags = IORESOURCE_IRQ;
>> > > > > > > +                 res->start = -EPROBE_DEFER;
>> > > > > > > +                 res->end = -EPROBE_DEFER;
>> > > > > >
>> > > > > > NAK.  Definitely a bad idea to start introducing magic values other into
>> > > > > > resources.  Please don't do this.
>> > > > >
>> > > > > Do you have any better ideas on how to sort out this issue then?
>> > > >
>> > > > I guess we could allocate all the resources lazily here, I'll take a look
>> > > > at that.
>> > >
>> > > Here's a version that allocates the resources lazily with the notifier.
>> > > Seems to boot, need to play with it a bit more though to make sure we're
>> > > not overwriting resources for any legacy devices.
>> >
>> > Blurg. Using a notifier really feels like we don't have a good handle on
>> > a reasonable solution yet. Basically it means we're hooking into the
>> > driver core without /looking/ like we're hooking into the driver core. I
>> > don't think this is any better, but I don't have a better suggestion at
>> > the moment.   :-(
>>
>> Unfortunately this patch, or something that accomplishes the same results,
>> is somewhat high-priority for us on OMAP.  OMAP37xx got prematurely
>> converted to DT booting, and now dynamic power management is broken:
>>
>>     http://marc.info/?l=linux-arm-kernel&m=138658294830408&w=2
>>
>> Tony writes that this patch is one of the two patches needed to get things
>> working again:
>>
>>     http://marc.info/?l=linux-arm-kernel&m=138660942506846&w=2
>>
>> Is it possible to get this patch, or something similar, merged for
>> v3.13-rc?
>>
>> Once something like PM is broken, it's pretty easy for other broken
>> patches to make it into the tree, since it becomes very difficult to test
>> without turning into a maintainer denial-of-service attack.
>
> Ping.  Could you please provide some guidance here about what you'd need
> to get this solved for v3.13-rc?

I agree with doing the platform_get_irq modification and feel free to
add my ack. I'm going to be offline for the next week.

Rob

[PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Rob Herring]

On Mon, Dec 30, 2013 at 4:10 PM, Paul Walmsley <paul@pwsan.com> wrote:
> Hi Grant, Rob,
>
> On Tue, 10 Dec 2013, Paul Walmsley wrote:
>
>> On Sun, 24 Nov 2013, Grant Likely wrote:
>>
>> > On Fri, 22 Nov 2013 17:50:35 -0800, Tony Lindgren <tony@atomide.com> wrote:
>> > > * Tony Lindgren <tony@atomide.com> [131122 17:16]:
>> > > > * Tony Lindgren <tony@atomide.com> [131122 17:09]:
>> > > > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [131122 16:56]:
>> > > > > > On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
>> > > > > > > +         /* See of_device_resource_notify for populating interrupts */
>> > > > > > > +         for (i = 0; i < num_irq; i++, res++) {
>> > > > > > > +                 res->flags = IORESOURCE_IRQ;
>> > > > > > > +                 res->start = -EPROBE_DEFER;
>> > > > > > > +                 res->end = -EPROBE_DEFER;
>> > > > > >
>> > > > > > NAK.  Definitely a bad idea to start introducing magic values other into
>> > > > > > resources.  Please don't do this.
>> > > > >
>> > > > > Do you have any better ideas on how to sort out this issue then?
>> > > >
>> > > > I guess we could allocate all the resources lazily here, I'll take a look
>> > > > at that.
>> > >
>> > > Here's a version that allocates the resources lazily with the notifier.
>> > > Seems to boot, need to play with it a bit more though to make sure we're
>> > > not overwriting resources for any legacy devices.
>> >
>> > Blurg. Using a notifier really feels like we don't have a good handle on
>> > a reasonable solution yet. Basically it means we're hooking into the
>> > driver core without /looking/ like we're hooking into the driver core. I
>> > don't think this is any better, but I don't have a better suggestion at
>> > the moment.   :-(
>>
>> Unfortunately this patch, or something that accomplishes the same results,
>> is somewhat high-priority for us on OMAP.  OMAP37xx got prematurely
>> converted to DT booting, and now dynamic power management is broken:
>>
>>     http://marc.info/?l=linux-arm-kernel&m=138658294830408&w=2
>>
>> Tony writes that this patch is one of the two patches needed to get things
>> working again:
>>
>>     http://marc.info/?l=linux-arm-kernel&m=138660942506846&w=2
>>
>> Is it possible to get this patch, or something similar, merged for
>> v3.13-rc?
>>
>> Once something like PM is broken, it's pretty easy for other broken
>> patches to make it into the tree, since it becomes very difficult to test
>> without turning into a maintainer denial-of-service attack.
>
> Ping.  Could you please provide some guidance here about what you'd need
> to get this solved for v3.13-rc?

I agree with doing the platform_get_irq modification and feel free to
add my ack. I'm going to be offline for the next week.

Rob

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Rob Herring]

On Mon, Dec 30, 2013 at 4:10 PM, Paul Walmsley <paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi Grant, Rob,
>
> On Tue, 10 Dec 2013, Paul Walmsley wrote:
>
>> On Sun, 24 Nov 2013, Grant Likely wrote:
>>
>> > On Fri, 22 Nov 2013 17:50:35 -0800, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
>> > > * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [131122 17:16]:
>> > > > * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [131122 17:09]:
>> > > > > * Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> [131122 16:56]:
>> > > > > > On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
>> > > > > > > +         /* See of_device_resource_notify for populating interrupts */
>> > > > > > > +         for (i = 0; i < num_irq; i++, res++) {
>> > > > > > > +                 res->flags = IORESOURCE_IRQ;
>> > > > > > > +                 res->start = -EPROBE_DEFER;
>> > > > > > > +                 res->end = -EPROBE_DEFER;
>> > > > > >
>> > > > > > NAK.  Definitely a bad idea to start introducing magic values other into
>> > > > > > resources.  Please don't do this.
>> > > > >
>> > > > > Do you have any better ideas on how to sort out this issue then?
>> > > >
>> > > > I guess we could allocate all the resources lazily here, I'll take a look
>> > > > at that.
>> > >
>> > > Here's a version that allocates the resources lazily with the notifier.
>> > > Seems to boot, need to play with it a bit more though to make sure we're
>> > > not overwriting resources for any legacy devices.
>> >
>> > Blurg. Using a notifier really feels like we don't have a good handle on
>> > a reasonable solution yet. Basically it means we're hooking into the
>> > driver core without /looking/ like we're hooking into the driver core. I
>> > don't think this is any better, but I don't have a better suggestion at
>> > the moment.   :-(
>>
>> Unfortunately this patch, or something that accomplishes the same results,
>> is somewhat high-priority for us on OMAP.  OMAP37xx got prematurely
>> converted to DT booting, and now dynamic power management is broken:
>>
>>     http://marc.info/?l=linux-arm-kernel&m=138658294830408&w=2
>>
>> Tony writes that this patch is one of the two patches needed to get things
>> working again:
>>
>>     http://marc.info/?l=linux-arm-kernel&m=138660942506846&w=2
>>
>> Is it possible to get this patch, or something similar, merged for
>> v3.13-rc?
>>
>> Once something like PM is broken, it's pretty easy for other broken
>> patches to make it into the tree, since it becomes very difficult to test
>> without turning into a maintainer denial-of-service attack.
>
> Ping.  Could you please provide some guidance here about what you'd need
> to get this solved for v3.13-rc?

I agree with doing the platform_get_irq modification and feel free to
add my ack. I'm going to be offline for the next week.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Paul Walmsley]

Hi Tony, Rob,

On Tue, 31 Dec 2013, Rob Herring wrote:

> On Mon, Dec 30, 2013 at 4:10 PM, Paul Walmsley <paul@pwsan.com> wrote:
> > Hi Grant, Rob,
> >
> > On Tue, 10 Dec 2013, Paul Walmsley wrote:
> >
> >> On Sun, 24 Nov 2013, Grant Likely wrote:
> >>
> >> > On Fri, 22 Nov 2013 17:50:35 -0800, Tony Lindgren <tony@atomide.com> wrote:
> >> > > * Tony Lindgren <tony@atomide.com> [131122 17:16]:
> >> > > > * Tony Lindgren <tony@atomide.com> [131122 17:09]:
> >> > > > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [131122 16:56]:
> >> > > > > > On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
> >> > > > > > > +         /* See of_device_resource_notify for populating interrupts */
> >> > > > > > > +         for (i = 0; i < num_irq; i++, res++) {
> >> > > > > > > +                 res->flags = IORESOURCE_IRQ;
> >> > > > > > > +                 res->start = -EPROBE_DEFER;
> >> > > > > > > +                 res->end = -EPROBE_DEFER;
> >> > > > > >
> >> > > > > > NAK.  Definitely a bad idea to start introducing magic values other into
> >> > > > > > resources.  Please don't do this.
> >> > > > >
> >> > > > > Do you have any better ideas on how to sort out this issue then?
> >> > > >
> >> > > > I guess we could allocate all the resources lazily here, I'll take a look
> >> > > > at that.
> >> > >
> >> > > Here's a version that allocates the resources lazily with the notifier.
> >> > > Seems to boot, need to play with it a bit more though to make sure we're
> >> > > not overwriting resources for any legacy devices.
> >> >
> >> > Blurg. Using a notifier really feels like we don't have a good handle on
> >> > a reasonable solution yet. Basically it means we're hooking into the
> >> > driver core without /looking/ like we're hooking into the driver core. I
> >> > don't think this is any better, but I don't have a better suggestion at
> >> > the moment.   :-(
> >>
> >> Unfortunately this patch, or something that accomplishes the same results,
> >> is somewhat high-priority for us on OMAP.  OMAP37xx got prematurely
> >> converted to DT booting, and now dynamic power management is broken:
> >>
> >>     http://marc.info/?l=linux-arm-kernel&m=138658294830408&w=2
> >>
> >> Tony writes that this patch is one of the two patches needed to get things
> >> working again:
> >>
> >>     http://marc.info/?l=linux-arm-kernel&m=138660942506846&w=2
> >>
> >> Is it possible to get this patch, or something similar, merged for
> >> v3.13-rc?
> >>
> >> Once something like PM is broken, it's pretty easy for other broken
> >> patches to make it into the tree, since it becomes very difficult to test
> >> without turning into a maintainer denial-of-service attack.
> >
> > Ping.  Could you please provide some guidance here about what you'd need
> > to get this solved for v3.13-rc?
> 
> I agree with doing the platform_get_irq modification and feel free to
> add my ack. I'm going to be offline for the next week.

Thanks Rob!

Tony, would you consider sending this patch upstream for v3.13-rc along 
with your 37xxevm fix patches?


- Paul

[PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Paul Walmsley]

Hi Tony, Rob,

On Tue, 31 Dec 2013, Rob Herring wrote:

> On Mon, Dec 30, 2013 at 4:10 PM, Paul Walmsley <paul@pwsan.com> wrote:
> > Hi Grant, Rob,
> >
> > On Tue, 10 Dec 2013, Paul Walmsley wrote:
> >
> >> On Sun, 24 Nov 2013, Grant Likely wrote:
> >>
> >> > On Fri, 22 Nov 2013 17:50:35 -0800, Tony Lindgren <tony@atomide.com> wrote:
> >> > > * Tony Lindgren <tony@atomide.com> [131122 17:16]:
> >> > > > * Tony Lindgren <tony@atomide.com> [131122 17:09]:
> >> > > > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [131122 16:56]:
> >> > > > > > On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
> >> > > > > > > +         /* See of_device_resource_notify for populating interrupts */
> >> > > > > > > +         for (i = 0; i < num_irq; i++, res++) {
> >> > > > > > > +                 res->flags = IORESOURCE_IRQ;
> >> > > > > > > +                 res->start = -EPROBE_DEFER;
> >> > > > > > > +                 res->end = -EPROBE_DEFER;
> >> > > > > >
> >> > > > > > NAK.  Definitely a bad idea to start introducing magic values other into
> >> > > > > > resources.  Please don't do this.
> >> > > > >
> >> > > > > Do you have any better ideas on how to sort out this issue then?
> >> > > >
> >> > > > I guess we could allocate all the resources lazily here, I'll take a look
> >> > > > at that.
> >> > >
> >> > > Here's a version that allocates the resources lazily with the notifier.
> >> > > Seems to boot, need to play with it a bit more though to make sure we're
> >> > > not overwriting resources for any legacy devices.
> >> >
> >> > Blurg. Using a notifier really feels like we don't have a good handle on
> >> > a reasonable solution yet. Basically it means we're hooking into the
> >> > driver core without /looking/ like we're hooking into the driver core. I
> >> > don't think this is any better, but I don't have a better suggestion at
> >> > the moment.   :-(
> >>
> >> Unfortunately this patch, or something that accomplishes the same results,
> >> is somewhat high-priority for us on OMAP.  OMAP37xx got prematurely
> >> converted to DT booting, and now dynamic power management is broken:
> >>
> >>     http://marc.info/?l=linux-arm-kernel&m=138658294830408&w=2
> >>
> >> Tony writes that this patch is one of the two patches needed to get things
> >> working again:
> >>
> >>     http://marc.info/?l=linux-arm-kernel&m=138660942506846&w=2
> >>
> >> Is it possible to get this patch, or something similar, merged for
> >> v3.13-rc?
> >>
> >> Once something like PM is broken, it's pretty easy for other broken
> >> patches to make it into the tree, since it becomes very difficult to test
> >> without turning into a maintainer denial-of-service attack.
> >
> > Ping.  Could you please provide some guidance here about what you'd need
> > to get this solved for v3.13-rc?
> 
> I agree with doing the platform_get_irq modification and feel free to
> add my ack. I'm going to be offline for the next week.

Thanks Rob!

Tony, would you consider sending this patch upstream for v3.13-rc along 
with your 37xxevm fix patches?


- Paul

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Paul Walmsley]

Hi Tony, Rob,

On Tue, 31 Dec 2013, Rob Herring wrote:

> On Mon, Dec 30, 2013 at 4:10 PM, Paul Walmsley <paul@pwsan.com> wrote:
> > Hi Grant, Rob,
> >
> > On Tue, 10 Dec 2013, Paul Walmsley wrote:
> >
> >> On Sun, 24 Nov 2013, Grant Likely wrote:
> >>
> >> > On Fri, 22 Nov 2013 17:50:35 -0800, Tony Lindgren <tony@atomide.com> wrote:
> >> > > * Tony Lindgren <tony@atomide.com> [131122 17:16]:
> >> > > > * Tony Lindgren <tony@atomide.com> [131122 17:09]:
> >> > > > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [131122 16:56]:
> >> > > > > > On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
> >> > > > > > > +         /* See of_device_resource_notify for populating interrupts */
> >> > > > > > > +         for (i = 0; i < num_irq; i++, res++) {
> >> > > > > > > +                 res->flags = IORESOURCE_IRQ;
> >> > > > > > > +                 res->start = -EPROBE_DEFER;
> >> > > > > > > +                 res->end = -EPROBE_DEFER;
> >> > > > > >
> >> > > > > > NAK.  Definitely a bad idea to start introducing magic values other into
> >> > > > > > resources.  Please don't do this.
> >> > > > >
> >> > > > > Do you have any better ideas on how to sort out this issue then?
> >> > > >
> >> > > > I guess we could allocate all the resources lazily here, I'll take a look
> >> > > > at that.
> >> > >
> >> > > Here's a version that allocates the resources lazily with the notifier.
> >> > > Seems to boot, need to play with it a bit more though to make sure we're
> >> > > not overwriting resources for any legacy devices.
> >> >
> >> > Blurg. Using a notifier really feels like we don't have a good handle on
> >> > a reasonable solution yet. Basically it means we're hooking into the
> >> > driver core without /looking/ like we're hooking into the driver core. I
> >> > don't think this is any better, but I don't have a better suggestion at
> >> > the moment.   :-(
> >>
> >> Unfortunately this patch, or something that accomplishes the same results,
> >> is somewhat high-priority for us on OMAP.  OMAP37xx got prematurely
> >> converted to DT booting, and now dynamic power management is broken:
> >>
> >>     http://marc.info/?l=linux-arm-kernel&m=138658294830408&w=2
> >>
> >> Tony writes that this patch is one of the two patches needed to get things
> >> working again:
> >>
> >>     http://marc.info/?l=linux-arm-kernel&m=138660942506846&w=2
> >>
> >> Is it possible to get this patch, or something similar, merged for
> >> v3.13-rc?
> >>
> >> Once something like PM is broken, it's pretty easy for other broken
> >> patches to make it into the tree, since it becomes very difficult to test
> >> without turning into a maintainer denial-of-service attack.
> >
> > Ping.  Could you please provide some guidance here about what you'd need
> > to get this solved for v3.13-rc?
> 
> I agree with doing the platform_get_irq modification and feel free to
> add my ack. I'm going to be offline for the next week.

Thanks Rob!

Tony, would you consider sending this patch upstream for v3.13-rc along 
with your 37xxevm fix patches?


- Paul

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Tony Lindgren]

* Paul Walmsley <paul@pwsan.com> [140106 15:43]:
> On Tue, 31 Dec 2013, Rob Herring wrote:
> > On Mon, Dec 30, 2013 at 4:10 PM, Paul Walmsley <paul@pwsan.com> wrote:
> > > On Tue, 10 Dec 2013, Paul Walmsley wrote:
> > >> Is it possible to get this patch, or something similar, merged for
> > >> v3.13-rc?
> > >>
> > >> Once something like PM is broken, it's pretty easy for other broken
> > >> patches to make it into the tree, since it becomes very difficult to test
> > >> without turning into a maintainer denial-of-service attack.
> > >
> > > Ping.  Could you please provide some guidance here about what you'd need
> > > to get this solved for v3.13-rc?
> > 
> > I agree with doing the platform_get_irq modification and feel free to
> > add my ack. I'm going to be offline for the next week.
> 
> Thanks Rob!
> 
> Tony, would you consider sending this patch upstream for v3.13-rc along 
> with your 37xxevm fix patches?

Hmm I'd like to see a proper patch posted for platform_get_irq() by
Thierry as that one is really his patch. And it also had a comment from
Grant.

After that I can queue it if nobody else is picking it as I have a
dependency to it.

Regards,

Tony

[PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Tony Lindgren]

* Paul Walmsley <paul@pwsan.com> [140106 15:43]:
> On Tue, 31 Dec 2013, Rob Herring wrote:
> > On Mon, Dec 30, 2013 at 4:10 PM, Paul Walmsley <paul@pwsan.com> wrote:
> > > On Tue, 10 Dec 2013, Paul Walmsley wrote:
> > >> Is it possible to get this patch, or something similar, merged for
> > >> v3.13-rc?
> > >>
> > >> Once something like PM is broken, it's pretty easy for other broken
> > >> patches to make it into the tree, since it becomes very difficult to test
> > >> without turning into a maintainer denial-of-service attack.
> > >
> > > Ping.  Could you please provide some guidance here about what you'd need
> > > to get this solved for v3.13-rc?
> > 
> > I agree with doing the platform_get_irq modification and feel free to
> > add my ack. I'm going to be offline for the next week.
> 
> Thanks Rob!
> 
> Tony, would you consider sending this patch upstream for v3.13-rc along 
> with your 37xxevm fix patches?

Hmm I'd like to see a proper patch posted for platform_get_irq() by
Thierry as that one is really his patch. And it also had a comment from
Grant.

After that I can queue it if nobody else is picking it as I have a
dependency to it.

Regards,

Tony

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Tony Lindgren]

* Paul Walmsley <paul@pwsan.com> [140106 15:43]:
> On Tue, 31 Dec 2013, Rob Herring wrote:
> > On Mon, Dec 30, 2013 at 4:10 PM, Paul Walmsley <paul@pwsan.com> wrote:
> > > On Tue, 10 Dec 2013, Paul Walmsley wrote:
> > >> Is it possible to get this patch, or something similar, merged for
> > >> v3.13-rc?
> > >>
> > >> Once something like PM is broken, it's pretty easy for other broken
> > >> patches to make it into the tree, since it becomes very difficult to test
> > >> without turning into a maintainer denial-of-service attack.
> > >
> > > Ping.  Could you please provide some guidance here about what you'd need
> > > to get this solved for v3.13-rc?
> > 
> > I agree with doing the platform_get_irq modification and feel free to
> > add my ack. I'm going to be offline for the next week.
> 
> Thanks Rob!
> 
> Tony, would you consider sending this patch upstream for v3.13-rc along 
> with your 37xxevm fix patches?

Hmm I'd like to see a proper patch posted for platform_get_irq() by
Thierry as that one is really his patch. And it also had a comment from
Grant.

After that I can queue it if nobody else is picking it as I have a
dependency to it.

Regards,

Tony

[PATCH] driver-core: platform: Resolve DT interrupt references late

[Thierry Reding]

When devices are probed from the device tree, any interrupts that they
reference are resolved at device creation time. This causes problems if
the interrupt provider hasn't been registered yet at that time, which
results in the interrupt being set to 0.

This is especially bad for platform devices because they are created at
a very early stage during boot when the majority of interrupt providers
haven't had a chance to be probed yet. One of the platform where this
causes major issues is OMAP.

Note that this patch is the easy way out to fix a large part of the
problems for now. A more proper solution for the long term would be to
transition drivers to an API that always resolves resources of any kind
(not only interrupts) at probe time.

For some background and discussion on possible solutions, see:

	https://lkml.org/lkml/2013/11/22/520

Acked-by: Rob Herring <robherring2@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Note that this is somewhat urgent and should if at all possible go into
v3.13 before the release.

 drivers/base/platform.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 3a94b799f166..c894d1af3a5e 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -13,6 +13,7 @@
 #include <linux/string.h>
 #include <linux/platform_device.h>
 #include <linux/of_device.h>
+#include <linux/of_irq.h>
 #include <linux/module.h>
 #include <linux/init.h>
 #include <linux/dma-mapping.h>
@@ -87,7 +88,12 @@ int platform_get_irq(struct platform_device *dev, unsigned int num)
 		return -ENXIO;
 	return dev->archdata.irqs[num];
 #else
-	struct resource *r = platform_get_resource(dev, IORESOURCE_IRQ, num);
+	struct resource *r;
+
+	if (IS_ENABLED(CONFIG_OF) && dev->dev.of_node)
+		return irq_of_parse_and_map(dev->dev.of_node, num);
+
+	r = platform_get_resource(dev, IORESOURCE_IRQ, num);
 
 	return r ? r->start : -ENXIO;
 #endif
-- 
1.8.4.2

[PATCH] driver-core: platform: Resolve DT interrupt references late

[Thierry Reding]

When devices are probed from the device tree, any interrupts that they
reference are resolved at device creation time. This causes problems if
the interrupt provider hasn't been registered yet at that time, which
results in the interrupt being set to 0.

This is especially bad for platform devices because they are created at
a very early stage during boot when the majority of interrupt providers
haven't had a chance to be probed yet. One of the platform where this
causes major issues is OMAP.

Note that this patch is the easy way out to fix a large part of the
problems for now. A more proper solution for the long term would be to
transition drivers to an API that always resolves resources of any kind
(not only interrupts) at probe time.

For some background and discussion on possible solutions, see:

	https://lkml.org/lkml/2013/11/22/520

Acked-by: Rob Herring <robherring2@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Note that this is somewhat urgent and should if at all possible go into
v3.13 before the release.

 drivers/base/platform.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 3a94b799f166..c894d1af3a5e 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -13,6 +13,7 @@
 #include <linux/string.h>
 #include <linux/platform_device.h>
 #include <linux/of_device.h>
+#include <linux/of_irq.h>
 #include <linux/module.h>
 #include <linux/init.h>
 #include <linux/dma-mapping.h>
@@ -87,7 +88,12 @@ int platform_get_irq(struct platform_device *dev, unsigned int num)
 		return -ENXIO;
 	return dev->archdata.irqs[num];
 #else
-	struct resource *r = platform_get_resource(dev, IORESOURCE_IRQ, num);
+	struct resource *r;
+
+	if (IS_ENABLED(CONFIG_OF) && dev->dev.of_node)
+		return irq_of_parse_and_map(dev->dev.of_node, num);
+
+	r = platform_get_resource(dev, IORESOURCE_IRQ, num);
 
 	return r ? r->start : -ENXIO;
 #endif
-- 
1.8.4.2

Re: [PATCH] driver-core: platform: Resolve DT interrupt references late

[Arnd Bergmann]

On Wednesday 08 January 2014 13:51:17 Thierry Reding wrote:
> When devices are probed from the device tree, any interrupts that they
> reference are resolved at device creation time. This causes problems if
> the interrupt provider hasn't been registered yet at that time, which
> results in the interrupt being set to 0.

Thanks for looking at this problem, it has bothered a lot of people
for a long time. I'm sorry I wasn't there for the discussion in November,
but when it came up before, I suggested a different solution that
apparently didn't get implemented.

> Note that this patch is the easy way out to fix a large part of the
> problems for now. A more proper solution for the long term would be to
> transition drivers to an API that always resolves resources of any kind
> (not only interrupts) at probe time.
> 
> For some background and discussion on possible solutions, see:
> 
> 	https://lkml.org/lkml/2013/11/22/520

I hope I read this thread correctly, sorry if I missed an important
part. My idea was to add the code not in platform_get_irq() but add
the resource in platform_drv_probe(), and just bail out with
-EPROBE_DEFER there if necessary.

We could then skip adding the resources at device creation time.
Is this something you already plan to do later, or is there a reason
it wouldn't work?

In the meantime, I don't see anything with your patch, but it also
wouldn't hurt to do it now if it solves all the problems.

	Arnd

[PATCH] driver-core: platform: Resolve DT interrupt references late

[Arnd Bergmann]

On Wednesday 08 January 2014 13:51:17 Thierry Reding wrote:
> When devices are probed from the device tree, any interrupts that they
> reference are resolved at device creation time. This causes problems if
> the interrupt provider hasn't been registered yet at that time, which
> results in the interrupt being set to 0.

Thanks for looking at this problem, it has bothered a lot of people
for a long time. I'm sorry I wasn't there for the discussion in November,
but when it came up before, I suggested a different solution that
apparently didn't get implemented.

> Note that this patch is the easy way out to fix a large part of the
> problems for now. A more proper solution for the long term would be to
> transition drivers to an API that always resolves resources of any kind
> (not only interrupts) at probe time.
> 
> For some background and discussion on possible solutions, see:
> 
> 	https://lkml.org/lkml/2013/11/22/520

I hope I read this thread correctly, sorry if I missed an important
part. My idea was to add the code not in platform_get_irq() but add
the resource in platform_drv_probe(), and just bail out with
-EPROBE_DEFER there if necessary.

We could then skip adding the resources at device creation time.
Is this something you already plan to do later, or is there a reason
it wouldn't work?

In the meantime, I don't see anything with your patch, but it also
wouldn't hurt to do it now if it solves all the problems.

	Arnd

Re: [PATCH] driver-core: platform: Resolve DT interrupt references late

[Arnd Bergmann]

On Wednesday 08 January 2014 13:51:17 Thierry Reding wrote:
> When devices are probed from the device tree, any interrupts that they
> reference are resolved at device creation time. This causes problems if
> the interrupt provider hasn't been registered yet at that time, which
> results in the interrupt being set to 0.

Thanks for looking at this problem, it has bothered a lot of people
for a long time. I'm sorry I wasn't there for the discussion in November,
but when it came up before, I suggested a different solution that
apparently didn't get implemented.

> Note that this patch is the easy way out to fix a large part of the
> problems for now. A more proper solution for the long term would be to
> transition drivers to an API that always resolves resources of any kind
> (not only interrupts) at probe time.
> 
> For some background and discussion on possible solutions, see:
> 
> 	https://lkml.org/lkml/2013/11/22/520

I hope I read this thread correctly, sorry if I missed an important
part. My idea was to add the code not in platform_get_irq() but add
the resource in platform_drv_probe(), and just bail out with
-EPROBE_DEFER there if necessary.

We could then skip adding the resources at device creation time.
Is this something you already plan to do later, or is there a reason
it wouldn't work?

In the meantime, I don't see anything with your patch, but it also
wouldn't hurt to do it now if it solves all the problems.

	Arnd

Re: [PATCH] driver-core: platform: Resolve DT interrupt references late

[Thierry Reding]

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

On Wed, Jan 08, 2014 at 02:41:19PM +0100, Arnd Bergmann wrote:
> On Wednesday 08 January 2014 13:51:17 Thierry Reding wrote:
> > When devices are probed from the device tree, any interrupts that they
> > reference are resolved at device creation time. This causes problems if
> > the interrupt provider hasn't been registered yet at that time, which
> > results in the interrupt being set to 0.
> 
> Thanks for looking at this problem, it has bothered a lot of people
> for a long time. I'm sorry I wasn't there for the discussion in November,
> but when it came up before, I suggested a different solution that
> apparently didn't get implemented.
> 
> > Note that this patch is the easy way out to fix a large part of the
> > problems for now. A more proper solution for the long term would be to
> > transition drivers to an API that always resolves resources of any kind
> > (not only interrupts) at probe time.
> > 
> > For some background and discussion on possible solutions, see:
> > 
> > 	https://lkml.org/lkml/2013/11/22/520
> 
> I hope I read this thread correctly, sorry if I missed an important
> part. My idea was to add the code not in platform_get_irq() but add
> the resource in platform_drv_probe(), and just bail out with
> -EPROBE_DEFER there if necessary.

One of the reasons we can't do that just yet is that we don't actually
get back an accurate error code from the OF IRQ helpers. Therefore if we
want to support deferred probing we either have to return -EPROBE_DEFER
for all errors (which is a bad idea because some errors just can't be
resolved by deferral) or we change the OF IRQ functions to propagate the
error code properly so that we know exactly when -EPROBE_DEFER makes
sense (i.e. the IRQ domain for an interrupt-parent hasn't been
registered yet).

Actually I posted a round of patches quite a while back that did exactly
this for interrupts. The changes were somewhat involved because it means
propagating an error code from fairly deep down in the OF code back to
the various higher-level helpers. If you're interested, the last version
of that is here:

	https://lkml.org/lkml/2013/9/18/216

Grant in particular seemed to be uncomfortable about how invasive the
patch series is.

Perhaps I should step back for a minute and provide some background on
how the initial idea came about. This was first triggered by the IOMMU
probe ordering issue that you may have heard about. One of the reasons
to do this for interrupts was because they are an existing type of
resource yet suffer from a very similar problem, so I wanted to solve
the issue for interrupts and thereby get a better overview of what
needed to be done for IOMMUs.

The most logical place for this code to reside seemed to be in the probe
path of platform devices (or I2C and other devices for that matter). The
patch series introduced an of_platform_probe() function that's called
from platform_drv_probe(). This would automatically give us deferred
probe support provided that we could propagate the appropriate error
code while at the same time giving us some flexibility to hook up other
resource types (such as IOMMUs).

One problem with the IOMMU patches is that they've received some strong
pushback from both Greg and Grant, arguing that it doesn't belong in the
core. If you want to read up on that, here's a link to the latest
version:

	https://lkml.org/lkml/2013/12/12/74

Some things had been discussed in earlier iterations of that series, but
this should give you the basic idea.

It stands to reason that if they push back on the IOMMU variant of what
is essentially the same thing, they will push back on the IRQ variant as
well. One alternative I proposed was to, just as you suggested earlier,
move the code into platform_drv_probe() or rather a function called from
it. That proposal never got any replies, though.

	https://lkml.org/lkml/2013/12/14/39

> We could then skip adding the resources at device creation time.
> Is this something you already plan to do later, or is there a reason
> it wouldn't work?

The current thread here suggests that it would be preferable not to have
any static allocations at all, but rather introduce a new API to resolve
things at probe time if necessary. I think the idea was to have a set of
functions like:

	int device_get_irq(struct device *dev, unsigned int num);
	struct resource *device_get_mem_region(struct device *dev,
					       unsigned int num);

Or even possible the more generic:

	struct resource *device_get_resource(struct device *dev,
					     unsigned int type,
					     unsigned int num);

If every driver used these functions, all resources could trivially be
resolved at probe time. That solution is also the most invasive one of
course, because it requires all existing drivers to be converted. At
least the API would be all new and therefore the conversion could happen
piecemeal.

One downside of that approach is that, while it maps well to platform
devices or generic devices that have some sort of firmware interface
such as OF or ACPI, I don't see how it can be made to work with an I2C
client that's registered from board setup code for example. Well, I
suppose that problem could be solved by throwing another lookup table at
it, just like we do for clocks, regulators, PWMs and GPIOs.

The good thing about it would be more consistency between the various
types of resources. Eventually I could imagine that we could even get
rid of struct resource (or at least only use it for a single type of
resource). But as I said, it'll take quite a bit of work to convert
everything to that.

> In the meantime, I don't see anything with your patch, but it also
> wouldn't hurt to do it now if it solves all the problems.

Well, the commit message explicitly states that this is only a temporary
measure, mostly to fix a number of regressions on OMAP where things were
broken by the conversion to DT in 3.13. The same is probably true of
other boards as well.

I'm willing to help fix things properly in the long run, but I think a
simple and low-risk patch like this would be worthwhile if it means that
a good many boards aren't broken in 3.13. Also given the history of the
above I can imagine that it will take more than the 3.14 cycle to get
this resolved satisfactorily, so at least for interrupts this would give
us a good stopgap solution in the meantime.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

[PATCH] driver-core: platform: Resolve DT interrupt references late

[Thierry Reding]

On Wed, Jan 08, 2014 at 02:41:19PM +0100, Arnd Bergmann wrote:
> On Wednesday 08 January 2014 13:51:17 Thierry Reding wrote:
> > When devices are probed from the device tree, any interrupts that they
> > reference are resolved at device creation time. This causes problems if
> > the interrupt provider hasn't been registered yet at that time, which
> > results in the interrupt being set to 0.
> 
> Thanks for looking at this problem, it has bothered a lot of people
> for a long time. I'm sorry I wasn't there for the discussion in November,
> but when it came up before, I suggested a different solution that
> apparently didn't get implemented.
> 
> > Note that this patch is the easy way out to fix a large part of the
> > problems for now. A more proper solution for the long term would be to
> > transition drivers to an API that always resolves resources of any kind
> > (not only interrupts) at probe time.
> > 
> > For some background and discussion on possible solutions, see:
> > 
> > 	https://lkml.org/lkml/2013/11/22/520
> 
> I hope I read this thread correctly, sorry if I missed an important
> part. My idea was to add the code not in platform_get_irq() but add
> the resource in platform_drv_probe(), and just bail out with
> -EPROBE_DEFER there if necessary.

One of the reasons we can't do that just yet is that we don't actually
get back an accurate error code from the OF IRQ helpers. Therefore if we
want to support deferred probing we either have to return -EPROBE_DEFER
for all errors (which is a bad idea because some errors just can't be
resolved by deferral) or we change the OF IRQ functions to propagate the
error code properly so that we know exactly when -EPROBE_DEFER makes
sense (i.e. the IRQ domain for an interrupt-parent hasn't been
registered yet).

Actually I posted a round of patches quite a while back that did exactly
this for interrupts. The changes were somewhat involved because it means
propagating an error code from fairly deep down in the OF code back to
the various higher-level helpers. If you're interested, the last version
of that is here:

	https://lkml.org/lkml/2013/9/18/216

Grant in particular seemed to be uncomfortable about how invasive the
patch series is.

Perhaps I should step back for a minute and provide some background on
how the initial idea came about. This was first triggered by the IOMMU
probe ordering issue that you may have heard about. One of the reasons
to do this for interrupts was because they are an existing type of
resource yet suffer from a very similar problem, so I wanted to solve
the issue for interrupts and thereby get a better overview of what
needed to be done for IOMMUs.

The most logical place for this code to reside seemed to be in the probe
path of platform devices (or I2C and other devices for that matter). The
patch series introduced an of_platform_probe() function that's called
from platform_drv_probe(). This would automatically give us deferred
probe support provided that we could propagate the appropriate error
code while at the same time giving us some flexibility to hook up other
resource types (such as IOMMUs).

One problem with the IOMMU patches is that they've received some strong
pushback from both Greg and Grant, arguing that it doesn't belong in the
core. If you want to read up on that, here's a link to the latest
version:

	https://lkml.org/lkml/2013/12/12/74

Some things had been discussed in earlier iterations of that series, but
this should give you the basic idea.

It stands to reason that if they push back on the IOMMU variant of what
is essentially the same thing, they will push back on the IRQ variant as
well. One alternative I proposed was to, just as you suggested earlier,
move the code into platform_drv_probe() or rather a function called from
it. That proposal never got any replies, though.

	https://lkml.org/lkml/2013/12/14/39

> We could then skip adding the resources at device creation time.
> Is this something you already plan to do later, or is there a reason
> it wouldn't work?

The current thread here suggests that it would be preferable not to have
any static allocations at all, but rather introduce a new API to resolve
things at probe time if necessary. I think the idea was to have a set of
functions like:

	int device_get_irq(struct device *dev, unsigned int num);
	struct resource *device_get_mem_region(struct device *dev,
					       unsigned int num);

Or even possible the more generic:

	struct resource *device_get_resource(struct device *dev,
					     unsigned int type,
					     unsigned int num);

If every driver used these functions, all resources could trivially be
resolved at probe time. That solution is also the most invasive one of
course, because it requires all existing drivers to be converted. At
least the API would be all new and therefore the conversion could happen
piecemeal.

One downside of that approach is that, while it maps well to platform
devices or generic devices that have some sort of firmware interface
such as OF or ACPI, I don't see how it can be made to work with an I2C
client that's registered from board setup code for example. Well, I
suppose that problem could be solved by throwing another lookup table at
it, just like we do for clocks, regulators, PWMs and GPIOs.

The good thing about it would be more consistency between the various
types of resources. Eventually I could imagine that we could even get
rid of struct resource (or at least only use it for a single type of
resource). But as I said, it'll take quite a bit of work to convert
everything to that.

> In the meantime, I don't see anything with your patch, but it also
> wouldn't hurt to do it now if it solves all the problems.

Well, the commit message explicitly states that this is only a temporary
measure, mostly to fix a number of regressions on OMAP where things were
broken by the conversion to DT in 3.13. The same is probably true of
other boards as well.

I'm willing to help fix things properly in the long run, but I think a
simple and low-risk patch like this would be worthwhile if it means that
a good many boards aren't broken in 3.13. Also given the history of the
above I can imagine that it will take more than the 3.14 cycle to get
this resolved satisfactorily, so at least for interrupts this would give
us a good stopgap solution in the meantime.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140108/d3199ff3/attachment.sig>

Re: [PATCH] driver-core: platform: Resolve DT interrupt references late

[Arnd Bergmann]

On Wednesday 08 January 2014 15:55:27 Thierry Reding wrote:
> On Wed, Jan 08, 2014 at 02:41:19PM +0100, Arnd Bergmann wrote:
> > On Wednesday 08 January 2014 13:51:17 Thierry Reding wrote:
> > I hope I read this thread correctly, sorry if I missed an important
> > part. My idea was to add the code not in platform_get_irq() but add
> > the resource in platform_drv_probe(), and just bail out with
> > -EPROBE_DEFER there if necessary.
> 
> One of the reasons we can't do that just yet is that we don't actually
> get back an accurate error code from the OF IRQ helpers. Therefore if we
> want to support deferred probing we either have to return -EPROBE_DEFER
> for all errors (which is a bad idea because some errors just can't be
> resolved by deferral) or we change the OF IRQ functions to propagate the
> error code properly so that we know exactly when -EPROBE_DEFER makes
> sense (i.e. the IRQ domain for an interrupt-parent hasn't been
> registered yet).

I see.

> Actually I posted a round of patches quite a while back that did exactly
> this for interrupts. The changes were somewhat involved because it means
> propagating an error code from fairly deep down in the OF code back to
> the various higher-level helpers. If you're interested, the last version
> of that is here:
> 
> 	https://lkml.org/lkml/2013/9/18/216
> 
> Grant in particular seemed to be uncomfortable about how invasive the
> patch series is.

Interesting. It seems like a worthwhile thing to do, but I can understand
Grant's reluctance.

> 
> One problem with the IOMMU patches is that they've received some strong
> pushback from both Greg and Grant, arguing that it doesn't belong in the
> core. If you want to read up on that, here's a link to the latest
> version:
> 
> 	https://lkml.org/lkml/2013/12/12/74
> 
> Some things had been discussed in earlier iterations of that series, but
> this should give you the basic idea.

I'm skipping that discussion for now and stick with your summary

> It stands to reason that if they push back on the IOMMU variant of what
> is essentially the same thing, they will push back on the IRQ variant as
> well. One alternative I proposed was to, just as you suggested earlier,
> move the code into platform_drv_probe() or rather a function called from
> it. That proposal never got any replies, though.
> 
> 	https://lkml.org/lkml/2013/12/14/39

I guess putting it into the platform_drv_probe function seems reasonable,
I would be more scared of the implications of a notifier based method.

> > We could then skip adding the resources at device creation time.
> > Is this something you already plan to do later, or is there a reason
> > it wouldn't work?
> 
> The current thread here suggests that it would be preferable not to have
> any static allocations at all, but rather introduce a new API to resolve
> things at probe time if necessary. I think the idea was to have a set of
> functions like:
> 
> 	int device_get_irq(struct device *dev, unsigned int num);
> 	struct resource *device_get_mem_region(struct device *dev,
> 					       unsigned int num);
> 
> Or even possible the more generic:
> 
> 	struct resource *device_get_resource(struct device *dev,
> 					     unsigned int type,
> 					     unsigned int num);
> 
> If every driver used these functions, all resources could trivially be
> resolved at probe time. That solution is also the most invasive one of
> course, because it requires all existing drivers to be converted. At
> least the API would be all new and therefore the conversion could happen
> piecemeal.

Right, that does sound nice, and has the added benefit of saving
some memory allocations. I'd prefer the less generic variant here,
but I haven't given it much thought.
 
> One downside of that approach is that, while it maps well to platform
> devices or generic devices that have some sort of firmware interface
> such as OF or ACPI, I don't see how it can be made to work with an I2C
> client that's registered from board setup code for example. Well, I
> suppose that problem could be solved by throwing another lookup table at
> it, just like we do for clocks, regulators, PWMs and GPIOs.

Wouldn't you still be able to attach resources in the traditional
way for those, but use the same new interface to get at them?

> The good thing about it would be more consistency between the various
> types of resources. Eventually I could imagine that we could even get
> rid of struct resource (or at least only use it for a single type of
> resource). But as I said, it'll take quite a bit of work to convert
> everything to that.

struct resource is a structure with a long and complex history.
I'd certainly like to put some of it behind us and do something
that fits better into the 'struct device' concept which it
predates. I agree it would be a big effort though.

> > In the meantime, I don't see anything with your patch, but it also
> > wouldn't hurt to do it now if it solves all the problems.
> 
> Well, the commit message explicitly states that this is only a temporary
> measure, mostly to fix a number of regressions on OMAP where things were
> broken by the conversion to DT in 3.13. The same is probably true of
> other boards as well.

Right.

> I'm willing to help fix things properly in the long run, but I think a
> simple and low-risk patch like this would be worthwhile if it means that
> a good many boards aren't broken in 3.13. Also given the history of the
> above I can imagine that it will take more than the 3.14 cycle to get
> this resolved satisfactorily, so at least for interrupts this would give
> us a good stopgap solution in the meantime.

Ok. Thanks so much for your detailed background information!

	Arnd

[PATCH] driver-core: platform: Resolve DT interrupt references late

[Arnd Bergmann]

On Wednesday 08 January 2014 15:55:27 Thierry Reding wrote:
> On Wed, Jan 08, 2014 at 02:41:19PM +0100, Arnd Bergmann wrote:
> > On Wednesday 08 January 2014 13:51:17 Thierry Reding wrote:
> > I hope I read this thread correctly, sorry if I missed an important
> > part. My idea was to add the code not in platform_get_irq() but add
> > the resource in platform_drv_probe(), and just bail out with
> > -EPROBE_DEFER there if necessary.
> 
> One of the reasons we can't do that just yet is that we don't actually
> get back an accurate error code from the OF IRQ helpers. Therefore if we
> want to support deferred probing we either have to return -EPROBE_DEFER
> for all errors (which is a bad idea because some errors just can't be
> resolved by deferral) or we change the OF IRQ functions to propagate the
> error code properly so that we know exactly when -EPROBE_DEFER makes
> sense (i.e. the IRQ domain for an interrupt-parent hasn't been
> registered yet).

I see.

> Actually I posted a round of patches quite a while back that did exactly
> this for interrupts. The changes were somewhat involved because it means
> propagating an error code from fairly deep down in the OF code back to
> the various higher-level helpers. If you're interested, the last version
> of that is here:
> 
> 	https://lkml.org/lkml/2013/9/18/216
> 
> Grant in particular seemed to be uncomfortable about how invasive the
> patch series is.

Interesting. It seems like a worthwhile thing to do, but I can understand
Grant's reluctance.

> 
> One problem with the IOMMU patches is that they've received some strong
> pushback from both Greg and Grant, arguing that it doesn't belong in the
> core. If you want to read up on that, here's a link to the latest
> version:
> 
> 	https://lkml.org/lkml/2013/12/12/74
> 
> Some things had been discussed in earlier iterations of that series, but
> this should give you the basic idea.

I'm skipping that discussion for now and stick with your summary

> It stands to reason that if they push back on the IOMMU variant of what
> is essentially the same thing, they will push back on the IRQ variant as
> well. One alternative I proposed was to, just as you suggested earlier,
> move the code into platform_drv_probe() or rather a function called from
> it. That proposal never got any replies, though.
> 
> 	https://lkml.org/lkml/2013/12/14/39

I guess putting it into the platform_drv_probe function seems reasonable,
I would be more scared of the implications of a notifier based method.

> > We could then skip adding the resources at device creation time.
> > Is this something you already plan to do later, or is there a reason
> > it wouldn't work?
> 
> The current thread here suggests that it would be preferable not to have
> any static allocations at all, but rather introduce a new API to resolve
> things at probe time if necessary. I think the idea was to have a set of
> functions like:
> 
> 	int device_get_irq(struct device *dev, unsigned int num);
> 	struct resource *device_get_mem_region(struct device *dev,
> 					       unsigned int num);
> 
> Or even possible the more generic:
> 
> 	struct resource *device_get_resource(struct device *dev,
> 					     unsigned int type,
> 					     unsigned int num);
> 
> If every driver used these functions, all resources could trivially be
> resolved at probe time. That solution is also the most invasive one of
> course, because it requires all existing drivers to be converted. At
> least the API would be all new and therefore the conversion could happen
> piecemeal.

Right, that does sound nice, and has the added benefit of saving
some memory allocations. I'd prefer the less generic variant here,
but I haven't given it much thought.
 
> One downside of that approach is that, while it maps well to platform
> devices or generic devices that have some sort of firmware interface
> such as OF or ACPI, I don't see how it can be made to work with an I2C
> client that's registered from board setup code for example. Well, I
> suppose that problem could be solved by throwing another lookup table at
> it, just like we do for clocks, regulators, PWMs and GPIOs.

Wouldn't you still be able to attach resources in the traditional
way for those, but use the same new interface to get at them?

> The good thing about it would be more consistency between the various
> types of resources. Eventually I could imagine that we could even get
> rid of struct resource (or at least only use it for a single type of
> resource). But as I said, it'll take quite a bit of work to convert
> everything to that.

struct resource is a structure with a long and complex history.
I'd certainly like to put some of it behind us and do something
that fits better into the 'struct device' concept which it
predates. I agree it would be a big effort though.

> > In the meantime, I don't see anything with your patch, but it also
> > wouldn't hurt to do it now if it solves all the problems.
> 
> Well, the commit message explicitly states that this is only a temporary
> measure, mostly to fix a number of regressions on OMAP where things were
> broken by the conversion to DT in 3.13. The same is probably true of
> other boards as well.

Right.

> I'm willing to help fix things properly in the long run, but I think a
> simple and low-risk patch like this would be worthwhile if it means that
> a good many boards aren't broken in 3.13. Also given the history of the
> above I can imagine that it will take more than the 3.14 cycle to get
> this resolved satisfactorily, so at least for interrupts this would give
> us a good stopgap solution in the meantime.

Ok. Thanks so much for your detailed background information!

	Arnd

Re: [PATCH] driver-core: platform: Resolve DT interrupt references late

[Thierry Reding]

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

On Wed, Jan 08, 2014 at 04:11:08PM +0100, Arnd Bergmann wrote:
> On Wednesday 08 January 2014 15:55:27 Thierry Reding wrote:
> > On Wed, Jan 08, 2014 at 02:41:19PM +0100, Arnd Bergmann wrote:
> > > On Wednesday 08 January 2014 13:51:17 Thierry Reding wrote:
[...]
> > Actually I posted a round of patches quite a while back that did exactly
> > this for interrupts. The changes were somewhat involved because it means
> > propagating an error code from fairly deep down in the OF code back to
> > the various higher-level helpers. If you're interested, the last version
> > of that is here:
> > 
> > 	https://lkml.org/lkml/2013/9/18/216
> > 
> > Grant in particular seemed to be uncomfortable about how invasive the
> > patch series is.
> 
> Interesting. It seems like a worthwhile thing to do, but I can understand
> Grant's reluctance.

To be fair, Grant didn't say outright no. Given how easily this could
turn into a regression nightmare I do understand the reluctance as well.
Merging things piece by piece would make it somewhat less risky but at
the same time makes it hard to keep at it.

> > It stands to reason that if they push back on the IOMMU variant of what
> > is essentially the same thing, they will push back on the IRQ variant as
> > well. One alternative I proposed was to, just as you suggested earlier,
> > move the code into platform_drv_probe() or rather a function called from
> > it. That proposal never got any replies, though.
> > 
> > 	https://lkml.org/lkml/2013/12/14/39
> 
> I guess putting it into the platform_drv_probe function seems reasonable,
> I would be more scared of the implications of a notifier based method.

I fully agree. Of course if we decide against moving things into the
core and in favour of a more generic API that drivers should use, then
this issue goes away silently at least for resources that the driver
needs to use explicitly (memory-mapped regions, interrupts, ...).

The issue remains for IOMMU which is meant to be used transparently
through the DMA API. Perhaps a good compromise would be to have some
sort of generic helper that can be called to initialize IOMMU support
for a particular device and support probe deferral on error. Something
like this perhaps:

	int iommu_attach(struct device *dev);
	int iommu_detach(struct device *dev);

I still don't like very much how that needs to be done in each driver
explicitly, but if we can't do it in the core, then the only other clean
way to handle it would be to treat it like any other sort of resource
and handle it explicitly. Perhaps handing out some sort of cookie would
be preferable to just an error code?

> > > We could then skip adding the resources at device creation time.
> > > Is this something you already plan to do later, or is there a reason
> > > it wouldn't work?
> > 
> > The current thread here suggests that it would be preferable not to have
> > any static allocations at all, but rather introduce a new API to resolve
> > things at probe time if necessary. I think the idea was to have a set of
> > functions like:
> > 
> > 	int device_get_irq(struct device *dev, unsigned int num);
> > 	struct resource *device_get_mem_region(struct device *dev,
> > 					       unsigned int num);
> > 
> > Or even possible the more generic:
> > 
> > 	struct resource *device_get_resource(struct device *dev,
> > 					     unsigned int type,
> > 					     unsigned int num);
> > 
> > If every driver used these functions, all resources could trivially be
> > resolved at probe time. That solution is also the most invasive one of
> > course, because it requires all existing drivers to be converted. At
> > least the API would be all new and therefore the conversion could happen
> > piecemeal.
> 
> Right, that does sound nice, and has the added benefit of saving
> some memory allocations. I'd prefer the less generic variant here,
> but I haven't given it much thought.

I do prefer the less generic ones as well. They seem to be more
convenient to use.

> > One downside of that approach is that, while it maps well to platform
> > devices or generic devices that have some sort of firmware interface
> > such as OF or ACPI, I don't see how it can be made to work with an I2C
> > client that's registered from board setup code for example. Well, I
> > suppose that problem could be solved by throwing another lookup table at
> > it, just like we do for clocks, regulators, PWMs and GPIOs.
> 
> Wouldn't you still be able to attach resources in the traditional
> way for those, but use the same new interface to get at them?

I wouldn't know how. For instance platform devices store the IRQ number
within a struct resource of type IORESOURCE_IRQ, whereas I2C clients
store them in the struct i2c_client's .irq field.

So without actually introspecting the struct device (possibly using the
.bus field for example) and upcasting you won't know how to get at the
resources. One possibility to remedy that would be to try and unify the
resources within struct device. But that doesn't feel right.

One other thing I had considered at one point was to extend the bus_type
structure and give it a way to obtain resources in a bus-specific way,
but that feel even more wrong.

Perhaps I'm missing something obvious, though, and this is actually much
more trivial to solve.

> > The good thing about it would be more consistency between the various
> > types of resources. Eventually I could imagine that we could even get
> > rid of struct resource (or at least only use it for a single type of
> > resource). But as I said, it'll take quite a bit of work to convert
> > everything to that.
> 
> struct resource is a structure with a long and complex history.
> I'd certainly like to put some of it behind us and do something
> that fits better into the 'struct device' concept which it
> predates. I agree it would be a big effort though.

I concur.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

[PATCH] driver-core: platform: Resolve DT interrupt references late

[Thierry Reding]

On Wed, Jan 08, 2014 at 04:11:08PM +0100, Arnd Bergmann wrote:
> On Wednesday 08 January 2014 15:55:27 Thierry Reding wrote:
> > On Wed, Jan 08, 2014 at 02:41:19PM +0100, Arnd Bergmann wrote:
> > > On Wednesday 08 January 2014 13:51:17 Thierry Reding wrote:
[...]
> > Actually I posted a round of patches quite a while back that did exactly
> > this for interrupts. The changes were somewhat involved because it means
> > propagating an error code from fairly deep down in the OF code back to
> > the various higher-level helpers. If you're interested, the last version
> > of that is here:
> > 
> > 	https://lkml.org/lkml/2013/9/18/216
> > 
> > Grant in particular seemed to be uncomfortable about how invasive the
> > patch series is.
> 
> Interesting. It seems like a worthwhile thing to do, but I can understand
> Grant's reluctance.

To be fair, Grant didn't say outright no. Given how easily this could
turn into a regression nightmare I do understand the reluctance as well.
Merging things piece by piece would make it somewhat less risky but at
the same time makes it hard to keep at it.

> > It stands to reason that if they push back on the IOMMU variant of what
> > is essentially the same thing, they will push back on the IRQ variant as
> > well. One alternative I proposed was to, just as you suggested earlier,
> > move the code into platform_drv_probe() or rather a function called from
> > it. That proposal never got any replies, though.
> > 
> > 	https://lkml.org/lkml/2013/12/14/39
> 
> I guess putting it into the platform_drv_probe function seems reasonable,
> I would be more scared of the implications of a notifier based method.

I fully agree. Of course if we decide against moving things into the
core and in favour of a more generic API that drivers should use, then
this issue goes away silently at least for resources that the driver
needs to use explicitly (memory-mapped regions, interrupts, ...).

The issue remains for IOMMU which is meant to be used transparently
through the DMA API. Perhaps a good compromise would be to have some
sort of generic helper that can be called to initialize IOMMU support
for a particular device and support probe deferral on error. Something
like this perhaps:

	int iommu_attach(struct device *dev);
	int iommu_detach(struct device *dev);

I still don't like very much how that needs to be done in each driver
explicitly, but if we can't do it in the core, then the only other clean
way to handle it would be to treat it like any other sort of resource
and handle it explicitly. Perhaps handing out some sort of cookie would
be preferable to just an error code?

> > > We could then skip adding the resources at device creation time.
> > > Is this something you already plan to do later, or is there a reason
> > > it wouldn't work?
> > 
> > The current thread here suggests that it would be preferable not to have
> > any static allocations at all, but rather introduce a new API to resolve
> > things at probe time if necessary. I think the idea was to have a set of
> > functions like:
> > 
> > 	int device_get_irq(struct device *dev, unsigned int num);
> > 	struct resource *device_get_mem_region(struct device *dev,
> > 					       unsigned int num);
> > 
> > Or even possible the more generic:
> > 
> > 	struct resource *device_get_resource(struct device *dev,
> > 					     unsigned int type,
> > 					     unsigned int num);
> > 
> > If every driver used these functions, all resources could trivially be
> > resolved at probe time. That solution is also the most invasive one of
> > course, because it requires all existing drivers to be converted. At
> > least the API would be all new and therefore the conversion could happen
> > piecemeal.
> 
> Right, that does sound nice, and has the added benefit of saving
> some memory allocations. I'd prefer the less generic variant here,
> but I haven't given it much thought.

I do prefer the less generic ones as well. They seem to be more
convenient to use.

> > One downside of that approach is that, while it maps well to platform
> > devices or generic devices that have some sort of firmware interface
> > such as OF or ACPI, I don't see how it can be made to work with an I2C
> > client that's registered from board setup code for example. Well, I
> > suppose that problem could be solved by throwing another lookup table at
> > it, just like we do for clocks, regulators, PWMs and GPIOs.
> 
> Wouldn't you still be able to attach resources in the traditional
> way for those, but use the same new interface to get at them?

I wouldn't know how. For instance platform devices store the IRQ number
within a struct resource of type IORESOURCE_IRQ, whereas I2C clients
store them in the struct i2c_client's .irq field.

So without actually introspecting the struct device (possibly using the
.bus field for example) and upcasting you won't know how to get at the
resources. One possibility to remedy that would be to try and unify the
resources within struct device. But that doesn't feel right.

One other thing I had considered at one point was to extend the bus_type
structure and give it a way to obtain resources in a bus-specific way,
but that feel even more wrong.

Perhaps I'm missing something obvious, though, and this is actually much
more trivial to solve.

> > The good thing about it would be more consistency between the various
> > types of resources. Eventually I could imagine that we could even get
> > rid of struct resource (or at least only use it for a single type of
> > resource). But as I said, it'll take quite a bit of work to convert
> > everything to that.
> 
> struct resource is a structure with a long and complex history.
> I'd certainly like to put some of it behind us and do something
> that fits better into the 'struct device' concept which it
> predates. I agree it would be a big effort though.

I concur.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140108/e1f786ae/attachment.sig>

Re: [PATCH] driver-core: platform: Resolve DT interrupt references late

[Arnd Bergmann]

On Wednesday 08 January 2014, Thierry Reding wrote:
> On Wed, Jan 08, 2014 at 04:11:08PM +0100, Arnd Bergmann wrote:
> > On Wednesday 08 January 2014 15:55:27 Thierry Reding wrote:
> > > It stands to reason that if they push back on the IOMMU variant of what
> > > is essentially the same thing, they will push back on the IRQ variant as
> > > well. One alternative I proposed was to, just as you suggested earlier,
> > > move the code into platform_drv_probe() or rather a function called from
> > > it. That proposal never got any replies, though.
> > > 
> > > 	https://lkml.org/lkml/2013/12/14/39
> > 
> > I guess putting it into the platform_drv_probe function seems reasonable,
> > I would be more scared of the implications of a notifier based method.
> 
> I fully agree. Of course if we decide against moving things into the
> core and in favour of a more generic API that drivers should use, then
> this issue goes away silently at least for resources that the driver
> needs to use explicitly (memory-mapped regions, interrupts, ...).
> 
> The issue remains for IOMMU which is meant to be used transparently
> through the DMA API. Perhaps a good compromise would be to have some
> sort of generic helper that can be called to initialize IOMMU support
> for a particular device and support probe deferral on error. Something
> like this perhaps:
> 
> 	int iommu_attach(struct device *dev);
> 	int iommu_detach(struct device *dev);
> 
> I still don't like very much how that needs to be done in each driver
> explicitly, but if we can't do it in the core, then the only other clean
> way to handle it would be to treat it like any other sort of resource
> and handle it explicitly. Perhaps handing out some sort of cookie would
> be preferable to just an error code?

The more I think about the iommu case, the more I am convinced that it
does belong into the core, in whatever form we can find. As far as I
can tell from the little reliable information I have on the topic, I
would assume that we can keep it in the DT probing code, as there won't
be a need for multiple arbitrary IOMMUs with ACPI or with board files.

> > > One downside of that approach is that, while it maps well to platform
> > > devices or generic devices that have some sort of firmware interface
> > > such as OF or ACPI, I don't see how it can be made to work with an I2C
> > > client that's registered from board setup code for example. Well, I
> > > suppose that problem could be solved by throwing another lookup table at
> > > it, just like we do for clocks, regulators, PWMs and GPIOs.
> > 
> > Wouldn't you still be able to attach resources in the traditional
> > way for those, but use the same new interface to get at them?
> 
> I wouldn't know how. For instance platform devices store the IRQ number
> within a struct resource of type IORESOURCE_IRQ, whereas I2C clients
> store them in the struct i2c_client's .irq field.

Good point, I forgot about the special case for i2c_client->irq.
I looked now and noticed that very few i2c devices actually use this
field, but larger number uses platform_data, which has a similar
problem.

> So without actually introspecting the struct device (possibly using the
> .bus field for example) and upcasting you won't know how to get at the
> resources. One possibility to remedy that would be to try and unify the
> resources within struct device. But that doesn't feel right.
> 
> One other thing I had considered at one point was to extend the bus_type
> structure and give it a way to obtain resources in a bus-specific way,
> but that feel even more wrong.
> 
> Perhaps I'm missing something obvious, though, and this is actually much
> more trivial to solve.

No trivial solution that I can see. I think we can deal with the case
where platform code uses platform_device->resources, and everything else
comes down to having multiple code branches in the driver, as we already
have to deal with platform_data and DT properties describing stuff that
doesn't fit in the resources.

	Arnd

[PATCH] driver-core: platform: Resolve DT interrupt references late

[Arnd Bergmann]

On Wednesday 08 January 2014, Thierry Reding wrote:
> On Wed, Jan 08, 2014 at 04:11:08PM +0100, Arnd Bergmann wrote:
> > On Wednesday 08 January 2014 15:55:27 Thierry Reding wrote:
> > > It stands to reason that if they push back on the IOMMU variant of what
> > > is essentially the same thing, they will push back on the IRQ variant as
> > > well. One alternative I proposed was to, just as you suggested earlier,
> > > move the code into platform_drv_probe() or rather a function called from
> > > it. That proposal never got any replies, though.
> > > 
> > > 	https://lkml.org/lkml/2013/12/14/39
> > 
> > I guess putting it into the platform_drv_probe function seems reasonable,
> > I would be more scared of the implications of a notifier based method.
> 
> I fully agree. Of course if we decide against moving things into the
> core and in favour of a more generic API that drivers should use, then
> this issue goes away silently at least for resources that the driver
> needs to use explicitly (memory-mapped regions, interrupts, ...).
> 
> The issue remains for IOMMU which is meant to be used transparently
> through the DMA API. Perhaps a good compromise would be to have some
> sort of generic helper that can be called to initialize IOMMU support
> for a particular device and support probe deferral on error. Something
> like this perhaps:
> 
> 	int iommu_attach(struct device *dev);
> 	int iommu_detach(struct device *dev);
> 
> I still don't like very much how that needs to be done in each driver
> explicitly, but if we can't do it in the core, then the only other clean
> way to handle it would be to treat it like any other sort of resource
> and handle it explicitly. Perhaps handing out some sort of cookie would
> be preferable to just an error code?

The more I think about the iommu case, the more I am convinced that it
does belong into the core, in whatever form we can find. As far as I
can tell from the little reliable information I have on the topic, I
would assume that we can keep it in the DT probing code, as there won't
be a need for multiple arbitrary IOMMUs with ACPI or with board files.

> > > One downside of that approach is that, while it maps well to platform
> > > devices or generic devices that have some sort of firmware interface
> > > such as OF or ACPI, I don't see how it can be made to work with an I2C
> > > client that's registered from board setup code for example. Well, I
> > > suppose that problem could be solved by throwing another lookup table at
> > > it, just like we do for clocks, regulators, PWMs and GPIOs.
> > 
> > Wouldn't you still be able to attach resources in the traditional
> > way for those, but use the same new interface to get at them?
> 
> I wouldn't know how. For instance platform devices store the IRQ number
> within a struct resource of type IORESOURCE_IRQ, whereas I2C clients
> store them in the struct i2c_client's .irq field.

Good point, I forgot about the special case for i2c_client->irq.
I looked now and noticed that very few i2c devices actually use this
field, but larger number uses platform_data, which has a similar
problem.

> So without actually introspecting the struct device (possibly using the
> .bus field for example) and upcasting you won't know how to get at the
> resources. One possibility to remedy that would be to try and unify the
> resources within struct device. But that doesn't feel right.
> 
> One other thing I had considered at one point was to extend the bus_type
> structure and give it a way to obtain resources in a bus-specific way,
> but that feel even more wrong.
> 
> Perhaps I'm missing something obvious, though, and this is actually much
> more trivial to solve.

No trivial solution that I can see. I think we can deal with the case
where platform code uses platform_device->resources, and everything else
comes down to having multiple code branches in the driver, as we already
have to deal with platform_data and DT properties describing stuff that
doesn't fit in the resources.

	Arnd

Re: [PATCH] driver-core: platform: Resolve DT interrupt references late

[Arnd Bergmann]

On Wednesday 08 January 2014, Thierry Reding wrote:
> On Wed, Jan 08, 2014 at 04:11:08PM +0100, Arnd Bergmann wrote:
> > On Wednesday 08 January 2014 15:55:27 Thierry Reding wrote:
> > > It stands to reason that if they push back on the IOMMU variant of what
> > > is essentially the same thing, they will push back on the IRQ variant as
> > > well. One alternative I proposed was to, just as you suggested earlier,
> > > move the code into platform_drv_probe() or rather a function called from
> > > it. That proposal never got any replies, though.
> > > 
> > > 	https://lkml.org/lkml/2013/12/14/39
> > 
> > I guess putting it into the platform_drv_probe function seems reasonable,
> > I would be more scared of the implications of a notifier based method.
> 
> I fully agree. Of course if we decide against moving things into the
> core and in favour of a more generic API that drivers should use, then
> this issue goes away silently at least for resources that the driver
> needs to use explicitly (memory-mapped regions, interrupts, ...).
> 
> The issue remains for IOMMU which is meant to be used transparently
> through the DMA API. Perhaps a good compromise would be to have some
> sort of generic helper that can be called to initialize IOMMU support
> for a particular device and support probe deferral on error. Something
> like this perhaps:
> 
> 	int iommu_attach(struct device *dev);
> 	int iommu_detach(struct device *dev);
> 
> I still don't like very much how that needs to be done in each driver
> explicitly, but if we can't do it in the core, then the only other clean
> way to handle it would be to treat it like any other sort of resource
> and handle it explicitly. Perhaps handing out some sort of cookie would
> be preferable to just an error code?

The more I think about the iommu case, the more I am convinced that it
does belong into the core, in whatever form we can find. As far as I
can tell from the little reliable information I have on the topic, I
would assume that we can keep it in the DT probing code, as there won't
be a need for multiple arbitrary IOMMUs with ACPI or with board files.

> > > One downside of that approach is that, while it maps well to platform
> > > devices or generic devices that have some sort of firmware interface
> > > such as OF or ACPI, I don't see how it can be made to work with an I2C
> > > client that's registered from board setup code for example. Well, I
> > > suppose that problem could be solved by throwing another lookup table at
> > > it, just like we do for clocks, regulators, PWMs and GPIOs.
> > 
> > Wouldn't you still be able to attach resources in the traditional
> > way for those, but use the same new interface to get at them?
> 
> I wouldn't know how. For instance platform devices store the IRQ number
> within a struct resource of type IORESOURCE_IRQ, whereas I2C clients
> store them in the struct i2c_client's .irq field.

Good point, I forgot about the special case for i2c_client->irq.
I looked now and noticed that very few i2c devices actually use this
field, but larger number uses platform_data, which has a similar
problem.

> So without actually introspecting the struct device (possibly using the
> .bus field for example) and upcasting you won't know how to get at the
> resources. One possibility to remedy that would be to try and unify the
> resources within struct device. But that doesn't feel right.
> 
> One other thing I had considered at one point was to extend the bus_type
> structure and give it a way to obtain resources in a bus-specific way,
> but that feel even more wrong.
> 
> Perhaps I'm missing something obvious, though, and this is actually much
> more trivial to solve.

No trivial solution that I can see. I think we can deal with the case
where platform code uses platform_device->resources, and everything else
comes down to having multiple code branches in the driver, as we already
have to deal with platform_data and DT properties describing stuff that
doesn't fit in the resources.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] driver-core: platform: Resolve DT interrupt references late

[Thierry Reding]

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

On Wed, Jan 08, 2014 at 05:25:17PM +0100, Arnd Bergmann wrote:
> On Wednesday 08 January 2014, Thierry Reding wrote:
> > On Wed, Jan 08, 2014 at 04:11:08PM +0100, Arnd Bergmann wrote:
> > > On Wednesday 08 January 2014 15:55:27 Thierry Reding wrote:
> > > > It stands to reason that if they push back on the IOMMU variant of what
> > > > is essentially the same thing, they will push back on the IRQ variant as
> > > > well. One alternative I proposed was to, just as you suggested earlier,
> > > > move the code into platform_drv_probe() or rather a function called from
> > > > it. That proposal never got any replies, though.
> > > > 
> > > > 	https://lkml.org/lkml/2013/12/14/39
> > > 
> > > I guess putting it into the platform_drv_probe function seems reasonable,
> > > I would be more scared of the implications of a notifier based method.
> > 
> > I fully agree. Of course if we decide against moving things into the
> > core and in favour of a more generic API that drivers should use, then
> > this issue goes away silently at least for resources that the driver
> > needs to use explicitly (memory-mapped regions, interrupts, ...).
> > 
> > The issue remains for IOMMU which is meant to be used transparently
> > through the DMA API. Perhaps a good compromise would be to have some
> > sort of generic helper that can be called to initialize IOMMU support
> > for a particular device and support probe deferral on error. Something
> > like this perhaps:
> > 
> > 	int iommu_attach(struct device *dev);
> > 	int iommu_detach(struct device *dev);
> > 
> > I still don't like very much how that needs to be done in each driver
> > explicitly, but if we can't do it in the core, then the only other clean
> > way to handle it would be to treat it like any other sort of resource
> > and handle it explicitly. Perhaps handing out some sort of cookie would
> > be preferable to just an error code?
> 
> The more I think about the iommu case, the more I am convinced that it
> does belong into the core, in whatever form we can find. As far as I
> can tell from the little reliable information I have on the topic, I
> would assume that we can keep it in the DT probing code, as there won't
> be a need for multiple arbitrary IOMMUs with ACPI or with board files.

I think part of the problem is that we don't have any DT probing code
yet. of_platform_probe() would have been that code. Perhaps if you weigh
in Grant and Greg will reconsider.

> > > > One downside of that approach is that, while it maps well to platform
> > > > devices or generic devices that have some sort of firmware interface
> > > > such as OF or ACPI, I don't see how it can be made to work with an I2C
> > > > client that's registered from board setup code for example. Well, I
> > > > suppose that problem could be solved by throwing another lookup table at
> > > > it, just like we do for clocks, regulators, PWMs and GPIOs.
> > > 
> > > Wouldn't you still be able to attach resources in the traditional
> > > way for those, but use the same new interface to get at them?
> > 
> > I wouldn't know how. For instance platform devices store the IRQ number
> > within a struct resource of type IORESOURCE_IRQ, whereas I2C clients
> > store them in the struct i2c_client's .irq field.
> 
> Good point, I forgot about the special case for i2c_client->irq.
> I looked now and noticed that very few i2c devices actually use this
> field, but larger number uses platform_data, which has a similar
> problem.

Yeah. It's kind of messy. The more I think about it, the more I begin to
like the lookup table option. One big advantage of that is that we could
actually unify much of the lookup code, much like we do for other types
of resources. It's a pattern that has worked fairly well in a number of
cases, so it seems natural to use it for interrupts as well.

An even more extreme option would be to go all the way and introduce
struct irq, along the same lines of the new struct gpiod. That would
allow nice things such as storing trigger types and such within the IRQ
handle and propagate them automatically.

> > So without actually introspecting the struct device (possibly using the
> > .bus field for example) and upcasting you won't know how to get at the
> > resources. One possibility to remedy that would be to try and unify the
> > resources within struct device. But that doesn't feel right.
> > 
> > One other thing I had considered at one point was to extend the bus_type
> > structure and give it a way to obtain resources in a bus-specific way,
> > but that feel even more wrong.
> > 
> > Perhaps I'm missing something obvious, though, and this is actually much
> > more trivial to solve.
> 
> No trivial solution that I can see. I think we can deal with the case
> where platform code uses platform_device->resources, and everything else
> comes down to having multiple code branches in the driver, as we already
> have to deal with platform_data and DT properties describing stuff that
> doesn't fit in the resources.

That would be another argument in favour of the lookup table. It would
provide a unified mechanism to define static interrupts if no firmware
interface is available *independent* of the device type. You could have
something like:

	static const struct irq_lookup board_irq_lookup[] = {
		IRQ_LOOKUP("gpio", 0, "0-0040", NULL), /* I2C client via GPIO expander */
		IRQ_LOOKUP("intc", 0, "ehci.1", NULL), /* platform device via INTC */
	};

Along with:

	struct irq *irq_get(struct device *dev, const char *con_id);

To look it up via DT, ACPI, lookup table. That obviously means a more or
less complete change in how interrupts are handled in the kernel, and it
may not be worth it in the end.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

[PATCH] driver-core: platform: Resolve DT interrupt references late

[Thierry Reding]

On Wed, Jan 08, 2014 at 05:25:17PM +0100, Arnd Bergmann wrote:
> On Wednesday 08 January 2014, Thierry Reding wrote:
> > On Wed, Jan 08, 2014 at 04:11:08PM +0100, Arnd Bergmann wrote:
> > > On Wednesday 08 January 2014 15:55:27 Thierry Reding wrote:
> > > > It stands to reason that if they push back on the IOMMU variant of what
> > > > is essentially the same thing, they will push back on the IRQ variant as
> > > > well. One alternative I proposed was to, just as you suggested earlier,
> > > > move the code into platform_drv_probe() or rather a function called from
> > > > it. That proposal never got any replies, though.
> > > > 
> > > > 	https://lkml.org/lkml/2013/12/14/39
> > > 
> > > I guess putting it into the platform_drv_probe function seems reasonable,
> > > I would be more scared of the implications of a notifier based method.
> > 
> > I fully agree. Of course if we decide against moving things into the
> > core and in favour of a more generic API that drivers should use, then
> > this issue goes away silently at least for resources that the driver
> > needs to use explicitly (memory-mapped regions, interrupts, ...).
> > 
> > The issue remains for IOMMU which is meant to be used transparently
> > through the DMA API. Perhaps a good compromise would be to have some
> > sort of generic helper that can be called to initialize IOMMU support
> > for a particular device and support probe deferral on error. Something
> > like this perhaps:
> > 
> > 	int iommu_attach(struct device *dev);
> > 	int iommu_detach(struct device *dev);
> > 
> > I still don't like very much how that needs to be done in each driver
> > explicitly, but if we can't do it in the core, then the only other clean
> > way to handle it would be to treat it like any other sort of resource
> > and handle it explicitly. Perhaps handing out some sort of cookie would
> > be preferable to just an error code?
> 
> The more I think about the iommu case, the more I am convinced that it
> does belong into the core, in whatever form we can find. As far as I
> can tell from the little reliable information I have on the topic, I
> would assume that we can keep it in the DT probing code, as there won't
> be a need for multiple arbitrary IOMMUs with ACPI or with board files.

I think part of the problem is that we don't have any DT probing code
yet. of_platform_probe() would have been that code. Perhaps if you weigh
in Grant and Greg will reconsider.

> > > > One downside of that approach is that, while it maps well to platform
> > > > devices or generic devices that have some sort of firmware interface
> > > > such as OF or ACPI, I don't see how it can be made to work with an I2C
> > > > client that's registered from board setup code for example. Well, I
> > > > suppose that problem could be solved by throwing another lookup table at
> > > > it, just like we do for clocks, regulators, PWMs and GPIOs.
> > > 
> > > Wouldn't you still be able to attach resources in the traditional
> > > way for those, but use the same new interface to get at them?
> > 
> > I wouldn't know how. For instance platform devices store the IRQ number
> > within a struct resource of type IORESOURCE_IRQ, whereas I2C clients
> > store them in the struct i2c_client's .irq field.
> 
> Good point, I forgot about the special case for i2c_client->irq.
> I looked now and noticed that very few i2c devices actually use this
> field, but larger number uses platform_data, which has a similar
> problem.

Yeah. It's kind of messy. The more I think about it, the more I begin to
like the lookup table option. One big advantage of that is that we could
actually unify much of the lookup code, much like we do for other types
of resources. It's a pattern that has worked fairly well in a number of
cases, so it seems natural to use it for interrupts as well.

An even more extreme option would be to go all the way and introduce
struct irq, along the same lines of the new struct gpiod. That would
allow nice things such as storing trigger types and such within the IRQ
handle and propagate them automatically.

> > So without actually introspecting the struct device (possibly using the
> > .bus field for example) and upcasting you won't know how to get at the
> > resources. One possibility to remedy that would be to try and unify the
> > resources within struct device. But that doesn't feel right.
> > 
> > One other thing I had considered at one point was to extend the bus_type
> > structure and give it a way to obtain resources in a bus-specific way,
> > but that feel even more wrong.
> > 
> > Perhaps I'm missing something obvious, though, and this is actually much
> > more trivial to solve.
> 
> No trivial solution that I can see. I think we can deal with the case
> where platform code uses platform_device->resources, and everything else
> comes down to having multiple code branches in the driver, as we already
> have to deal with platform_data and DT properties describing stuff that
> doesn't fit in the resources.

That would be another argument in favour of the lookup table. It would
provide a unified mechanism to define static interrupts if no firmware
interface is available *independent* of the device type. You could have
something like:

	static const struct irq_lookup board_irq_lookup[] = {
		IRQ_LOOKUP("gpio", 0, "0-0040", NULL), /* I2C client via GPIO expander */
		IRQ_LOOKUP("intc", 0, "ehci.1", NULL), /* platform device via INTC */
	};

Along with:

	struct irq *irq_get(struct device *dev, const char *con_id);

To look it up via DT, ACPI, lookup table. That obviously means a more or
less complete change in how interrupts are handled in the kernel, and it
may not be worth it in the end.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140108/a53c0093/attachment-0001.sig>

Re: [PATCH] driver-core: platform: Resolve DT interrupt references late

[Arnd Bergmann]

On Wednesday 08 January 2014 20:59:10 Thierry Reding wrote:
> On Wed, Jan 08, 2014 at 05:25:17PM +0100, Arnd Bergmann wrote:
> > On Wednesday 08 January 2014, Thierry Reding wrote:
> > > On Wed, Jan 08, 2014 at 04:11:08PM +0100, Arnd Bergmann wrote:
> > The more I think about the iommu case, the more I am convinced that it
> > does belong into the core, in whatever form we can find. As far as I
> > can tell from the little reliable information I have on the topic, I
> > would assume that we can keep it in the DT probing code, as there won't
> > be a need for multiple arbitrary IOMMUs with ACPI or with board files.
> 
> I think part of the problem is that we don't have any DT probing code
> yet. of_platform_probe() would have been that code. Perhaps if you weigh
> in Grant and Greg will reconsider.

For all I know, we don't even have a binding proposal, but I may
have missed that.

> > Good point, I forgot about the special case for i2c_client->irq.
> > I looked now and noticed that very few i2c devices actually use this
> > field, but larger number uses platform_data, which has a similar
> > problem.
> 
> Yeah. It's kind of messy. The more I think about it, the more I begin to
> like the lookup table option. One big advantage of that is that we could
> actually unify much of the lookup code, much like we do for other types
> of resources. It's a pattern that has worked fairly well in a number of
> cases, so it seems natural to use it for interrupts as well.
> 
> An even more extreme option would be to go all the way and introduce
> struct irq, along the same lines of the new struct gpiod. That would
> allow nice things such as storing trigger types and such within the IRQ
> handle and propagate them automatically.

We already have struct irq_desc, and I believe everybody who works
with interrupts supports migrating from irq number interfaces to
irq descriptors as soon as we can find someone willing to do that
work.
 
> > No trivial solution that I can see. I think we can deal with the case
> > where platform code uses platform_device->resources, and everything else
> > comes down to having multiple code branches in the driver, as we already
> > have to deal with platform_data and DT properties describing stuff that
> > doesn't fit in the resources.
> 
> That would be another argument in favour of the lookup table. It would
> provide a unified mechanism to define static interrupts if no firmware
> interface is available *independent* of the device type. You could have
> something like:
> 
> 	static const struct irq_lookup board_irq_lookup[] = {
> 		IRQ_LOOKUP("gpio", 0, "0-0040", NULL), /* I2C client via GPIO expander */
> 		IRQ_LOOKUP("intc", 0, "ehci.1", NULL), /* platform device via INTC */
> 	};
> 
> Along with:
> 
> 	struct irq *irq_get(struct device *dev, const char *con_id);
> 
> To look it up via DT, ACPI, lookup table. That obviously means a more or
> less complete change in how interrupts are handled in the kernel, and it
> may not be worth it in the end.

It would certainly need a long migration period, and a plan for how to
get there without breaking things in the meantime. Rather than a lookup
table like the kind we have for clocks, I'd prefer a general way to
attach named properties to devices. My feeling is that building upon
devres would be a good plan, since it already provides a way to attach
arbitrary data to a device.

	Arnd

[PATCH] driver-core: platform: Resolve DT interrupt references late

[Arnd Bergmann]

On Wednesday 08 January 2014 20:59:10 Thierry Reding wrote:
> On Wed, Jan 08, 2014 at 05:25:17PM +0100, Arnd Bergmann wrote:
> > On Wednesday 08 January 2014, Thierry Reding wrote:
> > > On Wed, Jan 08, 2014 at 04:11:08PM +0100, Arnd Bergmann wrote:
> > The more I think about the iommu case, the more I am convinced that it
> > does belong into the core, in whatever form we can find. As far as I
> > can tell from the little reliable information I have on the topic, I
> > would assume that we can keep it in the DT probing code, as there won't
> > be a need for multiple arbitrary IOMMUs with ACPI or with board files.
> 
> I think part of the problem is that we don't have any DT probing code
> yet. of_platform_probe() would have been that code. Perhaps if you weigh
> in Grant and Greg will reconsider.

For all I know, we don't even have a binding proposal, but I may
have missed that.

> > Good point, I forgot about the special case for i2c_client->irq.
> > I looked now and noticed that very few i2c devices actually use this
> > field, but larger number uses platform_data, which has a similar
> > problem.
> 
> Yeah. It's kind of messy. The more I think about it, the more I begin to
> like the lookup table option. One big advantage of that is that we could
> actually unify much of the lookup code, much like we do for other types
> of resources. It's a pattern that has worked fairly well in a number of
> cases, so it seems natural to use it for interrupts as well.
> 
> An even more extreme option would be to go all the way and introduce
> struct irq, along the same lines of the new struct gpiod. That would
> allow nice things such as storing trigger types and such within the IRQ
> handle and propagate them automatically.

We already have struct irq_desc, and I believe everybody who works
with interrupts supports migrating from irq number interfaces to
irq descriptors as soon as we can find someone willing to do that
work.
 
> > No trivial solution that I can see. I think we can deal with the case
> > where platform code uses platform_device->resources, and everything else
> > comes down to having multiple code branches in the driver, as we already
> > have to deal with platform_data and DT properties describing stuff that
> > doesn't fit in the resources.
> 
> That would be another argument in favour of the lookup table. It would
> provide a unified mechanism to define static interrupts if no firmware
> interface is available *independent* of the device type. You could have
> something like:
> 
> 	static const struct irq_lookup board_irq_lookup[] = {
> 		IRQ_LOOKUP("gpio", 0, "0-0040", NULL), /* I2C client via GPIO expander */
> 		IRQ_LOOKUP("intc", 0, "ehci.1", NULL), /* platform device via INTC */
> 	};
> 
> Along with:
> 
> 	struct irq *irq_get(struct device *dev, const char *con_id);
> 
> To look it up via DT, ACPI, lookup table. That obviously means a more or
> less complete change in how interrupts are handled in the kernel, and it
> may not be worth it in the end.

It would certainly need a long migration period, and a plan for how to
get there without breaking things in the meantime. Rather than a lookup
table like the kind we have for clocks, I'd prefer a general way to
attach named properties to devices. My feeling is that building upon
devres would be a good plan, since it already provides a way to attach
arbitrary data to a device.

	Arnd

Re: [PATCH] driver-core: platform: Resolve DT interrupt references late

[Arnd Bergmann]

On Wednesday 08 January 2014 20:59:10 Thierry Reding wrote:
> On Wed, Jan 08, 2014 at 05:25:17PM +0100, Arnd Bergmann wrote:
> > On Wednesday 08 January 2014, Thierry Reding wrote:
> > > On Wed, Jan 08, 2014 at 04:11:08PM +0100, Arnd Bergmann wrote:
> > The more I think about the iommu case, the more I am convinced that it
> > does belong into the core, in whatever form we can find. As far as I
> > can tell from the little reliable information I have on the topic, I
> > would assume that we can keep it in the DT probing code, as there won't
> > be a need for multiple arbitrary IOMMUs with ACPI or with board files.
> 
> I think part of the problem is that we don't have any DT probing code
> yet. of_platform_probe() would have been that code. Perhaps if you weigh
> in Grant and Greg will reconsider.

For all I know, we don't even have a binding proposal, but I may
have missed that.

> > Good point, I forgot about the special case for i2c_client->irq.
> > I looked now and noticed that very few i2c devices actually use this
> > field, but larger number uses platform_data, which has a similar
> > problem.
> 
> Yeah. It's kind of messy. The more I think about it, the more I begin to
> like the lookup table option. One big advantage of that is that we could
> actually unify much of the lookup code, much like we do for other types
> of resources. It's a pattern that has worked fairly well in a number of
> cases, so it seems natural to use it for interrupts as well.
> 
> An even more extreme option would be to go all the way and introduce
> struct irq, along the same lines of the new struct gpiod. That would
> allow nice things such as storing trigger types and such within the IRQ
> handle and propagate them automatically.

We already have struct irq_desc, and I believe everybody who works
with interrupts supports migrating from irq number interfaces to
irq descriptors as soon as we can find someone willing to do that
work.
 
> > No trivial solution that I can see. I think we can deal with the case
> > where platform code uses platform_device->resources, and everything else
> > comes down to having multiple code branches in the driver, as we already
> > have to deal with platform_data and DT properties describing stuff that
> > doesn't fit in the resources.
> 
> That would be another argument in favour of the lookup table. It would
> provide a unified mechanism to define static interrupts if no firmware
> interface is available *independent* of the device type. You could have
> something like:
> 
> 	static const struct irq_lookup board_irq_lookup[] = {
> 		IRQ_LOOKUP("gpio", 0, "0-0040", NULL), /* I2C client via GPIO expander */
> 		IRQ_LOOKUP("intc", 0, "ehci.1", NULL), /* platform device via INTC */
> 	};
> 
> Along with:
> 
> 	struct irq *irq_get(struct device *dev, const char *con_id);
> 
> To look it up via DT, ACPI, lookup table. That obviously means a more or
> less complete change in how interrupts are handled in the kernel, and it
> may not be worth it in the end.

It would certainly need a long migration period, and a plan for how to
get there without breaking things in the meantime. Rather than a lookup
table like the kind we have for clocks, I'd prefer a general way to
attach named properties to devices. My feeling is that building upon
devres would be a good plan, since it already provides a way to attach
arbitrary data to a device.

	Arnd

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] driver-core: platform: Resolve DT interrupt references late

[Thierry Reding]

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

On Wed, Jan 08, 2014 at 09:09:17PM +0100, Arnd Bergmann wrote:
> On Wednesday 08 January 2014 20:59:10 Thierry Reding wrote:
> > On Wed, Jan 08, 2014 at 05:25:17PM +0100, Arnd Bergmann wrote:
> > > On Wednesday 08 January 2014, Thierry Reding wrote:
> > > > On Wed, Jan 08, 2014 at 04:11:08PM +0100, Arnd Bergmann wrote:
> > > The more I think about the iommu case, the more I am convinced that it
> > > does belong into the core, in whatever form we can find. As far as I
> > > can tell from the little reliable information I have on the topic, I
> > > would assume that we can keep it in the DT probing code, as there won't
> > > be a need for multiple arbitrary IOMMUs with ACPI or with board files.
> > 
> > I think part of the problem is that we don't have any DT probing code
> > yet. of_platform_probe() would have been that code. Perhaps if you weigh
> > in Grant and Greg will reconsider.
> 
> For all I know, we don't even have a binding proposal, but I may
> have missed that.

Yeah, last time I checked there was no concensus on that. I'll try to
dig up the thread and get it going again, adding you on Cc if you don't
mind (and in case you weren't Cc'ed in the first place anyway).

> > > Good point, I forgot about the special case for i2c_client->irq.
> > > I looked now and noticed that very few i2c devices actually use this
> > > field, but larger number uses platform_data, which has a similar
> > > problem.
> > 
> > Yeah. It's kind of messy. The more I think about it, the more I begin to
> > like the lookup table option. One big advantage of that is that we could
> > actually unify much of the lookup code, much like we do for other types
> > of resources. It's a pattern that has worked fairly well in a number of
> > cases, so it seems natural to use it for interrupts as well.
> > 
> > An even more extreme option would be to go all the way and introduce
> > struct irq, along the same lines of the new struct gpiod. That would
> > allow nice things such as storing trigger types and such within the IRQ
> > handle and propagate them automatically.
> 
> We already have struct irq_desc, and I believe everybody who works
> with interrupts supports migrating from irq number interfaces to
> irq descriptors as soon as we can find someone willing to do that
> work.

I didn't know that. I had always assumed irq_desc was only for internal
use by the IRQ code. Perhaps I'll look into that at some point.

> > > No trivial solution that I can see. I think we can deal with the case
> > > where platform code uses platform_device->resources, and everything else
> > > comes down to having multiple code branches in the driver, as we already
> > > have to deal with platform_data and DT properties describing stuff that
> > > doesn't fit in the resources.
> > 
> > That would be another argument in favour of the lookup table. It would
> > provide a unified mechanism to define static interrupts if no firmware
> > interface is available *independent* of the device type. You could have
> > something like:
> > 
> > 	static const struct irq_lookup board_irq_lookup[] = {
> > 		IRQ_LOOKUP("gpio", 0, "0-0040", NULL), /* I2C client via GPIO expander */
> > 		IRQ_LOOKUP("intc", 0, "ehci.1", NULL), /* platform device via INTC */
> > 	};
> > 
> > Along with:
> > 
> > 	struct irq *irq_get(struct device *dev, const char *con_id);
> > 
> > To look it up via DT, ACPI, lookup table. That obviously means a more or
> > less complete change in how interrupts are handled in the kernel, and it
> > may not be worth it in the end.
> 
> It would certainly need a long migration period, and a plan for how to
> get there without breaking things in the meantime. Rather than a lookup
> table like the kind we have for clocks, I'd prefer a general way to
> attach named properties to devices. My feeling is that building upon
> devres would be a good plan, since it already provides a way to attach
> arbitrary data to a device.

The problem with devres, or any other solution for that matter, is that
for the cases where we'd need something like this (that is, statically
allocated devices in board setup code) we don't have a fully initialized
struct device. We need at least device_initialize() to have been called
before devres can be used. Therefore we still need some sort of lookup
table that can be used to seed devres objects. Also devres will go away
completely when a driver is unloaded, so it'll have to be repopulated
everytime.

I don't think that would buy us much over a simple table lookup.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

[PATCH] driver-core: platform: Resolve DT interrupt references late

[Thierry Reding]

On Wed, Jan 08, 2014 at 09:09:17PM +0100, Arnd Bergmann wrote:
> On Wednesday 08 January 2014 20:59:10 Thierry Reding wrote:
> > On Wed, Jan 08, 2014 at 05:25:17PM +0100, Arnd Bergmann wrote:
> > > On Wednesday 08 January 2014, Thierry Reding wrote:
> > > > On Wed, Jan 08, 2014 at 04:11:08PM +0100, Arnd Bergmann wrote:
> > > The more I think about the iommu case, the more I am convinced that it
> > > does belong into the core, in whatever form we can find. As far as I
> > > can tell from the little reliable information I have on the topic, I
> > > would assume that we can keep it in the DT probing code, as there won't
> > > be a need for multiple arbitrary IOMMUs with ACPI or with board files.
> > 
> > I think part of the problem is that we don't have any DT probing code
> > yet. of_platform_probe() would have been that code. Perhaps if you weigh
> > in Grant and Greg will reconsider.
> 
> For all I know, we don't even have a binding proposal, but I may
> have missed that.

Yeah, last time I checked there was no concensus on that. I'll try to
dig up the thread and get it going again, adding you on Cc if you don't
mind (and in case you weren't Cc'ed in the first place anyway).

> > > Good point, I forgot about the special case for i2c_client->irq.
> > > I looked now and noticed that very few i2c devices actually use this
> > > field, but larger number uses platform_data, which has a similar
> > > problem.
> > 
> > Yeah. It's kind of messy. The more I think about it, the more I begin to
> > like the lookup table option. One big advantage of that is that we could
> > actually unify much of the lookup code, much like we do for other types
> > of resources. It's a pattern that has worked fairly well in a number of
> > cases, so it seems natural to use it for interrupts as well.
> > 
> > An even more extreme option would be to go all the way and introduce
> > struct irq, along the same lines of the new struct gpiod. That would
> > allow nice things such as storing trigger types and such within the IRQ
> > handle and propagate them automatically.
> 
> We already have struct irq_desc, and I believe everybody who works
> with interrupts supports migrating from irq number interfaces to
> irq descriptors as soon as we can find someone willing to do that
> work.

I didn't know that. I had always assumed irq_desc was only for internal
use by the IRQ code. Perhaps I'll look into that at some point.

> > > No trivial solution that I can see. I think we can deal with the case
> > > where platform code uses platform_device->resources, and everything else
> > > comes down to having multiple code branches in the driver, as we already
> > > have to deal with platform_data and DT properties describing stuff that
> > > doesn't fit in the resources.
> > 
> > That would be another argument in favour of the lookup table. It would
> > provide a unified mechanism to define static interrupts if no firmware
> > interface is available *independent* of the device type. You could have
> > something like:
> > 
> > 	static const struct irq_lookup board_irq_lookup[] = {
> > 		IRQ_LOOKUP("gpio", 0, "0-0040", NULL), /* I2C client via GPIO expander */
> > 		IRQ_LOOKUP("intc", 0, "ehci.1", NULL), /* platform device via INTC */
> > 	};
> > 
> > Along with:
> > 
> > 	struct irq *irq_get(struct device *dev, const char *con_id);
> > 
> > To look it up via DT, ACPI, lookup table. That obviously means a more or
> > less complete change in how interrupts are handled in the kernel, and it
> > may not be worth it in the end.
> 
> It would certainly need a long migration period, and a plan for how to
> get there without breaking things in the meantime. Rather than a lookup
> table like the kind we have for clocks, I'd prefer a general way to
> attach named properties to devices. My feeling is that building upon
> devres would be a good plan, since it already provides a way to attach
> arbitrary data to a device.

The problem with devres, or any other solution for that matter, is that
for the cases where we'd need something like this (that is, statically
allocated devices in board setup code) we don't have a fully initialized
struct device. We need at least device_initialize() to have been called
before devres can be used. Therefore we still need some sort of lookup
table that can be used to seed devres objects. Also devres will go away
completely when a driver is unloaded, so it'll have to be repopulated
everytime.

I don't think that would buy us much over a simple table lookup.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140108/e9fef157/attachment.sig>

Re: [PATCH] driver-core: platform: Resolve DT interrupt references late

[Arnd Bergmann]

On Wednesday 08 January 2014 21:24:08 Thierry Reding wrote:
> 
> The problem with devres, or any other solution for that matter, is that
> for the cases where we'd need something like this (that is, statically
> allocated devices in board setup code) we don't have a fully initialized
> struct device. We need at least device_initialize() to have been called
> before devres can be used. Therefore we still need some sort of lookup
> table that can be used to seed devres objects. Also devres will go away
> completely when a driver is unloaded, so it'll have to be repopulated
> everytime.
> 
> I don't think that would buy us much over a simple table lookup.

I would think we can come up with a way to add data to a device that
ends up in devres by the time the device gets registered. The question
is more whether you want a global table (or a set of global tables
for that matter) or rather have all the data local to the devices
you register. I generally prefer the latter.

There is an interesting question about what subsystems you'd want to
include in this mechanism. We have a growing number of subsystems
that want data represented in DT (clock, regulator, dmaengine, reset,
led, pwm, irq, iommu, ...), most of which don't have a 'struct resource'
equivalent. We could either try to create something generic enough
to easily cover all of them, or we declare that if you actually want
to use all of them you should really use DT, and we make it hard to
add another subsystem specific lookup mechanism.

	Arnd

[PATCH] driver-core: platform: Resolve DT interrupt references late

[Arnd Bergmann]

On Wednesday 08 January 2014 21:24:08 Thierry Reding wrote:
> 
> The problem with devres, or any other solution for that matter, is that
> for the cases where we'd need something like this (that is, statically
> allocated devices in board setup code) we don't have a fully initialized
> struct device. We need at least device_initialize() to have been called
> before devres can be used. Therefore we still need some sort of lookup
> table that can be used to seed devres objects. Also devres will go away
> completely when a driver is unloaded, so it'll have to be repopulated
> everytime.
> 
> I don't think that would buy us much over a simple table lookup.

I would think we can come up with a way to add data to a device that
ends up in devres by the time the device gets registered. The question
is more whether you want a global table (or a set of global tables
for that matter) or rather have all the data local to the devices
you register. I generally prefer the latter.

There is an interesting question about what subsystems you'd want to
include in this mechanism. We have a growing number of subsystems
that want data represented in DT (clock, regulator, dmaengine, reset,
led, pwm, irq, iommu, ...), most of which don't have a 'struct resource'
equivalent. We could either try to create something generic enough
to easily cover all of them, or we declare that if you actually want
to use all of them you should really use DT, and we make it hard to
add another subsystem specific lookup mechanism.

	Arnd

Re: [PATCH] driver-core: platform: Resolve DT interrupt references late

[Tony Lindgren]

* Thierry Reding <thierry.reding@gmail.com> [140108 04:55]:
> When devices are probed from the device tree, any interrupts that they
> reference are resolved at device creation time. This causes problems if
> the interrupt provider hasn't been registered yet at that time, which
> results in the interrupt being set to 0.
> 
> This is especially bad for platform devices because they are created at
> a very early stage during boot when the majority of interrupt providers
> haven't had a chance to be probed yet. One of the platform where this
> causes major issues is OMAP.
> 
> Note that this patch is the easy way out to fix a large part of the
> problems for now. A more proper solution for the long term would be to
> transition drivers to an API that always resolves resources of any kind
> (not only interrupts) at probe time.
> 
> For some background and discussion on possible solutions, see:
> 
> 	https://lkml.org/lkml/2013/11/22/520
> 
> Acked-by: Rob Herring <robherring2@gmail.com>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> Note that this is somewhat urgent and should if at all possible go into
> v3.13 before the release.
> 
>  drivers/base/platform.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 3a94b799f166..c894d1af3a5e 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -13,6 +13,7 @@
>  #include <linux/string.h>
>  #include <linux/platform_device.h>
>  #include <linux/of_device.h>
> +#include <linux/of_irq.h>
>  #include <linux/module.h>
>  #include <linux/init.h>
>  #include <linux/dma-mapping.h>
> @@ -87,7 +88,12 @@ int platform_get_irq(struct platform_device *dev, unsigned int num)
>  		return -ENXIO;
>  	return dev->archdata.irqs[num];
>  #else
> -	struct resource *r = platform_get_resource(dev, IORESOURCE_IRQ, num);
> +	struct resource *r;
> +
> +	if (IS_ENABLED(CONFIG_OF) && dev->dev.of_node)
> +		return irq_of_parse_and_map(dev->dev.of_node, num);
> +
> +	r = platform_get_resource(dev, IORESOURCE_IRQ, num);
>  
>  	return r ? r->start : -ENXIO;
>  #endif

Hmm actually testing this patch, it does not fix fix the $Subject bug :(

irq: no irq domain found for /ocp/pinmux@48002030 !
[    0.301361] ------------[ cut here ]------------
[    0.301391] WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
[    0.301422] Modules linked in:
[    0.301452] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc7-00002-g4d998a6 #17
[    0.301513] [<c0015c04>] (unwind_backtrace+0x0/0xf4) from [<c00127b0>] (show_stack+0x14/0x1c)
[    0.301544] [<c00127b0>] (show_stack+0x14/0x1c) from [<c05685a4>] (dump_stack+0x6c/0xa0)
[    0.301574] [<c05685a4>] (dump_stack+0x6c/0xa0) from [<c00425b4>] (warn_slowpath_common+0x64/0x84)
[    0.301605] [<c00425b4>] (warn_slowpath_common+0x64/0x84) from [<c00425f0>] (warn_slowpath_null+0x1c/0x24)
[    0.301635] [<c00425f0>] (warn_slowpath_null+0x1c/0x24) from [<c0485210>] (of_device_alloc+0x144/0x184)
[    0.301635] [<c0485210>] (of_device_alloc+0x144/0x184) from [<c0485294>] (of_platform_device_create_pdata+0x44/0x9c)
[    0.301666] [<c0485294>] (of_platform_device_create_pdata+0x44/0x9c) from [<c04853bc>] (of_platform_bus_create+0xd0/0x170)
[    0.301696] [<c04853bc>] (of_platform_bus_create+0xd0/0x170) from [<c0485418>] (of_platform_bus_create+0x12c/0x170)
[    0.301727] [<c0485418>] (of_platform_bus_create+0x12c/0x170) from [<c04854bc>] (of_platform_populate+0x60/0x98)
[    0.301757] [<c04854bc>] (of_platform_populate+0x60/0x98) from [<c07ca53c>] (pdata_quirks_init+0x28/0x78)
[    0.301788] [<c07ca53c>] (pdata_quirks_init+0x28/0x78) from [<c07bab20>] (customize_machine+0x20/0x48)
[    0.301818] [<c07bab20>] (customize_machine+0x20/0x48) from [<c000882c>] (do_one_initcall+0x2c/0x150)
[    0.301849] [<c000882c>] (do_one_initcall+0x2c/0x150) from [<c07b75d8>] (do_basic_setup+0x94/0xd4)
[    0.301879] [<c07b75d8>] (do_basic_setup+0x94/0xd4) from [<c07b7694>] (kernel_init_freeable+0x7c/0x120)
[    0.301910] [<c07b7694>] (kernel_init_freeable+0x7c/0x120) from [<c05667ec>] (kernel_init+0x8/0x120)
[    0.301940] [<c05667ec>] (kernel_init+0x8/0x120) from [<c000e908>] (ret_from_fork+0x14/0x2c)
[    0.302124] ---[ end trace 2b87f5de2f86f809 ]---
...

There's nothing wrong with the interrupt related code paths, we're just
trying to call the functions at a wrong time when thing are not yet
initialized.

Below is a repost of what works for me without using notifiers. Anybody
got any better ideas for a minimal fix?

Regards,

Tony

8< -------------------------------
From: Tony Lindgren <tony@atomide.com>
Date: Tue, 7 Jan 2014 17:07:18 -0800
Subject: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

Currently we get the following kind of errors if we try to use interrupt
phandles to irqchips that have not yet initialized:

irq: no irq domain found for /ocp/pinmux@48002030 !
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
(show_stack+0x14/0x1c)
(dump_stack+0x6c/0xa0)
(warn_slowpath_common+0x64/0x84)
(warn_slowpath_null+0x1c/0x24)
(of_device_alloc+0x144/0x184)
(of_platform_device_create_pdata+0x44/0x9c)
(of_platform_bus_create+0xd0/0x170)
(of_platform_bus_create+0x12c/0x170)
(of_platform_populate+0x60/0x98)

This is because we're wrongly trying to populate resources that are not yet
available. It's perfectly valid to create irqchips dynamically, so let's
fix up the issue by populating the interrupt resources at the driver probe
time instead.

Note that at least currently we cannot dynamically allocate the resources as bus
specific code may add legacy resources with platform_device_add_resources()
before the driver probe. At least omap_device_alloc() currently relies on
num_resources to determine if legacy resources should be added. This issue
will get fixed automatically when mach-omap2 boots with DT only, but there
are probably other places too where platform_device_add_resources() modifies
things before driver probe.

The addition of of_platform_probe() is based on patches posted earlier by
Thierry Reding <thierry.reding@gmail.com>.

Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -481,6 +481,10 @@ static int platform_drv_probe(struct device *_dev)
 	struct platform_device *dev = to_platform_device(_dev);
 	int ret;
 
+	ret = of_platform_probe(dev);
+	if (ret)
+		return ret;
+
 	if (ACPI_HANDLE(_dev))
 		acpi_dev_pm_attach(_dev, true);
 
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -141,7 +141,7 @@ struct platform_device *of_device_alloc(struct device_node *np,
 				  struct device *parent)
 {
 	struct platform_device *dev;
-	int rc, i, num_reg = 0, num_irq;
+	int num_reg = 0, num_irq;
 	struct resource *res, temp_res;
 
 	dev = platform_device_alloc("", -1);
@@ -154,7 +154,14 @@ struct platform_device *of_device_alloc(struct device_node *np,
 			num_reg++;
 	num_irq = of_irq_count(np);
 
-	/* Populate the resource table */
+	/*
+	 * Only allocate the resources for us to use later on. Note that bus
+	 * specific code may also add in additional legacy resources using
+	 * platform_device_add_resources(), and may even rely on us allocating
+	 * the basic resources here to do so. So we cannot allocate the
+	 * resources lazily until the legacy code has been fixed to not rely
+	 * on allocating resources here.
+	 */
 	if (num_irq || num_reg) {
 		res = kzalloc(sizeof(*res) * (num_irq + num_reg), GFP_KERNEL);
 		if (!res) {
@@ -164,11 +171,7 @@ struct platform_device *of_device_alloc(struct device_node *np,
 
 		dev->num_resources = num_reg + num_irq;
 		dev->resource = res;
-		for (i = 0; i < num_reg; i++, res++) {
-			rc = of_address_to_resource(np, i, res);
-			WARN_ON(rc);
-		}
-		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
+		/* See of_device_resource_populate for populating the data */
 	}
 
 	dev->dev.of_node = of_node_get(np);
@@ -187,6 +190,50 @@ struct platform_device *of_device_alloc(struct device_node *np,
 EXPORT_SYMBOL(of_device_alloc);
 
 /**
+ * of_device_resource_populate - Populate device resources from device tree
+ * @dev: pointer to platform device
+ *
+ * The device interrupts are not necessarily available for all
+ * irqdomains initially so we need to populate them lazily at
+ * device probe time from of_platform_populate.
+ */
+static int of_device_resource_populate(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	int rc, i, num_reg = 0, num_irq;
+	struct resource *res, temp_res;
+
+	res = pdev->resource;
+
+	/*
+	 * Count the io and irq resources again. Currently we cannot rely on
+	 * pdev->num_resources as bus specific code may have changed that
+	 * with platform_device_add_resources(). But the resources we allocated
+	 * earlier are still there and available for us to populate.
+	 */
+	if (of_can_translate_address(np))
+		while (of_address_to_resource(np, num_reg, &temp_res) == 0)
+			num_reg++;
+	num_irq = of_irq_count(np);
+
+	if (pdev->num_resources < num_reg + num_irq) {
+		dev_WARN(&pdev->dev, "not enough resources %i < %i\n",
+			 pdev->num_resources, num_reg + num_irq);
+		return -EINVAL;
+	}
+
+	for (i = 0; i < num_reg; i++, res++) {
+		rc = of_address_to_resource(np, i, res);
+		WARN_ON(rc);
+	}
+
+	if (num_irq)
+		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
+
+	return 0;
+}
+
+/**
  * of_platform_device_create_pdata - Alloc, initialize and register an of_device
  * @np: pointer to node to create device for
  * @bus_id: name to assign device
@@ -485,4 +532,35 @@ int of_platform_populate(struct device_node *root,
 	return rc;
 }
 EXPORT_SYMBOL_GPL(of_platform_populate);
+
+/**
+ * of_platform_probe() - OF specific initialization at probe time
+ * @pdev: pointer to a platform device
+ *
+ * This function is called by the driver core to perform devicetree-specific
+ * setup for a given platform device at probe time. If a device's resources
+ * as specified in the device tree are not available yet, this function can
+ * return -EPROBE_DEFER and cause the device to be probed again later, when
+ * other drivers that potentially provide the missing resources have been
+ * probed in turn.
+ *
+ * Note that because of the above, all code executed by this function must
+ * be prepared to be run multiple times on the same device (i.e. it must be
+ * idempotent).
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int of_platform_probe(struct platform_device *pdev)
+{
+	int ret;
+
+	if (!pdev->dev.of_node)
+		return 0;
+
+	ret = of_device_resource_populate(pdev);
+	if (ret < 0)
+		return ret;
+
+	return 0;
+}
 #endif /* CONFIG_OF_ADDRESS */
--- a/include/linux/of_platform.h
+++ b/include/linux/of_platform.h
@@ -72,6 +72,8 @@ extern int of_platform_populate(struct device_node *root,
 				const struct of_device_id *matches,
 				const struct of_dev_auxdata *lookup,
 				struct device *parent);
+
+extern int of_platform_probe(struct platform_device *pdev);
 #else
 static inline int of_platform_populate(struct device_node *root,
 					const struct of_device_id *matches,
@@ -80,6 +82,11 @@ static inline int of_platform_populate(struct device_node *root,
 {
 	return -ENODEV;
 }
+
+static inline int of_platform_probe(struct platform_device *pdev)
+{
+	return 0;
+}
 #endif
 
 #endif	/* _LINUX_OF_PLATFORM_H */

[PATCH] driver-core: platform: Resolve DT interrupt references late

[Tony Lindgren]

* Thierry Reding <thierry.reding@gmail.com> [140108 04:55]:
> When devices are probed from the device tree, any interrupts that they
> reference are resolved at device creation time. This causes problems if
> the interrupt provider hasn't been registered yet at that time, which
> results in the interrupt being set to 0.
> 
> This is especially bad for platform devices because they are created at
> a very early stage during boot when the majority of interrupt providers
> haven't had a chance to be probed yet. One of the platform where this
> causes major issues is OMAP.
> 
> Note that this patch is the easy way out to fix a large part of the
> problems for now. A more proper solution for the long term would be to
> transition drivers to an API that always resolves resources of any kind
> (not only interrupts) at probe time.
> 
> For some background and discussion on possible solutions, see:
> 
> 	https://lkml.org/lkml/2013/11/22/520
> 
> Acked-by: Rob Herring <robherring2@gmail.com>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> Note that this is somewhat urgent and should if at all possible go into
> v3.13 before the release.
> 
>  drivers/base/platform.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 3a94b799f166..c894d1af3a5e 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -13,6 +13,7 @@
>  #include <linux/string.h>
>  #include <linux/platform_device.h>
>  #include <linux/of_device.h>
> +#include <linux/of_irq.h>
>  #include <linux/module.h>
>  #include <linux/init.h>
>  #include <linux/dma-mapping.h>
> @@ -87,7 +88,12 @@ int platform_get_irq(struct platform_device *dev, unsigned int num)
>  		return -ENXIO;
>  	return dev->archdata.irqs[num];
>  #else
> -	struct resource *r = platform_get_resource(dev, IORESOURCE_IRQ, num);
> +	struct resource *r;
> +
> +	if (IS_ENABLED(CONFIG_OF) && dev->dev.of_node)
> +		return irq_of_parse_and_map(dev->dev.of_node, num);
> +
> +	r = platform_get_resource(dev, IORESOURCE_IRQ, num);
>  
>  	return r ? r->start : -ENXIO;
>  #endif

Hmm actually testing this patch, it does not fix fix the $Subject bug :(

irq: no irq domain found for /ocp/pinmux at 48002030 !
[    0.301361] ------------[ cut here ]------------
[    0.301391] WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
[    0.301422] Modules linked in:
[    0.301452] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc7-00002-g4d998a6 #17
[    0.301513] [<c0015c04>] (unwind_backtrace+0x0/0xf4) from [<c00127b0>] (show_stack+0x14/0x1c)
[    0.301544] [<c00127b0>] (show_stack+0x14/0x1c) from [<c05685a4>] (dump_stack+0x6c/0xa0)
[    0.301574] [<c05685a4>] (dump_stack+0x6c/0xa0) from [<c00425b4>] (warn_slowpath_common+0x64/0x84)
[    0.301605] [<c00425b4>] (warn_slowpath_common+0x64/0x84) from [<c00425f0>] (warn_slowpath_null+0x1c/0x24)
[    0.301635] [<c00425f0>] (warn_slowpath_null+0x1c/0x24) from [<c0485210>] (of_device_alloc+0x144/0x184)
[    0.301635] [<c0485210>] (of_device_alloc+0x144/0x184) from [<c0485294>] (of_platform_device_create_pdata+0x44/0x9c)
[    0.301666] [<c0485294>] (of_platform_device_create_pdata+0x44/0x9c) from [<c04853bc>] (of_platform_bus_create+0xd0/0x170)
[    0.301696] [<c04853bc>] (of_platform_bus_create+0xd0/0x170) from [<c0485418>] (of_platform_bus_create+0x12c/0x170)
[    0.301727] [<c0485418>] (of_platform_bus_create+0x12c/0x170) from [<c04854bc>] (of_platform_populate+0x60/0x98)
[    0.301757] [<c04854bc>] (of_platform_populate+0x60/0x98) from [<c07ca53c>] (pdata_quirks_init+0x28/0x78)
[    0.301788] [<c07ca53c>] (pdata_quirks_init+0x28/0x78) from [<c07bab20>] (customize_machine+0x20/0x48)
[    0.301818] [<c07bab20>] (customize_machine+0x20/0x48) from [<c000882c>] (do_one_initcall+0x2c/0x150)
[    0.301849] [<c000882c>] (do_one_initcall+0x2c/0x150) from [<c07b75d8>] (do_basic_setup+0x94/0xd4)
[    0.301879] [<c07b75d8>] (do_basic_setup+0x94/0xd4) from [<c07b7694>] (kernel_init_freeable+0x7c/0x120)
[    0.301910] [<c07b7694>] (kernel_init_freeable+0x7c/0x120) from [<c05667ec>] (kernel_init+0x8/0x120)
[    0.301940] [<c05667ec>] (kernel_init+0x8/0x120) from [<c000e908>] (ret_from_fork+0x14/0x2c)
[    0.302124] ---[ end trace 2b87f5de2f86f809 ]---
...

There's nothing wrong with the interrupt related code paths, we're just
trying to call the functions at a wrong time when thing are not yet
initialized.

Below is a repost of what works for me without using notifiers. Anybody
got any better ideas for a minimal fix?

Regards,

Tony

8< -------------------------------
From: Tony Lindgren <tony@atomide.com>
Date: Tue, 7 Jan 2014 17:07:18 -0800
Subject: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

Currently we get the following kind of errors if we try to use interrupt
phandles to irqchips that have not yet initialized:

irq: no irq domain found for /ocp/pinmux at 48002030 !
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
(show_stack+0x14/0x1c)
(dump_stack+0x6c/0xa0)
(warn_slowpath_common+0x64/0x84)
(warn_slowpath_null+0x1c/0x24)
(of_device_alloc+0x144/0x184)
(of_platform_device_create_pdata+0x44/0x9c)
(of_platform_bus_create+0xd0/0x170)
(of_platform_bus_create+0x12c/0x170)
(of_platform_populate+0x60/0x98)

This is because we're wrongly trying to populate resources that are not yet
available. It's perfectly valid to create irqchips dynamically, so let's
fix up the issue by populating the interrupt resources at the driver probe
time instead.

Note that at least currently we cannot dynamically allocate the resources as bus
specific code may add legacy resources with platform_device_add_resources()
before the driver probe. At least omap_device_alloc() currently relies on
num_resources to determine if legacy resources should be added. This issue
will get fixed automatically when mach-omap2 boots with DT only, but there
are probably other places too where platform_device_add_resources() modifies
things before driver probe.

The addition of of_platform_probe() is based on patches posted earlier by
Thierry Reding <thierry.reding@gmail.com>.

Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -481,6 +481,10 @@ static int platform_drv_probe(struct device *_dev)
 	struct platform_device *dev = to_platform_device(_dev);
 	int ret;
 
+	ret = of_platform_probe(dev);
+	if (ret)
+		return ret;
+
 	if (ACPI_HANDLE(_dev))
 		acpi_dev_pm_attach(_dev, true);
 
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -141,7 +141,7 @@ struct platform_device *of_device_alloc(struct device_node *np,
 				  struct device *parent)
 {
 	struct platform_device *dev;
-	int rc, i, num_reg = 0, num_irq;
+	int num_reg = 0, num_irq;
 	struct resource *res, temp_res;
 
 	dev = platform_device_alloc("", -1);
@@ -154,7 +154,14 @@ struct platform_device *of_device_alloc(struct device_node *np,
 			num_reg++;
 	num_irq = of_irq_count(np);
 
-	/* Populate the resource table */
+	/*
+	 * Only allocate the resources for us to use later on. Note that bus
+	 * specific code may also add in additional legacy resources using
+	 * platform_device_add_resources(), and may even rely on us allocating
+	 * the basic resources here to do so. So we cannot allocate the
+	 * resources lazily until the legacy code has been fixed to not rely
+	 * on allocating resources here.
+	 */
 	if (num_irq || num_reg) {
 		res = kzalloc(sizeof(*res) * (num_irq + num_reg), GFP_KERNEL);
 		if (!res) {
@@ -164,11 +171,7 @@ struct platform_device *of_device_alloc(struct device_node *np,
 
 		dev->num_resources = num_reg + num_irq;
 		dev->resource = res;
-		for (i = 0; i < num_reg; i++, res++) {
-			rc = of_address_to_resource(np, i, res);
-			WARN_ON(rc);
-		}
-		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
+		/* See of_device_resource_populate for populating the data */
 	}
 
 	dev->dev.of_node = of_node_get(np);
@@ -187,6 +190,50 @@ struct platform_device *of_device_alloc(struct device_node *np,
 EXPORT_SYMBOL(of_device_alloc);
 
 /**
+ * of_device_resource_populate - Populate device resources from device tree
+ * @dev: pointer to platform device
+ *
+ * The device interrupts are not necessarily available for all
+ * irqdomains initially so we need to populate them lazily at
+ * device probe time from of_platform_populate.
+ */
+static int of_device_resource_populate(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	int rc, i, num_reg = 0, num_irq;
+	struct resource *res, temp_res;
+
+	res = pdev->resource;
+
+	/*
+	 * Count the io and irq resources again. Currently we cannot rely on
+	 * pdev->num_resources as bus specific code may have changed that
+	 * with platform_device_add_resources(). But the resources we allocated
+	 * earlier are still there and available for us to populate.
+	 */
+	if (of_can_translate_address(np))
+		while (of_address_to_resource(np, num_reg, &temp_res) == 0)
+			num_reg++;
+	num_irq = of_irq_count(np);
+
+	if (pdev->num_resources < num_reg + num_irq) {
+		dev_WARN(&pdev->dev, "not enough resources %i < %i\n",
+			 pdev->num_resources, num_reg + num_irq);
+		return -EINVAL;
+	}
+
+	for (i = 0; i < num_reg; i++, res++) {
+		rc = of_address_to_resource(np, i, res);
+		WARN_ON(rc);
+	}
+
+	if (num_irq)
+		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
+
+	return 0;
+}
+
+/**
  * of_platform_device_create_pdata - Alloc, initialize and register an of_device
  * @np: pointer to node to create device for
  * @bus_id: name to assign device
@@ -485,4 +532,35 @@ int of_platform_populate(struct device_node *root,
 	return rc;
 }
 EXPORT_SYMBOL_GPL(of_platform_populate);
+
+/**
+ * of_platform_probe() - OF specific initialization at probe time
+ * @pdev: pointer to a platform device
+ *
+ * This function is called by the driver core to perform devicetree-specific
+ * setup for a given platform device@probe time. If a device's resources
+ * as specified in the device tree are not available yet, this function can
+ * return -EPROBE_DEFER and cause the device to be probed again later, when
+ * other drivers that potentially provide the missing resources have been
+ * probed in turn.
+ *
+ * Note that because of the above, all code executed by this function must
+ * be prepared to be run multiple times on the same device (i.e. it must be
+ * idempotent).
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int of_platform_probe(struct platform_device *pdev)
+{
+	int ret;
+
+	if (!pdev->dev.of_node)
+		return 0;
+
+	ret = of_device_resource_populate(pdev);
+	if (ret < 0)
+		return ret;
+
+	return 0;
+}
 #endif /* CONFIG_OF_ADDRESS */
--- a/include/linux/of_platform.h
+++ b/include/linux/of_platform.h
@@ -72,6 +72,8 @@ extern int of_platform_populate(struct device_node *root,
 				const struct of_device_id *matches,
 				const struct of_dev_auxdata *lookup,
 				struct device *parent);
+
+extern int of_platform_probe(struct platform_device *pdev);
 #else
 static inline int of_platform_populate(struct device_node *root,
 					const struct of_device_id *matches,
@@ -80,6 +82,11 @@ static inline int of_platform_populate(struct device_node *root,
 {
 	return -ENODEV;
 }
+
+static inline int of_platform_probe(struct platform_device *pdev)
+{
+	return 0;
+}
 #endif
 
 #endif	/* _LINUX_OF_PLATFORM_H */

Re: [PATCH] driver-core: platform: Resolve DT interrupt references late

[Tony Lindgren]

* Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [140108 04:55]:
> When devices are probed from the device tree, any interrupts that they
> reference are resolved at device creation time. This causes problems if
> the interrupt provider hasn't been registered yet at that time, which
> results in the interrupt being set to 0.
> 
> This is especially bad for platform devices because they are created at
> a very early stage during boot when the majority of interrupt providers
> haven't had a chance to be probed yet. One of the platform where this
> causes major issues is OMAP.
> 
> Note that this patch is the easy way out to fix a large part of the
> problems for now. A more proper solution for the long term would be to
> transition drivers to an API that always resolves resources of any kind
> (not only interrupts) at probe time.
> 
> For some background and discussion on possible solutions, see:
> 
> 	https://lkml.org/lkml/2013/11/22/520
> 
> Acked-by: Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> Note that this is somewhat urgent and should if at all possible go into
> v3.13 before the release.
> 
>  drivers/base/platform.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 3a94b799f166..c894d1af3a5e 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -13,6 +13,7 @@
>  #include <linux/string.h>
>  #include <linux/platform_device.h>
>  #include <linux/of_device.h>
> +#include <linux/of_irq.h>
>  #include <linux/module.h>
>  #include <linux/init.h>
>  #include <linux/dma-mapping.h>
> @@ -87,7 +88,12 @@ int platform_get_irq(struct platform_device *dev, unsigned int num)
>  		return -ENXIO;
>  	return dev->archdata.irqs[num];
>  #else
> -	struct resource *r = platform_get_resource(dev, IORESOURCE_IRQ, num);
> +	struct resource *r;
> +
> +	if (IS_ENABLED(CONFIG_OF) && dev->dev.of_node)
> +		return irq_of_parse_and_map(dev->dev.of_node, num);
> +
> +	r = platform_get_resource(dev, IORESOURCE_IRQ, num);
>  
>  	return r ? r->start : -ENXIO;
>  #endif

Hmm actually testing this patch, it does not fix fix the $Subject bug :(

irq: no irq domain found for /ocp/pinmux@48002030 !
[    0.301361] ------------[ cut here ]------------
[    0.301391] WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
[    0.301422] Modules linked in:
[    0.301452] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc7-00002-g4d998a6 #17
[    0.301513] [<c0015c04>] (unwind_backtrace+0x0/0xf4) from [<c00127b0>] (show_stack+0x14/0x1c)
[    0.301544] [<c00127b0>] (show_stack+0x14/0x1c) from [<c05685a4>] (dump_stack+0x6c/0xa0)
[    0.301574] [<c05685a4>] (dump_stack+0x6c/0xa0) from [<c00425b4>] (warn_slowpath_common+0x64/0x84)
[    0.301605] [<c00425b4>] (warn_slowpath_common+0x64/0x84) from [<c00425f0>] (warn_slowpath_null+0x1c/0x24)
[    0.301635] [<c00425f0>] (warn_slowpath_null+0x1c/0x24) from [<c0485210>] (of_device_alloc+0x144/0x184)
[    0.301635] [<c0485210>] (of_device_alloc+0x144/0x184) from [<c0485294>] (of_platform_device_create_pdata+0x44/0x9c)
[    0.301666] [<c0485294>] (of_platform_device_create_pdata+0x44/0x9c) from [<c04853bc>] (of_platform_bus_create+0xd0/0x170)
[    0.301696] [<c04853bc>] (of_platform_bus_create+0xd0/0x170) from [<c0485418>] (of_platform_bus_create+0x12c/0x170)
[    0.301727] [<c0485418>] (of_platform_bus_create+0x12c/0x170) from [<c04854bc>] (of_platform_populate+0x60/0x98)
[    0.301757] [<c04854bc>] (of_platform_populate+0x60/0x98) from [<c07ca53c>] (pdata_quirks_init+0x28/0x78)
[    0.301788] [<c07ca53c>] (pdata_quirks_init+0x28/0x78) from [<c07bab20>] (customize_machine+0x20/0x48)
[    0.301818] [<c07bab20>] (customize_machine+0x20/0x48) from [<c000882c>] (do_one_initcall+0x2c/0x150)
[    0.301849] [<c000882c>] (do_one_initcall+0x2c/0x150) from [<c07b75d8>] (do_basic_setup+0x94/0xd4)
[    0.301879] [<c07b75d8>] (do_basic_setup+0x94/0xd4) from [<c07b7694>] (kernel_init_freeable+0x7c/0x120)
[    0.301910] [<c07b7694>] (kernel_init_freeable+0x7c/0x120) from [<c05667ec>] (kernel_init+0x8/0x120)
[    0.301940] [<c05667ec>] (kernel_init+0x8/0x120) from [<c000e908>] (ret_from_fork+0x14/0x2c)
[    0.302124] ---[ end trace 2b87f5de2f86f809 ]---
...

There's nothing wrong with the interrupt related code paths, we're just
trying to call the functions at a wrong time when thing are not yet
initialized.

Below is a repost of what works for me without using notifiers. Anybody
got any better ideas for a minimal fix?

Regards,

Tony

8< -------------------------------
From: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Date: Tue, 7 Jan 2014 17:07:18 -0800
Subject: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

Currently we get the following kind of errors if we try to use interrupt
phandles to irqchips that have not yet initialized:

irq: no irq domain found for /ocp/pinmux@48002030 !
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
(show_stack+0x14/0x1c)
(dump_stack+0x6c/0xa0)
(warn_slowpath_common+0x64/0x84)
(warn_slowpath_null+0x1c/0x24)
(of_device_alloc+0x144/0x184)
(of_platform_device_create_pdata+0x44/0x9c)
(of_platform_bus_create+0xd0/0x170)
(of_platform_bus_create+0x12c/0x170)
(of_platform_populate+0x60/0x98)

This is because we're wrongly trying to populate resources that are not yet
available. It's perfectly valid to create irqchips dynamically, so let's
fix up the issue by populating the interrupt resources at the driver probe
time instead.

Note that at least currently we cannot dynamically allocate the resources as bus
specific code may add legacy resources with platform_device_add_resources()
before the driver probe. At least omap_device_alloc() currently relies on
num_resources to determine if legacy resources should be added. This issue
will get fixed automatically when mach-omap2 boots with DT only, but there
are probably other places too where platform_device_add_resources() modifies
things before driver probe.

The addition of of_platform_probe() is based on patches posted earlier by
Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>.

Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>

--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -481,6 +481,10 @@ static int platform_drv_probe(struct device *_dev)
 	struct platform_device *dev = to_platform_device(_dev);
 	int ret;
 
+	ret = of_platform_probe(dev);
+	if (ret)
+		return ret;
+
 	if (ACPI_HANDLE(_dev))
 		acpi_dev_pm_attach(_dev, true);
 
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -141,7 +141,7 @@ struct platform_device *of_device_alloc(struct device_node *np,
 				  struct device *parent)
 {
 	struct platform_device *dev;
-	int rc, i, num_reg = 0, num_irq;
+	int num_reg = 0, num_irq;
 	struct resource *res, temp_res;
 
 	dev = platform_device_alloc("", -1);
@@ -154,7 +154,14 @@ struct platform_device *of_device_alloc(struct device_node *np,
 			num_reg++;
 	num_irq = of_irq_count(np);
 
-	/* Populate the resource table */
+	/*
+	 * Only allocate the resources for us to use later on. Note that bus
+	 * specific code may also add in additional legacy resources using
+	 * platform_device_add_resources(), and may even rely on us allocating
+	 * the basic resources here to do so. So we cannot allocate the
+	 * resources lazily until the legacy code has been fixed to not rely
+	 * on allocating resources here.
+	 */
 	if (num_irq || num_reg) {
 		res = kzalloc(sizeof(*res) * (num_irq + num_reg), GFP_KERNEL);
 		if (!res) {
@@ -164,11 +171,7 @@ struct platform_device *of_device_alloc(struct device_node *np,
 
 		dev->num_resources = num_reg + num_irq;
 		dev->resource = res;
-		for (i = 0; i < num_reg; i++, res++) {
-			rc = of_address_to_resource(np, i, res);
-			WARN_ON(rc);
-		}
-		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
+		/* See of_device_resource_populate for populating the data */
 	}
 
 	dev->dev.of_node = of_node_get(np);
@@ -187,6 +190,50 @@ struct platform_device *of_device_alloc(struct device_node *np,
 EXPORT_SYMBOL(of_device_alloc);
 
 /**
+ * of_device_resource_populate - Populate device resources from device tree
+ * @dev: pointer to platform device
+ *
+ * The device interrupts are not necessarily available for all
+ * irqdomains initially so we need to populate them lazily at
+ * device probe time from of_platform_populate.
+ */
+static int of_device_resource_populate(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	int rc, i, num_reg = 0, num_irq;
+	struct resource *res, temp_res;
+
+	res = pdev->resource;
+
+	/*
+	 * Count the io and irq resources again. Currently we cannot rely on
+	 * pdev->num_resources as bus specific code may have changed that
+	 * with platform_device_add_resources(). But the resources we allocated
+	 * earlier are still there and available for us to populate.
+	 */
+	if (of_can_translate_address(np))
+		while (of_address_to_resource(np, num_reg, &temp_res) == 0)
+			num_reg++;
+	num_irq = of_irq_count(np);
+
+	if (pdev->num_resources < num_reg + num_irq) {
+		dev_WARN(&pdev->dev, "not enough resources %i < %i\n",
+			 pdev->num_resources, num_reg + num_irq);
+		return -EINVAL;
+	}
+
+	for (i = 0; i < num_reg; i++, res++) {
+		rc = of_address_to_resource(np, i, res);
+		WARN_ON(rc);
+	}
+
+	if (num_irq)
+		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
+
+	return 0;
+}
+
+/**
  * of_platform_device_create_pdata - Alloc, initialize and register an of_device
  * @np: pointer to node to create device for
  * @bus_id: name to assign device
@@ -485,4 +532,35 @@ int of_platform_populate(struct device_node *root,
 	return rc;
 }
 EXPORT_SYMBOL_GPL(of_platform_populate);
+
+/**
+ * of_platform_probe() - OF specific initialization at probe time
+ * @pdev: pointer to a platform device
+ *
+ * This function is called by the driver core to perform devicetree-specific
+ * setup for a given platform device at probe time. If a device's resources
+ * as specified in the device tree are not available yet, this function can
+ * return -EPROBE_DEFER and cause the device to be probed again later, when
+ * other drivers that potentially provide the missing resources have been
+ * probed in turn.
+ *
+ * Note that because of the above, all code executed by this function must
+ * be prepared to be run multiple times on the same device (i.e. it must be
+ * idempotent).
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int of_platform_probe(struct platform_device *pdev)
+{
+	int ret;
+
+	if (!pdev->dev.of_node)
+		return 0;
+
+	ret = of_device_resource_populate(pdev);
+	if (ret < 0)
+		return ret;
+
+	return 0;
+}
 #endif /* CONFIG_OF_ADDRESS */
--- a/include/linux/of_platform.h
+++ b/include/linux/of_platform.h
@@ -72,6 +72,8 @@ extern int of_platform_populate(struct device_node *root,
 				const struct of_device_id *matches,
 				const struct of_dev_auxdata *lookup,
 				struct device *parent);
+
+extern int of_platform_probe(struct platform_device *pdev);
 #else
 static inline int of_platform_populate(struct device_node *root,
 					const struct of_device_id *matches,
@@ -80,6 +82,11 @@ static inline int of_platform_populate(struct device_node *root,
 {
 	return -ENODEV;
 }
+
+static inline int of_platform_probe(struct platform_device *pdev)
+{
+	return 0;
+}
 #endif
 
 #endif	/* _LINUX_OF_PLATFORM_H */
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] driver-core: platform: Resolve DT interrupt references late

[Thierry Reding]

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

On Wed, Jan 08, 2014 at 08:40:41AM -0800, Tony Lindgren wrote:
> * Thierry Reding <thierry.reding@gmail.com> [140108 04:55]:
> > When devices are probed from the device tree, any interrupts that they
> > reference are resolved at device creation time. This causes problems if
> > the interrupt provider hasn't been registered yet at that time, which
> > results in the interrupt being set to 0.
> > 
> > This is especially bad for platform devices because they are created at
> > a very early stage during boot when the majority of interrupt providers
> > haven't had a chance to be probed yet. One of the platform where this
> > causes major issues is OMAP.
> > 
> > Note that this patch is the easy way out to fix a large part of the
> > problems for now. A more proper solution for the long term would be to
> > transition drivers to an API that always resolves resources of any kind
> > (not only interrupts) at probe time.
> > 
> > For some background and discussion on possible solutions, see:
> > 
> > 	https://lkml.org/lkml/2013/11/22/520
> > 
> > Acked-by: Rob Herring <robherring2@gmail.com>
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> > Note that this is somewhat urgent and should if at all possible go into
> > v3.13 before the release.
> > 
> >  drivers/base/platform.c | 8 +++++++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> > index 3a94b799f166..c894d1af3a5e 100644
> > --- a/drivers/base/platform.c
> > +++ b/drivers/base/platform.c
> > @@ -13,6 +13,7 @@
> >  #include <linux/string.h>
> >  #include <linux/platform_device.h>
> >  #include <linux/of_device.h>
> > +#include <linux/of_irq.h>
> >  #include <linux/module.h>
> >  #include <linux/init.h>
> >  #include <linux/dma-mapping.h>
> > @@ -87,7 +88,12 @@ int platform_get_irq(struct platform_device *dev, unsigned int num)
> >  		return -ENXIO;
> >  	return dev->archdata.irqs[num];
> >  #else
> > -	struct resource *r = platform_get_resource(dev, IORESOURCE_IRQ, num);
> > +	struct resource *r;
> > +
> > +	if (IS_ENABLED(CONFIG_OF) && dev->dev.of_node)
> > +		return irq_of_parse_and_map(dev->dev.of_node, num);
> > +
> > +	r = platform_get_resource(dev, IORESOURCE_IRQ, num);
> >  
> >  	return r ? r->start : -ENXIO;
> >  #endif
> 
> Hmm actually testing this patch, it does not fix fix the $Subject bug :(
> 
> irq: no irq domain found for /ocp/pinmux@48002030 !
> [    0.301361] ------------[ cut here ]------------
> [    0.301391] WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
> [    0.301422] Modules linked in:
> [    0.301452] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc7-00002-g4d998a6 #17
> [    0.301513] [<c0015c04>] (unwind_backtrace+0x0/0xf4) from [<c00127b0>] (show_stack+0x14/0x1c)
> [    0.301544] [<c00127b0>] (show_stack+0x14/0x1c) from [<c05685a4>] (dump_stack+0x6c/0xa0)
> [    0.301574] [<c05685a4>] (dump_stack+0x6c/0xa0) from [<c00425b4>] (warn_slowpath_common+0x64/0x84)
> [    0.301605] [<c00425b4>] (warn_slowpath_common+0x64/0x84) from [<c00425f0>] (warn_slowpath_null+0x1c/0x24)
> [    0.301635] [<c00425f0>] (warn_slowpath_null+0x1c/0x24) from [<c0485210>] (of_device_alloc+0x144/0x184)
> [    0.301635] [<c0485210>] (of_device_alloc+0x144/0x184) from [<c0485294>] (of_platform_device_create_pdata+0x44/0x9c)
> [    0.301666] [<c0485294>] (of_platform_device_create_pdata+0x44/0x9c) from [<c04853bc>] (of_platform_bus_create+0xd0/0x170)
> [    0.301696] [<c04853bc>] (of_platform_bus_create+0xd0/0x170) from [<c0485418>] (of_platform_bus_create+0x12c/0x170)
> [    0.301727] [<c0485418>] (of_platform_bus_create+0x12c/0x170) from [<c04854bc>] (of_platform_populate+0x60/0x98)
> [    0.301757] [<c04854bc>] (of_platform_populate+0x60/0x98) from [<c07ca53c>] (pdata_quirks_init+0x28/0x78)
> [    0.301788] [<c07ca53c>] (pdata_quirks_init+0x28/0x78) from [<c07bab20>] (customize_machine+0x20/0x48)
> [    0.301818] [<c07bab20>] (customize_machine+0x20/0x48) from [<c000882c>] (do_one_initcall+0x2c/0x150)
> [    0.301849] [<c000882c>] (do_one_initcall+0x2c/0x150) from [<c07b75d8>] (do_basic_setup+0x94/0xd4)
> [    0.301879] [<c07b75d8>] (do_basic_setup+0x94/0xd4) from [<c07b7694>] (kernel_init_freeable+0x7c/0x120)
> [    0.301910] [<c07b7694>] (kernel_init_freeable+0x7c/0x120) from [<c05667ec>] (kernel_init+0x8/0x120)
> [    0.301940] [<c05667ec>] (kernel_init+0x8/0x120) from [<c000e908>] (ret_from_fork+0x14/0x2c)
> [    0.302124] ---[ end trace 2b87f5de2f86f809 ]---
> ...
> 
> There's nothing wrong with the interrupt related code paths, we're just
> trying to call the functions at a wrong time when thing are not yet
> initialized.

The patch won't get rid of that warning, but it should at least restore
things to a working state at runtime. At least for well-behaved drivers
that use platform_get_irq() rather than those that try to access the
resources directly.

> Below is a repost of what works for me without using notifiers. Anybody
> got any better ideas for a minimal fix?

That patch is somewhat big for something that should be a minimal fix.
Being the size that it is it might have undesired side-effects that may
not get noticed until it's way too late, so I'm hesitant to have
something like this merged at this point in the release cycle.

Thierry

> 8< -------------------------------
> From: Tony Lindgren <tony@atomide.com>
> Date: Tue, 7 Jan 2014 17:07:18 -0800
> Subject: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts
> 
> Currently we get the following kind of errors if we try to use interrupt
> phandles to irqchips that have not yet initialized:
> 
> irq: no irq domain found for /ocp/pinmux@48002030 !
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
> (show_stack+0x14/0x1c)
> (dump_stack+0x6c/0xa0)
> (warn_slowpath_common+0x64/0x84)
> (warn_slowpath_null+0x1c/0x24)
> (of_device_alloc+0x144/0x184)
> (of_platform_device_create_pdata+0x44/0x9c)
> (of_platform_bus_create+0xd0/0x170)
> (of_platform_bus_create+0x12c/0x170)
> (of_platform_populate+0x60/0x98)
> 
> This is because we're wrongly trying to populate resources that are not yet
> available. It's perfectly valid to create irqchips dynamically, so let's
> fix up the issue by populating the interrupt resources at the driver probe
> time instead.
> 
> Note that at least currently we cannot dynamically allocate the resources as bus
> specific code may add legacy resources with platform_device_add_resources()
> before the driver probe. At least omap_device_alloc() currently relies on
> num_resources to determine if legacy resources should be added. This issue
> will get fixed automatically when mach-omap2 boots with DT only, but there
> are probably other places too where platform_device_add_resources() modifies
> things before driver probe.
> 
> The addition of of_platform_probe() is based on patches posted earlier by
> Thierry Reding <thierry.reding@gmail.com>.
> 
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> 
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -481,6 +481,10 @@ static int platform_drv_probe(struct device *_dev)
>  	struct platform_device *dev = to_platform_device(_dev);
>  	int ret;
>  
> +	ret = of_platform_probe(dev);
> +	if (ret)
> +		return ret;
> +
>  	if (ACPI_HANDLE(_dev))
>  		acpi_dev_pm_attach(_dev, true);
>  
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -141,7 +141,7 @@ struct platform_device *of_device_alloc(struct device_node *np,
>  				  struct device *parent)
>  {
>  	struct platform_device *dev;
> -	int rc, i, num_reg = 0, num_irq;
> +	int num_reg = 0, num_irq;
>  	struct resource *res, temp_res;
>  
>  	dev = platform_device_alloc("", -1);
> @@ -154,7 +154,14 @@ struct platform_device *of_device_alloc(struct device_node *np,
>  			num_reg++;
>  	num_irq = of_irq_count(np);
>  
> -	/* Populate the resource table */
> +	/*
> +	 * Only allocate the resources for us to use later on. Note that bus
> +	 * specific code may also add in additional legacy resources using
> +	 * platform_device_add_resources(), and may even rely on us allocating
> +	 * the basic resources here to do so. So we cannot allocate the
> +	 * resources lazily until the legacy code has been fixed to not rely
> +	 * on allocating resources here.
> +	 */
>  	if (num_irq || num_reg) {
>  		res = kzalloc(sizeof(*res) * (num_irq + num_reg), GFP_KERNEL);
>  		if (!res) {
> @@ -164,11 +171,7 @@ struct platform_device *of_device_alloc(struct device_node *np,
>  
>  		dev->num_resources = num_reg + num_irq;
>  		dev->resource = res;
> -		for (i = 0; i < num_reg; i++, res++) {
> -			rc = of_address_to_resource(np, i, res);
> -			WARN_ON(rc);
> -		}
> -		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
> +		/* See of_device_resource_populate for populating the data */
>  	}
>  
>  	dev->dev.of_node = of_node_get(np);
> @@ -187,6 +190,50 @@ struct platform_device *of_device_alloc(struct device_node *np,
>  EXPORT_SYMBOL(of_device_alloc);
>  
>  /**
> + * of_device_resource_populate - Populate device resources from device tree
> + * @dev: pointer to platform device
> + *
> + * The device interrupts are not necessarily available for all
> + * irqdomains initially so we need to populate them lazily at
> + * device probe time from of_platform_populate.
> + */
> +static int of_device_resource_populate(struct platform_device *pdev)
> +{
> +	struct device_node *np = pdev->dev.of_node;
> +	int rc, i, num_reg = 0, num_irq;
> +	struct resource *res, temp_res;
> +
> +	res = pdev->resource;
> +
> +	/*
> +	 * Count the io and irq resources again. Currently we cannot rely on
> +	 * pdev->num_resources as bus specific code may have changed that
> +	 * with platform_device_add_resources(). But the resources we allocated
> +	 * earlier are still there and available for us to populate.
> +	 */
> +	if (of_can_translate_address(np))
> +		while (of_address_to_resource(np, num_reg, &temp_res) == 0)
> +			num_reg++;
> +	num_irq = of_irq_count(np);
> +
> +	if (pdev->num_resources < num_reg + num_irq) {
> +		dev_WARN(&pdev->dev, "not enough resources %i < %i\n",
> +			 pdev->num_resources, num_reg + num_irq);
> +		return -EINVAL;
> +	}
> +
> +	for (i = 0; i < num_reg; i++, res++) {
> +		rc = of_address_to_resource(np, i, res);
> +		WARN_ON(rc);
> +	}
> +
> +	if (num_irq)
> +		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
> +
> +	return 0;
> +}
> +
> +/**
>   * of_platform_device_create_pdata - Alloc, initialize and register an of_device
>   * @np: pointer to node to create device for
>   * @bus_id: name to assign device
> @@ -485,4 +532,35 @@ int of_platform_populate(struct device_node *root,
>  	return rc;
>  }
>  EXPORT_SYMBOL_GPL(of_platform_populate);
> +
> +/**
> + * of_platform_probe() - OF specific initialization at probe time
> + * @pdev: pointer to a platform device
> + *
> + * This function is called by the driver core to perform devicetree-specific
> + * setup for a given platform device at probe time. If a device's resources
> + * as specified in the device tree are not available yet, this function can
> + * return -EPROBE_DEFER and cause the device to be probed again later, when
> + * other drivers that potentially provide the missing resources have been
> + * probed in turn.
> + *
> + * Note that because of the above, all code executed by this function must
> + * be prepared to be run multiple times on the same device (i.e. it must be
> + * idempotent).
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int of_platform_probe(struct platform_device *pdev)
> +{
> +	int ret;
> +
> +	if (!pdev->dev.of_node)
> +		return 0;
> +
> +	ret = of_device_resource_populate(pdev);
> +	if (ret < 0)
> +		return ret;
> +
> +	return 0;
> +}
>  #endif /* CONFIG_OF_ADDRESS */
> --- a/include/linux/of_platform.h
> +++ b/include/linux/of_platform.h
> @@ -72,6 +72,8 @@ extern int of_platform_populate(struct device_node *root,
>  				const struct of_device_id *matches,
>  				const struct of_dev_auxdata *lookup,
>  				struct device *parent);
> +
> +extern int of_platform_probe(struct platform_device *pdev);
>  #else
>  static inline int of_platform_populate(struct device_node *root,
>  					const struct of_device_id *matches,
> @@ -80,6 +82,11 @@ static inline int of_platform_populate(struct device_node *root,
>  {
>  	return -ENODEV;
>  }
> +
> +static inline int of_platform_probe(struct platform_device *pdev)
> +{
> +	return 0;
> +}
>  #endif
>  
>  #endif	/* _LINUX_OF_PLATFORM_H */

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

[PATCH] driver-core: platform: Resolve DT interrupt references late

[Thierry Reding]

On Wed, Jan 08, 2014 at 08:40:41AM -0800, Tony Lindgren wrote:
> * Thierry Reding <thierry.reding@gmail.com> [140108 04:55]:
> > When devices are probed from the device tree, any interrupts that they
> > reference are resolved at device creation time. This causes problems if
> > the interrupt provider hasn't been registered yet at that time, which
> > results in the interrupt being set to 0.
> > 
> > This is especially bad for platform devices because they are created at
> > a very early stage during boot when the majority of interrupt providers
> > haven't had a chance to be probed yet. One of the platform where this
> > causes major issues is OMAP.
> > 
> > Note that this patch is the easy way out to fix a large part of the
> > problems for now. A more proper solution for the long term would be to
> > transition drivers to an API that always resolves resources of any kind
> > (not only interrupts) at probe time.
> > 
> > For some background and discussion on possible solutions, see:
> > 
> > 	https://lkml.org/lkml/2013/11/22/520
> > 
> > Acked-by: Rob Herring <robherring2@gmail.com>
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> > Note that this is somewhat urgent and should if at all possible go into
> > v3.13 before the release.
> > 
> >  drivers/base/platform.c | 8 +++++++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> > index 3a94b799f166..c894d1af3a5e 100644
> > --- a/drivers/base/platform.c
> > +++ b/drivers/base/platform.c
> > @@ -13,6 +13,7 @@
> >  #include <linux/string.h>
> >  #include <linux/platform_device.h>
> >  #include <linux/of_device.h>
> > +#include <linux/of_irq.h>
> >  #include <linux/module.h>
> >  #include <linux/init.h>
> >  #include <linux/dma-mapping.h>
> > @@ -87,7 +88,12 @@ int platform_get_irq(struct platform_device *dev, unsigned int num)
> >  		return -ENXIO;
> >  	return dev->archdata.irqs[num];
> >  #else
> > -	struct resource *r = platform_get_resource(dev, IORESOURCE_IRQ, num);
> > +	struct resource *r;
> > +
> > +	if (IS_ENABLED(CONFIG_OF) && dev->dev.of_node)
> > +		return irq_of_parse_and_map(dev->dev.of_node, num);
> > +
> > +	r = platform_get_resource(dev, IORESOURCE_IRQ, num);
> >  
> >  	return r ? r->start : -ENXIO;
> >  #endif
> 
> Hmm actually testing this patch, it does not fix fix the $Subject bug :(
> 
> irq: no irq domain found for /ocp/pinmux at 48002030 !
> [    0.301361] ------------[ cut here ]------------
> [    0.301391] WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
> [    0.301422] Modules linked in:
> [    0.301452] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc7-00002-g4d998a6 #17
> [    0.301513] [<c0015c04>] (unwind_backtrace+0x0/0xf4) from [<c00127b0>] (show_stack+0x14/0x1c)
> [    0.301544] [<c00127b0>] (show_stack+0x14/0x1c) from [<c05685a4>] (dump_stack+0x6c/0xa0)
> [    0.301574] [<c05685a4>] (dump_stack+0x6c/0xa0) from [<c00425b4>] (warn_slowpath_common+0x64/0x84)
> [    0.301605] [<c00425b4>] (warn_slowpath_common+0x64/0x84) from [<c00425f0>] (warn_slowpath_null+0x1c/0x24)
> [    0.301635] [<c00425f0>] (warn_slowpath_null+0x1c/0x24) from [<c0485210>] (of_device_alloc+0x144/0x184)
> [    0.301635] [<c0485210>] (of_device_alloc+0x144/0x184) from [<c0485294>] (of_platform_device_create_pdata+0x44/0x9c)
> [    0.301666] [<c0485294>] (of_platform_device_create_pdata+0x44/0x9c) from [<c04853bc>] (of_platform_bus_create+0xd0/0x170)
> [    0.301696] [<c04853bc>] (of_platform_bus_create+0xd0/0x170) from [<c0485418>] (of_platform_bus_create+0x12c/0x170)
> [    0.301727] [<c0485418>] (of_platform_bus_create+0x12c/0x170) from [<c04854bc>] (of_platform_populate+0x60/0x98)
> [    0.301757] [<c04854bc>] (of_platform_populate+0x60/0x98) from [<c07ca53c>] (pdata_quirks_init+0x28/0x78)
> [    0.301788] [<c07ca53c>] (pdata_quirks_init+0x28/0x78) from [<c07bab20>] (customize_machine+0x20/0x48)
> [    0.301818] [<c07bab20>] (customize_machine+0x20/0x48) from [<c000882c>] (do_one_initcall+0x2c/0x150)
> [    0.301849] [<c000882c>] (do_one_initcall+0x2c/0x150) from [<c07b75d8>] (do_basic_setup+0x94/0xd4)
> [    0.301879] [<c07b75d8>] (do_basic_setup+0x94/0xd4) from [<c07b7694>] (kernel_init_freeable+0x7c/0x120)
> [    0.301910] [<c07b7694>] (kernel_init_freeable+0x7c/0x120) from [<c05667ec>] (kernel_init+0x8/0x120)
> [    0.301940] [<c05667ec>] (kernel_init+0x8/0x120) from [<c000e908>] (ret_from_fork+0x14/0x2c)
> [    0.302124] ---[ end trace 2b87f5de2f86f809 ]---
> ...
> 
> There's nothing wrong with the interrupt related code paths, we're just
> trying to call the functions at a wrong time when thing are not yet
> initialized.

The patch won't get rid of that warning, but it should at least restore
things to a working state at runtime. At least for well-behaved drivers
that use platform_get_irq() rather than those that try to access the
resources directly.

> Below is a repost of what works for me without using notifiers. Anybody
> got any better ideas for a minimal fix?

That patch is somewhat big for something that should be a minimal fix.
Being the size that it is it might have undesired side-effects that may
not get noticed until it's way too late, so I'm hesitant to have
something like this merged at this point in the release cycle.

Thierry

> 8< -------------------------------
> From: Tony Lindgren <tony@atomide.com>
> Date: Tue, 7 Jan 2014 17:07:18 -0800
> Subject: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts
> 
> Currently we get the following kind of errors if we try to use interrupt
> phandles to irqchips that have not yet initialized:
> 
> irq: no irq domain found for /ocp/pinmux at 48002030 !
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
> (show_stack+0x14/0x1c)
> (dump_stack+0x6c/0xa0)
> (warn_slowpath_common+0x64/0x84)
> (warn_slowpath_null+0x1c/0x24)
> (of_device_alloc+0x144/0x184)
> (of_platform_device_create_pdata+0x44/0x9c)
> (of_platform_bus_create+0xd0/0x170)
> (of_platform_bus_create+0x12c/0x170)
> (of_platform_populate+0x60/0x98)
> 
> This is because we're wrongly trying to populate resources that are not yet
> available. It's perfectly valid to create irqchips dynamically, so let's
> fix up the issue by populating the interrupt resources at the driver probe
> time instead.
> 
> Note that at least currently we cannot dynamically allocate the resources as bus
> specific code may add legacy resources with platform_device_add_resources()
> before the driver probe. At least omap_device_alloc() currently relies on
> num_resources to determine if legacy resources should be added. This issue
> will get fixed automatically when mach-omap2 boots with DT only, but there
> are probably other places too where platform_device_add_resources() modifies
> things before driver probe.
> 
> The addition of of_platform_probe() is based on patches posted earlier by
> Thierry Reding <thierry.reding@gmail.com>.
> 
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> 
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -481,6 +481,10 @@ static int platform_drv_probe(struct device *_dev)
>  	struct platform_device *dev = to_platform_device(_dev);
>  	int ret;
>  
> +	ret = of_platform_probe(dev);
> +	if (ret)
> +		return ret;
> +
>  	if (ACPI_HANDLE(_dev))
>  		acpi_dev_pm_attach(_dev, true);
>  
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -141,7 +141,7 @@ struct platform_device *of_device_alloc(struct device_node *np,
>  				  struct device *parent)
>  {
>  	struct platform_device *dev;
> -	int rc, i, num_reg = 0, num_irq;
> +	int num_reg = 0, num_irq;
>  	struct resource *res, temp_res;
>  
>  	dev = platform_device_alloc("", -1);
> @@ -154,7 +154,14 @@ struct platform_device *of_device_alloc(struct device_node *np,
>  			num_reg++;
>  	num_irq = of_irq_count(np);
>  
> -	/* Populate the resource table */
> +	/*
> +	 * Only allocate the resources for us to use later on. Note that bus
> +	 * specific code may also add in additional legacy resources using
> +	 * platform_device_add_resources(), and may even rely on us allocating
> +	 * the basic resources here to do so. So we cannot allocate the
> +	 * resources lazily until the legacy code has been fixed to not rely
> +	 * on allocating resources here.
> +	 */
>  	if (num_irq || num_reg) {
>  		res = kzalloc(sizeof(*res) * (num_irq + num_reg), GFP_KERNEL);
>  		if (!res) {
> @@ -164,11 +171,7 @@ struct platform_device *of_device_alloc(struct device_node *np,
>  
>  		dev->num_resources = num_reg + num_irq;
>  		dev->resource = res;
> -		for (i = 0; i < num_reg; i++, res++) {
> -			rc = of_address_to_resource(np, i, res);
> -			WARN_ON(rc);
> -		}
> -		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
> +		/* See of_device_resource_populate for populating the data */
>  	}
>  
>  	dev->dev.of_node = of_node_get(np);
> @@ -187,6 +190,50 @@ struct platform_device *of_device_alloc(struct device_node *np,
>  EXPORT_SYMBOL(of_device_alloc);
>  
>  /**
> + * of_device_resource_populate - Populate device resources from device tree
> + * @dev: pointer to platform device
> + *
> + * The device interrupts are not necessarily available for all
> + * irqdomains initially so we need to populate them lazily at
> + * device probe time from of_platform_populate.
> + */
> +static int of_device_resource_populate(struct platform_device *pdev)
> +{
> +	struct device_node *np = pdev->dev.of_node;
> +	int rc, i, num_reg = 0, num_irq;
> +	struct resource *res, temp_res;
> +
> +	res = pdev->resource;
> +
> +	/*
> +	 * Count the io and irq resources again. Currently we cannot rely on
> +	 * pdev->num_resources as bus specific code may have changed that
> +	 * with platform_device_add_resources(). But the resources we allocated
> +	 * earlier are still there and available for us to populate.
> +	 */
> +	if (of_can_translate_address(np))
> +		while (of_address_to_resource(np, num_reg, &temp_res) == 0)
> +			num_reg++;
> +	num_irq = of_irq_count(np);
> +
> +	if (pdev->num_resources < num_reg + num_irq) {
> +		dev_WARN(&pdev->dev, "not enough resources %i < %i\n",
> +			 pdev->num_resources, num_reg + num_irq);
> +		return -EINVAL;
> +	}
> +
> +	for (i = 0; i < num_reg; i++, res++) {
> +		rc = of_address_to_resource(np, i, res);
> +		WARN_ON(rc);
> +	}
> +
> +	if (num_irq)
> +		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
> +
> +	return 0;
> +}
> +
> +/**
>   * of_platform_device_create_pdata - Alloc, initialize and register an of_device
>   * @np: pointer to node to create device for
>   * @bus_id: name to assign device
> @@ -485,4 +532,35 @@ int of_platform_populate(struct device_node *root,
>  	return rc;
>  }
>  EXPORT_SYMBOL_GPL(of_platform_populate);
> +
> +/**
> + * of_platform_probe() - OF specific initialization at probe time
> + * @pdev: pointer to a platform device
> + *
> + * This function is called by the driver core to perform devicetree-specific
> + * setup for a given platform device at probe time. If a device's resources
> + * as specified in the device tree are not available yet, this function can
> + * return -EPROBE_DEFER and cause the device to be probed again later, when
> + * other drivers that potentially provide the missing resources have been
> + * probed in turn.
> + *
> + * Note that because of the above, all code executed by this function must
> + * be prepared to be run multiple times on the same device (i.e. it must be
> + * idempotent).
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int of_platform_probe(struct platform_device *pdev)
> +{
> +	int ret;
> +
> +	if (!pdev->dev.of_node)
> +		return 0;
> +
> +	ret = of_device_resource_populate(pdev);
> +	if (ret < 0)
> +		return ret;
> +
> +	return 0;
> +}
>  #endif /* CONFIG_OF_ADDRESS */
> --- a/include/linux/of_platform.h
> +++ b/include/linux/of_platform.h
> @@ -72,6 +72,8 @@ extern int of_platform_populate(struct device_node *root,
>  				const struct of_device_id *matches,
>  				const struct of_dev_auxdata *lookup,
>  				struct device *parent);
> +
> +extern int of_platform_probe(struct platform_device *pdev);
>  #else
>  static inline int of_platform_populate(struct device_node *root,
>  					const struct of_device_id *matches,
> @@ -80,6 +82,11 @@ static inline int of_platform_populate(struct device_node *root,
>  {
>  	return -ENODEV;
>  }
> +
> +static inline int of_platform_probe(struct platform_device *pdev)
> +{
> +	return 0;
> +}
>  #endif
>  
>  #endif	/* _LINUX_OF_PLATFORM_H */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140108/37d11f14/attachment-0001.sig>

Re: [PATCH] driver-core: platform: Resolve DT interrupt references late

[Thierry Reding]

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

On Wed, Jan 08, 2014 at 08:40:41AM -0800, Tony Lindgren wrote:
> * Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [140108 04:55]:
> > When devices are probed from the device tree, any interrupts that they
> > reference are resolved at device creation time. This causes problems if
> > the interrupt provider hasn't been registered yet at that time, which
> > results in the interrupt being set to 0.
> > 
> > This is especially bad for platform devices because they are created at
> > a very early stage during boot when the majority of interrupt providers
> > haven't had a chance to be probed yet. One of the platform where this
> > causes major issues is OMAP.
> > 
> > Note that this patch is the easy way out to fix a large part of the
> > problems for now. A more proper solution for the long term would be to
> > transition drivers to an API that always resolves resources of any kind
> > (not only interrupts) at probe time.
> > 
> > For some background and discussion on possible solutions, see:
> > 
> > 	https://lkml.org/lkml/2013/11/22/520
> > 
> > Acked-by: Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > ---
> > Note that this is somewhat urgent and should if at all possible go into
> > v3.13 before the release.
> > 
> >  drivers/base/platform.c | 8 +++++++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> > index 3a94b799f166..c894d1af3a5e 100644
> > --- a/drivers/base/platform.c
> > +++ b/drivers/base/platform.c
> > @@ -13,6 +13,7 @@
> >  #include <linux/string.h>
> >  #include <linux/platform_device.h>
> >  #include <linux/of_device.h>
> > +#include <linux/of_irq.h>
> >  #include <linux/module.h>
> >  #include <linux/init.h>
> >  #include <linux/dma-mapping.h>
> > @@ -87,7 +88,12 @@ int platform_get_irq(struct platform_device *dev, unsigned int num)
> >  		return -ENXIO;
> >  	return dev->archdata.irqs[num];
> >  #else
> > -	struct resource *r = platform_get_resource(dev, IORESOURCE_IRQ, num);
> > +	struct resource *r;
> > +
> > +	if (IS_ENABLED(CONFIG_OF) && dev->dev.of_node)
> > +		return irq_of_parse_and_map(dev->dev.of_node, num);
> > +
> > +	r = platform_get_resource(dev, IORESOURCE_IRQ, num);
> >  
> >  	return r ? r->start : -ENXIO;
> >  #endif
> 
> Hmm actually testing this patch, it does not fix fix the $Subject bug :(
> 
> irq: no irq domain found for /ocp/pinmux@48002030 !
> [    0.301361] ------------[ cut here ]------------
> [    0.301391] WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
> [    0.301422] Modules linked in:
> [    0.301452] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc7-00002-g4d998a6 #17
> [    0.301513] [<c0015c04>] (unwind_backtrace+0x0/0xf4) from [<c00127b0>] (show_stack+0x14/0x1c)
> [    0.301544] [<c00127b0>] (show_stack+0x14/0x1c) from [<c05685a4>] (dump_stack+0x6c/0xa0)
> [    0.301574] [<c05685a4>] (dump_stack+0x6c/0xa0) from [<c00425b4>] (warn_slowpath_common+0x64/0x84)
> [    0.301605] [<c00425b4>] (warn_slowpath_common+0x64/0x84) from [<c00425f0>] (warn_slowpath_null+0x1c/0x24)
> [    0.301635] [<c00425f0>] (warn_slowpath_null+0x1c/0x24) from [<c0485210>] (of_device_alloc+0x144/0x184)
> [    0.301635] [<c0485210>] (of_device_alloc+0x144/0x184) from [<c0485294>] (of_platform_device_create_pdata+0x44/0x9c)
> [    0.301666] [<c0485294>] (of_platform_device_create_pdata+0x44/0x9c) from [<c04853bc>] (of_platform_bus_create+0xd0/0x170)
> [    0.301696] [<c04853bc>] (of_platform_bus_create+0xd0/0x170) from [<c0485418>] (of_platform_bus_create+0x12c/0x170)
> [    0.301727] [<c0485418>] (of_platform_bus_create+0x12c/0x170) from [<c04854bc>] (of_platform_populate+0x60/0x98)
> [    0.301757] [<c04854bc>] (of_platform_populate+0x60/0x98) from [<c07ca53c>] (pdata_quirks_init+0x28/0x78)
> [    0.301788] [<c07ca53c>] (pdata_quirks_init+0x28/0x78) from [<c07bab20>] (customize_machine+0x20/0x48)
> [    0.301818] [<c07bab20>] (customize_machine+0x20/0x48) from [<c000882c>] (do_one_initcall+0x2c/0x150)
> [    0.301849] [<c000882c>] (do_one_initcall+0x2c/0x150) from [<c07b75d8>] (do_basic_setup+0x94/0xd4)
> [    0.301879] [<c07b75d8>] (do_basic_setup+0x94/0xd4) from [<c07b7694>] (kernel_init_freeable+0x7c/0x120)
> [    0.301910] [<c07b7694>] (kernel_init_freeable+0x7c/0x120) from [<c05667ec>] (kernel_init+0x8/0x120)
> [    0.301940] [<c05667ec>] (kernel_init+0x8/0x120) from [<c000e908>] (ret_from_fork+0x14/0x2c)
> [    0.302124] ---[ end trace 2b87f5de2f86f809 ]---
> ...
> 
> There's nothing wrong with the interrupt related code paths, we're just
> trying to call the functions at a wrong time when thing are not yet
> initialized.

The patch won't get rid of that warning, but it should at least restore
things to a working state at runtime. At least for well-behaved drivers
that use platform_get_irq() rather than those that try to access the
resources directly.

> Below is a repost of what works for me without using notifiers. Anybody
> got any better ideas for a minimal fix?

That patch is somewhat big for something that should be a minimal fix.
Being the size that it is it might have undesired side-effects that may
not get noticed until it's way too late, so I'm hesitant to have
something like this merged at this point in the release cycle.

Thierry

> 8< -------------------------------
> From: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> Date: Tue, 7 Jan 2014 17:07:18 -0800
> Subject: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts
> 
> Currently we get the following kind of errors if we try to use interrupt
> phandles to irqchips that have not yet initialized:
> 
> irq: no irq domain found for /ocp/pinmux@48002030 !
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
> (show_stack+0x14/0x1c)
> (dump_stack+0x6c/0xa0)
> (warn_slowpath_common+0x64/0x84)
> (warn_slowpath_null+0x1c/0x24)
> (of_device_alloc+0x144/0x184)
> (of_platform_device_create_pdata+0x44/0x9c)
> (of_platform_bus_create+0xd0/0x170)
> (of_platform_bus_create+0x12c/0x170)
> (of_platform_populate+0x60/0x98)
> 
> This is because we're wrongly trying to populate resources that are not yet
> available. It's perfectly valid to create irqchips dynamically, so let's
> fix up the issue by populating the interrupt resources at the driver probe
> time instead.
> 
> Note that at least currently we cannot dynamically allocate the resources as bus
> specific code may add legacy resources with platform_device_add_resources()
> before the driver probe. At least omap_device_alloc() currently relies on
> num_resources to determine if legacy resources should be added. This issue
> will get fixed automatically when mach-omap2 boots with DT only, but there
> are probably other places too where platform_device_add_resources() modifies
> things before driver probe.
> 
> The addition of of_platform_probe() is based on patches posted earlier by
> Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>.
> 
> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> 
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -481,6 +481,10 @@ static int platform_drv_probe(struct device *_dev)
>  	struct platform_device *dev = to_platform_device(_dev);
>  	int ret;
>  
> +	ret = of_platform_probe(dev);
> +	if (ret)
> +		return ret;
> +
>  	if (ACPI_HANDLE(_dev))
>  		acpi_dev_pm_attach(_dev, true);
>  
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -141,7 +141,7 @@ struct platform_device *of_device_alloc(struct device_node *np,
>  				  struct device *parent)
>  {
>  	struct platform_device *dev;
> -	int rc, i, num_reg = 0, num_irq;
> +	int num_reg = 0, num_irq;
>  	struct resource *res, temp_res;
>  
>  	dev = platform_device_alloc("", -1);
> @@ -154,7 +154,14 @@ struct platform_device *of_device_alloc(struct device_node *np,
>  			num_reg++;
>  	num_irq = of_irq_count(np);
>  
> -	/* Populate the resource table */
> +	/*
> +	 * Only allocate the resources for us to use later on. Note that bus
> +	 * specific code may also add in additional legacy resources using
> +	 * platform_device_add_resources(), and may even rely on us allocating
> +	 * the basic resources here to do so. So we cannot allocate the
> +	 * resources lazily until the legacy code has been fixed to not rely
> +	 * on allocating resources here.
> +	 */
>  	if (num_irq || num_reg) {
>  		res = kzalloc(sizeof(*res) * (num_irq + num_reg), GFP_KERNEL);
>  		if (!res) {
> @@ -164,11 +171,7 @@ struct platform_device *of_device_alloc(struct device_node *np,
>  
>  		dev->num_resources = num_reg + num_irq;
>  		dev->resource = res;
> -		for (i = 0; i < num_reg; i++, res++) {
> -			rc = of_address_to_resource(np, i, res);
> -			WARN_ON(rc);
> -		}
> -		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
> +		/* See of_device_resource_populate for populating the data */
>  	}
>  
>  	dev->dev.of_node = of_node_get(np);
> @@ -187,6 +190,50 @@ struct platform_device *of_device_alloc(struct device_node *np,
>  EXPORT_SYMBOL(of_device_alloc);
>  
>  /**
> + * of_device_resource_populate - Populate device resources from device tree
> + * @dev: pointer to platform device
> + *
> + * The device interrupts are not necessarily available for all
> + * irqdomains initially so we need to populate them lazily at
> + * device probe time from of_platform_populate.
> + */
> +static int of_device_resource_populate(struct platform_device *pdev)
> +{
> +	struct device_node *np = pdev->dev.of_node;
> +	int rc, i, num_reg = 0, num_irq;
> +	struct resource *res, temp_res;
> +
> +	res = pdev->resource;
> +
> +	/*
> +	 * Count the io and irq resources again. Currently we cannot rely on
> +	 * pdev->num_resources as bus specific code may have changed that
> +	 * with platform_device_add_resources(). But the resources we allocated
> +	 * earlier are still there and available for us to populate.
> +	 */
> +	if (of_can_translate_address(np))
> +		while (of_address_to_resource(np, num_reg, &temp_res) == 0)
> +			num_reg++;
> +	num_irq = of_irq_count(np);
> +
> +	if (pdev->num_resources < num_reg + num_irq) {
> +		dev_WARN(&pdev->dev, "not enough resources %i < %i\n",
> +			 pdev->num_resources, num_reg + num_irq);
> +		return -EINVAL;
> +	}
> +
> +	for (i = 0; i < num_reg; i++, res++) {
> +		rc = of_address_to_resource(np, i, res);
> +		WARN_ON(rc);
> +	}
> +
> +	if (num_irq)
> +		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
> +
> +	return 0;
> +}
> +
> +/**
>   * of_platform_device_create_pdata - Alloc, initialize and register an of_device
>   * @np: pointer to node to create device for
>   * @bus_id: name to assign device
> @@ -485,4 +532,35 @@ int of_platform_populate(struct device_node *root,
>  	return rc;
>  }
>  EXPORT_SYMBOL_GPL(of_platform_populate);
> +
> +/**
> + * of_platform_probe() - OF specific initialization at probe time
> + * @pdev: pointer to a platform device
> + *
> + * This function is called by the driver core to perform devicetree-specific
> + * setup for a given platform device at probe time. If a device's resources
> + * as specified in the device tree are not available yet, this function can
> + * return -EPROBE_DEFER and cause the device to be probed again later, when
> + * other drivers that potentially provide the missing resources have been
> + * probed in turn.
> + *
> + * Note that because of the above, all code executed by this function must
> + * be prepared to be run multiple times on the same device (i.e. it must be
> + * idempotent).
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int of_platform_probe(struct platform_device *pdev)
> +{
> +	int ret;
> +
> +	if (!pdev->dev.of_node)
> +		return 0;
> +
> +	ret = of_device_resource_populate(pdev);
> +	if (ret < 0)
> +		return ret;
> +
> +	return 0;
> +}
>  #endif /* CONFIG_OF_ADDRESS */
> --- a/include/linux/of_platform.h
> +++ b/include/linux/of_platform.h
> @@ -72,6 +72,8 @@ extern int of_platform_populate(struct device_node *root,
>  				const struct of_device_id *matches,
>  				const struct of_dev_auxdata *lookup,
>  				struct device *parent);
> +
> +extern int of_platform_probe(struct platform_device *pdev);
>  #else
>  static inline int of_platform_populate(struct device_node *root,
>  					const struct of_device_id *matches,
> @@ -80,6 +82,11 @@ static inline int of_platform_populate(struct device_node *root,
>  {
>  	return -ENODEV;
>  }
> +
> +static inline int of_platform_probe(struct platform_device *pdev)
> +{
> +	return 0;
> +}
>  #endif
>  
>  #endif	/* _LINUX_OF_PLATFORM_H */

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] driver-core: platform: Resolve DT interrupt references late

[Tony Lindgren]

* Thierry Reding <thierry.reding@gmail.com> [140108 11:32]:
> On Wed, Jan 08, 2014 at 08:40:41AM -0800, Tony Lindgren wrote:
> > 
> > There's nothing wrong with the interrupt related code paths, we're just
> > trying to call the functions at a wrong time when thing are not yet
> > initialized.
> 
> The patch won't get rid of that warning, but it should at least restore
> things to a working state at runtime. At least for well-behaved drivers
> that use platform_get_irq() rather than those that try to access the
> resources directly.

Well the problem I'm seeing is these nasty warnings.

BTW, I think the issue you're talking about regarding platform_get_irq()
got fixed by 4a43d686fe33 (of/irq: Pass trigger type in IRQ resource flags).
 
> > Below is a repost of what works for me without using notifiers. Anybody
> > got any better ideas for a minimal fix?
> 
> That patch is somewhat big for something that should be a minimal fix.
> Being the size that it is it might have undesired side-effects that may
> not get noticed until it's way too late, so I'm hesitant to have
> something like this merged at this point in the release cycle.

Yes I agree it's rather invasive, but we also do have things pretty
badly broken in the kernel for device tree based booting. And it seems
that nobody has a smaller patch that would fix it.

Regards,

Tony

[PATCH] driver-core: platform: Resolve DT interrupt references late

[Tony Lindgren]

* Thierry Reding <thierry.reding@gmail.com> [140108 11:32]:
> On Wed, Jan 08, 2014 at 08:40:41AM -0800, Tony Lindgren wrote:
> > 
> > There's nothing wrong with the interrupt related code paths, we're just
> > trying to call the functions at a wrong time when thing are not yet
> > initialized.
> 
> The patch won't get rid of that warning, but it should at least restore
> things to a working state at runtime. At least for well-behaved drivers
> that use platform_get_irq() rather than those that try to access the
> resources directly.

Well the problem I'm seeing is these nasty warnings.

BTW, I think the issue you're talking about regarding platform_get_irq()
got fixed by 4a43d686fe33 (of/irq: Pass trigger type in IRQ resource flags).
 
> > Below is a repost of what works for me without using notifiers. Anybody
> > got any better ideas for a minimal fix?
> 
> That patch is somewhat big for something that should be a minimal fix.
> Being the size that it is it might have undesired side-effects that may
> not get noticed until it's way too late, so I'm hesitant to have
> something like this merged at this point in the release cycle.

Yes I agree it's rather invasive, but we also do have things pretty
badly broken in the kernel for device tree based booting. And it seems
that nobody has a smaller patch that would fix it.

Regards,

Tony

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [131122 16:44]:
> @@ -168,7 +218,13 @@ struct platform_device *of_device_alloc(struct device_node *np,
>  			rc = of_address_to_resource(np, i, res);
>  			WARN_ON(rc);
>  		}
> -		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
> +
> +		/* See of_device_resource_notify for populating interrupts */
> +		for (i = 0; i < num_irq; i++, res++) {
> +			res->flags = IORESOURCE_IRQ;
> +			res->start = -EPROBE_DEFER;
> +			res->end = -EPROBE_DEFER;
> +		}

Hmm actually we want to use some other value here as res->start
is not an int. Maybe some kind of hwirq_max + EPROBE_DEFER.

Tony

[PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [131122 16:44]:
> @@ -168,7 +218,13 @@ struct platform_device *of_device_alloc(struct device_node *np,
>  			rc = of_address_to_resource(np, i, res);
>  			WARN_ON(rc);
>  		}
> -		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
> +
> +		/* See of_device_resource_notify for populating interrupts */
> +		for (i = 0; i < num_irq; i++, res++) {
> +			res->flags = IORESOURCE_IRQ;
> +			res->start = -EPROBE_DEFER;
> +			res->end = -EPROBE_DEFER;
> +		}

Hmm actually we want to use some other value here as res->start
is not an int. Maybe some kind of hwirq_max + EPROBE_DEFER.

Tony

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Tony Lindgren]

* Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [131122 16:44]:
> @@ -168,7 +218,13 @@ struct platform_device *of_device_alloc(struct device_node *np,
>  			rc = of_address_to_resource(np, i, res);
>  			WARN_ON(rc);
>  		}
> -		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
> +
> +		/* See of_device_resource_notify for populating interrupts */
> +		for (i = 0; i < num_irq; i++, res++) {
> +			res->flags = IORESOURCE_IRQ;
> +			res->start = -EPROBE_DEFER;
> +			res->end = -EPROBE_DEFER;
> +		}

Hmm actually we want to use some other value here as res->start
is not an int. Maybe some kind of hwirq_max + EPROBE_DEFER.

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Grant Likely]

On Fri, 22 Nov 2013 16:43:35 -0800, Tony Lindgren <tony@atomide.com> wrote:
> Currently we get the following kind of errors if we try to use
> interrupt phandles to irqchips that have not yet initialized:
> 
> irq: no irq domain found for /ocp/pinmux@48002030 !
> WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
> (show_stack+0x14/0x1c)
> (dump_stack+0x6c/0xa0)
> (warn_slowpath_common+0x64/0x84)
> (warn_slowpath_null+0x1c/0x24)
> (of_device_alloc+0x144/0x184)
> (of_platform_device_create_pdata+0x44/0x9c)
> (of_platform_bus_create+0xd0/0x170)
> (of_platform_bus_create+0x12c/0x170)
> (of_platform_populate+0x60/0x98)
> ...
> 
> This is because we're wrongly trying to populate resources that are not
> yet available. It's perfectly valid to create irqchips dynamically,
> so let's fix up the issue by populating the interrupt resources based
> on a notifier call instead.
> 
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> 
> ---
> 
> Rob & Grant, care to merge this for the -rc if this looks OK to you?
> 
> These happen for example when using interrupts-extended for omap
> wake-up interrupts where the irq domain is created by pinctrl-single.c
> at module_init time.
> 
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -130,6 +130,56 @@ void of_device_make_bus_id(struct device *dev)
>  	dev_set_name(dev, "%s.%d", node->name, magic - 1);
>  }
>  
> +/*
> + * The device interrupts are not necessarily available for all
> + * irqdomains initially so we need to populate them using a
> + * notifier.
> + */
> +static int of_device_resource_notify(struct notifier_block *nb,
> +				     unsigned long event, void *dev)
> +{
> +	struct platform_device *pdev = to_platform_device(dev);
> +	struct device_node *np = pdev->dev.of_node;
> +	struct resource *res = pdev->resource;
> +	struct resource *irqr = NULL;
> +	int num_irq, i, found = 0;
> +
> +	if (event != BUS_NOTIFY_BIND_DRIVER)
> +		return 0;
> +
> +	if (!np)
> +		goto out;
> +
> +	num_irq = of_irq_count(np);
> +	if (!num_irq)
> +		goto out;
> +
> +	for (i = 0; i < pdev->num_resources; i++, res++) {
> +		if (res->flags != IORESOURCE_IRQ ||
> +		    res->start != -EPROBE_DEFER ||
> +		    res->end != -EPROBE_DEFER)
> +			continue;
> +
> +		if (!irqr)
> +			irqr = res;
> +		found++;
> +	}
> +
> +	if (!found)
> +		goto out;
> +
> +	if (found != num_irq) {
> +		dev_WARN(dev, "error populating irq resources: %i != %i\n",
> +			 found, num_irq);
> +		goto out;
> +	}
> +
> +	WARN_ON(of_irq_to_resource_table(np, irqr, num_irq) != num_irq);
> +
> +out:
> +	return NOTIFY_DONE;
> +}
> +
>  /**
>   * of_device_alloc - Allocate and initialize an of_device
>   * @np: device node to assign to device
> @@ -168,7 +218,13 @@ struct platform_device *of_device_alloc(struct device_node *np,
>  			rc = of_address_to_resource(np, i, res);
>  			WARN_ON(rc);
>  		}
> -		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
> +
> +		/* See of_device_resource_notify for populating interrupts */
> +		for (i = 0; i < num_irq; i++, res++) {
> +			res->flags = IORESOURCE_IRQ;
> +			res->start = -EPROBE_DEFER;
> +			res->end = -EPROBE_DEFER;
> +		}

I actually like the idea of completely allocating the resource structure
but leaving some entries empty. However, I agree with rmk that putting
garbage into a resource structure is a bad idea. What about changing the
value of flags to 0 or some other value to be obviously an empty
property and give the follow up parsing some context about which ones it
needs to attempt to recalculate?

However, I still don't like the notifier approach of actually triggering
the fixup. We need something better.

g.

[PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Grant Likely]

On Fri, 22 Nov 2013 16:43:35 -0800, Tony Lindgren <tony@atomide.com> wrote:
> Currently we get the following kind of errors if we try to use
> interrupt phandles to irqchips that have not yet initialized:
> 
> irq: no irq domain found for /ocp/pinmux at 48002030 !
> WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
> (show_stack+0x14/0x1c)
> (dump_stack+0x6c/0xa0)
> (warn_slowpath_common+0x64/0x84)
> (warn_slowpath_null+0x1c/0x24)
> (of_device_alloc+0x144/0x184)
> (of_platform_device_create_pdata+0x44/0x9c)
> (of_platform_bus_create+0xd0/0x170)
> (of_platform_bus_create+0x12c/0x170)
> (of_platform_populate+0x60/0x98)
> ...
> 
> This is because we're wrongly trying to populate resources that are not
> yet available. It's perfectly valid to create irqchips dynamically,
> so let's fix up the issue by populating the interrupt resources based
> on a notifier call instead.
> 
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> 
> ---
> 
> Rob & Grant, care to merge this for the -rc if this looks OK to you?
> 
> These happen for example when using interrupts-extended for omap
> wake-up interrupts where the irq domain is created by pinctrl-single.c
> at module_init time.
> 
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -130,6 +130,56 @@ void of_device_make_bus_id(struct device *dev)
>  	dev_set_name(dev, "%s.%d", node->name, magic - 1);
>  }
>  
> +/*
> + * The device interrupts are not necessarily available for all
> + * irqdomains initially so we need to populate them using a
> + * notifier.
> + */
> +static int of_device_resource_notify(struct notifier_block *nb,
> +				     unsigned long event, void *dev)
> +{
> +	struct platform_device *pdev = to_platform_device(dev);
> +	struct device_node *np = pdev->dev.of_node;
> +	struct resource *res = pdev->resource;
> +	struct resource *irqr = NULL;
> +	int num_irq, i, found = 0;
> +
> +	if (event != BUS_NOTIFY_BIND_DRIVER)
> +		return 0;
> +
> +	if (!np)
> +		goto out;
> +
> +	num_irq = of_irq_count(np);
> +	if (!num_irq)
> +		goto out;
> +
> +	for (i = 0; i < pdev->num_resources; i++, res++) {
> +		if (res->flags != IORESOURCE_IRQ ||
> +		    res->start != -EPROBE_DEFER ||
> +		    res->end != -EPROBE_DEFER)
> +			continue;
> +
> +		if (!irqr)
> +			irqr = res;
> +		found++;
> +	}
> +
> +	if (!found)
> +		goto out;
> +
> +	if (found != num_irq) {
> +		dev_WARN(dev, "error populating irq resources: %i != %i\n",
> +			 found, num_irq);
> +		goto out;
> +	}
> +
> +	WARN_ON(of_irq_to_resource_table(np, irqr, num_irq) != num_irq);
> +
> +out:
> +	return NOTIFY_DONE;
> +}
> +
>  /**
>   * of_device_alloc - Allocate and initialize an of_device
>   * @np: device node to assign to device
> @@ -168,7 +218,13 @@ struct platform_device *of_device_alloc(struct device_node *np,
>  			rc = of_address_to_resource(np, i, res);
>  			WARN_ON(rc);
>  		}
> -		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
> +
> +		/* See of_device_resource_notify for populating interrupts */
> +		for (i = 0; i < num_irq; i++, res++) {
> +			res->flags = IORESOURCE_IRQ;
> +			res->start = -EPROBE_DEFER;
> +			res->end = -EPROBE_DEFER;
> +		}

I actually like the idea of completely allocating the resource structure
but leaving some entries empty. However, I agree with rmk that putting
garbage into a resource structure is a bad idea. What about changing the
value of flags to 0 or some other value to be obviously an empty
property and give the follow up parsing some context about which ones it
needs to attempt to recalculate?

However, I still don't like the notifier approach of actually triggering
the fixup. We need something better.

g.

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Grant Likely]

On Fri, 22 Nov 2013 16:43:35 -0800, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> Currently we get the following kind of errors if we try to use
> interrupt phandles to irqchips that have not yet initialized:
> 
> irq: no irq domain found for /ocp/pinmux@48002030 !
> WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
> (show_stack+0x14/0x1c)
> (dump_stack+0x6c/0xa0)
> (warn_slowpath_common+0x64/0x84)
> (warn_slowpath_null+0x1c/0x24)
> (of_device_alloc+0x144/0x184)
> (of_platform_device_create_pdata+0x44/0x9c)
> (of_platform_bus_create+0xd0/0x170)
> (of_platform_bus_create+0x12c/0x170)
> (of_platform_populate+0x60/0x98)
> ...
> 
> This is because we're wrongly trying to populate resources that are not
> yet available. It's perfectly valid to create irqchips dynamically,
> so let's fix up the issue by populating the interrupt resources based
> on a notifier call instead.
> 
> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> 
> ---
> 
> Rob & Grant, care to merge this for the -rc if this looks OK to you?
> 
> These happen for example when using interrupts-extended for omap
> wake-up interrupts where the irq domain is created by pinctrl-single.c
> at module_init time.
> 
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -130,6 +130,56 @@ void of_device_make_bus_id(struct device *dev)
>  	dev_set_name(dev, "%s.%d", node->name, magic - 1);
>  }
>  
> +/*
> + * The device interrupts are not necessarily available for all
> + * irqdomains initially so we need to populate them using a
> + * notifier.
> + */
> +static int of_device_resource_notify(struct notifier_block *nb,
> +				     unsigned long event, void *dev)
> +{
> +	struct platform_device *pdev = to_platform_device(dev);
> +	struct device_node *np = pdev->dev.of_node;
> +	struct resource *res = pdev->resource;
> +	struct resource *irqr = NULL;
> +	int num_irq, i, found = 0;
> +
> +	if (event != BUS_NOTIFY_BIND_DRIVER)
> +		return 0;
> +
> +	if (!np)
> +		goto out;
> +
> +	num_irq = of_irq_count(np);
> +	if (!num_irq)
> +		goto out;
> +
> +	for (i = 0; i < pdev->num_resources; i++, res++) {
> +		if (res->flags != IORESOURCE_IRQ ||
> +		    res->start != -EPROBE_DEFER ||
> +		    res->end != -EPROBE_DEFER)
> +			continue;
> +
> +		if (!irqr)
> +			irqr = res;
> +		found++;
> +	}
> +
> +	if (!found)
> +		goto out;
> +
> +	if (found != num_irq) {
> +		dev_WARN(dev, "error populating irq resources: %i != %i\n",
> +			 found, num_irq);
> +		goto out;
> +	}
> +
> +	WARN_ON(of_irq_to_resource_table(np, irqr, num_irq) != num_irq);
> +
> +out:
> +	return NOTIFY_DONE;
> +}
> +
>  /**
>   * of_device_alloc - Allocate and initialize an of_device
>   * @np: device node to assign to device
> @@ -168,7 +218,13 @@ struct platform_device *of_device_alloc(struct device_node *np,
>  			rc = of_address_to_resource(np, i, res);
>  			WARN_ON(rc);
>  		}
> -		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
> +
> +		/* See of_device_resource_notify for populating interrupts */
> +		for (i = 0; i < num_irq; i++, res++) {
> +			res->flags = IORESOURCE_IRQ;
> +			res->start = -EPROBE_DEFER;
> +			res->end = -EPROBE_DEFER;
> +		}

I actually like the idea of completely allocating the resource structure
but leaving some entries empty. However, I agree with rmk that putting
garbage into a resource structure is a bad idea. What about changing the
value of flags to 0 or some other value to be obviously an empty
property and give the follow up parsing some context about which ones it
needs to attempt to recalculate?

However, I still don't like the notifier approach of actually triggering
the fixup. We need something better.

g.

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Thierry Reding]

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

On Sun, Nov 24, 2013 at 09:36:51PM +0000, Grant Likely wrote:
> On Fri, 22 Nov 2013 16:43:35 -0800, Tony Lindgren <tony@atomide.com> wrote:
> > Currently we get the following kind of errors if we try to use
> > interrupt phandles to irqchips that have not yet initialized:
> > 
> > irq: no irq domain found for /ocp/pinmux@48002030 !
> > WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
> > Modules linked in:
> > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
> > (show_stack+0x14/0x1c)
> > (dump_stack+0x6c/0xa0)
> > (warn_slowpath_common+0x64/0x84)
> > (warn_slowpath_null+0x1c/0x24)
> > (of_device_alloc+0x144/0x184)
> > (of_platform_device_create_pdata+0x44/0x9c)
> > (of_platform_bus_create+0xd0/0x170)
> > (of_platform_bus_create+0x12c/0x170)
> > (of_platform_populate+0x60/0x98)
> > ...
> > 
> > This is because we're wrongly trying to populate resources that are not
> > yet available. It's perfectly valid to create irqchips dynamically,
> > so let's fix up the issue by populating the interrupt resources based
> > on a notifier call instead.
> > 
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > 
> > ---
> > 
> > Rob & Grant, care to merge this for the -rc if this looks OK to you?
> > 
> > These happen for example when using interrupts-extended for omap
> > wake-up interrupts where the irq domain is created by pinctrl-single.c
> > at module_init time.
> > 
> > --- a/drivers/of/platform.c
> > +++ b/drivers/of/platform.c
> > @@ -130,6 +130,56 @@ void of_device_make_bus_id(struct device *dev)
> >  	dev_set_name(dev, "%s.%d", node->name, magic - 1);
> >  }
> >  
> > +/*
> > + * The device interrupts are not necessarily available for all
> > + * irqdomains initially so we need to populate them using a
> > + * notifier.
> > + */
> > +static int of_device_resource_notify(struct notifier_block *nb,
> > +				     unsigned long event, void *dev)
> > +{
> > +	struct platform_device *pdev = to_platform_device(dev);
> > +	struct device_node *np = pdev->dev.of_node;
> > +	struct resource *res = pdev->resource;
> > +	struct resource *irqr = NULL;
> > +	int num_irq, i, found = 0;
> > +
> > +	if (event != BUS_NOTIFY_BIND_DRIVER)
> > +		return 0;
> > +
> > +	if (!np)
> > +		goto out;
> > +
> > +	num_irq = of_irq_count(np);
> > +	if (!num_irq)
> > +		goto out;
> > +
> > +	for (i = 0; i < pdev->num_resources; i++, res++) {
> > +		if (res->flags != IORESOURCE_IRQ ||
> > +		    res->start != -EPROBE_DEFER ||
> > +		    res->end != -EPROBE_DEFER)
> > +			continue;
> > +
> > +		if (!irqr)
> > +			irqr = res;
> > +		found++;
> > +	}
> > +
> > +	if (!found)
> > +		goto out;
> > +
> > +	if (found != num_irq) {
> > +		dev_WARN(dev, "error populating irq resources: %i != %i\n",
> > +			 found, num_irq);
> > +		goto out;
> > +	}
> > +
> > +	WARN_ON(of_irq_to_resource_table(np, irqr, num_irq) != num_irq);
> > +
> > +out:
> > +	return NOTIFY_DONE;
> > +}
> > +
> >  /**
> >   * of_device_alloc - Allocate and initialize an of_device
> >   * @np: device node to assign to device
> > @@ -168,7 +218,13 @@ struct platform_device *of_device_alloc(struct device_node *np,
> >  			rc = of_address_to_resource(np, i, res);
> >  			WARN_ON(rc);
> >  		}
> > -		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
> > +
> > +		/* See of_device_resource_notify for populating interrupts */
> > +		for (i = 0; i < num_irq; i++, res++) {
> > +			res->flags = IORESOURCE_IRQ;
> > +			res->start = -EPROBE_DEFER;
> > +			res->end = -EPROBE_DEFER;
> > +		}
> 
> I actually like the idea of completely allocating the resource structure
> but leaving some entries empty. However, I agree with rmk that putting
> garbage into a resource structure is a bad idea. What about changing the
> value of flags to 0 or some other value to be obviously an empty
> property and give the follow up parsing some context about which ones it
> needs to attempt to recalculate?

When I worked on this a while back I came to the same conclusion. It's
nice to allocate all the resources at once, because the number of them
doesn't change, only their actually values.

However it seems to me like there's no way with the way platform_device
is currently defined to pass along enough context to allow it to obtain
the correct set of resources that need to be populated.

We can't really set flags to 0 because then we loose all information
about the type of resource, which is the only thing that could remotely
be used to track interrupt-type resources and recalculate only those. I
was looking at perhaps modifying the platform_device struct to use a
different means of storing the resources that would make this easier.
One possibility would be to add per-type arrays or lists of resources.
That way we could simply remove the complete list of interrupts and redo
them each time probing is deferred.

However it looks like a whole lot of code currently relies on knowing
the internals of struct platform_device, so that will likely turn into a
nightmare patchset. coccinelle could possibly be very helpful here,
though.

Perhaps a backwards-compatible way would be to add some fields that keep
track of where in the single array of struct resource:s the interrupts
start and then overwrite the values, while at the same time not having
to reallocate memory all the time. It's slightly hackish and I fear if
we don't clean up after that we'll run the risk of cluttering up the
structure eventually.

I'm wondering if long term (well, really long-term) it might be better
to move away from platform_device completely, given how various people
have said that they don't like them and rather have them not exist at
all. I haven't quite seen anyone explicitly stating why or what an
alternative would look like, but perhaps someone can educate me.

> However, I still don't like the notifier approach of actually triggering
> the fixup. We need something better.

I don't either. Notifiers are really not suitable for this in my
opinion. We've had this discussion before in the context of Hiroshi's
IOMMU patches, and they don't allow errors to be propagated easily. They
also are a very decentralized way to do things and therefore better
suited to do things that are really driver-specific. For something that
every device requires (such as interrupt reference resolution), a change
to the core seems like a more desirable approach to me.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

[PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Thierry Reding]

On Sun, Nov 24, 2013 at 09:36:51PM +0000, Grant Likely wrote:
> On Fri, 22 Nov 2013 16:43:35 -0800, Tony Lindgren <tony@atomide.com> wrote:
> > Currently we get the following kind of errors if we try to use
> > interrupt phandles to irqchips that have not yet initialized:
> > 
> > irq: no irq domain found for /ocp/pinmux at 48002030 !
> > WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
> > Modules linked in:
> > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
> > (show_stack+0x14/0x1c)
> > (dump_stack+0x6c/0xa0)
> > (warn_slowpath_common+0x64/0x84)
> > (warn_slowpath_null+0x1c/0x24)
> > (of_device_alloc+0x144/0x184)
> > (of_platform_device_create_pdata+0x44/0x9c)
> > (of_platform_bus_create+0xd0/0x170)
> > (of_platform_bus_create+0x12c/0x170)
> > (of_platform_populate+0x60/0x98)
> > ...
> > 
> > This is because we're wrongly trying to populate resources that are not
> > yet available. It's perfectly valid to create irqchips dynamically,
> > so let's fix up the issue by populating the interrupt resources based
> > on a notifier call instead.
> > 
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > 
> > ---
> > 
> > Rob & Grant, care to merge this for the -rc if this looks OK to you?
> > 
> > These happen for example when using interrupts-extended for omap
> > wake-up interrupts where the irq domain is created by pinctrl-single.c
> > at module_init time.
> > 
> > --- a/drivers/of/platform.c
> > +++ b/drivers/of/platform.c
> > @@ -130,6 +130,56 @@ void of_device_make_bus_id(struct device *dev)
> >  	dev_set_name(dev, "%s.%d", node->name, magic - 1);
> >  }
> >  
> > +/*
> > + * The device interrupts are not necessarily available for all
> > + * irqdomains initially so we need to populate them using a
> > + * notifier.
> > + */
> > +static int of_device_resource_notify(struct notifier_block *nb,
> > +				     unsigned long event, void *dev)
> > +{
> > +	struct platform_device *pdev = to_platform_device(dev);
> > +	struct device_node *np = pdev->dev.of_node;
> > +	struct resource *res = pdev->resource;
> > +	struct resource *irqr = NULL;
> > +	int num_irq, i, found = 0;
> > +
> > +	if (event != BUS_NOTIFY_BIND_DRIVER)
> > +		return 0;
> > +
> > +	if (!np)
> > +		goto out;
> > +
> > +	num_irq = of_irq_count(np);
> > +	if (!num_irq)
> > +		goto out;
> > +
> > +	for (i = 0; i < pdev->num_resources; i++, res++) {
> > +		if (res->flags != IORESOURCE_IRQ ||
> > +		    res->start != -EPROBE_DEFER ||
> > +		    res->end != -EPROBE_DEFER)
> > +			continue;
> > +
> > +		if (!irqr)
> > +			irqr = res;
> > +		found++;
> > +	}
> > +
> > +	if (!found)
> > +		goto out;
> > +
> > +	if (found != num_irq) {
> > +		dev_WARN(dev, "error populating irq resources: %i != %i\n",
> > +			 found, num_irq);
> > +		goto out;
> > +	}
> > +
> > +	WARN_ON(of_irq_to_resource_table(np, irqr, num_irq) != num_irq);
> > +
> > +out:
> > +	return NOTIFY_DONE;
> > +}
> > +
> >  /**
> >   * of_device_alloc - Allocate and initialize an of_device
> >   * @np: device node to assign to device
> > @@ -168,7 +218,13 @@ struct platform_device *of_device_alloc(struct device_node *np,
> >  			rc = of_address_to_resource(np, i, res);
> >  			WARN_ON(rc);
> >  		}
> > -		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
> > +
> > +		/* See of_device_resource_notify for populating interrupts */
> > +		for (i = 0; i < num_irq; i++, res++) {
> > +			res->flags = IORESOURCE_IRQ;
> > +			res->start = -EPROBE_DEFER;
> > +			res->end = -EPROBE_DEFER;
> > +		}
> 
> I actually like the idea of completely allocating the resource structure
> but leaving some entries empty. However, I agree with rmk that putting
> garbage into a resource structure is a bad idea. What about changing the
> value of flags to 0 or some other value to be obviously an empty
> property and give the follow up parsing some context about which ones it
> needs to attempt to recalculate?

When I worked on this a while back I came to the same conclusion. It's
nice to allocate all the resources at once, because the number of them
doesn't change, only their actually values.

However it seems to me like there's no way with the way platform_device
is currently defined to pass along enough context to allow it to obtain
the correct set of resources that need to be populated.

We can't really set flags to 0 because then we loose all information
about the type of resource, which is the only thing that could remotely
be used to track interrupt-type resources and recalculate only those. I
was looking at perhaps modifying the platform_device struct to use a
different means of storing the resources that would make this easier.
One possibility would be to add per-type arrays or lists of resources.
That way we could simply remove the complete list of interrupts and redo
them each time probing is deferred.

However it looks like a whole lot of code currently relies on knowing
the internals of struct platform_device, so that will likely turn into a
nightmare patchset. coccinelle could possibly be very helpful here,
though.

Perhaps a backwards-compatible way would be to add some fields that keep
track of where in the single array of struct resource:s the interrupts
start and then overwrite the values, while at the same time not having
to reallocate memory all the time. It's slightly hackish and I fear if
we don't clean up after that we'll run the risk of cluttering up the
structure eventually.

I'm wondering if long term (well, really long-term) it might be better
to move away from platform_device completely, given how various people
have said that they don't like them and rather have them not exist at
all. I haven't quite seen anyone explicitly stating why or what an
alternative would look like, but perhaps someone can educate me.

> However, I still don't like the notifier approach of actually triggering
> the fixup. We need something better.

I don't either. Notifiers are really not suitable for this in my
opinion. We've had this discussion before in the context of Hiroshi's
IOMMU patches, and they don't allow errors to be propagated easily. They
also are a very decentralized way to do things and therefore better
suited to do things that are really driver-specific. For something that
every device requires (such as interrupt reference resolution), a change
to the core seems like a more desirable approach to me.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131125/71c1f060/attachment-0001.sig>

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Thierry Reding]

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

On Sun, Nov 24, 2013 at 09:36:51PM +0000, Grant Likely wrote:
> On Fri, 22 Nov 2013 16:43:35 -0800, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> > Currently we get the following kind of errors if we try to use
> > interrupt phandles to irqchips that have not yet initialized:
> > 
> > irq: no irq domain found for /ocp/pinmux@48002030 !
> > WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
> > Modules linked in:
> > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
> > (show_stack+0x14/0x1c)
> > (dump_stack+0x6c/0xa0)
> > (warn_slowpath_common+0x64/0x84)
> > (warn_slowpath_null+0x1c/0x24)
> > (of_device_alloc+0x144/0x184)
> > (of_platform_device_create_pdata+0x44/0x9c)
> > (of_platform_bus_create+0xd0/0x170)
> > (of_platform_bus_create+0x12c/0x170)
> > (of_platform_populate+0x60/0x98)
> > ...
> > 
> > This is because we're wrongly trying to populate resources that are not
> > yet available. It's perfectly valid to create irqchips dynamically,
> > so let's fix up the issue by populating the interrupt resources based
> > on a notifier call instead.
> > 
> > Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> > 
> > ---
> > 
> > Rob & Grant, care to merge this for the -rc if this looks OK to you?
> > 
> > These happen for example when using interrupts-extended for omap
> > wake-up interrupts where the irq domain is created by pinctrl-single.c
> > at module_init time.
> > 
> > --- a/drivers/of/platform.c
> > +++ b/drivers/of/platform.c
> > @@ -130,6 +130,56 @@ void of_device_make_bus_id(struct device *dev)
> >  	dev_set_name(dev, "%s.%d", node->name, magic - 1);
> >  }
> >  
> > +/*
> > + * The device interrupts are not necessarily available for all
> > + * irqdomains initially so we need to populate them using a
> > + * notifier.
> > + */
> > +static int of_device_resource_notify(struct notifier_block *nb,
> > +				     unsigned long event, void *dev)
> > +{
> > +	struct platform_device *pdev = to_platform_device(dev);
> > +	struct device_node *np = pdev->dev.of_node;
> > +	struct resource *res = pdev->resource;
> > +	struct resource *irqr = NULL;
> > +	int num_irq, i, found = 0;
> > +
> > +	if (event != BUS_NOTIFY_BIND_DRIVER)
> > +		return 0;
> > +
> > +	if (!np)
> > +		goto out;
> > +
> > +	num_irq = of_irq_count(np);
> > +	if (!num_irq)
> > +		goto out;
> > +
> > +	for (i = 0; i < pdev->num_resources; i++, res++) {
> > +		if (res->flags != IORESOURCE_IRQ ||
> > +		    res->start != -EPROBE_DEFER ||
> > +		    res->end != -EPROBE_DEFER)
> > +			continue;
> > +
> > +		if (!irqr)
> > +			irqr = res;
> > +		found++;
> > +	}
> > +
> > +	if (!found)
> > +		goto out;
> > +
> > +	if (found != num_irq) {
> > +		dev_WARN(dev, "error populating irq resources: %i != %i\n",
> > +			 found, num_irq);
> > +		goto out;
> > +	}
> > +
> > +	WARN_ON(of_irq_to_resource_table(np, irqr, num_irq) != num_irq);
> > +
> > +out:
> > +	return NOTIFY_DONE;
> > +}
> > +
> >  /**
> >   * of_device_alloc - Allocate and initialize an of_device
> >   * @np: device node to assign to device
> > @@ -168,7 +218,13 @@ struct platform_device *of_device_alloc(struct device_node *np,
> >  			rc = of_address_to_resource(np, i, res);
> >  			WARN_ON(rc);
> >  		}
> > -		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
> > +
> > +		/* See of_device_resource_notify for populating interrupts */
> > +		for (i = 0; i < num_irq; i++, res++) {
> > +			res->flags = IORESOURCE_IRQ;
> > +			res->start = -EPROBE_DEFER;
> > +			res->end = -EPROBE_DEFER;
> > +		}
> 
> I actually like the idea of completely allocating the resource structure
> but leaving some entries empty. However, I agree with rmk that putting
> garbage into a resource structure is a bad idea. What about changing the
> value of flags to 0 or some other value to be obviously an empty
> property and give the follow up parsing some context about which ones it
> needs to attempt to recalculate?

When I worked on this a while back I came to the same conclusion. It's
nice to allocate all the resources at once, because the number of them
doesn't change, only their actually values.

However it seems to me like there's no way with the way platform_device
is currently defined to pass along enough context to allow it to obtain
the correct set of resources that need to be populated.

We can't really set flags to 0 because then we loose all information
about the type of resource, which is the only thing that could remotely
be used to track interrupt-type resources and recalculate only those. I
was looking at perhaps modifying the platform_device struct to use a
different means of storing the resources that would make this easier.
One possibility would be to add per-type arrays or lists of resources.
That way we could simply remove the complete list of interrupts and redo
them each time probing is deferred.

However it looks like a whole lot of code currently relies on knowing
the internals of struct platform_device, so that will likely turn into a
nightmare patchset. coccinelle could possibly be very helpful here,
though.

Perhaps a backwards-compatible way would be to add some fields that keep
track of where in the single array of struct resource:s the interrupts
start and then overwrite the values, while at the same time not having
to reallocate memory all the time. It's slightly hackish and I fear if
we don't clean up after that we'll run the risk of cluttering up the
structure eventually.

I'm wondering if long term (well, really long-term) it might be better
to move away from platform_device completely, given how various people
have said that they don't like them and rather have them not exist at
all. I haven't quite seen anyone explicitly stating why or what an
alternative would look like, but perhaps someone can educate me.

> However, I still don't like the notifier approach of actually triggering
> the fixup. We need something better.

I don't either. Notifiers are really not suitable for this in my
opinion. We've had this discussion before in the context of Hiroshi's
IOMMU patches, and they don't allow errors to be propagated easily. They
also are a very decentralized way to do things and therefore better
suited to do things that are really driver-specific. For something that
every device requires (such as interrupt reference resolution), a change
to the core seems like a more desirable approach to me.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Thierry Reding]

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

On Mon, Nov 25, 2013 at 10:25:50AM +0100, Thierry Reding wrote:
> On Sun, Nov 24, 2013 at 09:36:51PM +0000, Grant Likely wrote:
> > On Fri, 22 Nov 2013 16:43:35 -0800, Tony Lindgren <tony@atomide.com> wrote:
> > > Currently we get the following kind of errors if we try to use
> > > interrupt phandles to irqchips that have not yet initialized:
> > > 
> > > irq: no irq domain found for /ocp/pinmux@48002030 !
> > > WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
> > > Modules linked in:
> > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
> > > (show_stack+0x14/0x1c)
> > > (dump_stack+0x6c/0xa0)
> > > (warn_slowpath_common+0x64/0x84)
> > > (warn_slowpath_null+0x1c/0x24)
> > > (of_device_alloc+0x144/0x184)
> > > (of_platform_device_create_pdata+0x44/0x9c)
> > > (of_platform_bus_create+0xd0/0x170)
> > > (of_platform_bus_create+0x12c/0x170)
> > > (of_platform_populate+0x60/0x98)
> > > ...
> > > 
> > > This is because we're wrongly trying to populate resources that are not
> > > yet available. It's perfectly valid to create irqchips dynamically,
> > > so let's fix up the issue by populating the interrupt resources based
> > > on a notifier call instead.
> > > 
> > > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > > 
> > > ---
> > > 
> > > Rob & Grant, care to merge this for the -rc if this looks OK to you?
> > > 
> > > These happen for example when using interrupts-extended for omap
> > > wake-up interrupts where the irq domain is created by pinctrl-single.c
> > > at module_init time.
> > > 
> > > --- a/drivers/of/platform.c
> > > +++ b/drivers/of/platform.c
> > > @@ -130,6 +130,56 @@ void of_device_make_bus_id(struct device *dev)
> > >  	dev_set_name(dev, "%s.%d", node->name, magic - 1);
> > >  }
> > >  
> > > +/*
> > > + * The device interrupts are not necessarily available for all
> > > + * irqdomains initially so we need to populate them using a
> > > + * notifier.
> > > + */
> > > +static int of_device_resource_notify(struct notifier_block *nb,
> > > +				     unsigned long event, void *dev)
> > > +{
> > > +	struct platform_device *pdev = to_platform_device(dev);
> > > +	struct device_node *np = pdev->dev.of_node;
> > > +	struct resource *res = pdev->resource;
> > > +	struct resource *irqr = NULL;
> > > +	int num_irq, i, found = 0;
> > > +
> > > +	if (event != BUS_NOTIFY_BIND_DRIVER)
> > > +		return 0;
> > > +
> > > +	if (!np)
> > > +		goto out;
> > > +
> > > +	num_irq = of_irq_count(np);
> > > +	if (!num_irq)
> > > +		goto out;
> > > +
> > > +	for (i = 0; i < pdev->num_resources; i++, res++) {
> > > +		if (res->flags != IORESOURCE_IRQ ||
> > > +		    res->start != -EPROBE_DEFER ||
> > > +		    res->end != -EPROBE_DEFER)
> > > +			continue;
> > > +
> > > +		if (!irqr)
> > > +			irqr = res;
> > > +		found++;
> > > +	}
> > > +
> > > +	if (!found)
> > > +		goto out;
> > > +
> > > +	if (found != num_irq) {
> > > +		dev_WARN(dev, "error populating irq resources: %i != %i\n",
> > > +			 found, num_irq);
> > > +		goto out;
> > > +	}
> > > +
> > > +	WARN_ON(of_irq_to_resource_table(np, irqr, num_irq) != num_irq);
> > > +
> > > +out:
> > > +	return NOTIFY_DONE;
> > > +}
> > > +
> > >  /**
> > >   * of_device_alloc - Allocate and initialize an of_device
> > >   * @np: device node to assign to device
> > > @@ -168,7 +218,13 @@ struct platform_device *of_device_alloc(struct device_node *np,
> > >  			rc = of_address_to_resource(np, i, res);
> > >  			WARN_ON(rc);
> > >  		}
> > > -		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
> > > +
> > > +		/* See of_device_resource_notify for populating interrupts */
> > > +		for (i = 0; i < num_irq; i++, res++) {
> > > +			res->flags = IORESOURCE_IRQ;
> > > +			res->start = -EPROBE_DEFER;
> > > +			res->end = -EPROBE_DEFER;
> > > +		}
> > 
> > I actually like the idea of completely allocating the resource structure
> > but leaving some entries empty. However, I agree with rmk that putting
> > garbage into a resource structure is a bad idea. What about changing the
> > value of flags to 0 or some other value to be obviously an empty
> > property and give the follow up parsing some context about which ones it
> > needs to attempt to recalculate?
> 
> When I worked on this a while back I came to the same conclusion. It's
> nice to allocate all the resources at once, because the number of them
> doesn't change, only their actually values.

I should maybe add: one issue that was raised during review of my
initial patch series was that we'll also need to cope with situations
like the following:

	1) device's interrupt parent is probed (assigned IRQ base X)
	2) device is probed (interrupt parent there, therefore gets
	   assigned IRQ (X + z)
	3) device in removed
	4) device's interrupt parent is removed
	5) device is probed (deferred because interrupt parent isn't
	   there)
	6) device's interrupt parent is probed (assigned IRQ base Y)
	7) device is probed, gets assigned IRQ (Y + z)

So not only do we have to track which resources are interrupt resources,
but we also need to have them reassigned everytime the device is probed,
therefore interrupt mappings need to be properly disposed and the values
invalidated when probing is deferred or the device removed.

Having a dynamic list of properties all of a sudden doesn't sound like
such a bad idea after all. It makes handling this kind of situation
rather trivial, especially per-type lists. Those lists will be empty at
first and populated during the first probe. When probing fails or when a
device is unloaded, we dispose the mappings and empty the lists, so that
subsequent probes will start from scratch. It certainly sounds like a
bit of a waste of CPU cycles, but on the other hand it makes the code
much simpler.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

[PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Thierry Reding]

On Mon, Nov 25, 2013 at 10:25:50AM +0100, Thierry Reding wrote:
> On Sun, Nov 24, 2013 at 09:36:51PM +0000, Grant Likely wrote:
> > On Fri, 22 Nov 2013 16:43:35 -0800, Tony Lindgren <tony@atomide.com> wrote:
> > > Currently we get the following kind of errors if we try to use
> > > interrupt phandles to irqchips that have not yet initialized:
> > > 
> > > irq: no irq domain found for /ocp/pinmux at 48002030 !
> > > WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
> > > Modules linked in:
> > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
> > > (show_stack+0x14/0x1c)
> > > (dump_stack+0x6c/0xa0)
> > > (warn_slowpath_common+0x64/0x84)
> > > (warn_slowpath_null+0x1c/0x24)
> > > (of_device_alloc+0x144/0x184)
> > > (of_platform_device_create_pdata+0x44/0x9c)
> > > (of_platform_bus_create+0xd0/0x170)
> > > (of_platform_bus_create+0x12c/0x170)
> > > (of_platform_populate+0x60/0x98)
> > > ...
> > > 
> > > This is because we're wrongly trying to populate resources that are not
> > > yet available. It's perfectly valid to create irqchips dynamically,
> > > so let's fix up the issue by populating the interrupt resources based
> > > on a notifier call instead.
> > > 
> > > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > > 
> > > ---
> > > 
> > > Rob & Grant, care to merge this for the -rc if this looks OK to you?
> > > 
> > > These happen for example when using interrupts-extended for omap
> > > wake-up interrupts where the irq domain is created by pinctrl-single.c
> > > at module_init time.
> > > 
> > > --- a/drivers/of/platform.c
> > > +++ b/drivers/of/platform.c
> > > @@ -130,6 +130,56 @@ void of_device_make_bus_id(struct device *dev)
> > >  	dev_set_name(dev, "%s.%d", node->name, magic - 1);
> > >  }
> > >  
> > > +/*
> > > + * The device interrupts are not necessarily available for all
> > > + * irqdomains initially so we need to populate them using a
> > > + * notifier.
> > > + */
> > > +static int of_device_resource_notify(struct notifier_block *nb,
> > > +				     unsigned long event, void *dev)
> > > +{
> > > +	struct platform_device *pdev = to_platform_device(dev);
> > > +	struct device_node *np = pdev->dev.of_node;
> > > +	struct resource *res = pdev->resource;
> > > +	struct resource *irqr = NULL;
> > > +	int num_irq, i, found = 0;
> > > +
> > > +	if (event != BUS_NOTIFY_BIND_DRIVER)
> > > +		return 0;
> > > +
> > > +	if (!np)
> > > +		goto out;
> > > +
> > > +	num_irq = of_irq_count(np);
> > > +	if (!num_irq)
> > > +		goto out;
> > > +
> > > +	for (i = 0; i < pdev->num_resources; i++, res++) {
> > > +		if (res->flags != IORESOURCE_IRQ ||
> > > +		    res->start != -EPROBE_DEFER ||
> > > +		    res->end != -EPROBE_DEFER)
> > > +			continue;
> > > +
> > > +		if (!irqr)
> > > +			irqr = res;
> > > +		found++;
> > > +	}
> > > +
> > > +	if (!found)
> > > +		goto out;
> > > +
> > > +	if (found != num_irq) {
> > > +		dev_WARN(dev, "error populating irq resources: %i != %i\n",
> > > +			 found, num_irq);
> > > +		goto out;
> > > +	}
> > > +
> > > +	WARN_ON(of_irq_to_resource_table(np, irqr, num_irq) != num_irq);
> > > +
> > > +out:
> > > +	return NOTIFY_DONE;
> > > +}
> > > +
> > >  /**
> > >   * of_device_alloc - Allocate and initialize an of_device
> > >   * @np: device node to assign to device
> > > @@ -168,7 +218,13 @@ struct platform_device *of_device_alloc(struct device_node *np,
> > >  			rc = of_address_to_resource(np, i, res);
> > >  			WARN_ON(rc);
> > >  		}
> > > -		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
> > > +
> > > +		/* See of_device_resource_notify for populating interrupts */
> > > +		for (i = 0; i < num_irq; i++, res++) {
> > > +			res->flags = IORESOURCE_IRQ;
> > > +			res->start = -EPROBE_DEFER;
> > > +			res->end = -EPROBE_DEFER;
> > > +		}
> > 
> > I actually like the idea of completely allocating the resource structure
> > but leaving some entries empty. However, I agree with rmk that putting
> > garbage into a resource structure is a bad idea. What about changing the
> > value of flags to 0 or some other value to be obviously an empty
> > property and give the follow up parsing some context about which ones it
> > needs to attempt to recalculate?
> 
> When I worked on this a while back I came to the same conclusion. It's
> nice to allocate all the resources at once, because the number of them
> doesn't change, only their actually values.

I should maybe add: one issue that was raised during review of my
initial patch series was that we'll also need to cope with situations
like the following:

	1) device's interrupt parent is probed (assigned IRQ base X)
	2) device is probed (interrupt parent there, therefore gets
	   assigned IRQ (X + z)
	3) device in removed
	4) device's interrupt parent is removed
	5) device is probed (deferred because interrupt parent isn't
	   there)
	6) device's interrupt parent is probed (assigned IRQ base Y)
	7) device is probed, gets assigned IRQ (Y + z)

So not only do we have to track which resources are interrupt resources,
but we also need to have them reassigned everytime the device is probed,
therefore interrupt mappings need to be properly disposed and the values
invalidated when probing is deferred or the device removed.

Having a dynamic list of properties all of a sudden doesn't sound like
such a bad idea after all. It makes handling this kind of situation
rather trivial, especially per-type lists. Those lists will be empty at
first and populated during the first probe. When probing fails or when a
device is unloaded, we dispose the mappings and empty the lists, so that
subsequent probes will start from scratch. It certainly sounds like a
bit of a waste of CPU cycles, but on the other hand it makes the code
much simpler.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131125/baafc0a7/attachment.sig>

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Thierry Reding]

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

On Mon, Nov 25, 2013 at 10:25:50AM +0100, Thierry Reding wrote:
> On Sun, Nov 24, 2013 at 09:36:51PM +0000, Grant Likely wrote:
> > On Fri, 22 Nov 2013 16:43:35 -0800, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> > > Currently we get the following kind of errors if we try to use
> > > interrupt phandles to irqchips that have not yet initialized:
> > > 
> > > irq: no irq domain found for /ocp/pinmux@48002030 !
> > > WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
> > > Modules linked in:
> > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
> > > (show_stack+0x14/0x1c)
> > > (dump_stack+0x6c/0xa0)
> > > (warn_slowpath_common+0x64/0x84)
> > > (warn_slowpath_null+0x1c/0x24)
> > > (of_device_alloc+0x144/0x184)
> > > (of_platform_device_create_pdata+0x44/0x9c)
> > > (of_platform_bus_create+0xd0/0x170)
> > > (of_platform_bus_create+0x12c/0x170)
> > > (of_platform_populate+0x60/0x98)
> > > ...
> > > 
> > > This is because we're wrongly trying to populate resources that are not
> > > yet available. It's perfectly valid to create irqchips dynamically,
> > > so let's fix up the issue by populating the interrupt resources based
> > > on a notifier call instead.
> > > 
> > > Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> > > 
> > > ---
> > > 
> > > Rob & Grant, care to merge this for the -rc if this looks OK to you?
> > > 
> > > These happen for example when using interrupts-extended for omap
> > > wake-up interrupts where the irq domain is created by pinctrl-single.c
> > > at module_init time.
> > > 
> > > --- a/drivers/of/platform.c
> > > +++ b/drivers/of/platform.c
> > > @@ -130,6 +130,56 @@ void of_device_make_bus_id(struct device *dev)
> > >  	dev_set_name(dev, "%s.%d", node->name, magic - 1);
> > >  }
> > >  
> > > +/*
> > > + * The device interrupts are not necessarily available for all
> > > + * irqdomains initially so we need to populate them using a
> > > + * notifier.
> > > + */
> > > +static int of_device_resource_notify(struct notifier_block *nb,
> > > +				     unsigned long event, void *dev)
> > > +{
> > > +	struct platform_device *pdev = to_platform_device(dev);
> > > +	struct device_node *np = pdev->dev.of_node;
> > > +	struct resource *res = pdev->resource;
> > > +	struct resource *irqr = NULL;
> > > +	int num_irq, i, found = 0;
> > > +
> > > +	if (event != BUS_NOTIFY_BIND_DRIVER)
> > > +		return 0;
> > > +
> > > +	if (!np)
> > > +		goto out;
> > > +
> > > +	num_irq = of_irq_count(np);
> > > +	if (!num_irq)
> > > +		goto out;
> > > +
> > > +	for (i = 0; i < pdev->num_resources; i++, res++) {
> > > +		if (res->flags != IORESOURCE_IRQ ||
> > > +		    res->start != -EPROBE_DEFER ||
> > > +		    res->end != -EPROBE_DEFER)
> > > +			continue;
> > > +
> > > +		if (!irqr)
> > > +			irqr = res;
> > > +		found++;
> > > +	}
> > > +
> > > +	if (!found)
> > > +		goto out;
> > > +
> > > +	if (found != num_irq) {
> > > +		dev_WARN(dev, "error populating irq resources: %i != %i\n",
> > > +			 found, num_irq);
> > > +		goto out;
> > > +	}
> > > +
> > > +	WARN_ON(of_irq_to_resource_table(np, irqr, num_irq) != num_irq);
> > > +
> > > +out:
> > > +	return NOTIFY_DONE;
> > > +}
> > > +
> > >  /**
> > >   * of_device_alloc - Allocate and initialize an of_device
> > >   * @np: device node to assign to device
> > > @@ -168,7 +218,13 @@ struct platform_device *of_device_alloc(struct device_node *np,
> > >  			rc = of_address_to_resource(np, i, res);
> > >  			WARN_ON(rc);
> > >  		}
> > > -		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
> > > +
> > > +		/* See of_device_resource_notify for populating interrupts */
> > > +		for (i = 0; i < num_irq; i++, res++) {
> > > +			res->flags = IORESOURCE_IRQ;
> > > +			res->start = -EPROBE_DEFER;
> > > +			res->end = -EPROBE_DEFER;
> > > +		}
> > 
> > I actually like the idea of completely allocating the resource structure
> > but leaving some entries empty. However, I agree with rmk that putting
> > garbage into a resource structure is a bad idea. What about changing the
> > value of flags to 0 or some other value to be obviously an empty
> > property and give the follow up parsing some context about which ones it
> > needs to attempt to recalculate?
> 
> When I worked on this a while back I came to the same conclusion. It's
> nice to allocate all the resources at once, because the number of them
> doesn't change, only their actually values.

I should maybe add: one issue that was raised during review of my
initial patch series was that we'll also need to cope with situations
like the following:

	1) device's interrupt parent is probed (assigned IRQ base X)
	2) device is probed (interrupt parent there, therefore gets
	   assigned IRQ (X + z)
	3) device in removed
	4) device's interrupt parent is removed
	5) device is probed (deferred because interrupt parent isn't
	   there)
	6) device's interrupt parent is probed (assigned IRQ base Y)
	7) device is probed, gets assigned IRQ (Y + z)

So not only do we have to track which resources are interrupt resources,
but we also need to have them reassigned everytime the device is probed,
therefore interrupt mappings need to be properly disposed and the values
invalidated when probing is deferred or the device removed.

Having a dynamic list of properties all of a sudden doesn't sound like
such a bad idea after all. It makes handling this kind of situation
rather trivial, especially per-type lists. Those lists will be empty at
first and populated during the first probe. When probing fails or when a
device is unloaded, we dispose the mappings and empty the lists, so that
subsequent probes will start from scratch. It certainly sounds like a
bit of a waste of CPU cycles, but on the other hand it makes the code
much simpler.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Tony Lindgren]

* Thierry Reding <thierry.reding@gmail.com> [131125 01:51]:
> On Mon, Nov 25, 2013 at 10:25:50AM +0100, Thierry Reding wrote:
> > On Sun, Nov 24, 2013 at 09:36:51PM +0000, Grant Likely wrote:
> > > 
> > > I actually like the idea of completely allocating the resource structure
> > > but leaving some entries empty. However, I agree with rmk that putting
> > > garbage into a resource structure is a bad idea. What about changing the
> > > value of flags to 0 or some other value to be obviously an empty
> > > property and give the follow up parsing some context about which ones it
> > > needs to attempt to recalculate?
> > 
> > When I worked on this a while back I came to the same conclusion. It's
> > nice to allocate all the resources at once, because the number of them
> > doesn't change, only their actually values.
> 
> I should maybe add: one issue that was raised during review of my
> initial patch series was that we'll also need to cope with situations
> like the following:
> 
> 	1) device's interrupt parent is probed (assigned IRQ base X)
> 	2) device is probed (interrupt parent there, therefore gets
> 	   assigned IRQ (X + z)
> 	3) device in removed
> 	4) device's interrupt parent is removed
> 	5) device is probed (deferred because interrupt parent isn't
> 	   there)
> 	6) device's interrupt parent is probed (assigned IRQ base Y)
> 	7) device is probed, gets assigned IRQ (Y + z)
> 
> So not only do we have to track which resources are interrupt resources,
> but we also need to have them reassigned everytime the device is probed,
> therefore interrupt mappings need to be properly disposed and the values
> invalidated when probing is deferred or the device removed.
> 
> Having a dynamic list of properties all of a sudden doesn't sound like
> such a bad idea after all. It makes handling this kind of situation
> rather trivial, especially per-type lists. Those lists will be empty at
> first and populated during the first probe. When probing fails or when a
> device is unloaded, we dispose the mappings and empty the lists, so that
> subsequent probes will start from scratch. It certainly sounds like a
> bit of a waste of CPU cycles, but on the other hand it makes the code
> much simpler.

Looks like we cannot yet use devm_allocate, but that seems like a nice
solution in the long run. I just posted an updated patch to fix the $Subject
bug for the -rc cycle to this thread with more comments regarding dynamically
allocating the resources.

Regards,

Tony

[PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Tony Lindgren]

* Thierry Reding <thierry.reding@gmail.com> [131125 01:51]:
> On Mon, Nov 25, 2013 at 10:25:50AM +0100, Thierry Reding wrote:
> > On Sun, Nov 24, 2013 at 09:36:51PM +0000, Grant Likely wrote:
> > > 
> > > I actually like the idea of completely allocating the resource structure
> > > but leaving some entries empty. However, I agree with rmk that putting
> > > garbage into a resource structure is a bad idea. What about changing the
> > > value of flags to 0 or some other value to be obviously an empty
> > > property and give the follow up parsing some context about which ones it
> > > needs to attempt to recalculate?
> > 
> > When I worked on this a while back I came to the same conclusion. It's
> > nice to allocate all the resources at once, because the number of them
> > doesn't change, only their actually values.
> 
> I should maybe add: one issue that was raised during review of my
> initial patch series was that we'll also need to cope with situations
> like the following:
> 
> 	1) device's interrupt parent is probed (assigned IRQ base X)
> 	2) device is probed (interrupt parent there, therefore gets
> 	   assigned IRQ (X + z)
> 	3) device in removed
> 	4) device's interrupt parent is removed
> 	5) device is probed (deferred because interrupt parent isn't
> 	   there)
> 	6) device's interrupt parent is probed (assigned IRQ base Y)
> 	7) device is probed, gets assigned IRQ (Y + z)
> 
> So not only do we have to track which resources are interrupt resources,
> but we also need to have them reassigned everytime the device is probed,
> therefore interrupt mappings need to be properly disposed and the values
> invalidated when probing is deferred or the device removed.
> 
> Having a dynamic list of properties all of a sudden doesn't sound like
> such a bad idea after all. It makes handling this kind of situation
> rather trivial, especially per-type lists. Those lists will be empty at
> first and populated during the first probe. When probing fails or when a
> device is unloaded, we dispose the mappings and empty the lists, so that
> subsequent probes will start from scratch. It certainly sounds like a
> bit of a waste of CPU cycles, but on the other hand it makes the code
> much simpler.

Looks like we cannot yet use devm_allocate, but that seems like a nice
solution in the long run. I just posted an updated patch to fix the $Subject
bug for the -rc cycle to this thread with more comments regarding dynamically
allocating the resources.

Regards,

Tony

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Grant Likely]

On Mon, 25 Nov 2013 10:49:55 +0100, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Mon, Nov 25, 2013 at 10:25:50AM +0100, Thierry Reding wrote:
> > On Sun, Nov 24, 2013 at 09:36:51PM +0000, Grant Likely wrote:
> > > On Fri, 22 Nov 2013 16:43:35 -0800, Tony Lindgren <tony@atomide.com> wrote:
> > > > Currently we get the following kind of errors if we try to use
> > > > interrupt phandles to irqchips that have not yet initialized:
> > > > 
> > > > irq: no irq domain found for /ocp/pinmux@48002030 !
> > > > WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
> > > > Modules linked in:
> > > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
> > > > (show_stack+0x14/0x1c)
> > > > (dump_stack+0x6c/0xa0)
> > > > (warn_slowpath_common+0x64/0x84)
> > > > (warn_slowpath_null+0x1c/0x24)
> > > > (of_device_alloc+0x144/0x184)
> > > > (of_platform_device_create_pdata+0x44/0x9c)
> > > > (of_platform_bus_create+0xd0/0x170)
> > > > (of_platform_bus_create+0x12c/0x170)
> > > > (of_platform_populate+0x60/0x98)
> > > > ...
> > > > 
> > > > This is because we're wrongly trying to populate resources that are not
> > > > yet available. It's perfectly valid to create irqchips dynamically,
> > > > so let's fix up the issue by populating the interrupt resources based
> > > > on a notifier call instead.
> > > > 
> > > > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > > > 
> > > > ---
> > > > 
> > > > Rob & Grant, care to merge this for the -rc if this looks OK to you?
> > > > 
> > > > These happen for example when using interrupts-extended for omap
> > > > wake-up interrupts where the irq domain is created by pinctrl-single.c
> > > > at module_init time.
> > > > 
> > > > --- a/drivers/of/platform.c
> > > > +++ b/drivers/of/platform.c
> > > > @@ -130,6 +130,56 @@ void of_device_make_bus_id(struct device *dev)
> > > >  	dev_set_name(dev, "%s.%d", node->name, magic - 1);
> > > >  }
> > > >  
> > > > +/*
> > > > + * The device interrupts are not necessarily available for all
> > > > + * irqdomains initially so we need to populate them using a
> > > > + * notifier.
> > > > + */
> > > > +static int of_device_resource_notify(struct notifier_block *nb,
> > > > +				     unsigned long event, void *dev)
> > > > +{
> > > > +	struct platform_device *pdev = to_platform_device(dev);
> > > > +	struct device_node *np = pdev->dev.of_node;
> > > > +	struct resource *res = pdev->resource;
> > > > +	struct resource *irqr = NULL;
> > > > +	int num_irq, i, found = 0;
> > > > +
> > > > +	if (event != BUS_NOTIFY_BIND_DRIVER)
> > > > +		return 0;
> > > > +
> > > > +	if (!np)
> > > > +		goto out;
> > > > +
> > > > +	num_irq = of_irq_count(np);
> > > > +	if (!num_irq)
> > > > +		goto out;
> > > > +
> > > > +	for (i = 0; i < pdev->num_resources; i++, res++) {
> > > > +		if (res->flags != IORESOURCE_IRQ ||
> > > > +		    res->start != -EPROBE_DEFER ||
> > > > +		    res->end != -EPROBE_DEFER)
> > > > +			continue;
> > > > +
> > > > +		if (!irqr)
> > > > +			irqr = res;
> > > > +		found++;
> > > > +	}
> > > > +
> > > > +	if (!found)
> > > > +		goto out;
> > > > +
> > > > +	if (found != num_irq) {
> > > > +		dev_WARN(dev, "error populating irq resources: %i != %i\n",
> > > > +			 found, num_irq);
> > > > +		goto out;
> > > > +	}
> > > > +
> > > > +	WARN_ON(of_irq_to_resource_table(np, irqr, num_irq) != num_irq);
> > > > +
> > > > +out:
> > > > +	return NOTIFY_DONE;
> > > > +}
> > > > +
> > > >  /**
> > > >   * of_device_alloc - Allocate and initialize an of_device
> > > >   * @np: device node to assign to device
> > > > @@ -168,7 +218,13 @@ struct platform_device *of_device_alloc(struct device_node *np,
> > > >  			rc = of_address_to_resource(np, i, res);
> > > >  			WARN_ON(rc);
> > > >  		}
> > > > -		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
> > > > +
> > > > +		/* See of_device_resource_notify for populating interrupts */
> > > > +		for (i = 0; i < num_irq; i++, res++) {
> > > > +			res->flags = IORESOURCE_IRQ;
> > > > +			res->start = -EPROBE_DEFER;
> > > > +			res->end = -EPROBE_DEFER;
> > > > +		}
> > > 
> > > I actually like the idea of completely allocating the resource structure
> > > but leaving some entries empty. However, I agree with rmk that putting
> > > garbage into a resource structure is a bad idea. What about changing the
> > > value of flags to 0 or some other value to be obviously an empty
> > > property and give the follow up parsing some context about which ones it
> > > needs to attempt to recalculate?
> > 
> > When I worked on this a while back I came to the same conclusion. It's
> > nice to allocate all the resources at once, because the number of them
> > doesn't change, only their actually values.
> 
> I should maybe add: one issue that was raised during review of my
> initial patch series was that we'll also need to cope with situations
> like the following:
> 
> 	1) device's interrupt parent is probed (assigned IRQ base X)
> 	2) device is probed (interrupt parent there, therefore gets
> 	   assigned IRQ (X + z)
> 	3) device in removed
> 	4) device's interrupt parent is removed
> 	5) device is probed (deferred because interrupt parent isn't
> 	   there)
> 	6) device's interrupt parent is probed (assigned IRQ base Y)
> 	7) device is probed, gets assigned IRQ (Y + z)
> 
> So not only do we have to track which resources are interrupt resources,
> but we also need to have them reassigned everytime the device is probed,
> therefore interrupt mappings need to be properly disposed and the values
> invalidated when probing is deferred or the device removed.

Yes, that is a problem, but the only way to handle that is to always
recalcuate all resource references at probe time. I don't feel good
about handling that in the core. I'd rather move drivers away from
referencing the resources table directly and instead use an API. Then
the resources table could be missing entirely.

g.

[PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Grant Likely]

On Mon, 25 Nov 2013 10:49:55 +0100, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Mon, Nov 25, 2013 at 10:25:50AM +0100, Thierry Reding wrote:
> > On Sun, Nov 24, 2013 at 09:36:51PM +0000, Grant Likely wrote:
> > > On Fri, 22 Nov 2013 16:43:35 -0800, Tony Lindgren <tony@atomide.com> wrote:
> > > > Currently we get the following kind of errors if we try to use
> > > > interrupt phandles to irqchips that have not yet initialized:
> > > > 
> > > > irq: no irq domain found for /ocp/pinmux at 48002030 !
> > > > WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
> > > > Modules linked in:
> > > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
> > > > (show_stack+0x14/0x1c)
> > > > (dump_stack+0x6c/0xa0)
> > > > (warn_slowpath_common+0x64/0x84)
> > > > (warn_slowpath_null+0x1c/0x24)
> > > > (of_device_alloc+0x144/0x184)
> > > > (of_platform_device_create_pdata+0x44/0x9c)
> > > > (of_platform_bus_create+0xd0/0x170)
> > > > (of_platform_bus_create+0x12c/0x170)
> > > > (of_platform_populate+0x60/0x98)
> > > > ...
> > > > 
> > > > This is because we're wrongly trying to populate resources that are not
> > > > yet available. It's perfectly valid to create irqchips dynamically,
> > > > so let's fix up the issue by populating the interrupt resources based
> > > > on a notifier call instead.
> > > > 
> > > > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > > > 
> > > > ---
> > > > 
> > > > Rob & Grant, care to merge this for the -rc if this looks OK to you?
> > > > 
> > > > These happen for example when using interrupts-extended for omap
> > > > wake-up interrupts where the irq domain is created by pinctrl-single.c
> > > > at module_init time.
> > > > 
> > > > --- a/drivers/of/platform.c
> > > > +++ b/drivers/of/platform.c
> > > > @@ -130,6 +130,56 @@ void of_device_make_bus_id(struct device *dev)
> > > >  	dev_set_name(dev, "%s.%d", node->name, magic - 1);
> > > >  }
> > > >  
> > > > +/*
> > > > + * The device interrupts are not necessarily available for all
> > > > + * irqdomains initially so we need to populate them using a
> > > > + * notifier.
> > > > + */
> > > > +static int of_device_resource_notify(struct notifier_block *nb,
> > > > +				     unsigned long event, void *dev)
> > > > +{
> > > > +	struct platform_device *pdev = to_platform_device(dev);
> > > > +	struct device_node *np = pdev->dev.of_node;
> > > > +	struct resource *res = pdev->resource;
> > > > +	struct resource *irqr = NULL;
> > > > +	int num_irq, i, found = 0;
> > > > +
> > > > +	if (event != BUS_NOTIFY_BIND_DRIVER)
> > > > +		return 0;
> > > > +
> > > > +	if (!np)
> > > > +		goto out;
> > > > +
> > > > +	num_irq = of_irq_count(np);
> > > > +	if (!num_irq)
> > > > +		goto out;
> > > > +
> > > > +	for (i = 0; i < pdev->num_resources; i++, res++) {
> > > > +		if (res->flags != IORESOURCE_IRQ ||
> > > > +		    res->start != -EPROBE_DEFER ||
> > > > +		    res->end != -EPROBE_DEFER)
> > > > +			continue;
> > > > +
> > > > +		if (!irqr)
> > > > +			irqr = res;
> > > > +		found++;
> > > > +	}
> > > > +
> > > > +	if (!found)
> > > > +		goto out;
> > > > +
> > > > +	if (found != num_irq) {
> > > > +		dev_WARN(dev, "error populating irq resources: %i != %i\n",
> > > > +			 found, num_irq);
> > > > +		goto out;
> > > > +	}
> > > > +
> > > > +	WARN_ON(of_irq_to_resource_table(np, irqr, num_irq) != num_irq);
> > > > +
> > > > +out:
> > > > +	return NOTIFY_DONE;
> > > > +}
> > > > +
> > > >  /**
> > > >   * of_device_alloc - Allocate and initialize an of_device
> > > >   * @np: device node to assign to device
> > > > @@ -168,7 +218,13 @@ struct platform_device *of_device_alloc(struct device_node *np,
> > > >  			rc = of_address_to_resource(np, i, res);
> > > >  			WARN_ON(rc);
> > > >  		}
> > > > -		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
> > > > +
> > > > +		/* See of_device_resource_notify for populating interrupts */
> > > > +		for (i = 0; i < num_irq; i++, res++) {
> > > > +			res->flags = IORESOURCE_IRQ;
> > > > +			res->start = -EPROBE_DEFER;
> > > > +			res->end = -EPROBE_DEFER;
> > > > +		}
> > > 
> > > I actually like the idea of completely allocating the resource structure
> > > but leaving some entries empty. However, I agree with rmk that putting
> > > garbage into a resource structure is a bad idea. What about changing the
> > > value of flags to 0 or some other value to be obviously an empty
> > > property and give the follow up parsing some context about which ones it
> > > needs to attempt to recalculate?
> > 
> > When I worked on this a while back I came to the same conclusion. It's
> > nice to allocate all the resources at once, because the number of them
> > doesn't change, only their actually values.
> 
> I should maybe add: one issue that was raised during review of my
> initial patch series was that we'll also need to cope with situations
> like the following:
> 
> 	1) device's interrupt parent is probed (assigned IRQ base X)
> 	2) device is probed (interrupt parent there, therefore gets
> 	   assigned IRQ (X + z)
> 	3) device in removed
> 	4) device's interrupt parent is removed
> 	5) device is probed (deferred because interrupt parent isn't
> 	   there)
> 	6) device's interrupt parent is probed (assigned IRQ base Y)
> 	7) device is probed, gets assigned IRQ (Y + z)
> 
> So not only do we have to track which resources are interrupt resources,
> but we also need to have them reassigned everytime the device is probed,
> therefore interrupt mappings need to be properly disposed and the values
> invalidated when probing is deferred or the device removed.

Yes, that is a problem, but the only way to handle that is to always
recalcuate all resource references at probe time. I don't feel good
about handling that in the core. I'd rather move drivers away from
referencing the resources table directly and instead use an API. Then
the resources table could be missing entirely.

g.

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Thierry Reding]

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

On Wed, Nov 27, 2013 at 03:56:29PM +0000, Grant Likely wrote:
> On Mon, 25 Nov 2013 10:49:55 +0100, Thierry Reding <thierry.reding@gmail.com> wrote:
> > On Mon, Nov 25, 2013 at 10:25:50AM +0100, Thierry Reding wrote:
> > > On Sun, Nov 24, 2013 at 09:36:51PM +0000, Grant Likely wrote:
> > > > On Fri, 22 Nov 2013 16:43:35 -0800, Tony Lindgren <tony@atomide.com> wrote:
> > > > > Currently we get the following kind of errors if we try to use
> > > > > interrupt phandles to irqchips that have not yet initialized:
> > > > > 
> > > > > irq: no irq domain found for /ocp/pinmux@48002030 !
> > > > > WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
> > > > > Modules linked in:
> > > > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
> > > > > (show_stack+0x14/0x1c)
> > > > > (dump_stack+0x6c/0xa0)
> > > > > (warn_slowpath_common+0x64/0x84)
> > > > > (warn_slowpath_null+0x1c/0x24)
> > > > > (of_device_alloc+0x144/0x184)
> > > > > (of_platform_device_create_pdata+0x44/0x9c)
> > > > > (of_platform_bus_create+0xd0/0x170)
> > > > > (of_platform_bus_create+0x12c/0x170)
> > > > > (of_platform_populate+0x60/0x98)
> > > > > ...
> > > > > 
> > > > > This is because we're wrongly trying to populate resources that are not
> > > > > yet available. It's perfectly valid to create irqchips dynamically,
> > > > > so let's fix up the issue by populating the interrupt resources based
> > > > > on a notifier call instead.
> > > > > 
> > > > > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > > > > 
> > > > > ---
> > > > > 
> > > > > Rob & Grant, care to merge this for the -rc if this looks OK to you?
> > > > > 
> > > > > These happen for example when using interrupts-extended for omap
> > > > > wake-up interrupts where the irq domain is created by pinctrl-single.c
> > > > > at module_init time.
> > > > > 
> > > > > --- a/drivers/of/platform.c
> > > > > +++ b/drivers/of/platform.c
> > > > > @@ -130,6 +130,56 @@ void of_device_make_bus_id(struct device *dev)
> > > > >  	dev_set_name(dev, "%s.%d", node->name, magic - 1);
> > > > >  }
> > > > >  
> > > > > +/*
> > > > > + * The device interrupts are not necessarily available for all
> > > > > + * irqdomains initially so we need to populate them using a
> > > > > + * notifier.
> > > > > + */
> > > > > +static int of_device_resource_notify(struct notifier_block *nb,
> > > > > +				     unsigned long event, void *dev)
> > > > > +{
> > > > > +	struct platform_device *pdev = to_platform_device(dev);
> > > > > +	struct device_node *np = pdev->dev.of_node;
> > > > > +	struct resource *res = pdev->resource;
> > > > > +	struct resource *irqr = NULL;
> > > > > +	int num_irq, i, found = 0;
> > > > > +
> > > > > +	if (event != BUS_NOTIFY_BIND_DRIVER)
> > > > > +		return 0;
> > > > > +
> > > > > +	if (!np)
> > > > > +		goto out;
> > > > > +
> > > > > +	num_irq = of_irq_count(np);
> > > > > +	if (!num_irq)
> > > > > +		goto out;
> > > > > +
> > > > > +	for (i = 0; i < pdev->num_resources; i++, res++) {
> > > > > +		if (res->flags != IORESOURCE_IRQ ||
> > > > > +		    res->start != -EPROBE_DEFER ||
> > > > > +		    res->end != -EPROBE_DEFER)
> > > > > +			continue;
> > > > > +
> > > > > +		if (!irqr)
> > > > > +			irqr = res;
> > > > > +		found++;
> > > > > +	}
> > > > > +
> > > > > +	if (!found)
> > > > > +		goto out;
> > > > > +
> > > > > +	if (found != num_irq) {
> > > > > +		dev_WARN(dev, "error populating irq resources: %i != %i\n",
> > > > > +			 found, num_irq);
> > > > > +		goto out;
> > > > > +	}
> > > > > +
> > > > > +	WARN_ON(of_irq_to_resource_table(np, irqr, num_irq) != num_irq);
> > > > > +
> > > > > +out:
> > > > > +	return NOTIFY_DONE;
> > > > > +}
> > > > > +
> > > > >  /**
> > > > >   * of_device_alloc - Allocate and initialize an of_device
> > > > >   * @np: device node to assign to device
> > > > > @@ -168,7 +218,13 @@ struct platform_device *of_device_alloc(struct device_node *np,
> > > > >  			rc = of_address_to_resource(np, i, res);
> > > > >  			WARN_ON(rc);
> > > > >  		}
> > > > > -		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
> > > > > +
> > > > > +		/* See of_device_resource_notify for populating interrupts */
> > > > > +		for (i = 0; i < num_irq; i++, res++) {
> > > > > +			res->flags = IORESOURCE_IRQ;
> > > > > +			res->start = -EPROBE_DEFER;
> > > > > +			res->end = -EPROBE_DEFER;
> > > > > +		}
> > > > 
> > > > I actually like the idea of completely allocating the resource structure
> > > > but leaving some entries empty. However, I agree with rmk that putting
> > > > garbage into a resource structure is a bad idea. What about changing the
> > > > value of flags to 0 or some other value to be obviously an empty
> > > > property and give the follow up parsing some context about which ones it
> > > > needs to attempt to recalculate?
> > > 
> > > When I worked on this a while back I came to the same conclusion. It's
> > > nice to allocate all the resources at once, because the number of them
> > > doesn't change, only their actually values.
> > 
> > I should maybe add: one issue that was raised during review of my
> > initial patch series was that we'll also need to cope with situations
> > like the following:
> > 
> > 	1) device's interrupt parent is probed (assigned IRQ base X)
> > 	2) device is probed (interrupt parent there, therefore gets
> > 	   assigned IRQ (X + z)
> > 	3) device in removed
> > 	4) device's interrupt parent is removed
> > 	5) device is probed (deferred because interrupt parent isn't
> > 	   there)
> > 	6) device's interrupt parent is probed (assigned IRQ base Y)
> > 	7) device is probed, gets assigned IRQ (Y + z)
> > 
> > So not only do we have to track which resources are interrupt resources,
> > but we also need to have them reassigned everytime the device is probed,
> > therefore interrupt mappings need to be properly disposed and the values
> > invalidated when probing is deferred or the device removed.
> 
> Yes, that is a problem, but the only way to handle that is to always
> recalcuate all resource references at probe time. I don't feel good
> about handling that in the core. I'd rather move drivers away from
> referencing the resources table directly and instead use an API. Then
> the resources table could be missing entirely.

Are you suggesting something like this?

---

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 3a94b799f166..c894d1af3a5e 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -13,6 +13,7 @@
 #include <linux/string.h>
 #include <linux/platform_device.h>
 #include <linux/of_device.h>
+#include <linux/of_irq.h>
 #include <linux/module.h>
 #include <linux/init.h>
 #include <linux/dma-mapping.h>
@@ -87,7 +88,12 @@ int platform_get_irq(struct platform_device *dev, unsigned int num)
                return -ENXIO;
        return dev->archdata.irqs[num];
 #else
-       struct resource *r = platform_get_resource(dev, IORESOURCE_IRQ, num);
+       struct resource *r;
+
+       if (IS_ENABLED(CONFIG_OF) && dev->dev.of_node)
+               return irq_of_parse_and_map(dev->dev.of_node, num);
+
+       r = platform_get_resource(dev, IORESOURCE_IRQ, num);
 
        return r ? r->start : -ENXIO;
 #endif

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

[PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Thierry Reding]

On Wed, Nov 27, 2013 at 03:56:29PM +0000, Grant Likely wrote:
> On Mon, 25 Nov 2013 10:49:55 +0100, Thierry Reding <thierry.reding@gmail.com> wrote:
> > On Mon, Nov 25, 2013 at 10:25:50AM +0100, Thierry Reding wrote:
> > > On Sun, Nov 24, 2013 at 09:36:51PM +0000, Grant Likely wrote:
> > > > On Fri, 22 Nov 2013 16:43:35 -0800, Tony Lindgren <tony@atomide.com> wrote:
> > > > > Currently we get the following kind of errors if we try to use
> > > > > interrupt phandles to irqchips that have not yet initialized:
> > > > > 
> > > > > irq: no irq domain found for /ocp/pinmux at 48002030 !
> > > > > WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
> > > > > Modules linked in:
> > > > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
> > > > > (show_stack+0x14/0x1c)
> > > > > (dump_stack+0x6c/0xa0)
> > > > > (warn_slowpath_common+0x64/0x84)
> > > > > (warn_slowpath_null+0x1c/0x24)
> > > > > (of_device_alloc+0x144/0x184)
> > > > > (of_platform_device_create_pdata+0x44/0x9c)
> > > > > (of_platform_bus_create+0xd0/0x170)
> > > > > (of_platform_bus_create+0x12c/0x170)
> > > > > (of_platform_populate+0x60/0x98)
> > > > > ...
> > > > > 
> > > > > This is because we're wrongly trying to populate resources that are not
> > > > > yet available. It's perfectly valid to create irqchips dynamically,
> > > > > so let's fix up the issue by populating the interrupt resources based
> > > > > on a notifier call instead.
> > > > > 
> > > > > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > > > > 
> > > > > ---
> > > > > 
> > > > > Rob & Grant, care to merge this for the -rc if this looks OK to you?
> > > > > 
> > > > > These happen for example when using interrupts-extended for omap
> > > > > wake-up interrupts where the irq domain is created by pinctrl-single.c
> > > > > at module_init time.
> > > > > 
> > > > > --- a/drivers/of/platform.c
> > > > > +++ b/drivers/of/platform.c
> > > > > @@ -130,6 +130,56 @@ void of_device_make_bus_id(struct device *dev)
> > > > >  	dev_set_name(dev, "%s.%d", node->name, magic - 1);
> > > > >  }
> > > > >  
> > > > > +/*
> > > > > + * The device interrupts are not necessarily available for all
> > > > > + * irqdomains initially so we need to populate them using a
> > > > > + * notifier.
> > > > > + */
> > > > > +static int of_device_resource_notify(struct notifier_block *nb,
> > > > > +				     unsigned long event, void *dev)
> > > > > +{
> > > > > +	struct platform_device *pdev = to_platform_device(dev);
> > > > > +	struct device_node *np = pdev->dev.of_node;
> > > > > +	struct resource *res = pdev->resource;
> > > > > +	struct resource *irqr = NULL;
> > > > > +	int num_irq, i, found = 0;
> > > > > +
> > > > > +	if (event != BUS_NOTIFY_BIND_DRIVER)
> > > > > +		return 0;
> > > > > +
> > > > > +	if (!np)
> > > > > +		goto out;
> > > > > +
> > > > > +	num_irq = of_irq_count(np);
> > > > > +	if (!num_irq)
> > > > > +		goto out;
> > > > > +
> > > > > +	for (i = 0; i < pdev->num_resources; i++, res++) {
> > > > > +		if (res->flags != IORESOURCE_IRQ ||
> > > > > +		    res->start != -EPROBE_DEFER ||
> > > > > +		    res->end != -EPROBE_DEFER)
> > > > > +			continue;
> > > > > +
> > > > > +		if (!irqr)
> > > > > +			irqr = res;
> > > > > +		found++;
> > > > > +	}
> > > > > +
> > > > > +	if (!found)
> > > > > +		goto out;
> > > > > +
> > > > > +	if (found != num_irq) {
> > > > > +		dev_WARN(dev, "error populating irq resources: %i != %i\n",
> > > > > +			 found, num_irq);
> > > > > +		goto out;
> > > > > +	}
> > > > > +
> > > > > +	WARN_ON(of_irq_to_resource_table(np, irqr, num_irq) != num_irq);
> > > > > +
> > > > > +out:
> > > > > +	return NOTIFY_DONE;
> > > > > +}
> > > > > +
> > > > >  /**
> > > > >   * of_device_alloc - Allocate and initialize an of_device
> > > > >   * @np: device node to assign to device
> > > > > @@ -168,7 +218,13 @@ struct platform_device *of_device_alloc(struct device_node *np,
> > > > >  			rc = of_address_to_resource(np, i, res);
> > > > >  			WARN_ON(rc);
> > > > >  		}
> > > > > -		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
> > > > > +
> > > > > +		/* See of_device_resource_notify for populating interrupts */
> > > > > +		for (i = 0; i < num_irq; i++, res++) {
> > > > > +			res->flags = IORESOURCE_IRQ;
> > > > > +			res->start = -EPROBE_DEFER;
> > > > > +			res->end = -EPROBE_DEFER;
> > > > > +		}
> > > > 
> > > > I actually like the idea of completely allocating the resource structure
> > > > but leaving some entries empty. However, I agree with rmk that putting
> > > > garbage into a resource structure is a bad idea. What about changing the
> > > > value of flags to 0 or some other value to be obviously an empty
> > > > property and give the follow up parsing some context about which ones it
> > > > needs to attempt to recalculate?
> > > 
> > > When I worked on this a while back I came to the same conclusion. It's
> > > nice to allocate all the resources at once, because the number of them
> > > doesn't change, only their actually values.
> > 
> > I should maybe add: one issue that was raised during review of my
> > initial patch series was that we'll also need to cope with situations
> > like the following:
> > 
> > 	1) device's interrupt parent is probed (assigned IRQ base X)
> > 	2) device is probed (interrupt parent there, therefore gets
> > 	   assigned IRQ (X + z)
> > 	3) device in removed
> > 	4) device's interrupt parent is removed
> > 	5) device is probed (deferred because interrupt parent isn't
> > 	   there)
> > 	6) device's interrupt parent is probed (assigned IRQ base Y)
> > 	7) device is probed, gets assigned IRQ (Y + z)
> > 
> > So not only do we have to track which resources are interrupt resources,
> > but we also need to have them reassigned everytime the device is probed,
> > therefore interrupt mappings need to be properly disposed and the values
> > invalidated when probing is deferred or the device removed.
> 
> Yes, that is a problem, but the only way to handle that is to always
> recalcuate all resource references at probe time. I don't feel good
> about handling that in the core. I'd rather move drivers away from
> referencing the resources table directly and instead use an API. Then
> the resources table could be missing entirely.

Are you suggesting something like this?

---

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 3a94b799f166..c894d1af3a5e 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -13,6 +13,7 @@
 #include <linux/string.h>
 #include <linux/platform_device.h>
 #include <linux/of_device.h>
+#include <linux/of_irq.h>
 #include <linux/module.h>
 #include <linux/init.h>
 #include <linux/dma-mapping.h>
@@ -87,7 +88,12 @@ int platform_get_irq(struct platform_device *dev, unsigned int num)
                return -ENXIO;
        return dev->archdata.irqs[num];
 #else
-       struct resource *r = platform_get_resource(dev, IORESOURCE_IRQ, num);
+       struct resource *r;
+
+       if (IS_ENABLED(CONFIG_OF) && dev->dev.of_node)
+               return irq_of_parse_and_map(dev->dev.of_node, num);
+
+       r = platform_get_resource(dev, IORESOURCE_IRQ, num);
 
        return r ? r->start : -ENXIO;
 #endif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131128/9007f9ca/attachment.sig>

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Thierry Reding]

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

On Wed, Nov 27, 2013 at 03:56:29PM +0000, Grant Likely wrote:
> On Mon, 25 Nov 2013 10:49:55 +0100, Thierry Reding <thierry.reding@gmail.com> wrote:
> > On Mon, Nov 25, 2013 at 10:25:50AM +0100, Thierry Reding wrote:
> > > On Sun, Nov 24, 2013 at 09:36:51PM +0000, Grant Likely wrote:
> > > > On Fri, 22 Nov 2013 16:43:35 -0800, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> > > > > Currently we get the following kind of errors if we try to use
> > > > > interrupt phandles to irqchips that have not yet initialized:
> > > > > 
> > > > > irq: no irq domain found for /ocp/pinmux@48002030 !
> > > > > WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
> > > > > Modules linked in:
> > > > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
> > > > > (show_stack+0x14/0x1c)
> > > > > (dump_stack+0x6c/0xa0)
> > > > > (warn_slowpath_common+0x64/0x84)
> > > > > (warn_slowpath_null+0x1c/0x24)
> > > > > (of_device_alloc+0x144/0x184)
> > > > > (of_platform_device_create_pdata+0x44/0x9c)
> > > > > (of_platform_bus_create+0xd0/0x170)
> > > > > (of_platform_bus_create+0x12c/0x170)
> > > > > (of_platform_populate+0x60/0x98)
> > > > > ...
> > > > > 
> > > > > This is because we're wrongly trying to populate resources that are not
> > > > > yet available. It's perfectly valid to create irqchips dynamically,
> > > > > so let's fix up the issue by populating the interrupt resources based
> > > > > on a notifier call instead.
> > > > > 
> > > > > Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> > > > > 
> > > > > ---
> > > > > 
> > > > > Rob & Grant, care to merge this for the -rc if this looks OK to you?
> > > > > 
> > > > > These happen for example when using interrupts-extended for omap
> > > > > wake-up interrupts where the irq domain is created by pinctrl-single.c
> > > > > at module_init time.
> > > > > 
> > > > > --- a/drivers/of/platform.c
> > > > > +++ b/drivers/of/platform.c
> > > > > @@ -130,6 +130,56 @@ void of_device_make_bus_id(struct device *dev)
> > > > >  	dev_set_name(dev, "%s.%d", node->name, magic - 1);
> > > > >  }
> > > > >  
> > > > > +/*
> > > > > + * The device interrupts are not necessarily available for all
> > > > > + * irqdomains initially so we need to populate them using a
> > > > > + * notifier.
> > > > > + */
> > > > > +static int of_device_resource_notify(struct notifier_block *nb,
> > > > > +				     unsigned long event, void *dev)
> > > > > +{
> > > > > +	struct platform_device *pdev = to_platform_device(dev);
> > > > > +	struct device_node *np = pdev->dev.of_node;
> > > > > +	struct resource *res = pdev->resource;
> > > > > +	struct resource *irqr = NULL;
> > > > > +	int num_irq, i, found = 0;
> > > > > +
> > > > > +	if (event != BUS_NOTIFY_BIND_DRIVER)
> > > > > +		return 0;
> > > > > +
> > > > > +	if (!np)
> > > > > +		goto out;
> > > > > +
> > > > > +	num_irq = of_irq_count(np);
> > > > > +	if (!num_irq)
> > > > > +		goto out;
> > > > > +
> > > > > +	for (i = 0; i < pdev->num_resources; i++, res++) {
> > > > > +		if (res->flags != IORESOURCE_IRQ ||
> > > > > +		    res->start != -EPROBE_DEFER ||
> > > > > +		    res->end != -EPROBE_DEFER)
> > > > > +			continue;
> > > > > +
> > > > > +		if (!irqr)
> > > > > +			irqr = res;
> > > > > +		found++;
> > > > > +	}
> > > > > +
> > > > > +	if (!found)
> > > > > +		goto out;
> > > > > +
> > > > > +	if (found != num_irq) {
> > > > > +		dev_WARN(dev, "error populating irq resources: %i != %i\n",
> > > > > +			 found, num_irq);
> > > > > +		goto out;
> > > > > +	}
> > > > > +
> > > > > +	WARN_ON(of_irq_to_resource_table(np, irqr, num_irq) != num_irq);
> > > > > +
> > > > > +out:
> > > > > +	return NOTIFY_DONE;
> > > > > +}
> > > > > +
> > > > >  /**
> > > > >   * of_device_alloc - Allocate and initialize an of_device
> > > > >   * @np: device node to assign to device
> > > > > @@ -168,7 +218,13 @@ struct platform_device *of_device_alloc(struct device_node *np,
> > > > >  			rc = of_address_to_resource(np, i, res);
> > > > >  			WARN_ON(rc);
> > > > >  		}
> > > > > -		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
> > > > > +
> > > > > +		/* See of_device_resource_notify for populating interrupts */
> > > > > +		for (i = 0; i < num_irq; i++, res++) {
> > > > > +			res->flags = IORESOURCE_IRQ;
> > > > > +			res->start = -EPROBE_DEFER;
> > > > > +			res->end = -EPROBE_DEFER;
> > > > > +		}
> > > > 
> > > > I actually like the idea of completely allocating the resource structure
> > > > but leaving some entries empty. However, I agree with rmk that putting
> > > > garbage into a resource structure is a bad idea. What about changing the
> > > > value of flags to 0 or some other value to be obviously an empty
> > > > property and give the follow up parsing some context about which ones it
> > > > needs to attempt to recalculate?
> > > 
> > > When I worked on this a while back I came to the same conclusion. It's
> > > nice to allocate all the resources at once, because the number of them
> > > doesn't change, only their actually values.
> > 
> > I should maybe add: one issue that was raised during review of my
> > initial patch series was that we'll also need to cope with situations
> > like the following:
> > 
> > 	1) device's interrupt parent is probed (assigned IRQ base X)
> > 	2) device is probed (interrupt parent there, therefore gets
> > 	   assigned IRQ (X + z)
> > 	3) device in removed
> > 	4) device's interrupt parent is removed
> > 	5) device is probed (deferred because interrupt parent isn't
> > 	   there)
> > 	6) device's interrupt parent is probed (assigned IRQ base Y)
> > 	7) device is probed, gets assigned IRQ (Y + z)
> > 
> > So not only do we have to track which resources are interrupt resources,
> > but we also need to have them reassigned everytime the device is probed,
> > therefore interrupt mappings need to be properly disposed and the values
> > invalidated when probing is deferred or the device removed.
> 
> Yes, that is a problem, but the only way to handle that is to always
> recalcuate all resource references at probe time. I don't feel good
> about handling that in the core. I'd rather move drivers away from
> referencing the resources table directly and instead use an API. Then
> the resources table could be missing entirely.

Are you suggesting something like this?

---

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 3a94b799f166..c894d1af3a5e 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -13,6 +13,7 @@
 #include <linux/string.h>
 #include <linux/platform_device.h>
 #include <linux/of_device.h>
+#include <linux/of_irq.h>
 #include <linux/module.h>
 #include <linux/init.h>
 #include <linux/dma-mapping.h>
@@ -87,7 +88,12 @@ int platform_get_irq(struct platform_device *dev, unsigned int num)
                return -ENXIO;
        return dev->archdata.irqs[num];
 #else
-       struct resource *r = platform_get_resource(dev, IORESOURCE_IRQ, num);
+       struct resource *r;
+
+       if (IS_ENABLED(CONFIG_OF) && dev->dev.of_node)
+               return irq_of_parse_and_map(dev->dev.of_node, num);
+
+       r = platform_get_resource(dev, IORESOURCE_IRQ, num);
 
        return r ? r->start : -ENXIO;
 #endif

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Grant Likely]

On Thu, 28 Nov 2013 16:46:23 +0100, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Wed, Nov 27, 2013 at 03:56:29PM +0000, Grant Likely wrote:
> > On Mon, 25 Nov 2013 10:49:55 +0100, Thierry Reding <thierry.reding@gmail.com> wrote:
> > > 
> > > I should maybe add: one issue that was raised during review of my
> > > initial patch series was that we'll also need to cope with situations
> > > like the following:
> > > 
> > > 	1) device's interrupt parent is probed (assigned IRQ base X)
> > > 	2) device is probed (interrupt parent there, therefore gets
> > > 	   assigned IRQ (X + z)
> > > 	3) device in removed
> > > 	4) device's interrupt parent is removed
> > > 	5) device is probed (deferred because interrupt parent isn't
> > > 	   there)
> > > 	6) device's interrupt parent is probed (assigned IRQ base Y)
> > > 	7) device is probed, gets assigned IRQ (Y + z)
> > > 
> > > So not only do we have to track which resources are interrupt resources,
> > > but we also need to have them reassigned everytime the device is probed,
> > > therefore interrupt mappings need to be properly disposed and the values
> > > invalidated when probing is deferred or the device removed.
> > 
> > Yes, that is a problem, but the only way to handle that is to always
> > recalcuate all resource references at probe time. I don't feel good
> > about handling that in the core. I'd rather move drivers away from
> > referencing the resources table directly and instead use an API. Then
> > the resources table could be missing entirely.
> 
> Are you suggesting something like this?
> 
> ---
> 
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 3a94b799f166..c894d1af3a5e 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -13,6 +13,7 @@
>  #include <linux/string.h>
>  #include <linux/platform_device.h>
>  #include <linux/of_device.h>
> +#include <linux/of_irq.h>
>  #include <linux/module.h>
>  #include <linux/init.h>
>  #include <linux/dma-mapping.h>
> @@ -87,7 +88,12 @@ int platform_get_irq(struct platform_device *dev, unsigned int num)
>                 return -ENXIO;
>         return dev->archdata.irqs[num];
>  #else
> -       struct resource *r = platform_get_resource(dev, IORESOURCE_IRQ, num);
> +       struct resource *r;
> +
> +       if (IS_ENABLED(CONFIG_OF) && dev->dev.of_node)
> +               return irq_of_parse_and_map(dev->dev.of_node, num);
> +
> +       r = platform_get_resource(dev, IORESOURCE_IRQ, num);

Yes. Or even more generically we could have a device_get_irq() function:

int device_get_irq(struct device *dev, unsigned int num)
{
	if (IS_ENABLED(CONFIG_OF) && dev->of_node)
		return irq_of_parse_and_map(dev->of_node, num);
	/* An ACPI hook could go here */
	return 0
}

It would be callable by any device driver, and platform_get_irq() could
call it too.

g.

[PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Grant Likely]

On Thu, 28 Nov 2013 16:46:23 +0100, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Wed, Nov 27, 2013 at 03:56:29PM +0000, Grant Likely wrote:
> > On Mon, 25 Nov 2013 10:49:55 +0100, Thierry Reding <thierry.reding@gmail.com> wrote:
> > > 
> > > I should maybe add: one issue that was raised during review of my
> > > initial patch series was that we'll also need to cope with situations
> > > like the following:
> > > 
> > > 	1) device's interrupt parent is probed (assigned IRQ base X)
> > > 	2) device is probed (interrupt parent there, therefore gets
> > > 	   assigned IRQ (X + z)
> > > 	3) device in removed
> > > 	4) device's interrupt parent is removed
> > > 	5) device is probed (deferred because interrupt parent isn't
> > > 	   there)
> > > 	6) device's interrupt parent is probed (assigned IRQ base Y)
> > > 	7) device is probed, gets assigned IRQ (Y + z)
> > > 
> > > So not only do we have to track which resources are interrupt resources,
> > > but we also need to have them reassigned everytime the device is probed,
> > > therefore interrupt mappings need to be properly disposed and the values
> > > invalidated when probing is deferred or the device removed.
> > 
> > Yes, that is a problem, but the only way to handle that is to always
> > recalcuate all resource references at probe time. I don't feel good
> > about handling that in the core. I'd rather move drivers away from
> > referencing the resources table directly and instead use an API. Then
> > the resources table could be missing entirely.
> 
> Are you suggesting something like this?
> 
> ---
> 
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 3a94b799f166..c894d1af3a5e 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -13,6 +13,7 @@
>  #include <linux/string.h>
>  #include <linux/platform_device.h>
>  #include <linux/of_device.h>
> +#include <linux/of_irq.h>
>  #include <linux/module.h>
>  #include <linux/init.h>
>  #include <linux/dma-mapping.h>
> @@ -87,7 +88,12 @@ int platform_get_irq(struct platform_device *dev, unsigned int num)
>                 return -ENXIO;
>         return dev->archdata.irqs[num];
>  #else
> -       struct resource *r = platform_get_resource(dev, IORESOURCE_IRQ, num);
> +       struct resource *r;
> +
> +       if (IS_ENABLED(CONFIG_OF) && dev->dev.of_node)
> +               return irq_of_parse_and_map(dev->dev.of_node, num);
> +
> +       r = platform_get_resource(dev, IORESOURCE_IRQ, num);

Yes. Or even more generically we could have a device_get_irq() function:

int device_get_irq(struct device *dev, unsigned int num)
{
	if (IS_ENABLED(CONFIG_OF) && dev->of_node)
		return irq_of_parse_and_map(dev->of_node, num);
	/* An ACPI hook could go here */
	return 0
}

It would be callable by any device driver, and platform_get_irq() could
call it too.

g.

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Thierry Reding]

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

On Wed, Dec 11, 2013 at 01:45:53PM +0000, Grant Likely wrote:
> On Thu, 28 Nov 2013 16:46:23 +0100, Thierry Reding <thierry.reding@gmail.com> wrote:
> > On Wed, Nov 27, 2013 at 03:56:29PM +0000, Grant Likely wrote:
> > > On Mon, 25 Nov 2013 10:49:55 +0100, Thierry Reding <thierry.reding@gmail.com> wrote:
> > > > 
> > > > I should maybe add: one issue that was raised during review of my
> > > > initial patch series was that we'll also need to cope with situations
> > > > like the following:
> > > > 
> > > > 	1) device's interrupt parent is probed (assigned IRQ base X)
> > > > 	2) device is probed (interrupt parent there, therefore gets
> > > > 	   assigned IRQ (X + z)
> > > > 	3) device in removed
> > > > 	4) device's interrupt parent is removed
> > > > 	5) device is probed (deferred because interrupt parent isn't
> > > > 	   there)
> > > > 	6) device's interrupt parent is probed (assigned IRQ base Y)
> > > > 	7) device is probed, gets assigned IRQ (Y + z)
> > > > 
> > > > So not only do we have to track which resources are interrupt resources,
> > > > but we also need to have them reassigned everytime the device is probed,
> > > > therefore interrupt mappings need to be properly disposed and the values
> > > > invalidated when probing is deferred or the device removed.
> > > 
> > > Yes, that is a problem, but the only way to handle that is to always
> > > recalcuate all resource references at probe time. I don't feel good
> > > about handling that in the core. I'd rather move drivers away from
> > > referencing the resources table directly and instead use an API. Then
> > > the resources table could be missing entirely.
> > 
> > Are you suggesting something like this?
> > 
> > ---
> > 
> > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> > index 3a94b799f166..c894d1af3a5e 100644
> > --- a/drivers/base/platform.c
> > +++ b/drivers/base/platform.c
> > @@ -13,6 +13,7 @@
> >  #include <linux/string.h>
> >  #include <linux/platform_device.h>
> >  #include <linux/of_device.h>
> > +#include <linux/of_irq.h>
> >  #include <linux/module.h>
> >  #include <linux/init.h>
> >  #include <linux/dma-mapping.h>
> > @@ -87,7 +88,12 @@ int platform_get_irq(struct platform_device *dev, unsigned int num)
> >                 return -ENXIO;
> >         return dev->archdata.irqs[num];
> >  #else
> > -       struct resource *r = platform_get_resource(dev, IORESOURCE_IRQ, num);
> > +       struct resource *r;
> > +
> > +       if (IS_ENABLED(CONFIG_OF) && dev->dev.of_node)
> > +               return irq_of_parse_and_map(dev->dev.of_node, num);
> > +
> > +       r = platform_get_resource(dev, IORESOURCE_IRQ, num);
> 
> Yes. Or even more generically we could have a device_get_irq() function:
> 
> int device_get_irq(struct device *dev, unsigned int num)
> {
> 	if (IS_ENABLED(CONFIG_OF) && dev->of_node)
> 		return irq_of_parse_and_map(dev->of_node, num);
> 	/* An ACPI hook could go here */
> 	return 0
> }
> 
> It would be callable by any device driver, and platform_get_irq() could
> call it too.

So how about we make the platform_get_irq() modification for starters,
so that the OMAP issues can be resolved and then turn our attention to
coming up with a more generic approach. If indeed we end up with what
you're proposing we can easily switch platform_get_irq() to use it.

One of the things I'm not so sure about is how to handle other types of
resources, since they'll be somewhat more specific to the type of
device. That's true also for devices other than platform devices. Let's
look at I2C devices for instance. The way to get at the IRQ number is
via the i2c_client->irq member.

device_get_irq() breaks down at that point because unless you want to
add special cases for all sorts of devices you have no way of getting at
the data if it hasn't been instantiated from DT (or ACPI). Actually, all
devices instantiated from platform data will suffer from this if I'm not
mistaken.

If you're saying that the device_get_irq() API should only cover cases
where some sort of firmware interface exists such as DT or ACPI, then I
suppose it could be made to work and drivers could rely on the subsystem
specific locations as fallback. I guess for I2C drivers you'd have to do
something like this:

	err = device_get_irq(&client->dev, 0);
	if (err >= 0)
		client->irq = err;

And then continue to use client->irq as usual. That obviously has the
side-effect of having to do this for every single driver, whereas the
original patches were meant to solve this in the core.

Given enough time we could probably migrate everyone to the new
interfaces, but it certainly is a lot of churn. Perhaps another
alternative would be to unify this some more by making each subsystem
provide special hooks that device_get_irq() and friends can call for
fallback when none of the "firmware" functions were successful.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

[PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Thierry Reding]

On Wed, Dec 11, 2013 at 01:45:53PM +0000, Grant Likely wrote:
> On Thu, 28 Nov 2013 16:46:23 +0100, Thierry Reding <thierry.reding@gmail.com> wrote:
> > On Wed, Nov 27, 2013 at 03:56:29PM +0000, Grant Likely wrote:
> > > On Mon, 25 Nov 2013 10:49:55 +0100, Thierry Reding <thierry.reding@gmail.com> wrote:
> > > > 
> > > > I should maybe add: one issue that was raised during review of my
> > > > initial patch series was that we'll also need to cope with situations
> > > > like the following:
> > > > 
> > > > 	1) device's interrupt parent is probed (assigned IRQ base X)
> > > > 	2) device is probed (interrupt parent there, therefore gets
> > > > 	   assigned IRQ (X + z)
> > > > 	3) device in removed
> > > > 	4) device's interrupt parent is removed
> > > > 	5) device is probed (deferred because interrupt parent isn't
> > > > 	   there)
> > > > 	6) device's interrupt parent is probed (assigned IRQ base Y)
> > > > 	7) device is probed, gets assigned IRQ (Y + z)
> > > > 
> > > > So not only do we have to track which resources are interrupt resources,
> > > > but we also need to have them reassigned everytime the device is probed,
> > > > therefore interrupt mappings need to be properly disposed and the values
> > > > invalidated when probing is deferred or the device removed.
> > > 
> > > Yes, that is a problem, but the only way to handle that is to always
> > > recalcuate all resource references at probe time. I don't feel good
> > > about handling that in the core. I'd rather move drivers away from
> > > referencing the resources table directly and instead use an API. Then
> > > the resources table could be missing entirely.
> > 
> > Are you suggesting something like this?
> > 
> > ---
> > 
> > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> > index 3a94b799f166..c894d1af3a5e 100644
> > --- a/drivers/base/platform.c
> > +++ b/drivers/base/platform.c
> > @@ -13,6 +13,7 @@
> >  #include <linux/string.h>
> >  #include <linux/platform_device.h>
> >  #include <linux/of_device.h>
> > +#include <linux/of_irq.h>
> >  #include <linux/module.h>
> >  #include <linux/init.h>
> >  #include <linux/dma-mapping.h>
> > @@ -87,7 +88,12 @@ int platform_get_irq(struct platform_device *dev, unsigned int num)
> >                 return -ENXIO;
> >         return dev->archdata.irqs[num];
> >  #else
> > -       struct resource *r = platform_get_resource(dev, IORESOURCE_IRQ, num);
> > +       struct resource *r;
> > +
> > +       if (IS_ENABLED(CONFIG_OF) && dev->dev.of_node)
> > +               return irq_of_parse_and_map(dev->dev.of_node, num);
> > +
> > +       r = platform_get_resource(dev, IORESOURCE_IRQ, num);
> 
> Yes. Or even more generically we could have a device_get_irq() function:
> 
> int device_get_irq(struct device *dev, unsigned int num)
> {
> 	if (IS_ENABLED(CONFIG_OF) && dev->of_node)
> 		return irq_of_parse_and_map(dev->of_node, num);
> 	/* An ACPI hook could go here */
> 	return 0
> }
> 
> It would be callable by any device driver, and platform_get_irq() could
> call it too.

So how about we make the platform_get_irq() modification for starters,
so that the OMAP issues can be resolved and then turn our attention to
coming up with a more generic approach. If indeed we end up with what
you're proposing we can easily switch platform_get_irq() to use it.

One of the things I'm not so sure about is how to handle other types of
resources, since they'll be somewhat more specific to the type of
device. That's true also for devices other than platform devices. Let's
look at I2C devices for instance. The way to get at the IRQ number is
via the i2c_client->irq member.

device_get_irq() breaks down at that point because unless you want to
add special cases for all sorts of devices you have no way of getting at
the data if it hasn't been instantiated from DT (or ACPI). Actually, all
devices instantiated from platform data will suffer from this if I'm not
mistaken.

If you're saying that the device_get_irq() API should only cover cases
where some sort of firmware interface exists such as DT or ACPI, then I
suppose it could be made to work and drivers could rely on the subsystem
specific locations as fallback. I guess for I2C drivers you'd have to do
something like this:

	err = device_get_irq(&client->dev, 0);
	if (err >= 0)
		client->irq = err;

And then continue to use client->irq as usual. That obviously has the
side-effect of having to do this for every single driver, whereas the
original patches were meant to solve this in the core.

Given enough time we could probably migrate everyone to the new
interfaces, but it certainly is a lot of churn. Perhaps another
alternative would be to unify this some more by making each subsystem
provide special hooks that device_get_irq() and friends can call for
fallback when none of the "firmware" functions were successful.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131211/cb4c6144/attachment-0001.sig>

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Thierry Reding]

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

On Wed, Dec 11, 2013 at 01:45:53PM +0000, Grant Likely wrote:
> On Thu, 28 Nov 2013 16:46:23 +0100, Thierry Reding <thierry.reding@gmail.com> wrote:
> > On Wed, Nov 27, 2013 at 03:56:29PM +0000, Grant Likely wrote:
> > > On Mon, 25 Nov 2013 10:49:55 +0100, Thierry Reding <thierry.reding@gmail.com> wrote:
> > > > 
> > > > I should maybe add: one issue that was raised during review of my
> > > > initial patch series was that we'll also need to cope with situations
> > > > like the following:
> > > > 
> > > > 	1) device's interrupt parent is probed (assigned IRQ base X)
> > > > 	2) device is probed (interrupt parent there, therefore gets
> > > > 	   assigned IRQ (X + z)
> > > > 	3) device in removed
> > > > 	4) device's interrupt parent is removed
> > > > 	5) device is probed (deferred because interrupt parent isn't
> > > > 	   there)
> > > > 	6) device's interrupt parent is probed (assigned IRQ base Y)
> > > > 	7) device is probed, gets assigned IRQ (Y + z)
> > > > 
> > > > So not only do we have to track which resources are interrupt resources,
> > > > but we also need to have them reassigned everytime the device is probed,
> > > > therefore interrupt mappings need to be properly disposed and the values
> > > > invalidated when probing is deferred or the device removed.
> > > 
> > > Yes, that is a problem, but the only way to handle that is to always
> > > recalcuate all resource references at probe time. I don't feel good
> > > about handling that in the core. I'd rather move drivers away from
> > > referencing the resources table directly and instead use an API. Then
> > > the resources table could be missing entirely.
> > 
> > Are you suggesting something like this?
> > 
> > ---
> > 
> > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> > index 3a94b799f166..c894d1af3a5e 100644
> > --- a/drivers/base/platform.c
> > +++ b/drivers/base/platform.c
> > @@ -13,6 +13,7 @@
> >  #include <linux/string.h>
> >  #include <linux/platform_device.h>
> >  #include <linux/of_device.h>
> > +#include <linux/of_irq.h>
> >  #include <linux/module.h>
> >  #include <linux/init.h>
> >  #include <linux/dma-mapping.h>
> > @@ -87,7 +88,12 @@ int platform_get_irq(struct platform_device *dev, unsigned int num)
> >                 return -ENXIO;
> >         return dev->archdata.irqs[num];
> >  #else
> > -       struct resource *r = platform_get_resource(dev, IORESOURCE_IRQ, num);
> > +       struct resource *r;
> > +
> > +       if (IS_ENABLED(CONFIG_OF) && dev->dev.of_node)
> > +               return irq_of_parse_and_map(dev->dev.of_node, num);
> > +
> > +       r = platform_get_resource(dev, IORESOURCE_IRQ, num);
> 
> Yes. Or even more generically we could have a device_get_irq() function:
> 
> int device_get_irq(struct device *dev, unsigned int num)
> {
> 	if (IS_ENABLED(CONFIG_OF) && dev->of_node)
> 		return irq_of_parse_and_map(dev->of_node, num);
> 	/* An ACPI hook could go here */
> 	return 0
> }
> 
> It would be callable by any device driver, and platform_get_irq() could
> call it too.

So how about we make the platform_get_irq() modification for starters,
so that the OMAP issues can be resolved and then turn our attention to
coming up with a more generic approach. If indeed we end up with what
you're proposing we can easily switch platform_get_irq() to use it.

One of the things I'm not so sure about is how to handle other types of
resources, since they'll be somewhat more specific to the type of
device. That's true also for devices other than platform devices. Let's
look at I2C devices for instance. The way to get at the IRQ number is
via the i2c_client->irq member.

device_get_irq() breaks down at that point because unless you want to
add special cases for all sorts of devices you have no way of getting at
the data if it hasn't been instantiated from DT (or ACPI). Actually, all
devices instantiated from platform data will suffer from this if I'm not
mistaken.

If you're saying that the device_get_irq() API should only cover cases
where some sort of firmware interface exists such as DT or ACPI, then I
suppose it could be made to work and drivers could rely on the subsystem
specific locations as fallback. I guess for I2C drivers you'd have to do
something like this:

	err = device_get_irq(&client->dev, 0);
	if (err >= 0)
		client->irq = err;

And then continue to use client->irq as usual. That obviously has the
side-effect of having to do this for every single driver, whereas the
original patches were meant to solve this in the core.

Given enough time we could probably migrate everyone to the new
interfaces, but it certainly is a lot of churn. Perhaps another
alternative would be to unify this some more by making each subsystem
provide special hooks that device_get_irq() and friends can call for
fallback when none of the "firmware" functions were successful.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Tony Lindgren]

* Thierry Reding <thierry.reding@gmail.com> [131211 07:14]:
> 
> So how about we make the platform_get_irq() modification for starters,
> so that the OMAP issues can be resolved and then turn our attention to
> coming up with a more generic approach. If indeed we end up with what
> you're proposing we can easily switch platform_get_irq() to use it.

Yeah we should do the minimal fix for the $Subject bug for the -rc cycle
so I can fix the PM test regression fix for the few omap3 platforms
already made DT only.
 
> One of the things I'm not so sure about is how to handle other types of
> resources, since they'll be somewhat more specific to the type of
> device. That's true also for devices other than platform devices. Let's
> look at I2C devices for instance. The way to get at the IRQ number is
> via the i2c_client->irq member.

Yes. And BTW, there's also another related glitch where there's no easy
way to configure auxdata from arch/arm/mach code for some devices.

For example, consider something like this that's fairly common:

1. i2c bus driver configured with DT and can take board specific auxdata

2. i2c bus intializes connected devices as configured with DT but
   cannot pass board specific auxdata as the auxdata for the i2c bus
   is empty

3. i2c connected pmic driver intializes as configured with DT, but
   cannot get board specifc auxdata

So we should probably add some parent or master auxdata table that's
also checked if the bus specific auxdata table is empty.
 
> device_get_irq() breaks down at that point because unless you want to
> add special cases for all sorts of devices you have no way of getting at
> the data if it hasn't been instantiated from DT (or ACPI). Actually, all
> devices instantiated from platform data will suffer from this if I'm not
> mistaken.
> 
> If you're saying that the device_get_irq() API should only cover cases
> where some sort of firmware interface exists such as DT or ACPI, then I
> suppose it could be made to work and drivers could rely on the subsystem
> specific locations as fallback. I guess for I2C drivers you'd have to do
> something like this:
> 
> 	err = device_get_irq(&client->dev, 0);
> 	if (err >= 0)
> 		client->irq = err;
> 
> And then continue to use client->irq as usual. That obviously has the
> side-effect of having to do this for every single driver, whereas the
> original patches were meant to solve this in the core.
> 
> Given enough time we could probably migrate everyone to the new
> interfaces, but it certainly is a lot of churn. Perhaps another
> alternative would be to unify this some more by making each subsystem
> provide special hooks that device_get_irq() and friends can call for
> fallback when none of the "firmware" functions were successful.

Ideally of course we'd have Linux generic way of doing this that works
for platform data, DT and ACPI without changing the existing interfaces :)

Regards,

Tony

[PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Tony Lindgren]

* Thierry Reding <thierry.reding@gmail.com> [131211 07:14]:
> 
> So how about we make the platform_get_irq() modification for starters,
> so that the OMAP issues can be resolved and then turn our attention to
> coming up with a more generic approach. If indeed we end up with what
> you're proposing we can easily switch platform_get_irq() to use it.

Yeah we should do the minimal fix for the $Subject bug for the -rc cycle
so I can fix the PM test regression fix for the few omap3 platforms
already made DT only.
 
> One of the things I'm not so sure about is how to handle other types of
> resources, since they'll be somewhat more specific to the type of
> device. That's true also for devices other than platform devices. Let's
> look at I2C devices for instance. The way to get at the IRQ number is
> via the i2c_client->irq member.

Yes. And BTW, there's also another related glitch where there's no easy
way to configure auxdata from arch/arm/mach code for some devices.

For example, consider something like this that's fairly common:

1. i2c bus driver configured with DT and can take board specific auxdata

2. i2c bus intializes connected devices as configured with DT but
   cannot pass board specific auxdata as the auxdata for the i2c bus
   is empty

3. i2c connected pmic driver intializes as configured with DT, but
   cannot get board specifc auxdata

So we should probably add some parent or master auxdata table that's
also checked if the bus specific auxdata table is empty.
 
> device_get_irq() breaks down at that point because unless you want to
> add special cases for all sorts of devices you have no way of getting at
> the data if it hasn't been instantiated from DT (or ACPI). Actually, all
> devices instantiated from platform data will suffer from this if I'm not
> mistaken.
> 
> If you're saying that the device_get_irq() API should only cover cases
> where some sort of firmware interface exists such as DT or ACPI, then I
> suppose it could be made to work and drivers could rely on the subsystem
> specific locations as fallback. I guess for I2C drivers you'd have to do
> something like this:
> 
> 	err = device_get_irq(&client->dev, 0);
> 	if (err >= 0)
> 		client->irq = err;
> 
> And then continue to use client->irq as usual. That obviously has the
> side-effect of having to do this for every single driver, whereas the
> original patches were meant to solve this in the core.
> 
> Given enough time we could probably migrate everyone to the new
> interfaces, but it certainly is a lot of churn. Perhaps another
> alternative would be to unify this some more by making each subsystem
> provide special hooks that device_get_irq() and friends can call for
> fallback when none of the "firmware" functions were successful.

Ideally of course we'd have Linux generic way of doing this that works
for platform data, DT and ACPI without changing the existing interfaces :)

Regards,

Tony

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Grant Likely]

On Mon, 25 Nov 2013 10:25:50 +0100, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Sun, Nov 24, 2013 at 09:36:51PM +0000, Grant Likely wrote:
> > On Fri, 22 Nov 2013 16:43:35 -0800, Tony Lindgren <tony@atomide.com> wrote:
> > > Currently we get the following kind of errors if we try to use
> > > interrupt phandles to irqchips that have not yet initialized:
> > > 
> > > irq: no irq domain found for /ocp/pinmux@48002030 !
> > > WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
> > > Modules linked in:
> > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
> > > (show_stack+0x14/0x1c)
> > > (dump_stack+0x6c/0xa0)
> > > (warn_slowpath_common+0x64/0x84)
> > > (warn_slowpath_null+0x1c/0x24)
> > > (of_device_alloc+0x144/0x184)
> > > (of_platform_device_create_pdata+0x44/0x9c)
> > > (of_platform_bus_create+0xd0/0x170)
> > > (of_platform_bus_create+0x12c/0x170)
> > > (of_platform_populate+0x60/0x98)
> > > ...
> > > 
> > > This is because we're wrongly trying to populate resources that are not
> > > yet available. It's perfectly valid to create irqchips dynamically,
> > > so let's fix up the issue by populating the interrupt resources based
> > > on a notifier call instead.
> > > 
> > > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > > 
> > > ---
> > > 
> > > Rob & Grant, care to merge this for the -rc if this looks OK to you?
> > > 
> > > These happen for example when using interrupts-extended for omap
> > > wake-up interrupts where the irq domain is created by pinctrl-single.c
> > > at module_init time.
> > > 
> > > --- a/drivers/of/platform.c
> > > +++ b/drivers/of/platform.c
> > > @@ -130,6 +130,56 @@ void of_device_make_bus_id(struct device *dev)
> > >  	dev_set_name(dev, "%s.%d", node->name, magic - 1);
> > >  }
> > >  
> > > +/*
> > > + * The device interrupts are not necessarily available for all
> > > + * irqdomains initially so we need to populate them using a
> > > + * notifier.
> > > + */
> > > +static int of_device_resource_notify(struct notifier_block *nb,
> > > +				     unsigned long event, void *dev)
> > > +{
> > > +	struct platform_device *pdev = to_platform_device(dev);
> > > +	struct device_node *np = pdev->dev.of_node;
> > > +	struct resource *res = pdev->resource;
> > > +	struct resource *irqr = NULL;
> > > +	int num_irq, i, found = 0;
> > > +
> > > +	if (event != BUS_NOTIFY_BIND_DRIVER)
> > > +		return 0;
> > > +
> > > +	if (!np)
> > > +		goto out;
> > > +
> > > +	num_irq = of_irq_count(np);
> > > +	if (!num_irq)
> > > +		goto out;
> > > +
> > > +	for (i = 0; i < pdev->num_resources; i++, res++) {
> > > +		if (res->flags != IORESOURCE_IRQ ||
> > > +		    res->start != -EPROBE_DEFER ||
> > > +		    res->end != -EPROBE_DEFER)
> > > +			continue;
> > > +
> > > +		if (!irqr)
> > > +			irqr = res;
> > > +		found++;
> > > +	}
> > > +
> > > +	if (!found)
> > > +		goto out;
> > > +
> > > +	if (found != num_irq) {
> > > +		dev_WARN(dev, "error populating irq resources: %i != %i\n",
> > > +			 found, num_irq);
> > > +		goto out;
> > > +	}
> > > +
> > > +	WARN_ON(of_irq_to_resource_table(np, irqr, num_irq) != num_irq);
> > > +
> > > +out:
> > > +	return NOTIFY_DONE;
> > > +}
> > > +
> > >  /**
> > >   * of_device_alloc - Allocate and initialize an of_device
> > >   * @np: device node to assign to device
> > > @@ -168,7 +218,13 @@ struct platform_device *of_device_alloc(struct device_node *np,
> > >  			rc = of_address_to_resource(np, i, res);
> > >  			WARN_ON(rc);
> > >  		}
> > > -		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
> > > +
> > > +		/* See of_device_resource_notify for populating interrupts */
> > > +		for (i = 0; i < num_irq; i++, res++) {
> > > +			res->flags = IORESOURCE_IRQ;
> > > +			res->start = -EPROBE_DEFER;
> > > +			res->end = -EPROBE_DEFER;
> > > +		}
> > 
> > I actually like the idea of completely allocating the resource structure
> > but leaving some entries empty. However, I agree with rmk that putting
> > garbage into a resource structure is a bad idea. What about changing the
> > value of flags to 0 or some other value to be obviously an empty
> > property and give the follow up parsing some context about which ones it
> > needs to attempt to recalculate?
> 
> When I worked on this a while back I came to the same conclusion. It's
> nice to allocate all the resources at once, because the number of them
> doesn't change, only their actually values.
> 
> However it seems to me like there's no way with the way platform_device
> is currently defined to pass along enough context to allow it to obtain
> the correct set of resources that need to be populated.
> 
> We can't really set flags to 0 because then we loose all information
> about the type of resource, which is the only thing that could remotely
> be used to track interrupt-type resources and recalculate only those. I
> was looking at perhaps modifying the platform_device struct to use a
> different means of storing the resources that would make this easier.
> One possibility would be to add per-type arrays or lists of resources.
> That way we could simply remove the complete list of interrupts and redo
> them each time probing is deferred.

Well, right now the only things in the resource structure (as created by
of_platform_device_create() are registers and interrupts. Registers are
populated first and we know what those are. Interrupts follow. As long
as we can recognize devices created with of_platform_device_create(),
then we can skip over all the address ranges because they get resolved
with no problem. Then all that are left are interrupts, and they are
populated in-order. That gives us a workable solution in the short term.

> However it looks like a whole lot of code currently relies on knowing
> the internals of struct platform_device, so that will likely turn into a
> nightmare patchset. coccinelle could possibly be very helpful here,
> though.
> 
> Perhaps a backwards-compatible way would be to add some fields that keep
> track of where in the single array of struct resource:s the interrupts
> start and then overwrite the values, while at the same time not having
> to reallocate memory all the time. It's slightly hackish and I fear if
> we don't clean up after that we'll run the risk of cluttering up the
> structure eventually.

That would work too.

> I'm wondering if long term (well, really long-term) it might be better
> to move away from platform_device completely, given how various people
> have said that they don't like them and rather have them not exist at
> all. I haven't quite seen anyone explicitly stating why or what an
> alternative would look like, but perhaps someone can educate me.

Platform device is really just fine. Greg hates it, but we use it in
quite a sane way I think. However, I do think we should have a common
way to get resources regardless of the struct device. It should be
platform_get_resource(), but rather firmware_get_resource(device) to get
things like irqs and memory regions.

g.

> > However, I still don't like the notifier approach of actually triggering
> > the fixup. We need something better.
> 
> I don't either. Notifiers are really not suitable for this in my
> opinion. We've had this discussion before in the context of Hiroshi's
> IOMMU patches, and they don't allow errors to be propagated easily. They
> also are a very decentralized way to do things and therefore better
> suited to do things that are really driver-specific. For something that
> every device requires (such as interrupt reference resolution), a change
> to the core seems like a more desirable approach to me.
> 
> Thierry

[PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Grant Likely]

On Mon, 25 Nov 2013 10:25:50 +0100, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Sun, Nov 24, 2013 at 09:36:51PM +0000, Grant Likely wrote:
> > On Fri, 22 Nov 2013 16:43:35 -0800, Tony Lindgren <tony@atomide.com> wrote:
> > > Currently we get the following kind of errors if we try to use
> > > interrupt phandles to irqchips that have not yet initialized:
> > > 
> > > irq: no irq domain found for /ocp/pinmux at 48002030 !
> > > WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
> > > Modules linked in:
> > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
> > > (show_stack+0x14/0x1c)
> > > (dump_stack+0x6c/0xa0)
> > > (warn_slowpath_common+0x64/0x84)
> > > (warn_slowpath_null+0x1c/0x24)
> > > (of_device_alloc+0x144/0x184)
> > > (of_platform_device_create_pdata+0x44/0x9c)
> > > (of_platform_bus_create+0xd0/0x170)
> > > (of_platform_bus_create+0x12c/0x170)
> > > (of_platform_populate+0x60/0x98)
> > > ...
> > > 
> > > This is because we're wrongly trying to populate resources that are not
> > > yet available. It's perfectly valid to create irqchips dynamically,
> > > so let's fix up the issue by populating the interrupt resources based
> > > on a notifier call instead.
> > > 
> > > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > > 
> > > ---
> > > 
> > > Rob & Grant, care to merge this for the -rc if this looks OK to you?
> > > 
> > > These happen for example when using interrupts-extended for omap
> > > wake-up interrupts where the irq domain is created by pinctrl-single.c
> > > at module_init time.
> > > 
> > > --- a/drivers/of/platform.c
> > > +++ b/drivers/of/platform.c
> > > @@ -130,6 +130,56 @@ void of_device_make_bus_id(struct device *dev)
> > >  	dev_set_name(dev, "%s.%d", node->name, magic - 1);
> > >  }
> > >  
> > > +/*
> > > + * The device interrupts are not necessarily available for all
> > > + * irqdomains initially so we need to populate them using a
> > > + * notifier.
> > > + */
> > > +static int of_device_resource_notify(struct notifier_block *nb,
> > > +				     unsigned long event, void *dev)
> > > +{
> > > +	struct platform_device *pdev = to_platform_device(dev);
> > > +	struct device_node *np = pdev->dev.of_node;
> > > +	struct resource *res = pdev->resource;
> > > +	struct resource *irqr = NULL;
> > > +	int num_irq, i, found = 0;
> > > +
> > > +	if (event != BUS_NOTIFY_BIND_DRIVER)
> > > +		return 0;
> > > +
> > > +	if (!np)
> > > +		goto out;
> > > +
> > > +	num_irq = of_irq_count(np);
> > > +	if (!num_irq)
> > > +		goto out;
> > > +
> > > +	for (i = 0; i < pdev->num_resources; i++, res++) {
> > > +		if (res->flags != IORESOURCE_IRQ ||
> > > +		    res->start != -EPROBE_DEFER ||
> > > +		    res->end != -EPROBE_DEFER)
> > > +			continue;
> > > +
> > > +		if (!irqr)
> > > +			irqr = res;
> > > +		found++;
> > > +	}
> > > +
> > > +	if (!found)
> > > +		goto out;
> > > +
> > > +	if (found != num_irq) {
> > > +		dev_WARN(dev, "error populating irq resources: %i != %i\n",
> > > +			 found, num_irq);
> > > +		goto out;
> > > +	}
> > > +
> > > +	WARN_ON(of_irq_to_resource_table(np, irqr, num_irq) != num_irq);
> > > +
> > > +out:
> > > +	return NOTIFY_DONE;
> > > +}
> > > +
> > >  /**
> > >   * of_device_alloc - Allocate and initialize an of_device
> > >   * @np: device node to assign to device
> > > @@ -168,7 +218,13 @@ struct platform_device *of_device_alloc(struct device_node *np,
> > >  			rc = of_address_to_resource(np, i, res);
> > >  			WARN_ON(rc);
> > >  		}
> > > -		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
> > > +
> > > +		/* See of_device_resource_notify for populating interrupts */
> > > +		for (i = 0; i < num_irq; i++, res++) {
> > > +			res->flags = IORESOURCE_IRQ;
> > > +			res->start = -EPROBE_DEFER;
> > > +			res->end = -EPROBE_DEFER;
> > > +		}
> > 
> > I actually like the idea of completely allocating the resource structure
> > but leaving some entries empty. However, I agree with rmk that putting
> > garbage into a resource structure is a bad idea. What about changing the
> > value of flags to 0 or some other value to be obviously an empty
> > property and give the follow up parsing some context about which ones it
> > needs to attempt to recalculate?
> 
> When I worked on this a while back I came to the same conclusion. It's
> nice to allocate all the resources at once, because the number of them
> doesn't change, only their actually values.
> 
> However it seems to me like there's no way with the way platform_device
> is currently defined to pass along enough context to allow it to obtain
> the correct set of resources that need to be populated.
> 
> We can't really set flags to 0 because then we loose all information
> about the type of resource, which is the only thing that could remotely
> be used to track interrupt-type resources and recalculate only those. I
> was looking at perhaps modifying the platform_device struct to use a
> different means of storing the resources that would make this easier.
> One possibility would be to add per-type arrays or lists of resources.
> That way we could simply remove the complete list of interrupts and redo
> them each time probing is deferred.

Well, right now the only things in the resource structure (as created by
of_platform_device_create() are registers and interrupts. Registers are
populated first and we know what those are. Interrupts follow. As long
as we can recognize devices created with of_platform_device_create(),
then we can skip over all the address ranges because they get resolved
with no problem. Then all that are left are interrupts, and they are
populated in-order. That gives us a workable solution in the short term.

> However it looks like a whole lot of code currently relies on knowing
> the internals of struct platform_device, so that will likely turn into a
> nightmare patchset. coccinelle could possibly be very helpful here,
> though.
> 
> Perhaps a backwards-compatible way would be to add some fields that keep
> track of where in the single array of struct resource:s the interrupts
> start and then overwrite the values, while at the same time not having
> to reallocate memory all the time. It's slightly hackish and I fear if
> we don't clean up after that we'll run the risk of cluttering up the
> structure eventually.

That would work too.

> I'm wondering if long term (well, really long-term) it might be better
> to move away from platform_device completely, given how various people
> have said that they don't like them and rather have them not exist at
> all. I haven't quite seen anyone explicitly stating why or what an
> alternative would look like, but perhaps someone can educate me.

Platform device is really just fine. Greg hates it, but we use it in
quite a sane way I think. However, I do think we should have a common
way to get resources regardless of the struct device. It should be
platform_get_resource(), but rather firmware_get_resource(device) to get
things like irqs and memory regions.

g.

> > However, I still don't like the notifier approach of actually triggering
> > the fixup. We need something better.
> 
> I don't either. Notifiers are really not suitable for this in my
> opinion. We've had this discussion before in the context of Hiroshi's
> IOMMU patches, and they don't allow errors to be propagated easily. They
> also are a very decentralized way to do things and therefore better
> suited to do things that are really driver-specific. For something that
> every device requires (such as interrupt reference resolution), a change
> to the core seems like a more desirable approach to me.
> 
> Thierry

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Grant Likely]

On Mon, 25 Nov 2013 10:25:50 +0100, Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Sun, Nov 24, 2013 at 09:36:51PM +0000, Grant Likely wrote:
> > On Fri, 22 Nov 2013 16:43:35 -0800, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> > > Currently we get the following kind of errors if we try to use
> > > interrupt phandles to irqchips that have not yet initialized:
> > > 
> > > irq: no irq domain found for /ocp/pinmux@48002030 !
> > > WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
> > > Modules linked in:
> > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
> > > (show_stack+0x14/0x1c)
> > > (dump_stack+0x6c/0xa0)
> > > (warn_slowpath_common+0x64/0x84)
> > > (warn_slowpath_null+0x1c/0x24)
> > > (of_device_alloc+0x144/0x184)
> > > (of_platform_device_create_pdata+0x44/0x9c)
> > > (of_platform_bus_create+0xd0/0x170)
> > > (of_platform_bus_create+0x12c/0x170)
> > > (of_platform_populate+0x60/0x98)
> > > ...
> > > 
> > > This is because we're wrongly trying to populate resources that are not
> > > yet available. It's perfectly valid to create irqchips dynamically,
> > > so let's fix up the issue by populating the interrupt resources based
> > > on a notifier call instead.
> > > 
> > > Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> > > 
> > > ---
> > > 
> > > Rob & Grant, care to merge this for the -rc if this looks OK to you?
> > > 
> > > These happen for example when using interrupts-extended for omap
> > > wake-up interrupts where the irq domain is created by pinctrl-single.c
> > > at module_init time.
> > > 
> > > --- a/drivers/of/platform.c
> > > +++ b/drivers/of/platform.c
> > > @@ -130,6 +130,56 @@ void of_device_make_bus_id(struct device *dev)
> > >  	dev_set_name(dev, "%s.%d", node->name, magic - 1);
> > >  }
> > >  
> > > +/*
> > > + * The device interrupts are not necessarily available for all
> > > + * irqdomains initially so we need to populate them using a
> > > + * notifier.
> > > + */
> > > +static int of_device_resource_notify(struct notifier_block *nb,
> > > +				     unsigned long event, void *dev)
> > > +{
> > > +	struct platform_device *pdev = to_platform_device(dev);
> > > +	struct device_node *np = pdev->dev.of_node;
> > > +	struct resource *res = pdev->resource;
> > > +	struct resource *irqr = NULL;
> > > +	int num_irq, i, found = 0;
> > > +
> > > +	if (event != BUS_NOTIFY_BIND_DRIVER)
> > > +		return 0;
> > > +
> > > +	if (!np)
> > > +		goto out;
> > > +
> > > +	num_irq = of_irq_count(np);
> > > +	if (!num_irq)
> > > +		goto out;
> > > +
> > > +	for (i = 0; i < pdev->num_resources; i++, res++) {
> > > +		if (res->flags != IORESOURCE_IRQ ||
> > > +		    res->start != -EPROBE_DEFER ||
> > > +		    res->end != -EPROBE_DEFER)
> > > +			continue;
> > > +
> > > +		if (!irqr)
> > > +			irqr = res;
> > > +		found++;
> > > +	}
> > > +
> > > +	if (!found)
> > > +		goto out;
> > > +
> > > +	if (found != num_irq) {
> > > +		dev_WARN(dev, "error populating irq resources: %i != %i\n",
> > > +			 found, num_irq);
> > > +		goto out;
> > > +	}
> > > +
> > > +	WARN_ON(of_irq_to_resource_table(np, irqr, num_irq) != num_irq);
> > > +
> > > +out:
> > > +	return NOTIFY_DONE;
> > > +}
> > > +
> > >  /**
> > >   * of_device_alloc - Allocate and initialize an of_device
> > >   * @np: device node to assign to device
> > > @@ -168,7 +218,13 @@ struct platform_device *of_device_alloc(struct device_node *np,
> > >  			rc = of_address_to_resource(np, i, res);
> > >  			WARN_ON(rc);
> > >  		}
> > > -		WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
> > > +
> > > +		/* See of_device_resource_notify for populating interrupts */
> > > +		for (i = 0; i < num_irq; i++, res++) {
> > > +			res->flags = IORESOURCE_IRQ;
> > > +			res->start = -EPROBE_DEFER;
> > > +			res->end = -EPROBE_DEFER;
> > > +		}
> > 
> > I actually like the idea of completely allocating the resource structure
> > but leaving some entries empty. However, I agree with rmk that putting
> > garbage into a resource structure is a bad idea. What about changing the
> > value of flags to 0 or some other value to be obviously an empty
> > property and give the follow up parsing some context about which ones it
> > needs to attempt to recalculate?
> 
> When I worked on this a while back I came to the same conclusion. It's
> nice to allocate all the resources at once, because the number of them
> doesn't change, only their actually values.
> 
> However it seems to me like there's no way with the way platform_device
> is currently defined to pass along enough context to allow it to obtain
> the correct set of resources that need to be populated.
> 
> We can't really set flags to 0 because then we loose all information
> about the type of resource, which is the only thing that could remotely
> be used to track interrupt-type resources and recalculate only those. I
> was looking at perhaps modifying the platform_device struct to use a
> different means of storing the resources that would make this easier.
> One possibility would be to add per-type arrays or lists of resources.
> That way we could simply remove the complete list of interrupts and redo
> them each time probing is deferred.

Well, right now the only things in the resource structure (as created by
of_platform_device_create() are registers and interrupts. Registers are
populated first and we know what those are. Interrupts follow. As long
as we can recognize devices created with of_platform_device_create(),
then we can skip over all the address ranges because they get resolved
with no problem. Then all that are left are interrupts, and they are
populated in-order. That gives us a workable solution in the short term.

> However it looks like a whole lot of code currently relies on knowing
> the internals of struct platform_device, so that will likely turn into a
> nightmare patchset. coccinelle could possibly be very helpful here,
> though.
> 
> Perhaps a backwards-compatible way would be to add some fields that keep
> track of where in the single array of struct resource:s the interrupts
> start and then overwrite the values, while at the same time not having
> to reallocate memory all the time. It's slightly hackish and I fear if
> we don't clean up after that we'll run the risk of cluttering up the
> structure eventually.

That would work too.

> I'm wondering if long term (well, really long-term) it might be better
> to move away from platform_device completely, given how various people
> have said that they don't like them and rather have them not exist at
> all. I haven't quite seen anyone explicitly stating why or what an
> alternative would look like, but perhaps someone can educate me.

Platform device is really just fine. Greg hates it, but we use it in
quite a sane way I think. However, I do think we should have a common
way to get resources regardless of the struct device. It should be
platform_get_resource(), but rather firmware_get_resource(device) to get
things like irqs and memory regions.

g.

> > However, I still don't like the notifier approach of actually triggering
> > the fixup. We need something better.
> 
> I don't either. Notifiers are really not suitable for this in my
> opinion. We've had this discussion before in the context of Hiroshi's
> IOMMU patches, and they don't allow errors to be propagated easily. They
> also are a very decentralized way to do things and therefore better
> suited to do things that are really driver-specific. For something that
> every device requires (such as interrupt reference resolution), a change
> to the core seems like a more desirable approach to me.
> 
> Thierry

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Tony Lindgren]

* Grant Likely <grant.likely@linaro.org> [131124 13:37]:
> 
> I actually like the idea of completely allocating the resource structure
> but leaving some entries empty. However, I agree with rmk that putting
> garbage into a resource structure is a bad idea. What about changing the
> value of flags to 0 or some other value to be obviously an empty
> property and give the follow up parsing some context about which ones it
> needs to attempt to recalculate?

If we want to play it safe, we should probably introduce something like
this to ioport.h:

+#define IORESOURCE_IRQ_DEFERRED	(1<<6)

Then we can populate IRQ resources initially with that. And later on
during the driver probe, we know it's safe to populate the resource
if res->flags & IORESOURCE_IRQ_DEFERRED.

That fixes the $Subject bug, and gets us a little bit further for
making more changes later on.

Regards,

Tony

[PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Tony Lindgren]

* Grant Likely <grant.likely@linaro.org> [131124 13:37]:
> 
> I actually like the idea of completely allocating the resource structure
> but leaving some entries empty. However, I agree with rmk that putting
> garbage into a resource structure is a bad idea. What about changing the
> value of flags to 0 or some other value to be obviously an empty
> property and give the follow up parsing some context about which ones it
> needs to attempt to recalculate?

If we want to play it safe, we should probably introduce something like
this to ioport.h:

+#define IORESOURCE_IRQ_DEFERRED	(1<<6)

Then we can populate IRQ resources initially with that. And later on
during the driver probe, we know it's safe to populate the resource
if res->flags & IORESOURCE_IRQ_DEFERRED.

That fixes the $Subject bug, and gets us a little bit further for
making more changes later on.

Regards,

Tony

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Tony Lindgren]

* Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> [131124 13:37]:
> 
> I actually like the idea of completely allocating the resource structure
> but leaving some entries empty. However, I agree with rmk that putting
> garbage into a resource structure is a bad idea. What about changing the
> value of flags to 0 or some other value to be obviously an empty
> property and give the follow up parsing some context about which ones it
> needs to attempt to recalculate?

If we want to play it safe, we should probably introduce something like
this to ioport.h:

+#define IORESOURCE_IRQ_DEFERRED	(1<<6)

Then we can populate IRQ resources initially with that. And later on
during the driver probe, we know it's safe to populate the resource
if res->flags & IORESOURCE_IRQ_DEFERRED.

That fixes the $Subject bug, and gets us a little bit further for
making more changes later on.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html