* [PATCH 5/6] arm64: tegra: Add Tegra194 chip device tree
From: Mikko Perttunen @ 2018-01-08 4:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515387278-29777-1-git-send-email-mperttunen@nvidia.com>
Add the chip-level device tree, including binding headers, for the
NVIDIA Tegra194 "Xavier" system-on-chip. Only a small subset of devices
are initially available, enough to boot to UART console.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 334 +++++++++++++++++++++++++++++
include/dt-bindings/clock/tegra194-clock.h | 59 +++++
include/dt-bindings/gpio/tegra194-gpio.h | 59 +++++
include/dt-bindings/reset/tegra194-reset.h | 40 ++++
4 files changed, 492 insertions(+)
create mode 100644 arch/arm64/boot/dts/nvidia/tegra194.dtsi
create mode 100644 include/dt-bindings/clock/tegra194-clock.h
create mode 100644 include/dt-bindings/gpio/tegra194-gpio.h
create mode 100644 include/dt-bindings/reset/tegra194-reset.h
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
new file mode 100644
index 000000000000..51eff420816d
--- /dev/null
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -0,0 +1,334 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <dt-bindings/clock/tegra194-clock.h>
+#include <dt-bindings/gpio/tegra194-gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/mailbox/tegra186-hsp.h>
+#include <dt-bindings/reset/tegra194-reset.h>
+
+/ {
+ compatible = "nvidia,tegra194";
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ uarta: serial at 3100000 {
+ compatible = "nvidia,tegra194-uart", "nvidia,tegra20-uart";
+ reg = <0x0 0x03100000 0x0 0x40>;
+ reg-shift = <2>;
+ interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&bpmp TEGRA194_CLK_UARTA>;
+ clock-names = "serial";
+ resets = <&bpmp TEGRA194_RESET_UARTA>;
+ reset-names = "serial";
+ status = "disabled";
+ };
+
+ uartb: serial at 3110000 {
+ compatible = "nvidia,tegra194-uart", "nvidia,tegra20-uart";
+ reg = <0x0 0x03110000 0x0 0x40>;
+ reg-shift = <2>;
+ interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&bpmp TEGRA194_CLK_UARTB>;
+ clock-names = "serial";
+ resets = <&bpmp TEGRA194_RESET_UARTB>;
+ reset-names = "serial";
+ status = "disabled";
+ };
+
+ uartd: serial at 3130000 {
+ compatible = "nvidia,tegra194-uart", "nvidia,tegra20-uart";
+ reg = <0x0 0x03130000 0x0 0x40>;
+ reg-shift = <2>;
+ interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&bpmp TEGRA194_CLK_UARTD>;
+ clock-names = "serial";
+ resets = <&bpmp TEGRA194_RESET_UARTD>;
+ reset-names = "serial";
+ status = "disabled";
+ };
+
+ uarte: serial at 3140000 {
+ compatible = "nvidia,tegra194-uart", "nvidia,tegra20-uart";
+ reg = <0x0 0x03140000 0x0 0x40>;
+ reg-shift = <2>;
+ interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&bpmp TEGRA194_CLK_UARTE>;
+ clock-names = "serial";
+ resets = <&bpmp TEGRA194_RESET_UARTE>;
+ reset-names = "serial";
+ status = "disabled";
+ };
+
+ uartf: serial at 3150000 {
+ compatible = "nvidia,tegra194-uart", "nvidia,tegra20-uart";
+ reg = <0x0 0x03150000 0x0 0x40>;
+ reg-shift = <2>;
+ interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&bpmp TEGRA194_CLK_UARTF>;
+ clock-names = "serial";
+ resets = <&bpmp TEGRA194_RESET_UARTF>;
+ reset-names = "serial";
+ status = "disabled";
+ };
+
+ gen1_i2c: i2c at 3160000 {
+ compatible = "nvidia,tegra194-i2c", "nvidia,tegra114-i2c";
+ reg = <0x0 0x03160000 0x0 0x10000>;
+ interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&bpmp TEGRA194_CLK_I2C1>;
+ clock-names = "div-clk";
+ resets = <&bpmp TEGRA194_RESET_I2C1>;
+ reset-names = "i2c";
+ status = "disabled";
+ };
+
+ uarth: serial at 3170000 {
+ compatible = "nvidia,tegra194-uart", "nvidia,tegra20-uart";
+ reg = <0x0 0x03170000 0x0 0x40>;
+ reg-shift = <2>;
+ interrupts = <GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&bpmp TEGRA194_CLK_UARTH>;
+ clock-names = "serial";
+ resets = <&bpmp TEGRA194_RESET_UARTH>;
+ reset-names = "serial";
+ status = "disabled";
+ };
+
+ cam_i2c: i2c at 3180000 {
+ compatible = "nvidia,tegra194-i2c", "nvidia,tegra114-i2c";
+ reg = <0x0 0x03180000 0x0 0x10000>;
+ interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&bpmp TEGRA194_CLK_I2C3>;
+ clock-names = "div-clk";
+ resets = <&bpmp TEGRA194_RESET_I2C3>;
+ reset-names = "i2c";
+ status = "disabled";
+ };
+
+ /* shares pads with dpaux1 */
+ dp_aux_ch1_i2c: i2c at 3190000 {
+ compatible = "nvidia,tegra194-i2c", "nvidia,tegra114-i2c";
+ reg = <0x0 0x03190000 0x0 0x10000>;
+ interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&bpmp TEGRA194_CLK_I2C4>;
+ clock-names = "div-clk";
+ resets = <&bpmp TEGRA194_RESET_I2C4>;
+ reset-names = "i2c";
+ status = "disabled";
+ };
+
+ /* shares pads with dpaux0 */
+ dp_aux_ch0_i2c: i2c at 31b0000 {
+ compatible = "nvidia,tegra194-i2c", "nvidia,tegra114-i2c";
+ reg = <0x0 0x031b0000 0x0 0x10000>;
+ interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&bpmp TEGRA194_CLK_I2C6>;
+ clock-names = "div-clk";
+ resets = <&bpmp TEGRA194_RESET_I2C6>;
+ reset-names = "i2c";
+ status = "disabled";
+ };
+
+ gen7_i2c: i2c at 31c0000 {
+ compatible = "nvidia,tegra194-i2c", "nvidia,tegra114-i2c";
+ reg = <0x0 0x031c0000 0x0 0x10000>;
+ interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&bpmp TEGRA194_CLK_I2C7>;
+ clock-names = "div-clk";
+ resets = <&bpmp TEGRA194_RESET_I2C7>;
+ reset-names = "i2c";
+ status = "disabled";
+ };
+
+ gen9_i2c: i2c at 31e0000 {
+ compatible = "nvidia,tegra194-i2c", "nvidia,tegra114-i2c";
+ reg = <0x0 0x031e0000 0x0 0x10000>;
+ interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&bpmp TEGRA194_CLK_I2C9>;
+ clock-names = "div-clk";
+ resets = <&bpmp TEGRA194_RESET_I2C9>;
+ reset-names = "i2c";
+ status = "disabled";
+ };
+
+ sdmmc1: sdhci at 3400000 {
+ compatible = "nvidia,tegra194-sdhci", "nvidia,tegra186-sdhci";
+ reg = <0x0 0x03400000 0x0 0x10000>;
+ interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&bpmp TEGRA194_CLK_SDMMC1>;
+ clock-names = "sdhci";
+ resets = <&bpmp TEGRA194_RESET_SDMMC1>;
+ reset-names = "sdhci";
+ status = "disabled";
+ };
+
+ sdmmc3: sdhci at 3440000 {
+ compatible = "nvidia,tegra194-sdhci", "nvidia,tegra186-sdhci";
+ reg = <0x0 0x03440000 0x0 0x10000>;
+ interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&bpmp TEGRA194_CLK_SDMMC3>;
+ clock-names = "sdhci";
+ resets = <&bpmp TEGRA194_RESET_SDMMC3>;
+ reset-names = "sdhci";
+ status = "disabled";
+ };
+
+ sdmmc4: sdhci at 3460000 {
+ compatible = "nvidia,tegra194-sdhci", "nvidia,tegra186-sdhci";
+ reg = <0x0 0x03460000 0x0 0x10000>;
+ interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&bpmp TEGRA194_CLK_SDMMC4>;
+ clock-names = "sdhci";
+ resets = <&bpmp TEGRA194_RESET_SDMMC4>;
+ reset-names = "sdhci";
+ status = "disabled";
+ };
+
+ gic: interrupt-controller at 3881000 {
+ compatible = "arm,gic-400";
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ reg = <0x0 0x03881000 0x0 0x1000>,
+ <0x0 0x03882000 0x0 0x2000>;
+ interrupts = <GIC_PPI 9
+ (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+ interrupt-parent = <&gic>;
+ };
+
+ hsp_top0: hsp at 3c00000 {
+ compatible = "nvidia,tegra186-hsp";
+ reg = <0x0 0x03c00000 0x0 0xa0000>;
+ interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "doorbell";
+ #mbox-cells = <2>;
+ };
+
+ gen2_i2c: i2c at c240000 {
+ compatible = "nvidia,tegra194-i2c", "nvidia,tegra114-i2c";
+ reg = <0x0 0x0c240000 0x0 0x10000>;
+ interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&bpmp TEGRA194_CLK_I2C2>;
+ clock-names = "div-clk";
+ resets = <&bpmp TEGRA194_RESET_I2C2>;
+ reset-names = "i2c";
+ status = "disabled";
+ };
+
+ gen8_i2c: i2c at c250000 {
+ compatible = "nvidia,tegra194-i2c", "nvidia,tegra114-i2c";
+ reg = <0x0 0x0c250000 0x0 0x10000>;
+ interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&bpmp TEGRA194_CLK_I2C8>;
+ clock-names = "div-clk";
+ resets = <&bpmp TEGRA194_RESET_I2C8>;
+ reset-names = "i2c";
+ status = "disabled";
+ };
+
+ uartc: serial at c280000 {
+ compatible = "nvidia,tegra194-uart", "nvidia,tegra20-uart";
+ reg = <0x0 0x0c280000 0x0 0x40>;
+ reg-shift = <2>;
+ interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&bpmp TEGRA194_CLK_UARTC>;
+ clock-names = "serial";
+ resets = <&bpmp TEGRA194_RESET_UARTC>;
+ reset-names = "serial";
+ status = "disabled";
+ };
+
+ uartg: serial at c290000 {
+ compatible = "nvidia,tegra194-uart", "nvidia,tegra20-uart";
+ reg = <0x0 0x0c290000 0x0 0x40>;
+ reg-shift = <2>;
+ interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&bpmp TEGRA194_CLK_UARTG>;
+ clock-names = "serial";
+ resets = <&bpmp TEGRA194_RESET_UARTG>;
+ reset-names = "serial";
+ status = "disabled";
+ };
+
+ pmc at c360000 {
+ compatible = "nvidia,tegra194-pmc";
+ reg = <0 0x0c360000 0 0x10000>,
+ <0 0x0c370000 0 0x10000>,
+ <0 0x0c380000 0 0x10000>,
+ <0 0x0c390000 0 0x10000>,
+ <0 0x0c3a0000 0 0x10000>;
+ reg-names = "pmc", "wake", "aotag", "scratch", "misc";
+ };
+
+ sysram at 40000000 {
+ compatible = "nvidia,tegra194-sysram", "mmio-sram";
+ reg = <0x0 0x40000000 0x0 0x50000>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0 0x0 0x0 0x40000000 0x0 0x50000>;
+
+ cpu_bpmp_tx: shmem at 4e000 {
+ compatible = "nvidia,tegra194-bpmp-shmem";
+ reg = <0x0 0x4e000 0x0 0x1000>;
+ label = "cpu-bpmp-tx";
+ pool;
+ };
+
+ cpu_bpmp_rx: shmem at 4f000 {
+ compatible = "nvidia,tegra194-bpmp-shmem";
+ reg = <0x0 0x4f000 0x0 0x1000>;
+ label = "cpu-bpmp-rx";
+ pool;
+ };
+ };
+
+ bpmp: bpmp {
+ compatible = "nvidia,tegra186-bpmp";
+ mboxes = <&hsp_top0 TEGRA_HSP_MBOX_TYPE_DB
+ TEGRA_HSP_DB_MASTER_BPMP>;
+ shmem = <&cpu_bpmp_tx &cpu_bpmp_rx>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+
+ bpmp_i2c: i2c {
+ compatible = "nvidia,tegra186-bpmp-i2c";
+ nvidia,bpmp-bus-id = <5>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ bpmp_thermal: thermal {
+ compatible = "nvidia,tegra186-bpmp-thermal";
+ #thermal-sensor-cells = <1>;
+ };
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = <GIC_PPI 13
+ (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14
+ (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11
+ (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10
+ (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+ interrupt-parent = <&gic>;
+ };
+};
diff --git a/include/dt-bindings/clock/tegra194-clock.h b/include/dt-bindings/clock/tegra194-clock.h
new file mode 100644
index 000000000000..7eba4763e375
--- /dev/null
+++ b/include/dt-bindings/clock/tegra194-clock.h
@@ -0,0 +1,59 @@
+/*
+ * Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __ABI_MACH_T194_CLOCK_H
+#define __ABI_MACH_T194_CLOCK_H
+
+/** @clkdesc{i2c_clks, out, mux, CLK_RST_CONTROLLER_CLK_SOURCE_I2C1} */
+#define TEGRA194_CLK_I2C1 48
+/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_I2C2 */
+#define TEGRA194_CLK_I2C2 49
+/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_I2C3 */
+#define TEGRA194_CLK_I2C3 50
+/** output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_I2C4 */
+#define TEGRA194_CLK_I2C4 51
+/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_I2C6 */
+#define TEGRA194_CLK_I2C6 52
+/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_I2C7 */
+#define TEGRA194_CLK_I2C7 53
+/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_I2C8 */
+#define TEGRA194_CLK_I2C8 54
+/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_I2C9 */
+#define TEGRA194_CLK_I2C9 55
+/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_SDMMC1 */
+#define TEGRA194_CLK_SDMMC1 120
+/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_SDMMC3 */
+#define TEGRA194_CLK_SDMMC3 122
+/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_SDMMC4 */
+#define TEGRA194_CLK_SDMMC4 123
+/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_UARTA */
+#define TEGRA194_CLK_UARTA 155
+/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_UARTB */
+#define TEGRA194_CLK_UARTB 156
+/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_UARTC */
+#define TEGRA194_CLK_UARTC 157
+/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_UARTD */
+#define TEGRA194_CLK_UARTD 158
+/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_UARTE */
+#define TEGRA194_CLK_UARTE 159
+/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_UARTF */
+#define TEGRA194_CLK_UARTF 160
+/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_UARTG */
+#define TEGRA194_CLK_UARTG 161
+/** @brief CLK_RST_CONTROLLER_CLK_SOURCE_UARTH switch divider output */
+#define TEGRA194_CLK_UARTH 190
+
+#endif
diff --git a/include/dt-bindings/gpio/tegra194-gpio.h b/include/dt-bindings/gpio/tegra194-gpio.h
new file mode 100644
index 000000000000..86435a73ef9e
--- /dev/null
+++ b/include/dt-bindings/gpio/tegra194-gpio.h
@@ -0,0 +1,59 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * This header provides constants for binding nvidia,tegra194-gpio*.
+ *
+ * The first cell in Tegra's GPIO specifier is the GPIO ID. The macros below
+ * provide names for this.
+ *
+ * The second cell contains standard flag values specified in gpio.h.
+ */
+
+#ifndef _DT_BINDINGS_GPIO_TEGRA194_GPIO_H
+#define _DT_BINDINGS_GPIO_TEGRA194_GPIO_H
+
+#include <dt-bindings/gpio/gpio.h>
+
+/* GPIOs implemented by main GPIO controller */
+#define TEGRA194_MAIN_GPIO_PORT_A 0
+#define TEGRA194_MAIN_GPIO_PORT_B 1
+#define TEGRA194_MAIN_GPIO_PORT_C 2
+#define TEGRA194_MAIN_GPIO_PORT_D 3
+#define TEGRA194_MAIN_GPIO_PORT_E 4
+#define TEGRA194_MAIN_GPIO_PORT_F 5
+#define TEGRA194_MAIN_GPIO_PORT_G 6
+#define TEGRA194_MAIN_GPIO_PORT_H 7
+#define TEGRA194_MAIN_GPIO_PORT_I 8
+#define TEGRA194_MAIN_GPIO_PORT_J 9
+#define TEGRA194_MAIN_GPIO_PORT_K 10
+#define TEGRA194_MAIN_GPIO_PORT_L 11
+#define TEGRA194_MAIN_GPIO_PORT_M 12
+#define TEGRA194_MAIN_GPIO_PORT_N 13
+#define TEGRA194_MAIN_GPIO_PORT_O 14
+#define TEGRA194_MAIN_GPIO_PORT_P 15
+#define TEGRA194_MAIN_GPIO_PORT_Q 16
+#define TEGRA194_MAIN_GPIO_PORT_R 17
+#define TEGRA194_MAIN_GPIO_PORT_S 18
+#define TEGRA194_MAIN_GPIO_PORT_T 19
+#define TEGRA194_MAIN_GPIO_PORT_U 20
+#define TEGRA194_MAIN_GPIO_PORT_V 21
+#define TEGRA194_MAIN_GPIO_PORT_W 22
+#define TEGRA194_MAIN_GPIO_PORT_X 23
+#define TEGRA194_MAIN_GPIO_PORT_Y 24
+#define TEGRA194_MAIN_GPIO_PORT_Z 25
+#define TEGRA194_MAIN_GPIO_PORT_FF 26
+#define TEGRA194_MAIN_GPIO_PORT_GG 27
+
+#define TEGRA194_MAIN_GPIO(port, offset) \
+ ((TEGRA194_MAIN_GPIO_PORT_##port * 8) + offset)
+
+/* GPIOs implemented by AON GPIO controller */
+#define TEGRA194_AON_GPIO_PORT_AA 0
+#define TEGRA194_AON_GPIO_PORT_BB 1
+#define TEGRA194_AON_GPIO_PORT_CC 2
+#define TEGRA194_AON_GPIO_PORT_DD 3
+#define TEGRA194_AON_GPIO_PORT_EE 4
+
+#define TEGRA194_AON_GPIO(port, offset) \
+ ((TEGRA194_AON_GPIO_PORT_##port * 8) + offset)
+
+#endif
diff --git a/include/dt-bindings/reset/tegra194-reset.h b/include/dt-bindings/reset/tegra194-reset.h
new file mode 100644
index 000000000000..7c6afac99c4a
--- /dev/null
+++ b/include/dt-bindings/reset/tegra194-reset.h
@@ -0,0 +1,40 @@
+/*
+ * Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __ABI_MACH_T194_RESET_H
+#define __ABI_MACH_T194_RESET_H
+
+#define TEGRA194_RESET_I2C1 24
+#define TEGRA194_RESET_I2C2 29
+#define TEGRA194_RESET_I2C3 30
+#define TEGRA194_RESET_I2C4 31
+#define TEGRA194_RESET_I2C6 32
+#define TEGRA194_RESET_I2C7 33
+#define TEGRA194_RESET_I2C8 34
+#define TEGRA194_RESET_I2C9 35
+#define TEGRA194_RESET_SDMMC1 82
+#define TEGRA194_RESET_SDMMC3 84
+#define TEGRA194_RESET_SDMMC4 85
+#define TEGRA194_RESET_UARTA 100
+#define TEGRA194_RESET_UARTB 101
+#define TEGRA194_RESET_UARTC 102
+#define TEGRA194_RESET_UARTD 103
+#define TEGRA194_RESET_UARTE 104
+#define TEGRA194_RESET_UARTF 105
+#define TEGRA194_RESET_UARTG 106
+#define TEGRA194_RESET_UARTH 107
+
+#endif
--
2.1.4
^ permalink raw reply related
* [PATCH 6/6] arm64: tegra: Add device tree for the Tegra194 P2972-0000 board
From: Mikko Perttunen @ 2018-01-08 4:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515387278-29777-1-git-send-email-mperttunen@nvidia.com>
Add device tree files for the Tegra194 P2972-0000 development board.
The board consists of the P2888 compute module and the P2822 baseboard.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
arch/arm64/boot/dts/nvidia/Makefile | 1 +
arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 246 +++++++++++++++++++++
arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts | 14 ++
3 files changed, 261 insertions(+)
create mode 100644 arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
create mode 100644 arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
diff --git a/arch/arm64/boot/dts/nvidia/Makefile b/arch/arm64/boot/dts/nvidia/Makefile
index 676aa2f238d1..7c13d7df484e 100644
--- a/arch/arm64/boot/dts/nvidia/Makefile
+++ b/arch/arm64/boot/dts/nvidia/Makefile
@@ -5,3 +5,4 @@ dtb-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210-p2371-2180.dtb
dtb-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210-p2571.dtb
dtb-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210-smaug.dtb
dtb-$(CONFIG_ARCH_TEGRA_186_SOC) += tegra186-p2771-0000.dtb
+dtb-$(CONFIG_ARCH_TEGRA_194_SOC) += tegra194-p2972-0000.dtb
diff --git a/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi b/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
new file mode 100644
index 000000000000..5b337f883d2c
--- /dev/null
+++ b/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
@@ -0,0 +1,246 @@
+// SPDX-License-Identifier: GPL-2.0
+#include "tegra194.dtsi"
+
+#include <dt-bindings/mfd/max77620.h>
+
+/ {
+ model = "NVIDIA Tegra194 P2888 Processor Module";
+ compatible = "nvidia,p2888", "nvidia,tegra194";
+
+ aliases {
+ sdhci0 = "/sdhci at 3460000";
+ sdhci1 = "/sdhci at 3400000";
+ serial0 = &uartc;
+ i2c0 = "/bpmp/i2c";
+ i2c1 = "/i2c at 3160000";
+ i2c2 = "/i2c at c240000";
+ i2c3 = "/i2c at 3180000";
+ i2c4 = "/i2c at 3190000";
+ i2c5 = "/i2c at 31c0000";
+ i2c6 = "/i2c at c250000";
+ i2c7 = "/i2c at 31e0000";
+ };
+
+ chosen {
+ bootargs = "earlycon console=ttyS0,115200n8";
+ stdout-path = "serial0:115200n8";
+ };
+
+ serial at c280000 {
+ status = "okay";
+ };
+
+ /* SDMMC1 (SD/MMC) */
+ sdhci at 3400000 {
+/*
+ cd-gpios = <&gpio TEGRA194_MAIN_GPIO(A, 0) GPIO_ACTIVE_LOW>;
+*/
+ };
+
+ /* SDMMC4 (eMMC) */
+ sdhci at 3460000 {
+ status = "okay";
+ bus-width = <8>;
+ non-removable;
+
+ vqmmc-supply = <&vdd_1v8ls>;
+ vmmc-supply = <&vdd_emmc_3v3>;
+ };
+
+ pmc at c360000 {
+ nvidia,invert-interrupt;
+ };
+
+ bpmp {
+ i2c {
+ status = "okay";
+
+ pmic: pmic at 3c {
+ compatible = "maxim,max20024";
+ reg = <0x3c>;
+
+ interrupts = <GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+
+ #gpio-cells = <2>;
+ gpio-controller;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&max20024_default>;
+
+ max20024_default: pinmux {
+ gpio0 {
+ pins = "gpio0";
+ function = "gpio";
+ };
+
+ gpio1 {
+ pins = "gpio1";
+ function = "fps-out";
+ maxim,active-fps-source = <MAX77620_FPS_SRC_DEF>;
+ };
+
+ gpio2 {
+ pins = "gpio2";
+ function = "fps-out";
+ maxim,active-fps-source = <MAX77620_FPS_SRC_DEF>;
+ };
+
+ gpio3 {
+ pins = "gpio3";
+ function = "fps-out";
+ maxim,active-fps-source = <MAX77620_FPS_SRC_DEF>;
+ };
+
+ gpio4 {
+ pins = "gpio4";
+ function = "32k-out1";
+ drive-push-pull = <1>;
+ };
+
+ gpio6 {
+ pins = "gpio6";
+ function = "gpio";
+ drive-push-pull = <1>;
+ };
+
+ gpio7 {
+ pins = "gpio7";
+ function = "gpio";
+ drive-push-pull = <0>;
+ };
+ };
+
+ fps {
+ fps0 {
+ maxim,fps-event-source = <MAX77620_FPS_EVENT_SRC_EN0>;
+ maxim,shutdown-fps-time-period-us = <640>;
+ };
+
+ fps1 {
+ maxim,fps-event-source = <MAX77620_FPS_EVENT_SRC_EN1>;
+ maxim,shutdown-fps-time-period-us = <640>;
+ maxim,device-state-on-disabled-event = <MAX77620_FPS_INACTIVE_STATE_SLEEP>;
+ };
+
+ fps2 {
+ maxim,fps-event-source = <MAX77620_FPS_EVENT_SRC_EN0>;
+ maxim,shutdown-fps-time-period-us = <640>;
+ };
+ };
+
+ regulators {
+ in-sd0-supply = <&vdd_5v0_sys>;
+ in-sd1-supply = <&vdd_5v0_sys>;
+ in-sd2-supply = <&vdd_5v0_sys>;
+ in-sd3-supply = <&vdd_5v0_sys>;
+ in-sd4-supply = <&vdd_5v0_sys>;
+
+ in-ldo0-1-supply = <&vdd_5v0_sys>;
+ in-ldo2-supply = <&vdd_5v0_sys>;
+ in-ldo3-5-supply = <&vdd_5v0_sys>;
+ in-ldo4-6-supply = <&vdd_5v0_sys>;
+ in-ldo7-8-supply = <&vdd_1v8ls>;
+
+ sd0 {
+ regulator-name = "VDD_1V0";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ sd1 {
+ regulator-name = "VDD_1V8HS";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vdd_1v8ls: sd2 {
+ regulator-name = "VDD_1V8LS";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ sd3 {
+ regulator-name = "VDD_1V8AO";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ sd4 {
+ regulator-name = "VDD_DDR_1V1";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo0 {
+ regulator-name = "VDD_RTC";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo2 {
+ regulator-name = "VDD_AO_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vdd_emmc_3v3: ldo3 {
+ regulator-name = "VDD_EMMC_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ ldo5 {
+ regulator-name = "VDD_USB_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ ldo6 {
+ regulator-name = "VDD_SDIO_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ ldo7 {
+ regulator-name = "VDD_CSI_1V2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+ };
+ };
+ };
+ };
+
+ regulators {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vdd_5v0_sys: regulator at 0 {
+ compatible = "regulator-fixed";
+ reg = <0>;
+
+ regulator-name = "VIN_SYS_5V0";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts b/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
new file mode 100644
index 000000000000..9f0b463ee5f7
--- /dev/null
+++ b/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+#include "tegra194-p2888.dtsi"
+
+/ {
+ model = "NVIDIA Tegra194 P2972-0000 Development Board";
+ compatible = "nvidia,p2972-0000", "nvidia,tegra194";
+
+ /* SDMMC1 (SD/MMC) */
+ sdhci at 3400000 {
+ status = "okay";
+ };
+};
--
2.1.4
^ permalink raw reply related
* [PATCH v4 6/7] ARM: davinci: convert to common clock framework
From: Sekhar Nori @ 2018-01-08 5:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7143f0fb-9bb2-dc66-56d4-aefa66f852a1@lechnology.com>
On Saturday 06 January 2018 07:12 AM, David Lechner wrote:
> On 01/05/2018 04:42 AM, Sekhar Nori wrote:
>> On Friday 05 January 2018 08:29 AM, David Lechner wrote:
>>> On 01/04/2018 11:50 AM, David Lechner wrote:
>>>> On 1/4/18 6:39 AM, Sekhar Nori wrote:
>>
>>>>> This is a pretty huge patch again and I hope it can be broken down.
>>>>> Ideally one per SoC converted and then the unused code removal.
>>>>>
>>>>
>>>> Will do.
>>>
>>> Well, I can do this, but I don't think it will compile or run. We can't
>>> have the common clock framework and the legacy davinci clocks enabled at
>>> the same time.
>>
>> I see. Can you at least hive off the code removal into a separate patch
>> for next submission. I will then take a closer look at this.
>>
>
> I've realized that I can accomplish this if I use some #if 0/#endif blocks
> temporarily if that sounds OK.
I haven't looked at your latest submission, but this wont be acceptable.
Even as a temporary measure.
If the patch cannot be broken down any, thats fine. I just wanted to
explore the possibility to ease review.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2 3/5] ARM64: dts: meson-axg: uart: Add the pinctrl info description
From: Yixun Lan @ 2018-01-08 6:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFBinCCuQ-NK747+GHDkhZty_UMMgzCYOYFcNTrRDJgU8OM=Gw@mail.gmail.com>
Hi Martin
On 01/08/18 04:19, Martin Blumenstingl wrote:
> Hi Yixun,
>
> On Sat, Jan 6, 2018 at 1:10 AM, Yixun Lan <yixun.lan@amlogic.com> wrote:
>> Describe the pinctrl info for the UART controller which is found
>> in the Meson-AXG SoCs.
>>
>> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
>> ---
>> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 97 ++++++++++++++++++++++++++++++
>> 1 file changed, 97 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> index 644d0f9eaf8c..1eb45781c850 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> @@ -448,6 +448,70 @@
>> function = "spi1";
>> };
>> };
>> +
>> + uart_a_pins: uart_a {
>> + mux {
>> + groups = "uart_tx_a",
>> + "uart_rx_a";
>> + function = "uart_a";
>> + };
>> + };
>> +
>> + uart_a_cts_rts_pins: uart_a_cts_rts {
>> + mux {
>> + groups = "uart_cts_a",
>> + "uart_rts_a";
>> + function = "uart_a";
>> + };
>> + };
>> +
>> + uart_b_x_pins: uart_b_x {
>> + mux {
>> + groups = "uart_tx_b_x",
>> + "uart_rx_b_x";
>> + function = "uart_b";
>> + };
>> + };
>> +
>> + uart_b_x_cts_rts_pins: uart_b_x_cts_rts {
>> + mux {
>> + groups = "uart_cts_b_x",
>> + "uart_rts_b_x";
>> + function = "uart_b";
>> + };
>> + };
>> +
>> + uart_b_z_pins: uart_b_z {
>> + mux {
>> + groups = "uart_tx_b_z",
>> + "uart_rx_b_z";
>> + function = "uart_b";
>> + };
>> + };
>> +
>> + uart_b_z_cts_rts_pins: uart_b_z_cts_rts {
>> + mux {
>> + groups = "uart_cts_b_z",
>> + "uart_rts_b_z";
>> + function = "uart_b";
>> + };
>> + };
>> +
>> + uart_ao_b_z_pins: uart_ao_b_z {
>> + mux {
>> + groups = "uart_ao_tx_b_z",
>> + "uart_ao_rx_b_z";
>> + function = "uart_ao_b_gpioz";
> (the following question just came up while I was looking at this
> patch, but I guess it's more a question towards the pinctrl driver)
> the name of the function looks a bit "weird" since below you are also
> using "uart_ao_b"
you right here, it's a question related to pinctrl subsystem.
from my point of view, it's even weird from the hardware perspective:
that, the UART function of AO domain route the pin of EE domain..
> did you choose "uart_ao_b_gpioz" here because we cannot have the same
> function name for the periphs and AO pinctrl or is there some other
> reason?
>
Current there is a conflict in the code level which both two pinctrl
tree (EE, AO) are using the same macro[1] to expand the definitions, so
there would be conflict symbol if we name both as 'uart_ao_b'
I think your idea of having an uniform function 'uart_ao_b' for both
pinctrl subsystem is actually possible/positive..
I will think about your suggestion and come up with a patch later,
thanks a lot!
[1] drivers/pinctrl/meson/pinctrl-meson.h
#define FUNCTION(fn) \
{ \
.name = #fn, \
.groups = fn ## _groups, \
.num_groups = ARRAY_SIZE(fn ## _groups), \
}
> I am asking because I would have expected it to look like this:
> groups = "uart_ao_tx_b_z", "uart_ao_rx_b_z";
> function = "uart_ao_b";
>
> (same for the cts/rts pins below)
>
>> + };
>> + };
>> +
>> + uart_ao_b_z_cts_rts_pins: uart_ao_b_z_cts_rts {
>> + mux {
>> + groups = "uart_ao_cts_b_z",
>> + "uart_ao_rts_b_z";
>> + function = "uart_ao_b_gpioz";
>> + };
>> + };
>> };
>> };
>>
>> @@ -492,12 +556,45 @@
>> gpio-ranges = <&pinctrl_aobus 0 0 15>;
>> };
>>
>> +
> did you add this additional newline on purpose?
>> remote_input_ao_pins: remote_input_ao {
>> mux {
>> groups = "remote_input_ao";
>> function = "remote_input_ao";
>> };
>> };
>> +
>> + uart_ao_a_pins: uart_ao_a {
>> + mux {
>> + groups = "uart_ao_tx_a",
>> + "uart_ao_rx_a";
>> + function = "uart_ao_a";
>> + };
>> + };
>> +
>> + uart_ao_a_cts_rts_pins: uart_ao_a_cts_rts {
>> + mux {
>> + groups = "uart_ao_cts_a",
>> + "uart_ao_rts_a";
>> + function = "uart_ao_a";
>> + };
>> + };
>> +
>> + uart_ao_b_pins: uart_ao_b {
>> + mux {
>> + groups = "uart_ao_tx_b",
>> + "uart_ao_rx_b";
>> + function = "uart_ao_b";
>> + };
>> + };
>> +
>> + uart_ao_b_cts_rts_pins: uart_ao_b_cts_rts {
>> + mux {
>> + groups = "uart_ao_cts_b",
>> + "uart_ao_rts_b";
>> + function = "uart_ao_b";
>> + };
>> + };
>> };
>>
>> pwm_AO_ab: pwm at 7000 {
>> --
>> 2.15.1
>>
>>
>> _______________________________________________
>> linux-amlogic mailing list
>> linux-amlogic at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-amlogic
>
> Regards
> Martin
>
> .
>
^ permalink raw reply
* soc: imx: gpcv2: removing and probing fails
From: Andrey Smirnov @ 2018-01-08 6:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHQ1cqHvkk01NDTB14PpG4tgpsbPg=75K9wqHUCBjWkyNuFy=A@mail.gmail.com>
On Sun, Jan 7, 2018 at 4:22 PM, Andrey Smirnov <andrew.smirnov@gmail.com> wrote:
> On Sun, Jan 7, 2018 at 2:48 AM, Stefan Agner <stefan@agner.ch> wrote:
>> Hi Andrew,
>>
>> I noticed that the driver fails when removing and probing again. As far
>> as I can see due to duplicate add of the platform devices.
>>
>> As far as I can tell the driver should register the remove callback and
>> do a platform_device_unregister on the newly created platform devices.
>> However, as far as I can tell we don't hold on to a reference to them...
>> I guess we could keep references in imx_gpcv2_probe, but maybe there is
>> an easier way?
>
> Stefan:
>
> Good catch and sorry for the inconvenience. I just spent a little bit
> of time repro-ing this and it looks like there are two separate bugs,
> actually. First one, as you correctly pointed out, is due to
> re-registration of pm-domain platform drivers. That, however, should
> only result in a WARNING and a failed driver probing, not in a killed
> init due to BUG. So the second one, that BUG message in the stack
> trace, is due to the fact that I incorrectly provide statically
> allocated data via dev.platform_data and it ends up being kfree'd in
> platform_device_release().
>
> IMHO, this driver isn't really meant to be removed, so the simplest
> solution to the first problem would be to specify
> "imx_gpc_driver.driver.suppress_bind_attrs = true" and remove any
> option to remove the driver, but I don't know if that's acceptable or
> not.
>
> Shawn, would the above be acceptable upstream?
>
> Solution for bug #2 is trivial and I'll send patches for both once we
> agree how to fix #1.
>
> Thanks,
> Andrey Smirnov
>
> P.S: Also, since I based my code on gpc.c, I suspect that driver will
> have exactly the same problem (I'll do some experiments to confirm)
Done with experiments. Same problem happens with gpc.c as well.
Andrey Smirnov
^ permalink raw reply
* [v2, 11/11] arm64: Implement branch predictor hardening for affected Cortex-A CPUs
From: Jayachandran C @ 2018-01-08 6:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515157961-20963-12-git-send-email-will.deacon@arm.com>
On Fri, Jan 05, 2018 at 01:12:41PM +0000, Will Deacon wrote:
> Cortex-A57, A72, A73 and A75 are susceptible to branch predictor aliasing
> and can theoretically be attacked by malicious code.
>
> This patch implements a PSCI-based mitigation for these CPUs when available.
> The call into firmware will invalidate the branch predictor state, preventing
> any malicious entries from affecting other victim contexts.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm64/kernel/bpi.S | 24 ++++++++++++++++++++++++
> arch/arm64/kernel/cpu_errata.c | 42 ++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 66 insertions(+)
>
> diff --git a/arch/arm64/kernel/bpi.S b/arch/arm64/kernel/bpi.S
> index 06a931eb2673..2e9146534174 100644
> --- a/arch/arm64/kernel/bpi.S
> +++ b/arch/arm64/kernel/bpi.S
> @@ -53,3 +53,27 @@ ENTRY(__bp_harden_hyp_vecs_start)
> vectors __kvm_hyp_vector
> .endr
> ENTRY(__bp_harden_hyp_vecs_end)
> +ENTRY(__psci_hyp_bp_inval_start)
> + sub sp, sp, #(8 * 18)
> + stp x16, x17, [sp, #(16 * 0)]
> + stp x14, x15, [sp, #(16 * 1)]
> + stp x12, x13, [sp, #(16 * 2)]
> + stp x10, x11, [sp, #(16 * 3)]
> + stp x8, x9, [sp, #(16 * 4)]
> + stp x6, x7, [sp, #(16 * 5)]
> + stp x4, x5, [sp, #(16 * 6)]
> + stp x2, x3, [sp, #(16 * 7)]
> + stp x0, x1, [sp, #(18 * 8)]
> + mov x0, #0x84000000
> + smc #0
> + ldp x16, x17, [sp, #(16 * 0)]
> + ldp x14, x15, [sp, #(16 * 1)]
> + ldp x12, x13, [sp, #(16 * 2)]
> + ldp x10, x11, [sp, #(16 * 3)]
> + ldp x8, x9, [sp, #(16 * 4)]
> + ldp x6, x7, [sp, #(16 * 5)]
> + ldp x4, x5, [sp, #(16 * 6)]
> + ldp x2, x3, [sp, #(16 * 7)]
> + ldp x0, x1, [sp, #(18 * 8)]
> + add sp, sp, #(8 * 18)
> +ENTRY(__psci_hyp_bp_inval_end)
> diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
> index 16ea5c6f314e..cb0fb3796bb8 100644
> --- a/arch/arm64/kernel/cpu_errata.c
> +++ b/arch/arm64/kernel/cpu_errata.c
> @@ -53,6 +53,8 @@ static int cpu_enable_trap_ctr_access(void *__unused)
> DEFINE_PER_CPU_READ_MOSTLY(struct bp_hardening_data, bp_hardening_data);
>
> #ifdef CONFIG_KVM
> +extern char __psci_hyp_bp_inval_start[], __psci_hyp_bp_inval_end[];
> +
> static void __copy_hyp_vect_bpi(int slot, const char *hyp_vecs_start,
> const char *hyp_vecs_end)
> {
> @@ -94,6 +96,9 @@ static void __install_bp_hardening_cb(bp_hardening_cb_t fn,
> spin_unlock(&bp_lock);
> }
> #else
> +#define __psci_hyp_bp_inval_start NULL
> +#define __psci_hyp_bp_inval_end NULL
> +
> static void __install_bp_hardening_cb(bp_hardening_cb_t fn,
> const char *hyp_vecs_start,
> const char *hyp_vecs_end)
> @@ -118,6 +123,21 @@ static void install_bp_hardening_cb(const struct arm64_cpu_capabilities *entry,
>
> __install_bp_hardening_cb(fn, hyp_vecs_start, hyp_vecs_end);
> }
> +
> +#include <linux/psci.h>
> +
> +static int enable_psci_bp_hardening(void *data)
> +{
> + const struct arm64_cpu_capabilities *entry = data;
> +
> + if (psci_ops.get_version)
> + install_bp_hardening_cb(entry,
> + (bp_hardening_cb_t)psci_ops.get_version,
> + __psci_hyp_bp_inval_start,
> + __psci_hyp_bp_inval_end);
> +
> + return 0;
> +}
> #endif /* CONFIG_HARDEN_BRANCH_PREDICTOR */
>
> #define MIDR_RANGE(model, min, max) \
> @@ -261,6 +281,28 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
> MIDR_ALL_VERSIONS(MIDR_CORTEX_A73),
> },
> #endif
> +#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
> + {
> + .capability = ARM64_HARDEN_BRANCH_PREDICTOR,
> + MIDR_ALL_VERSIONS(MIDR_CORTEX_A57),
> + .enable = enable_psci_bp_hardening,
> + },
> + {
> + .capability = ARM64_HARDEN_BRANCH_PREDICTOR,
> + MIDR_ALL_VERSIONS(MIDR_CORTEX_A72),
> + .enable = enable_psci_bp_hardening,
> + },
> + {
> + .capability = ARM64_HARDEN_BRANCH_PREDICTOR,
> + MIDR_ALL_VERSIONS(MIDR_CORTEX_A73),
> + .enable = enable_psci_bp_hardening,
> + },
> + {
> + .capability = ARM64_HARDEN_BRANCH_PREDICTOR,
> + MIDR_ALL_VERSIONS(MIDR_CORTEX_A75),
> + .enable = enable_psci_bp_hardening,
> + },
> +#endif
> {
> }
> };
On ThunderX2, we would like to do something similar, but it is important to
find out if the current firmware has support for BTB invalidate in the
PSCI version call. Otherwise, we will end up doing version calls that do
nothing but return version (and waste cycles).
I will follow up with ThunderX2 patches, but it would be good to have a
standard way of figuring out if the firmware has BTB invalidate support.
JC.
^ permalink raw reply
* [PATCH v2 3/5] ARM64: dts: meson-axg: uart: Add the pinctrl info description
From: Yixun Lan @ 2018-01-08 6:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b2571e30-d543-9288-68cf-1af86bb5f4bc@amlogic.com>
HI Martin:
On 01/08/18 14:07, Yixun Lan wrote:
> Hi Martin
>
> On 01/08/18 04:19, Martin Blumenstingl wrote:
>> Hi Yixun,
>>
>> On Sat, Jan 6, 2018 at 1:10 AM, Yixun Lan <yixun.lan@amlogic.com> wrote:
>>> Describe the pinctrl info for the UART controller which is found
>>> in the Meson-AXG SoCs.
>>>
>>> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
>>> ---
>>> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 97 ++++++++++++++++++++++++++++++
>>> 1 file changed, 97 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>>> index 644d0f9eaf8c..1eb45781c850 100644
>>> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>>> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>>> @@ -448,6 +448,70 @@
>>> function = "spi1";
>>> };
.
>>>
>>> +
>> did you add this additional newline on purpose?
oops, this is added by mistake..
thanks for catching this, I will fix it
>>> remote_input_ao_pins: remote_input_ao {
>>> mux {
>>> groups = "remote_input_ao";
>>> function = "remote_input_ao";
>>> };
>>> };
>>> +
>>> + uart_ao_a_pins: uart_ao_a {
>>> + mux {
>>> + groups = "uart_ao_tx_a",
>>> + "uart_ao_rx_a";
>>> + function = "uart_ao_a";
>>> + };
>>> + };
>>> +
>>> + uart_ao_a_cts_rts_pins: uart_ao_a_cts_rts {
>>> + mux {
>>> + groups = "uart_ao_cts_a",
>>> + "uart_ao_rts_a";
>>> + function = "uart_ao_a";
>>> + };
>>> + };
>>> +
>>> + uart_ao_b_pins: uart_ao_b {
>>> + mux {
>>> + groups = "uart_ao_tx_b",
>>> + "uart_ao_rx_b";
>>> + function = "uart_ao_b";
>>> + };
>>> + };
>>> +
>>> + uart_ao_b_cts_rts_pins: uart_ao_b_cts_rts {
>>> + mux {
>>> + groups = "uart_ao_cts_b",
>>> + "uart_ao_rts_b";
>>> + function = "uart_ao_b";
>>> + };
>>> + };
>>> };
>>>
>>> pwm_AO_ab: pwm at 7000 {
>>> --
>>> 2.15.1
>>>
>>>
>>> _______________________________________________
>>> linux-amlogic mailing list
>>> linux-amlogic at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-amlogic
>>
>> Regards
>> Martin
>>
>> .
>>
> .
>
^ permalink raw reply
* [PATCH 1/2] arm64: cputype: Add MIDR values for Cavium ThunderX2 CPUs
From: Jayachandran C @ 2018-01-08 6:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108063115.GA163286@jc-sabre>
Add the older Broadcom ID as well as the new Cavium ID for ThunderX2
CPUs.
Signed-off-by: Jayachandran C <jnair@caviumnetworks.com>
---
arch/arm64/include/asm/cputype.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 84385b9..cce5735 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -89,6 +89,7 @@
#define CAVIUM_CPU_PART_THUNDERX 0x0A1
#define CAVIUM_CPU_PART_THUNDERX_81XX 0x0A2
#define CAVIUM_CPU_PART_THUNDERX_83XX 0x0A3
+#define CAVIUM_CPU_PART_THUNDERX2 0x0AF
#define BRCM_CPU_PART_VULCAN 0x516
@@ -102,6 +103,8 @@
#define MIDR_THUNDERX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX)
#define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_81XX)
#define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_83XX)
+#define MIDR_CAVIUM_THUNDERX2 MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX2)
+#define MIDR_BRCM_VULCAN MIDR_CPU_MODEL(ARM_CPU_IMP_BRCM, BRCM_CPU_PART_VULCAN)
#define MIDR_QCOM_FALKOR_V1 MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR_V1)
#ifndef __ASSEMBLY__
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] arm64: Branch predictor hardening for Cavium ThunderX2
From: Jayachandran C @ 2018-01-08 6:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515394416-166994-1-git-send-email-jnair@caviumnetworks.com>
Use PSCI based mitigation for speculative execution attacks targeting
the branch predictor. The approach is similar to the one used for
Cortex-A CPUs, but in case of ThunderX2 we add another SMC call to
test if the firmware supports the capability.
If the secure firmware has been updated with the mitigation code to
invalidate the branch target buffer, we use the PSCI version call to
invoke it.
Signed-off-by: Jayachandran C <jnair@caviumnetworks.com>
---
arch/arm64/kernel/cpu_errata.c | 38 ++++++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index cb0fb37..abceb5d 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -124,6 +124,7 @@ static void install_bp_hardening_cb(const struct arm64_cpu_capabilities *entry,
__install_bp_hardening_cb(fn, hyp_vecs_start, hyp_vecs_end);
}
+#include <linux/arm-smccc.h>
#include <linux/psci.h>
static int enable_psci_bp_hardening(void *data)
@@ -138,6 +139,33 @@ static int enable_psci_bp_hardening(void *data)
return 0;
}
+
+#define CAVIUM_TX2_SIP_SMC_CALL 0xC200FF00
+#define CAVIUM_TX2_BTB_HARDEN_CAP 0xB0A0
+
+static int enable_tx2_psci_bp_hardening(void *data)
+{
+ const struct arm64_cpu_capabilities *entry = data;
+ struct arm_smccc_res res;
+
+ if (!entry->matches(entry, SCOPE_LOCAL_CPU))
+ return;
+
+ arm_smccc_smc(CAVIUM_TX2_SIP_SMC_CALL, CAVIUM_TX2_BTB_HARDEN_CAP, 0, 0, 0, 0, 0, 0, &res);
+ if (res.a0 != 0) {
+ pr_warn("Error: CONFIG_HARDEN_BRANCH_PREDICTOR enabled, but firmware does not support it\n");
+ return 0;
+ }
+ if (res.a1 == 1 && psci_ops.get_version) {
+ pr_info("CPU%d: Branch predictor hardening enabled\n", smp_processor_id());
+ install_bp_hardening_cb(entry,
+ (bp_hardening_cb_t)psci_ops.get_version,
+ __psci_hyp_bp_inval_start,
+ __psci_hyp_bp_inval_end);
+ }
+
+ return 0;
+}
#endif /* CONFIG_HARDEN_BRANCH_PREDICTOR */
#define MIDR_RANGE(model, min, max) \
@@ -302,6 +330,16 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
MIDR_ALL_VERSIONS(MIDR_CORTEX_A75),
.enable = enable_psci_bp_hardening,
},
+ {
+ .capability = ARM64_HARDEN_BRANCH_PREDICTOR,
+ MIDR_ALL_VERSIONS(MIDR_BRCM_VULCAN),
+ .enable = enable_tx2_psci_bp_hardening,
+ },
+ {
+ .capability = ARM64_HARDEN_BRANCH_PREDICTOR,
+ MIDR_ALL_VERSIONS(MIDR_CAVIUM_THUNDERX2),
+ .enable = enable_tx2_psci_bp_hardening,
+ },
#endif
{
}
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/6] clocksource/drivers: atmel-pit: allow unselecting ATMEL_PIT
From: Daniel Lezcano @ 2018-01-08 7:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180107184455.GG5545@piout.net>
On 07/01/2018 19:44, Alexandre Belloni wrote:
> On 07/01/2018 at 19:07:13 +0100, Daniel Lezcano wrote:
>> On 05/01/2018 15:30, Alexandre Belloni wrote:
>>> With the new TCB clocksource driver, atmel platforms are now able to boot
>>> without the PIT driver. Allow unselecting it.
>>>
>>> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>>> ---
>>> drivers/clocksource/Kconfig | 9 ++++++++-
>>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>>> index 5609572e0236..55ccfa0ba63b 100644
>>> --- a/drivers/clocksource/Kconfig
>>> +++ b/drivers/clocksource/Kconfig
>>> @@ -381,7 +381,14 @@ config ARMV7M_SYSTICK
>>>
>>> config ATMEL_PIT
>>> select TIMER_OF if OF
>>> - def_bool SOC_AT91SAM9 || SOC_SAMA5
>>> + bool "Atmel Periodic Interval Timer (PIT)"
>>> + depends on SOC_AT91SAM9 || SOC_SAMA5
>>> + default SOC_AT91SAM9 || SOC_SAMA5
>>> + help
>>> + Select this to get a clocksource based on the Atmel Periodic Interval
>>> + Timer. It has a relatively low resolution and the TC Block clocksource
>>> + should be preferred.
>>> + It also provides a clock event device.
>>
>> Please conform to the format:
>>
>> config ATMEL_PIT
>> bool "Atmel Periodic Interval Timer (PIT)" if COMPILE_TEST
>> select ...
>> help
>> bla bla
>>
>> and select ATMEL_PIT from the platform's Kconfig.
>>
>
> Well, the goal is actually to allow people to unselect it so we don't
> want the platform to select it.
Why do you need people to unselect it?
The goal of the Kconfig here is to be silent except in the case the
COMPILE_TEST option is set for cross-compilation test coverage.
We are migrating all these options to this format. Please make it silent.
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [v2,03/11] arm64: Take into account ID_AA64PFR0_EL1.CSV3
From: Jayachandran C @ 2018-01-08 7:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515157961-20963-4-git-send-email-will.deacon@arm.com>
On Fri, Jan 05, 2018 at 01:12:33PM +0000, Will Deacon wrote:
> For non-KASLR kernels where the KPTI behaviour has not been overridden
> on the command line we can use ID_AA64PFR0_EL1.CSV3 to determine whether
> or not we should unmap the kernel whilst running at EL0.
>
> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm64/include/asm/sysreg.h | 1 +
> arch/arm64/kernel/cpufeature.c | 8 +++++++-
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index 08cc88574659..ae519bbd3f9e 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -437,6 +437,7 @@
> #define ID_AA64ISAR1_DPB_SHIFT 0
>
> /* id_aa64pfr0 */
> +#define ID_AA64PFR0_CSV3_SHIFT 60
> #define ID_AA64PFR0_SVE_SHIFT 32
> #define ID_AA64PFR0_GIC_SHIFT 24
> #define ID_AA64PFR0_ASIMD_SHIFT 20
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 9f0545dfe497..d723fc071f39 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -145,6 +145,7 @@ static const struct arm64_ftr_bits ftr_id_aa64isar1[] = {
> };
>
> static const struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
> + ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR0_CSV3_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_SVE_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_GIC_SHIFT, 4, 0),
> S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_ASIMD_SHIFT, 4, ID_AA64PFR0_ASIMD_NI),
> @@ -851,6 +852,8 @@ static int __kpti_forced; /* 0: not forced, >0: forced on, <0: forced off */
> static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
> int __unused)
> {
> + u64 pfr0 = read_sanitised_ftr_reg(SYS_ID_AA64PFR0_EL1);
> +
> /* Forced on command line? */
> if (__kpti_forced) {
> pr_info_once("kernel page table isolation forced %s by command line option\n",
> @@ -862,7 +865,9 @@ static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
> if (IS_ENABLED(CONFIG_RANDOMIZE_BASE))
> return true;
>
> - return false;
> + /* Defer to CPU feature registers */
> + return !cpuid_feature_extract_unsigned_field(pfr0,
> + ID_AA64PFR0_CSV3_SHIFT);
If I read this correctly, this enables KPTI on all processors without the CSV3
set (which seems to be a future capability).
Turning on KPTI has a small but significant overhead, so I think we should turn
it off on processors that are not vulnerable to CVE-2017-5754. Can we add something
like this:
--->8
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 19ed09b..202b037 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -862,6 +862,13 @@ static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
return __kpti_forced > 0;
}
+ /* Don't force KPTI for CPUs that are not vulnerable */
+ switch (read_cpuid_id() & MIDR_CPU_MODEL_MASK) {
+ case MIDR_CAVIUM_THUNDERX2:
+ case MIDR_BRCM_VULCAN:
+ return false;
+ }
+
/* Useful for KASLR robustness */
if (IS_ENABLED(CONFIG_RANDOMIZE_BASE))
return true;
--
JC
^ permalink raw reply related
* [PATCH 0/2] pinctrl: meson: use one uniform 'function' name
From: Yixun Lan @ 2018-01-08 7:33 UTC (permalink / raw)
To: linux-arm-kernel
These two patches are general improvement for meson pinctrl driver.
It make the two pinctrl trees (ee/ao) to share one uniform 'function' name for
one hardware block even its pin groups live inside two differet hardware domains,
which for example EE vs AO domain here.
This idea is motivated by Martin's question at [1]
[1]
http://lkml.kernel.org/r/CAFBinCCuQ-NK747+GHDkhZty_UMMgzCYOYFcNTrRDJgU8OM=Gw at mail.gmail.com
Yixun Lan (2):
pinctrl: meson: introduce a macro to have name/groups seperated
pinctrl: meson-axg: correct the pin expansion of UART_AO_B
drivers/pinctrl/meson/pinctrl-meson-axg.c | 4 ++--
drivers/pinctrl/meson/pinctrl-meson.h | 8 +++++---
2 files changed, 7 insertions(+), 5 deletions(-)
--
2.15.1
^ permalink raw reply
* [PATCH 1/2] pinctrl: meson: introduce a macro to have name/groups seperated
From: Yixun Lan @ 2018-01-08 7:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108073328.205769-1-yixun.lan@amlogic.com>
We introduce a macro FUNCTION_EX here, the main motivation is
trying to have the possibility to expand the macro with the same of the
'.name' number but different multiple '.groups/.num_groups' numbers.
With this change, the meson pinctrl drivr is capable of have one uniform
'function' name but with different pin 'groups', as we face the sitiuation
that two pin groups may live inside different hardware domain (EE vs AO domain),
which mean we couldn't put them in one single group.
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
drivers/pinctrl/meson/pinctrl-meson.h | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/pinctrl/meson/pinctrl-meson.h b/drivers/pinctrl/meson/pinctrl-meson.h
index 12a391109329..d8f705098810 100644
--- a/drivers/pinctrl/meson/pinctrl-meson.h
+++ b/drivers/pinctrl/meson/pinctrl-meson.h
@@ -124,13 +124,15 @@ struct meson_pinctrl {
struct device_node *of_node;
};
-#define FUNCTION(fn) \
+#define FUNCTION_EX(fn, ex) \
{ \
.name = #fn, \
- .groups = fn ## _groups, \
- .num_groups = ARRAY_SIZE(fn ## _groups), \
+ .groups = fn ## ex ## _groups, \
+ .num_groups = ARRAY_SIZE(fn ## ex ## _groups), \
}
+#define FUNCTION(fn) FUNCTION_EX(fn, )
+
#define BANK(n, f, l, fi, li, per, peb, pr, pb, dr, db, or, ob, ir, ib) \
{ \
.name = n, \
--
2.15.1
^ permalink raw reply related
* [PATCH 2/2] pinctrl: meson-axg: correct the pin expansion of UART_AO_B
From: Yixun Lan @ 2018-01-08 7:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108073328.205769-1-yixun.lan@amlogic.com>
The 'uart_ao_b_groups' for the UART_AO_B pins is already defined which is
living inside the AO domain, for these pins which are routed out from EE domain,
we need to correct them with the 'FUNCTION_EX' macro, otherwise there is
a conflict in the code level.
Also slightly adjust the name to make it short and more consistent.
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
drivers/pinctrl/meson/pinctrl-meson-axg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/meson/pinctrl-meson-axg.c b/drivers/pinctrl/meson/pinctrl-meson-axg.c
index 1fda9d6c7ea3..308e5433bd04 100644
--- a/drivers/pinctrl/meson/pinctrl-meson-axg.c
+++ b/drivers/pinctrl/meson/pinctrl-meson-axg.c
@@ -716,7 +716,7 @@ static const char * const uart_b_groups[] = {
"uart_tx_b_x", "uart_rx_b_x", "uart_cts_b_x", "uart_rts_b_x",
};
-static const char * const uart_ao_b_gpioz_groups[] = {
+static const char * const uart_ao_b_z_groups[] = {
"uart_ao_tx_b_z", "uart_ao_rx_b_z",
"uart_ao_cts_b_z", "uart_ao_rts_b_z",
};
@@ -855,7 +855,7 @@ static struct meson_pmx_func meson_axg_periphs_functions[] = {
FUNCTION(nand),
FUNCTION(uart_a),
FUNCTION(uart_b),
- FUNCTION(uart_ao_b_gpioz),
+ FUNCTION_EX(uart_ao_b, _z),
FUNCTION(i2c0),
FUNCTION(i2c1),
FUNCTION(i2c2),
--
2.15.1
^ permalink raw reply related
* [PATCH v4 2/6] clk: renesas: rcar-gen3: Add Z2 clock divider support
From: Simon Horman @ 2018-01-08 8:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdWk3ke6GriUdxHp_62r-REYV3P4qNiNGOcGRiCQWCyKAg@mail.gmail.com>
On Fri, Jan 05, 2018 at 03:35:13PM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Fri, Jan 5, 2018 at 3:04 PM, Simon Horman <horms@verge.net.au> wrote:
> > On Wed, Jan 03, 2018 at 01:47:08PM +0100, Geert Uytterhoeven wrote:
> >> On Wed, Jan 3, 2018 at 1:18 PM, Simon Horman <horms+renesas@verge.net.au> wrote:
> >> > From: Takeshi Kihara <takeshi.kihara.df@renesas.com>
> >> >
> >> > This patch adds Z2 clock divider support for R-Car Gen3 SoC.
> >> >
> >> > Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
> >> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>
> >> As the CPG/MSSR driver now has suspend/resume support, do we need
> >> a notifier to restore the Z or Z2 registers? Or is that handled automatically
> >> by cpufreq during system resume, for both the primary and the secondary
> >> CPU cores?
> >
> > I am a bit unsure.
> >
> > When using the A57 cores, which is the default case, the Z clk is queried
> > by CPUFreq on resume. It appears that on my system its already set to the
> > correct value but I assume if it was not then it would be reset. However,
> > this does not cover Z2 clk. So perhaps to be safe we need to register
> > notifiers and make sure they they play nicely with CPUFreq?
>
> Of course the CPU is special: unlike many other devices, it must be running
> when the kernel is reentered upon system resume.
> It may be running using a different frequency setting, though.
> However, following "opp-suspend", the system will always suspend with the
> Z clock running at 1.5GHz, which is the default?
> So Z is probably OK.
>
> It's more interesting to check what happens when the little cores are
> enabled as well (unfortunately that requires different firmware).
> 1. Does cpufreq handle them correctly when they are onlined again during
> system resume?
> 2. What happens if you offline all big cores, and enter system suspend
> running with little cores only?
> Perhaps that's prevented by the "opp-suspend" property as well?
Thanks for clarifying the problem.
I should be able to install updated firmware on:
i* r8a7796 (M3-W) ES1.0 / Salvator-X; and
* r8a7795 (H3) ES2.0 / Salvator-XS.
* But not easily r8a7795 (H3) / Salvator-X
Do you know what the minimal / desired firmware version is to exercise the
scenarios you describe.
^ permalink raw reply
* [PATCH v4 2/6] clk: renesas: rcar-gen3: Add Z2 clock divider support
From: Geert Uytterhoeven @ 2018-01-08 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108080210.2c4rrijezfsad55k@verge.net.au>
Hi Simon,
On Mon, Jan 8, 2018 at 9:02 AM, Simon Horman <horms@verge.net.au> wrote:
> On Fri, Jan 05, 2018 at 03:35:13PM +0100, Geert Uytterhoeven wrote:
>> On Fri, Jan 5, 2018 at 3:04 PM, Simon Horman <horms@verge.net.au> wrote:
>> > On Wed, Jan 03, 2018 at 01:47:08PM +0100, Geert Uytterhoeven wrote:
>> >> On Wed, Jan 3, 2018 at 1:18 PM, Simon Horman <horms+renesas@verge.net.au> wrote:
>> >> > From: Takeshi Kihara <takeshi.kihara.df@renesas.com>
>> >> >
>> >> > This patch adds Z2 clock divider support for R-Car Gen3 SoC.
>> >> >
>> >> > Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
>> >> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>>
>> >> As the CPG/MSSR driver now has suspend/resume support, do we need
>> >> a notifier to restore the Z or Z2 registers? Or is that handled automatically
>> >> by cpufreq during system resume, for both the primary and the secondary
>> >> CPU cores?
>> >
>> > I am a bit unsure.
>> >
>> > When using the A57 cores, which is the default case, the Z clk is queried
>> > by CPUFreq on resume. It appears that on my system its already set to the
>> > correct value but I assume if it was not then it would be reset. However,
>> > this does not cover Z2 clk. So perhaps to be safe we need to register
>> > notifiers and make sure they they play nicely with CPUFreq?
>>
>> Of course the CPU is special: unlike many other devices, it must be running
>> when the kernel is reentered upon system resume.
>> It may be running using a different frequency setting, though.
>> However, following "opp-suspend", the system will always suspend with the
>> Z clock running at 1.5GHz, which is the default?
>> So Z is probably OK.
>>
>> It's more interesting to check what happens when the little cores are
>> enabled as well (unfortunately that requires different firmware).
>> 1. Does cpufreq handle them correctly when they are onlined again during
>> system resume?
>> 2. What happens if you offline all big cores, and enter system suspend
>> running with little cores only?
>> Perhaps that's prevented by the "opp-suspend" property as well?
>
> Thanks for clarifying the problem.
>
> I should be able to install updated firmware on:
> i* r8a7796 (M3-W) ES1.0 / Salvator-X; and
> * r8a7795 (H3) ES2.0 / Salvator-XS.
> * But not easily r8a7795 (H3) / Salvator-X
>
> Do you know what the minimal / desired firmware version is to exercise the
> scenarios you describe.
There are binaries available for "v2.7.0 8core". Unfortunately I
believe it supports
your "not easily r8a7795 (H3) / Salvator-X" only...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 3/5] ARM: dts: imx28-tx28: Pass unit address and reg to IOMUX node
From: Lothar Waßmann @ 2018-01-08 8:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514383478-32544-3-git-send-email-festevam@gmail.com>
Hi,
On Wed, 27 Dec 2017 12:04:36 -0200 Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> Pass unit address and reg to IOMUX node to fix the following build
> warning with W=1:
>
> arch/arm/boot/dts/imx28-tx28.dtb: Warning (simple_bus_reg): Node /apb at 80000000/apbh at 80000000/pinctrl at 80018000/tx28-edt-ft5x06-pins missing or empty reg/ranges property
> arch/arm/boot/dts/imx28-tx28.dtb: Warning (simple_bus_reg): Node /apb at 80000000/apbh at 80000000/pinctrl at 80018000/tx28-flexcan-xcvr-pins missing or empty reg/ranges property
> arch/arm/boot/dts/imx28-tx28.dtb: Warning (simple_bus_reg): Node /apb at 80000000/apbh at 80000000/pinctrl at 80018000/tx28-lcdif-23bit missing or empty reg/ranges property
> arch/arm/boot/dts/imx28-tx28.dtb: Warning (simple_bus_reg): Node /apb at 80000000/apbh at 80000000/pinctrl at 80018000/tx28-lcdif-ctrl missing or empty reg/ranges property
> arch/arm/boot/dts/imx28-tx28.dtb: Warning (simple_bus_reg): Node /apb at 80000000/apbh at 80000000/pinctrl at 80018000/tx28-mac0-gpio-pins missing or empty reg/ranges property
> arch/arm/boot/dts/imx28-tx28.dtb: Warning (simple_bus_reg): Node /apb at 80000000/apbh at 80000000/pinctrl at 80018000/tx28-pca9554-pins missing or empty reg/ranges property
> arch/arm/boot/dts/imx28-tx28.dtb: Warning (simple_bus_reg): Node /apb at 80000000/apbh at 80000000/pinctrl at 80018000/spi-gpiogrp missing or empty reg/ranges property
> arch/arm/boot/dts/imx28-tx28.dtb: Warning (simple_bus_reg): Node /apb at 80000000/apbh at 80000000/pinctrl at 80018000/tx28-tsc2007-pins missing or empty reg/ranges property
> arch/arm/boot/dts/imx28-tx28.dtb: Warning (simple_bus_reg): Node /apb at 80000000/apbh at 80000000/pinctrl at 80018000/tx28-usbphy0-pins missing or empty reg/ranges property
> arch/arm/boot/dts/imx28-tx28.dtb: Warning (simple_bus_reg): Node /apb at 80000000/apbh at 80000000/pinctrl at 80018000/tx28-usbphy1-pins missing or empty reg/ranges property
>
> Cc: Lothar Wa?mann <LW@KARO-electronics.de>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> arch/arm/boot/dts/imx28-tx28.dts | 30 ++++++++++++++++++++----------
> 1 file changed, 20 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx28-tx28.dts b/arch/arm/boot/dts/imx28-tx28.dts
> index 152621e..8a4f5bc 100644
> --- a/arch/arm/boot/dts/imx28-tx28.dts
> +++ b/arch/arm/boot/dts/imx28-tx28.dts
> @@ -531,7 +531,8 @@
> fsl,pull-up = <MXS_PULL_DISABLE>;
> };
>
> - tx28_edt_ft5x06_pins: tx28-edt-ft5x06-pins {
> + tx28_edt_ft5x06_pins: tx28-edt-ft5x06-pins at 0 {
> + reg = <0>;
> fsl,pinmux-ids = <
> MX28_PAD_SSP0_DATA6__GPIO_2_6 /* RESET */
> MX28_PAD_SSP0_DATA5__GPIO_2_5 /* IRQ */
> @@ -542,7 +543,8 @@
> fsl,pull-up = <MXS_PULL_DISABLE>;
> };
>
> - tx28_flexcan_xcvr_pins: tx28-flexcan-xcvr-pins {
> + tx28_flexcan_xcvr_pins: tx28-flexcan-xcvr-pins at 0 {
> + reg = <0>;
> fsl,pinmux-ids = <
> MX28_PAD_LCD_D00__GPIO_1_0
> >;
> @@ -551,7 +553,8 @@
> fsl,pull-up = <MXS_PULL_DISABLE>;
> };
>
> - tx28_lcdif_23bit_pins: tx28-lcdif-23bit {
> + tx28_lcdif_23bit_pins: tx28-lcdif-23bit at 0 {
> + reg = <0>;
> fsl,pinmux-ids = <
> /* LCD_D00 may be used as Flexcan Transceiver Enable on STK5-V5 */
> MX28_PAD_LCD_D01__LCD_D1
> @@ -583,7 +586,8 @@
> fsl,pull-up = <MXS_PULL_DISABLE>;
> };
>
> - tx28_lcdif_ctrl_pins: tx28-lcdif-ctrl {
> + tx28_lcdif_ctrl_pins: tx28-lcdif-ctrl at 0 {
> + reg = <0>;
> fsl,pinmux-ids = <
> MX28_PAD_LCD_ENABLE__GPIO_1_31 /* Enable */
> MX28_PAD_LCD_RESET__GPIO_3_30 /* Reset */
> @@ -593,7 +597,8 @@
> fsl,pull-up = <MXS_PULL_DISABLE>;
> };
>
> - tx28_mac0_pins_gpio: tx28-mac0-gpio-pins {
> + tx28_mac0_pins_gpio: tx28-mac0-gpio-pins at 0 {
> + reg = <0>;
> fsl,pinmux-ids = <
> MX28_PAD_ENET0_MDC__GPIO_4_0
> MX28_PAD_ENET0_MDIO__GPIO_4_1
> @@ -610,7 +615,8 @@
> fsl,pull-up = <MXS_PULL_DISABLE>;
> };
>
> - tx28_pca9554_pins: tx28-pca9554-pins {
> + tx28_pca9554_pins: tx28-pca9554-pins at 0 {
> + reg = <0>;
> fsl,pinmux-ids = <
> MX28_PAD_PWM3__GPIO_3_28
> >;
> @@ -619,7 +625,8 @@
> fsl,pull-up = <MXS_PULL_DISABLE>;
> };
>
> - tx28_spi_gpio_pins: spi-gpiogrp {
> + tx28_spi_gpio_pins: spi-gpiogrp at 0 {
> + reg = <0>;
> fsl,pinmux-ids = <
> MX28_PAD_AUART2_RX__GPIO_3_8
> MX28_PAD_AUART2_TX__GPIO_3_9
> @@ -633,7 +640,8 @@
> fsl,pull-up = <MXS_PULL_DISABLE>;
> };
>
> - tx28_tsc2007_pins: tx28-tsc2007-pins {
> + tx28_tsc2007_pins: tx28-tsc2007-pins at 0 {
> + reg = <0>;
> fsl,pinmux-ids = <
> MX28_PAD_SAIF0_MCLK__GPIO_3_20 /* TSC2007 IRQ */
> >;
> @@ -643,7 +651,8 @@
> };
>
>
> - tx28_usbphy0_pins: tx28-usbphy0-pins {
> + tx28_usbphy0_pins: tx28-usbphy0-pins at 0 {
> + reg = <0>;
> fsl,pinmux-ids = <
> MX28_PAD_GPMI_CE2N__GPIO_0_18 /* USBOTG_VBUSEN */
> MX28_PAD_GPMI_CE3N__GPIO_0_19 /* USBOTH_OC */
> @@ -653,7 +662,8 @@
> fsl,pull-up = <MXS_PULL_DISABLE>;
> };
>
> - tx28_usbphy1_pins: tx28-usbphy1-pins {
> + tx28_usbphy1_pins: tx28-usbphy1-pins at 0 {
> + reg = <0>;
> fsl,pinmux-ids = <
> MX28_PAD_SPDIF__GPIO_3_27 /* USBH_VBUSEN */
> MX28_PAD_JTAG_RTCK__GPIO_4_20 /* USBH_OC */
Acked-By: Lothar Wa?mann <LW@KARO-electronics.de>
Lothar Wa?mann
^ permalink raw reply
* [PATCH] mtd/nand/atmel: Delete an error message for a failed memory allocation in two functions
From: Boris Brezillon @ 2018-01-08 8:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <09e98604-00ec-64be-665a-a101b31028b1@Microchip.com>
[private message]
Hi Wenyou,
On Mon, 8 Jan 2018 08:58:21 +0800
"Yang, Wenyou" <Wenyou.Yang@Microchip.com> wrote:
> On 2018/1/6 4:55, SF Markus Elfring wrote:
> > From: Markus Elfring <elfring@users.sourceforge.net>
> > Date: Fri, 5 Jan 2018 21:45:04 +0100
> >
> > Omit an extra message for a memory allocation failure in these functions.
> >
> > This issue was detected by using the Coccinelle software.
> >
> > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> > ---
>
> Acked-by: Wenyou Yang <wenyou.yang@microchip.com>
Please don't encourage Markus to send more patches. The MTD maintainers
(like other maintainers) have decided to ignore his contributions.
If you want to know why, just google his name and you should have a
pretty good idea.
Thanks,
Boris
> > drivers/mtd/nand/atmel/nand-controller.c | 8 ++------
> > 1 file changed, 2 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/atmel/nand-controller.c b/drivers/mtd/nand/atmel/nand-controller.c
> > index 90a71a56bc23..a41b999229c9 100644
> > --- a/drivers/mtd/nand/atmel/nand-controller.c
> > +++ b/drivers/mtd/nand/atmel/nand-controller.c
> > @@ -1612,10 +1612,8 @@ static int atmel_nand_register(struct atmel_nand *nand)
> > mtd->name = devm_kasprintf(nc->dev, GFP_KERNEL,
> > "%s:nand.%d", dev_name(nc->dev),
> > nand->cs[0].id);
> > - if (!mtd->name) {
> > - dev_err(nc->dev, "Failed to allocate mtd->name\n");
> > + if (!mtd->name)
> > return -ENOMEM;
> > - }
> > }
> >
> > ret = nand_scan_tail(mtd);
> > @@ -1654,10 +1652,8 @@ static struct atmel_nand *atmel_nand_create(struct atmel_nand_controller *nc,
> > nand = devm_kzalloc(nc->dev,
> > sizeof(*nand) + (numcs * sizeof(*nand->cs)),
> > GFP_KERNEL);
> > - if (!nand) {
> > - dev_err(nc->dev, "Failed to allocate NAND object\n");
> > + if (!nand)
> > return ERR_PTR(-ENOMEM);
> > - }
> >
> > nand->numcs = numcs;
> >
>
> Best Regards,
> Wenyou Yang
^ permalink raw reply
* [PATCH v2 3/6] clocksource/drivers: atmel-pit: allow unselecting ATMEL_PIT
From: Boris Brezillon @ 2018-01-08 8:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b8c0c142-2a69-648b-1389-a4467a26211b@linaro.org>
On Mon, 8 Jan 2018 08:23:02 +0100
Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
> On 07/01/2018 19:44, Alexandre Belloni wrote:
> > On 07/01/2018 at 19:07:13 +0100, Daniel Lezcano wrote:
> >> On 05/01/2018 15:30, Alexandre Belloni wrote:
> >>> With the new TCB clocksource driver, atmel platforms are now able to boot
> >>> without the PIT driver. Allow unselecting it.
> >>>
> >>> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> >>> ---
> >>> drivers/clocksource/Kconfig | 9 ++++++++-
> >>> 1 file changed, 8 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> >>> index 5609572e0236..55ccfa0ba63b 100644
> >>> --- a/drivers/clocksource/Kconfig
> >>> +++ b/drivers/clocksource/Kconfig
> >>> @@ -381,7 +381,14 @@ config ARMV7M_SYSTICK
> >>>
> >>> config ATMEL_PIT
> >>> select TIMER_OF if OF
> >>> - def_bool SOC_AT91SAM9 || SOC_SAMA5
> >>> + bool "Atmel Periodic Interval Timer (PIT)"
> >>> + depends on SOC_AT91SAM9 || SOC_SAMA5
> >>> + default SOC_AT91SAM9 || SOC_SAMA5
> >>> + help
> >>> + Select this to get a clocksource based on the Atmel Periodic Interval
> >>> + Timer. It has a relatively low resolution and the TC Block clocksource
> >>> + should be preferred.
> >>> + It also provides a clock event device.
> >>
> >> Please conform to the format:
> >>
> >> config ATMEL_PIT
> >> bool "Atmel Periodic Interval Timer (PIT)" if COMPILE_TEST
> >> select ...
> >> help
> >> bla bla
> >>
> >> and select ATMEL_PIT from the platform's Kconfig.
> >>
> >
> > Well, the goal is actually to allow people to unselect it so we don't
> > want the platform to select it.
>
> Why do you need people to unselect it?
Because we have 2 possible clocksource for atmel platforms: the PIT or
the TCB, if the TCB is selected there's no point in compiling the PIT
driver.
>
> The goal of the Kconfig here is to be silent except in the case the
> COMPILE_TEST option is set for cross-compilation test coverage.
>
> We are migrating all these options to this format. Please make it silent.
>
>
^ permalink raw reply
* [PATCH] ARM: dts: sun[47]i: Fix display backend 1 output to TCON0 remote endpoint
From: Chen-Yu Tsai @ 2018-01-08 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180104132752.pcixtjugwfvlshpl@flea.lan>
On Thu, Jan 4, 2018 at 9:27 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Thu, Jan 04, 2018 at 12:31:55AM +0800, Chen-Yu Tsai wrote:
>> There is a copy-paste error in the display pipeline device tree graph.
>> The remote endpoint of the display backend 1's output to TCON0 points
>> to the wrong endpoint. This will result in the driver incorrectly
>> parsing the relationship of the components.
>>
>> Reported-by: Andrea Venturi <ennesimamail.av@gmail.com>
>> Fixes: 0df4cf33a594 ("ARM: dts: sun4i: Add device nodes for display
>> pipelines")
>> Fixes: 5b92b29bed45 ("ARM: dts: sun7i: Add device nodes for display
>> pipelines")
>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Applied (a few days ago).
This will be sent out in a pull request later.
ChenYu
^ permalink raw reply
* [PATCH] mtd/nand/atmel: Delete an error message for a failed memory allocation in two functions
From: Boris Brezillon @ 2018-01-08 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108091831.64d54599@bbrezillon>
On Mon, 8 Jan 2018 09:18:31 +0100
Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> [private message]
Oops, not so private :-).
> Hi Wenyou,
>
> On Mon, 8 Jan 2018 08:58:21 +0800
> "Yang, Wenyou" <Wenyou.Yang@Microchip.com> wrote:
>
> > On 2018/1/6 4:55, SF Markus Elfring wrote:
> > > From: Markus Elfring <elfring@users.sourceforge.net>
> > > Date: Fri, 5 Jan 2018 21:45:04 +0100
> > >
> > > Omit an extra message for a memory allocation failure in these functions.
> > >
> > > This issue was detected by using the Coccinelle software.
> > >
> > > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> > > ---
> >
> > Acked-by: Wenyou Yang <wenyou.yang@microchip.com>
>
> Please don't encourage Markus to send more patches. The MTD maintainers
> (like other maintainers) have decided to ignore his contributions.
>
> If you want to know why, just google his name and you should have a
> pretty good idea.
>
> Thanks,
>
> Boris
>
> > > drivers/mtd/nand/atmel/nand-controller.c | 8 ++------
> > > 1 file changed, 2 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/mtd/nand/atmel/nand-controller.c b/drivers/mtd/nand/atmel/nand-controller.c
> > > index 90a71a56bc23..a41b999229c9 100644
> > > --- a/drivers/mtd/nand/atmel/nand-controller.c
> > > +++ b/drivers/mtd/nand/atmel/nand-controller.c
> > > @@ -1612,10 +1612,8 @@ static int atmel_nand_register(struct atmel_nand *nand)
> > > mtd->name = devm_kasprintf(nc->dev, GFP_KERNEL,
> > > "%s:nand.%d", dev_name(nc->dev),
> > > nand->cs[0].id);
> > > - if (!mtd->name) {
> > > - dev_err(nc->dev, "Failed to allocate mtd->name\n");
> > > + if (!mtd->name)
> > > return -ENOMEM;
> > > - }
> > > }
> > >
> > > ret = nand_scan_tail(mtd);
> > > @@ -1654,10 +1652,8 @@ static struct atmel_nand *atmel_nand_create(struct atmel_nand_controller *nc,
> > > nand = devm_kzalloc(nc->dev,
> > > sizeof(*nand) + (numcs * sizeof(*nand->cs)),
> > > GFP_KERNEL);
> > > - if (!nand) {
> > > - dev_err(nc->dev, "Failed to allocate NAND object\n");
> > > + if (!nand)
> > > return ERR_PTR(-ENOMEM);
> > > - }
> > >
> > > nand->numcs = numcs;
> > >
> >
> > Best Regards,
> > Wenyou Yang
>
^ permalink raw reply
* [GIT PULL] Allwinner fixes for 4.15, round 2
From: Chen-Yu Tsai @ 2018-01-08 8:42 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Olof,
Here's another fix for 4.15. The error was introduced in 4.15-rc1,
so we'd really like to see it fixed for this release.
Thanks
ChenYu
The following changes since commit eac6a3639decefcc8eb0941dd3cebe79993670ad:
ARM: dts: sun8i: a711: Reinstate the PMIC compatible (2017-12-19 09:56:57 +0100)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-fixes-for-4.15-2
for you to fetch changes up to bdae44705c0d5b751fbd79bc4a169905b25ed335:
ARM: dts: sun[47]i: Fix display backend 1 output to TCON0 remote endpoint (2018-01-06 11:21:28 +0800)
----------------------------------------------------------------
Allwinner fixes for 4.15, round 2
One fix that fixes the display pipeline description in the device tree
for the A10 and A20 SoCs. This description was introduced in 4.15-rc1
with a mismatch in the graph remote endpoints, which would likely
result in the driver misinterpreting how the individual components fit
together.
----------------------------------------------------------------
Chen-Yu Tsai (1):
ARM: dts: sun[47]i: Fix display backend 1 output to TCON0 remote endpoint
arch/arm/boot/dts/sun4i-a10.dtsi | 2 +-
arch/arm/boot/dts/sun7i-a20.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180108/415a3776/attachment.sig>
^ permalink raw reply
* [PATCH v2 3/5] ARM64: dts: meson-axg: uart: Add the pinctrl info description
From: Jerome Brunet @ 2018-01-08 8:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b2571e30-d543-9288-68cf-1af86bb5f4bc@amlogic.com>
On Mon, 2018-01-08 at 14:07 +0800, Yixun Lan wrote:
> > (the following question just came up while I was looking at this
> > patch, but I guess it's more a question towards the pinctrl driver)
> > the name of the function looks a bit "weird" since below you are also
> > using "uart_ao_b"
>
> you right here, it's a question related to pinctrl subsystem.
> from my point of view, it's even weird from the hardware perspective:
> that, the UART function of AO domain route the pin of EE domain..
>
> > did you choose "uart_ao_b_gpioz" here because we cannot have the same
> > function name for the periphs and AO pinctrl or is there some other
> > reason?
> >
>
> Current there is a conflict in the code level which both two pinctrl
> tree (EE, AO) are using the same macro[1] to expand the definitions, so
> there would be conflict symbol if we name both as 'uart_ao_b'
>
> I think your idea of having an uniform function 'uart_ao_b' for both
> pinctrl subsystem is actually possible/positive..
>
> I will think about your suggestion and come up with a patch later,
> thanks a lot!
>
>
> [1] drivers/pinctrl/meson/pinctrl-meson.h
>
> #define FUNCTION(fn) \
> { \
> .name = #fn, \
> .groups = fn ## _groups, \
> .num_groups = ARRAY_SIZE(fn ## _groups), \
> }
The name feels weird because it should have been uart_ao_b_z ... We missed it in
the initial review. Except for correcting the function name, I don't think this
justify a change a pinctrl
^ permalink raw reply
* [PATCH v6 08/10] pwm: pwm-omap-dmtimer: Adapt driver to utilize dmtimer pdata ops
From: Claudiu Beznea @ 2018-01-08 8:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514887799-24605-9-git-send-email-j-keerthy@ti.com>
On 02.01.2018 12:09, Keerthy wrote:
> Adapt driver to utilize dmtimer pdata ops instead of pdata-quirks.
>
> Signed-off-by: Keerthy <j-keerthy@ti.com>
> Tested-by: Ladislav Michl <ladis@linux-mips.org>
> ---
> drivers/pwm/pwm-omap-dmtimer.c | 39 ++++++++++++++++++++++-----------------
> 1 file changed, 22 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/pwm/pwm-omap-dmtimer.c b/drivers/pwm/pwm-omap-dmtimer.c
> index 5ad42f3..3b27aff 100644
> --- a/drivers/pwm/pwm-omap-dmtimer.c
> +++ b/drivers/pwm/pwm-omap-dmtimer.c
> @@ -23,6 +23,7 @@
> #include <linux/mutex.h>
> #include <linux/of.h>
> #include <linux/of_platform.h>
> +#include <linux/platform_data/dmtimer-omap.h>
> #include <linux/platform_data/pwm_omap_dmtimer.h>
> #include <linux/platform_device.h>
> #include <linux/pm_runtime.h>
> @@ -37,7 +38,7 @@ struct pwm_omap_dmtimer_chip {
> struct pwm_chip chip;
> struct mutex mutex;
> pwm_omap_dmtimer *dm_timer;
> - struct pwm_omap_dmtimer_pdata *pdata;
> + struct omap_dm_timer_ops *pdata;
> struct platform_device *dm_timer_pdev;
> };
>
> @@ -242,19 +243,33 @@ static int pwm_omap_dmtimer_probe(struct platform_device *pdev)
> {
> struct device_node *np = pdev->dev.of_node;
> struct device_node *timer;
> + struct platform_device *timer_pdev;
> struct pwm_omap_dmtimer_chip *omap;
> - struct pwm_omap_dmtimer_pdata *pdata;
> + struct dmtimer_platform_data *timer_pdata;
> + struct omap_dm_timer_ops *pdata;
> pwm_omap_dmtimer *dm_timer;
> u32 v;
> int status;
>
> - pdata = dev_get_platdata(&pdev->dev);
> - if (!pdata) {
> - dev_err(&pdev->dev, "Missing dmtimer platform data\n");
> + timer = of_parse_phandle(np, "ti,timers", 0);
of_node_put() should be called when done with device_node pointer returned
by of_parse_phandle() (you may want to check the return ERROR cases below
regarding this statement):
> + if (!timer)
> + return -ENODEV;
> +
> + timer_pdev = of_find_device_by_node(timer);
> + if (!timer_pdev) {
> + dev_err(&pdev->dev, "Unable to find Timer pdev\n");
here
> + return -ENODEV;
> + }
> +
> + timer_pdata = dev_get_platdata(&timer_pdev->dev);
> + if (!timer_pdata) {
> + dev_err(&pdev->dev, "dmtimer pdata structure NULL\n");
here
> return -EINVAL;
> }
>
> - if (!pdata->request_by_node ||
> + pdata = timer_pdata->timer_ops;
> +
> + if (!pdata || !pdata->request_by_node ||
> !pdata->free ||
> !pdata->enable ||
> !pdata->disable ||
> @@ -270,10 +285,6 @@ static int pwm_omap_dmtimer_probe(struct platform_device *pdev)
> return -EINVAL;
> }
>
> - timer = of_parse_phandle(np, "ti,timers", 0);
> - if (!timer)
> - return -ENODEV;
> -
> if (!of_get_property(timer, "ti,timer-pwm", NULL)) {
here
> dev_err(&pdev->dev, "Missing ti,timer-pwm capability\n");
> return -ENODEV;
> @@ -291,13 +302,7 @@ static int pwm_omap_dmtimer_probe(struct platform_device *pdev)
>
> omap->pdata = pdata;
> omap->dm_timer = dm_timer;
> -
> - omap->dm_timer_pdev = of_find_device_by_node(timer);
> - if (!omap->dm_timer_pdev) {
> - dev_err(&pdev->dev, "Unable to find timer pdev\n");
> - omap->pdata->free(dm_timer);
> - return -EINVAL;
> - }
> + omap->dm_timer_pdev = timer_pdev;
>
> /*
> * Ensure that the timer is stopped before we allow PWM core to call
>
And all the other return instructions from probe function not listed by git diff
^ permalink raw reply
* [PATCH] imx6: fix pcie enumeration
From: Koen Vandeputte @ 2018-01-08 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105171828.GC24933@red-moon>
On 2018-01-05 18:18, Lorenzo Pieralisi wrote:
>>
>> Hi Lorenzo,
>>
>> This is exactly what I'm trying to explain:
>>
>> The host starts of with a (hardcoded today) subord of 1. [bits 16:23]
>>
>> Since commit a20c7f36bd3d, downstream devices cannot assign bus nr's
>> higher than the subord of the upstream device.
>> So in this case, scanning stops after the bridge as soon as bus 1 is
>> assigned .. :)
> There is one thing that I need to understand though. Before the commit
> above, how would enumeration works given that the subordinate bus number
> was set to 1 and that the kernel, AFAICS, does not overwrite it ?
>
> Are you able to send me a log (enumeration with debugging enabled and
> lspci) with the commit above reverted please ?
>
> Thanks,
> Lorenzo
>
Info below as requested:
[??? 0.116729] OF: PCI: host bridge /soc/pcie at 0x01000000 ranges:
[??? 0.116748] OF: PCI:?? No bus range found for /soc/pcie at 0x01000000,
using [bus 00-ff]
[??? 0.116777] OF: PCI:??? IO 0x01f80000..0x01f8ffff -> 0x00000000
[??? 0.116796] OF: PCI:?? MEM 0x01000000..0x01efffff -> 0x01000000
[??? 0.337917] imx6q-pcie 1ffc000.pcie: link up
[??? 0.337934] imx6q-pcie 1ffc000.pcie: Link: Gen2 disabled
[??? 0.337947] imx6q-pcie 1ffc000.pcie: link up
[??? 0.337958] imx6q-pcie 1ffc000.pcie: Link up, Gen1
[??? 0.338197] imx6q-pcie 1ffc000.pcie: PCI host bridge to bus 0000:00
[??? 0.338215] pci_bus 0000:00: root bus resource [bus 00-ff]
[??? 0.338230] pci_bus 0000:00: root bus resource [io 0x0000-0xffff]
[??? 0.338243] pci_bus 0000:00: root bus resource [mem
0x01000000-0x01efffff]
[??? 0.338255] pci_bus 0000:00: scanning bus
[??? 0.338286] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
[??? 0.338311] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
[??? 0.338328] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
[??? 0.338362] pci 0000:00:00.0: calling pci_fixup_ide_bases+0x0/0x4c
[??? 0.338416] pci 0000:00:00.0: supports D1
[??? 0.338425] pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold
[??? 0.338436] pci 0000:00:00.0: PME# disabled
[??? 0.338664] pci_bus 0000:00: fixups for bus
[??? 0.338676] PCI: bus0: Fast back to back transfers disabled
[??? 0.338692] pci 0000:00:00.0: scanning [bus 01-01] behind bridge, pass 0
[??? 0.338822] pci_bus 0000:01: scanning bus
[??? 0.338926] pci 0000:01:00.0: [10b5:8604] type 01 class 0x060400
[??? 0.338969] pci 0000:01:00.0: calling ventana_pciesw_early_fixup+0x0/0xa4
[??? 0.457984] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x0001ffff]
[??? 0.458167] pci 0000:01:00.0: calling pci_fixup_ide_bases+0x0/0x4c
[??? 0.458635] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
[??? 0.458660] pci 0000:01:00.0: PME# disabled
[??? 0.458970] pci_bus 0000:01: fixups for bus
[??? 0.459027] PCI: bus1: Fast back to back transfers disabled
[??? 0.459052] pci 0000:01:00.0: scanning [bus 00-00] behind bridge, pass 0
[??? 0.459060] pci 0000:01:00.0: bridge configuration invalid ([bus
00-00]), reconfiguring
[??? 0.459115] pci 0000:01:00.0: scanning [bus 00-00] behind bridge, pass 1
[??? 0.459443] pci_bus 0000:02: busn_res: can not insert [bus 02-ff]
under [bus 01] (conflicts with (null) [bus 01])
[??? 0.459461] pci_bus 0000:02: scanning bus
[??? 0.459573] pci 0000:02:01.0: [10b5:8604] type 01 class 0x060400
[??? 0.459617] pci 0000:02:01.0: calling ventana_pciesw_early_fixup+0x0/0xa4
[??? 0.459865] pci 0000:02:01.0: calling pci_fixup_ide_bases+0x0/0x4c
[??? 0.460298] pci 0000:02:01.0: PME# supported from D0 D3hot D3cold
[??? 0.460321] pci 0000:02:01.0: PME# disabled
[??? 0.460719] pci 0000:02:04.0: [10b5:8604] type 01 class 0x060400
[??? 0.460760] pci 0000:02:04.0: calling ventana_pciesw_early_fixup+0x0/0xa4
[??? 0.461009] pci 0000:02:04.0: calling pci_fixup_ide_bases+0x0/0x4c
[??? 0.461436] pci 0000:02:04.0: PME# supported from D0 D3hot D3cold
[??? 0.461460] pci 0000:02:04.0: PME# disabled
[??? 0.461841] pci 0000:02:05.0: [10b5:8604] type 01 class 0x060400
[??? 0.461883] pci 0000:02:05.0: calling ventana_pciesw_early_fixup+0x0/0xa4
[??? 0.462128] pci 0000:02:05.0: calling pci_fixup_ide_bases+0x0/0x4c
[??? 0.462553] pci 0000:02:05.0: PME# supported from D0 D3hot D3cold
[??? 0.462578] pci 0000:02:05.0: PME# disabled
[??? 0.463084] pci_bus 0000:02: fixups for bus
[??? 0.463231] PCI: bus2: Fast back to back transfers disabled
[??? 0.463255] pci 0000:02:01.0: scanning [bus 00-00] behind bridge, pass 0
[??? 0.463264] pci 0000:02:01.0: bridge configuration invalid ([bus
00-00]), reconfiguring
[??? 0.463319] pci 0000:02:04.0: scanning [bus 00-00] behind bridge, pass 0
[??? 0.463328] pci 0000:02:04.0: bridge configuration invalid ([bus
00-00]), reconfiguring
[??? 0.463378] pci 0000:02:05.0: scanning [bus 00-00] behind bridge, pass 0
[??? 0.463385] pci 0000:02:05.0: bridge configuration invalid ([bus
00-00]), reconfiguring
[??? 0.463435] pci 0000:02:01.0: scanning [bus 00-00] behind bridge, pass 1
[??? 0.463764] pci_bus 0000:03: scanning bus
[??? 0.463785] pci_bus 0000:03: fixups for bus
[??? 0.463791] PCI: bus3: Fast back to back transfers enabled
[??? 0.463803] pci_bus 0000:03: bus scan returning with max=03
[??? 0.463814] pci_bus 0000:03: busn_res: [bus 03-ff] end is updated to 03
[??? 0.463833] pci_bus 0000:03: [bus 03] partially hidden behind bridge
0000:01 [bus 01]
[??? 0.463862] pci 0000:02:04.0: scanning [bus 00-00] behind bridge, pass 1
[??? 0.464178] pci_bus 0000:04: scanning bus
[??? 0.464197] pci_bus 0000:04: fixups for bus
[??? 0.464202] PCI: bus4: Fast back to back transfers enabled
[??? 0.464214] pci_bus 0000:04: bus scan returning with max=04
[??? 0.464223] pci_bus 0000:04: busn_res: [bus 04-ff] end is updated to 04
[??? 0.464242] pci_bus 0000:04: [bus 04] partially hidden behind bridge
0000:01 [bus 01]
[??? 0.464271] pci 0000:02:05.0: scanning [bus 00-00] behind bridge, pass 1
[??? 0.464586] pci_bus 0000:05: scanning bus
[??? 0.464691] pci 0000:05:00.0: [168c:0033] type 00 class 0x028000
[??? 0.464825] pci 0000:05:00.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]
[??? 0.465036] pci 0000:05:00.0: reg 0x30: [mem 0x00000000-0x0000ffff pref]
[??? 0.465095] pci 0000:05:00.0: calling pci_fixup_ide_bases+0x0/0x4c
[??? 0.465117] pci 0000:05:00.0: calling quirk_no_bus_reset+0x0/0x20
[??? 0.465489] pci 0000:05:00.0: supports D1
[??? 0.465498] pci 0000:05:00.0: PME# supported from D0 D1 D3hot
[??? 0.465524] pci 0000:05:00.0: PME# disabled
[??? 0.465859] pci_bus 0000:05: fixups for bus
[??? 0.465903] PCI: bus5: Fast back to back transfers disabled
[??? 0.465916] pci_bus 0000:05: bus scan returning with max=05
[??? 0.465926] pci_bus 0000:05: busn_res: [bus 05-ff] end is updated to 05
[??? 0.465946] pci_bus 0000:05: [bus 05] partially hidden behind bridge
0000:01 [bus 01]
[??? 0.465965] pci_bus 0000:02: bus scan returning with max=05
[??? 0.465974] pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 05
[??? 0.465984] pci_bus 0000:02: busn_res: can not insert [bus 02-05]
under [bus 01] (conflicts with (null) [bus 01])
[??? 0.466005] pci_bus 0000:02: [bus 02-05] partially hidden behind
bridge 0000:01 [bus 01]
[??? 0.466026] pci_bus 0000:01: bus scan returning with max=05
[??? 0.466033] pci 0000:00:00.0: bridge has subordinate 01 but max busn 05
[??? 0.466049] pci 0000:00:00.0: scanning [bus 01-01] behind bridge, pass 1
[??? 0.466059] pci_bus 0000:00: bus scan returning with max=01
[??? 0.466186] pci 0000:00:00.0: fixup irq: got 298
[??? 0.466196] pci 0000:00:00.0: assigning IRQ 298
[??? 0.466247] pci 0000:01:00.0: fixup irq: got 298
[??? 0.466254] pci 0000:01:00.0: assigning IRQ 298
[??? 0.466374] pci 0000:02:01.0: fixup irq: got 299
[??? 0.466382] pci 0000:02:01.0: assigning IRQ 299
[??? 0.466436] pci 0000:02:04.0: fixup irq: got 298
[??? 0.466442] pci 0000:02:04.0: assigning IRQ 298
[??? 0.466501] pci 0000:02:05.0: fixup irq: got 299
[??? 0.466509] pci 0000:02:05.0: assigning IRQ 299
[??? 0.466562] pci 0000:05:00.0: fixup irq: got 299
[??? 0.466569] pci 0000:05:00.0: assigning IRQ 299
[??? 0.466807] pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
[??? 0.466825] pci 0000:00:00.0: BAR 8: assigned [mem 0x01100000-0x012fffff]
[??? 0.466843] pci 0000:00:00.0: BAR 6: assigned [mem
0x01300000-0x0130ffff pref]
[??? 0.466862] pci 0000:01:00.0: BAR 8: assigned [mem 0x01100000-0x011fffff]
[??? 0.466875] pci 0000:01:00.0: BAR 0: assigned [mem 0x01200000-0x0121ffff]
[??? 0.466908] pci 0000:02:05.0: BAR 8: assigned [mem 0x01100000-0x011fffff]
[??? 0.466919] pci 0000:02:01.0: PCI bridge to [bus 03]
[??? 0.467001] pci 0000:02:04.0: PCI bridge to [bus 04]
[??? 0.467086] pci 0000:05:00.0: BAR 0: assigned [mem
0x01100000-0x0111ffff 64bit]
[??? 0.467160] pci 0000:05:00.0: BAR 6: assigned [mem
0x01120000-0x0112ffff pref]
[??? 0.467171] pci 0000:02:05.0: PCI bridge to [bus 05]
[??? 0.467206] pci 0000:02:05.0:?? bridge window [mem 0x01100000-0x011fffff]
[??? 0.467262] pci 0000:01:00.0: PCI bridge to [bus 02-05]
[??? 0.467297] pci 0000:01:00.0:?? bridge window [mem 0x01100000-0x011fffff]
[??? 0.467352] pci 0000:00:00.0: PCI bridge to [bus 01]
[??? 0.467364] pci 0000:00:00.0:?? bridge window [mem 0x01100000-0x012fffff]
[??? 0.467627] pcieport 0000:00:00.0: Signaling PME through PCIe PME
interrupt
[??? 0.467643] pci 0000:01:00.0: Signaling PME through PCIe PME interrupt
[??? 0.467653] pci 0000:02:01.0: Signaling PME through PCIe PME interrupt
[??? 0.467662] pci 0000:02:04.0: Signaling PME through PCIe PME interrupt
[??? 0.467671] pci 0000:02:05.0: Signaling PME through PCIe PME interrupt
[??? 0.467680] pci 0000:05:00.0: Signaling PME through PCIe PME interrupt
[??? 0.467694] pcie_pme 0000:00:00.0:pcie001: service driver pcie_pme loaded
[??? 0.468019] pcieport 0000:01:00.0: enabling device (0140 -> 0142)
[??? 0.468147] pcieport 0000:01:00.0: enabling bus mastering
[??? 0.468886] pcieport 0000:02:01.0: enabling bus mastering
[??? 0.469576] pcieport 0000:02:04.0: enabling bus mastering
[??? 0.470165] pcieport 0000:02:05.0: enabling device (0140 -> 0142)
[??? 0.470275] pcieport 0000:02:05.0: enabling bus mastering
[ Node 4 | node-4 ] lspci -v
00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00
[Normal decode])
??? Flags: bus master, fast devsel, latency 0, IRQ 298
??? Memory at 01000000 (32-bit, non-prefetchable) [size=1M]
??? Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
??? I/O behind bridge: None
??? Memory behind bridge: 01100000-012fffff [size=2M]
??? Prefetchable memory behind bridge: None
??? [virtual] Expansion ROM at 01300000 [disabled] [size=64K]
??? Capabilities: [40] Power Management version 3
??? Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
??? Capabilities: [70] Express Root Port (Slot-), MSI 00
??? Capabilities: [100] Advanced Error Reporting
??? Capabilities: [140] Virtual Channel
??? Kernel driver in use: pcieport
lspci: Unable to load libkmod resources: error -12
01:00.0 PCI bridge: PLX Technology, Inc. PEX 8604 4-lane, 4-Port PCI
Express Gen 2 (5.0 GT/s) Switch (rev ba) (prog-if 00 [Normal decode])
??? Flags: bus master, fast devsel, latency 0, IRQ 298
??? Memory at 01200000 (32-bit, non-prefetchable) [size=128K]
??? Bus: primary=01, secondary=02, subordinate=05, sec-latency=0
??? I/O behind bridge: None
??? Memory behind bridge: 01100000-011fffff [size=1M]
??? Prefetchable memory behind bridge: None
??? Capabilities: [40] Power Management version 3
??? Capabilities: [48] MSI: Enable- Count=1/4 Maskable+ 64bit+
??? Capabilities: [68] Express Upstream Port, MSI 00
??? Capabilities: [a4] Subsystem: PLX Technology, Inc. PEX 8604 4-lane,
4-Port PCI Express Gen 2 (5.0 GT/s) Switch
??? Capabilities: [100] Device Serial Number ba-86-01-10-b5-df-0e-00
??? Capabilities: [fb4] Advanced Error Reporting
??? Capabilities: [138] Power Budgeting <?>
??? Capabilities: [148] Virtual Channel
??? Capabilities: [448] Vendor Specific Information: ID=0000 Rev=0
Len=0cc <?>
??? Capabilities: [950] Vendor Specific Information: ID=0001 Rev=0
Len=010 <?>
??? Kernel driver in use: pcieport
02:01.0 PCI bridge: PLX Technology, Inc. PEX 8604 4-lane, 4-Port PCI
Express Gen 2 (5.0 GT/s) Switch (rev ba) (prog-if 00 [Normal decode])
??? Flags: bus master, fast devsel, latency 0, IRQ 299
??? Bus: primary=02, secondary=03, subordinate=03, sec-latency=0
??? I/O behind bridge: None
??? Memory behind bridge: None
??? Prefetchable memory behind bridge: None
??? Capabilities: [40] Power Management version 3
??? Capabilities: [48] MSI: Enable- Count=1/4 Maskable+ 64bit+
??? Capabilities: [68] Express Downstream Port (Slot+), MSI 00
??? Capabilities: [a4] Subsystem: PLX Technology, Inc. PEX 8604 4-lane,
4-Port PCI Express Gen 2 (5.0 GT/s) Switch
??? Capabilities: [100] Device Serial Number ba-86-01-10-b5-df-0e-00
??? Capabilities: [fb4] Advanced Error Reporting
??? Capabilities: [148] Virtual Channel
??? Capabilities: [520] Access Control Services
??? Capabilities: [950] Vendor Specific Information: ID=0001 Rev=0
Len=010 <?>
??? Kernel driver in use: pcieport
02:04.0 PCI bridge: PLX Technology, Inc. PEX 8604 4-lane, 4-Port PCI
Express Gen 2 (5.0 GT/s) Switch (rev ba) (prog-if 00 [Normal decode])
??? Flags: bus master, fast devsel, latency 0, IRQ 298
??? Bus: primary=02, secondary=04, subordinate=04, sec-latency=0
??? I/O behind bridge: None
??? Memory behind bridge: None
??? Prefetchable memory behind bridge: None
??? Capabilities: [40] Power Management version 3
??? Capabilities: [48] MSI: Enable- Count=1/4 Maskable+ 64bit+
??? Capabilities: [68] Express Downstream Port (Slot+), MSI 00
??? Capabilities: [a4] Subsystem: PLX Technology, Inc. PEX 8604 4-lane,
4-Port PCI Express Gen 2 (5.0 GT/s) Switch
??? Capabilities: [100] Device Serial Number ba-86-01-10-b5-df-0e-00
??? Capabilities: [fb4] Advanced Error Reporting
??? Capabilities: [148] Virtual Channel
??? Capabilities: [520] Access Control Services
??? Capabilities: [950] Vendor Specific Information: ID=0001 Rev=0
Len=010 <?>
??? Kernel driver in use: pcieport
02:05.0 PCI bridge: PLX Technology, Inc. PEX 8604 4-lane, 4-Port PCI
Express Gen 2 (5.0 GT/s) Switch (rev ba) (prog-if 00 [Normal decode])
??? Flags: bus master, fast devsel, latency 0, IRQ 299
??? Bus: primary=02, secondary=05, subordinate=05, sec-latency=0
??? I/O behind bridge: None
??? Memory behind bridge: 01100000-011fffff [size=1M]
??? Prefetchable memory behind bridge: None
??? Capabilities: [40] Power Management version 3
??? Capabilities: [48] MSI: Enable- Count=1/4 Maskable+ 64bit+
??? Capabilities: [68] Express Downstream Port (Slot+), MSI 00
??? Capabilities: [a4] Subsystem: PLX Technology, Inc. PEX 8604 4-lane,
4-Port PCI Express Gen 2 (5.0 GT/s) Switch
??? Capabilities: [100] Device Serial Number ba-86-01-10-b5-df-0e-00
??? Capabilities: [fb4] Advanced Error Reporting
??? Capabilities: [148] Virtual Channel
??? Capabilities: [520] Access Control Services
??? Capabilities: [950] Vendor Specific Information: ID=0001 Rev=0
Len=010 <?>
??? Kernel driver in use: pcieport
05:00.0 Network controller: Qualcomm Atheros AR958x 802.11abgn Wireless
Network Adapter (rev 01)
??? Subsystem: Device 19b6:d016
??? Flags: bus master, fast devsel, latency 0, IRQ 299
??? Memory at 01100000 (64-bit, non-prefetchable) [size=128K]
??? [virtual] Expansion ROM at 01120000 [disabled] [size=64K]
??? Capabilities: [40] Power Management version 3
??? Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
??? Capabilities: [70] Express Endpoint, MSI 00
??? Capabilities: [100] Advanced Error Reporting
??? Capabilities: [140] Virtual Channel
??? Capabilities: [300] Device Serial Number 00-00-00-00-00-00-00-00
??? Kernel driver in use: ath9k
^ permalink raw reply
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