* [PATCH v4 4/5] bus: stm32: Add stm32 ETZPC firewall bus controller
From: Benjamin Gaignard @ 2020-06-05 8:33 UTC (permalink / raw)
To: robh+dt, mcoquelin.stm32, alexandre.torgue, linus.walleij, gregkh
Cc: Benjamin Gaignard, tomase, linux-kernel, stefano.stabellini,
linux-stm32, linux-arm-kernel
In-Reply-To: <20200605083348.13880-1-benjamin.gaignard@st.com>
Add STM32 Extended TrustZone Protection bus controller.
For each of device-tree nodes it will check and apply
firewall configuration. If it doesn't match the device
will not be probed by platform bus.
A device could be configured to be accessible by trusted world,
co-processor or non-secure world.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
drivers/bus/stm32/Kconfig | 8 ++
drivers/bus/stm32/Makefile | 1 +
drivers/bus/stm32/stm32-etzpc.c | 163 ++++++++++++++++++++++++++++
include/dt-bindings/bus/stm32/stm32-etzpc.h | 90 +++++++++++++++
4 files changed, 262 insertions(+)
create mode 100644 drivers/bus/stm32/stm32-etzpc.c
create mode 100644 include/dt-bindings/bus/stm32/stm32-etzpc.h
diff --git a/drivers/bus/stm32/Kconfig b/drivers/bus/stm32/Kconfig
index 57221e833e2d..5dc6e2504de5 100644
--- a/drivers/bus/stm32/Kconfig
+++ b/drivers/bus/stm32/Kconfig
@@ -1,3 +1,11 @@
config FIREWALL_CONTROLLERS
bool "Support of bus firewall controllers"
depends on OF
+
+config STM32_ETZPC
+ bool "STM32 ETZPC bus controller"
+ depends on MACH_STM32MP157
+ select FIREWALL_CONTROLLERS
+ help
+ Select y to enable STM32 Extended TrustZone Protection
+ Controller (ETZPC)
diff --git a/drivers/bus/stm32/Makefile b/drivers/bus/stm32/Makefile
index eb6b978d6450..d42e99b5865e 100644
--- a/drivers/bus/stm32/Makefile
+++ b/drivers/bus/stm32/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_FIREWALL_CONTROLLERS) += firewall.o
+obj-$(CONFIG_STM32_ETZPC) += stm32-etzpc.o
diff --git a/drivers/bus/stm32/stm32-etzpc.c b/drivers/bus/stm32/stm32-etzpc.c
new file mode 100644
index 000000000000..ad0e16eea66b
--- /dev/null
+++ b/drivers/bus/stm32/stm32-etzpc.c
@@ -0,0 +1,163 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) STMicroelectronics 2020 - All Rights Reserved
+ * Author: Benjamin Gaignard <benjamin.gaignard@st.com> for STMicroelectronics.
+ */
+
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+
+#include <dt-bindings/bus/stm32/stm32-etzpc.h>
+
+#include "firewall.h"
+
+#define ETZPC_DECPROT 0x010
+#define ETZPC_NUM_LOCKS 94
+
+struct stm32_etzpc {
+ struct regmap_field *fields[ETZPC_NUM_LOCKS];
+};
+
+static int stm32_etzpc_set_config(struct device *dev,
+ struct of_phandle_args *out_args)
+{
+ struct stm32_etzpc *etzpc = dev_get_drvdata(dev);
+ int index = out_args->args[0];
+ unsigned int value = out_args->args[1];
+ u32 status;
+
+ if (out_args->args_count != 2)
+ return -EINVAL;
+
+ if (index >= ETZPC_NUM_LOCKS)
+ return -EINVAL;
+
+ if (value > STM32_ETZPC_NON_SECURE)
+ return -EINVAL;
+
+ regmap_field_force_write(etzpc->fields[index], value);
+
+ /* Hardware could denied the new value, read it back to check it */
+ regmap_field_read(etzpc->fields[index], &status);
+
+ if (value != status) {
+ pr_info("failed to set configuration: index %d, value %d\n",
+ index, value);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static struct firewall_ops stm32_etzpc_ops = {
+ .set_config = stm32_etzpc_set_config,
+};
+
+static const struct regmap_config stm32_etzpc_regmap_cfg = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = sizeof(u32),
+ .max_register = 0x3FF,
+};
+
+static void stm32_etzpc_populate(struct device *parent)
+{
+ struct device_node *child;
+
+ if (!parent)
+ return;
+
+ for_each_available_child_of_node(dev_of_node(parent), child) {
+ if (firewall_set_default_config(child)) {
+ /*
+ * Failed to set firewall configuration mark the node
+ * as populated so platform bus won't probe it
+ */
+ of_node_set_flag(child, OF_POPULATED);
+ dev_info(parent, "%s: Bad firewall configuration\n",
+ child->name);
+ }
+ }
+}
+
+static int stm32_etzpc_probe(struct platform_device *pdev)
+{
+ struct stm32_etzpc *etzpc;
+ struct device *firewall;
+ struct regmap *regmap;
+ struct resource *res;
+ void __iomem *mmio;
+ int i;
+
+ etzpc = devm_kzalloc(&pdev->dev, sizeof(*etzpc), GFP_KERNEL);
+ if (!etzpc)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ mmio = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(mmio))
+ return PTR_ERR(mmio);
+
+ regmap = devm_regmap_init_mmio(&pdev->dev, mmio,
+ &stm32_etzpc_regmap_cfg);
+
+ for (i = 0; i < ETZPC_NUM_LOCKS; i++) {
+ struct reg_field field;
+
+ /*
+ * Each hardware block status is defined by
+ * a 2 bits field and all of them are packed into
+ * 32 bits registers. Do some computation to get
+ * register offset and the shift.
+ */
+ field.reg = ETZPC_DECPROT + (i >> 4) * sizeof(u32);
+ field.lsb = (i % 0x10) << 1;
+ field.msb = field.lsb + 1;
+
+ etzpc->fields[i] = devm_regmap_field_alloc(&pdev->dev,
+ regmap, field);
+ }
+
+ platform_set_drvdata(pdev, etzpc);
+
+ firewall = firewall_register(dev_of_node(&pdev->dev),
+ &stm32_etzpc_ops);
+ if (!firewall)
+ return -EINVAL;
+
+ dev_set_drvdata(firewall, etzpc);
+
+ stm32_etzpc_populate(&pdev->dev);
+
+ return 0;
+}
+
+static const struct of_device_id stm32_etzpc_of_match[] = {
+ { .compatible = "st,stm32-etzpc-bus" },
+ { /* end node */ }
+};
+MODULE_DEVICE_TABLE(of, stm32_etzpc_of_match);
+
+static struct platform_driver stm32_etzpc_driver = {
+ .probe = stm32_etzpc_probe,
+ .driver = {
+ .name = "stm32-etzpc",
+ .of_match_table = stm32_etzpc_of_match,
+ },
+};
+
+static int __init stm32_etzpc_init(void)
+{
+ return platform_driver_register(&stm32_etzpc_driver);
+}
+arch_initcall(stm32_etzpc_init);
+
+MODULE_AUTHOR("Benjamin Gaignard <benjamin.gaignard@st.com>");
+MODULE_DESCRIPTION("STMicroelectronics STM32 Bus Firewall Controller");
diff --git a/include/dt-bindings/bus/stm32/stm32-etzpc.h b/include/dt-bindings/bus/stm32/stm32-etzpc.h
new file mode 100644
index 000000000000..9c4783b9783c
--- /dev/null
+++ b/include/dt-bindings/bus/stm32/stm32-etzpc.h
@@ -0,0 +1,90 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) STMicroelectronics 2020 - All Rights Reserved
+ * Author: Benjamin Gaignard <benjamin.gaignard@st.com> for STMicroelectronics.
+ */
+
+#ifndef _STM32_ETZPC_H_
+#define _STM32_ETZPC_H_
+
+/* ETZPC configurations: trust-zone, non-secure or coprocessor*/
+#define STM32_ETZPC_TRUST 1
+#define STM32_ETPCZ_COPRO 2
+#define STM32_ETZPC_NON_SECURE 3
+
+/* ETZPC hard blocks index */
+#define STM32_ETZPC_USART1 3
+#define STM32_ETZPC_SPI6 4
+#define STM32_ETZPC_I2C4 5
+#define STM32_ETZPC_RNG1 7
+#define STM32_ETZPC_HASH1 8
+#define STM32_ETZPC_CRYP1 9
+#define STM32_ETZPC_I2C6 12
+#define STM32_ETZPC_TIM2 16
+#define STM32_ETZPC_TIM3 17
+#define STM32_ETZPC_TIM4 18
+#define STM32_ETZPC_TIM5 19
+#define STM32_ETZPC_TIM6 20
+#define STM32_ETZPC_TIM7 21
+#define STM32_ETZPC_TIM12 22
+#define STM32_ETZPC_TIM13 23
+#define STM32_ETZPC_TIM14 24
+#define STM32_ETZPC_LPTIM1 25
+#define STM32_ETZPC_SPI2 27
+#define STM32_ETZPC_SPI3 28
+#define STM32_ETZPC_USART2 30
+#define STM32_ETZPC_USART3 31
+#define STM32_ETZPC_USART4 32
+#define STM32_ETZPC_USART5 33
+#define STM32_ETZPC_I2C1 34
+#define STM32_ETZPC_I2C2 35
+#define STM32_ETZPC_I2C3 36
+#define STM32_ETZPC_I2C5 37
+#define STM32_ETZPC_CEC 38
+#define STM32_ETZPC_DAC 39
+#define STM32_ETZPC_UART7 40
+#define STM32_ETZPC_UART8 41
+#define STM32_ETZPC_MDIOS 44
+#define STM32_ETZPC_TIM1 48
+#define STM32_ETZPC_TIM8 49
+#define STM32_ETZPC_USART6 51
+#define STM32_ETZPC_SPI1 52
+#define STM32_ETZPC_SPI4 53
+#define STM32_ETZPC_TIM15 54
+#define STM32_ETZPC_TIM16 55
+#define STM32_ETZPC_TIM17 56
+#define STM32_ETZPC_SPI5 57
+#define STM32_ETZPC_SAI1 58
+#define STM32_ETZPC_SAI2 59
+#define STM32_ETZPC_SAI3 60
+#define STM32_ETZPC_DFSDM 61
+#define STM32_ETZPC_TT_FDCAN 62
+#define STM32_ETZPC_LPTIM2 64
+#define STM32_ETZPC_LPTIM3 65
+#define STM32_ETZPC_LPTIM4 66
+#define STM32_ETZPC_LPTIM5 67
+#define STM32_ETZPC_SAI4 68
+#define STM32_ETZPC_VREFBUF 69
+#define STM32_ETZPC_DCMI 70
+#define STM32_ETZPC_CRC2 71
+#define STM32_ETZPC_ADC 72
+#define STM32_ETZPC_HASH2 73
+#define STM32_ETZPC_RNG2 74
+#define STM32_ETZPC_CRYP2 75
+#define STM32_ETZPC_SRAM1 80
+#define STM32_ETZPC_SRAM2 81
+#define STM32_ETZPC_SRAM3 82
+#define STM32_ETZPC_SRAM4 83
+#define STM32_ETZPC_RETRAM 84
+#define STM32_ETZPC_OTG 85
+#define STM32_ETZPC_SDMMC3 86
+#define STM32_ETZPC_DLYBSD3 87
+#define STM32_ETZPC_DMA1 88
+#define STM32_ETZPC_DMA2 89
+#define STM32_ETZPC_DMAMUX 90
+#define STM32_ETZPC_FMC 91
+#define STM32_ETZPC_QSPI 92
+#define STM32_ETZPC_DLYBQ 93
+#define STM32_ETZPC_ETH1 94
+
+#endif /* _STM32_ETZPC_H_ */
--
2.15.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 1/5] dt-bindings: bus: Add firewall bindings
From: Benjamin Gaignard @ 2020-06-05 8:33 UTC (permalink / raw)
To: robh+dt, mcoquelin.stm32, alexandre.torgue, linus.walleij, gregkh
Cc: Benjamin Gaignard, tomase, linux-kernel, stefano.stabellini,
linux-stm32, linux-arm-kernel
In-Reply-To: <20200605083348.13880-1-benjamin.gaignard@st.com>
Add schemas for firewall consumer and provider.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
---
.../bindings/bus/stm32/firewall-consumer.yaml | 36 ++++++++++++++++++++++
.../bindings/bus/stm32/firewall-provider.yaml | 18 +++++++++++
2 files changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/bus/stm32/firewall-consumer.yaml
create mode 100644 Documentation/devicetree/bindings/bus/stm32/firewall-provider.yaml
diff --git a/Documentation/devicetree/bindings/bus/stm32/firewall-consumer.yaml b/Documentation/devicetree/bindings/bus/stm32/firewall-consumer.yaml
new file mode 100644
index 000000000000..d3d76f99b38d
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/stm32/firewall-consumer.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bus/stm32/firewall-consumer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common Bus Firewall consumer binding
+
+description: |
+ Firewall properties provide the possible firewall bus controller
+ configurations for a device.
+ Bus firewall controllers are typically used to control if a hardware
+ block can perform read or write operations on bus.
+ The contents of the firewall bus configuration properties are defined by
+ the binding for the individual firewall controller device.
+
+ The first configuration 'firewall-0' or the one named 'default' is
+ applied before probing the device itself.
+
+maintainers:
+ - Benjamin Gaignard <benjamin.gaignard@st.com>
+
+# always select the core schema
+select: true
+
+properties:
+ firewall-0: true
+
+ firewall-names: true
+
+patternProperties:
+ "firewall-[0-9]":
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+dependencies:
+ firewall-names: [ firewall-0 ]
diff --git a/Documentation/devicetree/bindings/bus/stm32/firewall-provider.yaml b/Documentation/devicetree/bindings/bus/stm32/firewall-provider.yaml
new file mode 100644
index 000000000000..299824c620ea
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/stm32/firewall-provider.yaml
@@ -0,0 +1,18 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bus/stm32/firewall-provider.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common Bus Firewall provider binding
+
+maintainers:
+ - Benjamin Gaignard <benjamin.gaignard@st.com>
+
+properties:
+ '#firewall-cells':
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Number of cells in a bus firewall specifier
+
+required:
+ - '#firewall-cells'
--
2.15.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 3/5] dt-bindings: bus: Add STM32 ETZPC firewall controller
From: Benjamin Gaignard @ 2020-06-05 8:33 UTC (permalink / raw)
To: robh+dt, mcoquelin.stm32, alexandre.torgue, linus.walleij, gregkh
Cc: Benjamin Gaignard, tomase, linux-kernel, stefano.stabellini,
linux-stm32, linux-arm-kernel
In-Reply-To: <20200605083348.13880-1-benjamin.gaignard@st.com>
Document STM32 ETZPC firewall controller bindings
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
.../bindings/bus/stm32/st,stm32-etzpc.yaml | 46 ++++++++++++++++++++++
1 file changed, 46 insertions(+)
create mode 100644 Documentation/devicetree/bindings/bus/stm32/st,stm32-etzpc.yaml
diff --git a/Documentation/devicetree/bindings/bus/stm32/st,stm32-etzpc.yaml b/Documentation/devicetree/bindings/bus/stm32/st,stm32-etzpc.yaml
new file mode 100644
index 000000000000..d92865fda40c
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/stm32/st,stm32-etzpc.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bus/stm32/st,stm32-etzpc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STM32 Extended TrustZone Protection controller
+
+maintainers:
+ - Benjamin Gaignard <benjamin.gaignard@st.com>
+
+description: STMicroelectronics's STM32 firewall bus controller implementation
+
+allOf:
+ - $ref: "firewall-provider.yaml#"
+ - $ref: /schemas/simple-bus.yaml#
+
+properties:
+ compatible:
+ contains:
+ enum:
+ - st,stm32-etzpc-bus
+
+ reg:
+ maxItems: 1
+
+ '#firewall-cells':
+ const: 2
+
+required:
+ - compatible
+ - reg
+ - '#firewall-cells'
+
+examples:
+ - |
+ soc@5c007000 {
+ compatible = "st,stm32-etzpc-bus", "simple-bus";
+ reg = <0x5c007000 0x400>;
+ #firewall-cells = <2>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ };
+
+...
--
2.15.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 5/5] ARM: dts: stm32: Use ETZPC firewall bus
From: Benjamin Gaignard @ 2020-06-05 8:33 UTC (permalink / raw)
To: robh+dt, mcoquelin.stm32, alexandre.torgue, linus.walleij, gregkh
Cc: Benjamin Gaignard, tomase, linux-kernel, stefano.stabellini,
linux-stm32, linux-arm-kernel
In-Reply-To: <20200605083348.13880-1-benjamin.gaignard@st.com>
Allow STM32 ETZPC to check firewall configuration before populating
the platform bus.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
arch/arm/boot/dts/stm32mp151.dtsi | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/stm32mp151.dtsi b/arch/arm/boot/dts/stm32mp151.dtsi
index 3ea05ba48215..0290eb6f3c35 100644
--- a/arch/arm/boot/dts/stm32mp151.dtsi
+++ b/arch/arm/boot/dts/stm32mp151.dtsi
@@ -4,6 +4,7 @@
* Author: Ludovic Barre <ludovic.barre@st.com> for STMicroelectronics.
*/
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/bus/stm32/stm32-etzpc.h>
#include <dt-bindings/clock/stm32mp1-clks.h>
#include <dt-bindings/reset/stm32mp1-resets.h>
@@ -110,8 +111,10 @@
status = "disabled";
};
- soc {
- compatible = "simple-bus";
+ etzpc_bus: soc@5c007000 {
+ compatible = "st,stm32-etzpc-bus", "simple-bus";
+ reg = <0x5c007000 0x400>;
+ #firewall-cells = <2>;
#address-cells = <1>;
#size-cells = <1>;
interrupt-parent = <&intc>;
--
2.15.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 0/5] STM32 ETZPC bus controller
From: Benjamin Gaignard @ 2020-06-05 8:33 UTC (permalink / raw)
To: robh+dt, mcoquelin.stm32, alexandre.torgue, linus.walleij, gregkh
Cc: Benjamin Gaignard, tomase, linux-kernel, stefano.stabellini,
linux-stm32, linux-arm-kernel
STM32 Extended TrustZone Protection controller act like a firewall on the
platform bus. Depending of its configuration devices could be accessible
by the TrustZone, the co-processor or the non-secure world. ETZPC
configuration could evolve at runtime for example to switch a device from
non-secure world to co-processor.
The series introduce 'firewall' helpers to handle the new devices-tree
properties. These properties are not dedicated to ETZPC and will be reused
for STM32 next generation of bus controller.
version 4:
- use bus API
version 3:
- add description in firewall consumer bindings
- add Linus reviewed-by tag
version 2:
- fix unit name into st,stm32-etzpc.yaml example and DT
Benjamin Gaignard (5):
dt-bindings: bus: Add firewall bindings
bus: stm32: Introduce firewall controller helpers
dt-bindings: bus: Add STM32 ETZPC firewall controller
bus: stm32: Add stm32 ETZPC firewall bus controller
ARM: dts: stm32: Use ETZPC firewall bus
.../bindings/bus/stm32/firewall-consumer.yaml | 36 +++
.../bindings/bus/stm32/firewall-provider.yaml | 18 ++
.../bindings/bus/stm32/st,stm32-etzpc.yaml | 46 ++++
arch/arm/boot/dts/stm32mp151.dtsi | 7 +-
drivers/bus/Kconfig | 2 +
drivers/bus/Makefile | 2 +
drivers/bus/stm32/Kconfig | 11 +
drivers/bus/stm32/Makefile | 2 +
drivers/bus/stm32/firewall.c | 251 +++++++++++++++++++++
drivers/bus/stm32/firewall.h | 66 ++++++
drivers/bus/stm32/stm32-etzpc.c | 163 +++++++++++++
include/dt-bindings/bus/stm32/stm32-etzpc.h | 90 ++++++++
12 files changed, 692 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/bus/stm32/firewall-consumer.yaml
create mode 100644 Documentation/devicetree/bindings/bus/stm32/firewall-provider.yaml
create mode 100644 Documentation/devicetree/bindings/bus/stm32/st,stm32-etzpc.yaml
create mode 100644 drivers/bus/stm32/Kconfig
create mode 100644 drivers/bus/stm32/Makefile
create mode 100644 drivers/bus/stm32/firewall.c
create mode 100644 drivers/bus/stm32/firewall.h
create mode 100644 drivers/bus/stm32/stm32-etzpc.c
create mode 100644 include/dt-bindings/bus/stm32/stm32-etzpc.h
--
2.15.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump
From: Nicolas Saenz Julienne @ 2020-06-05 8:21 UTC (permalink / raw)
To: John Donnelly, Bhupesh Sharma
Cc: Devicetree List, Arnd Bergmann, Baoquan He,
Linux Doc Mailing List, chenzhou, Catalin Marinas, RuiRui Yang,
Prabhakar Kushwaha, kexec mailing list, Linux Kernel Mailing List,
Rob Herring, Simon Horman, James Morse, guohanjun,
Thomas Gleixner, Prabhakar Kushwaha, Will Deacon, Ingo Molnar,
linux-arm-kernel
In-Reply-To: <de6c7c59-89d2-5b2e-d7ba-50403c4bcaf2@oracle.com>
[-- Attachment #1.1: Type: text/plain, Size: 19044 bytes --]
On Thu, 2020-06-04 at 21:26 -0500, John Donnelly wrote:
> On 6/4/20 12:01 PM, Nicolas Saenz Julienne wrote:
> > On Thu, 2020-06-04 at 01:17 +0530, Bhupesh Sharma wrote:
> > > Hi All,
> > >
> > > On Wed, Jun 3, 2020 at 9:03 PM John Donnelly <john.p.donnelly@oracle.com>
> > > wrote:
> > > > > On Jun 3, 2020, at 8:20 AM, chenzhou <chenzhou10@huawei.com> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > >
> > > > > On 2020/6/3 19:47, Prabhakar Kushwaha wrote:
> > > > > > Hi Chen,
> > > > > >
> > > > > > On Tue, Jun 2, 2020 at 8:12 PM John Donnelly <
> > > > > > john.p.donnelly@oracle.com
> > > > > > > wrote:
> > > > > > >
> > > > > > > > On Jun 2, 2020, at 12:38 AM, Prabhakar Kushwaha <
> > > > > > > > prabhakar.pkin@gmail.com> wrote:
> > > > > > > >
> > > > > > > > On Tue, Jun 2, 2020 at 3:29 AM John Donnelly <
> > > > > > > > john.p.donnelly@oracle.com> wrote:
> > > > > > > > > Hi . See below !
> > > > > > > > >
> > > > > > > > > > On Jun 1, 2020, at 4:02 PM, Bhupesh Sharma <
> > > > > > > > > > bhsharma@redhat.com>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Hi John,
> > > > > > > > > >
> > > > > > > > > > On Tue, Jun 2, 2020 at 1:01 AM John Donnelly <
> > > > > > > > > > John.P.donnelly@oracle.com> wrote:
> > > > > > > > > > > Hi,
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On 6/1/20 7:02 AM, Prabhakar Kushwaha wrote:
> > > > > > > > > > > > Hi Chen,
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, May 21, 2020 at 3:05 PM Chen Zhou <
> > > > > > > > > > > > chenzhou10@huawei.com> wrote:
> > > > > > > > > > > > > This patch series enable reserving crashkernel above
> > > > > > > > > > > > > 4G in
> > > > > > > > > > > > > arm64.
> > > > > > > > > > > > >
> > > > > > > > > > > > > There are following issues in arm64 kdump:
> > > > > > > > > > > > > 1. We use crashkernel=X to reserve crashkernel below
> > > > > > > > > > > > > 4G,
> > > > > > > > > > > > > which will fail
> > > > > > > > > > > > > when there is no enough low memory.
> > > > > > > > > > > > > 2. Currently, crashkernel=Y@X can be used to reserve
> > > > > > > > > > > > > crashkernel above 4G,
> > > > > > > > > > > > > in this case, if swiotlb or DMA buffers are required,
> > > > > > > > > > > > > crash dump kernel
> > > > > > > > > > > > > will boot failure because there is no low memory
> > > > > > > > > > > > > available
> > > > > > > > > > > > > for allocation.
> > > > > > > > > > > > >
> > > > > > > > > > > > We are getting "warn_alloc" [1] warning during boot of
> > > > > > > > > > > > kdump
> > > > > > > > > > > > kernel
> > > > > > > > > > > > with bootargs as [2] of primary kernel.
> > > > > > > > > > > > This error observed on ThunderX2 ARM64 platform.
> > > > > > > > > > > >
> > > > > > > > > > > > It is observed with latest upstream tag (v5.7-rc3) with
> > > > > > > > > > > > this
> > > > > > > > > > > > patch set
> > > > > > > > > > > > and
> > > > > > > > > > > >
> >
https://urldefense.com/v3/__https://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbiIAAlzu$
> > > > > > > > > > > > Also **without** this patch-set
> > > > > > > > > > > > "
> > > > > > > > > > > >
> >
https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$
> > > > > > > > > > > > "
> > > > > > > > > > > >
> > > > > > > > > > > > This issue comes whenever crashkernel memory is reserved
> > > > > > > > > > > > after 0xc000_0000.
> > > > > > > > > > > > More details discussed earlier in
> > > > > > > > > > > >
> >
https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$
> > without
> > > > > > > > > > > > any
> > > > > > > > > > > > solution
> > > > > > > > > > > >
> > > > > > > > > > > > This patch-set is expected to solve similar kind of
> > > > > > > > > > > > issue.
> > > > > > > > > > > > i.e. low memory is only targeted for DMA, swiotlb; So
> > > > > > > > > > > > above
> > > > > > > > > > > > mentioned
> > > > > > > > > > > > observation should be considered/fixed. .
> > > > > > > > > > > >
> > > > > > > > > > > > --pk
> > > > > > > > > > > >
> > > > > > > > > > > > [1]
> > > > > > > > > > > > [ 30.366695] DMI: Cavium Inc. Saber/Saber, BIOS
> > > > > > > > > > > > TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
> > > > > > > > > > > > [ 30.367696] NET: Registered protocol family 16
> > > > > > > > > > > > [ 30.369973] swapper/0: page allocation failure:
> > > > > > > > > > > > order:6,
> > > > > > > > > > > > mode:0x1(GFP_DMA),
> > > > > > > > > > > > nodemask=(null),cpuset=/,mems_allowed=0
> > > > > > > > > > > > [ 30.369980] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> > > > > > > > > > > > 5.7.0-rc3+ #121
> > > > > > > > > > > > [ 30.369981] Hardware name: Cavium Inc. Saber/Saber,
> > > > > > > > > > > > BIOS
> > > > > > > > > > > > TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
> > > > > > > > > > > > [ 30.369984] Call trace:
> > > > > > > > > > > > [ 30.369989] dump_backtrace+0x0/0x1f8
> > > > > > > > > > > > [ 30.369991] show_stack+0x20/0x30
> > > > > > > > > > > > [ 30.369997] dump_stack+0xc0/0x10c
> > > > > > > > > > > > [ 30.370001] warn_alloc+0x10c/0x178
> > > > > > > > > > > > [ 30.370004] __alloc_pages_slowpath.constprop.111+0xb
> > > > > > > > > > > > 10/0
> > > > > > > > > > > > xb50
> > > > > > > > > > > > [ 30.370006] __alloc_pages_nodemask+0x2b4/0x300
> > > > > > > > > > > > [ 30.370008] alloc_page_interleave+0x24/0x98
> > > > > > > > > > > > [ 30.370011] alloc_pages_current+0xe4/0x108
> > > > > > > > > > > > [ 30.370017] dma_atomic_pool_init+0x44/0x1a4
> > > > > > > > > > > > [ 30.370020] do_one_initcall+0x54/0x228
> > > > > > > > > > > > [ 30.370027] kernel_init_freeable+0x228/0x2cc
> > > > > > > > > > > > [ 30.370031] kernel_init+0x1c/0x110
> > > > > > > > > > > > [ 30.370034] ret_from_fork+0x10/0x18
> > > > > > > > > > > > [ 30.370036] Mem-Info:
> > > > > > > > > > > > [ 30.370064] active_anon:0 inactive_anon:0
> > > > > > > > > > > > isolated_anon:0
> > > > > > > > > > > > [ 30.370064] active_file:0 inactive_file:0
> > > > > > > > > > > > isolated_file:0
> > > > > > > > > > > > [ 30.370064] unevictable:0 dirty:0 writeback:0
> > > > > > > > > > > > unstable:0
> > > > > > > > > > > > [ 30.370064] slab_reclaimable:34
> > > > > > > > > > > > slab_unreclaimable:4438
> > > > > > > > > > > > [ 30.370064] mapped:0 shmem:0 pagetables:14 bounce:0
> > > > > > > > > > > > [ 30.370064] free:1537719 free_pcp:219 free_cma:0
> > > > > > > > > > > > [ 30.370070] Node 0 active_anon:0kB inactive_anon:0kB
> > > > > > > > > > > > active_file:0kB inactive_file:0kB unevictable:0kB
> > > > > > > > > > > > isolated(anon):0kB
> > > > > > > > > > > > isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB
> > > > > > > > > > > > shmem:0kB
> > > > > > > > > > > > shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB
> > > > > > > > > > > > writeback_tmp:0kB
> > > > > > > > > > > > unstable:0kB all_unreclaimable? no
> > > > > > > > > > > > [ 30.370073] Node 1 active_anon:0kB inactive_anon:0kB
> > > > > > > > > > > > active_file:0kB inactive_file:0kB unevictable:0kB
> > > > > > > > > > > > isolated(anon):0kB
> > > > > > > > > > > > isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB
> > > > > > > > > > > > shmem:0kB
> > > > > > > > > > > > shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB
> > > > > > > > > > > > writeback_tmp:0kB
> > > > > > > > > > > > unstable:0kB all_unreclaimable? no
> > > > > > > > > > > > [ 30.370079] Node 0 DMA free:0kB min:0kB low:0kB
> > > > > > > > > > > > high:0kB
> > > > > > > > > > > > reserved_highatomic:0KB active_anon:0kB
> > > > > > > > > > > > inactive_anon:0kB
> > > > > > > > > > > > active_file:0kB inactive_file:0kB unevictable:0kB
> > > > > > > > > > > > writepending:0kB
> > > > > > > > > > > > present:128kB managed:0kB mlocked:0kB kernel_stack:0kB
> > > > > > > > > > > > pagetables:0kB
> > > > > > > > > > > > bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> > > > > > > > > > > > [ 30.370084] lowmem_reserve[]: 0 250 6063 6063
> > > > > > > > > > > > [ 30.370090] Node 0 DMA32 free:256000kB min:408kB
> > > > > > > > > > > > low:664kB
> > > > > > > > > > > > high:920kB reserved_highatomic:0KB active_anon:0kB
> > > > > > > > > > > > inactive_anon:0kB
> > > > > > > > > > > > active_file:0kB inactive_file:0kB unevictable:0kB
> > > > > > > > > > > > writepending:0kB
> > > > > > > > > > > > present:269700kB managed:256000kB mlocked:0kB
> > > > > > > > > > > > kernel_stack:0kB
> > > > > > > > > > > > pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB
> > > > > > > > > > > > free_cma:0kB
> > > > > > > > > > > > [ 30.370094] lowmem_reserve[]: 0 0 5813 5813
> > > > > > > > > > > > [ 30.370100] Node 0 Normal free:5894876kB min:9552kB
> > > > > > > > > > > > low:15504kB
> > > > > > > > > > > > high:21456kB reserved_highatomic:0KB active_anon:0kB
> > > > > > > > > > > > inactive_anon:0kB
> > > > > > > > > > > > active_file:0kB inactive_file:0kB unevictable:0kB
> > > > > > > > > > > > writepending:0kB
> > > > > > > > > > > > present:8388608kB managed:5953112kB mlocked:0kB
> > > > > > > > > > > > kernel_stack:21672kB
> > > > > > > > > > > > pagetables:56kB bounce:0kB free_pcp:876kB
> > > > > > > > > > > > local_pcp:176kB
> > > > > > > > > > > > free_cma:0kB
> > > > > > > > > > > > [ 30.370104] lowmem_reserve[]: 0 0 0 0
> > > > > > > > > > > > [ 30.370107] Node 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB
> > > > > > > > > > > > 0*64kB
> > > > > > > > > > > > 0*128kB
> > > > > > > > > > > > 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
> > > > > > > > > > > > [ 30.370113] Node 0 DMA32: 0*4kB 0*8kB 0*16kB 0*32kB
> > > > > > > > > > > > 0*64kB 0*128kB
> > > > > > > > > > > > 0*256kB 0*512kB 0*1024kB 1*2048kB (M) 62*4096kB (M) =
> > > > > > > > > > > > 256000kB
> > > > > > > > > > > > [ 30.370119] Node 0 Normal: 2*4kB (M) 3*8kB (ME)
> > > > > > > > > > > > 2*16kB
> > > > > > > > > > > > (UE) 3*32kB
> > > > > > > > > > > > (UM) 1*64kB (U) 2*128kB (M) 2*256kB (ME) 3*512kB (ME)
> > > > > > > > > > > > 3*1024kB (ME)
> > > > > > > > > > > > 3*2048kB (UME) 1436*4096kB (M) = 5893600kB
> > > > > > > > > > > > [ 30.370129] Node 0 hugepages_total=0 hugepages_free=0
> > > > > > > > > > > > hugepages_surp=0 hugepages_size=1048576kB
> > > > > > > > > > > > [ 30.370130] 0 total pagecache pages
> > > > > > > > > > > > [ 30.370132] 0 pages in swap cache
> > > > > > > > > > > > [ 30.370134] Swap cache stats: add 0, delete 0, find
> > > > > > > > > > > > 0/0
> > > > > > > > > > > > [ 30.370135] Free swap = 0kB
> > > > > > > > > > > > [ 30.370136] Total swap = 0kB
> > > > > > > > > > > > [ 30.370137] 2164609 pages RAM
> > > > > > > > > > > > [ 30.370139] 0 pages HighMem/MovableOnly
> > > > > > > > > > > > [ 30.370140] 612331 pages reserved
> > > > > > > > > > > > [ 30.370141] 0 pages hwpoisoned
> > > > > > > > > > > > [ 30.370143] DMA: failed to allocate 256 KiB pool for
> > > > > > > > > > > > atomic
> > > > > > > > > > > > coherent allocation
> > > > > > > > > > > During my testing I saw the same error and
> > > > > > > > > > > Chen's solution
> > > > > > > > > > > corrected it .
> > > > > > > > > > Which combination you are using on your side? I am using
> > > > > > > > > > Prabhakar's
> > > > > > > > > > suggested environment and can reproduce the issue
> > > > > > > > > > with or without Chen's crashkernel support above 4G
> > > > > > > > > > patchset.
> > > > > > > > > >
> > > > > > > > > > I am also using a ThunderX2 platform with latest
> > > > > > > > > > makedumpfile
> > > > > > > > > > code and
> > > > > > > > > > kexec-tools (with the suggested patch
> > > > > > > > > > <
> > > > > > > > > >
> >
https://urldefense.com/v3/__https://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!J6lUig58-Gw6TKZnEEYzEeSU36T-1SqlB1kImU00xtX_lss5Tx-JbUmLE9TJC3foXBLg$
> > > > > > > > > > > ).
> > > > > > > > > > Thanks,
> > > > > > > > > > Bhupesh
> > > > > > > > > I did this activity 5 months ago and I have moved on to other
> > > > > > > > > activities. My DMA failures were related to PCI devices that
> > > > > > > > > could
> > > > > > > > > not be enumerated because low-DMA space was not available
> > > > > > > > > when
> > > > > > > > > crashkernel was moved above 4G; I don’t recall the exact
> > > > > > > > > platform.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > For this failure ,
> > > > > > > > >
> > > > > > > > > > > > DMA: failed to allocate 256 KiB pool for atomic
> > > > > > > > > > > > coherent allocation
> > > > > > > > > Is due to :
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > 3618082c
> > > > > > > > > ("arm64 use both ZONE_DMA and ZONE_DMA32")
> > > > > > > > >
> > > > > > > > > With the introduction of ZONE_DMA to support the Raspberry DMA
> > > > > > > > > region below 1G, the crashkernel is placed in the upper 4G
> > > > > > > > > ZONE_DMA_32 region. Since the crashkernel does not have access
> > > > > > > > > to the ZONE_DMA region, it prints out call trace during
> > > > > > > > > bootup.
> > > > > > > > >
> > > > > > > > > It is due to having this CONFIG item ON :
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > CONFIG_ZONE_DMA=y
> > > > > > > > >
> > > > > > > > > Turning off ZONE_DMA fixes a issue and Raspberry PI 4 will
> > > > > > > > > use the device tree to specify memory below 1G.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > Disabling ZONE_DMA is temporary solution. We may need proper
> > > > > > > > solution
> > > > > > > Perhaps the Raspberry platform configuration dependencies need
> > > > > > > separated from “server class” Arm equipment ? Or auto-
> > > > > > > configured on
> > > > > > > boot ? Consult an expert ;-)
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > > I would like to see Chen’s feature added , perhaps as
> > > > > > > > > EXPERIMENTAL, so we can get some configuration testing done
> > > > > > > > > on
> > > > > > > > > it. It corrects having a DMA zone in low memory while crash-
> > > > > > > > > kernel is above 4GB. This has been going on for a year now.
> > > > > > > > I will also like this patch to be added in Linux as early as
> > > > > > > > possible.
> > > > > > > >
> > > > > > > > Issue mentioned by me happens with or without this patch.
> > > > > > > >
> > > > > > > > This patch-set can consider fixing because it uses low memory
> > > > > > > > for
> > > > > > > > DMA
> > > > > > > > & swiotlb only.
> > > > > > > > We can consider restricting crashkernel within the required
> > > > > > > > range
> > > > > > > > like below
> > > > > > > >
> > > > > > > > diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> > > > > > > > index 7f9e5a6dc48c..bd67b90d35bd 100644
> > > > > > > > --- a/kernel/crash_core.c
> > > > > > > > +++ b/kernel/crash_core.c
> > > > > > > > @@ -354,7 +354,7 @@ int __init reserve_crashkernel_low(void)
> > > > > > > > return 0;
> > > > > > > > }
> > > > > > > >
> > > > > > > > - low_base = memblock_find_in_range(0, 1ULL << 32,
> > > > > > > > low_size,
> > > > > > > > CRASH_ALIGN);
> > > > > > > > + low_base = memblock_find_in_range(0,0xc0000000,
> > > > > > > > low_size,
> > > > > > > > CRASH_ALIGN);
> > > > > > > > if (!low_base) {
> > > > > > > > pr_err("Cannot reserve %ldMB crashkernel low
> > > > > > > > memory,
> > > > > > > > please try smaller size.\n",
> > > > > > > > (unsigned long)(low_size >> 20));
> > > > > > > >
> > > > > > > >
> > > > > > > I suspect 0xc0000000 would need to be a CONFIG item and not
> > > > > > > hard-coded.
> > > > > > >
> > > > > > if you consider this as valid change, can you please incorporate as
> > > > > > part of your patch-set.
> > > > > After commit 1a8e1cef7 ("arm64: use both ZONE_DMA and ZONE_DMA32"),the
> > > > > 0-
> > > > > 4G memory is splited
> > > > > to DMA [mem 0x0000000000000000-0x000000003fffffff] and DMA32 [mem
> > > > > 0x0000000040000000-0x00000000ffffffff] on arm64.
> > > > >
> > > > > From the above discussion, on your platform, the low crashkernel fall
> > > > > in
> > > > > DMA32 region, but your environment needs to access DMA
> > > > > region, so there is the call trace.
> > > > >
> > > > > I have a question, why do you choose 0xc0000000 here?
> > > > >
> > > > > Besides, this is common code, we also need to consider about x86.
> > > > >
> > > > + nsaenzjulienne@suse.de
> > Thanks for adding me to the conversation, and sorry for the headaches.
> >
> > > > Exactly . This is why it needs to be a CONFIG option for Raspberry
> > > > .., or device tree option.
> > > >
> > > >
> > > > We could revert 1a8e1cef7 since it broke Arm kdump too.
> > > Well, unfortunately the patch for commit 1a8e1cef7603 ("arm64: use
> > > both ZONE_DMA and ZONE_DMA32") was not Cc'ed to the kexec mailing
> > > list, thus we couldn't get many eyes on it for a thorough review from
> > > kexec/kdump p-o-v.
> > >
> > > Also we historically never had distinction in common arch code on the
> > > basis of the intended end use-case: embedded, server or automotive, so
> > > I am not sure introducing a Raspberry specific CONFIG option would be
> > > a good idea.
> > +1
> >
> > From the distros perspective it's very important to keep a single kernel
> > image.
> >
> > > So, rather than reverting the patch, we can look at addressing the
> > > same properly this time - especially from a kdump p-o-v.
> > > This issue has been reported by some Red Hat arm64 partners with
> > > upstream kernel also and as we have noticed in the past as well,
> > > hardcoding the placement of the crashkernel base address (unless the
> > > base address is specified by a crashkernel=X@Y like bootargs) is also
> > > not a portable suggestion.
> > >
> > > I am working on a possible fix and will have more updates on the same
> > > in a day-or-two.
> > Please keep me in the loop, we've also had issues pointing to this reported
> > by
> > SUSE partners. I can do some testing both on the RPi4 and on big servers
> > that
> > need huge crashkernel sizes.
> >
> > Regards,
> > Nicolas
> >
> Hi Nicolas,
>
>
> You want want to review this topic with the various email threads . It
> has been a long journey.
Will do, thanks!
Regards,
Nicolas
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 05/11] pwm: add support for sl28cpld PWM controller
From: Andy Shevchenko @ 2020-06-05 8:15 UTC (permalink / raw)
To: Michael Walle
Cc: devicetree, Linus Walleij, Thierry Reding, Lee Jones,
Jason Cooper, Andy Shevchenko, Marc Zyngier, Bartosz Golaszewski,
Uwe Kleine-König, Guenter Roeck, linux-pwm, Jean Delvare,
linux-watchdog, open list:GPIO SUBSYSTEM, Mark Brown,
Thomas Gleixner, Wim Van Sebroeck, linux-arm Mailing List,
linux-hwmon, Greg Kroah-Hartman, Linux Kernel Mailing List,
Li Yang, Rob Herring, Shawn Guo
In-Reply-To: <20200604211039.12689-6-michael@walle.cc>
On Fri, Jun 5, 2020 at 12:16 AM Michael Walle <michael@walle.cc> wrote:
>
> Add support for the PWM controller of the sl28cpld board management
> controller. This is part of a multi-function device driver.
>
> The controller has one PWM channel and can just generate four distinct
> frequencies.
So same comments (extra comma, cargo cult headers, etc) are applied
here and perhaps to all other patches in the series.
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 04/11] watchdog: add support for sl28cpld watchdog
From: Andy Shevchenko @ 2020-06-05 8:14 UTC (permalink / raw)
To: Michael Walle
Cc: devicetree, Linus Walleij, Thierry Reding, Lee Jones,
Jason Cooper, Andy Shevchenko, Marc Zyngier, Bartosz Golaszewski,
Uwe Kleine-König, Guenter Roeck, linux-pwm, Jean Delvare,
linux-watchdog, open list:GPIO SUBSYSTEM, Mark Brown,
Thomas Gleixner, Wim Van Sebroeck, linux-arm Mailing List,
linux-hwmon, Greg Kroah-Hartman, Linux Kernel Mailing List,
Li Yang, Rob Herring, Shawn Guo
In-Reply-To: <20200604211039.12689-5-michael@walle.cc>
On Fri, Jun 5, 2020 at 12:14 AM Michael Walle <michael@walle.cc> wrote:
>
> Add support for the watchdog of the sl28cpld board management
> controller. This is part of a multi-function device driver.
...
> +#include <linux/of_device.h>
Didn't find a user of this.
...
> +static bool nowayout = WATCHDOG_NOWAYOUT;
> +module_param(nowayout, bool, 0);
> +MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
> + __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
> +
> +static int timeout;
> +module_param(timeout, int, 0);
> +MODULE_PARM_DESC(timeout, "Initial watchdog timeout in seconds");
Guenter ACKed this, but I'm wondering why we still need module parameters...
...
> + int ret;
> +
> + ret = regmap_read(wdt->regmap, wdt->offset + WDT_COUNT, &val);
> +
> + return (ret < 0) ? 0 : val;
Besides extra parentheses and questionable ' < 0' part, the following
would look better I think
ret = ...
if (ret)
return 0;
return val;
...
> + int ret;
> +
> + ret = regmap_write(wdt->regmap, wdt->offset + WDT_TIMEOUT, timeout);
> + if (!ret)
> + wdd->timeout = timeout;
> +
> + return ret;
Similar story here:
ret = ...
if (ret)
return ret;
wdd->... = ...
return 0;
...
> + ret = regmap_read(wdt->regmap, wdt->offset + WDT_CTRL, &status);
> + if (ret < 0)
What ' < 0' means? Do we have some positive return values?
Ditto for all your code.
> + return ret;
...
> + if (status & WDT_CTRL_EN) {
> + sl28cpld_wdt_start(wdd);
> + set_bit(WDOG_HW_RUNNING, &wdd->status);
Do you need atomic op here? Why?
> + }
...
> +static const struct of_device_id sl28cpld_wdt_of_match[] = {
> + { .compatible = "kontron,sl28cpld-wdt" },
> + {},
No comma.
> +};
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Security Random Number Generator support
From: Russell King - ARM Linux admin @ 2020-06-05 8:09 UTC (permalink / raw)
To: Neal Liu
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Julius Werner, Herbert Xu, Arnd Bergmann, Marc Zyngier,
Matt Mackall, Sean Wang, lkml, wsd_upstream, Rob Herring,
linux-mediatek@lists.infradead.org, Linux Crypto Mailing List,
Greg Kroah-Hartman, Matthias Brugger,
Crystal Guo (郭晶), Ard Biesheuvel, Linux ARM
In-Reply-To: <1591341543.19510.4.camel@mtkswgap22>
On Fri, Jun 05, 2020 at 03:19:03PM +0800, Neal Liu wrote:
> On Wed, 2020-06-03 at 17:34 +0800, Russell King - ARM Linux admin wrote:
> > This kind of thing is something that ARM have seems to shy away from
> > doing - it's a point I brought up many years ago when the whole
> > trustzone thing first appeared with its SMC call. Those around the
> > conference table were not interested - ARM seemed to prefer every
> > vendor to do off and do their own thing with the SMC interface.
>
> Does that mean it make sense to model a sec-rng driver, and get each
> vendor's SMC function id by DT node?
_If_ vendors have already gone off and decided to use different SMC
function IDs for this, while keeping the rest of the SMC interface
the same, then the choice has already been made.
I know on 32-bit that some of the secure world implementations can't
be changed; they're burnt into the ROM. I believe on 64-bit that isn't
the case, which makes it easier to standardise.
Do you have visibility of how this SMC is implemented in the secure
side? Is it in ATF, and is it done as a vendor hack or is there an
element of generic implementation to it? Has it been submitted
upstream to the main ATF repository?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 03/11] irqchip: add sl28cpld interrupt controller support
From: Andy Shevchenko @ 2020-06-05 8:07 UTC (permalink / raw)
To: Michael Walle
Cc: devicetree, Linus Walleij, Thierry Reding, Lee Jones,
Jason Cooper, Andy Shevchenko, Marc Zyngier, Bartosz Golaszewski,
Uwe Kleine-König, Guenter Roeck, linux-pwm, Jean Delvare,
linux-watchdog, open list:GPIO SUBSYSTEM, Mark Brown,
Thomas Gleixner, Wim Van Sebroeck, linux-arm Mailing List,
linux-hwmon, Greg Kroah-Hartman, Linux Kernel Mailing List,
Li Yang, Rob Herring, Shawn Guo
In-Reply-To: <20200604211039.12689-4-michael@walle.cc>
On Fri, Jun 5, 2020 at 12:13 AM Michael Walle <michael@walle.cc> wrote:
>
> Add support for the interrupt controller inside the sl28 CPLD management
> controller.
>
> The interrupt controller can handle at most 8 interrupts and is really
> simplistic and consists only of an interrupt mask and an interrupt
> pending register.
...
> +config SL28CPLD_INTC
> + bool
Same Q: Why not module?
...
> +static const struct of_device_id sl28cpld_intc_of_match[] = {
> + { .compatible = "kontron,sl28cpld-intc" },
> + {},
There is no point to have comma in terminator line.
> +};
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 08/14] media: platform: Change case for improving code quality
From: Xia Jiang @ 2020-06-05 8:04 UTC (permalink / raw)
To: Hans Verkuil
Cc: drinkcat, devicetree, mojahsu, srv_heupstream, Rick Chang,
senozhatsky, linux-kernel, Tomasz Figa, maoguang.meng,
Matthias Brugger, sj.huang, Rob Herring, linux-mediatek,
Mauro Carvalho Chehab, Marek Szyprowski, linux-arm-kernel,
linux-media
In-Reply-To: <4b8cc41e-5171-0d48-f588-96e4212ab22c@xs4all.nl>
On Mon, 2020-05-11 at 10:37 +0200, Hans Verkuil wrote:
> On 03/04/2020 11:40, Xia Jiang wrote:
> > Change register offset hex numberals from upercase to lowercase.
>
> Typos:
>
> numberals -> numerals
>
> upercase -> uppercase
Done.
>
> Regards,
>
> Hans
>
> >
> > Signed-off-by: Xia Jiang <xia.jiang@mediatek.com>
> > ---
> > v8: no changes
> > ---
> > drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h | 18 +++++++++---------
> > 1 file changed, 9 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h b/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h
> > index 94db04e9cdb6..2945da842dfa 100644
> > --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h
> > +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h
> > @@ -20,29 +20,29 @@
> > #define BIT_INQST_MASK_ALLIRQ 0x37
> >
> > #define JPGDEC_REG_RESET 0x0090
> > -#define JPGDEC_REG_BRZ_FACTOR 0x00F8
> > -#define JPGDEC_REG_DU_NUM 0x00FC
> > +#define JPGDEC_REG_BRZ_FACTOR 0x00f8
> > +#define JPGDEC_REG_DU_NUM 0x00fc
> > #define JPGDEC_REG_DEST_ADDR0_Y 0x0140
> > #define JPGDEC_REG_DEST_ADDR0_U 0x0144
> > #define JPGDEC_REG_DEST_ADDR0_V 0x0148
> > -#define JPGDEC_REG_DEST_ADDR1_Y 0x014C
> > +#define JPGDEC_REG_DEST_ADDR1_Y 0x014c
> > #define JPGDEC_REG_DEST_ADDR1_U 0x0150
> > #define JPGDEC_REG_DEST_ADDR1_V 0x0154
> > #define JPGDEC_REG_STRIDE_Y 0x0158
> > -#define JPGDEC_REG_STRIDE_UV 0x015C
> > +#define JPGDEC_REG_STRIDE_UV 0x015c
> > #define JPGDEC_REG_IMG_STRIDE_Y 0x0160
> > #define JPGDEC_REG_IMG_STRIDE_UV 0x0164
> > -#define JPGDEC_REG_WDMA_CTRL 0x016C
> > +#define JPGDEC_REG_WDMA_CTRL 0x016c
> > #define JPGDEC_REG_PAUSE_MCU_NUM 0x0170
> > -#define JPGDEC_REG_OPERATION_MODE 0x017C
> > +#define JPGDEC_REG_OPERATION_MODE 0x017c
> > #define JPGDEC_REG_FILE_ADDR 0x0200
> > -#define JPGDEC_REG_COMP_ID 0x020C
> > +#define JPGDEC_REG_COMP_ID 0x020c
> > #define JPGDEC_REG_TOTAL_MCU_NUM 0x0210
> > #define JPGDEC_REG_COMP0_DATA_UNIT_NUM 0x0224
> > -#define JPGDEC_REG_DU_CTRL 0x023C
> > +#define JPGDEC_REG_DU_CTRL 0x023c
> > #define JPGDEC_REG_TRIG 0x0240
> > #define JPGDEC_REG_FILE_BRP 0x0248
> > -#define JPGDEC_REG_FILE_TOTAL_SIZE 0x024C
> > +#define JPGDEC_REG_FILE_TOTAL_SIZE 0x024c
> > #define JPGDEC_REG_QT_ID 0x0270
> > #define JPGDEC_REG_INTERRUPT_STATUS 0x0274
> > #define JPGDEC_REG_STATUS 0x0278
> >
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
From: Andy Shevchenko @ 2020-06-05 8:02 UTC (permalink / raw)
To: Michael Walle
Cc: devicetree, Linus Walleij, Thierry Reding, Lee Jones,
Jason Cooper, Andy Shevchenko, Marc Zyngier, Bartosz Golaszewski,
Uwe Kleine-König, Guenter Roeck, linux-pwm, Jean Delvare,
linux-watchdog, open list:GPIO SUBSYSTEM, Mark Brown,
Thomas Gleixner, Wim Van Sebroeck, linux-arm Mailing List,
linux-hwmon, Greg Kroah-Hartman, Linux Kernel Mailing List,
Li Yang, Rob Herring, Shawn Guo
In-Reply-To: <CAHp75Vd-R3yqhq88-whY6vdDhESpzvFCsbi-ygSTjfXfUzOrtg@mail.gmail.com>
On Fri, Jun 5, 2020 at 11:01 AM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Fri, Jun 5, 2020 at 12:16 AM Michael Walle <michael@walle.cc> wrote:
...
> > Please note that the MFD driver is defined as bool in the Kconfig
> > because the next patch will add interrupt support.
> > + bool "Kontron sl28 core driver"
> > + depends on I2C=y
>
> Why not module?
To be clear, I have read above, but it didn't shed a light.
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
From: Andy Shevchenko @ 2020-06-05 8:01 UTC (permalink / raw)
To: Michael Walle
Cc: devicetree, Linus Walleij, Thierry Reding, Lee Jones,
Jason Cooper, Andy Shevchenko, Marc Zyngier, Bartosz Golaszewski,
Uwe Kleine-König, Guenter Roeck, linux-pwm, Jean Delvare,
linux-watchdog, open list:GPIO SUBSYSTEM, Mark Brown,
Thomas Gleixner, Wim Van Sebroeck, linux-arm Mailing List,
linux-hwmon, Greg Kroah-Hartman, Linux Kernel Mailing List,
Li Yang, Rob Herring, Shawn Guo
In-Reply-To: <20200604211039.12689-3-michael@walle.cc>
On Fri, Jun 5, 2020 at 12:16 AM Michael Walle <michael@walle.cc> wrote:
>
> Add the core support for the board management controller found on the
> SMARC-sAL28 board. It consists of the following functions:
> - watchdog
> - GPIO controller
> - PWM controller
> - fan sensor
> - interrupt controller
>
> At the moment, this controller is used on the Kontron SMARC-sAL28 board.
>
> Please note that the MFD driver is defined as bool in the Kconfig
> because the next patch will add interrupt support.
...
> +config MFD_SL28CPLD
> + bool "Kontron sl28 core driver"
> + depends on I2C=y
Why not module?
> + depends on OF
I didn't find an evidence this is needed.
No Compile Test?
> + select REGMAP_I2C
> + select MFD_CORE
...
> +#include <linux/of_platform.h>
No evidence of user of this.
I think you meant mod_devicetable.h.
...
> +static struct i2c_driver sl28cpld_driver = {
> + .probe_new = sl28cpld_probe,
> + .driver = {
> + .name = "sl28cpld",
> + .of_match_table = of_match_ptr(sl28cpld_of_match),
Drop of_match_ptr(). It has a little sense in this context (depends OF).
It will have a little sense even if you drop depends OF b/c you will
introduce a compiler warning.
> + },
> +};
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: (EXT) RE: [PATCH v8 00/13] add ecspi ERR009165 for i.mx6/7 soc family
From: Matthias Schiffer @ 2020-06-05 7:57 UTC (permalink / raw)
To: Robin Gong
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
festevam@gmail.com, martin.fuzzey@flowbird.group, Markus Niebel,
catalin.marinas@arm.com, s.hauer@pengutronix.de,
will.deacon@arm.com, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, linux-spi@vger.kernel.org, vkoul@kernel.org,
broonie@kernel.org, dl-linux-imx, kernel@pengutronix.de,
u.kleine-koenig@pengutronix.de, dan.j.williams@intel.com,
shawnguo@kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <VE1PR04MB6638463E7E6577E84F8D1FF589860@VE1PR04MB6638.eurprd04.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 4792 bytes --]
On Fri, 2020-06-05 at 02:45 +0000, Robin Gong wrote:
> On 2020/06/03 Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
> wrote:
> > On Wed, 2020-06-03 at 09:50 +0000, Robin Gong wrote:
> > > On 2020/06/03 Matthias Schiffer <
> > > matthias.schiffer@ew.tq-group.com>
> > > wrote:
> > > > On Thu, 2020-05-21 at 04:34 +0800, Robin Gong wrote:
> > > > > There is ecspi ERR009165 on i.mx6/7 soc family, which cause
> > > > > FIFO
> > > > > transfer to be send twice in DMA mode. Please get more
> > > > > information
> > > > > from:
> > > > >
> >
> >
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> > > > > .
> > > > >
> > > >
> > > >
> >
> > nxp.com%2Fdocs%2Fen%2Ferrata%2FIMX6DQCE.pdf&data=02%7C01%7C
> > > > yibin.g
> > > > >
> > > >
> > > >
> >
> > ong%40nxp.com%7C4621358b9be04a79d2d508d80798835b%7C686ea1d3bc2b
> > > > 4c6fa92
> > > > >
> > > >
> > > >
> >
> > cd99c5c301635%7C0%7C1%7C637267698912634476&sdata=hR66H1hP%
> > > > 2Fqb6OXe
> > > > > w9wpXizY8DiNfZZ1KLwu3Kty87jc%3D&reserved=0. The
> > > > > workaround
> >
> > is
> > > > > adding new sdma ram script which works in XCH mode as PIO
> > > > > inside
> > > > > sdma instead of SMC mode, meanwhile, 'TX_THRESHOLD' should be
> > > > > 0.
> > > > > The issue
> > > >
> > > > should be exist on all legacy i.mx6/7 soc family before
> > > > i.mx6ul.
> > > > > NXP fix this design issue from i.mx6ul, so newer chips
> > > > > including
> > > > > i.mx6ul/ 6ull/6sll do not need this workaroud anymore. All
> > > > > other
> > > > > i.mx6/7/8 chips still need this workaroud. This patch set add
> > > > > new
> > > > > 'fsl,imx6ul-ecspi'
> > > > > for ecspi driver and 'ecspi_fixed' in sdma driver to choose
> > > > > if
> > > > > need errata or not.
> > > > > The first two reverted patches should be the same issue,
> > > > > though,
> > > > > it seems 'fixed' by changing to other shp script. Hope Sean
> > > > > or
> > > > > Sascha could have the chance to test this patch set if could
> > > > > fix
> > > > > their issues.
> > > > > Besides, enable sdma support for i.mx8mm/8mq and fix ecspi1
> > > > > not
> > > > > work on i.mx8mm because the event id is zero.
> > > > >
> > > > > PS:
> > > > > Please get sdma firmware from below linux-firmware and
> > > > > copy it
> > > > > to your local rootfs /lib/firmware/imx/sdma.
> > > >
> > > >
> > > > Hello Robin,
> > > >
> > > > we have tried out this series, and there seems to be an issue
> > > > with
> > > > the
> > > > PIO fallback. We are testing on an i.MX6Q board, and our kernel
> > > > is
> > > > a
> > > > mostly-unmodified 5.4, on which we backported all SDMA patches
> > > > from
> > > > next-20200602 (imx-sdma.c is identical to next-20200602
> > > > version),
> > > > and
> > > > then applied this whole series.
> > > >
> > > > We build the SDMA driver as a kernel module, which is loaded by
> > > > udev,
> > > > so the root filesystem is ready and the SDMA firmware can be
> > > > loaded.
> > > > The behaviour we're seeing is the following:
> > > >
> > > > 1. As long as the SDMA driver is not loaded, initializing
> > > > spi_imx
> > > > will
> > > > be deferred
> > > > 2. imx_sdma is loaded. The SDMA firmware is not yet loaded at
> > > > this
> > > > point
> > > > 3. spi_imx is initialized and an SPI-NOR flash is probed. To
> > > > load
> > > > the
> > > > BFPT, the driver will attempt to use DMA; this will fail with
> > > > EINVAL as
> > > > long as the SDMA firmware is not ready, so the fallback to PIO
> > > > happens
> > > > (4. SDMA firmware is ready, subsequent SPI transfers use DMA)
> > > >
> > > > The problem happens in step 3: Whenever the driver falls back
> > > > to
> > > > PIO,
> > > > the received data is corrupt. The behaviour is specific to the
> > > > fallback: When I disable DMA completely via spi_imx.use_dma, or
> > > > when
> > > > the timing is lucky and the SDMA firmware gets loaded before
> > > > the
> > > > flash
> > > > is probed, no corruption can be observed.
> > >
> > > Thanks Matthias, would you like post log?
> > >
> >
> > I have attached the following log files:
> > - pio.log: DMA disabled via module parameter
> > - dma.log: "lucky" timing, SDMA firmware loaded before SPI-NOR
> > probe
> > - fallback.log: DMA->PIO fallback
> >
> > The logs include some additional log messages:
> > - Return value of spi_imx_dma_transfer() before PIO fallback
> > - SPI-NOR SFPT dump
> >
> > It can be seen that the BFPT data is identical in pio.log and
> > dma.log,
> > and differs almost completely in fallback.log. The corrupted data
> > seems
> > to be random, or uninitialized memory; it differs with every boot.
>
> Would you please have a try with the attached patch? Thanks.
Thank you, this fixes the issue we're seeing.
Kind regards,
Matthias
[-- Attachment #2: fixed.log --]
[-- Type: text/x-log, Size: 33368 bytes --]
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.4.39 (oe-user@oe-host) (gcc version 9.2.0 (GCC)) #1 SMP PREEMPT Fri Jun 5 07:23:40 UTC 2020
[ 0.000000] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt: Machine model: TQ TQMa6Q on MBa6x
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] cma: Reserved 160 MiB at 0x46000000
[ 0.000000] On node 0 totalpages: 262144
[ 0.000000] Normal zone: 2048 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 262144 pages, LIFO batch:63
[ 0.000000] percpu: Embedded 20 pages/cpu s50664 r8192 d23064 u81920
[ 0.000000] pcpu-alloc: s50664 r8192 d23064 u81920 alloc=20*4096
[ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 260096
[ 0.000000] Kernel command line: root=/dev/mmcblk1p2 ro rootwait console=ttymxc1,115200 spi_imx.dyndbg=+p consoleblank=0 cma=160M
[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 0.000000] Memory: 850004K/1048576K available (12288K kernel code, 942K rwdata, 3656K rodata, 1024K init, 6554K bss, 34732K reserved, 163840K cma-reserved, 0K highmem)
[ 0.000000] random: get_random_u32 called from __kmem_cache_create+0x20/0x2b8 with crng_init=0
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] ftrace: allocating 34625 entries in 68 pages
[ 0.000000] Running RCU self tests
[ 0.000000] rcu: Preemptible hierarchical RCU implementation.
[ 0.000000] rcu: RCU lockdep checking is enabled.
[ 0.000000] Tasks RCU enabled.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] L2C-310 errata 752271 769419 enabled
[ 0.000000] L2C-310 enabling early BRESP for Cortex-A9
[ 0.000000] L2C-310 full line of zeros enabled for Cortex-A9
[ 0.000000] L2C-310 ID prefetch enabled, offset 16 lines
[ 0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled
[ 0.000000] L2C-310 cache controller enabled, 16 ways, 1024 kB
[ 0.000000] L2C-310: CACHE_ID 0x410000c7, AUX_CTRL 0x76470001
[ 0.000000] Switching to timer-based delay loop, resolution 333ns
[ 0.000009] sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every 715827882841ns
[ 0.000040] clocksource: mxc_timer1: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 637086815595 ns
[ 0.001629] Console: colour dummy device 80x30
[ 0.001665] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[ 0.001687] ... MAX_LOCKDEP_SUBCLASSES: 8
[ 0.001711] ... MAX_LOCK_DEPTH: 48
[ 0.001731] ... MAX_LOCKDEP_KEYS: 8192
[ 0.001753] ... CLASSHASH_SIZE: 4096
[ 0.001774] ... MAX_LOCKDEP_ENTRIES: 32768
[ 0.001795] ... MAX_LOCKDEP_CHAINS: 65536
[ 0.001816] ... CHAINHASH_SIZE: 32768
[ 0.001836] memory used by lock dependency info: 3997 kB
[ 0.001856] memory used for stack traces: 2112 kB
[ 0.001878] per task-struct memory footprint: 1536 bytes
[ 0.001953] Calibrating delay loop (skipped), value calculated using timer frequency.. 6.00 BogoMIPS (lpj=30000)
[ 0.001988] pid_max: default: 32768 minimum: 301
[ 0.002526] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[ 0.002572] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[ 0.005083] CPU: Testing write buffer coherency: ok
[ 0.005169] CPU0: Spectre v2: using BPIALL workaround
[ 0.006459] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.059678] Setting up static identity map for 0x10100000 - 0x10100060
[ 0.079539] rcu: Hierarchical SRCU implementation.
[ 0.129550] smp: Bringing up secondary CPUs ...
[ 0.210001] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.210016] CPU1: Spectre v2: using BPIALL workaround
[ 0.289894] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
[ 0.289910] CPU2: Spectre v2: using BPIALL workaround
[ 0.369888] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
[ 0.369903] CPU3: Spectre v2: using BPIALL workaround
[ 0.370513] smp: Brought up 1 node, 4 CPUs
[ 0.370547] SMP: Total of 4 processors activated (24.00 BogoMIPS).
[ 0.370573] CPU: All CPU(s) started in SVC mode.
[ 0.372564] devtmpfs: initialized
[ 0.411117] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
[ 0.413270] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.413334] futex hash table entries: 1024 (order: 4, 65536 bytes, linear)
[ 0.421673] pinctrl core: initialized pinctrl subsystem
[ 0.426412] NET: Registered protocol family 16
[ 0.433920] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.437726] cpuidle: using governor ladder
[ 0.438009] CPU identified as i.MX6Q, silicon rev 1.5
[ 0.471621] vdd1p1: supplied by regulator-dummy
[ 0.473787] vdd3p0: supplied by regulator-dummy
[ 0.475680] vdd2p5: supplied by regulator-dummy
[ 0.477536] vddarm: supplied by regulator-dummy
[ 0.479670] vddpu: supplied by regulator-dummy
[ 0.481530] vddsoc: supplied by regulator-dummy
[ 0.521081] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
[ 0.521146] hw-breakpoint: maximum watchpoint size is 4 bytes.
[ 0.524299] imx6q-pinctrl 20e0000.iomuxc: initialized IMX pinctrl driver
[ 0.644216] mxs-dma 110000.dma-apbh: initialized
[ 0.653222] vgaarb: loaded
[ 0.654666] SCSI subsystem initialized
[ 0.655483] libata version 3.00 loaded.
[ 0.656501] usbcore: registered new interface driver usbfs
[ 0.656737] usbcore: registered new interface driver hub
[ 0.657080] usbcore: registered new device driver usb
[ 0.657588] usb_phy_generic usbphynop1: usbphynop1 supply vcc not found, using dummy regulator
[ 0.658449] usb_phy_generic usbphynop2: usbphynop2 supply vcc not found, using dummy regulator
[ 0.665470] i2c i2c-0: IMX I2C adapter registered
[ 0.666320] pps_core: LinuxPPS API ver. 1 registered
[ 0.666349] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[ 0.666430] PTP clock support registered
[ 0.674652] clocksource: Switched to clocksource mxc_timer1
[ 1.740208] thermal_sys: Registered thermal governor 'fair_share'
[ 1.740222] thermal_sys: Registered thermal governor 'step_wise'
[ 1.740260] thermal_sys: Registered thermal governor 'user_space'
[ 1.741160] NET: Registered protocol family 2
[ 1.743061] tcp_listen_portaddr_hash hash table entries: 512 (order: 2, 20480 bytes, linear)
[ 1.743196] TCP established hash table entries: 8192 (order: 3, 32768 bytes, linear)
[ 1.743432] TCP bind hash table entries: 8192 (order: 6, 294912 bytes, linear)
[ 1.744897] TCP: Hash tables configured (established 8192 bind 8192)
[ 1.745528] UDP hash table entries: 512 (order: 3, 40960 bytes, linear)
[ 1.745768] UDP-Lite hash table entries: 512 (order: 3, 40960 bytes, linear)
[ 1.746564] NET: Registered protocol family 1
[ 1.748943] RPC: Registered named UNIX socket transport module.
[ 1.749009] RPC: Registered udp transport module.
[ 1.749037] RPC: Registered tcp transport module.
[ 1.749064] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 1.760424] PCI: CLS 0 bytes, default 64
[ 1.761389] hw perfevents: no interrupt-affinity property for /pmu, guessing.
[ 1.762261] hw perfevents: enabled with armv7_cortex_a9 PMU driver, 7 counters available
[ 1.768318] Initialise system trusted keyrings
[ 1.769028] workingset: timestamp_bits=30 max_order=18 bucket_order=0
[ 1.792661] NFS: Registering the id_resolver key type
[ 1.792800] Key type id_resolver registered
[ 1.792870] Key type id_legacy registered
[ 1.792932] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[ 1.793719] fuse: init (API version 7.31)
[ 1.796020] NILFS version 2 loaded
[ 1.838986] Key type asymmetric registered
[ 1.839100] Asymmetric key parser 'x509' registered
[ 1.839275] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
[ 1.839367] io scheduler mq-deadline registered
[ 1.839401] io scheduler kyber registered
[ 1.847454] imx6q-pcie 1ffc000.pcie: host bridge /soc/pcie@1ffc000 ranges:
[ 1.847675] imx6q-pcie 1ffc000.pcie: IO 0x01f80000..0x01f8ffff -> 0x00000000
[ 1.847866] imx6q-pcie 1ffc000.pcie: MEM 0x01000000..0x01efffff -> 0x01000000
[ 1.859118] pfuze100-regulator 0-0008: Full layer: 2, Metal layer: 1
[ 1.860092] pfuze100-regulator 0-0008: FAB: 0, FIN: 0
[ 1.860126] pfuze100-regulator 0-0008: pfuze100 found.
[ 1.891216] 21e8000.serial: ttymxc1 at MMIO 0x21e8000 (irq = 66, base_baud = 5000000) is a IMX
[ 2.678656] printk: console [ttymxc1] enabled
[ 2.685153] 21ec000.serial: ttymxc2 at MMIO 0x21ec000 (irq = 67, base_baud = 5000000) is a IMX
[ 2.695707] 21f0000.serial: ttymxc3 at MMIO 0x21f0000 (irq = 68, base_baud = 5000000) is a IMX
[ 2.706224] 21f4000.serial: ttymxc4 at MMIO 0x21f4000 (irq = 69, base_baud = 5000000) is a IMX
[ 2.739808] etnaviv etnaviv: bound 130000.gpu (ops gpu_ops)
[ 2.746264] etnaviv etnaviv: bound 134000.gpu (ops gpu_ops)
[ 2.752620] etnaviv etnaviv: bound 2204000.gpu (ops gpu_ops)
[ 2.758410] etnaviv-gpu 130000.gpu: model: GC2000, revision: 5108
[ 2.765556] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007
[ 2.771816] etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215
[ 2.778030] etnaviv-gpu 2204000.gpu: Ignoring GPU with VG and FE2.0
[ 2.787199] [drm] Initialized etnaviv 1.3.0 20151214 for etnaviv on minor 0
[ 2.799546] imx-ipuv3 2400000.ipu: IPUv3H probed
[ 2.807632] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 2.814322] [drm] No driver support for vblank timestamp query.
[ 2.821418] imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops ipu_crtc_ops)
[ 2.829349] imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops ipu_crtc_ops)
[ 2.837354] imx-drm display-subsystem: bound imx-ipuv3-crtc.6 (ops ipu_crtc_ops)
[ 2.845276] imx-drm display-subsystem: bound imx-ipuv3-crtc.7 (ops ipu_crtc_ops)
[ 2.854389] [drm] Initialized imx-drm 1.0.0 20120507 for display-subsystem on minor 1
[ 2.862675] imx-ipuv3 2800000.ipu: IPUv3H probed
[ 2.912586] loop: module loaded
[ 2.918439] at24 0-0050: 8192 byte 24c64 EEPROM, writable, 32 bytes/write
[ 2.927616] at24 0-0057: 8192 byte 24c64 EEPROM, writable, 32 bytes/write
[ 2.937469] ahci-imx 2200000.sata: fsl,transmit-level-mV not specified, using 00000024
[ 2.945500] ahci-imx 2200000.sata: fsl,transmit-boost-mdB not specified, using 00000480
[ 2.953544] ahci-imx 2200000.sata: fsl,transmit-atten-16ths not specified, using 00002000
[ 2.961821] ahci-imx 2200000.sata: fsl,receive-eq-mdB not specified, using 05000000
[ 2.969862] ahci-imx 2200000.sata: 2200000.sata supply ahci not found, using dummy regulator
[ 2.974678] imx6q-pcie 1ffc000.pcie: Phy link never came up
[ 2.978838] ahci-imx 2200000.sata: 2200000.sata supply phy not found, using dummy regulator
[ 2.987906] imx6q-pcie 1ffc000.pcie: PCI host bridge to bus 0000:00
[ 2.993159] ahci-imx 2200000.sata: 2200000.sata supply target not found, using dummy regulator
[ 2.998671] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 2.998699] pci_bus 0000:00: root bus resource [io 0x0000-0xffff]
[ 3.011182] ahci-imx 2200000.sata: SSS flag set, parallel bus scan disabled
[ 3.012881] pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
[ 3.019183] ahci-imx 2200000.sata: AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl platform mode
[ 3.026411] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
[ 3.033056] ahci-imx 2200000.sata: flags: ncq sntf stag pm led clo only pmp pio slum part ccc apst
[ 3.041992] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
[ 3.063650] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
[ 3.067674] scsi host0: ahci-imx
[ 3.070548] pci 0000:00:00.0: Limiting cfg_size to 512
[ 3.075295] ata1: SATA max UDMA/133 mmio [mem 0x02200000-0x02203fff] port 0x100 irq 72
[ 3.079130] pci 0000:00:00.0: supports D1
[ 3.089282] spi_imx 2008000.spi: can't get the TX DMA channel, error -517!
[ 3.090799] pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold
[ 3.092133] spi_imx 2018000.spi: can't get the TX DMA channel, error -517!
[ 3.099384] libphy: Fixed MDIO Bus: probed
[ 3.102695] PCI: bus0: Fast back to back transfers disabled
[ 3.105356] CAN device driver interface
[ 3.113649] PCI: bus1: Fast back to back transfers enabled
[ 3.114285] flexcan 2090000.flexcan: 2090000.flexcan supply xceiver not found, using dummy regulator
[ 3.119291] pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
[ 3.131705] flexcan 2094000.flexcan: 2094000.flexcan supply xceiver not found, using dummy regulator
[ 3.135310] pci 0000:00:00.0: BAR 6: assigned [mem 0x01100000-0x0110ffff pref]
[ 3.151786] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
[ 3.153541] pps pps0: new PPS source ptp0
[ 3.159151] pcieport 0000:00:00.0: PME: Signaling with IRQ 306
[ 3.168741] pcieport 0000:00:00.0: AER: enabled with IRQ 306
[ 3.169048] libphy: fec_enet_mii_bus: probed
[ 3.183769] fec 2188000.ethernet eth0: registered PHC device 0
[ 3.190548] usbcore: registered new interface driver cdc_ether
[ 3.196665] usbcore: registered new interface driver smsc95xx
[ 3.202461] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 3.209144] ehci-pci: EHCI PCI platform driver
[ 3.219204] imx_usb 2184000.usb: No over current polarity defined
[ 3.230025] ci_hdrc ci_hdrc.0: EHCI Host Controller
[ 3.235495] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1
[ 3.264720] ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00
[ 3.271845] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.04
[ 3.280322] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 3.287654] usb usb1: Product: EHCI Host Controller
[ 3.292565] usb usb1: Manufacturer: Linux 5.4.39 ehci_hcd
[ 3.298056] usb usb1: SerialNumber: ci_hdrc.0
[ 3.305485] hub 1-0:1.0: USB hub found
[ 3.309555] hub 1-0:1.0: 1 port detected
[ 3.317484] imx_usb 2184200.usb: 2184200.usb supply vbus not found, using dummy regulator
[ 3.330416] ci_hdrc ci_hdrc.1: EHCI Host Controller
[ 3.335501] ci_hdrc ci_hdrc.1: new USB bus registered, assigned bus number 2
[ 3.364702] ci_hdrc ci_hdrc.1: USB 2.0 started, EHCI 1.00
[ 3.371209] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.04
[ 3.379600] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 3.386918] usb usb2: Product: EHCI Host Controller
[ 3.391831] usb usb2: Manufacturer: Linux 5.4.39 ehci_hcd
[ 3.397322] usb usb2: SerialNumber: ci_hdrc.1
[ 3.403588] hub 2-0:1.0: USB hub found
[ 3.407620] hub 2-0:1.0: 1 port detected
[ 3.416582] mousedev: PS/2 mouse device common for all mice
[ 3.426923] ata1: SATA link down (SStatus 0 SControl 300)
[ 3.432599] ahci-imx 2200000.sata: no device found, disabling link.
[ 3.434404] rtc-ds1307 0-0068: registered as rtc0
[ 3.438995] ahci-imx 2200000.sata: pass ahci_imx..hotplug=1 to enable hotplug
[ 3.445882] i2c /dev entries driver
[ 3.455954] IR NEC protocol handler initialized
[ 3.460526] IR RC5(x/sz) protocol handler initialized
[ 3.465704] IR RC6 protocol handler initialized
[ 3.470272] IR JVC protocol handler initialized
[ 3.474914] IR Sony protocol handler initialized
[ 3.479565] IR SANYO protocol handler initialized
[ 3.484300] IR Sharp protocol handler initialized
[ 3.489093] IR MCE Keyboard/mouse protocol handler initialized
[ 3.495017] IR XMP protocol handler initialized
[ 3.506346] lm75 0-0048: hwmon0: sensor 'lm75'
[ 3.513239] lm75 0-0049: hwmon1: sensor 'lm75'
[ 3.523672] imx2-wdt 20bc000.wdog: timeout 60 sec (nowayout=0)
[ 3.532392] sdhci: Secure Digital Host Controller Interface driver
[ 3.538672] sdhci: Copyright(c) Pierre Ossman
[ 3.543062] sdhci-pltfm: SDHCI platform and OF driver helper
[ 3.550780] sdhci-esdhc-imx 2194000.usdhc: Got CD GPIO
[ 3.556135] sdhci-esdhc-imx 2194000.usdhc: Got WP GPIO
[ 3.598990] mmc1: SDHCI controller on 2194000.usdhc [2194000.usdhc] using ADMA
[ 3.651070] mmc1: new high speed SD card at address 1234
[ 3.657883] mmc0: SDHCI controller on 2198000.usdhc [2198000.usdhc] using ADMA
[ 3.670288] ledtrig-cpu: registered to indicate activity on CPUs
[ 3.671305] mmcblk1: mmc1:1234 SA02G 1.84 GiB
[ 3.681554] caam 2100000.caam: Entropy delay = 3200
[ 3.703274] mmcblk1: p1 p2
[ 3.747319] caam 2100000.caam: Instantiated RNG4 SH0
[ 3.774779] usb 2-1: new high-speed USB device number 2 using ci_hdrc
[ 3.787144] mmc0: new DDR MMC card at address 0001
[ 3.794197] mmcblk0: mmc0:0001 MMC04G 3.52 GiB
[ 3.799884] mmcblk0boot0: mmc0:0001 MMC04G partition 1 16.0 MiB
[ 3.806963] mmcblk0boot1: mmc0:0001 MMC04G partition 2 16.0 MiB
[ 3.808082] caam 2100000.caam: Instantiated RNG4 SH1
[ 3.813829] mmcblk0rpmb: mmc0:0001 MMC04G partition 3 128 KiB, chardev (248:0)
[ 3.817956] caam 2100000.caam: device ID = 0x0a16010000000000 (Era 4)
[ 3.817974] caam 2100000.caam: job rings = 2, qi = 0
[ 3.892098] caam algorithms registered in /proc/crypto
[ 3.912582] caam_jr 2101000.jr0: registering rng-caam
[ 3.919891] hidraw: raw HID events driver (C) Jiri Kosina
[ 3.930853] NET: Registered protocol family 10
[ 3.939894] Segment Routing with IPv6
[ 3.943729] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[ 3.952463] NET: Registered protocol family 17
[ 3.957050] can: controller area network core (rev 20170425 abi 9)
[ 3.963506] NET: Registered protocol family 29
[ 3.968053] can: raw protocol (rev 20170425)
[ 3.972458] can: broadcast manager protocol (rev 20170425 t)
[ 3.975864] usb 2-1: New USB device found, idVendor=0424, idProduct=2517, bcdDevice= 0.02
[ 3.978267] can: netlink gateway (rev 20190810) max_hops=1
[ 3.986497] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 3.992533] Key type dns_resolver registered
[ 4.001775] hub 2-1:1.0: USB hub found
[ 4.007726] hub 2-1:1.0: 7 ports detected
[ 4.019922] Registering SWP/SWPB emulation handler
[ 4.026940] Loading compiled-in X.509 certificates
[ 4.033765] Key type ._fscrypt registered
[ 4.038061] Key type .fscrypt registered
[ 4.197921] spi_imx 2008000.spi: can't get the TX DMA channel, error -517!
[ 4.199984] spi_imx 2018000.spi: can't get the TX DMA channel, error -517!
[ 4.203694] imx_thermal tempmon: Industrial CPU temperature grade - max:105C critical:100C passive:95C
[ 4.215406] spi_imx 2008000.spi: can't get the TX DMA channel, error -517!
[ 4.217246] spi_imx 2018000.spi: can't get the TX DMA channel, error -517!
[ 4.219297] spi_imx 2008000.spi: can't get the TX DMA channel, error -517!
[ 4.221081] spi_imx 2018000.spi: can't get the TX DMA channel, error -517!
[ 4.225245] random: fast init done
[ 4.229248] rtc-ds1307 0-0068: setting system clock to 2000-01-01T00:01:08 UTC (946684868)
[ 4.238084] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 4.258979] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 4.267092] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[ 4.276176] cfg80211: failed to load regulatory.db
[ 4.301827] EXT4-fs (mmcblk1p2): INFO: recovery required on readonly filesystem
[ 4.309472] EXT4-fs (mmcblk1p2): write access will be enabled during recovery
[ 4.334800] usb 2-1.1: new high-speed USB device number 3 using ci_hdrc
[ 4.496212] usb 2-1.1: New USB device found, idVendor=0424, idProduct=9e00, bcdDevice= 3.00
[ 4.504886] usb 2-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 4.517379] smsc95xx v1.0.6
[ 4.648480] smsc95xx 2-1.1:1.0 eth1: register 'smsc95xx' at usb-ci_hdrc.1-1.1, smsc95xx USB 2.0 Ethernet, f2:78:83:43:d1:7b
[ 4.662389] spi_imx 2008000.spi: can't get the TX DMA channel, error -517!
[ 4.664256] spi_imx 2018000.spi: can't get the TX DMA channel, error -517!
[ 4.967482] EXT4-fs (mmcblk1p2): recovery complete
[ 4.986706] EXT4-fs (mmcblk1p2): mounted filesystem with ordered data mode. Opts: (null)
[ 4.996436] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[ 5.007139] devtmpfs: mounted
[ 5.028362] Freeing unused kernel memory: 1024K
[ 5.034564] Run /sbin/init as init process
[ 5.606188] systemd[1]: System time before build time, advancing clock.
[ 5.710605] systemd[1]: systemd 243.2+ running in system mode. (-PAM -AUDIT -SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP -LIBCRYPTSETUP -GCRYPT -GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID -ELFUTILS +KMOD -IDN2 -IDN -PCRE2 default-hierarchy=hybrid)
[ 5.736335] systemd[1]: Detected architecture arm.
[ 5.799308] systemd[1]: Set hostname to <tqma6q-mba6x>.
[ 6.675645] systemd[1]: /lib/systemd/system/dbus.socket:5: ListenStream= references a path below legacy directory /var/run/, updating /var/run/dbus/system_bus_socket \xe2\x86\x92 /run/dbus/system_bus_socket; please update the unit file accordingly.
[ 7.024418] systemd[1]: /lib/systemd/system/rpcbind.socket:5: ListenStream= references a path below legacy directory /var/run/, updating /var/run/rpcbind.sock \xe2\x86\x92 /run/rpcbind.sock; please update the unit file accordingly.
[ 7.088772] random: systemd: uninitialized urandom read (16 bytes read)
[ 7.100144] systemd[1]: Created slice system-getty.slice.
[ 7.135611] random: systemd: uninitialized urandom read (16 bytes read)
[ 7.146536] systemd[1]: Created slice system-serial\x2dgetty.slice.
[ 7.195582] random: systemd: uninitialized urandom read (16 bytes read)
[ 7.206267] systemd[1]: Created slice User and Session Slice.
[ 7.247801] systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
[ 7.287818] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
[ 8.148199] random: crng init done
[ 8.151661] random: 7 urandom warning(s) missed due to ratelimiting
[ 8.613147] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
[ 8.619572] ext4 filesystem being remounted at / supports timestamps until 2038 (0x7fffffff)
[ 9.101979] systemd[297]: systemd-udevd.service: ProtectHostname=yes is configured, but the kernel does not support UTS namespaces, ignoring namespace setup.
[ 9.267307] systemd-journald[279]: Received client request to flush runtime journal.
[ 11.123314] input: gpio-buttons as /devices/soc0/gpio-buttons/input/input0
[ 11.127794] input: gpio-beeper as /devices/soc0/gpio-beeper/input/input1
[ 11.157434] mc: Linux media interface: v0.10
[ 11.172601] spi_imx 2008000.spi: can't get the TX DMA channel, error -517!
[ 11.174915] spi_imx 2018000.spi: can't get the TX DMA channel, error -517!
[ 11.176776] spi_imx 2008000.spi: can't get the TX DMA channel, error -517!
[ 11.178815] spi_imx 2018000.spi: can't get the TX DMA channel, error -517!
[ 11.219686] videodev: Linux video capture interface: v2.00
[ 11.401520] imx_media_common: module is from the staging directory, the quality is unknown, you have been warned.
[ 11.457916] spi_imx 2008000.spi: can't get the TX DMA channel, error -517!
[ 11.460009] spi_imx 2018000.spi: can't get the TX DMA channel, error -517!
[ 11.470667] imx6_media: module is from the staging directory, the quality is unknown, you have been warned.
[ 11.650219] fsl-ssi-dai 2028000.ssi: No cache defaults, reading back from HW
[ 11.860185] spi_imx 2008000.spi: can't get the TX DMA channel, error -517!
[ 11.869667] spi_imx 2018000.spi: can't get the TX DMA channel, error -517!
[ 11.871503] fsl-ssi-dai 2028000.ssi: No cache defaults, reading back from HW
[ 11.968879] spi spi0.0: spi_imx_setup: mode 0, 8 bpw, 50000000 hz
[ 11.972130] spi_imx 2008000.spi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 50000000, post: 0, pre: 1
[ 11.972637] spi_imx 2008000.spi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 50000000, post: 0, pre: 1
[ 12.016379] spi-nor spi0.0: n25q128a13
[ 12.020443] spi-nor spi0.0: spi_nor_info_init_params: 03
[ 12.035872] spi_imx 2008000.spi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 50000000, post: 0, pre: 1
[ 12.035951] spi_imx 2008000.spi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 50000000, post: 0, pre: 1
[ 12.036037] spi_imx 2008000.spi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 50000000, post: 0, pre: 1
[ 12.036102] spi_imx 2008000.spi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 50000000, post: 0, pre: 1
[ 12.036459] spi-nor spi0.0: Header: 53
[ 12.040355] spi-nor spi0.0: Header: 46
[ 12.044198] spi-nor spi0.0: Header: 44
[ 12.073621] spi-nor spi0.0: Header: 50
[ 12.077592] spi-nor spi0.0: Header: 05
[ 12.081414] spi-nor spi0.0: Header: 01
[ 12.112231] spi-nor spi0.0: Header: 01
[ 12.134785] spi-nor spi0.0: Header: ff
[ 12.139506] spi-nor spi0.0: Header: 00
[ 12.143317] spi-nor spi0.0: Header: 05
[ 12.159246] spi-nor spi0.0: Header: 01
[ 12.163108] spi-nor spi0.0: Header: 10
[ 12.184776] spi-nor spi0.0: Header: 30
[ 12.188615] spi-nor spi0.0: Header: 00
[ 12.221040] spi-nor spi0.0: Header: 00
[ 12.244702] spi-nor spi0.0: Header: ff
[ 12.266541] spi_imx 2008000.spi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 50000000, post: 0, pre: 1
[ 12.266706] spi_imx 2008000.spi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 50000000, post: 0, pre: 1
[ 12.266788] spi_imx 2008000.spi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 50000000, post: 0, pre: 1
[ 12.266866] spi_imx 2008000.spi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 50000000, post: 0, pre: 1
[ 12.267190] spi-nor spi0.0: bfpt addr=30 len=40
[ 12.285142] spi_imx 2008000.spi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 50000000, post: 0, pre: 1
[ 12.285246] spi_imx 2008000.spi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 50000000, post: 0, pre: 1
[ 12.285534] spi_imx 2008000.spi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 50000000, post: 0, pre: 1
[ 12.285658] spi_imx 2008000.spi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 50000000, post: 0, pre: 1
[ 12.286591] spi-nor spi0.0: DMA transfer: -22
[ 12.286630] spi-nor spi0.0: Fallback to PIO mode
[ 12.296534] spi-nor spi0.0: bfpt: e5
[ 12.314782] spi-nor spi0.0: bfpt: 20
[ 12.344792] spi-nor spi0.0: bfpt: f1
[ 12.348426] spi-nor spi0.0: bfpt: ff
[ 12.352037] spi-nor spi0.0: bfpt: ff
[ 12.397380] spi-nor spi0.0: bfpt: ff
[ 12.416917] spi-nor spi0.0: bfpt: ff
[ 12.420597] spi-nor spi0.0: bfpt: 07
[ 12.424267] spi-nor spi0.0: bfpt: 29
[ 12.442571] spi-nor spi0.0: bfpt: eb
[ 12.458160] spi-nor spi0.0: bfpt: 27
[ 12.462405] Micrel KSZ9031 Gigabit PHY 2188000.ethernet-1:03: attached PHY driver [Micrel KSZ9031 Gigabit PHY] (mii_bus:phy_addr=2188000.ethernet-1:03, irq=104)
[ 12.467943] spi-nor spi0.0: bfpt: 6b
[ 12.510726] spi-nor spi0.0: bfpt: 27
[ 12.514394] spi-nor spi0.0: bfpt: 3b
[ 12.518667] spi-nor spi0.0: bfpt: 27
[ 12.534799] spi-nor spi0.0: bfpt: bb
[ 12.538425] spi-nor spi0.0: bfpt: ff
[ 12.542035] spi-nor spi0.0: bfpt: ff
[ 12.550887] imx6_media_csi: module is from the staging directory, the quality is unknown, you have been warned.
[ 12.554781] spi-nor spi0.0: bfpt: ff
[ 12.561370] imx6_media_csi: module is from the staging directory, the quality is unknown, you have been warned.
[ 12.574772] spi-nor spi0.0: bfpt: ff
[ 12.578560] spi-nor spi0.0: bfpt: ff
[ 12.582176] spi-nor spi0.0: bfpt: ff
[ 12.583566] imx6_media_csi: module is from the staging directory, the quality is unknown, you have been warned.
[ 12.585889] spi-nor spi0.0: bfpt: 27
[ 12.585908] spi-nor spi0.0: bfpt: bb
[ 12.585923] spi-nor spi0.0: bfpt: ff
[ 12.585938] spi-nor spi0.0: bfpt: ff
[ 12.585953] spi-nor spi0.0: bfpt: 29
[ 12.626081] imx6_media_csi: module is from the staging directory, the quality is unknown, you have been warned.
[ 12.656095] ipu1_csi0: Registered ipu1_csi0 capture as /dev/video0
[ 12.675198] ipu1_ic_prpenc: Registered ipu1_ic_prpenc capture as /dev/video1
[ 12.683695] spi-nor spi0.0: bfpt: eb
[ 12.687574] spi-nor spi0.0: bfpt: 0c
[ 12.691231] spi-nor spi0.0: bfpt: 20
[ 12.705004] ipu1_ic_prpvf: Registered ipu1_ic_prpvf capture as /dev/video2
[ 12.712086] imx-media: ipu1_csi0:1 -> ipu1_ic_prp:0
[ 12.717491] spi-nor spi0.0: bfpt: 10
[ 12.721154] spi-nor spi0.0: bfpt: d8
[ 12.734691] spi-nor spi0.0: bfpt: 00
[ 12.738348] spi-nor spi0.0: bfpt: 00
[ 12.741995] spi-nor spi0.0: bfpt: 00
[ 12.745946] imx-media: ipu1_csi0:1 -> ipu1_vdic:0
[ 12.750739] imx-media: ipu1_vdic:2 -> ipu1_ic_prp:0
[ 12.764770] spi-nor spi0.0: bfpt: 00
[ 12.768433] spi-nor spi0.0: bfpt: 35
[ 12.772076] spi-nor spi0.0: bfpt: 8a
[ 12.775953] imx-media: ipu1_ic_prp:1 -> ipu1_ic_prpenc:0
[ 12.781355] imx-media: ipu1_ic_prp:2 -> ipu1_ic_prpvf:0
[ 12.804725] spi-nor spi0.0: bfpt: 01
[ 12.808484] spi-nor spi0.0: bfpt: 00
[ 12.812131] spi-nor spi0.0: bfpt: 82
[ 12.816051] imx-media: subdev ipu1_csi0 bound
[ 12.822311] ipu1_csi1: Registered ipu1_csi1 capture as /dev/video3
[ 12.844770] spi-nor spi0.0: bfpt: a3
[ 12.848570] imx-media: ipu1_csi1:1 -> ipu1_ic_prp:0
[ 12.853600] imx-media: ipu1_csi1:1 -> ipu1_vdic:0
[ 12.858512] spi-nor spi0.0: bfpt: 03
[ 12.862158] spi-nor spi0.0: bfpt: cb
[ 12.865986] spi-nor spi0.0: bfpt: ac
[ 12.869667] spi-nor spi0.0: bfpt: c1
[ 12.873309] spi-nor spi0.0: bfpt: 04
[ 12.877400] imx-media: subdev ipu1_csi1 bound
[ 12.894954] ipu2_csi0: Registered ipu2_csi0 capture as /dev/video4
[ 12.902306] spi-nor spi0.0: bfpt: 2e
[ 12.906067] spi-nor spi0.0: bfpt: 7a
[ 12.909718] spi-nor spi0.0: bfpt: 75
[ 12.913391] spi-nor spi0.0: bfpt: 7a
[ 12.922719] ipu2_ic_prpenc: Registered ipu2_ic_prpenc capture as /dev/video5
[ 12.936367] ipu2_ic_prpvf: Registered ipu2_ic_prpvf capture as /dev/video6
[ 12.943584] imx-media: ipu2_csi0:1 -> ipu2_ic_prp:0
[ 12.954793] spi-nor spi0.0: bfpt: 75
[ 12.958625] spi-nor spi0.0: bfpt: fb
[ 12.962308] spi-nor spi0.0: bfpt: 00
[ 12.974773] imx-media: ipu2_csi0:1 -> ipu2_vdic:0
[ 12.994794] spi-nor spi0.0: bfpt: 00
[ 12.998462] spi-nor spi0.0: bfpt: 80
[ 13.002103] spi-nor spi0.0: bfpt: 08
[ 13.006025] imx-media: ipu2_vdic:2 -> ipu2_ic_prp:0
[ 13.010994] imx-media: ipu2_ic_prp:1 -> ipu2_ic_prpenc:0
[ 13.016510] spi-nor spi0.0: bfpt: 0f
[ 13.020173] spi-nor spi0.0: bfpt: 82
[ 13.023833] spi-nor spi0.0: bfpt: ff
[ 13.027699] imx-media: ipu2_ic_prp:2 -> ipu2_ic_prpvf:0
[ 13.032998] imx-media: subdev ipu2_csi0 bound
[ 13.054705] spi-nor spi0.0: bfpt: 81
[ 13.058330] spi-nor spi0.0: bfpt: 3d
[ 13.064247] ipu2_csi1: Registered ipu2_csi1 capture as /dev/video7
[ 13.071092] spi-nor spi0.0: bfpt: 00
[ 13.084715] imx-media: ipu2_csi1:1 -> ipu2_ic_prp:0
[ 13.089898] spi-nor spi0.0: bfpt: 00
[ 13.093519] spi-nor spi0.0: spi_nor_parse_bfpt: 03
[ 13.098731] imx-media: ipu2_csi1:1 -> ipu2_vdic:0
[ 13.103489] imx-media: subdev ipu2_csi1 bound
[ 13.114805] spi-nor spi0.0: spi_nor_parse_bfpt: 0c
[ 13.121796] spi-nor spi0.0: param headers: 03
[ 13.132542] spi-nor spi0.0: param headers: 00
[ 13.148607] spi-nor spi0.0: param headers: 01
[ 13.153245] spi-nor spi0.0: param headers: 02
[ 13.174355] spi-nor spi0.0: param headers: 00
[ 13.178882] spi-nor spi0.0: param headers: 01
[ 13.183279] spi-nor spi0.0: param headers: 00
[ 13.204795] spi-nor spi0.0: param headers: ff
[ 13.224825] spi-nor spi0.0: has uniform erase
[ 13.229237] spi-nor spi0.0: spi_nor_select_erase: 08
[ 13.234241] spi-nor spi0.0: n25q128a13 (16384 Kbytes)
[ 13.316374] coda 2040000.vpu: Direct firmware load for vpu_fw_imx6q.bin failed with error -2
[ 13.331434] imx-sdma 20ec000.sdma: loaded firmware 3.5
[ 13.355143] coda 2040000.vpu: Using fallback firmware vpu/vpu_fw_imx6q.bin
[ 13.383312] spi spi0.1: spi_imx_setup: mode 0, 8 bpw, 1000000 hz
[ 13.414032] spi_imx 2008000.spi: probed
[ 13.514940] spi spi4.0: spi_imx_setup: mode 0, 8 bpw, 1000000 hz
[ 13.517232] spi_imx 2018000.spi: probed
[ 13.680184] imx-tlv320aic32x4 sound: tlv320aic32x4-hifi <-> 2028000.ssi mapping ok
[ 13.693001] coda 2040000.vpu: Firmware code revision: 570363
[ 13.715442] coda 2040000.vpu: Initialized CODA960.
[ 13.720303] coda 2040000.vpu: Firmware version: 3.1.1
[ 13.746657] coda 2040000.vpu: encoder registered as video8
[ 13.757458] coda 2040000.vpu: decoder registered as video9
[ 14.365520] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
[ 14.373301] IPv6: ADDRCONF(NETDEV_CHANGE): can1: link becomes ready
[ 14.473634] smsc95xx 2-1.1:1.0 eth1: link up, 100Mbps, full-duplex, lpa 0xC5E1
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/6 v4] arm64/vdso: Add time namespace page
From: Andrei Vagin @ 2020-06-05 7:45 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Dmitry Safonov
Cc: Mark Rutland, linux-kernel, Andrei Vagin, Thomas Gleixner,
Vincenzo Frascino, linux-arm-kernel
In-Reply-To: <20200602180259.76361-4-avagin@gmail.com>
Allocate the time namespace page among VVAR pages. Provide
__arch_get_timens_vdso_data() helper for VDSO code to get the
code-relative position of VVARs on that special page.
If a task belongs to a time namespace then the VVAR page which contains
the system wide VDSO data is replaced with a namespace specific page
which has the same layout as the VVAR page. That page has vdso_data->seq
set to 1 to enforce the slow path and vdso_data->clock_mode set to
VCLOCK_TIMENS to enforce the time namespace handling path.
The extra check in the case that vdso_data->seq is odd, e.g. a concurrent
update of the VDSO data is in progress, is not really affecting regular
tasks which are not part of a time namespace as the task is spin waiting
for the update to finish and vdso_data->seq to become even again.
If a time namespace task hits that code path, it invokes the corresponding
time getter function which retrieves the real VVAR page, reads host time
and then adds the offset for the requested clock which is stored in the
special VVAR page.
Cc: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Reviewed-by: Dmitry Safonov <dima@arista.com>
Signed-off-by: Andrei Vagin <avagin@gmail.com>
---
v4: - fix an issue reported by the lkp robot.
- vvar has the same size with/without CONFIG_TIME_NAMESPACE, but the
timens page isn't allocated on !CONFIG_TIME_NAMESPACE. This
simplifies criu/vdso migration between different kernel configs.
arch/arm64/include/asm/vdso.h | 2 ++
.../include/asm/vdso/compat_gettimeofday.h | 12 +++++++++++
arch/arm64/include/asm/vdso/gettimeofday.h | 8 ++++++++
arch/arm64/kernel/vdso.c | 20 ++++++++++++++++---
arch/arm64/kernel/vdso/vdso.lds.S | 5 ++++-
arch/arm64/kernel/vdso32/vdso.lds.S | 5 ++++-
include/vdso/datapage.h | 1 +
7 files changed, 48 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/include/asm/vdso.h b/arch/arm64/include/asm/vdso.h
index 07468428fd29..f99dcb94b438 100644
--- a/arch/arm64/include/asm/vdso.h
+++ b/arch/arm64/include/asm/vdso.h
@@ -12,6 +12,8 @@
*/
#define VDSO_LBASE 0x0
+#define __VVAR_PAGES 2
+
#ifndef __ASSEMBLY__
#include <generated/vdso-offsets.h>
diff --git a/arch/arm64/include/asm/vdso/compat_gettimeofday.h b/arch/arm64/include/asm/vdso/compat_gettimeofday.h
index b6907ae78e53..b7c549d46d18 100644
--- a/arch/arm64/include/asm/vdso/compat_gettimeofday.h
+++ b/arch/arm64/include/asm/vdso/compat_gettimeofday.h
@@ -152,6 +152,18 @@ static __always_inline const struct vdso_data *__arch_get_vdso_data(void)
return ret;
}
+#ifdef CONFIG_TIME_NS
+static __always_inline const struct vdso_data *__arch_get_timens_vdso_data(void)
+{
+ const struct vdso_data *ret;
+
+ /* See __arch_get_vdso_data(). */
+ asm volatile("mov %0, %1" : "=r"(ret) : "r"(_timens_data));
+
+ return ret;
+}
+#endif
+
#endif /* !__ASSEMBLY__ */
#endif /* __ASM_VDSO_GETTIMEOFDAY_H */
diff --git a/arch/arm64/include/asm/vdso/gettimeofday.h b/arch/arm64/include/asm/vdso/gettimeofday.h
index afba6ba332f8..cf39eae5eaaf 100644
--- a/arch/arm64/include/asm/vdso/gettimeofday.h
+++ b/arch/arm64/include/asm/vdso/gettimeofday.h
@@ -96,6 +96,14 @@ const struct vdso_data *__arch_get_vdso_data(void)
return _vdso_data;
}
+#ifdef CONFIG_TIME_NS
+static __always_inline
+const struct vdso_data *__arch_get_timens_vdso_data(void)
+{
+ return _timens_data;
+}
+#endif
+
#endif /* !__ASSEMBLY__ */
#endif /* __ASM_VDSO_GETTIMEOFDAY_H */
diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index 33df3cdf7982..fd609120386d 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -46,6 +46,12 @@ enum arch_vdso_type {
#define VDSO_TYPES (ARM64_VDSO + 1)
#endif /* CONFIG_COMPAT_VDSO */
+enum vvar_pages {
+ VVAR_DATA_PAGE_OFFSET,
+ VVAR_TIMENS_PAGE_OFFSET,
+ VVAR_NR_PAGES,
+};
+
struct __vdso_abi {
const char *name;
const char *vdso_code_start;
@@ -81,6 +87,7 @@ static union {
} vdso_data_store __page_aligned_data;
struct vdso_data *vdso_data = vdso_data_store.data;
+
static int __vdso_remap(enum arch_vdso_type arch_index,
const struct vm_special_mapping *sm,
struct vm_area_struct *new_vma)
@@ -132,6 +139,11 @@ static int __vdso_init(enum arch_vdso_type arch_index)
}
#ifdef CONFIG_TIME_NS
+struct vdso_data *arch_get_vdso_data(void *vvar_page)
+{
+ return (struct vdso_data *)(vvar_page);
+}
+
/*
* The vvar page layout depends on whether a task belongs to the root or
* non-root time namespace. Whenever a task changes its namespace, the VVAR
@@ -180,9 +192,11 @@ static int __setup_additional_pages(enum arch_vdso_type arch_index,
unsigned long vdso_base, vdso_text_len, vdso_mapping_len;
void *ret;
+ BUILD_BUG_ON(VVAR_NR_PAGES != __VVAR_PAGES);
+
vdso_text_len = vdso_lookup[arch_index].vdso_pages << PAGE_SHIFT;
/* Be sure to map the data page */
- vdso_mapping_len = vdso_text_len + PAGE_SIZE;
+ vdso_mapping_len = vdso_text_len + VVAR_NR_PAGES * PAGE_SIZE;
vdso_base = get_unmapped_area(NULL, 0, vdso_mapping_len, 0, 0);
if (IS_ERR_VALUE(vdso_base)) {
@@ -190,13 +204,13 @@ static int __setup_additional_pages(enum arch_vdso_type arch_index,
goto up_fail;
}
- ret = _install_special_mapping(mm, vdso_base, PAGE_SIZE,
+ ret = _install_special_mapping(mm, vdso_base, VVAR_NR_PAGES * PAGE_SIZE,
VM_READ|VM_MAYREAD|VM_PFNMAP,
vdso_lookup[arch_index].dm);
if (IS_ERR(ret))
goto up_fail;
- vdso_base += PAGE_SIZE;
+ vdso_base += VVAR_NR_PAGES * PAGE_SIZE;
mm->context.vdso = (void *)vdso_base;
ret = _install_special_mapping(mm, vdso_base, vdso_text_len,
VM_READ|VM_EXEC|
diff --git a/arch/arm64/kernel/vdso/vdso.lds.S b/arch/arm64/kernel/vdso/vdso.lds.S
index 7ad2d3a0cd48..d808ad31e01f 100644
--- a/arch/arm64/kernel/vdso/vdso.lds.S
+++ b/arch/arm64/kernel/vdso/vdso.lds.S
@@ -17,7 +17,10 @@ OUTPUT_ARCH(aarch64)
SECTIONS
{
- PROVIDE(_vdso_data = . - PAGE_SIZE);
+ PROVIDE(_vdso_data = . - __VVAR_PAGES * PAGE_SIZE);
+#ifdef CONFIG_TIME_NS
+ PROVIDE(_timens_data = _vdso_data + PAGE_SIZE);
+#endif
. = VDSO_LBASE + SIZEOF_HEADERS;
.hash : { *(.hash) } :text
diff --git a/arch/arm64/kernel/vdso32/vdso.lds.S b/arch/arm64/kernel/vdso32/vdso.lds.S
index a3944927eaeb..06cc60a9630f 100644
--- a/arch/arm64/kernel/vdso32/vdso.lds.S
+++ b/arch/arm64/kernel/vdso32/vdso.lds.S
@@ -17,7 +17,10 @@ OUTPUT_ARCH(arm)
SECTIONS
{
- PROVIDE_HIDDEN(_vdso_data = . - PAGE_SIZE);
+ PROVIDE_HIDDEN(_vdso_data = . - __VVAR_PAGES * PAGE_SIZE);
+#ifdef CONFIG_TIME_NS
+ PROVIDE_HIDDEN(_timens_data = _vdso_data + PAGE_SIZE);
+#endif
. = VDSO_LBASE + SIZEOF_HEADERS;
.hash : { *(.hash) } :text
diff --git a/include/vdso/datapage.h b/include/vdso/datapage.h
index 7955c56d6b3c..ee810cae4e1e 100644
--- a/include/vdso/datapage.h
+++ b/include/vdso/datapage.h
@@ -109,6 +109,7 @@ struct vdso_data {
* relocation, and this is what we need.
*/
extern struct vdso_data _vdso_data[CS_BASES] __attribute__((visibility("hidden")));
+extern struct vdso_data _timens_data[CS_BASES] __attribute__((visibility("hidden")));
/*
* The generic vDSO implementation requires that gettimeofday.h
--
2.24.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] arm64: fpsimd: Added API to manage fpsimd state inside kernel
From: Wooyeon Kim @ 2020-06-05 7:30 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Mark Rutland, hk92.kim, Wooki Min, Bhupesh Sharma, yb.song,
yj.yim, Julien Grall, Vincenzo Frascino, Sanghoon Lee,
jinsoo37.kim, hyewon.ryu, yhwan.joo, Anisse Astier, Marc Zyngier,
dongww.kim, linux-arm-kernel, jihun.kim, Dave Martin, Kees Cook,
Suzuki K Poulose, Sudeep Holla, Kristina Martsenko, junik.lee,
sgun.bae, Jeongtae Park, kgene.kim, Wooyeon Kim, Thomas Gleixner,
Allison Randal, Steve Capper, Greg Kroah-Hartman, linux-kernel,
James Morse, hyeyeon5.shim, dh.han
In-Reply-To: <CGME20200605073214epcas2p1576f3f90dbcefaad6180f2559ca5980d@epcas2p1.samsung.com>
From: Wooki Min <wooki.min@samsung.com>
This is an patch to use FPSIMD register in Kernel space.
It need to manage to use FPSIMD register without damaging it
of the user task.
Following items have been implemented and added.
1. Using FPSIMD in ISR (in_interrupt)
It can used __efi_fpsimd_begin/__efi_fpsimd_end
which is already implemented.
Save fpsimd state before entering ISR,
and restore fpsimd state after ISR ends.
For use in external kernel module,
it is declared as EXPORT_SYMBOL.
2. User task -> Function in kernel
Add fpsimd_get/fpsimd_put API to save/restore
FPSIMD in use by the user.
In this case, depth variable is used to set fpsimd usage
depth between User and Kernel space.
* fpsimd_get: Save the FPSIMD of the user task.
* fpsimd_put: Restore the FPSIMD of the user task.
EX> fpsimd_get();
API in kernel space();
fpsimd_put();
3. Add kernel task FPSIMD save/restore in "fpsimd_thread_switch"
It checks the depth value in current task structure and
does save/restore action for FP/SIMD register used by kernel
context.
Signed-off-by: Wooki Min <wooki.min@samsung.com>
Signed-off-by: Jeongtae Park <jtp.park@samsung.com>
Signed-off-by: Sanghoon Lee <shoon114.lee@samsung.com>
Signed-off-by: Wooyeon Kim <wooy88.kim@samsung.com>
---
arch/arm64/include/asm/fpsimd.h | 6 +++
arch/arm64/include/asm/processor.h | 13 +++++
arch/arm64/include/uapi/asm/ptrace.h | 8 ++++
arch/arm64/kernel/fpsimd.c | 71 +++++++++++++++++++++++++---
4 files changed, 92 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h
index 59f10dd13f12..462c434fc57c 100644
--- a/arch/arm64/include/asm/fpsimd.h
+++ b/arch/arm64/include/asm/fpsimd.h
@@ -167,6 +167,12 @@ static inline void sve_setup(void) { }
extern void __efi_fpsimd_begin(void);
extern void __efi_fpsimd_end(void);
+void fpsimd_set_task_using(struct task_struct *t);
+void fpsimd_clr_task_using(struct task_struct *t);
+
+void fpsimd_get(void);
+void fpsimd_put(void);
+
#endif
#endif
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index 240fe5e5b720..265669456bcb 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -139,6 +139,19 @@ struct thread_struct {
unsigned long tp2_value;
struct user_fpsimd_state fpsimd_state;
} uw;
+ struct fpsimd_kernel_state fpsimd_kernel_state;
+
+ /*
+ * indicate the depth of using FP/SIMD registers in kernel mode.
+ * above kernel state should be preserved at first time
+ * before FP/SIMD registers be used by other tasks
+ * and the state should be restored before they be used by own.
+ *
+ * a kernel thread which uses FP/SIMD registers have to
+ * set this depth and it could utilize for a tasks executes
+ * some NEON instructions without preemption disable.
+ */
+ atomic_t fpsimd_kernel_depth;
unsigned int fpsimd_cpu;
void *sve_state; /* SVE registers, if any */
diff --git a/arch/arm64/include/uapi/asm/ptrace.h b/arch/arm64/include/uapi/asm/ptrace.h
index 42cbe34d95ce..0327e719721e 100644
--- a/arch/arm64/include/uapi/asm/ptrace.h
+++ b/arch/arm64/include/uapi/asm/ptrace.h
@@ -105,6 +105,14 @@ struct user_hwdebug_state {
} dbg_regs[16];
};
+/* Kernel structure for floating point */
+struct fpsimd_kernel_state {
+ __uint128_t vregs[32];
+ __u32 fpsr;
+ __u32 fpcr;
+ unsigned int cpu;
+};
+
/* SVE/FP/SIMD state (NT_ARM_SVE) */
struct user_sve_header {
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 35cb5e66c504..07597423fcfc 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -269,9 +269,6 @@ static void sve_free(struct task_struct *task)
*/
static void task_fpsimd_load(void)
{
- WARN_ON(!system_supports_fpsimd());
- WARN_ON(!have_cpu_fpsimd_context());
-
if (system_supports_sve() && test_thread_flag(TIF_SVE))
sve_load_state(sve_pffr(¤t->thread),
¤t->thread.uw.fpsimd_state.fpsr,
@@ -290,9 +287,6 @@ static void fpsimd_save(void)
this_cpu_ptr(&fpsimd_last_state);
/* set by fpsimd_bind_task_to_cpu() or fpsimd_bind_state_to_cpu() */
- WARN_ON(!system_supports_fpsimd());
- WARN_ON(!have_cpu_fpsimd_context());
-
if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {
if (system_supports_sve() && test_thread_flag(TIF_SVE)) {
if (WARN_ON(sve_get_vl() != last->sve_vl)) {
@@ -982,6 +976,10 @@ void do_fpsimd_exc(unsigned int esr, struct pt_regs *regs)
void fpsimd_thread_switch(struct task_struct *next)
{
bool wrong_task, wrong_cpu;
+ struct fpsimd_kernel_state *cur_kst
+ = ¤t->thread.fpsimd_kernel_state;
+ struct fpsimd_kernel_state *nxt_kst
+ = &next->thread.fpsimd_kernel_state;
if (!system_supports_fpsimd())
return;
@@ -991,6 +989,16 @@ void fpsimd_thread_switch(struct task_struct *next)
/* Save unsaved fpsimd state, if any: */
fpsimd_save();
+ if (atomic_read(¤t->thread.fpsimd_kernel_depth))
+ fpsimd_save_state((struct user_fpsimd_state *)cur_kst);
+
+ if (atomic_read(&next->thread.fpsimd_kernel_depth)) {
+ fpsimd_load_state((struct user_fpsimd_state *)nxt_kst);
+ this_cpu_write(fpsimd_last_state.st,
+ (struct user_fpsimd_state *)nxt_kst);
+ nxt_kst->cpu = smp_processor_id();
+ }
+
/*
* Fix up TIF_FOREIGN_FPSTATE to correctly describe next's
* state. For kernel threads, FPSIMD registers are never loaded
@@ -1233,6 +1241,55 @@ void fpsimd_save_and_flush_cpu_state(void)
__put_cpu_fpsimd_context();
}
+void fpsimd_set_task_using(struct task_struct *t)
+{
+ atomic_set(&t->thread.fpsimd_kernel_depth, 1);
+}
+EXPORT_SYMBOL(fpsimd_set_task_using);
+
+void fpsimd_clr_task_using(struct task_struct *t)
+{
+ atomic_set(&t->thread.fpsimd_kernel_depth, 0);
+}
+EXPORT_SYMBOL(fpsimd_clr_task_using);
+
+void fpsimd_get(void)
+{
+ if (in_interrupt())
+ return;
+
+ if (atomic_inc_return(¤t->thread.fpsimd_kernel_depth) == 1) {
+ preempt_disable();
+ if (current->mm) {
+ fpsimd_save();
+ fpsimd_flush_task_state(current);
+ }
+ fpsimd_flush_cpu_state();
+ preempt_enable();
+ }
+}
+EXPORT_SYMBOL(fpsimd_get);
+
+void fpsimd_put(void)
+{
+ if (in_interrupt())
+ return;
+
+ WARN_ON(atomic_dec_return(
+ ¤t->thread.fpsimd_kernel_depth) < 0);
+
+ if (atomic_read(¤t->thread.fpsimd_kernel_depth) == 0) {
+ preempt_disable();
+ if (current->mm && test_thread_flag(TIF_FOREIGN_FPSTATE)) {
+ task_fpsimd_load();
+ fpsimd_bind_task_to_cpu();
+ clear_thread_flag(TIF_FOREIGN_FPSTATE);
+ }
+ preempt_enable();
+ }
+}
+EXPORT_SYMBOL(fpsimd_put);
+
#ifdef CONFIG_KERNEL_MODE_NEON
/*
@@ -1338,6 +1395,7 @@ void __efi_fpsimd_begin(void)
__this_cpu_write(efi_fpsimd_state_used, true);
}
}
+EXPORT_SYMBOL(__efi_fpsimd_begin);
/*
* __efi_fpsimd_end(): clean up FPSIMD after an EFI runtime services call
@@ -1364,6 +1422,7 @@ void __efi_fpsimd_end(void)
}
}
}
+EXPORT_SYMBOL(__efi_fpsimd_end);
#endif /* CONFIG_EFI */
--
2.27.0.rc0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: Security Random Number Generator support
From: Neal Liu @ 2020-06-05 7:19 UTC (permalink / raw)
To: Russell King - ARM Linux admin, Marc Zyngier
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Julius Werner, Herbert Xu, Arnd Bergmann, Greg Kroah-Hartman,
Sean Wang, linux-mediatek@lists.infradead.org, lkml, wsd_upstream,
Rob Herring, Neal Liu, Linux Crypto Mailing List, Matt Mackall,
Matthias Brugger, Crystal Guo (郭晶), Ard Biesheuvel,
Linux ARM
In-Reply-To: <20200603093416.GY1551@shell.armlinux.org.uk>
On Wed, 2020-06-03 at 17:34 +0800, Russell King - ARM Linux admin wrote:
> On Wed, Jun 03, 2020 at 08:40:58AM +0100, Marc Zyngier wrote:
> > On 2020-06-03 08:29, Neal Liu wrote:
> > > On Tue, 2020-06-02 at 21:02 +0800, Marc Zyngier wrote:
> > > > On 2020-06-02 13:14, Ard Biesheuvel wrote:
> > > > > On Tue, 2 Jun 2020 at 10:15, Neal Liu <neal.liu@mediatek.com> wrote:
> > > > >>
> > > > >> These patch series introduce a security random number generator
> > > > >> which provides a generic interface to get hardware rnd from Secure
> > > > >> state. The Secure state can be Arm Trusted Firmware(ATF), Trusted
> > > > >> Execution Environment(TEE), or even EL2 hypervisor.
> > > > >>
> > > > >> Patch #1..2 adds sec-rng kernel driver for Trustzone based SoCs.
> > > > >> For security awareness SoCs on ARMv8 with TrustZone enabled,
> > > > >> peripherals like entropy sources is not accessible from normal world
> > > > >> (linux) and rather accessible from secure world (HYP/ATF/TEE) only.
> > > > >> This driver aims to provide a generic interface to Arm Trusted
> > > > >> Firmware or Hypervisor rng service.
> > > > >>
> > > > >>
> > > > >> changes since v1:
> > > > >> - rename mt67xx-rng to mtk-sec-rng since all MediaTek ARMv8 SoCs can
> > > > >> reuse
> > > > >> this driver.
> > > > >> - refine coding style and unnecessary check.
> > > > >>
> > > > >> changes since v2:
> > > > >> - remove unused comments.
> > > > >> - remove redundant variable.
> > > > >>
> > > > >> changes since v3:
> > > > >> - add dt-bindings for MediaTek rng with TrustZone enabled.
> > > > >> - revise HWRNG SMC call fid.
> > > > >>
> > > > >> changes since v4:
> > > > >> - move bindings to the arm/firmware directory.
> > > > >> - revise driver init flow to check more property.
> > > > >>
> > > > >> changes since v5:
> > > > >> - refactor to more generic security rng driver which
> > > > >> is not platform specific.
> > > > >>
> > > > >> *** BLURB HERE ***
> > > > >>
> > > > >> Neal Liu (2):
> > > > >> dt-bindings: rng: add bindings for sec-rng
> > > > >> hwrng: add sec-rng driver
> > > > >>
> > > > >
> > > > > There is no reason to model a SMC call as a driver, and represent it
> > > > > via a DT node like this.
> > > >
> > > > +1.
> > > >
> > > > > It would be much better if this SMC interface is made truly generic,
> > > > > and wired into the arch_get_random() interface, which can be used much
> > > > > earlier.
> > > >
> > > > Wasn't there a plan to standardize a SMC call to rule them all?
> > > >
> > > > M.
> > >
> > > Could you give us a hint how to make this SMC interface more generic in
> > > addition to my approach?
> > > There is no (easy) way to get platform-independent SMC function ID,
> > > which is why we encode it into device tree, and provide a generic
> > > driver. In this way, different devices can be mapped and then get
> > > different function ID internally.
> >
> > The idea is simply to have *one* single ID that caters for all
> > implementations, just like we did for PSCI at the time. This
> > requires ARM to edict a standard, which is what I was referring
> > to above.
>
> This sounds all too familiar.
>
> This kind of thing is something that ARM have seems to shy away from
> doing - it's a point I brought up many years ago when the whole
> trustzone thing first appeared with its SMC call. Those around the
> conference table were not interested - ARM seemed to prefer every
> vendor to do off and do their own thing with the SMC interface.
Does that mean it make sense to model a sec-rng driver, and get each
vendor's SMC function id by DT node?
>
> Then OMAP came along with its SMC interfaces, and so did the pain of
> not having a standardised way to configure the L2C when Linux was
> running in the non-secure world, resulting in stuff like l2c_configure
> etc, where each and every implementation has to supply a function to
> call its platform specific SMC interfaces to configure a piece of
> hardware common across many different platforms.
>
> ARM have seemed reluctant to standardise on stuff like this, so
> unless someone pushes hard for it from inside ARM, I doubt it will
> ever happen.
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v10 07/20] dt-bindings: mtd: Document boolean NAND ECC properties
From: Miquel Raynal @ 2020-06-05 7:18 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Vignesh Raghavendra, Tudor Ambarus,
Julien Su, Richard Weinberger, Boris Brezillon, linux-mtd,
Thomas Petazzoni, Mason Yang, linux-arm-kernel
In-Reply-To: <20200604230804.GA13821@bogus>
Hi Rob,
Rob Herring <robh@kernel.org> wrote on Thu, 4 Jun 2020 17:08:04 -0600:
> On Wed, Jun 03, 2020 at 07:57:46PM +0200, Miquel Raynal wrote:
> > Document nand-use-soft-ecc-engine and nand-no-ecc-engine properties.
> > The former is here to force software correction, the latter prevents
> > any correction to happen.
> >
> > These properties (along with nand-ecc-engine) are supposed to be more
> > accurate than the current nand-ecc-modes wich is very misleading and
> > very often people think it is mandatory while the core should be
> > relied upon to decide which correction to handle.
> >
> > nand-ecc-mode was already inacurate, but it becomes totally
> > problematic with setups where there are several hardware engines.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > ---
> > Documentation/devicetree/bindings/mtd/nand-controller.yaml | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
> > index 0969d2e6720b..a3750978ebb8 100644
> > --- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml
> > +++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
> > @@ -68,6 +68,12 @@ patternProperties:
> > 3/ The ECC engine is external, in this case the phandle should
> > reference the specific ECC engine node.
> >
> > + nand-use-soft-ecc-engine: true
> > + description: Use a software ECC engine.
>
> Humm, I'm surprised this is valid YAML. nand-use-soft-ecc-engine can't
> be both a boolean and a map (aka schema, aka dict).
>
> nand-use-soft-ecc-engine:
> type: boolean
> description: ...
>
Ok, I might have been inspired from this line in example-schema.yaml:
interrupt-controller: true
# The core checks this is a boolean, so just have to list it here to be
# valid for this binding.
Thanks for the review, I'll correct it.
Cheers,
Miquèl
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
From: Lee Jones @ 2020-06-05 6:57 UTC (permalink / raw)
To: Michael Walle, broonie
Cc: devicetree, Linus Walleij, Thierry Reding, Jason Cooper,
Andy Shevchenko, Marc Zyngier, Bartosz Golaszewski,
Uwe Kleine-König, Guenter Roeck, linux-pwm, Jean Delvare,
linux-watchdog, linux-gpio, Mark Brown, Thomas Gleixner,
Wim Van Sebroeck, linux-arm-kernel, linux-hwmon,
Greg Kroah-Hartman, linux-kernel, Li Yang, Rob Herring, Shawn Guo
In-Reply-To: <20200604211039.12689-3-michael@walle.cc>
Mark, what do you think?
On Thu, 04 Jun 2020, Michael Walle wrote:
> Add the core support for the board management controller found on the
> SMARC-sAL28 board. It consists of the following functions:
> - watchdog
> - GPIO controller
> - PWM controller
> - fan sensor
> - interrupt controller
>
> At the moment, this controller is used on the Kontron SMARC-sAL28 board.
>
> Please note that the MFD driver is defined as bool in the Kconfig
> because the next patch will add interrupt support.
>
> Signed-off-by: Michael Walle <michael@walle.cc>
> ---
> drivers/mfd/Kconfig | 19 ++++++++++
> drivers/mfd/Makefile | 2 ++
> drivers/mfd/sl28cpld.c | 79 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 100 insertions(+)
> create mode 100644 drivers/mfd/sl28cpld.c
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 4f8b73d92df3..5c0cd514d197 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -2109,5 +2109,24 @@ config SGI_MFD_IOC3
> If you have an SGI Origin, Octane, or a PCI IOC3 card,
> then say Y. Otherwise say N.
>
> +config MFD_SL28CPLD
> + bool "Kontron sl28 core driver"
"Kontron SL28 Core Driver"
> + depends on I2C=y
> + depends on OF
> + select REGMAP_I2C
> + select MFD_CORE
> + help
> + This option enables support for the board management controller
> + found on the Kontron sl28 CPLD. You have to select individual
I can't find any reference to the "Kontron sl28 CPLD" online.
Is there a datasheet?
> + functions, such as watchdog, GPIO, etc, under the corresponding menus
> + in order to enable them.
> +
> + Currently supported boards are:
> +
> + Kontron SMARC-sAL28
> +
> + To compile this driver as a module, choose M here: the module will be
> + called sl28cpld.
> +
> endmenu
> endif
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 9367a92f795a..be59fb40aa28 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -264,3 +264,5 @@ obj-$(CONFIG_MFD_ROHM_BD718XX) += rohm-bd718x7.o
> obj-$(CONFIG_MFD_STMFX) += stmfx.o
>
> obj-$(CONFIG_SGI_MFD_IOC3) += ioc3.o
> +
> +obj-$(CONFIG_MFD_SL28CPLD) += sl28cpld.o
> diff --git a/drivers/mfd/sl28cpld.c b/drivers/mfd/sl28cpld.c
> new file mode 100644
> index 000000000000..a23194bb6efa
> --- /dev/null
> +++ b/drivers/mfd/sl28cpld.c
> @@ -0,0 +1,79 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * MFD core for the sl28cpld.
Ideally this would match the Kconfig subject line.
> + * Copyright 2019 Kontron Europe GmbH
This is out of date.
> + */
> +
> +#include <linux/i2c.h>
> +#include <linux/interrupt.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/core.h>
> +#include <linux/module.h>
> +#include <linux/of_platform.h>
> +#include <linux/regmap.h>
> +
> +#define SL28CPLD_VERSION 0x03
> +#define SL28CPLD_MIN_REQ_VERSION 14
> +
> +struct sl28cpld {
> + struct device *dev;
> + struct regmap *regmap;
> +};
Why do you need this structure?
> +static const struct regmap_config sl28cpld_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .reg_stride = 1,
> +};
> +
> +static int sl28cpld_probe(struct i2c_client *i2c)
> +{
> + struct sl28cpld *sl28cpld;
> + struct device *dev = &i2c->dev;
> + unsigned int cpld_version;
> + int ret;
> +
> + sl28cpld = devm_kzalloc(dev, sizeof(*sl28cpld), GFP_KERNEL);
> + if (!sl28cpld)
> + return -ENOMEM;
> +
> + sl28cpld->regmap = devm_regmap_init_i2c(i2c, &sl28cpld_regmap_config);
> + if (IS_ERR(sl28cpld->regmap))
> + return PTR_ERR(sl28cpld->regmap);
This is now a shared memory allocator and not an MFD at all.
I'm clamping down on these type of drivers!
Please find a better way to accomplish this.
Potentially using "simple-mfd" and "simple-regmap".
The former already exists and does what you want. The latter doesn't
yet exist, but could solve your and lots of other contributor's
issues.
Heck maybe I'll implement it myself if this keeps happening.
> + ret = regmap_read(sl28cpld->regmap, SL28CPLD_VERSION, &cpld_version);
> + if (ret)
> + return ret;
> +
> + if (cpld_version < SL28CPLD_MIN_REQ_VERSION) {
> + dev_err(dev, "unsupported CPLD version %d\n", cpld_version);
> + return -ENODEV;
> + }
> +
> + sl28cpld->dev = dev;
> + i2c_set_clientdata(i2c, sl28cpld);
If the struct definition is in here, how do you use it elsewhere?
> + dev_info(dev, "successfully probed. CPLD version %d\n", cpld_version);
> +
> + return devm_of_platform_populate(&i2c->dev);
> +}
> +
> +static const struct of_device_id sl28cpld_of_match[] = {
> + { .compatible = "kontron,sl28cpld-r1", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, sl28cpld_of_match);
> +
> +static struct i2c_driver sl28cpld_driver = {
> + .probe_new = sl28cpld_probe,
> + .driver = {
> + .name = "sl28cpld",
> + .of_match_table = of_match_ptr(sl28cpld_of_match),
> + },
> +};
> +module_i2c_driver(sl28cpld_driver);
> +
> +MODULE_DESCRIPTION("sl28cpld MFD Core Driver");
> +MODULE_AUTHOR("Michael Walle <michael@walle.cc>");
> +MODULE_LICENSE("GPL");
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 8/8] pinctrl: imx8dxl: Support building as module
From: Anson Huang @ 2020-06-05 6:34 UTC (permalink / raw)
To: aisheng.dong, festevam, shawnguo, stefan, kernel, linus.walleij,
s.hauer, linux-gpio, linux-kernel, linux-arm-kernel
Cc: Linux-imx
In-Reply-To: <1591338874-4733-1-git-send-email-Anson.Huang@nxp.com>
Support building i.MX8DXL pinctrl driver as module.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
drivers/pinctrl/freescale/Kconfig | 2 +-
drivers/pinctrl/freescale/pinctrl-imx8dxl.c | 9 +++------
2 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/pinctrl/freescale/Kconfig b/drivers/pinctrl/freescale/Kconfig
index d9fb5f2..08fcf5c 100644
--- a/drivers/pinctrl/freescale/Kconfig
+++ b/drivers/pinctrl/freescale/Kconfig
@@ -166,7 +166,7 @@ config PINCTRL_IMX8QXP
Say Y here to enable the imx8qxp pinctrl driver
config PINCTRL_IMX8DXL
- bool "IMX8DXL pinctrl driver"
+ tristate "IMX8DXL pinctrl driver"
depends on IMX_SCU && ARCH_MXC && ARM64
select PINCTRL_IMX_SCU
help
diff --git a/drivers/pinctrl/freescale/pinctrl-imx8dxl.c b/drivers/pinctrl/freescale/pinctrl-imx8dxl.c
index 7f32e57..c11fcfb 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx8dxl.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx8dxl.c
@@ -165,6 +165,7 @@ static const struct of_device_id imx8dxl_pinctrl_of_match[] = {
{ .compatible = "fsl,imx8dxl-iomuxc", },
{ /* sentinel */ }
};
+MODULE_DEVICE_TABLE(of, imx8dxl_pinctrl_of_match);
static int imx8dxl_pinctrl_probe(struct platform_device *pdev)
{
@@ -185,9 +186,5 @@ static struct platform_driver imx8dxl_pinctrl_driver = {
},
.probe = imx8dxl_pinctrl_probe,
};
-
-static int __init imx8dxl_pinctrl_init(void)
-{
- return platform_driver_register(&imx8dxl_pinctrl_driver);
-}
-arch_initcall(imx8dxl_pinctrl_init);
+module_platform_driver(imx8dxl_pinctrl_driver);
+MODULE_LICENSE("GPL v2");
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 7/8] pinctrl: imx8qm: Support building as module
From: Anson Huang @ 2020-06-05 6:34 UTC (permalink / raw)
To: aisheng.dong, festevam, shawnguo, stefan, kernel, linus.walleij,
s.hauer, linux-gpio, linux-kernel, linux-arm-kernel
Cc: Linux-imx
In-Reply-To: <1591338874-4733-1-git-send-email-Anson.Huang@nxp.com>
Support building i.MX8QM pinctrl driver as module.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
drivers/pinctrl/freescale/Kconfig | 2 +-
drivers/pinctrl/freescale/pinctrl-imx8qm.c | 9 +++------
2 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/pinctrl/freescale/Kconfig b/drivers/pinctrl/freescale/Kconfig
index 0a728bb..d9fb5f2 100644
--- a/drivers/pinctrl/freescale/Kconfig
+++ b/drivers/pinctrl/freescale/Kconfig
@@ -152,7 +152,7 @@ config PINCTRL_IMX8MQ
Say Y here to enable the imx8mq pinctrl driver
config PINCTRL_IMX8QM
- bool "IMX8QM pinctrl driver"
+ tristate "IMX8QM pinctrl driver"
depends on IMX_SCU && ARCH_MXC && ARM64
select PINCTRL_IMX_SCU
help
diff --git a/drivers/pinctrl/freescale/pinctrl-imx8qm.c b/drivers/pinctrl/freescale/pinctrl-imx8qm.c
index 0b6029b..905702a 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx8qm.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx8qm.c
@@ -298,6 +298,7 @@ static const struct of_device_id imx8qm_pinctrl_of_match[] = {
{ .compatible = "fsl,imx8qm-iomuxc", },
{ /* sentinel */ }
};
+MODULE_DEVICE_TABLE(of, imx8qm_pinctrl_of_match);
static int imx8qm_pinctrl_probe(struct platform_device *pdev)
{
@@ -318,9 +319,5 @@ static struct platform_driver imx8qm_pinctrl_driver = {
},
.probe = imx8qm_pinctrl_probe,
};
-
-static int __init imx8qm_pinctrl_init(void)
-{
- return platform_driver_register(&imx8qm_pinctrl_driver);
-}
-arch_initcall(imx8qm_pinctrl_init);
+module_platform_driver(imx8qm_pinctrl_driver);
+MODULE_LICENSE("GPL v2");
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 6/8] pinctrl: imx8qxp: Support building as module
From: Anson Huang @ 2020-06-05 6:34 UTC (permalink / raw)
To: aisheng.dong, festevam, shawnguo, stefan, kernel, linus.walleij,
s.hauer, linux-gpio, linux-kernel, linux-arm-kernel
Cc: Linux-imx
In-Reply-To: <1591338874-4733-1-git-send-email-Anson.Huang@nxp.com>
Support building i.MX8QXP pinctrl driver as module.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
drivers/pinctrl/freescale/Kconfig | 2 +-
drivers/pinctrl/freescale/pinctrl-imx8qxp.c | 9 +++------
2 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/pinctrl/freescale/Kconfig b/drivers/pinctrl/freescale/Kconfig
index 2bf90b3..0a728bb 100644
--- a/drivers/pinctrl/freescale/Kconfig
+++ b/drivers/pinctrl/freescale/Kconfig
@@ -159,7 +159,7 @@ config PINCTRL_IMX8QM
Say Y here to enable the imx8qm pinctrl driver
config PINCTRL_IMX8QXP
- bool "IMX8QXP pinctrl driver"
+ tristate "IMX8QXP pinctrl driver"
depends on IMX_SCU && ARCH_MXC && ARM64
select PINCTRL_IMX_SCU
help
diff --git a/drivers/pinctrl/freescale/pinctrl-imx8qxp.c b/drivers/pinctrl/freescale/pinctrl-imx8qxp.c
index 1131dc3..0eaa36b 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx8qxp.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx8qxp.c
@@ -204,6 +204,7 @@ static const struct of_device_id imx8qxp_pinctrl_of_match[] = {
{ .compatible = "fsl,imx8qxp-iomuxc", },
{ /* sentinel */ }
};
+MODULE_DEVICE_TABLE(of, imx8qxp_pinctrl_of_match);
static int imx8qxp_pinctrl_probe(struct platform_device *pdev)
{
@@ -224,9 +225,5 @@ static struct platform_driver imx8qxp_pinctrl_driver = {
},
.probe = imx8qxp_pinctrl_probe,
};
-
-static int __init imx8qxp_pinctrl_init(void)
-{
- return platform_driver_register(&imx8qxp_pinctrl_driver);
-}
-arch_initcall(imx8qxp_pinctrl_init);
+module_platform_driver(imx8qxp_pinctrl_driver);
+MODULE_LICENSE("GPL v2");
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 5/8] pinctrl: imx8mp: Support building as module
From: Anson Huang @ 2020-06-05 6:34 UTC (permalink / raw)
To: aisheng.dong, festevam, shawnguo, stefan, kernel, linus.walleij,
s.hauer, linux-gpio, linux-kernel, linux-arm-kernel
Cc: Linux-imx
In-Reply-To: <1591338874-4733-1-git-send-email-Anson.Huang@nxp.com>
Support building i.MX8MP pinctrl driver as module.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
drivers/pinctrl/freescale/Kconfig | 2 +-
drivers/pinctrl/freescale/pinctrl-imx8mp.c | 10 ++++------
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/pinctrl/freescale/Kconfig b/drivers/pinctrl/freescale/Kconfig
index df77e752..2bf90b3 100644
--- a/drivers/pinctrl/freescale/Kconfig
+++ b/drivers/pinctrl/freescale/Kconfig
@@ -138,7 +138,7 @@ config PINCTRL_IMX8MN
Say Y here to enable the imx8mn pinctrl driver
config PINCTRL_IMX8MP
- bool "IMX8MP pinctrl driver"
+ tristate "IMX8MP pinctrl driver"
depends on ARCH_MXC
select PINCTRL_IMX
help
diff --git a/drivers/pinctrl/freescale/pinctrl-imx8mp.c b/drivers/pinctrl/freescale/pinctrl-imx8mp.c
index e3f644c..f3f3bdd 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx8mp.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx8mp.c
@@ -5,6 +5,7 @@
#include <linux/err.h>
#include <linux/init.h>
+#include <linux/module.h>
#include <linux/of.h>
#include <linux/pinctrl/pinctrl.h>
#include <linux/platform_device.h>
@@ -324,6 +325,7 @@ static const struct of_device_id imx8mp_pinctrl_of_match[] = {
{ .compatible = "fsl,imx8mp-iomuxc", .data = &imx8mp_pinctrl_info, },
{ /* sentinel */ }
};
+MODULE_DEVICE_TABLE(of, imx8mp_pinctrl_of_match);
static int imx8mp_pinctrl_probe(struct platform_device *pdev)
{
@@ -337,9 +339,5 @@ static struct platform_driver imx8mp_pinctrl_driver = {
},
.probe = imx8mp_pinctrl_probe,
};
-
-static int __init imx8mp_pinctrl_init(void)
-{
- return platform_driver_register(&imx8mp_pinctrl_driver);
-}
-arch_initcall(imx8mp_pinctrl_init);
+module_platform_driver(imx8mp_pinctrl_driver);
+MODULE_LICENSE("GPL v2");
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/8] pinctrl: imx8mn: Support building as module
From: Anson Huang @ 2020-06-05 6:34 UTC (permalink / raw)
To: aisheng.dong, festevam, shawnguo, stefan, kernel, linus.walleij,
s.hauer, linux-gpio, linux-kernel, linux-arm-kernel
Cc: Linux-imx
In-Reply-To: <1591338874-4733-1-git-send-email-Anson.Huang@nxp.com>
Support building i.MX8MN pinctrl driver as module.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
drivers/pinctrl/freescale/Kconfig | 2 +-
drivers/pinctrl/freescale/pinctrl-imx8mn.c | 10 ++++------
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/pinctrl/freescale/Kconfig b/drivers/pinctrl/freescale/Kconfig
index 3681c4d..b909719 100644
--- a/drivers/pinctrl/freescale/Kconfig
+++ b/drivers/pinctrl/freescale/Kconfig
@@ -131,7 +131,7 @@ config PINCTRL_IMX8MM
Say Y here to enable the imx8mm pinctrl driver
config PINCTRL_IMX8MN
- bool "IMX8MN pinctrl driver"
+ tristate "IMX8MN pinctrl driver"
depends on ARCH_MXC
select PINCTRL_IMX
help
diff --git a/drivers/pinctrl/freescale/pinctrl-imx8mn.c b/drivers/pinctrl/freescale/pinctrl-imx8mn.c
index 100ed8c..b6db780 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx8mn.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx8mn.c
@@ -5,6 +5,7 @@
#include <linux/err.h>
#include <linux/init.h>
+#include <linux/module.h>
#include <linux/of.h>
#include <linux/pinctrl/pinctrl.h>
#include <linux/platform_device.h>
@@ -326,6 +327,7 @@ static const struct of_device_id imx8mn_pinctrl_of_match[] = {
{ .compatible = "fsl,imx8mn-iomuxc", .data = &imx8mn_pinctrl_info, },
{ /* sentinel */ }
};
+MODULE_DEVICE_TABLE(of, imx8mn_pinctrl_of_match);
static int imx8mn_pinctrl_probe(struct platform_device *pdev)
{
@@ -340,9 +342,5 @@ static struct platform_driver imx8mn_pinctrl_driver = {
},
.probe = imx8mn_pinctrl_probe,
};
-
-static int __init imx8mn_pinctrl_init(void)
-{
- return platform_driver_register(&imx8mn_pinctrl_driver);
-}
-arch_initcall(imx8mn_pinctrl_init);
+module_platform_driver(imx8mn_pinctrl_driver);
+MODULE_LICENSE("GPL v2");
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 4/8] pinctrl: imx8mq: Support building as module
From: Anson Huang @ 2020-06-05 6:34 UTC (permalink / raw)
To: aisheng.dong, festevam, shawnguo, stefan, kernel, linus.walleij,
s.hauer, linux-gpio, linux-kernel, linux-arm-kernel
Cc: Linux-imx
In-Reply-To: <1591338874-4733-1-git-send-email-Anson.Huang@nxp.com>
Support building i.MX8MQ pinctrl driver as module.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
drivers/pinctrl/freescale/Kconfig | 2 +-
drivers/pinctrl/freescale/pinctrl-imx8mq.c | 9 ++++-----
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/pinctrl/freescale/Kconfig b/drivers/pinctrl/freescale/Kconfig
index b909719..df77e752 100644
--- a/drivers/pinctrl/freescale/Kconfig
+++ b/drivers/pinctrl/freescale/Kconfig
@@ -145,7 +145,7 @@ config PINCTRL_IMX8MP
Say Y here to enable the imx8mp pinctrl driver
config PINCTRL_IMX8MQ
- bool "IMX8MQ pinctrl driver"
+ tristate "IMX8MQ pinctrl driver"
depends on ARCH_MXC
select PINCTRL_IMX
help
diff --git a/drivers/pinctrl/freescale/pinctrl-imx8mq.c b/drivers/pinctrl/freescale/pinctrl-imx8mq.c
index 50aa1c0..db5b41a 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx8mq.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx8mq.c
@@ -8,6 +8,7 @@
#include <linux/err.h>
#include <linux/init.h>
#include <linux/io.h>
+#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_device.h>
#include <linux/pinctrl/pinctrl.h>
@@ -329,6 +330,7 @@ static const struct of_device_id imx8mq_pinctrl_of_match[] = {
{ .compatible = "fsl,imx8mq-iomuxc", .data = &imx8mq_pinctrl_info, },
{ /* sentinel */ }
};
+MODULE_DEVICE_TABLE(of, imx8mq_pinctrl_of_match);
static int imx8mq_pinctrl_probe(struct platform_device *pdev)
{
@@ -345,8 +347,5 @@ static struct platform_driver imx8mq_pinctrl_driver = {
.probe = imx8mq_pinctrl_probe,
};
-static int __init imx8mq_pinctrl_init(void)
-{
- return platform_driver_register(&imx8mq_pinctrl_driver);
-}
-arch_initcall(imx8mq_pinctrl_init);
+module_platform_driver(imx8mq_pinctrl_driver);
+MODULE_LICENSE("GPL v2");
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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