On Thu, May 24, 2018 at 1:56 PM, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:

On Thu, May 24, 2018 at 12:50:17PM -0500, Rob Herring wrote:

...

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 agraf@suse.de Signed-off-by: Rob Herring robh@kernel.org

---

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

diff --git a/drivers/base/dd.c b/drivers/base/dd.c index c9f54089429b..d6034718da6f 100644 --- a/drivers/base/dd.c +++ b/drivers/base/dd.c @@ -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");
  

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

No, the screaming is on purpose.

Bjorn had concerns about debugging/supporting subtle problems that could stem from this. Such as electrical settings not quite right that cause intermittent errors.

Rob

On Thu, May 24, 2018 at 2:00 PM, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:

On Thu, May 24, 2018 at 12:50:17PM -0500, Rob Herring wrote:

...

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 agraf@suse.de Signed-off-by: Rob Herring robh@kernel.org

---

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

diff --git a/drivers/base/dd.c b/drivers/base/dd.c index c9f54089429b..d6034718da6f 100644 --- a/drivers/base/dd.c +++ b/drivers/base/dd.c @@ -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) {
  

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.

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.

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.

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

On Fri, May 25, 2018 at 7:20 AM, Robin Murphy robin.murphy@arm.com wrote:

On 24/05/18 21:57, Rob Herring wrote:

...

On Thu, May 24, 2018 at 2:00 PM, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:

...

On Thu, May 24, 2018 at 12:50:17PM -0500, Rob Herring wrote:

...

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 agraf@suse.de Signed-off-by: Rob Herring robh@kernel.org

---

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

diff --git a/drivers/base/dd.c b/drivers/base/dd.c index c9f54089429b..d6034718da6f 100644 --- a/drivers/base/dd.c +++ b/drivers/base/dd.c @@ -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) {
  

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.

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.

All the other (though static or internal to driver core) functions are prefixed driver_deferred_probe_* so I was trying to remain consistent there. You're right though, with the timeout it's not just whether initcalls are done. It's really "get the return value depending on the core's deferred probe state". So perhaps one of these:

driver_deferred_probe_get_return_val() driver_deferred_probe_handle_return()

The other option would be a more straight-forward functions that just returns a bool on whether to continue deferring and leave the return code handling to the caller:

if (driver_deferred_probe_enabled_for_builtin(dev)) return -EPROBE_DEFER; else return -ENODEV;

The pinctrl case would look like this:

builtin_only = of_property_read_bool(np_pctldev, "pinctrl-use-default"); if (builtin_only && driver_deferred_probe_enabled_for_builtin(dev)) return -EPROBE_DEFER; else if (!builtin_only && driver_deferred_probe_enabled(dev)) return -EPROBE_DEFER; else return -ENODEV;

I still prefer the former, picking the bike shed color is easier with the latter.

...

...

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.

...

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.

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.

A bitmask is just 32 booleans stuffed into one parameter which I can guess Greg's opinion on.

I can't really think of other flags we might need here. If we added some userspace trigger saying module loading is done, I don't think we'd need that to be per caller.

Rob

On Thu, May 24, 2018 at 5:28 PM, Bjorn Andersson bjorn.andersson@linaro.org wrote:

On Thu 24 May 10:50 PDT 2018, Rob Herring wrote:

...

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.

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.

For pinctrl, you are not affected now unless you change your DT. I made pinctrl opt-in since as you said it could lead to some intermittent problems. If iommu or power domains are required, then it should fail pretty hard.

However, good luck getting your serial console to work if it has a pinctrl dependency and that's a module. It won't work because the console has to be up before userspace. Of course, you can just rely on earlycon, but that just proves that pinctrl is not required (at least for 1 serial pin). :)

Rob

Regards, Bjorn

...

Cc: Alexander Graf agraf@suse.de Signed-off-by: Rob Herring robh@kernel.org

---

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

diff --git a/drivers/base/dd.c b/drivers/base/dd.c index c9f54089429b..d6034718da6f 100644 --- a/drivers/base/dd.c +++ b/drivers/base/dd.c @@ -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); diff --git a/include/linux/device.h b/include/linux/device.h index 477956990f5e..f3dafd44c285 100644 --- a/include/linux/device.h +++ b/include/linux/device.h @@ -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

On Thu, May 24, 2018 at 12:50:18PM -0500, Rob Herring wrote:

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 robh@kernel.org

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

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 11fc28ecdb6d..dd3f40b34a24 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -809,6 +809,13 @@ Defaults to the default architecture's huge page size if not specified.

• 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 :)

thanks,

greg k-h

On Thu, May 24, 2018 at 02:45:48PM -0500, Rob Herring wrote:

On Thu, May 24, 2018 at 2:01 PM, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:

...

On Thu, May 24, 2018 at 12:50:18PM -0500, Rob Herring wrote:

...

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 robh@kernel.org

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

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 11fc28ecdb6d..dd3f40b34a24 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -809,6 +809,13 @@ Defaults to the default architecture's huge page size if not specified.

• 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 it is a debug option, make it obvious it's only for debugging. The commit log here says it's a debug option, but your documentation does not say that at all, and that's what people will read.

Well, they might read it, probably not. But at least give us something to point at when they mess things up :)

thanks,

greg k-h

Hi Rob,

On 2018-05-24 19:50, Rob Herring wrote:

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 will.deacon@arm.com Cc: Robin Murphy robin.murphy@arm.com Cc: Joerg Roedel joro@8bytes.org Cc: Marek Szyprowski m.szyprowski@samsung.com Cc: Kukjin Kim kgene@kernel.org Cc: Krzysztof Kozlowski krzk@kernel.org Cc: Rob Clark robdclark@gmail.com Cc: Heiko Stuebner heiko@sntech.de Cc: Frank Rowand frowand.list@gmail.com Cc: linux-arm-kernel@lists.infradead.org Cc: iommu@lists.linux-foundation.org Cc: linux-samsung-soc@vger.kernel.org Cc: linux-arm-msm@vger.kernel.org Cc: linux-rockchip@lists.infradead.org Cc: devicetree@vger.kernel.org Signed-off-by: Rob Herring robh@kernel.org

For Exynos IOMMU:

Acked-by: Marek Szyprowski m.szyprowski@samsung.com

---

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(-)

diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c index 1d647104bccc..22bdabd3d8e0 100644 --- a/drivers/iommu/arm-smmu-v3.c +++ b/drivers/iommu/arm-smmu-v3.c @@ -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 will.deacon@arm.com"); MODULE_LICENSE("GPL v2");

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index 69e7c60792a8..9dd7cbaa3b0c 100644 --- a/drivers/iommu/arm-smmu.c +++ b/drivers/iommu/arm-smmu.c @@ -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 will.deacon@arm.com"); MODULE_LICENSE("GPL v2");

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c index 85879cfec52f..b128cb4372d3 100644 --- a/drivers/iommu/exynos-iommu.c +++ b/drivers/iommu/exynos-iommu.c @@ -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"); diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c index 40ae6e87cb88..f026aa16d5f1 100644 --- a/drivers/iommu/ipmmu-vmsa.c +++ b/drivers/iommu/ipmmu-vmsa.c @@ -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 laurent.pinchart@ideasonboard.com"); MODULE_LICENSE("GPL v2");

diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c index 0d3350463a3f..27377742600d 100644 --- a/drivers/iommu/msm_iommu.c +++ b/drivers/iommu/msm_iommu.c @@ -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 stepanm@codeaurora.org");

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index 2aac8387717c..1904ccf9fc4e 100644 --- a/drivers/iommu/of_iommu.c +++ b/drivers/iommu/of_iommu.c @@ -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); diff --git a/drivers/iommu/qcom_iommu.c b/drivers/iommu/qcom_iommu.c index 65b9c99707f8..fa0f6c39a144 100644 --- a/drivers/iommu/qcom_iommu.c +++ b/drivers/iommu/qcom_iommu.c @@ -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");

diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c index 0468acfa131f..90d37f29c24c 100644 --- a/drivers/iommu/rockchip-iommu.c +++ b/drivers/iommu/rockchip-iommu.c @@ -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 xxm@rock-chips.com and Daniel Kurtz djkurtz@chromium.org"); MODULE_ALIAS("platform:rockchip-iommu");

diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h index 4fa654e4b5a9..f3d40dd7bb66 100644 --- a/include/linux/of_iommu.h +++ b/include/linux/of_iommu.h @@ -32,8 +32,4 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev, #endif /* CONFIG_OF_IOMMU */ -extern struct of_device_id __iommu_of_table;

-#define IOMMU_OF_DECLARE(name, compat) OF_DECLARE_1(iommu, name, compat, NULL)

• #endif /* __OF_IOMMU_H */

Best regards