Make deferring probe forever optional

Subsystems or drivers may opt-in to this behavior by calling driver_deferred_probe_check_init_done() instead of just returning -EPROBE_DEFER. They may use additional information from DT or kernel's config to decide whether to continue to defer probe or not.

Quoted 4 lines · Rob Herring

Subsystems or drivers may opt-in to this behavior by calling driver_deferred_probe_check_init_done() instead of just returning -EPROBE_DEFER. They may use additional information from DT or kernel's config to decide whether to continue to defer probe or not.

Should userspace have some involvement in this decision? It knows if it's got any intention of loading modules for example. Kernel config checks might be good enough, though it's going to be a pain to work out if the relevant driver is built as a module for example.

Quoted 4 lines · Rob Herring

Subsystems or drivers may opt-in to this behavior by calling driver_deferred_probe_check_init_done() instead of just returning -EPROBE_DEFER. They may use additional information from DT or kernel's config to decide whether to continue to defer probe or not.

Should userspace have some involvement in this decision? It knows if it's got any intention of loading modules for example. Kernel config checks might be good enough, though it's going to be a pain to work out if the relevant driver is built as a module for example.

Quoted 4 lines · Rob Herring

Subsystems or drivers may opt-in to this behavior by calling driver_deferred_probe_check_init_done() instead of just returning -EPROBE_DEFER. They may use additional information from DT or kernel's config to decide whether to continue to defer probe or not.

Should userspace have some involvement in this decision? It knows if it's got any intention of loading modules for example. Kernel config checks might be good enough, though it's going to be a pain to work out if the relevant driver is built as a module for example.

Quoted 7 lines · Mark Brown

Quoted 4 lines · Rob Herring

Subsystems or drivers may opt-in to this behavior by calling driver_deferred_probe_check_init_done() instead of just returning -EPROBE_DEFER. They may use additional information from DT or kernel's config to decide whether to continue to defer probe or not.

Quoted 5 lines

Should userspace have some involvement in this decision? It knows if it's got any intention of loading modules for example. Kernel config checks might be good enough, though it's going to be a pain to work out if the relevant driver is built as a module for example.

A parallel issue is that loading an overlay could provide the resource that will allow the deferred probe to complete. (That is, once we finish implementing the run time overlays feature.)

Deferred probe will currently wait forever on dependent devices to probe, but sometimes a driver will never exist. It's also not always critical for a driver to exist. Platforms can rely on default configuration from the bootloader or reset defaults for things such as pinctrl and power domains. This is often the case with initial platform support until various drivers get enabled. There's at least 2 scenarios where deferred probe can render a platform broken. Both involve using a DT which has more devices and dependencies than the kernel supports. The 1st case is a driver may be disabled in the kernel config. The 2nd case is the kernel version may simply not have the dependent driver. This can happen if using a newer DT (provided by firmware perhaps) with a stable kernel version.

Subsystems or drivers may opt-in to this behavior by calling driver_deferred_probe_check_init_done() instead of just returning -EPROBE_DEFER. They may use additional information from DT or kernel's config to decide whether to continue to defer probe or not.

Cc Alexander Graf <[email protected]>

Signed-off-by Rob Herring <[email protected]>

---
 drivers/base/dd.c      | 17 +++++++++++++++++
 include/linux/device.h |  2 ++
 2 files changed, 19 insertions(+)

drivers/base/dd.c +0 -0

index c9f54089429b..d6034718da6f 100644

Quoted 32 lines · Rob Herring

Deferred probe will currently wait forever on dependent devices to probe, but sometimes a driver will never exist. It's also not always critical for a driver to exist. Platforms can rely on default configuration from the bootloader or reset defaults for things such as pinctrl and power domains. This is often the case with initial platform support until various drivers get enabled. There's at least 2 scenarios where deferred probe can render a platform broken. Both involve using a DT which has more devices and dependencies than the kernel supports. The 1st case is a driver may be disabled in the kernel config. The 2nd case is the kernel version may simply not have the dependent driver. This can happen if using a newer DT (provided by firmware perhaps) with a stable kernel version.

Subsystems or drivers may opt-in to this behavior by calling driver_deferred_probe_check_init_done() instead of just returning -EPROBE_DEFER. They may use additional information from DT or kernel's config to decide whether to continue to defer probe or not.

Cc Alexander Graf <[email protected]>

Signed-off-by Rob Herring <[email protected]>

---
 drivers/base/dd.c      | 17 +++++++++++++++++
 include/linux/device.h |  2 ++
 2 files changed, 19 insertions(+)

