* [PATCH] ARM: dts: pxa3xx: fix MMC clocks
From: Daniel Mack @ 2018-05-24 17:43 UTC (permalink / raw)
To: linux-arm-kernel
The clocks for the 3 MMC controllers on pxa3xx platforms are CLK_MMC1,
CLK_MMC2 and CLK_MMC3. CLK_MMC is only for pxa2xx.
Signed-off-by: Daniel Mack <daniel@zonque.org>
---
arch/arm/boot/dts/pxa3xx.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/pxa3xx.dtsi b/arch/arm/boot/dts/pxa3xx.dtsi
index 132cce03414f..7ffe06f1dcc0 100644
--- a/arch/arm/boot/dts/pxa3xx.dtsi
+++ b/arch/arm/boot/dts/pxa3xx.dtsi
@@ -174,7 +174,7 @@
compatible = "marvell,pxa-mmc";
reg = <0x41100000 0x1000>;
interrupts = <23>;
- clocks = <&clks CLK_MMC>;
+ clocks = <&clks CLK_MMC1>;
dmas = <&pdma 21 3
&pdma 22 3>;
dma-names = "rx", "tx";
@@ -185,7 +185,7 @@
compatible = "marvell,pxa-mmc";
reg = <0x42000000 0x1000>;
interrupts = <41>;
- clocks = <&clks CLK_MMC1>;
+ clocks = <&clks CLK_MMC2>;
dmas = <&pdma 93 3
&pdma 94 3>;
dma-names = "rx", "tx";
@@ -196,7 +196,7 @@
compatible = "marvell,pxa-mmc";
reg = <0x42500000 0x1000>;
interrupts = <55>;
- clocks = <&clks CLK_MMC2>;
+ clocks = <&clks CLK_MMC3>;
dmas = <&pdma 46 3
&pdma 47 3>;
dma-names = "rx", "tx";
--
2.14.3
^ permalink raw reply related
* [PATCH v2 0/8] Make deferring probe forever optional
From: Rob Herring @ 2018-05-24 17:50 UTC (permalink / raw)
To: linux-arm-kernel
This series came out of a discussion on the ARM boot-architecture
list[1] about DT forwards and backwards compatibility issues. There are
issues with newer DTs breaking on older, stable kernels. Some of these
are difficult to solve, but cases of optional devices not having
kernel support should be solvable.
I tested this on a RPi3 B with the pinctrl driver forced off. With this
change, the MMC/SD and UART drivers can function without the pinctrl
driver.
v2:
- Add a DT property for pinctrl to flag using defaults
- Add a debug timeout to stop deferring some number of seconds after
initcalls are done (giving modules a chance to load)
- Split pinctrl support to its own patch
- WARN when we stop deferring probe for a device
- Add IOMMU support
- Add PM domain support
Rob
[1] https://lists.linaro.org/pipermail/boot-architecture/2018-April/000466.html
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(-)
--
2.17.0
^ permalink raw reply
* [PATCH v2 1/8] driver core: make deferring probe after init optional
From: Rob Herring @ 2018-05-24 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175024.19874-1-robh@kernel.org>
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");
+ 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
^ permalink raw reply related
* [PATCH v2 2/8] driver core: add a deferred probe timeout
From: Rob Herring @ 2018-05-24 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175024.19874-1-robh@kernel.org>
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.
+
dhash_entries= [KNL]
Set number of hash buckets for dentry cache.
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index d6034718da6f..4133b240c7e4 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -226,9 +226,17 @@ void device_unblock_probing(void)
driver_deferred_probe_trigger();
}
+static int deferred_probe_timeout = -1;
+static int __init deferred_probe_timeout_setup(char *str)
+{
+ deferred_probe_timeout = simple_strtol(str, NULL, 0);
+ return 1;
+}
+__setup("deferred_probe_timeout=", deferred_probe_timeout_setup);
+
int driver_deferred_probe_check_init_done(struct device *dev, bool optional)
{
- if (optional && initcalls_done) {
+ if ((optional || !deferred_probe_timeout) && initcalls_done) {
dev_WARN(dev, "ignoring dependency for device, assuming no driver");
return -ENODEV;
}
@@ -236,6 +244,19 @@ int driver_deferred_probe_check_init_done(struct device *dev, bool optional)
return -EPROBE_DEFER;
}
+static void deferred_probe_timeout_work_func(struct work_struct *work)
+{
+ struct device_private *private, *p;
+
+ deferred_probe_timeout = 0;
+ driver_deferred_probe_trigger();
+ flush_work(&deferred_probe_work);
+
+ list_for_each_entry_safe(private, p, &deferred_probe_pending_list, deferred_probe)
+ dev_info(private->device, "deferred probe pending");
+}
+static DECLARE_DELAYED_WORK(deferred_probe_timeout_work, deferred_probe_timeout_work_func);
+
/**
* deferred_probe_initcall() - Enable probing of deferred devices
*
@@ -257,6 +278,11 @@ static int deferred_probe_initcall(void)
*/
driver_deferred_probe_trigger();
flush_work(&deferred_probe_work);
+
+ if (deferred_probe_timeout > 0) {
+ schedule_delayed_work(&deferred_probe_timeout_work,
+ deferred_probe_timeout * HZ);
+ }
return 0;
}
late_initcall(deferred_probe_initcall);
--
2.17.0
^ permalink raw reply related
* [PATCH v2 3/8] dt-bindings: pinctrl: add a 'pinctrl-use-default' property
From: Rob Herring @ 2018-05-24 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175024.19874-1-robh@kernel.org>
Pin setup may be optional in some cases such as the reset default works
or the pin setup is done by the bootloader. In these cases, it is optional
for the OS to support managing the pin controller and pin setup. In order
to support this scenario, add a property 'pinctrl-use-default' to indicate
that the pin configuration is optional.
Signed-off-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/pinctrl/pinctrl-bindings.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
index ad9bbbba36e9..cef2b5855d60 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
@@ -103,6 +103,12 @@ Optional properties:
#pinctrl-cells: Number of pin control cells in addition to the index within the
pin controller device instance
+pinctrl-use-default: Boolean. Indicates that the OS can use the boot default
+ pin configuration. This allows using an OS that does not have a
+ driver for the pin controller. This property can be set either
+ globally for the pin controller or in child nodes for individual
+ pin group control.
+
Pin controller devices should contain the pin configuration nodes that client
devices reference.
--
2.17.0
^ permalink raw reply related
* [PATCH v2 4/8] arm: dts: bcm283x: mark the UART pin muxing nodes with pinctrl-use-default
From: Rob Herring @ 2018-05-24 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175024.19874-1-robh@kernel.org>
Signed-off-by: Rob Herring <robh@kernel.org>
---
arch/arm/boot/dts/bcm283x.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index ac00e730f898..c8b8ede3d273 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -321,6 +321,7 @@
};
uart0_gpio14: uart0_gpio14 {
+ pinctrl-use-default;
brcm,pins = <14 15>;
brcm,function = <BCM2835_FSEL_ALT0>;
};
@@ -353,6 +354,7 @@
};
uart1_gpio14: uart1_gpio14 {
+ pinctrl-use-default;
brcm,pins = <14 15>;
brcm,function = <BCM2835_FSEL_ALT5>;
};
--
2.17.0
^ permalink raw reply related
* [PATCH v2 5/8] pinctrl: optionally stop deferring probe at end of initcalls
From: Rob Herring @ 2018-05-24 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175024.19874-1-robh@kernel.org>
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 <robh@kernel.org>
---
drivers/pinctrl/devicetree.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/devicetree.c b/drivers/pinctrl/devicetree.c
index b601039d6c69..74a31074b406 100644
--- a/drivers/pinctrl/devicetree.c
+++ b/drivers/pinctrl/devicetree.c
@@ -110,17 +110,23 @@ static int dt_to_map_one_config(struct pinctrl *p,
int ret;
struct pinctrl_map *map;
unsigned num_maps;
+ bool pctl_optional = false;
/* Find the pin controller containing np_config */
np_pctldev = of_node_get(np_config);
for (;;) {
+ if (!pctl_optional)
+ pctl_optional = of_property_read_bool(np_pctldev, "pinctrl-use-default");
+
np_pctldev = of_get_next_parent(np_pctldev);
if (!np_pctldev || of_node_is_root(np_pctldev)) {
- dev_info(p->dev, "could not find pctldev for node %pOF, deferring probe\n",
- np_config);
of_node_put(np_pctldev);
- /* OK let's just assume this will appear later then */
- return -EPROBE_DEFER;
+ ret = driver_deferred_probe_check_init_done(p->dev, pctl_optional);
+ if (ret == -EPROBE_DEFER)
+ /* OK let's just assume this will appear later then */
+ dev_info(p->dev, "could not find pctldev for node %pOF, deferring probe\n",
+ np_config);
+ return ret;
}
/* If we're creating a hog we can use the passed pctldev */
if (pctldev && (np_pctldev == p->dev->of_node))
--
2.17.0
^ permalink raw reply related
* [PATCH v2 6/8] iommu: Stop deferring probe at end of initcalls
From: Rob Herring @ 2018-05-24 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175024.19874-1-robh@kernel.org>
The IOMMU subsystem has its own mechanism to not defer probe if driver
support is missing. Now that the driver core supports stopping deferring
probe if drivers aren't built-in (and probed), use the driver core
support so the IOMMU specific support can be removed.
Cc: Joerg Roedel <joro@8bytes.org>
Cc: iommu at lists.linux-foundation.org
Signed-off-by: Rob Herring <robh@kernel.org>
---
drivers/iommu/of_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 5c36a8b7656a..2aac8387717c 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -133,7 +133,7 @@ static int of_iommu_xlate(struct device *dev,
* a proper probe-ordering dependency mechanism in future.
*/
if (!ops)
- return -EPROBE_DEFER;
+ return driver_deferred_probe_check_init_done(dev, true);
return ops->of_xlate(dev, iommu_spec);
}
--
2.17.0
^ permalink raw reply related
* [PATCH v2 7/8] iommu: Remove IOMMU_OF_DECLARE
From: Rob Herring @ 2018-05-24 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175024.19874-1-robh@kernel.org>
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 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 <robh@kernel.org>
---
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 */
--
2.17.0
^ permalink raw reply related
* [PATCH v2 8/8] PM / Domains: Stop deferring probe at the end of initcall
From: Rob Herring @ 2018-05-24 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175024.19874-1-robh@kernel.org>
All PM domain drivers must be built-in (at least those using DT), so
there is no point deferring probe after initcalls are done. Continuing
to defer probe may prevent booting successfully even if managing PM
domains is not required. This can happen if the user failed to enable
the driver or if power-domains are added to a platform's DT, but there
is not yet a driver (e.g. a new DTB with an old kernel).
Call the driver core function driver_deferred_probe_check_init_done()
instead of just returning -EPROBE_DEFER to stop deferring probe when
initcalls are done.
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Kevin Hilman <khilman@kernel.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Len Brown <len.brown@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-pm at vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
---
drivers/base/power/domain.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 1ea0e2502e8e..6398cf786e6a 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -2218,7 +2218,7 @@ int genpd_dev_pm_attach(struct device *dev)
mutex_unlock(&gpd_list_lock);
dev_dbg(dev, "%s() failed to find PM domain: %ld\n",
__func__, PTR_ERR(pd));
- return -EPROBE_DEFER;
+ return driver_deferred_probe_check_init_done(dev, true);
}
dev_dbg(dev, "adding to PM domain %s\n", pd->name);
--
2.17.0
^ permalink raw reply related
* [PATCH v3 5/6] spi: at91-usart: add driver for at91-usart as spi
From: Alexandre Belloni @ 2018-05-24 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0e6e71e2-f8ac-7889-0d81-8d8a4c15223d@microchip.com>
Hi,
On 24/05/2018 19:04:11+0300, Radu Pirea wrote:
>
>
> On 05/17/2018 07:54 AM, Mark Brown wrote:
> > On Tue, May 15, 2018 at 12:22:24PM +0300, Radu Pirea wrote:
> > > On Mon, 2018-05-14 at 20:38 +0300, Andy Shevchenko wrote:
> >
> > > > So, what is not going as expected in "SPI core takes care of CSs"
> > > > case?
> > > > Did you use oscilloscope for that?
> >
> > > Yes, I used and CSs was not asserted. Anyway, I will will try again.
> >
> > If the core chip select handling is not working properly for some reason
> > then the core chip select handling should be fixed rather than just open
> > coding in your driver - probably it's also broken for other users.
> >
>
> Hi Mark,
>
> I found the fix for cs-gpios. If I change spi_add_device function like
> this(see below) everything is ok.
>
> int spi_add_device(struct spi_device *spi)
>
> ...
>
> if (ctlr->cs_gpios){
> spi->cs_gpio = ctlr->cs_gpios[spi->chip_select];
> if(gpio_is_valid(spi->cs_gpio))
> gpio_direction_output(spi->cs_gpio, !(spi->mode & SPI_CS_HIGH));
>
> }
>
> ...
>
> return status;
> }
>
> In the subsystem gpio direction of pins is never set and gpio_set_value()
> don't set the direction.
> In my opinion gpio_direction_output() set direction should be called in
> spi_add_device. What do you think? Is ok?
Back in 2014, I was suggesting using devm_gpio_request_one() in
of_spi_register_master(). That would take care of setting the direction
of the GPIO:
https://www.spinics.net/lists/arm-kernel/msg351251.html
I never took the time to create the patch and test though.
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v2 02/13] ARM: pxa: add dma slave map
From: Robert Jarzmik @ 2018-05-24 18:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524070703.11901-3-robert.jarzmik@free.fr>
Robert Jarzmik <robert.jarzmik@free.fr> writes:
> In order to remove the specific knowledge of the dma mapping from PXA
> drivers, add a default slave map for pxa architectures.
>
> This is the first step, and once all drivers are converted,
> pxad_filter_fn() will be made static, and the DMA resources removed from
> device.c.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> + { "smc911x.0", "rx", PDMA_FILTER_PARAM(LOWEST, -1) },
> + { "smc911x.0", "tx", PDMA_FILTER_PARAM(LOWEST, -1) },
> + { "smc91x.0", "data", PDMA_FILTER_PARAM(LOWEST, -1) },
Hi Arnd,
Actually after rereading this, I realised that I completely forgot your former
comment about having a NULL parameter for network devices (as there is no
requestor behind).
I will cook it up for v3 ... that will be a minor change in this patch (hence
I'll keep any Ack), but for patches 0006 and 0007, things will change, and
another patch for Vinod will appear.
Cheers.
--
Robert
^ permalink raw reply
* [PATCH v3 5/6] spi: at91-usart: add driver for at91-usart as spi
From: Mark Brown @ 2018-05-24 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0e6e71e2-f8ac-7889-0d81-8d8a4c15223d@microchip.com>
On Thu, May 24, 2018 at 07:04:11PM +0300, Radu Pirea wrote:
> if (ctlr->cs_gpios){
> spi->cs_gpio = ctlr->cs_gpios[spi->chip_select];
> if(gpio_is_valid(spi->cs_gpio))
> gpio_direction_output(spi->cs_gpio, !(spi->mode & SPI_CS_HIGH));
>
> }
You're expected to request the GPIOs in your driver using one of the
modern request functions like gpio_request_one() (or ideally the GPIO
descriptor APIs now) which combine the direction setting and request
into a single operation.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180524/afe4d42a/attachment.sig>
^ permalink raw reply
* [PATCH v3 5/6] spi: at91-usart: add driver for at91-usart as spi
From: Mark Brown @ 2018-05-24 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175620.GB12093@piout.net>
On Thu, May 24, 2018 at 07:56:20PM +0200, Alexandre Belloni wrote:
> Back in 2014, I was suggesting using devm_gpio_request_one() in
> of_spi_register_master(). That would take care of setting the direction
> of the GPIO:
> https://www.spinics.net/lists/arm-kernel/msg351251.html
> I never took the time to create the patch and test though.
Right, this'd be ideal but unfortunately it does mean we'd have to
transition all the existing users that open code their requests which is
a pain. It'd be really nice if someone had the time/enthusiam to do it
though.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180524/4bbd58ed/attachment.sig>
^ permalink raw reply
* [PATCH v2 1/8] driver core: make deferring probe after init optional
From: Mark Brown @ 2018-05-24 18:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175024.19874-2-robh@kernel.org>
On Thu, May 24, 2018 at 12:50:17PM -0500, Rob Herring wrote:
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180524/252c8b9e/attachment.sig>
^ permalink raw reply
* [GIT PULL 1/2] ARM: dts: exynos: Second round for v4.18
From: Krzysztof Kozlowski @ 2018-05-24 18:20 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On top of previous pull request.
Best regards,
Krzysztof
The following changes since commit 83cb529b2ef4f3446e60e75522d76fdaaea4724c:
ARM: dts: exynos: Update x and y properties for mms114 touchscreen (2018-05-13 15:15:49 +0200)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-4.18-2
for you to fetch changes up to 68605101460ea4c62a966b1ad3e8db90d8fbaa31:
ARM: dts: exynos: Add support for audio over HDMI for Odroid X/X2/U3 (2018-05-15 18:46:14 +0200)
----------------------------------------------------------------
Samsung DTS ARM changes for v4.18, part 2
1. Add support for audio over HDMI for Odroid X/X2/U3.
----------------------------------------------------------------
Sylwester Nawrocki (1):
ARM: dts: exynos: Add support for audio over HDMI for Odroid X/X2/U3
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 33 +++++++++++++++----------
arch/arm/boot/dts/exynos4412-odroidu3.dts | 6 ++---
arch/arm/boot/dts/exynos4412-odroidx.dts | 6 ++---
3 files changed, 26 insertions(+), 19 deletions(-)
^ permalink raw reply
* [GIT PULL 2/2] arm64: dts: exynos: Second round for v4.18
From: Krzysztof Kozlowski @ 2018-05-24 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524182016.5866-1-krzk@kernel.org>
Hi,
On top of previous pull request.
Best regards,
Krzysztof
The following changes since commit 8dd6203f32f20cb83469eb859efded9e403b3e9f:
arm64: dts: exynos: Add mem-2-mem Scaler devices (2018-05-13 11:26:13 +0200)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt64-4.18-2
for you to fetch changes up to f0b5e8a21e6604980c35eeeba1ee3a124f45ad1f:
arm64: dts: exynos: Add more clocks to Exynos5433 Decon/DeconTV (2018-05-23 20:23:24 +0200)
----------------------------------------------------------------
Samsung DTS ARM64 changes for v4.18, part 2
1. Add clocks necessary for DECON hardware windows no 4 and 5 on
Exynos5433.
----------------------------------------------------------------
Marek Szyprowski (1):
arm64: dts: exynos: Add more clocks to Exynos5433 Decon/DeconTV
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH V2] PCI/portdrv: do not disable device on reboot/shutdown
From: Bjorn Helgaas @ 2018-05-24 18:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <61f70fd6-52fd-da07-ce73-303f95132131@codeaurora.org>
On Wed, May 23, 2018 at 06:57:18PM -0400, Sinan Kaya wrote:
> On 5/23/2018 5:32 PM, Bjorn Helgaas wrote:
> >
> > The crash seems to indicate that the hpsa device attempted a DMA after
> > we cleared the Root Port's PCI_COMMAND_MASTER, which means
> > hpsa_shutdown() didn't stop DMA from the device (it looks like *most*
> > shutdown methods don't disable device DMA, so it's in good company).
>
> All drivers are expected to shutdown DMA and interrupts in their shutdown()
> routines. They can skip removing threads, data structures etc. but DMA and
> interrupt disabling are required. This is the difference between shutdown()
> and remove() callbacks.
>
> If you see that this is not being done in HPSA, then that is where the
> bugfix should be.
>
> Counter argument is that if shutdown() is not implemented, at least remove()
> should be called. Expecting all drivers to implement shutdown() callbacks
> is just bad by design in my opinion.
>
> Code should have fallen back to remove() if shutdown() doesn't exist.
> I can propose a patch for this but this is yet another story to chase.
That sounds like a reasonable idea, and it is definitely another can
of worms. I looked briefly at some of the .shutdown() cases:
- device_shutdown() doesn't fall back to remove().
- It looks like most bus_types don't implement .shutdown() at all (I
didn't look at them all).
- Of the bus_types that do implement .shutdown(), most do not fall
back to .remove(). ps3_system_bus_type() is an example of one
that *does* fall back to a driver's .remove() if there is no
.shutdown().
Implement shutdown (no fallback unless indicated):
ecard_bus_type
gio_bus_type
ps3_system_bus_type # does fallback to remove
ibmebus_bus_type
isa_bus_type
platform_bus_type # not direct implementation
fmc_bus_type # fmc_shutdown() looks spurious
mipi_dsi_bus_type
hv_bus
> >> This has been found to cause crashes on HP DL360 Gen9 machines during
> >> reboot. Besides, kexec is already clearing the bus master bit in
> >> pci_device_shutdown() after all PCI drivers are removed.
> >
> > The original path was:
> >
> > pci_device_shutdown(hpsa)
> > drv->shutdown
> > hpsa_shutdown # hpsa_pci_driver.shutdown
> > ...
> > pci_device_shutdown(RP) # root port
> > drv->shutdown
> > pcie_portdrv_remove # pcie_portdriver.shutdown
> > pcie_port_device_remove
> > pci_disable_device
> > do_pci_disable_device
> > # clear RP PCI_COMMAND_MASTER
> > if (kexec)
> > pci_clear_master(RP)
> > # clear RP PCI_COMMAND_MASTER
> >
> > If I understand correctly, the new path after this patch is:
> >
> > pci_device_shutdown(hpsa)
> > drv->shutdown
> > hpsa_shutdown # hpsa_pci_driver.shutdown
> > ...
> > pci_device_shutdown(RP) # root port
> > drv->shutdown
> > pcie_portdrv_shutdown # pcie_portdriver.shutdown
> > __pcie_portdrv_remove(RP, false)
> > pcie_port_device_remove(RP, false)
> > # do NOT clear RP PCI_COMMAND_MASTER
>
> yup
>
> > if (kexec)
> > pci_clear_master(RP)
> > # clear RP PCI_COMMAND_MASTER
> >
> > I guess this patch avoids the panic during reboot because we're not in
> > the kexec path, so we never clear PCI_COMMAND_MASTER for the Root
> > Port, so the hpsa device can DMA happily until the lights go out.
> >
> > But DMA continuing for some random amount of time before the reboot or
> > shutdown happens makes me a little queasy. That doesn't sound safe.
> > The more I think about this, the more confused I get. What am I
> > missing?
>
> see above.
>
> >
> >> Just remove the extra clear in shutdown path by seperating the remove and
> >> shutdown APIs in the PORTDRV.
> >>
> >> static pci_ers_result_t pcie_portdrv_error_detected(struct pci_dev *dev,
> >> @@ -218,7 +228,7 @@ static struct pci_driver pcie_portdriver = {
> >>
> >> .probe = pcie_portdrv_probe,
> >> .remove = pcie_portdrv_remove,
> >> - .shutdown = pcie_portdrv_remove,
> >> + .shutdown = pcie_portdrv_shutdown,
> >
> > What are the circumstances when we call .remove() vs .shutdown()?
> >
> > I guess the main (maybe only) way to call .remove() is to hot-remove
> > the port? And .shutdown() is basically used in the reboot and kexec
> > paths?
>
> Correct. shutdown() is only called during reboot/shutdown calls. If you echo
> 1 into the remove file, remove() gets called. Handy for hotplug use cases.
> It needs to be the exact opposite of the probe. It needs to clean up resources
> etc. and have the HW in a state where it can be reinitialized via probe again.
>
> >
> >> .err_handler = &pcie_portdrv_err_handler,
> >>
> >> --
> >> 2.7.4
> >>
> >
>
>
> --
> Sinan Kaya
> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v2 1/8] driver core: make deferring probe after init optional
From: Greg Kroah-Hartman @ 2018-05-24 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175024.19874-2-robh@kernel.org>
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?
thanks,
greg k-h
^ permalink raw reply
* [PATCH v2 1/8] driver core: make deferring probe after init optional
From: Greg Kroah-Hartman @ 2018-05-24 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175024.19874-2-robh@kernel.org>
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?
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 :)
thanks,
greg k-h
^ permalink raw reply
* [PATCH v2 2/8] driver core: add a deferred probe timeout
From: Greg Kroah-Hartman @ 2018-05-24 19:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175024.19874-3-robh@kernel.org>
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
^ permalink raw reply
* uImage target support on arm64
From: Ramon Fried @ 2018-05-24 19:05 UTC (permalink / raw)
To: linux-arm-kernel
Hi.
I've noticed that it's not supported.
Is it on purpose ?
If not I'll be happy to add support for: make uImage
for arm64 targets.
Warm regards,
Ramon.
^ permalink raw reply
* [PATCH 0/4] arm64: align KPTI interface with x86
From: Mark Langsdorf @ 2018-05-24 19:09 UTC (permalink / raw)
To: linux-arm-kernel
ARM64 supports KPTI, but is missing some user interface features such as
a debugfs entry compared to the x86 implementation.
Add the nopti argument, update the documentation so that ARM64 as well
as x86 supports nopti and kpti, and add a debugfs entry to check the
status of the kpti on a running machine.
--Mark Langsdorf
^ permalink raw reply
* [PATCH 1/4] arm64: capabilities: add nopti command line argument
From: Mark Langsdorf @ 2018-05-24 19:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524190932.32118-1-mlangsdo@redhat.com>
The x86 kernel and the documentation use 'nopti' as the kernel command
line argument to disable kernel page table isolation, so add nopti to
the arm64 kernel for compatibility.
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
---
Documentation/admin-guide/kernel-parameters.txt | 6 +++---
arch/arm64/kernel/cpufeature.c | 11 ++++++++++-
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index f2040d4..a987725 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3342,8 +3342,8 @@
pt. [PARIDE]
See Documentation/blockdev/paride.txt.
- pti= [X86_64] Control Page Table Isolation of user and
- kernel address spaces. Disabling this feature
+ pti= [X86_64, ARM64] Control Page Table Isolation of user
+ and kernel address spaces. Disabling this feature
removes hardening, but improves performance of
system calls and interrupts.
@@ -3354,7 +3354,7 @@
Not specifying this option is equivalent to pti=auto.
- nopti [X86_64]
+ nopti [X86_64, ARM64]
Equivalent to pti=off
pty.legacy_count=
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 9d1b06d..7c5d8712 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -934,10 +934,19 @@ static int __init parse_kpti(char *str)
if (ret)
return ret;
- __kpti_forced = enabled ? 1 : -1;
+ if (!__kpti_forced)
+ __kpti_forced = enabled ? 1 : -1;
return 0;
}
__setup("kpti=", parse_kpti);
+
+/* for compatibility with documentation and x86 nopti command line arg */
+static int __init force_nokpti(char *arg)
+{
+ __kpti_forced = -1;
+ return 0;
+}
+early_param("nopti", force_nokpti);
#endif /* CONFIG_UNMAP_KERNEL_AT_EL0 */
#ifdef CONFIG_ARM64_HW_AFDBM
--
2.9.5
^ permalink raw reply related
* [PATCH 2/4] arm64: kdebugfs: create arm64 debugfs directory
From: Mark Langsdorf @ 2018-05-24 19:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524190932.32118-1-mlangsdo@redhat.com>
Create debugfs directory for arm64, like the existing one for x86.
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
---
arch/arm64/kernel/Makefile | 3 ++-
arch/arm64/kernel/kdebugfs.c | 27 +++++++++++++++++++++++++++
2 files changed, 29 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/kernel/kdebugfs.c
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index bf825f3..a48b298 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -18,7 +18,8 @@ arm64-obj-y := debug-monitors.o entry.o irq.o fpsimd.o \
hyp-stub.o psci.o cpu_ops.o insn.o \
return_address.o cpuinfo.o cpu_errata.o \
cpufeature.o alternative.o cacheinfo.o \
- smp.o smp_spin_table.o topology.o smccc-call.o
+ smp.o smp_spin_table.o topology.o smccc-call.o \
+ kdebugfs.o
extra-$(CONFIG_EFI) := efi-entry.o
diff --git a/arch/arm64/kernel/kdebugfs.c b/arch/arm64/kernel/kdebugfs.c
new file mode 100644
index 0000000..e1e3332
--- /dev/null
+++ b/arch/arm64/kernel/kdebugfs.c
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Architecture specific debugfs files
+ *
+ * Copyright (C) 2018 Red Hat, Inc.
+ */
+
+#include <linux/debugfs.h>
+#include <linux/export.h>
+#include <linux/init.h>
+
+struct dentry *arch_debugfs_dir;
+EXPORT_SYMBOL(arch_debugfs_dir);
+
+static int __init arch_kdebugfs_init(void)
+{
+ int error = 0;
+
+ arch_debugfs_dir = debugfs_create_dir("arm64", NULL);
+ if (IS_ERR(arch_debugfs_dir)) {
+ arch_debugfs_dir = NULL;
+ return -ENOMEM;
+ }
+
+ return error;
+}
+postcore_initcall(arch_kdebugfs_init);
--
2.9.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox