* Re: [PATCH V5 00/12] 52-bit kernel + user VAs
From: Will Deacon @ 2019-08-13 13:10 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: crecklin, Ard Biesheuvel, Catalin Marinas, bhsharma, Steve Capper,
Linux-Renesas, maz, Linux ARM
In-Reply-To: <CAMuHMdWvkWGoNC5HbWoZwtpg5VXxTZqRZqQy4BLPgQXZJtKnsQ@mail.gmail.com>
Hi Geert,
On Tue, Aug 13, 2019 at 02:43:23PM +0200, Geert Uytterhoeven wrote:
> On Fri, Aug 9, 2019 at 6:47 PM Will Deacon <will@kernel.org> wrote:
> > On Wed, Aug 07, 2019 at 04:55:12PM +0100, Steve Capper wrote:
> > > This patch series adds support for 52-bit kernel VAs using some of the
> > > machinery already introduced by the 52-bit userspace VA code in 5.0.
> >
> > Cheers, I've pushed this out on a for-next/52-bit-kva branch with one
> > small patch on top and Catalin's tags added.
>
> As of commit 14c127c957c1c607 ("arm64: mm: Flip kernel VA space"), the
> kernel log is spammed with
>
> virt_to_phys used for non-linear address: (____ptrval____)
> (__func__.6603+0x14d681/0x17fb3d)
> WARNING: CPU: 0 PID: 264 at arch/arm64/mm/physaddr.c:15
> __virt_to_phys+0x28/0x58
> Modules linked in:
> CPU: 0 PID: 264 Comm: mdev Not tainted
> 5.3.0-rc3-rcar3-initrd-00002-g14c127c957c1c607 #38
> Hardware name: Renesas Ebisu-4D board based on r8a77990 (DT)
> pstate: 60000005 (nZCv daif -PAN -UAO)
> pc : __virt_to_phys+0x28/0x58
> lr : __virt_to_phys+0x28/0x58
> sp : ffffffc011953c80
> x29: ffffffc011953c80 x28: ffffff8078790140
> x27: 0000000000000000 x26: 0000000000000000
> x25: ffffffc010a539b9 x24: ffffffc010a86000
> x23: ffffffc010a539ba x22: 0000000000000001
> x21: 0000000000202038 x20: 0000000000000001
> x19: ffffffc010a539b9 x18: 000000000000000a
> x17: 0000000000000000 x16: 0000000000000000
> x15: 00000000000ca51d x14: 0720072007200720
> x13: 0720072007200720 x12: 0720072007200720
> x11: 0720072007200720 x10: 0720072007200720
> x9 : 0720072007200720 x8 : 0000000000000001
> x7 : 0000000000000007 x6 : ffffff8079824f00
> x5 : 0000000000000140 x4 : 0000000000000000
> x3 : 0000000000000000 x2 : 00000000ffffffff
> x1 : 0713abbc9281cf00 x0 : 0000000000000000
> Call trace:
> __virt_to_phys+0x28/0x58
> __check_object_size+0xd0/0x1e0
> filldir64+0x1d8/0x2b0
> kernfs_fop_readdir+0x64/0x200
> iterate_dir+0x68/0x144
> ksys_getdents64+0x88/0x154
> __arm64_sys_getdents64+0x18/0x24
> el0_svc_common.constprop.0+0x84/0xe8
> el0_svc_compat_handler+0x18/0x20
> el0_svc_compat+0x8/0x10
> ---[ end trace 6980a45f636e18be ]---
>
> as soon as userspace starts.
Can you try the hack I posted here, please?
https://lkml.org/lkml/2019/8/13/555
Also, what .config are you using?
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: next/pending-fixes build: 222 builds: 3 failed, 219 passed, 3 errors, 425 warnings (v5.3-rc4-185-g260510fdbaa7)
From: Christoph Hellwig @ 2019-08-13 13:08 UTC (permalink / raw)
To: Mark Brown
Cc: linux-next, kernel-build-reports, Christoph Hellwig,
linux-arm-kernel, Russell King
In-Reply-To: <20190813123740.GD5093@sirena.co.uk>
On Tue, Aug 13, 2019 at 01:37:40PM +0100, Mark Brown wrote:
> On Tue, Aug 13, 2019 at 05:14:59AM -0700, kernelci.org bot wrote:
>
> For the past few days -next has been failing to build configurations
> with LPAE enabled:
>
> > arm:
> > axm55xx_defconfig: (gcc-8) FAIL
> > keystone_defconfig: (gcc-8) FAIL
> > multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: (gcc-8) FAIL
>
> due to errors related to dma_atomic_pool_init()
>
The commit is completely bogus and slipped into my tree that gets pulled
into linux-next by accident. It has been dropped already.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 0/5] iommu/amd: Convert the AMD iommu driver to the dma-iommu api
From: Christoph Hellwig @ 2019-08-13 13:07 UTC (permalink / raw)
To: Tom Murphy
Cc: Heiko Stuebner, Will Deacon, virtualization, David Brown,
Thierry Reding, linux-s390, linux-samsung-soc,
Jean-Philippe Brucker, Joerg Roedel, Krzysztof Kozlowski,
Jonathan Hunter, Christoph Hellwig, linux-rockchip, Andy Gross,
Matthias Brugger, Gerald Schaefer, linux-arm-msm, linux-mediatek,
linux-tegra, linux-arm-kernel, Robin Murphy, linux-kernel, iommu,
Kukjin Kim, David Woodhouse
In-Reply-To: <CALQxJuvxBc3MH3_B_fZ3FvURHOM3F3dvvZ6x=GtALUAvyu7Qxw@mail.gmail.com>
On Tue, Aug 13, 2019 at 08:09:26PM +0800, Tom Murphy wrote:
> Hi Christoph,
>
> I quit my job and am having a great time traveling South East Asia.
Enjoy! I just returned from my vacation.
> I definitely don't want this work to go to waste and I hope to repost it
> later this week but I can't guarantee it.
>
> Let me know if you need this urgently.
It isn't in any strict sense urgent. I just have various DMA API plans
that I'd rather just implement in dma-direct and dma-iommu rather than
also in two additional commonly used iommu drivers. So on the one had
the sooner the better, on the other hand no real urgency.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH next v9 07/11] usb: roles: Add fwnode_usb_role_switch_get() function
From: Heikki Krogerus @ 2019-08-13 13:01 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Mark Rutland, devicetree, Hans de Goede, Greg Kroah-Hartman,
Linus Walleij, linux-usb, linux-kernel, Biju Das,
Badhri Jagan Sridharan, Andy Shevchenko, Rob Herring,
linux-mediatek, Min Guo, Matthias Brugger, Nagarjuna Kristam,
Adam Thomson, linux-arm-kernel, Li Jun
In-Reply-To: <1565695634-9711-8-git-send-email-chunfeng.yun@mediatek.com>
On Tue, Aug 13, 2019 at 07:27:10PM +0800, Chunfeng Yun wrote:
> From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
>
> The fwnode_usb_role_switch_get() function is exactly the
> same as usb_role_switch_get(), except that it takes struct
> fwnode_handle as parameter instead of struct device.
>
> Suggested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Why is my SoB replaced with Suggested-by tag in this patch?
thanks,
--
heikki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 2/2] arm64: dts: imx: Add i.mx8mq nitrogen8m basic dts support
From: Dafna Hirschfeld @ 2019-08-13 12:51 UTC (permalink / raw)
To: dafna.hirschfeld
Cc: mark.rutland, devicetree, ezequiel, s.hauer, linux-kernel,
Troy Kisky, Gary Bisson, robh+dt, kernel, kernel, shawnguo,
linux-arm-kernel
From: Gary Bisson <gary.bisson@boundarydevices.com>
Add basic dts support for i.MX8MQ NITROGEN8M.
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
[Dafna: porting vendor's code to mainline]
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../boot/dts/freescale/imx8mq-nitrogen.dts | 400 ++++++++++++++++++
2 files changed, 401 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mq-nitrogen.dts
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 8c0c4343e586..e2c6c93f47b6 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -25,6 +25,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mm-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr4-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-librem5-devkit.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mq-nitrogen.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-pico-pi.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-rmb3.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-zest.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-nitrogen.dts b/arch/arm64/boot/dts/freescale/imx8mq-nitrogen.dts
new file mode 100644
index 000000000000..da25ea9055cd
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mq-nitrogen.dts
@@ -0,0 +1,400 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2018 Boundary Devices
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/input/input.h>
+#include "imx8mq.dtsi"
+
+/ {
+ model = "Boundary Devices i.MX8MQ Nitrogen8M";
+ compatible = "boundary,imx8mq-nitrogen8m", "fsl,imx8mq";
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@40000000 {
+ device_type = "memory";
+ reg = <0x00000000 0x40000000 0 0x80000000>;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_keys>;
+
+ power {
+ label = "Power Button";
+ gpios = <&gpio1 7 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_POWER>;
+ gpio-key,wakeup;
+ };
+ };
+
+ reg_vref_0v9: regulator-vref-0v9 {
+ compatible = "regulator-fixed";
+ regulator-name = "vref-0v9";
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+ };
+
+ reg_vref_1v8: regulator-vref-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "vref-1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ reg_vref_2v5: regulator-vref-2v5 {
+ compatible = "regulator-fixed";
+ regulator-name = "vref-2v5";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ };
+
+ reg_vref_3v3: regulator-vref-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vref-3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ reg_vref_5v: regulator-vref-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "vref-5v";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+};
+
+
+&fec1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fec1>;
+ phy-mode = "rgmii-id";
+ phy-handle = <ðphy0>;
+ fsl,magic-packet;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@4 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <4>;
+ interrupts-extended = <&gpio1 11 IRQ_TYPE_LEVEL_LOW>;
+ };
+ };
+};
+
+&i2c1 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "okay";
+
+ i2cmux@70 {
+ compatible = "nxp,pca9546";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1_pca9546>;
+ reg = <0x70>;
+ reset-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c1a: i2c1@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg_arm_dram: regulator@60 {
+ compatible = "fcs,fan53555";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_arm_dram>;
+ reg = <0x60>;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-always-on;
+ vsel-gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ i2c1b: i2c1@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg_dram_1p1v: regulator@60 {
+ compatible = "fcs,fan53555";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_dram_1p1v>;
+ reg = <0x60>;
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-always-on;
+ vsel-gpios = <&gpio2 11 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ i2c1c: i2c1@2 {
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg_soc_gpu_vpu: regulator@60 {
+ compatible = "fcs,fan53555";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_soc_gpu_vpu>;
+ reg = <0x60>;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-always-on;
+ vsel-gpios = <&gpio2 20 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ i2c1d: i2c1@3 {
+ reg = <3>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ rtc@68 {
+ compatible = "microcrystal,rv4162";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1d_rv4162>;
+ reg = <0x68>;
+ interrupts-extended = <&gpio1 6 IRQ_TYPE_LEVEL_LOW>;
+ wakeup-source;
+ };
+ };
+ };
+};
+
+&uart1 { /* console */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ assigned-clocks = <&clk IMX8MQ_CLK_UART1>;
+ assigned-clock-parents = <&clk IMX8MQ_CLK_25M>;
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ assigned-clocks = <&clk IMX8MQ_CLK_UART2>;
+ assigned-clock-parents = <&clk IMX8MQ_CLK_25M>;
+ status = "okay";
+};
+
+&usdhc1 {
+ bus-width = <8>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ non-removable;
+ vmmc-supply = <®_vref_1v8>;
+ status = "okay";
+};
+
+&wdog1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
+ fsl,ext-reset-output;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hog>;
+ pinctrl_hog: hoggrp {
+ fsl,pins = <
+ /* J17 connector, odd */
+ MX8MQ_IOMUXC_SAI1_RXFS_GPIO4_IO0 0x19 /* Pin 19 */
+ MX8MQ_IOMUXC_SAI1_RXC_GPIO4_IO1 0x19 /* Pin 21 */
+ MX8MQ_IOMUXC_SAI1_RXD1_GPIO4_IO3 0x19 /* Pin 23 */
+ MX8MQ_IOMUXC_SAI1_RXD2_GPIO4_IO4 0x19 /* Pin 25 */
+ MX8MQ_IOMUXC_SAI1_RXD3_GPIO4_IO5 0x19 /* Pin 27 */
+ MX8MQ_IOMUXC_SAI1_RXD4_GPIO4_IO6 0x19 /* Pin 29 */
+ MX8MQ_IOMUXC_SAI1_RXD5_GPIO4_IO7 0x19 /* Pin 31 */
+ MX8MQ_IOMUXC_SAI1_RXD6_GPIO4_IO8 0x19 /* Pin 33 */
+ MX8MQ_IOMUXC_SAI1_RXD7_GPIO4_IO9 0x19 /* Pin 35 */
+ MX8MQ_IOMUXC_SAI1_TXD1_GPIO4_IO13 0x19 /* Pin 39 */
+ MX8MQ_IOMUXC_SAI1_TXD2_GPIO4_IO14 0x19 /* Pin 41 */
+ MX8MQ_IOMUXC_SAI1_TXD3_GPIO4_IO15 0x19 /* Pin 43 */
+ MX8MQ_IOMUXC_SAI1_TXD4_GPIO4_IO16 0x19 /* Pin 45 */
+ MX8MQ_IOMUXC_SAI1_TXD5_GPIO4_IO17 0x19 /* Pin 47 */
+ MX8MQ_IOMUXC_SAI1_TXD6_GPIO4_IO18 0x19 /* Pin 49 */
+ MX8MQ_IOMUXC_SAI1_TXD7_GPIO4_IO19 0x19 /* Pin 51 */
+
+ /* J17 connector, even */
+ MX8MQ_IOMUXC_SAI3_RXFS_GPIO4_IO28 0x19 /* Pin 44 */
+ MX8MQ_IOMUXC_SAI3_RXC_GPIO4_IO29 0x19 /* Pin 48 */
+ MX8MQ_IOMUXC_GPIO1_IO10_GPIO1_IO10 0x19 /* Pin 50 */
+ MX8MQ_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x19 /* Pin 54 */
+ MX8MQ_IOMUXC_GPIO1_IO05_GPIO1_IO5 0x19 /* Pin 56 */
+
+ /* J18 connector, odd */
+ MX8MQ_IOMUXC_NAND_CE3_B_GPIO3_IO4 0x19 /* Pin 41 */
+ MX8MQ_IOMUXC_NAND_CLE_GPIO3_IO5 0x19 /* Pin 43 */
+ MX8MQ_IOMUXC_NAND_READY_B_GPIO3_IO16 0x19 /* Pin 45 */
+ MX8MQ_IOMUXC_NAND_DATA05_GPIO3_IO11 0x19 /* Pin 47 */
+ MX8MQ_IOMUXC_NAND_WP_B_GPIO3_IO18 0x19 /* Pin 49 */
+ MX8MQ_IOMUXC_NAND_DQS_GPIO3_IO14 0x19 /* Pin 53 */
+
+ /* J18 connector, even */
+ MX8MQ_IOMUXC_NAND_ALE_GPIO3_IO0 0x19 /* Pin 32 */
+ MX8MQ_IOMUXC_NAND_CE0_B_GPIO3_IO1 0x19 /* Pin 36 */
+ MX8MQ_IOMUXC_NAND_DATA00_GPIO3_IO6 0x19 /* Pin 38 */
+ MX8MQ_IOMUXC_NAND_DATA01_GPIO3_IO7 0x19 /* Pin 40 */
+ MX8MQ_IOMUXC_NAND_DATA02_GPIO3_IO8 0x19 /* Pin 42 */
+ MX8MQ_IOMUXC_NAND_DATA03_GPIO3_IO9 0x19 /* Pin 44 */
+ MX8MQ_IOMUXC_NAND_DATA04_GPIO3_IO10 0x19 /* Pin 46 */
+
+ /* J13 Pin 2, WL_WAKE */
+ MX8MQ_IOMUXC_SAI5_RXD2_GPIO3_IO23 0xd6
+ /* J13 Pin 4, WL_IRQ, not needed for Silex */
+ MX8MQ_IOMUXC_SAI5_RXD0_GPIO3_IO21 0xd6
+ /* J13 pin 9, unused */
+ MX8MQ_IOMUXC_SD2_CD_B_GPIO2_IO12 0x19
+ /* J13 Pin 41, BT_CLK_REQ */
+ MX8MQ_IOMUXC_SAI5_RXD1_GPIO3_IO22 0xd6
+ /* J13 Pin 42, BT_HOST_WAKE */
+ MX8MQ_IOMUXC_SAI5_MCLK_GPIO3_IO25 0xd6
+
+ /* Clock for both CSI1 and CSI2 */
+ MX8MQ_IOMUXC_GPIO1_IO15_CCMSRCGPCMIX_CLKO2 0x07
+ /* test points */
+ MX8MQ_IOMUXC_GPIO1_IO04_GPIO1_IO4 0xc1 /* TP87 */
+ >;
+ };
+
+ pinctrl_fec1: fec1grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_ENET_MDC_ENET1_MDC 0x3
+ MX8MQ_IOMUXC_ENET_MDIO_ENET1_MDIO 0x23
+ MX8MQ_IOMUXC_ENET_TX_CTL_ENET1_RGMII_TX_CTL 0x1f
+ MX8MQ_IOMUXC_ENET_TXC_ENET1_RGMII_TXC 0x1f
+ MX8MQ_IOMUXC_ENET_TD0_ENET1_RGMII_TD0 0x1f
+ MX8MQ_IOMUXC_ENET_TD1_ENET1_RGMII_TD1 0x1f
+ MX8MQ_IOMUXC_ENET_TD2_ENET1_RGMII_TD2 0x1f
+ MX8MQ_IOMUXC_ENET_TD3_ENET1_RGMII_TD3 0x1f
+ MX8MQ_IOMUXC_ENET_RX_CTL_ENET1_RGMII_RX_CTL 0x91
+ MX8MQ_IOMUXC_ENET_RXC_ENET1_RGMII_RXC 0x91
+ MX8MQ_IOMUXC_ENET_RD0_ENET1_RGMII_RD0 0x91
+ MX8MQ_IOMUXC_ENET_RD1_ENET1_RGMII_RD1 0x91
+ MX8MQ_IOMUXC_ENET_RD2_ENET1_RGMII_RD2 0x91
+ MX8MQ_IOMUXC_ENET_RD3_ENET1_RGMII_RD3 0x91
+ MX8MQ_IOMUXC_GPIO1_IO09_GPIO1_IO9 0x19
+ MX8MQ_IOMUXC_GPIO1_IO11_GPIO1_IO11 0x59
+ >;
+ };
+
+ pinctrl_gpio_keys: gpio-keysgrp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_GPIO1_IO07_GPIO1_IO7 0x19
+ >;
+ };
+
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_I2C1_SCL_I2C1_SCL 0x4000007f
+ MX8MQ_IOMUXC_I2C1_SDA_I2C1_SDA 0x4000007f
+ >;
+ };
+
+ pinctrl_i2c1_pca9546: i2c1-pca9546grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_GPIO1_IO08_GPIO1_IO8 0x49
+ >;
+ };
+
+ pinctrl_i2c1d_rv4162: i2c1d-rv4162grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_GPIO1_IO06_GPIO1_IO6 0x49
+ >;
+ };
+
+ pinctrl_reg_arm_dram: reg-arm-dram {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SAI5_RXD3_GPIO3_IO24 0x16
+ >;
+ };
+
+ pinctrl_reg_dram_1p1v: reg-dram-1p1v {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD1_STROBE_GPIO2_IO11 0x16
+ >;
+ };
+
+ pinctrl_reg_soc_gpu_vpu: reg-soc-gpu-vpu {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD2_WP_GPIO2_IO20 0x16
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_UART1_RXD_UART1_DCE_RX 0x45
+ MX8MQ_IOMUXC_UART1_TXD_UART1_DCE_TX 0x45
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_UART2_RXD_UART2_DCE_RX 0x45
+ MX8MQ_IOMUXC_UART2_TXD_UART2_DCE_TX 0x45
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x83
+ MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xc3
+ MX8MQ_IOMUXC_SD1_DATA0_USDHC1_DATA0 0xc3
+ MX8MQ_IOMUXC_SD1_DATA1_USDHC1_DATA1 0xc3
+ MX8MQ_IOMUXC_SD1_DATA2_USDHC1_DATA2 0xc3
+ MX8MQ_IOMUXC_SD1_DATA3_USDHC1_DATA3 0xc3
+ MX8MQ_IOMUXC_SD1_DATA4_USDHC1_DATA4 0xc3
+ MX8MQ_IOMUXC_SD1_DATA5_USDHC1_DATA5 0xc3
+ MX8MQ_IOMUXC_SD1_DATA6_USDHC1_DATA6 0xc3
+ MX8MQ_IOMUXC_SD1_DATA7_USDHC1_DATA7 0xc3
+ MX8MQ_IOMUXC_SD1_RESET_B_GPIO2_IO10 0x41
+ >;
+ };
+
+ pinctrl_usdhc1_100mhz: usdhc1grp100mhz {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x8d
+ MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xcd
+ MX8MQ_IOMUXC_SD1_DATA0_USDHC1_DATA0 0xcd
+ MX8MQ_IOMUXC_SD1_DATA1_USDHC1_DATA1 0xcd
+ MX8MQ_IOMUXC_SD1_DATA2_USDHC1_DATA2 0xcd
+ MX8MQ_IOMUXC_SD1_DATA3_USDHC1_DATA3 0xcd
+ MX8MQ_IOMUXC_SD1_DATA4_USDHC1_DATA4 0xcd
+ MX8MQ_IOMUXC_SD1_DATA5_USDHC1_DATA5 0xcd
+ MX8MQ_IOMUXC_SD1_DATA6_USDHC1_DATA6 0xcd
+ MX8MQ_IOMUXC_SD1_DATA7_USDHC1_DATA7 0xcd
+ >;
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1grp200mhz {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x9f
+ MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xdf
+ MX8MQ_IOMUXC_SD1_DATA0_USDHC1_DATA0 0xdf
+ MX8MQ_IOMUXC_SD1_DATA1_USDHC1_DATA1 0xdf
+ MX8MQ_IOMUXC_SD1_DATA2_USDHC1_DATA2 0xdf
+ MX8MQ_IOMUXC_SD1_DATA3_USDHC1_DATA3 0xdf
+ MX8MQ_IOMUXC_SD1_DATA4_USDHC1_DATA4 0xdf
+ MX8MQ_IOMUXC_SD1_DATA5_USDHC1_DATA5 0xdf
+ MX8MQ_IOMUXC_SD1_DATA6_USDHC1_DATA6 0xdf
+ MX8MQ_IOMUXC_SD1_DATA7_USDHC1_DATA7 0xdf
+ >;
+ };
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B 0xc6
+ >;
+ };
+};
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 1/2] dt-bindings: arm: imx: add imx8mq nitrogen support
From: Dafna Hirschfeld @ 2019-08-13 12:51 UTC (permalink / raw)
To: dafna.hirschfeld
Cc: mark.rutland, devicetree, ezequiel, s.hauer, linux-kernel,
Troy Kisky, Gary Bisson, robh+dt, kernel, kernel, shawnguo,
linux-arm-kernel
In-Reply-To: <20190813125147.29605-1-dafna.hirschfeld@collabora.com>
From: Gary Bisson <gary.bisson@boundarydevices.com>
The Nitrogen8M is an ARM based single board computer (SBC)
designed to leverage the full capabilities of NXP’s i.MX8M
Quad processor.
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
[Dafna: porting vendor's code to mainline]
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
---
Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 362bf827cad1..16db1c699ba7 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -224,6 +224,7 @@ properties:
- description: i.MX8MQ based Boards
items:
- enum:
+ - boundary,imx8mq-nitrogen8m # i.MX8MQ NITROGEN Board
- fsl,imx8mq-evk # i.MX8MQ EVK Board
- purism,librem5-devkit # Purism Librem5 devkit
- technexion,pico-pi-imx8m # TechNexion PICO-PI-8M evk
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 5/5] ARM: dts: sunxi: Add missing watchdog interrupts
From: Maxime Ripard @ 2019-08-13 12:47 UTC (permalink / raw)
To: linux, wim
Cc: Mark Rutland, devicetree, Maxime Ripard, linux-kernel,
Maxime Ripard, Chen-Yu Tsai, Rob Herring, Frank Rowand,
linux-arm-kernel
In-Reply-To: <20190813124744.32614-1-mripard@kernel.org>
From: Maxime Ripard <maxime.ripard@bootlin.com>
The watchdog has an interrupt on all our SoCs, but it wasn't always listed.
Add it to the devicetree where it's missing.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
arch/arm/boot/dts/sun4i-a10.dtsi | 1 +
arch/arm/boot/dts/sun5i.dtsi | 1 +
arch/arm/boot/dts/sun6i-a31.dtsi | 1 +
arch/arm/boot/dts/sun7i-a20.dtsi | 1 +
arch/arm/boot/dts/sun8i-r40.dtsi | 1 +
5 files changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index 077d45c7db6f..eed9fcb46185 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -815,6 +815,7 @@
wdt: watchdog@1c20c90 {
compatible = "allwinner,sun4i-a10-wdt";
reg = <0x01c20c90 0x10>;
+ interrupts = <24>;
};
rtc: rtc@1c20d00 {
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index 4e725afe7203..29a825f7afd1 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -600,6 +600,7 @@
wdt: watchdog@1c20c90 {
compatible = "allwinner,sun4i-a10-wdt";
reg = <0x01c20c90 0x10>;
+ interrupts = <24>;
};
ir0: ir@1c21800 {
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 916f99db6206..b32d2d7cad4e 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -744,6 +744,7 @@
wdt1: watchdog@1c20ca0 {
compatible = "allwinner,sun6i-a31-wdt";
reg = <0x01c20ca0 0x20>;
+ interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
};
spdif: spdif@1c21000 {
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 9ad8e445b240..aeb682e757f2 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -1115,6 +1115,7 @@
wdt: watchdog@1c20c90 {
compatible = "allwinner,sun4i-a10-wdt";
reg = <0x01c20c90 0x10>;
+ interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
};
rtc: rtc@1c20d00 {
diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi b/arch/arm/boot/dts/sun8i-r40.dtsi
index 09e20768228c..f1be554b5894 100644
--- a/arch/arm/boot/dts/sun8i-r40.dtsi
+++ b/arch/arm/boot/dts/sun8i-r40.dtsi
@@ -404,6 +404,7 @@
wdt: watchdog@1c20c90 {
compatible = "allwinner,sun4i-a10-wdt";
reg = <0x01c20c90 0x10>;
+ interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
};
uart0: serial@1c28000 {
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 4/5] ARM: dts: sun8i: a83t: Remove the watchdog clock
From: Maxime Ripard @ 2019-08-13 12:47 UTC (permalink / raw)
To: linux, wim
Cc: Mark Rutland, devicetree, Maxime Ripard, linux-kernel,
Maxime Ripard, Chen-Yu Tsai, Rob Herring, Frank Rowand,
linux-arm-kernel
In-Reply-To: <20190813124744.32614-1-mripard@kernel.org>
From: Maxime Ripard <maxime.ripard@bootlin.com>
The watchdog binding doesn't define a clock, and it indeed looks like
there's no explicit clock feeding it.
Let's remove it from our DT.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 523be6611c50..15f8c80f69a5 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -817,7 +817,6 @@
compatible = "allwinner,sun6i-a31-wdt";
reg = <0x01c20ca0 0x20>;
interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&osc24M>;
};
spdif: spdif@1c21000 {
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/5] dt-bindings: watchdog: sun4i: Add the watchdog interrupts
From: Maxime Ripard @ 2019-08-13 12:47 UTC (permalink / raw)
To: linux, wim
Cc: Mark Rutland, devicetree, Maxime Ripard, linux-kernel,
Maxime Ripard, Chen-Yu Tsai, Rob Herring, Frank Rowand,
linux-arm-kernel
In-Reply-To: <20190813124744.32614-1-mripard@kernel.org>
From: Maxime Ripard <maxime.ripard@bootlin.com>
The Allwinner watchdog has an interrupt, either shared or dedicated
depending on the SoC, that has been described in some DT, but not all of
them.
The binding is also completely missing that description. Let's add that
property to be consistent.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
.../bindings/watchdog/allwinner,sun4i-a10-wdt.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml b/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml
index 93df27ec1664..4ace89f129b4 100644
--- a/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml
@@ -28,6 +28,9 @@ properties:
reg:
maxItems: 1
+ interrupts:
+ maxItems: 1
+
timeout-sec:
$ref: /schemas/types.yaml#/definitions/uint32
description:
@@ -36,6 +39,7 @@ properties:
required:
- compatible
- reg
+ - interrupts
additionalProperties: false
@@ -44,6 +48,7 @@ examples:
wdt: watchdog@1c20c90 {
compatible = "allwinner,sun4i-a10-wdt";
reg = <0x01c20c90 0x10>;
+ interrupts = <24>;
timeout-sec = <10>;
};
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/5] dt-bindings: watchdog: Convert Allwinner watchdog to a schema
From: Maxime Ripard @ 2019-08-13 12:47 UTC (permalink / raw)
To: linux, wim
Cc: Mark Rutland, devicetree, Maxime Ripard, linux-kernel,
Maxime Ripard, Chen-Yu Tsai, Rob Herring, Frank Rowand,
linux-arm-kernel
In-Reply-To: <20190813124744.32614-1-mripard@kernel.org>
From: Maxime Ripard <maxime.ripard@bootlin.com>
The Allwinner SoCs have a watchdog supported in Linux, with a matching
Device Tree binding.
Now that we have the DT validation in place, let's convert the device tree
bindings for that controller over to a YAML schemas.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
.../watchdog/allwinner,sun4i-a10-wdt.yaml | 50 +++++++++++++++++++
.../bindings/watchdog/sunxi-wdt.txt | 22 --------
2 files changed, 50 insertions(+), 22 deletions(-)
create mode 100644 Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml
delete mode 100644 Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml b/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml
new file mode 100644
index 000000000000..93df27ec1664
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/allwinner,sun4i-a10-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner A10 Watchdog Device Tree Bindings
+
+maintainers:
+ - Chen-Yu Tsai <wens@csie.org>
+ - Maxime Ripard <maxime.ripard@bootlin.com>
+
+properties:
+ compatible:
+ oneOf:
+ - const: allwinner,sun4i-a10-wdt
+ - const: allwinner,sun6i-a31-wdt
+ - items:
+ - const: allwinner,sun50i-a64-wdt
+ - const: allwinner,sun6i-a31-wdt
+ - items:
+ - const: allwinner,sun50i-h6-wdt
+ - const: allwinner,sun6i-a31-wdt
+ - items:
+ - const: allwinner,suniv-f1c100s-wdt
+ - const: allwinner,sun4i-a10-wdt
+
+ reg:
+ maxItems: 1
+
+ timeout-sec:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Contains the watchdog timeout in seconds.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ wdt: watchdog@1c20c90 {
+ compatible = "allwinner,sun4i-a10-wdt";
+ reg = <0x01c20c90 0x10>;
+ timeout-sec = <10>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt b/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt
deleted file mode 100644
index e65198d82a2b..000000000000
--- a/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-Allwinner SoCs Watchdog timer
-
-Required properties:
-
-- compatible : should be one of
- "allwinner,sun4i-a10-wdt"
- "allwinner,sun6i-a31-wdt"
- "allwinner,sun50i-a64-wdt","allwinner,sun6i-a31-wdt"
- "allwinner,sun50i-h6-wdt","allwinner,sun6i-a31-wdt"
- "allwinner,suniv-f1c100s-wdt", "allwinner,sun4i-a10-wdt"
-- reg : Specifies base physical address and size of the registers.
-
-Optional properties:
-- timeout-sec : Contains the watchdog timeout in seconds
-
-Example:
-
-wdt: watchdog@1c20c90 {
- compatible = "allwinner,sun4i-a10-wdt";
- reg = <0x01c20c90 0x10>;
- timeout-sec = <10>;
-};
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/5] dt-bindings: mfd: Convert Allwinner GPADC bindings to a schema
From: Maxime Ripard @ 2019-08-13 12:47 UTC (permalink / raw)
To: linux, wim
Cc: Mark Rutland, devicetree, Maxime Ripard, linux-kernel,
Maxime Ripard, Chen-Yu Tsai, Rob Herring, Frank Rowand,
linux-arm-kernel
From: Maxime Ripard <maxime.ripard@bootlin.com>
The Allwinner SoCs have an embedded GPADC that is doing thermal reading as
well, supported in Linux, with a matching Device Tree binding.
Now that we have the DT validation in place, let's convert the device tree
bindings for that controller over to a YAML schemas.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
.../iio/adc/allwinner,sun8i-a33-ths.yaml | 43 +++++++++++
.../bindings/mfd/allwinner,sun4i-a10-ts.yaml | 76 +++++++++++++++++++
.../devicetree/bindings/mfd/sun4i-gpadc.txt | 59 --------------
3 files changed, 119 insertions(+), 59 deletions(-)
create mode 100644 Documentation/devicetree/bindings/iio/adc/allwinner,sun8i-a33-ths.yaml
create mode 100644 Documentation/devicetree/bindings/mfd/allwinner,sun4i-a10-ts.yaml
delete mode 100644 Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/allwinner,sun8i-a33-ths.yaml b/Documentation/devicetree/bindings/iio/adc/allwinner,sun8i-a33-ths.yaml
new file mode 100644
index 000000000000..d74962c0f5ae
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/allwinner,sun8i-a33-ths.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/allwinner,sun8i-a33-ths.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner A33 Thermal Sensor Device Tree Bindings
+
+maintainers:
+ - Chen-Yu Tsai <wens@csie.org>
+ - Maxime Ripard <maxime.ripard@bootlin.com>
+
+properties:
+ "#io-channel-cells":
+ const: 0
+
+ "#thermal-sensor-cells":
+ const: 0
+
+ compatible:
+ const: allwinner,sun8i-a33-ths
+
+ reg:
+ maxItems: 1
+
+required:
+ - "#io-channel-cells"
+ - "#thermal-sensor-cells"
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ ths: ths@1c25000 {
+ compatible = "allwinner,sun8i-a33-ths";
+ reg = <0x01c25000 0x100>;
+ #thermal-sensor-cells = <0>;
+ #io-channel-cells = <0>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/mfd/allwinner,sun4i-a10-ts.yaml b/Documentation/devicetree/bindings/mfd/allwinner,sun4i-a10-ts.yaml
new file mode 100644
index 000000000000..4b1a09acb98b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/allwinner,sun4i-a10-ts.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/allwinner,sun4i-a10-ts.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner A10 Resistive Touchscreen Controller Device Tree Bindings
+
+maintainers:
+ - Chen-Yu Tsai <wens@csie.org>
+ - Maxime Ripard <maxime.ripard@bootlin.com>
+
+properties:
+ "#thermal-sensor-cells":
+ const: 0
+
+ compatible:
+ enum:
+ - allwinner,sun4i-a10-ts
+ - allwinner,sun5i-a13-ts
+ - allwinner,sun6i-a31-ts
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ allwinner,ts-attached:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: A touchscreen is attached to the controller
+
+ allwinner,tp-sensitive-adjust:
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - minimum: 0
+ maximum: 15
+ default: 15
+ description: Sensitivity of pen down detection
+
+ allwinner,filter-type:
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - minimum: 0
+ maximum: 3
+ default: 1
+ description: |
+ Select median and averaging filter. Sample used for median /
+ averaging filter:
+ 0: 4/2
+ 1: 5/3
+ 2: 8/4
+ 3: 16/8
+
+required:
+ - "#thermal-sensor-cells"
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ rtp: rtp@1c25000 {
+ compatible = "allwinner,sun4i-a10-ts";
+ reg = <0x01c25000 0x100>;
+ interrupts = <29>;
+ allwinner,ts-attached;
+ #thermal-sensor-cells = <0>;
+ /* sensitive/noisy touch panel */
+ allwinner,tp-sensitive-adjust = <0>;
+ allwinner,filter-type = <3>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
deleted file mode 100644
index 86dd8191b04c..000000000000
--- a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
+++ /dev/null
@@ -1,59 +0,0 @@
-Allwinner SoCs' GPADC Device Tree bindings
-------------------------------------------
-The Allwinner SoCs all have an ADC that can also act as a thermal sensor
-and sometimes as a touchscreen controller.
-
-Required properties:
- - compatible: "allwinner,sun8i-a33-ths",
- - reg: mmio address range of the chip,
- - #thermal-sensor-cells: shall be 0,
- - #io-channel-cells: shall be 0,
-
-Example:
- ths: ths@1c25000 {
- compatible = "allwinner,sun8i-a33-ths";
- reg = <0x01c25000 0x100>;
- #thermal-sensor-cells = <0>;
- #io-channel-cells = <0>;
- };
-
-sun4i, sun5i and sun6i SoCs are also supported via the older binding:
-
-sun4i resistive touchscreen controller
---------------------------------------
-
-Required properties:
- - compatible: "allwinner,sun4i-a10-ts", "allwinner,sun5i-a13-ts" or
- "allwinner,sun6i-a31-ts"
- - reg: mmio address range of the chip
- - interrupts: interrupt to which the chip is connected
- - #thermal-sensor-cells: shall be 0
-
-Optional properties:
- - allwinner,ts-attached : boolean indicating that an actual touchscreen
- is attached to the controller
- - allwinner,tp-sensitive-adjust : integer (4 bits)
- adjust sensitivity of pen down detection
- between 0 (least sensitive) and 15
- (defaults to 15)
- - allwinner,filter-type : integer (2 bits)
- select median and averaging filter
- samples used for median / averaging filter
- 0: 4/2
- 1: 5/3
- 2: 8/4
- 3: 16/8
- (defaults to 1)
-
-Example:
-
- rtp: rtp@1c25000 {
- compatible = "allwinner,sun4i-a10-ts";
- reg = <0x01c25000 0x100>;
- interrupts = <29>;
- allwinner,ts-attached;
- #thermal-sensor-cells = <0>;
- /* sensitive/noisy touch panel */
- allwinner,tp-sensitive-adjust = <0>;
- allwinner,filter-type = <3>;
- };
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/2] dt-bindings: media: Convert Allwinner A10 IR to a schema
From: Maxime Ripard @ 2019-08-13 12:45 UTC (permalink / raw)
To: mchehab, sean
Cc: Mark Rutland, devicetree, Maxime Ripard, linux-kernel,
Maxime Ripard, Chen-Yu Tsai, Rob Herring, Frank Rowand,
linux-arm-kernel, linux-media
In-Reply-To: <20190813124513.31413-1-mripard@kernel.org>
From: Maxime Ripard <maxime.ripard@bootlin.com>
The older Allwinner SoCs have a IR receiver supported in Linux, with a
matching Device Tree binding.
Now that we have the DT validation in place, let's convert the device tree
bindings for that controller over to a YAML schemas.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
.../media/allwinner,sun4i-a10-ir.yaml | 80 +++++++++++++++++++
.../devicetree/bindings/media/sunxi-ir.txt | 35 --------
2 files changed, 80 insertions(+), 35 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml
delete mode 100644 Documentation/devicetree/bindings/media/sunxi-ir.txt
diff --git a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml
new file mode 100644
index 000000000000..98c1bdde9a86
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/allwinner,sun4i-a10-ir.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner A10 Infrared Controller Device Tree Bindings
+
+maintainers:
+ - Chen-Yu Tsai <wens@csie.org>
+ - Maxime Ripard <maxime.ripard@bootlin.com>
+
+allOf:
+ - $ref: "rc.yaml#"
+
+properties:
+ compatible:
+ oneOf:
+ - const: allwinner,sun4i-a10-ir
+ - const: allwinner,sun5i-a13-ir
+ - items:
+ - const: allwinner,sun8i-a83t-ir
+ - const: allwinner,sun6i-a31-ir
+ - const: allwinner,sun6i-a31-ir
+ - items:
+ - const: allwinner,sun50i-a64-ir
+ - const: allwinner,sun6i-a31-ir
+ - items:
+ - const: allwinner,sun50i-h6-ir
+ - const: allwinner,sun6i-a31-ir
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Bus Clock
+ - description: Module Clock
+
+ clock-names:
+ items:
+ - const: apb
+ - const: ir
+
+ resets:
+ maxItems: 1
+
+ clock-frequency:
+ default: 8000000
+ description:
+ IR Receiver clock frequency, in Hertz.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+# FIXME: We should set it, but it would report all the generic
+# properties as additional properties.
+# additionalProperties: false
+
+examples:
+ - |
+ ir0: ir@1c21800 {
+ compatible = "allwinner,sun4i-a10-ir";
+ clocks = <&apb0_gates 6>, <&ir0_clk>;
+ clock-names = "apb", "ir";
+ clock-frequency = <3000000>;
+ resets = <&apb0_rst 1>;
+ interrupts = <0 5 1>;
+ reg = <0x01C21800 0x40>;
+ linux,rc-map-name = "rc-rc6-mce";
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt b/Documentation/devicetree/bindings/media/sunxi-ir.txt
deleted file mode 100644
index 81eaf95fb764..000000000000
--- a/Documentation/devicetree/bindings/media/sunxi-ir.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-Device-Tree bindings for SUNXI IR controller found in sunXi SoC family
-
-Required properties:
-- compatible :
- "allwinner,sun4i-a10-ir"
- "allwinner,sun5i-a13-ir"
- "allwinner,sun6i-a31-ir"
- "allwinner,sun50i-a64-ir", "allwinner,sun6i-a31-ir"
- "allwinner,sun50i-h6-ir", "allwinner,sun6i-a31-ir"
-- clocks : list of clock specifiers, corresponding to
- entries in clock-names property;
-- clock-names : should contain "apb" and "ir" entries;
-- interrupts : should contain IR IRQ number;
-- reg : should contain IO map address for IR.
-
-Required properties since A31:
-- resets : phandle + reset specifier pair
-
-Optional properties:
-- linux,rc-map-name: see rc.txt file in the same directory.
-- clock-frequency : IR Receiver clock frequency, in Hertz. Defaults to 8 MHz
- if missing.
-
-Example:
-
-ir0: ir@1c21800 {
- compatible = "allwinner,sun4i-a10-ir";
- clocks = <&apb0_gates 6>, <&ir0_clk>;
- clock-names = "apb", "ir";
- clock-frequency = <3000000>;
- resets = <&apb0_rst 1>;
- interrupts = <0 5 1>;
- reg = <0x01C21800 0x40>;
- linux,rc-map-name = "rc-rc6-mce";
-};
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: media: Add YAML schemas for the generic RC bindings
From: Maxime Ripard @ 2019-08-13 12:45 UTC (permalink / raw)
To: mchehab, sean
Cc: Mark Rutland, devicetree, Maxime Ripard, linux-kernel,
Maxime Ripard, Chen-Yu Tsai, Rob Herring, Frank Rowand,
linux-arm-kernel, linux-media
From: Maxime Ripard <maxime.ripard@bootlin.com>
The RC controllers have a bunch of generic properties that are needed in a
device tree. Add a YAML schemas for those.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
.../devicetree/bindings/media/rc.txt | 118 +--------------
.../devicetree/bindings/media/rc.yaml | 135 ++++++++++++++++++
2 files changed, 136 insertions(+), 117 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/rc.yaml
diff --git a/Documentation/devicetree/bindings/media/rc.txt b/Documentation/devicetree/bindings/media/rc.txt
index d3e7a012bfda..be629f7fa77e 100644
--- a/Documentation/devicetree/bindings/media/rc.txt
+++ b/Documentation/devicetree/bindings/media/rc.txt
@@ -1,117 +1 @@
-The following properties are common to the infrared remote controllers:
-
-- linux,rc-map-name: string, specifies the scancode/key mapping table
- defined in-kernel for the remote controller. Support values are:
- * "rc-adstech-dvb-t-pci"
- * "rc-alink-dtu-m"
- * "rc-anysee"
- * "rc-apac-viewcomp"
- * "rc-asus-pc39"
- * "rc-asus-ps3-100"
- * "rc-ati-tv-wonder-hd-600"
- * "rc-ati-x10"
- * "rc-avermedia-a16d"
- * "rc-avermedia-cardbus"
- * "rc-avermedia-dvbt"
- * "rc-avermedia-m135a"
- * "rc-avermedia-m733a-rm-k6"
- * "rc-avermedia-rm-ks"
- * "rc-avermedia"
- * "rc-avertv-303"
- * "rc-azurewave-ad-tu700"
- * "rc-behold-columbus"
- * "rc-behold"
- * "rc-budget-ci-old"
- * "rc-cec"
- * "rc-cinergy-1400"
- * "rc-cinergy"
- * "rc-delock-61959"
- * "rc-dib0700-nec"
- * "rc-dib0700-rc5"
- * "rc-digitalnow-tinytwin"
- * "rc-digittrade"
- * "rc-dm1105-nec"
- * "rc-dntv-live-dvbt-pro"
- * "rc-dntv-live-dvb-t"
- * "rc-dtt200u"
- * "rc-dvbsky"
- * "rc-empty"
- * "rc-em-terratec"
- * "rc-encore-enltv2"
- * "rc-encore-enltv-fm53"
- * "rc-encore-enltv"
- * "rc-evga-indtube"
- * "rc-eztv"
- * "rc-flydvb"
- * "rc-flyvideo"
- * "rc-fusionhdtv-mce"
- * "rc-gadmei-rm008z"
- * "rc-geekbox"
- * "rc-genius-tvgo-a11mce"
- * "rc-gotview7135"
- * "rc-hauppauge"
- * "rc-imon-mce"
- * "rc-imon-pad"
- * "rc-iodata-bctv7e"
- * "rc-it913x-v1"
- * "rc-it913x-v2"
- * "rc-kaiomy"
- * "rc-kworld-315u"
- * "rc-kworld-pc150u"
- * "rc-kworld-plus-tv-analog"
- * "rc-leadtek-y04g0051"
- * "rc-lirc"
- * "rc-lme2510"
- * "rc-manli"
- * "rc-medion-x10"
- * "rc-medion-x10-digitainer"
- * "rc-medion-x10-or2x"
- * "rc-msi-digivox-ii"
- * "rc-msi-digivox-iii"
- * "rc-msi-tvanywhere-plus"
- * "rc-msi-tvanywhere"
- * "rc-nebula"
- * "rc-nec-terratec-cinergy-xs"
- * "rc-norwood"
- * "rc-npgtech"
- * "rc-pctv-sedna"
- * "rc-pinnacle-color"
- * "rc-pinnacle-grey"
- * "rc-pinnacle-pctv-hd"
- * "rc-pixelview-new"
- * "rc-pixelview"
- * "rc-pixelview-002t"
- * "rc-pixelview-mk12"
- * "rc-powercolor-real-angel"
- * "rc-proteus-2309"
- * "rc-purpletv"
- * "rc-pv951"
- * "rc-hauppauge"
- * "rc-rc5-tv"
- * "rc-rc6-mce"
- * "rc-real-audio-220-32-keys"
- * "rc-reddo"
- * "rc-snapstream-firefly"
- * "rc-streamzap"
- * "rc-tbs-nec"
- * "rc-technisat-ts35"
- * "rc-technisat-usb2"
- * "rc-terratec-cinergy-c-pci"
- * "rc-terratec-cinergy-s2-hd"
- * "rc-terratec-cinergy-xs"
- * "rc-terratec-slim"
- * "rc-terratec-slim-2"
- * "rc-tevii-nec"
- * "rc-tivo"
- * "rc-total-media-in-hand"
- * "rc-total-media-in-hand-02"
- * "rc-trekstor"
- * "rc-tt-1500"
- * "rc-twinhan-dtv-cab-ci"
- * "rc-twinhan1027"
- * "rc-videomate-k100"
- * "rc-videomate-s350"
- * "rc-videomate-tv-pvr"
- * "rc-winfast"
- * "rc-winfast-usbii-deluxe"
- * "rc-su3000"
+This file has been moved to rc.yaml.
diff --git a/Documentation/devicetree/bindings/media/rc.yaml b/Documentation/devicetree/bindings/media/rc.yaml
new file mode 100644
index 000000000000..19b28e7edf9c
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rc.yaml
@@ -0,0 +1,135 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/rc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic Infrared Remote Controller Device Tree Bindings
+
+maintainers:
+ - Mauro Carvalho Chehab <mchehab@kernel.org>
+ - Sean Young <sean@mess.org>
+
+properties:
+ $nodename:
+ pattern: "^ir(@[a-f0-9]+)?$"
+
+ linux,rc-map-name:
+ description:
+ Specifies the scancode/key mapping table defined in-kernel for
+ the remote controller.
+ allOf:
+ - $ref: '/schemas/types.yaml#/definitions/string'
+ - enum:
+ - rc-adstech-dvb-t-pci
+ - rc-alink-dtu-m
+ - rc-anysee
+ - rc-apac-viewcomp
+ - rc-asus-pc39
+ - rc-asus-ps3-100
+ - rc-ati-tv-wonder-hd-600
+ - rc-ati-x10
+ - rc-avermedia
+ - rc-avermedia-a16d
+ - rc-avermedia-cardbus
+ - rc-avermedia-dvbt
+ - rc-avermedia-m135a
+ - rc-avermedia-m733a-rm-k6
+ - rc-avermedia-rm-ks
+ - rc-avertv-303
+ - rc-azurewave-ad-tu700
+ - rc-behold
+ - rc-behold-columbus
+ - rc-budget-ci-old
+ - rc-cec
+ - rc-cinergy
+ - rc-cinergy-1400
+ - rc-delock-61959
+ - rc-dib0700-nec
+ - rc-dib0700-rc5
+ - rc-digitalnow-tinytwin
+ - rc-digittrade
+ - rc-dm1105-nec
+ - rc-dntv-live-dvb-t
+ - rc-dntv-live-dvbt-pro
+ - rc-dtt200u
+ - rc-dvbsky
+ - rc-em-terratec
+ - rc-empty
+ - rc-encore-enltv
+ - rc-encore-enltv-fm53
+ - rc-encore-enltv2
+ - rc-evga-indtube
+ - rc-eztv
+ - rc-flydvb
+ - rc-flyvideo
+ - rc-fusionhdtv-mce
+ - rc-gadmei-rm008z
+ - rc-geekbox
+ - rc-genius-tvgo-a11mce
+ - rc-gotview7135
+ - rc-hauppauge
+ - rc-imon-mce
+ - rc-imon-pad
+ - rc-iodata-bctv7e
+ - rc-it913x-v1
+ - rc-it913x-v2
+ - rc-kaiomy
+ - rc-kworld-315u
+ - rc-kworld-pc150u
+ - rc-kworld-plus-tv-analog
+ - rc-leadtek-y04g0051
+ - rc-lirc
+ - rc-lme2510
+ - rc-manli
+ - rc-medion-x10
+ - rc-medion-x10-digitainer
+ - rc-medion-x10-or2x
+ - rc-msi-digivox-ii
+ - rc-msi-digivox-iii
+ - rc-msi-tvanywhere
+ - rc-msi-tvanywhere-plus
+ - rc-nebula
+ - rc-nec-terratec-cinergy-xs
+ - rc-norwood
+ - rc-npgtech
+ - rc-pctv-sedna
+ - rc-pinnacle-color
+ - rc-pinnacle-grey
+ - rc-pinnacle-pctv-hd
+ - rc-pixelview
+ - rc-pixelview-002t
+ - rc-pixelview-mk12
+ - rc-pixelview-new
+ - rc-powercolor-real-angel
+ - rc-proteus-2309
+ - rc-purpletv
+ - rc-pv951
+ - rc-rc5-tv
+ - rc-rc6-mce
+ - rc-real-audio-220-32-keys
+ - rc-reddo
+ - rc-snapstream-firefly
+ - rc-streamzap
+ - rc-su3000
+ - rc-tbs-nec
+ - rc-technisat-ts35
+ - rc-technisat-usb2
+ - rc-terratec-cinergy-c-pci
+ - rc-terratec-cinergy-s2-hd
+ - rc-terratec-cinergy-xs
+ - rc-terratec-slim
+ - rc-terratec-slim-2
+ - rc-tevii-nec
+ - rc-tivo
+ - rc-total-media-in-hand
+ - rc-total-media-in-hand-02
+ - rc-trekstor
+ - rc-tt-1500
+ - rc-twinhan-dtv-cab-ci
+ - rc-twinhan1027
+ - rc-videomate-k100
+ - rc-videomate-s350
+ - rc-videomate-tv-pvr
+ - rc-winfast
+ - rc-winfast-usbii-deluxe
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH V5 00/12] 52-bit kernel + user VAs
From: Geert Uytterhoeven @ 2019-08-13 12:43 UTC (permalink / raw)
To: Will Deacon, Steve Capper
Cc: crecklin, Ard Biesheuvel, Catalin Marinas, bhsharma,
Linux-Renesas, maz, Linux ARM
In-Reply-To: <20190809164716.qtt7zizfbqyjukwe@willie-the-truck>
Hi Will, Steve,
On Fri, Aug 9, 2019 at 6:47 PM Will Deacon <will@kernel.org> wrote:
> On Wed, Aug 07, 2019 at 04:55:12PM +0100, Steve Capper wrote:
> > This patch series adds support for 52-bit kernel VAs using some of the
> > machinery already introduced by the 52-bit userspace VA code in 5.0.
>
> Cheers, I've pushed this out on a for-next/52-bit-kva branch with one
> small patch on top and Catalin's tags added.
As of commit 14c127c957c1c607 ("arm64: mm: Flip kernel VA space"), the
kernel log is spammed with
virt_to_phys used for non-linear address: (____ptrval____)
(__func__.6603+0x14d681/0x17fb3d)
WARNING: CPU: 0 PID: 264 at arch/arm64/mm/physaddr.c:15
__virt_to_phys+0x28/0x58
Modules linked in:
CPU: 0 PID: 264 Comm: mdev Not tainted
5.3.0-rc3-rcar3-initrd-00002-g14c127c957c1c607 #38
Hardware name: Renesas Ebisu-4D board based on r8a77990 (DT)
pstate: 60000005 (nZCv daif -PAN -UAO)
pc : __virt_to_phys+0x28/0x58
lr : __virt_to_phys+0x28/0x58
sp : ffffffc011953c80
x29: ffffffc011953c80 x28: ffffff8078790140
x27: 0000000000000000 x26: 0000000000000000
x25: ffffffc010a539b9 x24: ffffffc010a86000
x23: ffffffc010a539ba x22: 0000000000000001
x21: 0000000000202038 x20: 0000000000000001
x19: ffffffc010a539b9 x18: 000000000000000a
x17: 0000000000000000 x16: 0000000000000000
x15: 00000000000ca51d x14: 0720072007200720
x13: 0720072007200720 x12: 0720072007200720
x11: 0720072007200720 x10: 0720072007200720
x9 : 0720072007200720 x8 : 0000000000000001
x7 : 0000000000000007 x6 : ffffff8079824f00
x5 : 0000000000000140 x4 : 0000000000000000
x3 : 0000000000000000 x2 : 00000000ffffffff
x1 : 0713abbc9281cf00 x0 : 0000000000000000
Call trace:
__virt_to_phys+0x28/0x58
__check_object_size+0xd0/0x1e0
filldir64+0x1d8/0x2b0
kernfs_fop_readdir+0x64/0x200
iterate_dir+0x68/0x144
ksys_getdents64+0x88/0x154
__arm64_sys_getdents64+0x18/0x24
el0_svc_common.constprop.0+0x84/0xe8
el0_svc_compat_handler+0x18/0x20
el0_svc_compat+0x8/0x10
---[ end trace 6980a45f636e18be ]---
as soon as userspace starts.
As this commit cannot be reverted easily, I had to revert the full branch with
"git revert -m 1 6ce0dc725177e9856c9a67f2e2cabb3f7a3d90d7".
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 12/16] arm64: prefer __section from compiler_attributes.h
From: Miguel Ojeda @ 2019-08-13 12:36 UTC (permalink / raw)
To: Will Deacon
Cc: Song Liu, Catalin Marinas, Alexei Starovoitov, Daniel Borkmann,
clang-built-linux, Allison Randal, yhs, Masayoshi Mizuma,
Suzuki K Poulose, Andrey Konovalov, Shaokun Zhang, Alexios Zavras,
Josh Poimboeuf, Sedat Dilek, Thomas Gleixner, bpf, Linux ARM,
Greg Kroah-Hartman, Nick Desaulniers, linux-kernel,
Network Development, Andrew Morton, Enrico Weigelt,
Martin KaFai Lau
In-Reply-To: <20190813082744.xmzmm4j675rqiz47@willie-the-truck>
On Tue, Aug 13, 2019 at 10:27 AM Will Deacon <will@kernel.org> wrote:
>
> Hi Nick,
>
> On Mon, Aug 12, 2019 at 02:50:45PM -0700, Nick Desaulniers wrote:
> > GCC unescapes escaped string section names while Clang does not. Because
> > __section uses the `#` stringification operator for the section name, it
> > doesn't need to be escaped.
> >
> > This antipattern was found with:
> > $ grep -e __section\(\" -e __section__\(\" -r
> >
> > Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
> > Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
> > Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
> > ---
> > arch/arm64/include/asm/cache.h | 2 +-
> > arch/arm64/kernel/smp_spin_table.c | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
>
> Does this fix a build issue, or is it just cosmetic or do we end up with
> duplicate sections or something else?
This should be cosmetic -- basically we are trying to move all users
of current available __attribute__s in compiler_attributes.h to the
__attr forms. I am also adding (slowly) new attributes that are
already used but we don't have them yet in __attr form.
> Happy to route it via arm64, just having trouble working out whether it's
> 5.3 material!
As you prefer! Those that are not taken by a maintainer I will pick up
and send via compiler-attributes.
I would go for 5.4, since there is no particular rush anyway.
Cheers,
Miguel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: media: i2c: Add IMX290 CMOS sensor binding
From: Sakari Ailus @ 2019-08-13 12:22 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: devicetree, c.barrett, linux-kernel, a.brela, robh+dt, mchehab,
linux-arm-kernel, linux-media
In-Reply-To: <20190813121400.GA29378@Mani-XPS-13-9360>
Hi Manivannan,
On Tue, Aug 13, 2019 at 05:44:00PM +0530, Manivannan Sadhasivam wrote:
> Hi Sakari,
>
> On Tue, Aug 13, 2019 at 02:46:43PM +0300, Sakari Ailus wrote:
> > Hi Manivannan,
> >
> > On Tue, Aug 13, 2019 at 05:03:58PM +0530, Manivannan Sadhasivam wrote:
> > > Hi Sakari,
> > >
> > > Thanks for the review!
> > >
> > > On Tue, Aug 13, 2019 at 12:45:26PM +0300, Sakari Ailus wrote:
> > > > Hi Manivannan,
> > > >
> > > > On Tue, Aug 06, 2019 at 06:39:36PM +0530, Manivannan Sadhasivam wrote:
> > > > > Add devicetree binding for IMX290 CMOS image sensor.
> > > > >
> > > > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > > > > Reviewed-by: Rob Herring <robh@kernel.org>
> > > > > ---
> > > > > .../devicetree/bindings/media/i2c/imx290.txt | 51 +++++++++++++++++++
> > > > > 1 file changed, 51 insertions(+)
> > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/imx290.txt
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/imx290.txt b/Documentation/devicetree/bindings/media/i2c/imx290.txt
> > > > > new file mode 100644
> > > > > index 000000000000..7535b5b5b24b
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/media/i2c/imx290.txt
> > > > > @@ -0,0 +1,51 @@
> > > > > +* Sony IMX290 1/2.8-Inch CMOS Image Sensor
> > > > > +
> > > > > +The Sony IMX290 is a 1/2.8-Inch CMOS Solid-state image sensor with
> > > > > +Square Pixel for Color Cameras. It is programmable through I2C and 4-wire
> > > > > +interfaces. The sensor output is available via CMOS logic parallel SDR output,
> > > > > +Low voltage LVDS DDR output and CSI-2 serial data output.
> > > >
> > > > If there are three to choose from, then you should specify which one is in
> > > > use. Given that I think chances remain slim we'd add support for the other
> > > > two (it's certainly not ruled out though), CSI-2 could be the default. But
> > > > this needs to be documented.
> > > >
> > >
> > > Hmm... I'm not sure here. Bindings should describe the hardware and not the
> > > limitations of the driver. Here as you said, the sensor can output frames
> > > in 3 different modes/formats but the driver only supports CSI2. I can add a
> > > note in the driver but not sure whether dt-binding is the right place or not!
> >
> > I guess alternatively you could document the necessary bindings for the
> > other two busses.
> >
> > But what I'm saying here is that it's highly unlikely they'll be ever
> > needed, and it'd be mostly a waste of time to implement that. (That said, I
> > have nothing against the use of these busses, but I've never seen anyone
> > using them.) Many other devices use defaults for more contentious settings.
> >
>
> Agree with you but my question was, whether I could document the supported
> mode in bindings or not! I have seen comments from Rob in the past that the
> binding should not document the limitations of the driver. But anyway, one
> can infer from the current binding that only CSI2 is supported for now, it's
> just stating it explicitly makes me doubtful!
I think it could be e.g.:
The CSI-2 bus is the default. No bindings have been defined for the other
busses.
...
> > > > I suppose you can't change the lane order, so clock-lanes is redundant
> > > > (don't use it in the example) and data-lanes should be monotonically
> > > > incrementing series from 1 to 4.
> > > >
> > >
> > > We can change the order and the example here illustrates how it has been
> > > wired in FRAMOS module. If I change the lane order like you said, it won't
> > > work.
> >
> > I highly doubt that. Neither the driver nor the sensor uses the lane
> > ordering information.
> >
>
> Agree but CSI2 host will need this informtion, right? Please correct me if
> I'm wrong!
The CSI-2 receiver may need that configuration, but it's not addressed by a
sensor's binding documentation (it's configured in the endpoint on the
receiver's side).
--
Sakari Ailus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: media: i2c: Add IMX290 CMOS sensor binding
From: Manivannan Sadhasivam @ 2019-08-13 12:16 UTC (permalink / raw)
To: Sakari Ailus
Cc: devicetree, c.barrett, linux-kernel, a.brela, robh+dt, mchehab,
linux-arm-kernel, linux-media
In-Reply-To: <20190813115427.GC2527@valkosipuli.retiisi.org.uk>
On Tue, Aug 13, 2019 at 02:54:27PM +0300, Sakari Ailus wrote:
> On Tue, Aug 06, 2019 at 06:39:36PM +0530, Manivannan Sadhasivam wrote:
> ...
> > +Required Properties:
> > +- compatible: Should be "sony,imx290"
> > +- reg: I2C bus address of the device
> > +- clocks: Reference to the xclk clock.
> > +- clock-names: Should be "xclk".
> > +- clock-frequency: Frequency of the xclk clock.
> > +- vdddo-supply: Sensor digital IO regulator.
> > +- vdda-supply: Sensor analog regulator.
> > +- vddd-supply: Sensor digital core regulator.
>
> Could you also add the link-frequencies property, please?
>
Sure, will do.
Thanks,
Mani
> --
> Sakari Ailus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: media: i2c: Add IMX290 CMOS sensor binding
From: Manivannan Sadhasivam @ 2019-08-13 12:14 UTC (permalink / raw)
To: Sakari Ailus
Cc: devicetree, c.barrett, linux-kernel, a.brela, robh+dt, mchehab,
linux-arm-kernel, linux-media
In-Reply-To: <20190813114643.GA2527@valkosipuli.retiisi.org.uk>
Hi Sakari,
On Tue, Aug 13, 2019 at 02:46:43PM +0300, Sakari Ailus wrote:
> Hi Manivannan,
>
> On Tue, Aug 13, 2019 at 05:03:58PM +0530, Manivannan Sadhasivam wrote:
> > Hi Sakari,
> >
> > Thanks for the review!
> >
> > On Tue, Aug 13, 2019 at 12:45:26PM +0300, Sakari Ailus wrote:
> > > Hi Manivannan,
> > >
> > > On Tue, Aug 06, 2019 at 06:39:36PM +0530, Manivannan Sadhasivam wrote:
> > > > Add devicetree binding for IMX290 CMOS image sensor.
> > > >
> > > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > > > Reviewed-by: Rob Herring <robh@kernel.org>
> > > > ---
> > > > .../devicetree/bindings/media/i2c/imx290.txt | 51 +++++++++++++++++++
> > > > 1 file changed, 51 insertions(+)
> > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/imx290.txt
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/media/i2c/imx290.txt b/Documentation/devicetree/bindings/media/i2c/imx290.txt
> > > > new file mode 100644
> > > > index 000000000000..7535b5b5b24b
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/media/i2c/imx290.txt
> > > > @@ -0,0 +1,51 @@
> > > > +* Sony IMX290 1/2.8-Inch CMOS Image Sensor
> > > > +
> > > > +The Sony IMX290 is a 1/2.8-Inch CMOS Solid-state image sensor with
> > > > +Square Pixel for Color Cameras. It is programmable through I2C and 4-wire
> > > > +interfaces. The sensor output is available via CMOS logic parallel SDR output,
> > > > +Low voltage LVDS DDR output and CSI-2 serial data output.
> > >
> > > If there are three to choose from, then you should specify which one is in
> > > use. Given that I think chances remain slim we'd add support for the other
> > > two (it's certainly not ruled out though), CSI-2 could be the default. But
> > > this needs to be documented.
> > >
> >
> > Hmm... I'm not sure here. Bindings should describe the hardware and not the
> > limitations of the driver. Here as you said, the sensor can output frames
> > in 3 different modes/formats but the driver only supports CSI2. I can add a
> > note in the driver but not sure whether dt-binding is the right place or not!
>
> I guess alternatively you could document the necessary bindings for the
> other two busses.
>
> But what I'm saying here is that it's highly unlikely they'll be ever
> needed, and it'd be mostly a waste of time to implement that. (That said, I
> have nothing against the use of these busses, but I've never seen anyone
> using them.) Many other devices use defaults for more contentious settings.
>
Agree with you but my question was, whether I could document the supported
mode in bindings or not! I have seen comments from Rob in the past that the
binding should not document the limitations of the driver. But anyway, one
can infer from the current binding that only CSI2 is supported for now, it's
just stating it explicitly makes me doubtful!
> >
> > > > +
> > > > +Required Properties:
> > > > +- compatible: Should be "sony,imx290"
> > > > +- reg: I2C bus address of the device
> > > > +- clocks: Reference to the xclk clock.
> > > > +- clock-names: Should be "xclk".
> > > > +- clock-frequency: Frequency of the xclk clock.
> > >
> > > ...in Hz.
> > >
> >
> > Ack.
> >
> > > > +- vdddo-supply: Sensor digital IO regulator.
> > > > +- vdda-supply: Sensor analog regulator.
> > > > +- vddd-supply: Sensor digital core regulator.
> > > > +
> > > > +Optional Properties:
> > > > +- reset-gpios: Sensor reset GPIO
> > > > +
> > > > +The imx290 device node should contain one 'port' child node with
> > > > +an 'endpoint' subnode. For further reading on port node refer to
> > > > +Documentation/devicetree/bindings/media/video-interfaces.txt.
> > >
> > > Which other properties are relevant for the device?
> >
> > Not much other than, clock/data lanes.
>
> Please document data-lanes, and which values it may have.
>
Ack.
> >
> > > I suppose you can't change the lane order, so clock-lanes is redundant
> > > (don't use it in the example) and data-lanes should be monotonically
> > > incrementing series from 1 to 4.
> > >
> >
> > We can change the order and the example here illustrates how it has been
> > wired in FRAMOS module. If I change the lane order like you said, it won't
> > work.
>
> I highly doubt that. Neither the driver nor the sensor uses the lane
> ordering information.
>
Agree but CSI2 host will need this informtion, right? Please correct me if
I'm wrong!
> And even if the driver only supported four lanes, then it should check the
> number of lanes is actually four.
>
Ack. Sensor works with 2/4 lanes but the driver only handles 4 for now. Will
add the check in driver.
Thanks,
Mani
> --
> Regards,
>
> Sakari Ailus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] soc: ti: pm33xx: Fix static checker warnings
From: Keerthy @ 2019-08-13 12:10 UTC (permalink / raw)
To: Tony Lindgren
Cc: d-gerlach, linux-kernel, t-kristo, linux-arm-kernel, ssantosh,
dan.carpenter
In-Reply-To: <20190813120453.GW52127@atomide.com>
On 13/08/19 5:34 PM, Tony Lindgren wrote:
> * Keerthy <j-keerthy@ti.com> [190626 00:50]:
>> The patch fixes a bunch of static checker warnings.
>
> Sorry I just noticed that this one is still pending, applying
> into fixes.
Thanks Tony
>
> Tony
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: "arm64/for-next/core" causes boot panic
From: Will Deacon @ 2019-08-13 12:06 UTC (permalink / raw)
To: Qian Cai
Cc: Catalin Marinas, steve.capper, linux-kernel, linux-arm-kernel,
Andrey Konovalov
In-Reply-To: <20190813105852.ovk5gtzddwlsm4ly@willie-the-truck>
[+Steve]
On Tue, Aug 13, 2019 at 11:58:52AM +0100, Will Deacon wrote:
> On Tue, Aug 13, 2019 at 10:02:01AM +0100, Will Deacon wrote:
> > On Mon, Aug 12, 2019 at 05:51:35PM -0400, Qian Cai wrote:
> > > Booting today's linux-next on an arm64 server triggers a panic with
> > > CONFIG_KASAN_SW_TAGS=y pointing to this line,
> >
> > Is this the only change on top of defconfig? If not, please can you share
> > your full .config?
> >
> > > kfree()->virt_to_head_page()->compound_head()
> > >
> > > unsigned long head = READ_ONCE(page->compound_head);
> > >
> > > The bisect so far indicates one of those could be bad,
> >
> > I guess that means the issue is reproducible on the arm64 for-next/core
> > branch. Once I have your .config, I'll give it a go.
>
> FWIW, I've managed to reproduce this using defconfig + SW_TAGS on
> for-next/core, so I'll keep investigating.
Right, hacky diff below seems to resolve this, so I'll split this up into
some proper patches as there is more than one bug here.
Thanks,
Will
--->8
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index afaf512c0e1b..541e8dcb5ab3 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -244,7 +244,7 @@ static inline const void *__tag_set(const void *addr, u8 tag)
/*
* The linear kernel range starts in the middle of the virtual adddress
* space. Testing the top bit for the start of the region is a
- * sufficient check.
+ * sufficient check and avoids having to worry about the tag.
*/
#define __is_lm_address(addr) (!((addr) & BIT(vabits_actual - 1)))
@@ -252,7 +252,7 @@ static inline const void *__tag_set(const void *addr, u8 tag)
#define __kimg_to_phys(addr) ((addr) - kimage_voffset)
#define __virt_to_phys_nodebug(x) ({ \
- phys_addr_t __x = (phys_addr_t)(x); \
+ phys_addr_t __x = (phys_addr_t)(__tag_reset(x)); \
__is_lm_address(__x) ? __lm_to_phys(__x) : \
__kimg_to_phys(__x); \
})
@@ -301,8 +301,8 @@ static inline void *phys_to_virt(phys_addr_t x)
#define __pa_nodebug(x) __virt_to_phys_nodebug((unsigned long)(x))
#define __va(x) ((void *)__phys_to_virt((phys_addr_t)(x)))
#define pfn_to_kaddr(pfn) __va((pfn) << PAGE_SHIFT)
-#define virt_to_pfn(x) __phys_to_pfn(__virt_to_phys((unsigned long)(x)))
-#define sym_to_pfn(x) __phys_to_pfn(__pa_symbol(x))
+#define virt_to_pfn(x) __phys_to_pfn(__virt_to_phys((unsigned long)(x)))
+#define sym_to_pfn(x) __phys_to_pfn(__pa_symbol(x))
/*
* virt_to_page(k) convert a _valid_ virtual address to struct page *
@@ -311,7 +311,7 @@ static inline void *phys_to_virt(phys_addr_t x)
#define ARCH_PFN_OFFSET ((unsigned long)PHYS_PFN_OFFSET)
#if !defined(CONFIG_SPARSEMEM_VMEMMAP) || defined(CONFIG_DEBUG_VIRTUAL)
-#define virt_to_page(kaddr) pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
+#define virt_to_page(kaddr) pfn_to_page(virt_to_pfn(kaddr))
#else
#define __virt_to_pgoff(kaddr) (((u64)(kaddr) - PAGE_OFFSET) / PAGE_SIZE * sizeof(struct page))
#define __page_to_voff(kaddr) (((u64)(kaddr) - VMEMMAP_START) * PAGE_SIZE / sizeof(struct page))
@@ -324,15 +324,17 @@ static inline void *phys_to_virt(phys_addr_t x)
((void *)__addr_tag); \
})
-#define virt_to_page(vaddr) ((struct page *)((__virt_to_pgoff(vaddr)) + VMEMMAP_START))
+#define virt_to_page(kaddr) ({ \
+ unsigned long __addr = __tag_reset((unsigned long)kaddr); \
+ (struct page *)((__virt_to_pgoff(__addr) + VMEMMAP_START)); \
+})
#endif
#endif
-#define _virt_addr_is_linear(kaddr) \
- (__tag_reset((u64)(kaddr)) >= PAGE_OFFSET)
-
-#define virt_addr_valid(kaddr) \
- (_virt_addr_is_linear(kaddr) && pfn_valid(virt_to_pfn(kaddr)))
+#define virt_addr_valid(kaddr) ({ \
+ unsigned long __addr = (unsigned long)kaddr; \
+ __is_lm_address(__addr) && pfn_valid(virt_to_pfn(__addr)); \
+})
/*
* Given that the GIC architecture permits ITS implementations that can only be
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH -next] soc: ti: pm33xx: Make two symbols static
From: Tony Lindgren @ 2019-08-13 12:06 UTC (permalink / raw)
To: Yue Haibing; +Cc: linux-kernel, linux-arm-kernel, ssantosh
In-Reply-To: <20190413141243.38620-1-yuehaibing@huawei.com>
* Yue Haibing <yuehaibing@huawei.com> [190413 07:13]:
> From: YueHaibing <yuehaibing@huawei.com>
>
> Fix sparse warnings:
>
> drivers/soc/ti/pm33xx.c:144:27: warning: symbol 'rtc_wake_src' was not declared. Should it be static?
> drivers/soc/ti/pm33xx.c:160:5: warning: symbol 'am33xx_rtc_only_idle' was not declared. Should it be static?
Applying into fixes thanks.
Tony
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] soc: ti: pm33xx: Fix static checker warnings
From: Tony Lindgren @ 2019-08-13 12:04 UTC (permalink / raw)
To: Keerthy
Cc: d-gerlach, linux-kernel, t-kristo, linux-arm-kernel, ssantosh,
dan.carpenter
In-Reply-To: <20190626075014.2911-1-j-keerthy@ti.com>
* Keerthy <j-keerthy@ti.com> [190626 00:50]:
> The patch fixes a bunch of static checker warnings.
Sorry I just noticed that this one is still pending, applying
into fixes.
Tony
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: OMAP: dma: Mark expected switch fall-throughs
From: Tony Lindgren @ 2019-08-13 12:00 UTC (permalink / raw)
To: Kees Cook
Cc: Stephen Rothwell, Aaro Koskinen, Gustavo A. R. Silva,
linux-kernel, Russell King, linux-omap, linux-arm-kernel
In-Reply-To: <201907290934.B2053972E3@keescook>
* Kees Cook <keescook@chromium.org> [190729 16:35]:
> On Sun, Jul 28, 2019 at 06:22:40PM -0500, Gustavo A. R. Silva wrote:
> > Mark switch cases where we are expecting to fall through.
> >
> > This patch fixes the following warnings:
> >
> > arch/arm/plat-omap/dma.c: In function 'omap_set_dma_src_burst_mode':
> > arch/arm/plat-omap/dma.c:384:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
> > if (dma_omap2plus()) {
> > ^
> > arch/arm/plat-omap/dma.c:393:2: note: here
> > case OMAP_DMA_DATA_BURST_16:
> > ^~~~
> > arch/arm/plat-omap/dma.c:394:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
> > if (dma_omap2plus()) {
> > ^
> > arch/arm/plat-omap/dma.c:402:2: note: here
> > default:
> > ^~~~~~~
> > arch/arm/plat-omap/dma.c: In function 'omap_set_dma_dest_burst_mode':
> > arch/arm/plat-omap/dma.c:473:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
> > if (dma_omap2plus()) {
> > ^
> > arch/arm/plat-omap/dma.c:481:2: note: here
> > default:
> > ^~~~~~~
> >
> > Notice that, in this particular case, the code comment is
> > modified in accordance with what GCC is expecting to find.
> >
> > Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
>
> Reviewed-by: Kees Cook <keescook@chromium.org>
Applying into fixes thanks.
Tony
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: cpufeature: Don't treat granule sizes as strict
From: Catalin Marinas @ 2019-08-13 11:59 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, khilman, Suzuki Poulose, linux-arm-kernel,
Marc Zyngier
In-Reply-To: <20190812150225.25386-1-will@kernel.org>
On Mon, Aug 12, 2019 at 04:02:25PM +0100, Will Deacon wrote:
> If a CPU doesn't support the page size for which the kernel is
> configured, then we will complain and refuse to bring it online. For
> secondary CPUs (and the boot CPU on a system booting with EFI), we will
> also print an error identifying the mismatch.
>
> Consequently, the only time that the cpufeature code can detect a
> granule size mismatch is for a granule other than the one that is
> currently being used. Although we would rather such systems didn't
> exist, we've unfortunately lost that battle and Kevin reports that
> on his amlogic S922X (odroid-n2 board) we end up warning and taining
> with defconfig because 16k pages are not supported by all of the CPUs.
>
> In such a situation, we don't actually care about the feature mismatch,
> particularly now that KVM only exposes the sanitised view of the CPU
> registers. Treat the granule fields as non-strict and let Kevin run
> without a tainted kernel.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Suzuki Poulose <suzuki.poulose@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Reported-by: Kevin Hilman <khilman@baylibre.com>
> Signed-off-by: Will Deacon <will@kernel.org>
Queued for 5.3-rc5. Thanks.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V5 00/12] 52-bit kernel + user VAs
From: Will Deacon @ 2019-08-13 11:59 UTC (permalink / raw)
To: Steve Capper
Cc: crecklin@redhat.com, ard.biesheuvel@linaro.org, Catalin Marinas,
bhsharma@redhat.com, maz@kernel.org, nd,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190813112348.GA19242@capper-ampere.manchester.arm.com>
On Tue, Aug 13, 2019 at 11:23:50AM +0000, Steve Capper wrote:
> On Fri, Aug 09, 2019 at 05:47:17PM +0100, Will Deacon wrote:
> > On Wed, Aug 07, 2019 at 04:55:12PM +0100, Steve Capper wrote:
> > > This patch series adds support for 52-bit kernel VAs using some of the
> > > machinery already introduced by the 52-bit userspace VA code in 5.0.
> >
> > Cheers, I've pushed this out on a for-next/52-bit-kva branch with one
> > small patch on top and Catalin's tags added.
> >
>
> Many thanks Will!
Save your thanks for when I've fixed the bugs ;)
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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