drivers/base/dd.c +0 -0

index c9f54089429b..d6034718da6f 100644
@@ -226,6 +226,16 @@ void device_unblock_probing(void)
      driver_deferred_probe_trigger();
 }
 

drivers/base/dd.c void device_unblock_probing(void) · line 232

Quoted 4 lines

drivers/base/dd.c +4 -0

+int driver_deferred_probe_check_init_done(struct device *dev, bool optional)
+{
+     if (optional && initcalls_done) {
+             dev_WARN(dev, "ignoring dependency for device, assuming no driver");

You really only need dev_warn(), here, right?

Deferred probe will currently wait forever on dependent devices to probe, but sometimes a driver will never exist. It's also not always critical for a driver to exist. Platforms can rely on default configuration from the bootloader or reset defaults for things such as pinctrl and power domains. This is often the case with initial platform support until various drivers get enabled. There's at least 2 scenarios where deferred probe can render a platform broken. Both involve using a DT which has more devices and dependencies than the kernel supports. The 1st case is a driver may be disabled in the kernel config. The 2nd case is the kernel version may simply not have the dependent driver. This can happen if using a newer DT (provided by firmware perhaps) with a stable kernel version.

Subsystems or drivers may opt-in to this behavior by calling driver_deferred_probe_check_init_done() instead of just returning -EPROBE_DEFER. They may use additional information from DT or kernel's config to decide whether to continue to defer probe or not.

Cc Alexander Graf <[email protected]>

Signed-off-by Rob Herring <[email protected]>

---
 drivers/base/dd.c      | 17 +++++++++++++++++
 include/linux/device.h |  2 ++
 2 files changed, 19 insertions(+)

drivers/base/dd.c +0 -0

index c9f54089429b..d6034718da6f 100644

Quoted 32 lines · Rob Herring

Deferred probe will currently wait forever on dependent devices to probe, but sometimes a driver will never exist. It's also not always critical for a driver to exist. Platforms can rely on default configuration from the bootloader or reset defaults for things such as pinctrl and power domains. This is often the case with initial platform support until various drivers get enabled. There's at least 2 scenarios where deferred probe can render a platform broken. Both involve using a DT which has more devices and dependencies than the kernel supports. The 1st case is a driver may be disabled in the kernel config. The 2nd case is the kernel version may simply not have the dependent driver. This can happen if using a newer DT (provided by firmware perhaps) with a stable kernel version.

Subsystems or drivers may opt-in to this behavior by calling driver_deferred_probe_check_init_done() instead of just returning -EPROBE_DEFER. They may use additional information from DT or kernel's config to decide whether to continue to defer probe or not.

Cc Alexander Graf <[email protected]>

Signed-off-by Rob Herring <[email protected]>

---
 drivers/base/dd.c      | 17 +++++++++++++++++
 include/linux/device.h |  2 ++
 2 files changed, 19 insertions(+)

drivers/base/dd.c +0 -0

index c9f54089429b..d6034718da6f 100644
@@ -226,6 +226,16 @@ void device_unblock_probing(void)
      driver_deferred_probe_trigger();
 }
 

drivers/base/dd.c void device_unblock_probing(void) · line 231

Quoted 3 lines

drivers/base/dd.c +3 -0

+int driver_deferred_probe_check_init_done(struct device *dev, bool optional)
+{
+     if (optional && initcalls_done) {

Wait, what's the "optional" mess here?

The caller knows this value, so why do you need to even pass it in here?

And bool values that are not obvious are horrid. I had to go look this up when reading the later patches that just passed "true" in this variable as I had no idea what that meant.

So as-is, no, this isn't ok, sorry.

And at the least, this needs some kerneldoc to explain it :)

Quoted 33 lines · Greg Kroah-Hartman

Quoted 32 lines · Rob Herring

Deferred probe will currently wait forever on dependent devices to probe, but sometimes a driver will never exist. It's also not always critical for a driver to exist. Platforms can rely on default configuration from the bootloader or reset defaults for things such as pinctrl and power domains. This is often the case with initial platform support until various drivers get enabled. There's at least 2 scenarios where deferred probe can render a platform broken. Both involve using a DT which has more devices and dependencies than the kernel supports. The 1st case is a driver may be disabled in the kernel config. The 2nd case is the kernel version may simply not have the dependent driver. This can happen if using a newer DT (provided by firmware perhaps) with a stable kernel version.

Subsystems or drivers may opt-in to this behavior by calling driver_deferred_probe_check_init_done() instead of just returning -EPROBE_DEFER. They may use additional information from DT or kernel's config to decide whether to continue to defer probe or not.

Cc Alexander Graf <[email protected]>

Signed-off-by Rob Herring <[email protected]>

---
  drivers/base/dd.c      | 17 +++++++++++++++++
  include/linux/device.h |  2 ++
  2 files changed, 19 insertions(+)

drivers/base/dd.c +0 -0

index c9f54089429b..d6034718da6f 100644
@@ -226,6 +226,16 @@ void device_unblock_probing(void)
       driver_deferred_probe_trigger();
  }
 

Quoted 5 lines

drivers/base/dd.c void device_unblock_probing(void) · line 231

Quoted 3 lines

drivers/base/dd.c +3 -0

+int driver_deferred_probe_check_init_done(struct device *dev, bool optional)
+{
+     if (optional && initcalls_done) {

Wait, what's the "optional" mess here?

My intent was that subsystems just always call this function and never return EPROBE_DEFER themselves. Then the driver core can make decisions as to what to do (such as the timeout added in the next patch). Or it can print common error/debug messages. So optional is a hint to allow subsystems per device control.

Quoted 2 lines

The caller knows this value, so why do you need to even pass it in here?

Because regardless of the value, we always stop deferring when/if we hit the timeout and the caller doesn't know about the timeout. If we get rid of it, we'd need functions for both init done and for deferred timeout.

Quoted 3 lines

And bool values that are not obvious are horrid. I had to go look this up when reading the later patches that just passed "true" in this variable as I had no idea what that meant.

Perhaps inverting it and calling it "keep_deferring" would be better. However, the flag is ignored if we have timed out.

Quoted 4 lines

So as-is, no, this isn't ok, sorry.

And at the least, this needs some kerneldoc to explain it :)

That part is easy enough to fix.

Rob

Quoted 53 lines · Rob Herring

Quoted 41 lines · Greg Kroah-Hartman

Quoted 39 lines · Rob Herring

Deferred probe will currently wait forever on dependent devices to probe,
but sometimes a driver will never exist. It's also not always critical for
a driver to exist. Platforms can rely on default configuration from the bootloader or reset defaults for things such as pinctrl and power domains.
This is often the case with initial platform support until various drivers
get enabled. There's at least 2 scenarios where deferred probe can render
a platform broken. Both involve using a DT which has more devices and dependencies than the kernel supports. The 1st case is a driver may be disabled in the kernel config. The 2nd case is the kernel version may simply not have the dependent driver. This can happen if using a newer DT
(provided by firmware perhaps) with a stable kernel version.

Subsystems or drivers may opt-in to this behavior by calling driver_deferred_probe_check_init_done() instead of just returning -EPROBE_DEFER. They may use additional information from DT or kernel's config to decide whether to continue to defer probe or not.

Cc Alexander Graf <[email protected]>

Signed-off-by Rob Herring <[email protected]>

---
  drivers/base/dd.c      | 17 +++++++++++++++++
  include/linux/device.h |  2 ++
  2 files changed, 19 insertions(+)

drivers/base/dd.c +0 -0

index c9f54089429b..d6034718da6f 100644
@@ -226,6 +226,16 @@ void device_unblock_probing(void)
       driver_deferred_probe_trigger();
  }
 

Quoted 7 lines

drivers/base/dd.c void device_unblock_probing(void) · line 231

Quoted 4 lines

drivers/base/dd.c +3 -0

+int driver_deferred_probe_check_init_done(struct device *dev, bool
 optional)
+{
+     if (optional && initcalls_done) {

Wait, what's the "optional" mess here?

Quoted 5 lines

My intent was that subsystems just always call this function and never return EPROBE_DEFER themselves. Then the driver core can make decisions as to what to do (such as the timeout added in the next patch). Or it can print common error/debug messages. So optional is a hint to allow subsystems per device control.

Maybe just driver_defer_probe() might be a more descriptive name? To me, calling "foo_check_x()" with a parameter that says "I don't actually care about x" is the really unintuitive bit.

Quoted 14 lines

Quoted 2 lines

The caller knows this value, so why do you need to even pass it in here?

Because regardless of the value, we always stop deferring when/if we hit the timeout and the caller doesn't know about the timeout. If we get rid of it, we'd need functions for both init done and for deferred timeout.

Quoted 3 lines

And bool values that are not obvious are horrid. I had to go look this up when reading the later patches that just passed "true" in this variable as I had no idea what that meant.

Quoted 2 lines

Perhaps inverting it and calling it "keep_deferring" would be better. However, the flag is ignored if we have timed out.

Perhaps an enum (or bitmask of named flags) then? That would allow the most readability at callsites, plus it seems quite likely that we may want intermediate degrees of "deferral strictness" eventually.

Deferred probe will currently wait forever on dependent devices to probe, but sometimes a driver will never exist. It's also not always critical for a driver to exist. Platforms can rely on default configuration from the bootloader or reset defaults for things such as pinctrl and power domains. This is often the case with initial platform support until various drivers get enabled. There's at least 2 scenarios where deferred probe can render a platform broken. Both involve using a DT which has more devices and dependencies than the kernel supports. The 1st case is a driver may be disabled in the kernel config. The 2nd case is the kernel version may simply not have the dependent driver. This can happen if using a newer DT (provided by firmware perhaps) with a stable kernel version.

Subsystems or drivers may opt-in to this behavior by calling driver_deferred_probe_check_init_done() instead of just returning -EPROBE_DEFER. They may use additional information from DT or kernel's config to decide whether to continue to defer probe or not.

Cc Alexander Graf <[email protected]>

Signed-off-by Rob Herring <[email protected]>

---
 drivers/base/dd.c      | 17 +++++++++++++++++
 include/linux/device.h |  2 ++
 2 files changed, 19 insertions(+)

drivers/base/dd.c +17 -0

index c9f54089429b..d6034718da6f 100644
@@ -226,6 +226,16 @@ void device_unblock_probing(void)
 	driver_deferred_probe_trigger();
 }
 
+int driver_deferred_probe_check_init_done(struct device *dev, bool optional)
+{
+	if (optional && initcalls_done) {
+		dev_WARN(dev, "ignoring dependency for device, assuming no driver");
+		return -ENODEV;
+	}
+
+	return -EPROBE_DEFER;
+}
+
 /**
  * deferred_probe_initcall() - Enable probing of deferred devices
  *

@@ -240,6 +250,13 @@ static int deferred_probe_initcall(void)
 	/* Sort as many dependencies as possible before exiting initcalls */
 	flush_work(&deferred_probe_work);
 	initcalls_done = true;
+
+	/*
+	 * Trigger deferred probe again, this time we won't defer anything
+	 * that is optional
+	 */
+	driver_deferred_probe_trigger();
+	flush_work(&deferred_probe_work);
 	return 0;
 }
 late_initcall(deferred_probe_initcall);

include/linux/device.h +2 -0

index 477956990f5e..f3dafd44c285 100644
@@ -334,6 +334,8 @@ struct device *driver_find_device(struct device_driver *drv,
 				  struct device *start, void *data,
 				  int (*match)(struct device *dev, void *data));
 
+int driver_deferred_probe_check_init_done(struct device *dev, bool optional);
+
 /**
  * struct subsys_interface - interfaces to device functions
  * @name:       name of the device function

Signature · 1 line

2.17.0

Quoted 12 lines · Rob Herring

Deferred probe will currently wait forever on dependent devices to probe, but sometimes a driver will never exist. It's also not always critical for a driver to exist. Platforms can rely on default configuration from the bootloader or reset defaults for things such as pinctrl and power domains. This is often the case with initial platform support until various drivers get enabled. There's at least 2 scenarios where deferred probe can render a platform broken. Both involve using a DT which has more devices and dependencies than the kernel supports. The 1st case is a driver may be disabled in the kernel config. The 2nd case is the kernel version may simply not have the dependent driver. This can happen if using a newer DT (provided by firmware perhaps) with a stable kernel version.

Quoted 5 lines

Subsystems or drivers may opt-in to this behavior by calling driver_deferred_probe_check_init_done() instead of just returning -EPROBE_DEFER. They may use additional information from DT or kernel's config to decide whether to continue to defer probe or not.

For builtin drivers this still looks reasonable.

But I would like to have an additional clarification here stating that drivers that might be targeted by this query must not be compiled as modules.

And I would prefer to see an ack from e.g. Arnd that arm-soc is okay that we drop "tristate" on drivers affected by this; e.g. if we put this in the pinctrl core then all pinctrl drivers should be "bool" and so should any i2c, ssbi and spmi buses and drivers be.

Regards,
Bjorn

Quoted 58 lines

Cc Alexander Graf <[email protected]>

Signed-off-by Rob Herring <[email protected]>

---
 drivers/base/dd.c      | 17 +++++++++++++++++
 include/linux/device.h |  2 ++
 2 files changed, 19 insertions(+)

drivers/base/dd.c +17 -0

index c9f54089429b..d6034718da6f 100644
@@ -226,6 +226,16 @@ void device_unblock_probing(void)
      driver_deferred_probe_trigger();
 }
 
+int driver_deferred_probe_check_init_done(struct device *dev, bool optional)
+{
+     if (optional && initcalls_done) {
+             dev_WARN(dev, "ignoring dependency for device, assuming no driver");
+             return -ENODEV;
+     }
+
+     return -EPROBE_DEFER;
+}
+
 /**
  * deferred_probe_initcall() - Enable probing of deferred devices
  *

@@ -240,6 +250,13 @@ static int deferred_probe_initcall(void)
      /* Sort as many dependencies as possible before exiting initcalls */
      flush_work(&deferred_probe_work);
      initcalls_done = true;
+
+     /*
+      * Trigger deferred probe again, this time we won't defer anything
+      * that is optional
+      */
+     driver_deferred_probe_trigger();
+     flush_work(&deferred_probe_work);
      return 0;
 }
 late_initcall(deferred_probe_initcall);

