* [PATCH v3 00/18] FSI device driver introduction
From: Greg KH @ 2017-01-19 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAA0LjjVAJiF8yF8prE22Uz18A+EWnNAPis+4LydGRK2BVp6NSg@mail.gmail.com>
On Tue, Jan 17, 2017 at 04:00:41PM -0600, Christopher Bostic wrote:
> On Tue, Jan 17, 2017 at 1:42 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Mon, Jan 16, 2017 at 03:22:48PM -0600, christopher.lee.bostic at gmail.com wrote:
> >> From: Chris Bostic <cbostic@us.ibm.com>
> >
> > <snip>
> >
> > Only this, and patch 02/18 came through, did something get stuck on your
> > end?
> >
>
> Hi Greg,
>
> Yes had an issue with the server blocking send, investigating why.
It's still failing, I keep getting only the 00 email :(
^ permalink raw reply
* [PATCH 4/4] ARM: dts: imx7: Add "LPSR" to LPSR iomux pin names
From: Sascha Hauer @ 2017-01-19 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170119090924.19636-1-s.hauer@pengutronix.de>
The i.MX7 has two iomux controllers. the iomuxc and the iomuxc_lpsr.
In a board dts we have to make sure that both controllers are supplied
with the correct pins. It's way too easy to do this wrong since only
a look into the reference manual can reveal which pins belong to which
controller. To make this clearer add "LPSR" to the pin names which
belong to the LPSR controller.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/boot/dts/imx7-colibri.dtsi | 16 ++---
arch/arm/boot/dts/imx7d-cl-som-imx7.dts | 2 +-
arch/arm/boot/dts/imx7d-nitrogen7.dts | 14 ++--
arch/arm/boot/dts/imx7d-pinfunc.h | 110 ++++++++++++++++----------------
arch/arm/boot/dts/imx7d-sdb.dts | 4 +-
arch/arm/boot/dts/imx7s-warp.dts | 2 +-
6 files changed, 74 insertions(+), 74 deletions(-)
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index a9cc65725f19..a171545478be 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -596,29 +596,29 @@
pinctrl_gpio_lpsr: gpio1-grp {
fsl,pins = <
- MX7D_PAD_GPIO1_IO01__GPIO1_IO1 0x59
- MX7D_PAD_GPIO1_IO02__GPIO1_IO2 0x59
- MX7D_PAD_GPIO1_IO03__GPIO1_IO3 0x59
+ MX7D_PAD_LPSR_GPIO1_IO01__GPIO1_IO1 0x59
+ MX7D_PAD_LPSR_GPIO1_IO02__GPIO1_IO2 0x59
+ MX7D_PAD_LPSR_GPIO1_IO03__GPIO1_IO3 0x59
>;
};
pinctrl_i2c1: i2c1-grp {
fsl,pins = <
- MX7D_PAD_GPIO1_IO05__I2C1_SDA 0x4000007f
- MX7D_PAD_GPIO1_IO04__I2C1_SCL 0x4000007f
+ MX7D_PAD_LPSR_GPIO1_IO05__I2C1_SDA 0x4000007f
+ MX7D_PAD_LPSR_GPIO1_IO04__I2C1_SCL 0x4000007f
>;
};
pinctrl_cd_usdhc1: usdhc1-cd-grp {
fsl,pins = <
- MX7D_PAD_GPIO1_IO00__GPIO1_IO0 0x59 /* CD */
+ MX7D_PAD_LPSR_GPIO1_IO00__GPIO1_IO0 0x59 /* CD */
>;
};
pinctrl_uart1_ctrl2: uart1-ctrl2-grp {
fsl,pins = <
- MX7D_PAD_GPIO1_IO07__GPIO1_IO7 0x14 /* DSR */
- MX7D_PAD_GPIO1_IO06__GPIO1_IO6 0x14 /* RI */
+ MX7D_PAD_LPSR_GPIO1_IO07__GPIO1_IO7 0x14 /* DSR */
+ MX7D_PAD_LPSR_GPIO1_IO06__GPIO1_IO6 0x14 /* RI */
>;
};
};
diff --git a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
index 1135bc99b3e7..ae45af1ad062 100644
--- a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
+++ b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
@@ -281,7 +281,7 @@
&iomuxc_lpsr {
pinctrl_usbotg1: usbotg1grp {
fsl,pins = <
- MX7D_PAD_GPIO1_IO05__GPIO1_IO5 0x14 /* OTG PWREN */
+ MX7D_PAD_LPSR_GPIO1_IO05__GPIO1_IO5 0x14 /* OTG PWREN */
>;
};
};
\ No newline at end of file
diff --git a/arch/arm/boot/dts/imx7d-nitrogen7.dts b/arch/arm/boot/dts/imx7d-nitrogen7.dts
index ce08f180f213..5d98e2b5d54b 100644
--- a/arch/arm/boot/dts/imx7d-nitrogen7.dts
+++ b/arch/arm/boot/dts/imx7d-nitrogen7.dts
@@ -712,33 +712,33 @@
pinctrl_hog_2: hoggrp-2 {
fsl,pins = <
- MX7D_PAD_GPIO1_IO02__GPIO1_IO2 0x7d
- MX7D_PAD_GPIO1_IO03__CCM_CLKO2 0x7d
+ MX7D_PAD_LPSR_GPIO1_IO02__GPIO1_IO2 0x7d
+ MX7D_PAD_LPSR_GPIO1_IO03__CCM_CLKO2 0x7d
>;
};
pinctrl_backlight_j9: backlightj9grp {
fsl,pins = <
- MX7D_PAD_GPIO1_IO07__GPIO1_IO7 0x7d
+ MX7D_PAD_LPSR_GPIO1_IO07__GPIO1_IO7 0x7d
>;
};
pinctrl_pwm1: pwm1grp {
fsl,pins = <
- MX7D_PAD_GPIO1_IO01__PWM1_OUT 0x7d
+ MX7D_PAD_LPSR_GPIO1_IO01__PWM1_OUT 0x7d
>;
};
pinctrl_usbotg1: usbotg1grp {
fsl,pins = <
- MX7D_PAD_GPIO1_IO04__USB_OTG1_OC 0x7d
- MX7D_PAD_GPIO1_IO05__GPIO1_IO5 0x14
+ MX7D_PAD_LPSR_GPIO1_IO04__USB_OTG1_OC 0x7d
+ MX7D_PAD_LPSR_GPIO1_IO05__GPIO1_IO5 0x14
>;
};
pinctrl_wdog1: wdog1grp {
fsl,pins = <
- MX7D_PAD_GPIO1_IO00__WDOD1_WDOG_B 0x75
+ MX7D_PAD_LPSR_GPIO1_IO00__WDOD1_WDOG_B 0x75
>;
};
};
diff --git a/arch/arm/boot/dts/imx7d-pinfunc.h b/arch/arm/boot/dts/imx7d-pinfunc.h
index 7bc3c00e56c6..f6f7e78f8820 100644
--- a/arch/arm/boot/dts/imx7d-pinfunc.h
+++ b/arch/arm/boot/dts/imx7d-pinfunc.h
@@ -15,61 +15,61 @@
* <mux_reg conf_reg input_reg mux_mode input_val>
*/
-#define MX7D_PAD_GPIO1_IO00__GPIO1_IO0 0x0000 0x0030 0x0000 0x0 0x0
-#define MX7D_PAD_GPIO1_IO00__PWM4_OUT 0x0000 0x0030 0x0000 0x1 0x0
-#define MX7D_PAD_GPIO1_IO00__WDOD1_WDOG_ANY 0x0000 0x0030 0x0000 0x2 0x0
-#define MX7D_PAD_GPIO1_IO00__WDOD1_WDOG_B 0x0000 0x0030 0x0000 0x3 0x0
-#define MX7D_PAD_GPIO1_IO00__WDOD1_WDOG__RST_B_DEB 0x0000 0x0030 0x0000 0x4 0x0
-#define MX7D_PAD_GPIO1_IO01__GPIO1_IO1 0x0004 0x0034 0x0000 0x0 0x0
-#define MX7D_PAD_GPIO1_IO01__PWM1_OUT 0x0004 0x0034 0x0000 0x1 0x0
-#define MX7D_PAD_GPIO1_IO01__CCM_ENET_REF_CLK3 0x0004 0x0034 0x0000 0x2 0x0
-#define MX7D_PAD_GPIO1_IO01__SAI1_MCLK 0x0004 0x0034 0x0000 0x3 0x0
-#define MX7D_PAD_GPIO1_IO01__ANATOP_24M_OUT 0x0004 0x0034 0x0000 0x4 0x0
-#define MX7D_PAD_GPIO1_IO01__OBSERVE0_OUT 0x0004 0x0034 0x0000 0x6 0x0
-#define MX7D_PAD_GPIO1_IO02__GPIO1_IO2 0x0008 0x0038 0x0000 0x0 0x0
-#define MX7D_PAD_GPIO1_IO02__PWM2_OUT 0x0008 0x0038 0x0000 0x1 0x0
-#define MX7D_PAD_GPIO1_IO02__CCM_ENET_REF_CLK1 0x0008 0x0038 0x0564 0x2 0x3
-#define MX7D_PAD_GPIO1_IO02__SAI2_MCLK 0x0008 0x0038 0x0000 0x3 0x0
-#define MX7D_PAD_GPIO1_IO02__CCM_CLKO1 0x0008 0x0038 0x0000 0x5 0x0
-#define MX7D_PAD_GPIO1_IO02__OBSERVE1_OUT 0x0008 0x0038 0x0000 0x6 0x0
-#define MX7D_PAD_GPIO1_IO02__USB_OTG1_ID 0x0008 0x0038 0x0734 0x7 0x3
-#define MX7D_PAD_GPIO1_IO03__GPIO1_IO3 0x000C 0x003C 0x0000 0x0 0x0
-#define MX7D_PAD_GPIO1_IO03__PWM3_OUT 0x000C 0x003C 0x0000 0x1 0x0
-#define MX7D_PAD_GPIO1_IO03__CCM_ENET_REF_CLK2 0x000C 0x003C 0x0570 0x2 0x3
-#define MX7D_PAD_GPIO1_IO03__SAI3_MCLK 0x000C 0x003C 0x0000 0x3 0x0
-#define MX7D_PAD_GPIO1_IO03__CCM_CLKO2 0x000C 0x003C 0x0000 0x5 0x0
-#define MX7D_PAD_GPIO1_IO03__OBSERVE2_OUT 0x000C 0x003C 0x0000 0x6 0x0
-#define MX7D_PAD_GPIO1_IO03__USB_OTG2_ID 0x000C 0x003C 0x0730 0x7 0x3
-#define MX7D_PAD_GPIO1_IO04__GPIO1_IO4 0x0010 0x0040 0x0000 0x0 0x0
-#define MX7D_PAD_GPIO1_IO04__USB_OTG1_OC 0x0010 0x0040 0x072C 0x1 0x1
-#define MX7D_PAD_GPIO1_IO04__FLEXTIMER1_CH4 0x0010 0x0040 0x0594 0x2 0x1
-#define MX7D_PAD_GPIO1_IO04__UART5_DCE_CTS 0x0010 0x0040 0x0000 0x3 0x0
-#define MX7D_PAD_GPIO1_IO04__UART5_DTE_RTS 0x0010 0x0040 0x0710 0x3 0x4
-#define MX7D_PAD_GPIO1_IO04__I2C1_SCL 0x0010 0x0040 0x05D4 0x4 0x2
-#define MX7D_PAD_GPIO1_IO04__OBSERVE3_OUT 0x0010 0x0040 0x0000 0x6 0x0
-#define MX7D_PAD_GPIO1_IO05__GPIO1_IO5 0x0014 0x0044 0x0000 0x0 0x0
-#define MX7D_PAD_GPIO1_IO05__USB_OTG1_PWR 0x0014 0x0044 0x0000 0x1 0x0
-#define MX7D_PAD_GPIO1_IO05__FLEXTIMER1_CH5 0x0014 0x0044 0x0598 0x2 0x1
-#define MX7D_PAD_GPIO1_IO05__UART5_DCE_RTS 0x0014 0x0044 0x0710 0x3 0x5
-#define MX7D_PAD_GPIO1_IO05__UART5_DTE_CTS 0x0014 0x0044 0x0000 0x3 0x0
-#define MX7D_PAD_GPIO1_IO05__I2C1_SDA 0x0014 0x0044 0x05D8 0x4 0x2
-#define MX7D_PAD_GPIO1_IO05__OBSERVE4_OUT 0x0014 0x0044 0x0000 0x6 0x0
-#define MX7D_PAD_GPIO1_IO06__GPIO1_IO6 0x0018 0x0048 0x0000 0x0 0x0
-#define MX7D_PAD_GPIO1_IO06__USB_OTG2_OC 0x0018 0x0048 0x0728 0x1 0x1
-#define MX7D_PAD_GPIO1_IO06__FLEXTIMER1_CH6 0x0018 0x0048 0x059C 0x2 0x1
-#define MX7D_PAD_GPIO1_IO06__UART5_DCE_RX 0x0018 0x0048 0x0714 0x3 0x4
-#define MX7D_PAD_GPIO1_IO06__UART5_DTE_TX 0x0018 0x0048 0x0000 0x3 0x0
-#define MX7D_PAD_GPIO1_IO06__I2C2_SCL 0x0018 0x0048 0x05DC 0x4 0x2
-#define MX7D_PAD_GPIO1_IO06__CCM_WAIT 0x0018 0x0048 0x0000 0x5 0x0
-#define MX7D_PAD_GPIO1_IO06__KPP_ROW4 0x0018 0x0048 0x0624 0x6 0x1
-#define MX7D_PAD_GPIO1_IO07__GPIO1_IO7 0x001C 0x004C 0x0000 0x0 0x0
-#define MX7D_PAD_GPIO1_IO07__USB_OTG2_PWR 0x001C 0x004C 0x0000 0x1 0x0
-#define MX7D_PAD_GPIO1_IO07__FLEXTIMER1_CH7 0x001C 0x004C 0x05A0 0x2 0x1
-#define MX7D_PAD_GPIO1_IO07__UART5_DCE_TX 0x001C 0x004C 0x0000 0x3 0x0
-#define MX7D_PAD_GPIO1_IO07__UART5_DTE_RX 0x001C 0x004C 0x0714 0x3 0x5
-#define MX7D_PAD_GPIO1_IO07__I2C2_SDA 0x001C 0x004C 0x05E0 0x4 0x2
-#define MX7D_PAD_GPIO1_IO07__CCM_STOP 0x001C 0x004C 0x0000 0x5 0x0
-#define MX7D_PAD_GPIO1_IO07__KPP_COL4 0x001C 0x004C 0x0604 0x6 0x1
+#define MX7D_PAD_LPSR_GPIO1_IO00__GPIO1_IO0 0x0000 0x0030 0x0000 0x0 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO00__PWM4_OUT 0x0000 0x0030 0x0000 0x1 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO00__WDOD1_WDOG_ANY 0x0000 0x0030 0x0000 0x2 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO00__WDOD1_WDOG_B 0x0000 0x0030 0x0000 0x3 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO00__WDOD1_WDOG__RST_B_DEB 0x0000 0x0030 0x0000 0x4 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO01__GPIO1_IO1 0x0004 0x0034 0x0000 0x0 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO01__PWM1_OUT 0x0004 0x0034 0x0000 0x1 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO01__CCM_ENET_REF_CLK3 0x0004 0x0034 0x0000 0x2 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO01__SAI1_MCLK 0x0004 0x0034 0x0000 0x3 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO01__ANATOP_24M_OUT 0x0004 0x0034 0x0000 0x4 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO01__OBSERVE0_OUT 0x0004 0x0034 0x0000 0x6 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO02__GPIO1_IO2 0x0008 0x0038 0x0000 0x0 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO02__PWM2_OUT 0x0008 0x0038 0x0000 0x1 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO02__CCM_ENET_REF_CLK1 0x0008 0x0038 0x0564 0x2 0x3
+#define MX7D_PAD_LPSR_GPIO1_IO02__SAI2_MCLK 0x0008 0x0038 0x0000 0x3 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO02__CCM_CLKO1 0x0008 0x0038 0x0000 0x5 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO02__OBSERVE1_OUT 0x0008 0x0038 0x0000 0x6 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO02__USB_OTG1_ID 0x0008 0x0038 0x0734 0x7 0x3
+#define MX7D_PAD_LPSR_GPIO1_IO03__GPIO1_IO3 0x000C 0x003C 0x0000 0x0 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO03__PWM3_OUT 0x000C 0x003C 0x0000 0x1 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO03__CCM_ENET_REF_CLK2 0x000C 0x003C 0x0570 0x2 0x3
+#define MX7D_PAD_LPSR_GPIO1_IO03__SAI3_MCLK 0x000C 0x003C 0x0000 0x3 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO03__CCM_CLKO2 0x000C 0x003C 0x0000 0x5 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO03__OBSERVE2_OUT 0x000C 0x003C 0x0000 0x6 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO03__USB_OTG2_ID 0x000C 0x003C 0x0730 0x7 0x3
+#define MX7D_PAD_LPSR_GPIO1_IO04__GPIO1_IO4 0x0010 0x0040 0x0000 0x0 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO04__USB_OTG1_OC 0x0010 0x0040 0x072C 0x1 0x1
+#define MX7D_PAD_LPSR_GPIO1_IO04__FLEXTIMER1_CH4 0x0010 0x0040 0x0594 0x2 0x1
+#define MX7D_PAD_LPSR_GPIO1_IO04__UART5_DCE_CTS 0x0010 0x0040 0x0000 0x3 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO04__UART5_DTE_RTS 0x0010 0x0040 0x0710 0x3 0x4
+#define MX7D_PAD_LPSR_GPIO1_IO04__I2C1_SCL 0x0010 0x0040 0x05D4 0x4 0x2
+#define MX7D_PAD_LPSR_GPIO1_IO04__OBSERVE3_OUT 0x0010 0x0040 0x0000 0x6 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO05__GPIO1_IO5 0x0014 0x0044 0x0000 0x0 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO05__USB_OTG1_PWR 0x0014 0x0044 0x0000 0x1 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO05__FLEXTIMER1_CH5 0x0014 0x0044 0x0598 0x2 0x1
+#define MX7D_PAD_LPSR_GPIO1_IO05__UART5_DCE_RTS 0x0014 0x0044 0x0710 0x3 0x5
+#define MX7D_PAD_LPSR_GPIO1_IO05__UART5_DTE_CTS 0x0014 0x0044 0x0000 0x3 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO05__I2C1_SDA 0x0014 0x0044 0x05D8 0x4 0x2
+#define MX7D_PAD_LPSR_GPIO1_IO05__OBSERVE4_OUT 0x0014 0x0044 0x0000 0x6 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO06__GPIO1_IO6 0x0018 0x0048 0x0000 0x0 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO06__USB_OTG2_OC 0x0018 0x0048 0x0728 0x1 0x1
+#define MX7D_PAD_LPSR_GPIO1_IO06__FLEXTIMER1_CH6 0x0018 0x0048 0x059C 0x2 0x1
+#define MX7D_PAD_LPSR_GPIO1_IO06__UART5_DCE_RX 0x0018 0x0048 0x0714 0x3 0x4
+#define MX7D_PAD_LPSR_GPIO1_IO06__UART5_DTE_TX 0x0018 0x0048 0x0000 0x3 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO06__I2C2_SCL 0x0018 0x0048 0x05DC 0x4 0x2
+#define MX7D_PAD_LPSR_GPIO1_IO06__CCM_WAIT 0x0018 0x0048 0x0000 0x5 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO06__KPP_ROW4 0x0018 0x0048 0x0624 0x6 0x1
+#define MX7D_PAD_LPSR_GPIO1_IO07__GPIO1_IO7 0x001C 0x004C 0x0000 0x0 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO07__USB_OTG2_PWR 0x001C 0x004C 0x0000 0x1 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO07__FLEXTIMER1_CH7 0x001C 0x004C 0x05A0 0x2 0x1
+#define MX7D_PAD_LPSR_GPIO1_IO07__UART5_DCE_TX 0x001C 0x004C 0x0000 0x3 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO07__UART5_DTE_RX 0x001C 0x004C 0x0714 0x3 0x5
+#define MX7D_PAD_LPSR_GPIO1_IO07__I2C2_SDA 0x001C 0x004C 0x05E0 0x4 0x2
+#define MX7D_PAD_LPSR_GPIO1_IO07__CCM_STOP 0x001C 0x004C 0x0000 0x5 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO07__KPP_COL4 0x001C 0x004C 0x0604 0x6 0x1
#define MX7D_PAD_GPIO1_IO08__GPIO1_IO8 0x0014 0x026C 0x0000 0x0 0x0
#define MX7D_PAD_GPIO1_IO08__SD1_VSELECT 0x0014 0x026C 0x0000 0x1 0x0
#define MX7D_PAD_GPIO1_IO08__WDOG1_WDOG_B 0x0014 0x026C 0x0000 0x2 0x0
diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
index 84f35a6cbb30..2afe48439948 100644
--- a/arch/arm/boot/dts/imx7d-sdb.dts
+++ b/arch/arm/boot/dts/imx7d-sdb.dts
@@ -635,13 +635,13 @@
&iomuxc_lpsr {
pinctrl_wdog: wdoggrp {
fsl,pins = <
- MX7D_PAD_GPIO1_IO00__WDOD1_WDOG_B 0x74
+ MX7D_PAD_LPSR_GPIO1_IO00__WDOD1_WDOG_B 0x74
>;
};
pinctrl_pwm1: pwm1grp {
fsl,pins = <
- MX7D_PAD_GPIO1_IO01__PWM1_OUT 0x110b0
+ MX7D_PAD_LPSR_GPIO1_IO01__PWM1_OUT 0x110b0
>;
};
};
\ No newline at end of file
diff --git a/arch/arm/boot/dts/imx7s-warp.dts b/arch/arm/boot/dts/imx7s-warp.dts
index cbb5bc16e713..d5237fd0fa65 100644
--- a/arch/arm/boot/dts/imx7s-warp.dts
+++ b/arch/arm/boot/dts/imx7s-warp.dts
@@ -442,7 +442,7 @@
&iomuxc_lpsr {
pinctrl_wdog: wdoggrp {
fsl,pins = <
- MX7D_PAD_GPIO1_IO00__WDOD1_WDOG_B 0x74
+ MX7D_PAD_LPSR_GPIO1_IO00__WDOD1_WDOG_B 0x74
>;
};
};
--
2.11.0
^ permalink raw reply related
* [PATCH 3/4] ARM: dts: imx7d-cl-som: Fix OTG power pinctrl
From: Sascha Hauer @ 2017-01-19 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170119090924.19636-1-s.hauer@pengutronix.de>
GPIO01_IO05 is controlled by the LPSR iomux controller, so attach
the corresponding pin to this controller.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/boot/dts/imx7d-cl-som-imx7.dts | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
index 58b09bf1ba2d..1135bc99b3e7 100644
--- a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
+++ b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
@@ -261,12 +261,6 @@
>;
};
- pinctrl_usbotg1: usbotg1grp {
- fsl,pins = <
- MX7D_PAD_GPIO1_IO05__GPIO1_IO5 0x14 /* OTG PWREN */
- >;
- };
-
pinctrl_usdhc3: usdhc3grp {
fsl,pins = <
MX7D_PAD_SD3_CMD__SD3_CMD 0x59
@@ -283,3 +277,11 @@
>;
};
};
+
+&iomuxc_lpsr {
+ pinctrl_usbotg1: usbotg1grp {
+ fsl,pins = <
+ MX7D_PAD_GPIO1_IO05__GPIO1_IO5 0x14 /* OTG PWREN */
+ >;
+ };
+};
\ No newline at end of file
--
2.11.0
^ permalink raw reply related
* [PATCH 2/4] ARM: dts: imx7d-sdp: Fix watchdog and pwm pinmux
From: Sascha Hauer @ 2017-01-19 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170119090924.19636-1-s.hauer@pengutronix.de>
The watchdog pin and the pwm output pin are controlled by the
iomuxc_lpsr, not the regular iomux, so move the pins there.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/boot/dts/imx7d-sdb.dts | 26 ++++++++++++++------------
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
index 2f33c463cbce..84f35a6cbb30 100644
--- a/arch/arm/boot/dts/imx7d-sdb.dts
+++ b/arch/arm/boot/dts/imx7d-sdb.dts
@@ -502,12 +502,6 @@
>;
};
- pinctrl_pwm1: pwm1grp {
- fsl,pins = <
- MX7D_PAD_GPIO1_IO01__PWM1_OUT 0x110b0
- >;
- };
-
pinctrl_tsc2046_pendown: tsc2046_pendown {
fsl,pins = <
MX7D_PAD_EPDC_BDR1__GPIO2_IO29 0x59
@@ -635,11 +629,19 @@
MX7D_PAD_SD3_STROBE__SD3_STROBE 0x1b
>;
};
-
- pinctrl_wdog: wdoggrp {
- fsl,pins = <
- MX7D_PAD_GPIO1_IO00__WDOD1_WDOG_B 0x74
- >;
- };
};
};
+
+&iomuxc_lpsr {
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <
+ MX7D_PAD_GPIO1_IO00__WDOD1_WDOG_B 0x74
+ >;
+ };
+
+ pinctrl_pwm1: pwm1grp {
+ fsl,pins = <
+ MX7D_PAD_GPIO1_IO01__PWM1_OUT 0x110b0
+ >;
+ };
+};
\ No newline at end of file
--
2.11.0
^ permalink raw reply related
* [PATCH 1/4] ARM: dts: imx7s-warp: Fix watchdog pinmux
From: Sascha Hauer @ 2017-01-19 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170119090924.19636-1-s.hauer@pengutronix.de>
The watchdog pin is controlled by the iomuxc_lpsr, not the regular
iomux, so move it there.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/boot/dts/imx7s-warp.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/imx7s-warp.dts b/arch/arm/boot/dts/imx7s-warp.dts
index 0345267f3390..cbb5bc16e713 100644
--- a/arch/arm/boot/dts/imx7s-warp.dts
+++ b/arch/arm/boot/dts/imx7s-warp.dts
@@ -437,7 +437,9 @@
MX7D_PAD_SD3_RESET_B__SD3_RESET_B 0x1b
>;
};
+};
+&iomuxc_lpsr {
pinctrl_wdog: wdoggrp {
fsl,pins = <
MX7D_PAD_GPIO1_IO00__WDOD1_WDOG_B 0x74
--
2.11.0
^ permalink raw reply related
* ARM: i.MX7: Fix LPSR specific iomux pins
From: Sascha Hauer @ 2017-01-19 9:09 UTC (permalink / raw)
To: linux-arm-kernel
The i.MX7 has two iomux controllers. the iomuxc and the iomuxc_lpsr.
Some pinmux settings in the board dts files are non functional because
they are attached to the wrong iomux controller. The following patches
fix this.
It's way too easy to fall into this trap again. Only a look into the
reference manual can reveal which pin belongs to which controller.
To make this clearer the last patch adds "LPSR" to the pin names
which belong to the LPSR controller.
Sascha
----------------------------------------------------------------
Sascha Hauer (4):
ARM: dts: imx7s-warp: Fix watchdog pinmux
ARM: dts: imx7d-sdp: Fix watchdog and pwm pinmux
ARM: dts: imx7d-cl-som: Fix OTG power pinctrl
ARM: dts: imx7: Add "LPSR" to LPSR iomux pin names
arch/arm/boot/dts/imx7-colibri.dtsi | 16 ++---
arch/arm/boot/dts/imx7d-cl-som-imx7.dts | 14 ++--
arch/arm/boot/dts/imx7d-nitrogen7.dts | 14 ++--
arch/arm/boot/dts/imx7d-pinfunc.h | 110 ++++++++++++++++----------------
arch/arm/boot/dts/imx7d-sdb.dts | 26 ++++----
arch/arm/boot/dts/imx7s-warp.dts | 4 +-
6 files changed, 95 insertions(+), 89 deletions(-)
^ permalink raw reply
* [PATCH v8 4/8] PWM: add PWM driver for STM32 plaftorm
From: Thierry Reding @ 2017-01-19 9:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484749251-14445-5-git-send-email-benjamin.gaignard@st.com>
On Wed, Jan 18, 2017 at 03:20:47PM +0100, Benjamin Gaignard wrote:
> This driver adds support for PWM driver on STM32 platform.
> The SoC have multiple instances of the hardware IP and each
> of them could have small differences: number of channels,
> complementary output, auto reload register size...
>
> version 8:
> - fix comments done by Thierry on version 7
>
> version 6:
> - change st,breakinput parameter to make it usuable for stm32f7 too.
>
> version 4:
> - detect at probe time hardware capabilities
> - fix comments done on v2 and v3
> - use PWM atomic ops
>
> version 2:
> - only keep one comptatible
> - use DT parameters to discover hardware block configuration
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> drivers/pwm/Kconfig | 9 ++
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-stm32.c | 398 ++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 408 insertions(+)
> create mode 100644 drivers/pwm/pwm-stm32.c
Similar nit than for 3/8. The canonical prefix for PWM subsystem patches
is "pwm: ". One other thing that I had missed earlier...
> +MODULE_ALIAS("platform: stm32-pwm");
I don't think there should be a space after ':'.
With those two fixed:
Acked-by: Thierry Reding <treding@nvidia.com>
-------------- 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/20170119/886f7f40/attachment-0001.sig>
^ permalink raw reply
* [PATCH] ARM: OMAP5: Add HWMOD_SWSUP_SIDLE_ACT flag for UART
From: Lokesh Vutla @ 2017-01-19 9:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118114807.9543-1-vigneshr@ti.com>
On Wednesday 18 January 2017 05:18 PM, Vignesh R wrote:
> According to the commit ca43ea345de9 ("ARM: OMAP2+: hwmod: Add a new
> flag to handle SIDLE in SWSUP only in active"), UART IP needs the sidle
> mode to be controlled in SW only while they are active. Once inactive,
> the IP needs to be put back in HW control so they are also wakeup
> capable. The flag HWMOD_SWSUP_SIDLE takes care of this. So add this flag
> to all instances of UART.
>
> With this change, 8250 UART now gives out proper RX Timeout interrupts
> and is usable as console.
>
> Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Thanks and regards,
Lokesh
^ permalink raw reply
* [PATCH v8 3/8] PWM: add pwm-stm32 DT bindings
From: Thierry Reding @ 2017-01-19 9:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484749251-14445-4-git-send-email-benjamin.gaignard@st.com>
On Wed, Jan 18, 2017 at 03:20:46PM +0100, Benjamin Gaignard wrote:
> Define bindings for pwm-stm32
>
> version 8:
> - reword st,breakinput description.
>
> version 6:
> - change st,breakinput parameter format to make it usuable on stm32f7 too.
>
> version 2:
> - use parameters instead of compatible of handle the hardware configuration
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> .../devicetree/bindings/pwm/pwm-stm32.txt | 35 ++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
One last nit: please use "dt-bindings: pwm:" as prefix for the patch
subject. So it would read something like this:
dt-bindings: pwm: Add STM32 bindings
or similar. That's the style that's been used for a while now. I'd have
fixed that up myself, but since Lee plans to take this through the MFD
tree I'd like to see that fixed up before it gets applied.
With the above:
Acked-by: Thierry Reding <thierry.reding@gmail.com>
-------------- 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/20170119/8a632a2f/attachment.sig>
^ permalink raw reply
* [PATCH v2 3/3] gpio: Support gpio nexus dt bindings
From: Linus Walleij @ 2017-01-19 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118005038.9216-4-stephen.boyd@linaro.org>
On Wed, Jan 18, 2017 at 1:50 AM, Stephen Boyd <stephen.boyd@linaro.org> wrote:
> Platforms like 96boards have a standardized connector/expansion
> slot that exposes signals like GPIOs to expansion boards in an
> SoC agnostic way. We'd like the DT overlays for the expansion
> boards to be written once without knowledge of the SoC on the
> other side of the connector. This avoids the unscalable
> combinatorial explosion of a different DT overlay for each
> expansion board and SoC pair.
>
> Now that we have nexus support in the OF core let's change the
> function call here that parses the phandle lists of gpios to use
> the nexus variant. This allows us to remap phandles and their
> arguments through any number of nexus nodes and end up with the
> actual gpio provider being used.
>
> Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Mark Brown <broonie@kernel.org>
> Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Provided that patches 1 & 2 go in reviewed and merged
by DT/device core people, they can merge this on top as well.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v29 9/9] Documentation: dt: chosen properties for arm64 kdump
From: AKASHI Takahiro @ 2017-01-19 9:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117082629.GA7012@dhcp-128-65.nay.redhat.com>
On Tue, Jan 17, 2017 at 04:26:29PM +0800, Dave Young wrote:
> On 01/16/17 at 05:25pm, AKASHI Takahiro wrote:
> > On Fri, Jan 13, 2017 at 11:17:56AM +0000, Mark Rutland wrote:
> > > On Fri, Jan 13, 2017 at 06:13:49PM +0900, AKASHI Takahiro wrote:
> > > > On Thu, Jan 12, 2017 at 03:39:45PM +0000, Mark Rutland wrote:
> > > > > On Wed, Dec 28, 2016 at 01:37:34PM +0900, AKASHI Takahiro wrote:
> > > > > > +linux,crashkernel-base
> > > > > > +linux,crashkernel-size
> > > > > > +----------------------
> > > > > > +
> > > > > > +These properties (currently used on PowerPC and arm64) indicates
> > > > > > +the base address and the size, respectively, of the reserved memory
> > > > > > +range for crash dump kernel.
> > > > >
> > > > > From this description, it's not clear to me what the (expected)
> > > > > consumers of this property are, nor what is expected to provide it.
> > > > >
> > > > > In previous rounds of review, I had assumed that this was used to
> > > > > describe a preference to the first kernel as to what region of memory
> > > > > should be used for a subsequent kdump kernel. Looking around, I'm not
> > > > > sure if I was correct in that assessment.
> > > > >
> > > > > I see that arch/powerpc seems to consume this property to configure
> > > > > crashk_res, but it also rewrites it based on crashk_res, presumably for
> > > > > the benefit of userspace. It's not clear to me how on powerpc the kdump
> > > > > kernel knows its memory range -- is more DT modification done in the
> > > > > kernel and/or userspace?
> > > >
> > > > I don't believe that powerpc will rewrite the property any way.
> > > > As far as I know from *the source code*, powerpc kernel retrieves
> > > > the memory range for crash dump kernel from a kernel command line, i.e.
> > > > crashkernel=, and then exposes it through DT to userspace (assuming
> > > > kexec-tools).
> > >
> > > The rewriting I describe is in export_crashk_values() in
> > > arch/powerpc/kernel/machine_kexec.c, where the code deletes existing the
> > > properties, and adds new ones, to the DT exposed to userspace.
> > >
> > > So I think we're just quibbling over the definition of "rewrite".
> >
> > Gotcha
> >
> > > > > arm64 we should either ensure that /proc/iomem is consistently usable
> > > > > (and have userspace consistently use it), or we should expose a new file
> > > > > specifically to expose this information.
> > > >
> > > > The thing that I had in my mind when adding this property is that
> > > > /proc/iomem would be obsolete in the future, then we should have
> > > > an alternative in hand.
> > >
> > > Ok.
> > >
> > > My disagreement is with using the DT as a channel to convey information
> > > from the kernel to userspace.
> > >
> > > I'm more than happy for a new file or other mechanism to express this
> > > information. For example, we could add
> > > /sys/kernel/kexec_crash_{base,size} or similar.
> >
> > It may make sense because /sys/kernel/kexec_crash_size already exists,
> > so why not kexec_crash_base?
> > My concern, however, is that this kind of interface might prevent us from
> > allowing multiple regions to be reserved for crash dump kernel in the future.
> > (There is an assumption that we have only one region at least on arm64 though.)
>
> In x86 there could be two ranges, one for softiotlb under 4G and another
> for range over 4G, but kexec_crash_size only shows the size of
> over-4g-range.
>
> It is better to use /proc/iomem, most arches use /proc/iomem. Do you
> have any reason why it will be obsolete? At least for the time being it
> is fine.
I don't know.
I just think that I might have seen that someone said so somewhere
and that more _powerful_ (structured) tool could supersede it :)
-Takahiro AKASHI
> >
> > Thanks,
> > -Takahiro AKASHI
> >
> > >
> > > > > Further, I do not think we need this property. It makes more sense to me
> > > > > for the preference of a a region to be described to the *first* kernel
> > > > > using the command line consistently.
> > > > >
> > > > > So I think we should drop this property, and not use it on arm64. Please
> > > > > document this as powerpc only.
> > > >
> > > > OK, but if we drop the property from arm64 code, we have no reason
> > > > to leave its description in this patch.
> > > > (In fact, there are a few more (undocumented) properties that only ppc
> > > > uses for kdump.)
> > >
> > > I'm happy to drop it, then.
> > >
> > > > > > +linux,usable-memory-range
> > > > > > +-------------------------
> > > > > > +
> > > > > > +This property (currently used only on arm64) holds the memory range,
> > > > > > +the base address and the size, which can be used as system ram on
> > > > > > +the *current* kernel. Note that, if this property is present, any memory
> > > > > > +regions under "memory" nodes in DT blob or ones marked as "conventional
> > > > > > +memory" in EFI memory map should be ignored.
> > > > >
> > > > > Could you please replace this with:
> > > > >
> > > > > This property (arm64 only) holds a base address and size, describing a
> > > > > limited region in which memory may be considered available for use by
> > > > > the kernel. Memory outside of this range is not available for use.
> > > > >
> > > > > This property describes a limitation: memory within this range is only
> > > > > valid when also described through another mechanism that the kernel
> > > > > would otherwise use to determine available memory (e.g. memory nodes
> > > > > or the EFI memory map). Valid memory may be sparse within the range.
> > > >
> > > > Sure.
> > >
> > > Cheers!
> > >
> > > Thanks,
> > > Mark.
> >
> > _______________________________________________
> > kexec mailing list
> > kexec at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* [PATCH v3] IOMMU: SMMUv2: Support for Extended Stream ID (16 bit)
From: Tomasz Nowicki @ 2017-01-19 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117151431.17085-1-aleksey.makarov@linaro.org>
Hi Aleksey,
On 17.01.2017 16:14, Aleksey Makarov wrote:
> Enable the Extended Stream ID feature when available.
>
> This patch on top of series "KVM PCIe/MSI passthrough on ARM/ARM64
> and IOVA reserved regions" by Eric Auger [1] allows to passthrough
> an external PCIe network card on a ThunderX server successfully.
>
> Without this patch that card caused a warning like
>
> pci 0006:90:00.0: stream ID 0x9000 out of range for SMMU (0x7fff)
>
> during boot.
>
> [1] https://lkml.kernel.org/r/1484127714-3263-1-git-send-email-eric.auger at redhat.com
>
> Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
I do not thing this is related to PCIe network card. It is rather common
to all devices which bus number > 127
----
iommu/arm-smmu: Support for Extended Stream ID (16 bit)
It is the time we have the real 16-bit Stream ID user, which is the
ThunderX. Its IO topology uses 1:1 map for requester to stream ID
translation:
RC no. | Requester ID | Stream ID
| |
RC_0 | 0-FFFF ---> | 0-FFFF
which allows to get full 16-bit stream ID. Currently all devices with
bus number >= 128 (0x80) get non-zero 16th bit of BDF and stream ID (due
to 1:1 map). Eventually SMMU drops such device because the stream ID is
out of range. This is the case for all devices connected as external
endpoints on ThunderX.
To fix above issue enable the Extended Stream ID optional feature when
available.
----
Please add my:
Reviewed-by: Tomasz Nowicki <tomasz.nowicki@caviumnetworks.com>
Tested-by: Tomasz Nowicki <tomasz.nowicki@caviumnetworks.com>
Thanks,
Tomasz
> ---
> v3:
> - keep formatting of the comment
> - fix printk message after the deleted chunk. "[Do] not print a mask
> here, since it's not overly interesting in itself, and add_device will
> still show the offending mask in full if it ever actually matters (as in
> the commit message)." (Robin Murphy)
>
> v2:
> https://lkml.kernel.org/r/20170116141111.29444-1-aleksey.makarov at linaro.org
> - remove unnecessary parentheses (Robin Murphy)
> - refactor testing SMR fields to after setting sCR0 as theirs width
> depends on sCR0_EXIDENABLE (Robin Murphy)
>
> v1 (rfc):
> https://lkml.kernel.org/r/20170110115755.19102-1-aleksey.makarov at linaro.org
>
> drivers/iommu/arm-smmu.c | 69 +++++++++++++++++++++++++++++++++---------------
> 1 file changed, 48 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 13d26009b8e0..861cc135722f 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -24,6 +24,7 @@
> * - v7/v8 long-descriptor format
> * - Non-secure access to the SMMU
> * - Context fault reporting
> + * - Extended Stream ID (16 bit)
> */
>
> #define pr_fmt(fmt) "arm-smmu: " fmt
> @@ -87,6 +88,7 @@
> #define sCR0_CLIENTPD (1 << 0)
> #define sCR0_GFRE (1 << 1)
> #define sCR0_GFIE (1 << 2)
> +#define sCR0_EXIDENABLE (1 << 3)
> #define sCR0_GCFGFRE (1 << 4)
> #define sCR0_GCFGFIE (1 << 5)
> #define sCR0_USFCFG (1 << 10)
> @@ -126,6 +128,7 @@
> #define ID0_NUMIRPT_MASK 0xff
> #define ID0_NUMSIDB_SHIFT 9
> #define ID0_NUMSIDB_MASK 0xf
> +#define ID0_EXIDS (1 << 8)
> #define ID0_NUMSMRG_SHIFT 0
> #define ID0_NUMSMRG_MASK 0xff
>
> @@ -169,6 +172,7 @@
> #define ARM_SMMU_GR0_S2CR(n) (0xc00 + ((n) << 2))
> #define S2CR_CBNDX_SHIFT 0
> #define S2CR_CBNDX_MASK 0xff
> +#define S2CR_EXIDVALID (1 << 10)
> #define S2CR_TYPE_SHIFT 16
> #define S2CR_TYPE_MASK 0x3
> enum arm_smmu_s2cr_type {
> @@ -354,6 +358,7 @@ struct arm_smmu_device {
> #define ARM_SMMU_FEAT_FMT_AARCH64_64K (1 << 9)
> #define ARM_SMMU_FEAT_FMT_AARCH32_L (1 << 10)
> #define ARM_SMMU_FEAT_FMT_AARCH32_S (1 << 11)
> +#define ARM_SMMU_FEAT_EXIDS (1 << 12)
> u32 features;
>
> #define ARM_SMMU_OPT_SECURE_CFG_ACCESS (1 << 0)
> @@ -1051,7 +1056,7 @@ static void arm_smmu_write_smr(struct arm_smmu_device *smmu, int idx)
> struct arm_smmu_smr *smr = smmu->smrs + idx;
> u32 reg = smr->id << SMR_ID_SHIFT | smr->mask << SMR_MASK_SHIFT;
>
> - if (smr->valid)
> + if (!(smmu->features & ARM_SMMU_FEAT_EXIDS) && smr->valid)
> reg |= SMR_VALID;
> writel_relaxed(reg, ARM_SMMU_GR0(smmu) + ARM_SMMU_GR0_SMR(idx));
> }
> @@ -1063,6 +1068,9 @@ static void arm_smmu_write_s2cr(struct arm_smmu_device *smmu, int idx)
> (s2cr->cbndx & S2CR_CBNDX_MASK) << S2CR_CBNDX_SHIFT |
> (s2cr->privcfg & S2CR_PRIVCFG_MASK) << S2CR_PRIVCFG_SHIFT;
>
> + if (smmu->features & ARM_SMMU_FEAT_EXIDS && smmu->smrs &&
> + smmu->smrs[idx].valid)
> + reg |= S2CR_EXIDVALID;
> writel_relaxed(reg, ARM_SMMU_GR0(smmu) + ARM_SMMU_GR0_S2CR(idx));
> }
>
> @@ -1073,6 +1081,34 @@ static void arm_smmu_write_sme(struct arm_smmu_device *smmu, int idx)
> arm_smmu_write_smr(smmu, idx);
> }
>
> +/*
> + * The width of SMR's mask field depends on sCR0_EXIDENABLE, so this function
> + * should be called after sCR0 is written.
> + */
> +static void arm_smmu_test_smr_masks(struct arm_smmu_device *smmu)
> +{
> + void __iomem *gr0_base = ARM_SMMU_GR0(smmu);
> + u32 smr;
> +
> + if (!smmu->smrs)
> + return;
> +
> + /*
> + * SMR.ID bits may not be preserved if the corresponding MASK
> + * bits are set, so check each one separately. We can reject
> + * masters later if they try to claim IDs outside these masks.
> + */
> + smr = smmu->streamid_mask << SMR_ID_SHIFT;
> + writel_relaxed(smr, gr0_base + ARM_SMMU_GR0_SMR(0));
> + smr = readl_relaxed(gr0_base + ARM_SMMU_GR0_SMR(0));
> + smmu->streamid_mask = smr >> SMR_ID_SHIFT;
> +
> + smr = smmu->streamid_mask << SMR_MASK_SHIFT;
> + writel_relaxed(smr, gr0_base + ARM_SMMU_GR0_SMR(0));
> + smr = readl_relaxed(gr0_base + ARM_SMMU_GR0_SMR(0));
> + smmu->smr_mask_mask = smr >> SMR_MASK_SHIFT;
> +}
> +
> static int arm_smmu_find_sme(struct arm_smmu_device *smmu, u16 id, u16 mask)
> {
> struct arm_smmu_smr *smrs = smmu->smrs;
> @@ -1674,6 +1710,9 @@ static void arm_smmu_device_reset(struct arm_smmu_device *smmu)
> if (smmu->features & ARM_SMMU_FEAT_VMID16)
> reg |= sCR0_VMID16EN;
>
> + if (smmu->features & ARM_SMMU_FEAT_EXIDS)
> + reg |= sCR0_EXIDENABLE;
> +
> /* Push the button */
> __arm_smmu_tlb_sync(smmu);
> writel(reg, ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sCR0);
> @@ -1761,11 +1800,14 @@ static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
> "\t(IDR0.CTTW overridden by FW configuration)\n");
>
> /* Max. number of entries we have for stream matching/indexing */
> - size = 1 << ((id >> ID0_NUMSIDB_SHIFT) & ID0_NUMSIDB_MASK);
> + if (smmu->version == ARM_SMMU_V2 && id & ID0_EXIDS) {
> + smmu->features |= ARM_SMMU_FEAT_EXIDS;
> + size = 1 << 16;
> + } else {
> + size = 1 << ((id >> ID0_NUMSIDB_SHIFT) & ID0_NUMSIDB_MASK);
> + }
> smmu->streamid_mask = size - 1;
> if (id & ID0_SMS) {
> - u32 smr;
> -
> smmu->features |= ARM_SMMU_FEAT_STREAM_MATCH;
> size = (id >> ID0_NUMSMRG_SHIFT) & ID0_NUMSMRG_MASK;
> if (size == 0) {
> @@ -1774,21 +1816,6 @@ static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
> return -ENODEV;
> }
>
> - /*
> - * SMR.ID bits may not be preserved if the corresponding MASK
> - * bits are set, so check each one separately. We can reject
> - * masters later if they try to claim IDs outside these masks.
> - */
> - smr = smmu->streamid_mask << SMR_ID_SHIFT;
> - writel_relaxed(smr, gr0_base + ARM_SMMU_GR0_SMR(0));
> - smr = readl_relaxed(gr0_base + ARM_SMMU_GR0_SMR(0));
> - smmu->streamid_mask = smr >> SMR_ID_SHIFT;
> -
> - smr = smmu->streamid_mask << SMR_MASK_SHIFT;
> - writel_relaxed(smr, gr0_base + ARM_SMMU_GR0_SMR(0));
> - smr = readl_relaxed(gr0_base + ARM_SMMU_GR0_SMR(0));
> - smmu->smr_mask_mask = smr >> SMR_MASK_SHIFT;
> -
> /* Zero-initialised to mark as invalid */
> smmu->smrs = devm_kcalloc(smmu->dev, size, sizeof(*smmu->smrs),
> GFP_KERNEL);
> @@ -1796,8 +1823,7 @@ static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
> return -ENOMEM;
>
> dev_notice(smmu->dev,
> - "\tstream matching with %lu register groups, mask 0x%x",
> - size, smmu->smr_mask_mask);
> + "\tstream matching with %lu register groups", size);
> }
> /* s2cr->type == 0 means translation, so initialise explicitly */
> smmu->s2crs = devm_kmalloc_array(smmu->dev, size, sizeof(*smmu->s2crs),
> @@ -2120,6 +2146,7 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
> iommu_register_instance(dev->fwnode, &arm_smmu_ops);
> platform_set_drvdata(pdev, smmu);
> arm_smmu_device_reset(smmu);
> + arm_smmu_test_smr_masks(smmu);
>
> /* Oh, for a proper bus abstraction */
> if (!iommu_present(&platform_bus_type))
>
^ permalink raw reply
* [PATCH v8 0/8] Add PWM and IIO timer drivers for STM32
From: Lee Jones @ 2017-01-19 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484749251-14445-1-git-send-email-benjamin.gaignard@st.com>
On Wed, 18 Jan 2017, Benjamin Gaignard wrote:
> version 8:
> - rebase on v4.10-rc4
> - fix comments done by Thierry on PWM
> - reword "reg" parameter description
> - change kernel kernel in IIO ABI documentation
>
> version 7:
> - rebase on v4.10-rc2
> - remove iio_device code from driver and keep only the trigger part
>
> version 6:
> - rename stm32-gptimer in stm32-timers.
> - change "st,stm32-gptimer" compatible to "st,stm32-timers".
> - modify "st,breakinput" parameter in pwm part.
> - split DT patch in 2
>
> version 5:
> - fix comments done on version 4
> - rebased on kernel 4.9-rc8
> - change nodes names and re-order then by addresses
>
> version 4:
> - fix comments done on version 3
> - don't use interrupts anymore in IIO timer
> - detect hardware capabilities at probe time to simplify binding
>
> version 3:
> - no change on mfd and pwm divers patches
> - add cross reference between bindings
> - change compatible to "st,stm32-timer-trigger"
> - fix attributes access rights
> - use string instead of int for master_mode and slave_mode
> - document device attributes in sysfs-bus-iio-timer-stm32
> - update DT with the new compatible
>
> version 2:
> - keep only one compatible per driver
> - use DT parameters to describe hardware block configuration:
> - pwm channels, complementary output, counter size, break input
> - triggers accepted and create by IIO timers
> - change DT to limite use of reference to the node
> - interrupt is now in IIO timer driver
> - rename stm32-mfd-timer to stm32-timers (for general purpose timer)
>
> The following patches enable PWM and IIO Timer features for STM32 platforms.
>
> Those two features are mixed into the registers of the same hardware block
> (named general purpose timer) which lead to introduce a multifunctions driver
> on the top of them to be able to share the registers.
>
> In STM32f4 14 instances of timer hardware block exist, even if they all have
> the same register mapping they could have a different number of pwm channels
> and/or different triggers capabilities. We use various parameters in DT to
> describe the differences between hardware blocks
>
> The MFD (stm32-timers.c) takes care of clock and register mapping
> by using regmap. stm32_timers structure is provided to its sub-node to
> share those information.
>
> PWM driver is implemented into pwm-stm32.c. Depending of the instance we may
> have up to 4 channels, sometime with complementary outputs or 32 bits counter
> instead of 16 bits. Some hardware blocks may also have a break input function
> which allows to stop pwm depending of a level, defined in devicetree, on an
> external pin.
>
> IIO timer driver (stm32-timer-trigger.c and stm32-timer-trigger.h) define a list
> of hardware triggers usable by hardware blocks like ADC, DAC or other timers.
>
> The matrix of possible connections between blocks is quite complex so we use
> trigger names and is_stm32_iio_timer_trigger() function to be sure that
> triggers are valid and configure the IPs.
>
> At run time IIO timer hardware blocks can configure (through "master_mode"
> IIO device attribute) which internal signal (counter enable, reset,
> comparison block, etc...) is used to generate the trigger.
>
> Benjamin Gaignard (8):
> MFD: add bindings for STM32 Timers driver
> MFD: add STM32 Timers driver
> PWM: add pwm-stm32 DT bindings
> PWM: add PWM driver for STM32 plaftorm
> IIO: add bindings for STM32 timer trigger driver
> IIO: add STM32 timer trigger driver
> ARM: dts: stm32: add Timers driver for stm32f429 MCU
> ARM: dts: stm32: Enable pwm1 and pwm3 for stm32f469-disco
>
> .../ABI/testing/sysfs-bus-iio-timer-stm32 | 29 ++
> .../bindings/iio/timer/stm32-timer-trigger.txt | 23 ++
> .../devicetree/bindings/mfd/stm32-timers.txt | 46 +++
> .../devicetree/bindings/pwm/pwm-stm32.txt | 35 ++
> arch/arm/boot/dts/stm32f429.dtsi | 275 ++++++++++++++
> arch/arm/boot/dts/stm32f469-disco.dts | 28 ++
> drivers/iio/trigger/Kconfig | 9 +
> drivers/iio/trigger/Makefile | 1 +
> drivers/iio/trigger/stm32-timer-trigger.c | 342 ++++++++++++++++++
> drivers/mfd/Kconfig | 11 +
> drivers/mfd/Makefile | 2 +
> drivers/mfd/stm32-timers.c | 80 +++++
> drivers/pwm/Kconfig | 9 +
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-stm32.c | 398 +++++++++++++++++++++
> include/linux/iio/timer/stm32-timer-trigger.h | 62 ++++
> include/linux/mfd/stm32-timers.h | 71 ++++
> 17 files changed, 1422 insertions(+)
> create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
> create mode 100644 Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
> create mode 100644 Documentation/devicetree/bindings/mfd/stm32-timers.txt
> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> create mode 100644 drivers/iio/trigger/stm32-timer-trigger.c
> create mode 100644 drivers/mfd/stm32-timers.c
> create mode 100644 drivers/pwm/pwm-stm32.c
> create mode 100644 include/linux/iio/timer/stm32-timer-trigger.h
> create mode 100644 include/linux/mfd/stm32-timers.h
Let me know when you have all your Acks.
I would be happy to take this through the MFD tree.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v9 2/5] i2c: Add STM32F4 I2C driver
From: M'boumba Cedric Madianga @ 2017-01-19 8:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170119080258.fovhfy2v6rrtgwgp@pengutronix.de>
ok fine
2017-01-19 9:02 GMT+01:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> Hello Cedric,
>
> On Wed, Jan 18, 2017 at 09:55:39PM +0100, M'boumba Cedric Madianga wrote:
>> 2017-01-18 19:42 GMT+01:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
>> > Hello Cedric,
>> >
>> > On Wed, Jan 18, 2017 at 04:21:17PM +0100, M'boumba Cedric Madianga wrote:
>> >> >> + * In standard mode, the maximum allowed SCL rise time is 1000 ns.
>> >> >> + * If, in the I2C_CR2 register, the value of FREQ[5:0] bits is equal to
>> >> >> + * 0x08 so period = 125 ns therefore the TRISE[5:0] bits must be
>> >> >> + * programmed with 09h.(1000 ns / 125 ns = 8 + 1)
>> >> >
>> >> > * programmed with 0x9.
>> >> > (1000 ns / 125 ns = 8)
>> >> >
>> >> >> + * So, for I2C standard mode TRISE = FREQ[5:0] + 1
>> >> >> + *
>> >> >> + * In fast mode, the maximum allowed SCL rise time is 300 ns.
>> >> >> + * If, in the I2C_CR2 register, the value of FREQ[5:0] bits is equal to
>> >> >> + * 0x08 so period = 125 ns therefore the TRISE[5:0] bits must be
>> >> >> + * programmed with 03h.(300 ns / 125 ns = 2 + 1)
>> >> >
>> >> > as above s/03h/0x3/;
>> >>
>> >> ok
>> >>
>> >> > s/.(/. (/;
>> >> ok
>> >>
>> >> > s/+ 1//;
>> >> This formula is use to understand how we find the result 0x3
>> >> So, 0x3 => 300 ns / 125ns = 2 + 1
>> >
>> > Yeah, I understood that, but writing 300 ns / 125ns = 2 + 1 is
>> > irritating at best.
>>
>> Ok. I will write 0x3 (300 ns / 125 ns + 1) and 0x9 (1000 ns / 125 ns + 1)
>>
>> >> > [...]
>> >> > If DUTY = 1: (to reach 400 kHz)
>> >> >
>> >> > Strange.
>> >> >
>> >> >> + val = DIV_ROUND_UP(i2c_dev->parent_rate, 400000 * 3);
>> >> >
>> >> > the manual reads:
>> >> >
>> >> > The minimum allowed value is 0x04, except in FAST DUTY mode
>> >> > where the minimum allowed value is 0x01
>> >> >
>> >> > You don't check for that, right?
>> >>
>> >> As the minimum freq value is 6 Mhz in fast mode the minimum CCR is 5
>> >> as described in the comment.
>> >> So I don't need to check that again as it is already done by checking
>> >> parent frequency.
>> >
>> > That would then go into a comment.
>>
>> Is it really needed ?
>> Adding some comments to explain implementation choices or hardware
>> way of working is clearly useful.
>> But for this kind of thing, I am really surprised...
>
> TL;DR: It's not needed, but it probably helps.
>
> Consider someone sees a breakage in your driver in five years. By then
> you either have other interests or at least forgot 95 % of the thoughts
> you had when implementing the driver.
>
> So when I see:
>
> val = DIV_ROUND_UP(i2c_dev->parent_rate, 400000 * 3);
> ccr |= STM32F4_I2C_CCR_CCR(val);
> writel_relaxed(ccr, i2c_dev->base + STM32F4_I2C_CCR);
>
> after seeing that the bus freq is wrong the obvious thoughts are:
>
> - Does this use the right algorithm?
> - Does this calculation result in values that are usable by the
> hardware?
>
> That you thought about this today doesn't mean it's still right in five
> years. During that time a new hardware variant is available with a
> higher parent freq. Or there is a new errata available for the SoC.
>
> So to help answer the questions above it helps if you add today the
> formulas from the manual and a quick reason for why val fits into the
> respective bits in the CCR register. That comment might be wrong until
> then, too, but that only means you should make it easy to verify.
> Something like:
>
> /*
> * Function bla_blub made sure that parent_rate is not higher
> * than 23 * pi MHz. As a result val is at most 13.2 bits wide
> * and so fits into the CCR bits.
> */
>
> This gives you in five years time the opportunity to quickly check
> bla_blub if this is still true, add a printk for parent_rate to check
> this, or quickly identify the bug in the code or the mismatch to the
> manual.
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K. | Uwe Kleine-K?nig |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v20 11/17] clocksource/drivers/arm_arch_timer: Introduce some new structs to prepare for GTDT
From: Hanjun Guo @ 2017-01-19 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118132541.8989-12-fu.wei@linaro.org>
On 2017/1/18 21:25, fu.wei at linaro.org wrote:
> From: Fu Wei <fu.wei@linaro.org>
>
> The patch introduce two new structs: arch_timer_mem, arch_timer_mem_frame.
> And also introduce a new define: ARCH_TIMER_MEM_MAX_FRAMES
>
> These will be used for refactoring the memory-mapped timer init code to
> prepare for GTDT
>
> Signed-off-by: Fu Wei <fu.wei@linaro.org>
> ---
> include/clocksource/arm_arch_timer.h | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h
> index 4a98c06..b7dd185 100644
> --- a/include/clocksource/arm_arch_timer.h
> +++ b/include/clocksource/arm_arch_timer.h
> @@ -57,6 +57,8 @@ enum arch_timer_spi_nr {
> #define ARCH_TIMER_MEM_PHYS_ACCESS 2
> #define ARCH_TIMER_MEM_VIRT_ACCESS 3
>
> +#define ARCH_TIMER_MEM_MAX_FRAMES 8
> +
> #define ARCH_TIMER_USR_PCT_ACCESS_EN (1 << 0) /* physical counter */
> #define ARCH_TIMER_USR_VCT_ACCESS_EN (1 << 1) /* virtual counter */
> #define ARCH_TIMER_VIRT_EVT_EN (1 << 2)
> @@ -72,6 +74,21 @@ struct arch_timer_kvm_info {
> int virtual_irq;
> };
>
> +struct arch_timer_mem_frame {
> + int frame_nr;
> + phys_addr_t cntbase;
> + size_t size;
> + int phys_irq;
> + int virt_irq;
> +};
> +
> +struct arch_timer_mem {
> + phys_addr_t cntctlbase;
> + size_t size;
> + int num_frames;
> + struct arch_timer_mem_frame frame[ARCH_TIMER_MEM_MAX_FRAMES];
> +};
Since struct is introduced but not used in this patch, how about
squash it with patch 12/17?
Thanks
Hanjun
^ permalink raw reply
* [PATCH] ARM64: dts: meson-gxm: Rename q200 and q201 DT files for consistency
From: Neil Armstrong @ 2017-01-19 8:21 UTC (permalink / raw)
To: linux-arm-kernel
In order to keep consistency naming with the Nexbox A1 DTS file, remove the
S912 SoC name in the GXM DT files.
Suggested-by: Andreas F?rber <afaerber@suse.de>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/Makefile | 4 ++--
.../boot/dts/amlogic/{meson-gxm-s912-q200.dts => meson-gxm-q200.dts} | 0
.../boot/dts/amlogic/{meson-gxm-s912-q201.dts => meson-gxm-q201.dts} | 0
3 files changed, 2 insertions(+), 2 deletions(-)
rename arch/arm64/boot/dts/amlogic/{meson-gxm-s912-q200.dts => meson-gxm-q200.dts} (100%)
rename arch/arm64/boot/dts/amlogic/{meson-gxm-s912-q201.dts => meson-gxm-q201.dts} (100%)
Kevin, is this patch format correct for you to apply ?
diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
index 0d7bfbf..1aca8e5 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -9,8 +9,8 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905x-p212.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905d-p230.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905d-p231.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxl-nexbox-a95x.dtb
-dtb-$(CONFIG_ARCH_MESON) += meson-gxm-s912-q200.dtb
-dtb-$(CONFIG_ARCH_MESON) += meson-gxm-s912-q201.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-gxm-q200.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-gxm-q201.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-nexbox-a1.dtb
always := $(dtb-y)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-q200.dts
similarity index 100%
rename from arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts
rename to arch/arm64/boot/dts/amlogic/meson-gxm-q200.dts
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-q201.dts
similarity index 100%
rename from arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts
rename to arch/arm64/boot/dts/amlogic/meson-gxm-q201.dts
--
1.9.1
^ permalink raw reply related
* [PATCH V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp
From: Laurent Pinchart @ 2017-01-19 8:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170119081214.GA29457@collabora.com>
Hi Peter,
On Thursday 19 Jan 2017 09:12:14 Peter Senna Tschudin wrote:
> On Wed, Jan 18, 2017 at 11:10:58PM +0200, Laurent Pinchart wrote:
> > On Monday 16 Jan 2017 09:37:11 Peter Senna Tschudin wrote:
> >> On Tue, Jan 10, 2017 at 11:04:58PM +0200, Laurent Pinchart wrote:
> >>> On Saturday 07 Jan 2017 01:29:52 Peter Senna Tschudin wrote:
> >>>> On 04 January, 2017 21:39 CET, Rob Herring wrote:
> >>>>> On Tue, Jan 3, 2017 at 5:34 PM, Peter Senna Tschudin wrote:
> >>>>>> On 03 January, 2017 23:51 CET, Rob Herring <robh@kernel.org> wrote:
> >>>>>>> On Sun, Jan 01, 2017 at 09:24:29PM +0100, Peter Senna Tschudin
wrote:
> >>>>>>>> Devicetree bindings documentation for the GE B850v3 LVDS/DP++
> >>>>>>>> display bridge.
> >>>>>>>>
> >>>>>>>> Cc: Martyn Welch <martyn.welch@collabora.co.uk>
> >>>>>>>> Cc: Martin Donnelly <martin.donnelly@ge.com>
> >>>>>>>> Cc: Javier Martinez Canillas <javier@dowhile0.org>
> >>>>>>>> Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> >>>>>>>> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> >>>>>>>> Cc: Rob Herring <robh@kernel.org>
> >>>>>>>> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> >>>>>>>> Signed-off-by: Peter Senna Tschudin <peter.senna@collabora.com>
> >>>>>>>> ---
> >>>>>>>> There was an Acked-by from Rob Herring <robh@kernel.org> for V6,
> >>>>>>>> but I changed the bindings to use i2c_new_secondary_device() so I
> >>>>>>>> removed it from the commit message.
>
> [...]
>
> >>>>>>>> .../devicetree/bindings/ge/b850v3-lvds-dp.txt | 39 +++++++++
> >>>>>>>
> >>>>>>> Isn't '-lvds-dp' redundant? The part# should be enough.
> >>>>>>
> >>>>>> b850v3 is the name of the product, this is why the proposed name.
> >>>>>> What about, b850v3-dp2 dp2 indicating the second DP output?
> >>>>>
> >>>>> Humm, b850v3 is the board name? This node should be the name of the
> >>>>> bridge chip.
> >>>>
> >>>> From the cover letter:
> >>>>
> >>>> -- // --
> >>>> There are two physical bridges on the video signal pipeline: a
> >>>> STDP4028(LVDS to DP) and a STDP2690(DP to DP++). The hardware and
> >>>> firmware made it complicated for this binding to comprise two device
> >>>> tree nodes, as the design goal is to configure both bridges based on
> >>>> the LVDS signal, which leave the driver powerless to control the
> >>>> video processing pipeline. The two bridges behaves as a single bridge,
> >>>> and the driver is only needed for telling the host about EDID / HPD,
> >>>> and for giving the host powers to ack interrupts. The video signal
> >>>> pipeline
> >>>>
> >>>> is as follows:
> >>>> Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video
> >>>> output
> >>>>
> >>>> -- // --
> >>>
> >>> You forgot to prefix your patch series with [HACK] ;-)
> >>>
> >>> How about fixing the issues that make the two DT nodes solution
> >>> difficult ? What are they ?
> >>
> >> The Firmware and the hardware design. Both bridges, with stock firmware,
> >> are fully capable of providig EDID information and handling interrupts.
> >> But on this specific design, with this specific firmware, I need to read
> >> EDID from one bridge, and handle interrupts on the other.
> >
> > Which firmware are you talking about ? Firmware running on the bridges, or
> > somewhere else ?
>
> Each bridge has it's own external flash containing a binary firmware.
> The goal of the firmware is to configure the output end based on the
> input end. This is part of what makes handling EDID and HPD challenging.
>
> >> Back when I was starting the development I could not come up with a
> >> proper way to split EDID and interrupts between two bridges in a way
> >> that would result in a fully functional connector. Did I miss something?
> >
> > You didn't, we did :-) I've been telling for quite some time now that we
> > must decouple bridges from connectors, and this is another example of why
> > we have such a need. Bridges should expose additional functions needed to
> > implement connector operations, and the connector should be instantiated
> > by the display driver with the help of bridge operations. You could then
> > create a connector that relies on one bridge to read the EDID and on the
> > other bridge to handle HPD.
>
> Ah thanks. So for now the single DT node approach is acceptable, right?
> The problem is that even if the driver is getting better on each
> iteration, the single DT node for two chips issue comes back often and I
> believe is _the_ issue preventing the driver from getting upstream. V1
> was sent ~ 8 months ago...
>
> Can I have some blessing on the single DT node approach for now?
With the "DT as an ABI" approach, I'm afraid not. Temporary hacks are
acceptable on the driver side, but you need two nodes in DT.
> I'm one of the 3 proposed maintainers for the driver, and I'm willing to
> maintain the driver on the long run, as is the same with the other two
> proposed maintainers. So when the time to split the node in two comes,
> we will be around, and willing to do it ourselves.
How about putting that team of 3 maintainers to work on fixing the problem in
the bridge API ? :-)
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Boris Brezillon @ 2017-01-19 8:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_Jsq+EyHtC7THLCJcwgtVtVESMOdmi3T3bBxgOqJt6BCtCHQ@mail.gmail.com>
Hi Rob,
On Wed, 18 Jan 2017 20:51:08 -0600
Rob Herring <robh@kernel.org> wrote:
> On Wed, Jan 18, 2017 at 5:38 PM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > Hello,
> >
> > On Wed, 18 Jan 2017 16:20:10 -0600, Rob Herring wrote:
> >
> >> > > Rob, Mark, any opinion?
> >> >
> >>
> >> Sigh, is how to do compatibles really not yet understood?
> >
> > Well, it seems like not everyone necessarily understands what is the
> > best strategy to adopt (me included).
> >
> >> > I agree that a clarification would be good. There are really two
> >> > options:
> >> >
> >> > 1. Have two compatible strings in the DT, the one that matches the
> >> > exact SoC where the IP is found (first compatible string) and the
> >> > one that matches some other SoC where the same IP is found (second
> >> > compatible string). Originally, Linux only supports the second
> >> > compatible string in its device driver, but if it happens that a
> >> > difference is found between two IPs that we thought were the same,
> >> > we can add support for the first compatible string in the driver,
> >> > with a slightly different behavior.
> >>
> >> This. And no wildcards in the compatible string.
> >
> > OK. So it means that today we do something like:
> >
> > compatible = "baz,foo-12", "baz,foo-00";
> >
> > and support only baz,foo-00 in the driver. If tomorrow we discover
> > that there is in fact a difference between the two IP blocks, we can
> > add support for baz,foo-12 in the driver, and handle the differences.
> >
> > But then, the DT still contains:
> >
> > compatible = "baz,foo-12", "baz,foo-00";
> >
> > and therefore pretends that the IP block is compatible with
> > "baz,foo-00" which is in fact *not* the case. It was a mistake to
> > consider it as compatible. So we keep living with a DT that has
> > incorrect information.
>
> I wouldn't say it's a mistake necessarily. The old compatible would
> probably work to some extent. I'd assume it was tested to some level.
> Or it could be other changes exposing a difference.
One last question and I'm done: is something like that acceptable?
compatible = "<vendor>,<old-soc>","<vendor>,<new-soc>";
This can happen when someone adds support for an unsupported feature
on a brand new SoC, and then someone else use the same driver for an
older SoC embedding the same IP but still wants to add a new compatible
just in case these 2 IPs appear to be slightly different.
Here the order of compat strings is no longer following a clear rule
like 'most-specific compatible first' or 'newest IP/SoC version first',
it's completely dependent on the order these IPs were supported in the
OS (Linux). I'm perfectly fine with that BTW, just want to make sure
this is authorized.
Regards,
Boris
^ permalink raw reply
* [PATCH 2/3] ARM64: dts: meson-gxbb: Add support for WeTek Hub and Play
From: Neil Armstrong @ 2017-01-19 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <m2mveox9mm.fsf@baylibre.com>
On 01/18/2017 11:53 PM, Kevin Hilman wrote:
> Neil Armstrong <narmstrong@baylibre.com> writes:
>
>> Adds support for the WeTek Hub and Play2 boards.
>> The Hub is an extremely small IPTv Set-Top-Box and the Play2 is a more
>> traditionnal Satellite or Terrestrial and IPTv Set-Top-Box.
>>
>> Both are based on the p200 Reference Design and out-of-tree support is
>> based on OpenELEC kernel at [1].
>>
>> [1] https://github.com/wetek-enigma/linux-amlogic
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>
> Did you get the GPIO/button info from the LibreELEC tree or did you find
> some schematics someplace? If you found any schematics, it would be
> nice to have links in the DTS files.
>
> Kevin
>
It was in the dts of the LibreELEC tree, I found no schematics so far.
I can respin a v2 with a link to the LibreELEC dts files.
Neil
^ permalink raw reply
* [PATCH V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp
From: Peter Senna Tschudin @ 2017-01-19 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2088084.GDlN6tZSQv@avalon>
On Wed, Jan 18, 2017 at 11:10:58PM +0200, Laurent Pinchart wrote:
> Hi Peter,
>
> On Monday 16 Jan 2017 09:37:11 Peter Senna Tschudin wrote:
> > On Tue, Jan 10, 2017 at 11:04:58PM +0200, Laurent Pinchart wrote:
> > > On Saturday 07 Jan 2017 01:29:52 Peter Senna Tschudin wrote:
> > >> On 04 January, 2017 21:39 CET, Rob Herring wrote:
> > >>> On Tue, Jan 3, 2017 at 5:34 PM, Peter Senna Tschudin wrote:
> > >>>> On 03 January, 2017 23:51 CET, Rob Herring <robh@kernel.org> wrote:
> > >>>>> On Sun, Jan 01, 2017 at 09:24:29PM +0100, Peter Senna Tschudin wrote:
> > >>>>>> Devicetree bindings documentation for the GE B850v3 LVDS/DP++
> > >>>>>> display bridge.
> > >>>>>>
> > >>>>>> Cc: Martyn Welch <martyn.welch@collabora.co.uk>
> > >>>>>> Cc: Martin Donnelly <martin.donnelly@ge.com>
> > >>>>>> Cc: Javier Martinez Canillas <javier@dowhile0.org>
> > >>>>>> Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> > >>>>>> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> > >>>>>> Cc: Rob Herring <robh@kernel.org>
> > >>>>>> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> > >>>>>> Signed-off-by: Peter Senna Tschudin <peter.senna@collabora.com>
> > >>>>>> ---
> > >>>>>> There was an Acked-by from Rob Herring <robh@kernel.org> for V6,
> > >>>>>> but I changed the bindings to use i2c_new_secondary_device() so I
> > >>>>>> removed it from the commit message.
> > >>>>>>
[...]
> > >>>>>> .../devicetree/bindings/ge/b850v3-lvds-dp.txt | 39 +++++++++++
> > >>>>>
> > >>>>> Isn't '-lvds-dp' redundant? The part# should be enough.
> > >>>>
> > >>>> b850v3 is the name of the product, this is why the proposed name.
> > >>>> What about, b850v3-dp2 dp2 indicating the second DP output?
> > >>>
> > >>> Humm, b850v3 is the board name? This node should be the name of the
> > >>> bridge chip.
> > >>
> > >> From the cover letter:
> > >>
> > >> -- // --
> > >> There are two physical bridges on the video signal pipeline: a
> > >> STDP4028(LVDS to DP) and a STDP2690(DP to DP++). The hardware and
> > >> firmware made it complicated for this binding to comprise two device
> > >> tree nodes, as the design goal is to configure both bridges based on
> > >> the LVDS signal, which leave the driver powerless to control the video
> > >> processing pipeline. The two bridges behaves as a single bridge, and
> > >> the driver is only needed for telling the host about EDID / HPD, and
> > >> for giving the host powers to ack interrupts. The video signal pipeline
> > >> is as follows:
> > >> Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video
> > >> output
> > >> -- // --
> > >
> > > You forgot to prefix your patch series with [HACK] ;-)
> > >
> > > How about fixing the issues that make the two DT nodes solution difficult
> > > ? What are they ?
> >
> > The Firmware and the hardware design. Both bridges, with stock firmware,
> > are fully capable of providig EDID information and handling interrupts.
> > But on this specific design, with this specific firmware, I need to read
> > EDID from one bridge, and handle interrupts on the other.
>
> Which firmware are you talking about ? Firmware running on the bridges, or
> somewhere else ?
Each bridge has it's own external flash containing a binary firmware.
The goal of the firmware is to configure the output end based on the
input end. This is part of what makes handling EDID and HPD challenging.
>
> > Back when I was starting the development I could not come up with a proper
> > way to split EDID and interrupts between two bridges in a way that would
> > result in a fully functional connector. Did I miss something?
>
> You didn't, we did :-) I've been telling for quite some time now that we must
> decouple bridges from connectors, and this is another example of why we have
> such a need. Bridges should expose additional functions needed to implement
> connector operations, and the connector should be instantiated by the display
> driver with the help of bridge operations. You could then create a connector
> that relies on one bridge to read the EDID and on the other bridge to handle
> HPD.
Ah thanks. So for now the single DT node approach is acceptable, right?
The problem is that even if the driver is getting better on each
iteration, the single DT node for two chips issue comes back often and I
believe is _the_ issue preventing the driver from getting upstream. V1
was sent ~ 8 months ago...
Can I have some blessing on the single DT node approach for now? I'm one
of the 3 proposed maintainers for the driver, and I'm willing to
maintain the driver on the long run, as is the same with the other two
proposed maintainers. So when the time to split the node in two comes,
we will be around, and willing to do it ourselves.
Thank you!
Peter
>
> --
> Regards,
>
> Laurent Pinchart
>
^ permalink raw reply
* [PATCH 1/2] ARM64: dts: meson-gxm: Add R-Box Pro
From: Neil Armstrong @ 2017-01-19 8:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <m237ggypfc.fsf@baylibre.com>
Hi Andreas, Kevin,
On 01/18/2017 11:27 PM, Kevin Hilman wrote:
> Andreas F?rber <afaerber@suse.de> writes:
>
>> Am 17.01.2017 um 04:06 schrieb Andreas F?rber:
>>> diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
>>> index 0d7bfbf7d922..66bc809a5eae 100644
>>> --- a/arch/arm64/boot/dts/amlogic/Makefile
>>> +++ b/arch/arm64/boot/dts/amlogic/Makefile
>>> @@ -12,6 +12,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxl-nexbox-a95x.dtb
>>> dtb-$(CONFIG_ARCH_MESON) += meson-gxm-s912-q200.dtb
>>> dtb-$(CONFIG_ARCH_MESON) += meson-gxm-s912-q201.dtb
>>> dtb-$(CONFIG_ARCH_MESON) += meson-gxm-nexbox-a1.dtb
>>
>> What is the logic behind meson-gxm-s912-q201 vs. meson-gxm-nexbox-a1?
>> Should it be renamed to include -s912 for consistency?
It followed the GXL logic... until I posted the nexbox-a1 without !
Since the q20x and p23x boards are the same, it was to enforce the fact that
the S912 was on the q200 and q201 boards.
> Oops, I think it should be renamed for consistency.
>
> I believe there's only one chip in the GXM family (S912) so it might be
> that we could either drop the -s912 from the q20x boards or, add it to
> the nexbox.
I believe this aswell AFAIK.
>
> I lean towards dropping the -s912 since there's a single chip in GXM.
> (FWIW, GXL has more than one chip in the family so we added the chip
> there.)
>
>>> +dtb-$(CONFIG_ARCH_MESON) += meson-gxm-rbox-pro.dtb
>>
>> Should this new board use meson-gxm-s912-?
>
> No. Unless Neil or you thing otherwise, I think we should send a patch
> to drop the -s912 from the q20x boards instead. (where "we" == Neil) ;)
Ok, will do.
>
> Kevin
Neil
^ permalink raw reply
* [PATCH v9 2/5] i2c: Add STM32F4 I2C driver
From: Uwe Kleine-König @ 2017-01-19 8:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOAejn2LobTMfvsvmW8cCiToFHuM6n26s5QPLLXxLzb-WKkhQw@mail.gmail.com>
Hello Cedric,
On Wed, Jan 18, 2017 at 09:55:39PM +0100, M'boumba Cedric Madianga wrote:
> 2017-01-18 19:42 GMT+01:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> > Hello Cedric,
> >
> > On Wed, Jan 18, 2017 at 04:21:17PM +0100, M'boumba Cedric Madianga wrote:
> >> >> + * In standard mode, the maximum allowed SCL rise time is 1000 ns.
> >> >> + * If, in the I2C_CR2 register, the value of FREQ[5:0] bits is equal to
> >> >> + * 0x08 so period = 125 ns therefore the TRISE[5:0] bits must be
> >> >> + * programmed with 09h.(1000 ns / 125 ns = 8 + 1)
> >> >
> >> > * programmed with 0x9.
> >> > (1000 ns / 125 ns = 8)
> >> >
> >> >> + * So, for I2C standard mode TRISE = FREQ[5:0] + 1
> >> >> + *
> >> >> + * In fast mode, the maximum allowed SCL rise time is 300 ns.
> >> >> + * If, in the I2C_CR2 register, the value of FREQ[5:0] bits is equal to
> >> >> + * 0x08 so period = 125 ns therefore the TRISE[5:0] bits must be
> >> >> + * programmed with 03h.(300 ns / 125 ns = 2 + 1)
> >> >
> >> > as above s/03h/0x3/;
> >>
> >> ok
> >>
> >> > s/.(/. (/;
> >> ok
> >>
> >> > s/+ 1//;
> >> This formula is use to understand how we find the result 0x3
> >> So, 0x3 => 300 ns / 125ns = 2 + 1
> >
> > Yeah, I understood that, but writing 300 ns / 125ns = 2 + 1 is
> > irritating at best.
>
> Ok. I will write 0x3 (300 ns / 125 ns + 1) and 0x9 (1000 ns / 125 ns + 1)
>
> >> > [...]
> >> > If DUTY = 1: (to reach 400 kHz)
> >> >
> >> > Strange.
> >> >
> >> >> + val = DIV_ROUND_UP(i2c_dev->parent_rate, 400000 * 3);
> >> >
> >> > the manual reads:
> >> >
> >> > The minimum allowed value is 0x04, except in FAST DUTY mode
> >> > where the minimum allowed value is 0x01
> >> >
> >> > You don't check for that, right?
> >>
> >> As the minimum freq value is 6 Mhz in fast mode the minimum CCR is 5
> >> as described in the comment.
> >> So I don't need to check that again as it is already done by checking
> >> parent frequency.
> >
> > That would then go into a comment.
>
> Is it really needed ?
> Adding some comments to explain implementation choices or hardware
> way of working is clearly useful.
> But for this kind of thing, I am really surprised...
TL;DR: It's not needed, but it probably helps.
Consider someone sees a breakage in your driver in five years. By then
you either have other interests or at least forgot 95 % of the thoughts
you had when implementing the driver.
So when I see:
val = DIV_ROUND_UP(i2c_dev->parent_rate, 400000 * 3);
ccr |= STM32F4_I2C_CCR_CCR(val);
writel_relaxed(ccr, i2c_dev->base + STM32F4_I2C_CCR);
after seeing that the bus freq is wrong the obvious thoughts are:
- Does this use the right algorithm?
- Does this calculation result in values that are usable by the
hardware?
That you thought about this today doesn't mean it's still right in five
years. During that time a new hardware variant is available with a
higher parent freq. Or there is a new errata available for the SoC.
So to help answer the questions above it helps if you add today the
formulas from the manual and a quick reason for why val fits into the
respective bits in the CCR register. That comment might be wrong until
then, too, but that only means you should make it easy to verify.
Something like:
/*
* Function bla_blub made sure that parent_rate is not higher
* than 23 * pi MHz. As a result val is at most 13.2 bits wide
* and so fits into the CCR bits.
*/
This gives you in five years time the opportunity to quickly check
bla_blub if this is still true, add a printk for parent_rate to check
this, or quickly identify the bug in the code or the mismatch to the
manual.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework counter frequency detection.
From: Hanjun Guo @ 2017-01-19 8:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118132541.8989-9-fu.wei@linaro.org>
Hi Fuwei,
One comments below.
On 2017/1/18 21:25, fu.wei at linaro.org wrote:
> From: Fu Wei <fu.wei@linaro.org>
>
> The counter frequency detection call(arch_timer_detect_rate) combines two
> ways to get counter frequency: system coprocessor register and MMIO timer.
> But in a specific timer init code, we only need one way to try:
> getting frequency from MMIO timer register will be needed only when we
> init MMIO timer; getting frequency from system coprocessor register will
> be needed only when we init arch timer.
>
> This patch separates paths to determine frequency:
> Separate out the MMIO frequency and the sysreg frequency detection call,
> and use the appropriate one for the counter.
>
> Signed-off-by: Fu Wei <fu.wei@linaro.org>
> ---
> drivers/clocksource/arm_arch_timer.c | 40 ++++++++++++++++++++++--------------
> 1 file changed, 25 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index 6484f84..9482481 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -488,23 +488,33 @@ static int arch_timer_starting_cpu(unsigned int cpu)
> return 0;
> }
>
> -static void arch_timer_detect_rate(void __iomem *cntbase)
> +static void __arch_timer_determine_rate(u32 rate)
> {
> - /* Who has more than one independent system counter? */
> - if (arch_timer_rate)
> - return;
> + /* Check the timer frequency. */
> + if (!arch_timer_rate) {
> + if (rate)
> + arch_timer_rate = rate;
> + else
> + pr_warn("frequency not available\n");
> + } else if (rate && arch_timer_rate != rate) {
^
Typo? I think it's "&" here.
Thanks
Hanjun
^ permalink raw reply
* [PATCH 1/2] security: Change name of CONFIG_DEBUG_RODATA
From: Pavel Machek @ 2017-01-19 7:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484789346-21012-2-git-send-email-labbott@redhat.com>
On Wed 2017-01-18 17:29:05, Laura Abbott wrote:
>
> Despite the word 'debug' in CONFIG_DEBUG_RODATA, this kernel option
> provides key security features that are to be expected on a modern
> system. Change the name to CONFIG_HARDENED_PAGE_MAPPINGS which more
> accurately describes what this option is intended to do.
I think this is bad change. CONFIG_DEBUG_RODATA is describing what it
does, CONFIG_HARDENED_PAGE_MAPPINGS is advertising.
We don't do advertising, and we don't force people to re-answer the
config questions without good reason.
CONFIG_HARDENED_RODATA might fix the first problem, but not the second
one.
Pavel
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
> Documentation/DocBook/kgdb.tmpl | 8 ++++----
> Documentation/security/self-protection.txt | 2 +-
> arch/arm/Kconfig | 1 +
> arch/arm/configs/aspeed_g4_defconfig | 2 +-
> arch/arm/configs/aspeed_g5_defconfig | 2 +-
> arch/arm/include/asm/cacheflush.h | 2 +-
> arch/arm/kernel/patch.c | 2 +-
> arch/arm/kernel/vmlinux.lds.S | 8 ++++----
> arch/arm/mm/Kconfig | 14 +-------------
> arch/arm/mm/init.c | 4 ++--
> arch/arm64/Kconfig | 4 +---
> arch/arm64/Kconfig.debug | 2 +-
> arch/parisc/Kconfig | 1 +
> arch/parisc/Kconfig.debug | 11 -----------
> arch/parisc/configs/712_defconfig | 2 +-
> arch/parisc/configs/c3000_defconfig | 2 +-
> arch/parisc/mm/init.c | 2 +-
> arch/s390/Kconfig | 4 +---
> arch/x86/Kconfig | 4 +---
> include/linux/init.h | 4 ++--
> init/main.c | 4 ++--
> kernel/configs/android-recommended.config | 2 +-
> kernel/power/hibernate.c | 2 +-
> kernel/power/power.h | 4 ++--
> kernel/power/snapshot.c | 4 ++--
> security/Kconfig | 16 ++++++++++++++++
> 26 files changed, 51 insertions(+), 62 deletions(-)
>
> diff --git a/Documentation/DocBook/kgdb.tmpl b/Documentation/DocBook/kgdb.tmpl
> index f3abca7..a79b638 100644
> --- a/Documentation/DocBook/kgdb.tmpl
> +++ b/Documentation/DocBook/kgdb.tmpl
> @@ -115,12 +115,12 @@
> </para>
> <para>
> If the architecture that you are using supports the kernel option
> - CONFIG_DEBUG_RODATA, you should consider turning it off. This
> + CONFIG_HARDENED_PAGE_MAPPINGS, you should consider turning it off. This
> option will prevent the use of software breakpoints because it
> marks certain regions of the kernel's memory space as read-only.
> If kgdb supports it for the architecture you are using, you can
> use hardware breakpoints if you desire to run with the
> - CONFIG_DEBUG_RODATA option turned on, else you need to turn off
> + CONFIG_HARDENED_PAGE_MAPPINGS option turned on, else you need to turn off
> this option.
> </para>
> <para>
> @@ -135,7 +135,7 @@
> <para>Here is an example set of .config symbols to enable or
> disable for kgdb:
> <itemizedlist>
> - <listitem><para># CONFIG_DEBUG_RODATA is not set</para></listitem>
> + <listitem><para># CONFIG_HARDENED_PAGE_MAPPINGS is not set</para></listitem>
> <listitem><para>CONFIG_FRAME_POINTER=y</para></listitem>
> <listitem><para>CONFIG_KGDB=y</para></listitem>
> <listitem><para>CONFIG_KGDB_SERIAL_CONSOLE=y</para></listitem>
> @@ -166,7 +166,7 @@
> </para>
> <para>Here is an example set of .config symbols to enable/disable kdb:
> <itemizedlist>
> - <listitem><para># CONFIG_DEBUG_RODATA is not set</para></listitem>
> + <listitem><para># CONFIG_HARDENED_PAGE_MAPPINGS is not set</para></listitem>
> <listitem><para>CONFIG_FRAME_POINTER=y</para></listitem>
> <listitem><para>CONFIG_KGDB=y</para></listitem>
> <listitem><para>CONFIG_KGDB_SERIAL_CONSOLE=y</para></listitem>
> diff --git a/Documentation/security/self-protection.txt b/Documentation/security/self-protection.txt
> index 3010576..da8cb36 100644
> --- a/Documentation/security/self-protection.txt
> +++ b/Documentation/security/self-protection.txt
> @@ -51,7 +51,7 @@ kernel, they are implemented in a way where the memory is temporarily
> made writable during the update, and then returned to the original
> permissions.)
>
> -In support of this are (the poorly named) CONFIG_DEBUG_RODATA and
> +In support of this are CONFIG_HARDENED_PAGE_MAPPINGS and
> CONFIG_DEBUG_SET_MODULE_RONX, which seek to make sure that code is not
> writable, data is not executable, and read-only data is neither writable
> nor executable.
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 186c4c2..09aff28 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -7,6 +7,7 @@ config ARM
> select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
> select ARCH_HAVE_CUSTOM_GPIO_H
> select ARCH_HAS_GCOV_PROFILE_ALL
> + select ARCH_HAS_HARDENED_MAPPINGS if MMU && !XIP_KERNEL
> select ARCH_MIGHT_HAVE_PC_PARPORT
> select ARCH_SUPPORTS_ATOMIC_RMW
> select ARCH_USE_BUILTIN_BSWAP
> diff --git a/arch/arm/configs/aspeed_g4_defconfig b/arch/arm/configs/aspeed_g4_defconfig
> index ca39c04..8ccc216 100644
> --- a/arch/arm/configs/aspeed_g4_defconfig
> +++ b/arch/arm/configs/aspeed_g4_defconfig
> @@ -25,7 +25,7 @@ CONFIG_MODULE_UNLOAD=y
> # CONFIG_ARCH_MULTI_V7 is not set
> CONFIG_ARCH_ASPEED=y
> CONFIG_MACH_ASPEED_G4=y
> -CONFIG_DEBUG_RODATA=y
> +CONFIG_HARDENED_PAGE_MAPPINGS=y
> CONFIG_AEABI=y
> CONFIG_UACCESS_WITH_MEMCPY=y
> CONFIG_SECCOMP=y
> diff --git a/arch/arm/configs/aspeed_g5_defconfig b/arch/arm/configs/aspeed_g5_defconfig
> index 4f366b0..90c5ce4 100644
> --- a/arch/arm/configs/aspeed_g5_defconfig
> +++ b/arch/arm/configs/aspeed_g5_defconfig
> @@ -26,7 +26,7 @@ CONFIG_ARCH_MULTI_V6=y
> # CONFIG_ARCH_MULTI_V7 is not set
> CONFIG_ARCH_ASPEED=y
> CONFIG_MACH_ASPEED_G5=y
> -CONFIG_DEBUG_RODATA=y
> +CONFIG_HARDENED_PAGE_MAPPINGS=y
> CONFIG_AEABI=y
> CONFIG_UACCESS_WITH_MEMCPY=y
> CONFIG_SECCOMP=y
> diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h
> index bdd283b..c3a7a72 100644
> --- a/arch/arm/include/asm/cacheflush.h
> +++ b/arch/arm/include/asm/cacheflush.h
> @@ -490,7 +490,7 @@ static inline int set_memory_x(unsigned long addr, int numpages) { return 0; }
> static inline int set_memory_nx(unsigned long addr, int numpages) { return 0; }
> #endif
>
> -#ifdef CONFIG_DEBUG_RODATA
> +#ifdef CONFIG_HARDENED_PAGE_MAPPINGS
> void set_kernel_text_rw(void);
> void set_kernel_text_ro(void);
> #else
> diff --git a/arch/arm/kernel/patch.c b/arch/arm/kernel/patch.c
> index 69bda1a..9da1bf5 100644
> --- a/arch/arm/kernel/patch.c
> +++ b/arch/arm/kernel/patch.c
> @@ -26,7 +26,7 @@ static void __kprobes *patch_map(void *addr, int fixmap, unsigned long *flags)
>
> if (module && IS_ENABLED(CONFIG_DEBUG_SET_MODULE_RONX))
> page = vmalloc_to_page(addr);
> - else if (!module && IS_ENABLED(CONFIG_DEBUG_RODATA))
> + else if (!module && IS_ENABLED(CONFIG_HARDENED_PAGE_MAPPINGS))
> page = virt_to_page(addr);
> else
> return addr;
> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
> index f7f55df..5c6a2e8 100644
> --- a/arch/arm/kernel/vmlinux.lds.S
> +++ b/arch/arm/kernel/vmlinux.lds.S
> @@ -97,7 +97,7 @@ SECTIONS
> HEAD_TEXT
> }
>
> -#ifdef CONFIG_DEBUG_RODATA
> +#ifdef CONFIG_HARDENED_PAGE_MAPPINGS
> . = ALIGN(1<<SECTION_SHIFT);
> #endif
>
> @@ -158,7 +158,7 @@ SECTIONS
>
> NOTES
>
> -#ifdef CONFIG_DEBUG_RODATA
> +#ifdef CONFIG_HARDENED_PAGE_MAPPINGS
> . = ALIGN(1<<SECTION_SHIFT);
> #else
> . = ALIGN(PAGE_SIZE);
> @@ -230,7 +230,7 @@ SECTIONS
> PERCPU_SECTION(L1_CACHE_BYTES)
> #endif
>
> -#ifdef CONFIG_DEBUG_RODATA
> +#ifdef CONFIG_HARDENED_PAGE_MAPPINGS
> . = ALIGN(1<<SECTION_SHIFT);
> #else
> . = ALIGN(THREAD_SIZE);
> @@ -325,7 +325,7 @@ SECTIONS
> STABS_DEBUG
> }
>
> -#ifdef CONFIG_DEBUG_RODATA
> +#ifdef CONFIG_HARDENED_PAGE_MAPPINGS
> /*
> * Without CONFIG_DEBUG_ALIGN_RODATA, __start_rodata_section_aligned will
> * be the first section-aligned location after __start_rodata. Otherwise,
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index f68e8ec..e770dc9 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -1051,21 +1051,9 @@ config ARCH_SUPPORTS_BIG_ENDIAN
> This option specifies the architecture can support big endian
> operation.
>
> -config DEBUG_RODATA
> - bool "Make kernel text and rodata read-only"
> - depends on MMU && !XIP_KERNEL
> - default y if CPU_V7
> - help
> - If this is set, kernel text and rodata memory will be made
> - read-only, and non-text kernel memory will be made non-executable.
> - The tradeoff is that each region is padded to section-size (1MiB)
> - boundaries (because their permissions are different and splitting
> - the 1M pages into 4K ones causes TLB performance problems), which
> - can waste memory.
> -
> config DEBUG_ALIGN_RODATA
> bool "Make rodata strictly non-executable"
> - depends on DEBUG_RODATA
> + depends on HARDENED_PAGE_MAPPINGS
> default y
> help
> If this is set, rodata will be made explicitly non-executable. This
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index 370581a..303bee4 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -572,7 +572,7 @@ void __init mem_init(void)
> }
> }
>
> -#ifdef CONFIG_DEBUG_RODATA
> +#ifdef CONFIG_HARDENED_PAGE_MAPPINGS
> struct section_perm {
> const char *name;
> unsigned long start;
> @@ -741,7 +741,7 @@ void set_kernel_text_ro(void)
>
> #else
> static inline void fix_kernmem_perms(void) { }
> -#endif /* CONFIG_DEBUG_RODATA */
> +#endif /* CONFIG_HARDENED_PAGE_MAPPINGS */
>
> void free_tcmmem(void)
> {
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 1117421..06fed56 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -11,6 +11,7 @@ config ARM64
> select ARCH_HAS_ELF_RANDOMIZE
> select ARCH_HAS_GCOV_PROFILE_ALL
> select ARCH_HAS_GIGANTIC_PAGE
> + select ARCH_HAS_HARDENED_MAPPINGS
> select ARCH_HAS_KCOV
> select ARCH_HAS_SG_CHAIN
> select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
> @@ -123,9 +124,6 @@ config ARCH_PHYS_ADDR_T_64BIT
> config MMU
> def_bool y
>
> -config DEBUG_RODATA
> - def_bool y
> -
> config ARM64_PAGE_SHIFT
> int
> default 16 if ARM64_64K_PAGES
> diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug
> index d1ebd46..a26d27f 100644
> --- a/arch/arm64/Kconfig.debug
> +++ b/arch/arm64/Kconfig.debug
> @@ -83,7 +83,7 @@ config DEBUG_SET_MODULE_RONX
> If in doubt, say Y.
>
> config DEBUG_ALIGN_RODATA
> - depends on DEBUG_RODATA
> + depends on ARCH_HAS_HARDENED_MAPPINGS
> bool "Align linker sections up to SECTION_SIZE"
> help
> If this option is enabled, sections that may potentially be marked as
> diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
> index 3a71f38..7c73eaa 100644
> --- a/arch/parisc/Kconfig
> +++ b/arch/parisc/Kconfig
> @@ -8,6 +8,7 @@ config PARISC
> select HAVE_SYSCALL_TRACEPOINTS
> select ARCH_WANT_FRAME_POINTERS
> select ARCH_HAS_ELF_RANDOMIZE
> + select ARCH_HAS_HARDENED_MAPPINGS
> select RTC_CLASS
> select RTC_DRV_GENERIC
> select INIT_ALL_POSSIBLE
> diff --git a/arch/parisc/Kconfig.debug b/arch/parisc/Kconfig.debug
> index 68b7cbd..0d856b9 100644
> --- a/arch/parisc/Kconfig.debug
> +++ b/arch/parisc/Kconfig.debug
> @@ -5,15 +5,4 @@ source "lib/Kconfig.debug"
> config TRACE_IRQFLAGS_SUPPORT
> def_bool y
>
> -config DEBUG_RODATA
> - bool "Write protect kernel read-only data structures"
> - depends on DEBUG_KERNEL
> - default y
> - help
> - Mark the kernel read-only data as write-protected in the pagetables,
> - in order to catch accidental (and incorrect) writes to such const
> - data. This option may have a slight performance impact because a
> - portion of the kernel code won't be covered by a TLB anymore.
> - If in doubt, say "N".
> -
> endmenu
> diff --git a/arch/parisc/configs/712_defconfig b/arch/parisc/configs/712_defconfig
> index db8f56b..f1a4732 100644
> --- a/arch/parisc/configs/712_defconfig
> +++ b/arch/parisc/configs/712_defconfig
> @@ -182,7 +182,7 @@ CONFIG_DEBUG_FS=y
> CONFIG_DEBUG_KERNEL=y
> CONFIG_DEBUG_MUTEXES=y
> # CONFIG_RCU_CPU_STALL_DETECTOR is not set
> -CONFIG_DEBUG_RODATA=y
> +CONFIG_HARDENED_PAGE_MAPPINGS=y
> CONFIG_CRYPTO_NULL=m
> CONFIG_CRYPTO_TEST=m
> CONFIG_CRYPTO_HMAC=y
> diff --git a/arch/parisc/configs/c3000_defconfig b/arch/parisc/configs/c3000_defconfig
> index fb92b89..03e88e2 100644
> --- a/arch/parisc/configs/c3000_defconfig
> +++ b/arch/parisc/configs/c3000_defconfig
> @@ -166,7 +166,7 @@ CONFIG_DEBUG_KERNEL=y
> CONFIG_DEBUG_MUTEXES=y
> # CONFIG_DEBUG_BUGVERBOSE is not set
> # CONFIG_RCU_CPU_STALL_DETECTOR is not set
> -CONFIG_DEBUG_RODATA=y
> +CONFIG_HARDENED_PAGE_MAPPINGS=y
> CONFIG_CRYPTO_NULL=m
> CONFIG_CRYPTO_TEST=m
> CONFIG_CRYPTO_MD5=m
> diff --git a/arch/parisc/mm/init.c b/arch/parisc/mm/init.c
> index e02ada3..f76f8ad 100644
> --- a/arch/parisc/mm/init.c
> +++ b/arch/parisc/mm/init.c
> @@ -545,7 +545,7 @@ void free_initmem(void)
> }
>
>
> -#ifdef CONFIG_DEBUG_RODATA
> +#ifdef CONFIG_HARDENED_PAGE_MAPPINGS
> void mark_rodata_ro(void)
> {
> /* rodata memory was already mapped with KERNEL_RO access rights by
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index c6722112..8e70ae5 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -62,15 +62,13 @@ config PCI_QUIRKS
> config ARCH_SUPPORTS_UPROBES
> def_bool y
>
> -config DEBUG_RODATA
> - def_bool y
> -
> config S390
> def_bool y
> select ARCH_HAS_DEVMEM_IS_ALLOWED
> select ARCH_HAS_ELF_RANDOMIZE
> select ARCH_HAS_GCOV_PROFILE_ALL
> select ARCH_HAS_GIGANTIC_PAGE
> + select ARCH_HAS_HARDENED_MAPPINGS
> select ARCH_HAS_KCOV
> select ARCH_HAS_SG_CHAIN
> select ARCH_HAS_UBSAN_SANITIZE_ALL
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index e487493..9d80cd8 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -50,6 +50,7 @@ config X86
> select ARCH_HAS_ELF_RANDOMIZE
> select ARCH_HAS_FAST_MULTIPLIER
> select ARCH_HAS_GCOV_PROFILE_ALL
> + select ARCH_HAS_HARDENED_MAPPINGS
> select ARCH_HAS_KCOV if X86_64
> select ARCH_HAS_MMIO_FLUSH
> select ARCH_HAS_PMEM_API if X86_64
> @@ -309,9 +310,6 @@ config ARCH_SUPPORTS_UPROBES
> config FIX_EARLYCON_MEM
> def_bool y
>
> -config DEBUG_RODATA
> - def_bool y
> -
> config PGTABLE_LEVELS
> int
> default 4 if X86_64
> diff --git a/include/linux/init.h b/include/linux/init.h
> index 885c3e6..9967bc9 100644
> --- a/include/linux/init.h
> +++ b/include/linux/init.h
> @@ -126,10 +126,10 @@ void prepare_namespace(void);
> void __init load_default_modules(void);
> int __init init_rootfs(void);
>
> -#if defined(CONFIG_DEBUG_RODATA) || defined(CONFIG_DEBUG_SET_MODULE_RONX)
> +#if defined(CONFIG_HARDENED_PAGE_MAPPINGS) || defined(CONFIG_DEBUG_SET_MODULE_RONX)
> extern bool rodata_enabled;
> #endif
> -#ifdef CONFIG_DEBUG_RODATA
> +#ifdef CONFIG_HARDENED_PAGE_MAPPINGS
> void mark_rodata_ro(void);
> #endif
>
> diff --git a/init/main.c b/init/main.c
> index b0c9d6f..4b3bcc4 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -925,7 +925,7 @@ static int try_to_run_init_process(const char *init_filename)
>
> static noinline void __init kernel_init_freeable(void);
>
> -#if defined(CONFIG_DEBUG_RODATA) || defined(CONFIG_DEBUG_SET_MODULE_RONX)
> +#if defined(CONFIG_HARDENED_PAGE_MAPPINGS) || defined(CONFIG_DEBUG_SET_MODULE_RONX)
> bool rodata_enabled __ro_after_init = true;
> static int __init set_debug_rodata(char *str)
> {
> @@ -934,7 +934,7 @@ static int __init set_debug_rodata(char *str)
> __setup("rodata=", set_debug_rodata);
> #endif
>
> -#ifdef CONFIG_DEBUG_RODATA
> +#ifdef CONFIG_HARDENED_PAGE_MAPPINGS
> static void mark_readonly(void)
> {
> if (rodata_enabled)
> diff --git a/kernel/configs/android-recommended.config b/kernel/configs/android-recommended.config
> index 297756b..b796bc8 100644
> --- a/kernel/configs/android-recommended.config
> +++ b/kernel/configs/android-recommended.config
> @@ -11,7 +11,7 @@ CONFIG_BLK_DEV_LOOP=y
> CONFIG_BLK_DEV_RAM=y
> CONFIG_BLK_DEV_RAM_SIZE=8192
> CONFIG_COMPACTION=y
> -CONFIG_DEBUG_RODATA=y
> +CONFIG_HARDENED_PAGE_MAPPINGS=y
> CONFIG_DM_CRYPT=y
> CONFIG_DM_UEVENT=y
> CONFIG_DM_VERITY=y
> diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
> index b26dbc4..f7a3ea3 100644
> --- a/kernel/power/hibernate.c
> +++ b/kernel/power/hibernate.c
> @@ -1156,7 +1156,7 @@ static int __init hibernate_setup(char *str)
> } else if (!strncmp(str, "no", 2)) {
> noresume = 1;
> nohibernate = 1;
> - } else if (IS_ENABLED(CONFIG_DEBUG_RODATA)
> + } else if (IS_ENABLED(CONFIG_HARDENED_PAGE_MAPPINGS)
> && !strncmp(str, "protect_image", 13)) {
> enable_restore_image_protection();
> }
> diff --git a/kernel/power/power.h b/kernel/power/power.h
> index 1dfa0da..dc2c7b8 100644
> --- a/kernel/power/power.h
> +++ b/kernel/power/power.h
> @@ -61,12 +61,12 @@ extern int hibernation_snapshot(int platform_mode);
> extern int hibernation_restore(int platform_mode);
> extern int hibernation_platform_enter(void);
>
> -#ifdef CONFIG_DEBUG_RODATA
> +#ifdef CONFIG_HARDENED_PAGE_MAPPINGS
> /* kernel/power/snapshot.c */
> extern void enable_restore_image_protection(void);
> #else
> static inline void enable_restore_image_protection(void) {}
> -#endif /* CONFIG_DEBUG_RODATA */
> +#endif /* CONFIG_HARDENED_PAGE_MAPPINGS */
>
> #else /* !CONFIG_HIBERNATION */
>
> diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
> index 2d8e2b2..a7c793e 100644
> --- a/kernel/power/snapshot.c
> +++ b/kernel/power/snapshot.c
> @@ -38,7 +38,7 @@
>
> #include "power.h"
>
> -#ifdef CONFIG_DEBUG_RODATA
> +#ifdef CONFIG_HARDENED_PAGE_MAPPINGS
> static bool hibernate_restore_protection;
> static bool hibernate_restore_protection_active;
>
> @@ -73,7 +73,7 @@ static inline void hibernate_restore_protection_begin(void) {}
> static inline void hibernate_restore_protection_end(void) {}
> static inline void hibernate_restore_protect_page(void *page_address) {}
> static inline void hibernate_restore_unprotect_page(void *page_address) {}
> -#endif /* CONFIG_DEBUG_RODATA */
> +#endif /* CONFIG_HARDENED_PAGE_MAPPINGS */
>
> static int swsusp_page_is_free(struct page *);
> static void swsusp_set_page_forbidden(struct page *);
> diff --git a/security/Kconfig b/security/Kconfig
> index 118f454..ad6ce82 100644
> --- a/security/Kconfig
> +++ b/security/Kconfig
> @@ -158,6 +158,22 @@ config HARDENED_USERCOPY_PAGESPAN
> been removed. This config is intended to be used only while
> trying to find such users.
>
> +config ARCH_HAS_HARDENED_MAPPINGS
> + def_bool n
> +
> +config HARDENED_PAGE_MAPPINGS
> + bool "Mark kernel mappings with stricter permissions (RO/W^X)"
> + default y
> + depends on ARCH_HAS_HARDENED_MAPPINGS
> + help
> + If this is set, kernel text and rodata memory will be made read-only,
> + and non-text memory will be made non-executable. This provides
> + protection against certain security attacks (e.g. executing the heap
> + or modifying text).
> +
> + Unless your system has known restrictions or performance issues, it
> + is recommended to say Y here.
> +
> source security/selinux/Kconfig
> source security/smack/Kconfig
> source security/tomoyo/Kconfig
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170119/ee90189b/attachment-0001.sig>
^ permalink raw reply
* [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Boris Brezillon @ 2017-01-19 7:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118222010.ivc6jxpnrumemvdf@rob-hp-laptop>
On Wed, 18 Jan 2017 16:20:10 -0600
Rob Herring <robh@kernel.org> wrote:
> On Tue, Jan 17, 2017 at 02:36:50PM +1100, Thomas Petazzoni wrote:
> > Hello,
> >
> > (Side note: you guys should learn about stripping irrelevant parts of
> > an e-mail when replying!)
> >
> > On Mon, 16 Jan 2017 09:40:32 +0100, Boris Brezillon wrote:
> >
> > > > Well this is OK I guess, but then you can also use "mediatek,mt8173-nor"
> > > > as the oldest supported compatible and be done with it, no ? It looks a
> > > > bit crappy though, I admit that ...
> > >
> > > Let's stop bikeshedding and wait for DT maintainers feedback
> > > before taking a decision ;-).
> > >
> > > Rob, Mark, any opinion?
> >
>
> Sigh, is how to do compatibles really not yet understood?
Apparently not, and I fear this is not the last misunderstanding on my
side ;-).
>
> > I agree that a clarification would be good. There are really two
> > options:
> >
> > 1. Have two compatible strings in the DT, the one that matches the
> > exact SoC where the IP is found (first compatible string) and the
> > one that matches some other SoC where the same IP is found (second
> > compatible string). Originally, Linux only supports the second
> > compatible string in its device driver, but if it happens that a
> > difference is found between two IPs that we thought were the same,
> > we can add support for the first compatible string in the driver,
> > with a slightly different behavior.
>
> This. And no wildcards in the compatible string.
>
> > 2. Have a single compatible string in the DT, matching the exact SoC
> > where the IP is found. This involves adding immediately this
> > compatible string in the corresponding driver.
>
> I wouldn't object to this from a DT perspective as I have no clue
> generally if IP blocks are "the same" or not. Subsystem maintainers will
> object though.
>
> > I've not really been able to figure out which of the two options is the
> > most future-proof/appropriate.
>
> They are both future-proof. #2 has the disadvantage of requiring a
> kernel update for a new SoC.
>
> Rob
^ 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