include/linux/device.h +2 -1

index 477956990f5e..f3dafd44c285 100644
@@ -334,6 +334,8 @@ struct device *driver_find_device(struct device_driver *drv,
                                struct device *start, void *data,
                                int (*match)(struct device *dev, void *data));
 
+int driver_deferred_probe_check_init_done(struct device *dev, bool optional);
+
 /**
  * struct subsys_interface - interfaces to device functions
  * @name:       name of the device function
--

2.17.0

Deferring probe can wait forever on dependencies that may never appear for a variety of reasons. This can be difficult to debug especially if the console has dependencies or userspace fails to boot to a shell. Add a timeout to retry probing without possibly optional dependencies and to dump out the deferred probe pending list after retrying.

This mechanism is intended for debug purposes. It won't work for the console which needs to be enabled before userspace starts. However, if the console's dependencies are resolved, then the kernel log will be printed (as opposed to no output).

Signed-off-by Rob Herring <[email protected]>

---
 .../admin-guide/kernel-parameters.txt         |  7 +++++
 drivers/base/dd.c                             | 28 ++++++++++++++++++-
 2 files changed, 34 insertions(+), 1 deletion(-)

Documentation/admin-guide/kernel-parameters.txt +0 -0

index 11fc28ecdb6d..dd3f40b34a24 100644

Quoted 25 lines · Rob Herring

Deferring probe can wait forever on dependencies that may never appear for a variety of reasons. This can be difficult to debug especially if the console has dependencies or userspace fails to boot to a shell. Add a timeout to retry probing without possibly optional dependencies and to dump out the deferred probe pending list after retrying.

This mechanism is intended for debug purposes. It won't work for the console which needs to be enabled before userspace starts. However, if the console's dependencies are resolved, then the kernel log will be printed (as opposed to no output).

Signed-off-by Rob Herring <[email protected]>

---
 .../admin-guide/kernel-parameters.txt         |  7 +++++
 drivers/base/dd.c                             | 28 ++++++++++++++++++-
 2 files changed, 34 insertions(+), 1 deletion(-)

Documentation/admin-guide/kernel-parameters.txt +0 -0

index 11fc28ecdb6d..dd3f40b34a24 100644
@@ -809,6 +809,13 @@
                      Defaults to the default architecture's huge page size
                      if not specified.
 

Documentation/admin-guide/kernel-parameters.txt line 817

Quoted 6 lines

Documentation/admin-guide/kernel-parameters.txt +6 -0

+     deferred_probe_timeout=
+                     [KNL] Set a timeout in seconds for deferred probe to
+                     give up waiting on dependencies to probe. Only specific
+                     dependencies (subsystems or drivers) that have opted in
+                     will be ignored. This option also dumps out devices
+                     still on the deferred probe list after retrying.

Doesn't sound like a debugging-only option. I can see devices enabling this when they figure out that's the only way their platform can boot :)

Quoted 26 lines · Greg Kroah-Hartman

Quoted 25 lines · Rob Herring

Deferring probe can wait forever on dependencies that may never appear for a variety of reasons. This can be difficult to debug especially if the console has dependencies or userspace fails to boot to a shell. Add a timeout to retry probing without possibly optional dependencies and to dump out the deferred probe pending list after retrying.

This mechanism is intended for debug purposes. It won't work for the console which needs to be enabled before userspace starts. However, if the console's dependencies are resolved, then the kernel log will be printed (as opposed to no output).

Signed-off-by Rob Herring <[email protected]>

---
 .../admin-guide/kernel-parameters.txt         |  7 +++++
 drivers/base/dd.c                             | 28 ++++++++++++++++++-
 2 files changed, 34 insertions(+), 1 deletion(-)

Documentation/admin-guide/kernel-parameters.txt +0 -0

index 11fc28ecdb6d..dd3f40b34a24 100644
@@ -809,6 +809,13 @@
                      Defaults to the default architecture's huge page size
                      if not specified.
 

Quoted 9 lines

Documentation/admin-guide/kernel-parameters.txt line 817

Quoted 6 lines

Documentation/admin-guide/kernel-parameters.txt +6 -0

+     deferred_probe_timeout=
+                     [KNL] Set a timeout in seconds for deferred probe to
+                     give up waiting on dependencies to probe. Only specific
+                     dependencies (subsystems or drivers) that have opted in
+                     will be ignored. This option also dumps out devices
+                     still on the deferred probe list after retrying.

Doesn't sound like a debugging-only option. I can see devices enabling this when they figure out that's the only way their platform can boot :)

Here's some rope...

No doubt it can be abused. So are you saying don't call it a debug option or hide it behind a config option? And for the latter, what's one that distros don't just turn on?

If the pinctrl node in DT indicates that pin setup is optional and the defaults can be used with the 'pinctrl-use-default', then only defer probe until initcalls are done. This gives platforms the option to work without their pinctrl driver being enabled.

Signed-off-by Rob Herring <[email protected]>

Now that we use the driver core to stop deferred probe for missing drivers, IOMMU_OF_DECLARE can be removed.

This is slightly less optimal than having a list of built-in drivers in that we'll now defer probe twice before giving up. This shouldn't have a significant impact on boot times as past discussions about deferred probe have given no evidence of deferred probe having a substantial impact.

Cc Will Deacon <[email protected]>

Cc Robin Murphy <[email protected]>

Cc Joerg Roedel <[email protected]>

Cc Marek Szyprowski <[email protected]>

Cc Kukjin Kim <[email protected]>

Cc Krzysztof Kozlowski <[email protected]>

Cc Rob Clark <[email protected]>

Cc Heiko Stuebner <[email protected]>

Cc Frank Rowand <[email protected]>

Cc [email protected]

Cc [email protected]

Cc [email protected]

Cc [email protected]

Cc [email protected]

Cc [email protected]

Signed-off-by Rob Herring <[email protected]>

---
 drivers/iommu/arm-smmu-v3.c    |  2 --
 drivers/iommu/arm-smmu.c       |  7 -------
 drivers/iommu/exynos-iommu.c   |  2 --
 drivers/iommu/ipmmu-vmsa.c     |  3 ---
 drivers/iommu/msm_iommu.c      |  2 --
 drivers/iommu/of_iommu.c       | 19 +------------------
 drivers/iommu/qcom_iommu.c     |  2 --
 drivers/iommu/rockchip-iommu.c |  2 --
 include/linux/of_iommu.h       |  4 ----
 9 files changed, 1 insertion(+), 42 deletions(-)

drivers/iommu/arm-smmu-v3.c +0 -2

index 1d647104bccc..22bdabd3d8e0 100644
@@ -2915,8 +2915,6 @@ static struct platform_driver arm_smmu_driver = {
 };
 module_platform_driver(arm_smmu_driver);
 
-IOMMU_OF_DECLARE(arm_smmuv3, "arm,smmu-v3");
-
 MODULE_DESCRIPTION("IOMMU API for ARM architected SMMUv3 implementations");
 MODULE_AUTHOR("Will Deacon <[email protected]>");
 MODULE_LICENSE("GPL v2");

drivers/iommu/arm-smmu.c +0 -0

index 69e7c60792a8..9dd7cbaa3b0c 100644
@@ -2211,13 +2211,6 @@ static struct platform_driver arm_smmu_driver = {
 };
 module_platform_driver(arm_smmu_driver);
 

Now that we use the driver core to stop deferred probe for missing drivers, IOMMU_OF_DECLARE can be removed.

This is slightly less optimal than having a list of built-in drivers in that we'll now defer probe twice before giving up. This shouldn't have a significant impact on boot times as past discussions about deferred probe have given no evidence of deferred probe having a substantial impact.

Cc Will Deacon <[email protected]>

Cc Robin Murphy <[email protected]>

Cc Joerg Roedel <[email protected]>

Cc Marek Szyprowski <[email protected]>

Cc Kukjin Kim <[email protected]>

Cc Krzysztof Kozlowski <[email protected]>

Cc Rob Clark <[email protected]>

Cc Heiko Stuebner <[email protected]>

Cc Frank Rowand <[email protected]>

Cc linux-arm-kernel at lists.infradead.org

Cc iommu at lists.linux-foundation.org

Cc linux-samsung-soc at vger.kernel.org

Cc linux-arm-msm at vger.kernel.org

Cc linux-rockchip at lists.infradead.org

Cc devicetree at vger.kernel.org

Signed-off-by Rob Herring <[email protected]>

---
  drivers/iommu/arm-smmu-v3.c    |  2 --
  drivers/iommu/arm-smmu.c       |  7 -------
  drivers/iommu/exynos-iommu.c   |  2 --
  drivers/iommu/ipmmu-vmsa.c     |  3 ---
  drivers/iommu/msm_iommu.c      |  2 --
  drivers/iommu/of_iommu.c       | 19 +------------------
  drivers/iommu/qcom_iommu.c     |  2 --
  drivers/iommu/rockchip-iommu.c |  2 --
  include/linux/of_iommu.h       |  4 ----
  9 files changed, 1 insertion(+), 42 deletions(-)

drivers/iommu/arm-smmu-v3.c +0 -2

index 1d647104bccc..22bdabd3d8e0 100644
@@ -2915,8 +2915,6 @@ static struct platform_driver arm_smmu_driver = {
  };
  module_platform_driver(arm_smmu_driver);
 
-IOMMU_OF_DECLARE(arm_smmuv3, "arm,smmu-v3");
-
  MODULE_DESCRIPTION("IOMMU API for ARM architected SMMUv3 implementations");
  MODULE_AUTHOR("Will Deacon <[email protected]>");
  MODULE_LICENSE("GPL v2");

drivers/iommu/arm-smmu.c +0 -7

index 69e7c60792a8..9dd7cbaa3b0c 100644
@@ -2211,13 +2211,6 @@ static struct platform_driver arm_smmu_driver = {
  };
  module_platform_driver(arm_smmu_driver);
 
-IOMMU_OF_DECLARE(arm_smmuv1, "arm,smmu-v1");
-IOMMU_OF_DECLARE(arm_smmuv2, "arm,smmu-v2");
-IOMMU_OF_DECLARE(arm_mmu400, "arm,mmu-400");
-IOMMU_OF_DECLARE(arm_mmu401, "arm,mmu-401");
-IOMMU_OF_DECLARE(arm_mmu500, "arm,mmu-500");
-IOMMU_OF_DECLARE(cavium_smmuv2, "cavium,smmu-v2");
-
  MODULE_DESCRIPTION("IOMMU API for ARM architected SMMU implementations");
  MODULE_AUTHOR("Will Deacon <[email protected]>");
  MODULE_LICENSE("GPL v2");

drivers/iommu/exynos-iommu.c +0 -2

index 85879cfec52f..b128cb4372d3 100644
@@ -1390,5 +1390,3 @@ static int __init exynos_iommu_init(void)
  	return ret;
  }
  core_initcall(exynos_iommu_init);
-
-IOMMU_OF_DECLARE(exynos_iommu_of, "samsung,exynos-sysmmu");

drivers/iommu/ipmmu-vmsa.c +0 -3

index 40ae6e87cb88..f026aa16d5f1 100644
@@ -1108,9 +1108,6 @@ static void __exit ipmmu_exit(void)
  subsys_initcall(ipmmu_init);
  module_exit(ipmmu_exit);
 
-IOMMU_OF_DECLARE(ipmmu_vmsa_iommu_of, "renesas,ipmmu-vmsa");
-IOMMU_OF_DECLARE(ipmmu_r8a7795_iommu_of, "renesas,ipmmu-r8a7795");
-
  MODULE_DESCRIPTION("IOMMU API for Renesas VMSA-compatible IPMMU");
  MODULE_AUTHOR("Laurent Pinchart <[email protected]>");
  MODULE_LICENSE("GPL v2");

drivers/iommu/msm_iommu.c +0 -2

index 0d3350463a3f..27377742600d 100644
@@ -877,7 +877,5 @@ static void __exit msm_iommu_driver_exit(void)
  subsys_initcall(msm_iommu_driver_init);
  module_exit(msm_iommu_driver_exit);
 
-IOMMU_OF_DECLARE(msm_iommu_of, "qcom,apq8064-iommu");
-
  MODULE_LICENSE("GPL v2");
  MODULE_AUTHOR("Stepan Moskovchenko <[email protected]>");

drivers/iommu/of_iommu.c +1 -18

index 2aac8387717c..1904ccf9fc4e 100644
@@ -27,9 +27,6 @@
 
  #define NO_IOMMU	1
 
-static const struct of_device_id __iommu_of_table_sentinel
-	__used __section(__iommu_of_table_end);
-
  /**
   * of_get_dma_window - Parse *dma-window property and returns 0 if found.
   *

@@ -98,19 +95,6 @@ int of_get_dma_window(struct device_node *dn, const char *prefix, int index,
  }
  EXPORT_SYMBOL_GPL(of_get_dma_window);
 
-static bool of_iommu_driver_present(struct device_node *np)
-{
-	/*
-	 * If the IOMMU still isn't ready by the time we reach init, assume
-	 * it never will be. We don't want to defer indefinitely, nor attempt
-	 * to dereference __iommu_of_table after it's been freed.
-	 */
-	if (system_state >= SYSTEM_RUNNING)
-		return false;
-
-	return of_match_node(&__iommu_of_table, np);
-}
-
  static int of_iommu_xlate(struct device *dev,
  			  struct of_phandle_args *iommu_spec)
  {

@@ -120,8 +104,7 @@ static int of_iommu_xlate(struct device *dev,
 
  	ops = iommu_ops_from_fwnode(fwnode);
  	if ((ops && !ops->of_xlate) ||
-	    !of_device_is_available(iommu_spec->np) ||
-	    (!ops && !of_iommu_driver_present(iommu_spec->np)))
+	    !of_device_is_available(iommu_spec->np))
  		return NO_IOMMU;
 
  	err = iommu_fwspec_init(dev, &iommu_spec->np->fwnode, ops);

drivers/iommu/qcom_iommu.c +0 -2

index 65b9c99707f8..fa0f6c39a144 100644
@@ -947,7 +947,5 @@ static void __exit qcom_iommu_exit(void)
  module_init(qcom_iommu_init);
  module_exit(qcom_iommu_exit);
 
-IOMMU_OF_DECLARE(qcom_iommu_dev, "qcom,msm-iommu-v1");
-
  MODULE_DESCRIPTION("IOMMU API for QCOM IOMMU v1 implementations");
  MODULE_LICENSE("GPL v2");

drivers/iommu/rockchip-iommu.c +0 -2

index 0468acfa131f..90d37f29c24c 100644
@@ -1284,8 +1284,6 @@ static int __init rk_iommu_init(void)
  }
  subsys_initcall(rk_iommu_init);
 
-IOMMU_OF_DECLARE(rk_iommu_of, "rockchip,iommu");
-
  MODULE_DESCRIPTION("IOMMU API for Rockchip");
  MODULE_AUTHOR("Simon Xue <[email protected]> and Daniel Kurtz <[email protected]>");
  MODULE_ALIAS("platform:rockchip-iommu");

include/linux/of_iommu.h +0 -0

index 4fa654e4b5a9..f3d40dd7bb66 100644

Rob Herring (8):
driver core: make deferring probe after init optional driver core: add a deferred probe timeout
dt-bindings: pinctrl: add a 'pinctrl-use-default' property
arm: dts: bcm283x: mark the UART pin muxing nodes with
pinctrl-use-default
pinctrl: optionally stop deferring probe at end of initcalls
iommu: Stop deferring probe at end of initcalls
iommu: Remove IOMMU_OF_DECLARE
PM / Domains: Stop deferring probe at the end of initcall

 .../admin-guide/kernel-parameters.txt         |  7 +++
 .../bindings/pinctrl/pinctrl-bindings.txt     |  6 +++
 arch/arm/boot/dts/bcm283x.dtsi                |  2 +
 drivers/base/dd.c                             | 43 +++++++++++++++++++
 drivers/base/power/domain.c                   |  2 +-
 drivers/iommu/arm-smmu-v3.c                   |  2 -
 drivers/iommu/arm-smmu.c                      |  7 ---
 drivers/iommu/exynos-iommu.c                  |  2 -
 drivers/iommu/ipmmu-vmsa.c                    |  3 --

 drivers/iommu/msm_iommu.c                     |  2 -
 drivers/iommu/of_iommu.c                      | 21 +--------
 drivers/iommu/qcom_iommu.c                    |  2 -
 drivers/iommu/rockchip-iommu.c                |  2 -
 drivers/pinctrl/devicetree.c                  | 14 ++++--
 include/linux/device.h                        |  2 +
 include/linux/of_iommu.h                      |  4 --
 16 files changed, 73 insertions(+), 48 deletions(-)