* [PATCH] arm64: dts: hip06: Fix no reg property warning
From: Wei Xu @ 2016-11-15 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477280428-30558-1-git-send-email-wangkefeng.wang@huawei.com>
Hi Kefeng,
On 2016/10/24 4:40, Kefeng Wang wrote:
> Warning (unit_address_vs_reg): Node /soc/ethernet at 4 has a unit name, but no reg property
> Warning (unit_address_vs_reg): Node /soc/ethernet at 5 has a unit name, but no reg property
> Warning (unit_address_vs_reg): Node /soc/ethernet at 0 has a unit name, but no reg property
> Warning (unit_address_vs_reg): Node /soc/ethernet at 1 has a unit name, but no reg property
>
> Fix warning when build with W=1.
>
> Cc: Kejian Yan <yankejian@huawei.com>
> Cc: Yisen Zhuang <yisen.zhuang@huawei.com>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> ---
Applied to the hisilicon soc tree.
Thanks!
Best Regards,
Wei
> arch/arm64/boot/dts/hisilicon/hip06.dtsi | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
> index b548763..f66c51b 100644
> --- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
> @@ -508,7 +508,7 @@
> };
> };
>
> - eth0: ethernet at 4{
> + eth0: ethernet-4{
> compatible = "hisilicon,hns-nic-v2";
> ae-handle = <&dsaf0>;
> port-idx-in-ae = <4>;
> @@ -517,7 +517,7 @@
> dma-coherent;
> };
>
> - eth1: ethernet at 5{
> + eth1: ethernet-5{
> compatible = "hisilicon,hns-nic-v2";
> ae-handle = <&dsaf0>;
> port-idx-in-ae = <5>;
> @@ -526,7 +526,7 @@
> dma-coherent;
> };
>
> - eth2: ethernet at 0{
> + eth2: ethernet-0{
> compatible = "hisilicon,hns-nic-v2";
> ae-handle = <&dsaf0>;
> port-idx-in-ae = <0>;
> @@ -535,7 +535,7 @@
> dma-coherent;
> };
>
> - eth3: ethernet at 1{
> + eth3: ethernet-1{
> compatible = "hisilicon,hns-nic-v2";
> ae-handle = <&dsaf0>;
> port-idx-in-ae = <1>;
>
^ permalink raw reply
* [PATCH 1/5] arm64: dts: hip06: Correct hardware pin number of usb node
From: Wei Xu @ 2016-11-15 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474708465-38958-2-git-send-email-wangkefeng.wang@huawei.com>
Hi Kefeng,
On 2016/9/24 10:14, Kefeng Wang wrote:
> The ohci/ehci hardware pin number should be 640/641, correct them.
>
> Fixes: commit aa8d3e74f54d ("arm64: dts: Add initial dts for Hisilicon Hip06 D03 board")
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> ---
Applied to the hisilicon soc tree.
Thanks!
Best Regards,
Wei
> arch/arm64/boot/dts/hisilicon/hip06.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
> index 66b1bbf..be76f7d 100644
> --- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
> @@ -322,7 +322,7 @@
> compatible = "generic-ohci";
> reg = <0x0 0xa7030000 0x0 0x10000>;
> interrupt-parent = <&mbigen_usb>;
> - interrupts = <64 4>;
> + interrupts = <640 4>;
> dma-coherent;
> status = "disabled";
> };
> @@ -331,7 +331,7 @@
> compatible = "generic-ehci";
> reg = <0x0 0xa7020000 0x0 0x10000>;
> interrupt-parent = <&mbigen_usb>;
> - interrupts = <65 4>;
> + interrupts = <641 4>;
> dma-coherent;
> status = "disabled";
> };
>
^ permalink raw reply
* [PATCH 2/5] Documentation: arm64: Add Hisilicon Hip07 D05 dts binding
From: Wei Xu @ 2016-11-15 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474708465-38958-3-git-send-email-wangkefeng.wang@huawei.com>
Hi Kefeng,
On 2016/9/24 10:14, Kefeng Wang wrote:
> This patch adds documentation for the devicetree bindings used by
> the DT files of Hisilicon Hip07 D05 board.
>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> ---
Applied to the hisilicon soc tree.
Thanks!
Best Regards,
Wei
> Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
> index 3f81575..7df79a7 100644
> --- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
> +++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
> @@ -28,6 +28,10 @@ HiP06 D03 Board
> Required root node properties:
> - compatible = "hisilicon,hip06-d03";
>
> +HiP07 D05 Board
> +Required root node properties:
> + - compatible = "hisilicon,hip07-d05";
> +
> Hisilicon system controller
>
> Required properties:
>
^ permalink raw reply
* [PATCH 3/5] arm64: dts: hisilicon: Add initial dts for Hip07 D05 board
From: Wei Xu @ 2016-11-15 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474708465-38958-4-git-send-email-wangkefeng.wang@huawei.com>
Hi Kefeng,
On 2016/9/24 10:14, Kefeng Wang wrote:
> Adding initial dt file for Hip07 D05 board, it is with dual socket
> and each socket has two SCCLs(supper cpu cluster), one SCCL contains
> four clusters and each cluster has quard Cortex-A72.
>
> Since each SCCL has their own DDR controller, it could be treated as
> a separate numa node. Thus, there are four numa nodes(one node with
> sixteen core) on Hip07 SoC.
>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> ---
Applied to the hisilicon soc tree.
Thanks!
Best Regards,
Wei
> arch/arm64/boot/dts/hisilicon/Makefile | 1 +
> arch/arm64/boot/dts/hisilicon/hip07-d05.dts | 66 ++
> arch/arm64/boot/dts/hisilicon/hip07.dtsi | 1059 +++++++++++++++++++++++++++
> 3 files changed, 1126 insertions(+)
> create mode 100644 arch/arm64/boot/dts/hisilicon/hip07-d05.dts
> create mode 100644 arch/arm64/boot/dts/hisilicon/hip07.dtsi
>
> diff --git a/arch/arm64/boot/dts/hisilicon/Makefile b/arch/arm64/boot/dts/hisilicon/Makefile
> index d5f43a0..c8b8f80 100644
> --- a/arch/arm64/boot/dts/hisilicon/Makefile
> +++ b/arch/arm64/boot/dts/hisilicon/Makefile
> @@ -1,6 +1,7 @@
> dtb-$(CONFIG_ARCH_HISI) += hi6220-hikey.dtb
> dtb-$(CONFIG_ARCH_HISI) += hip05-d02.dtb
> dtb-$(CONFIG_ARCH_HISI) += hip06-d03.dtb
> +dtb-$(CONFIG_ARCH_HISI) += hip07-d05.dtb
>
> always := $(dtb-y)
> subdir-y := $(dts-dirs)
> diff --git a/arch/arm64/boot/dts/hisilicon/hip07-d05.dts b/arch/arm64/boot/dts/hisilicon/hip07-d05.dts
> new file mode 100644
> index 0000000..e058442
> --- /dev/null
> +++ b/arch/arm64/boot/dts/hisilicon/hip07-d05.dts
> @@ -0,0 +1,66 @@
> +/**
> + * dts file for Hisilicon D05 Development Board
> + *
> + * Copyright (C) 2016 Hisilicon Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * publishhed by the Free Software Foundation.
> + *
> + */
> +
> +/dts-v1/;
> +
> +#include "hip07.dtsi"
> +
> +/ {
> + model = "Hisilicon Hip07 D05 Development Board";
> + compatible = "hisilicon,hip07-d05";
> +
> + /* the mem node will be updated by UEFI. */
> + memory at 0 {
> + device_type = "memory";
> + reg = <0x0 0x00000000 0x0 0x40000000>;
> + numa-node-id = <0>;
> + };
> +
> + distance-map {
> + compatible = "numa-distance-map-v1";
> + distance-matrix = <0 0 10>,
> + <0 1 15>,
> + <0 2 20>,
> + <0 3 25>,
> + <1 0 15>,
> + <1 1 10>,
> + <1 2 25>,
> + <1 3 30>,
> + <2 0 20>,
> + <2 1 25>,
> + <2 2 10>,
> + <2 3 15>,
> + <3 0 25>,
> + <3 1 30>,
> + <3 2 15>,
> + <3 3 10>;
> + };
> +
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +};
> +
> +&uart0 {
> + status = "ok";
> +};
> +
> +&usb_ohci {
> + status = "ok";
> +};
> +
> +&usb_ehci {
> + status = "ok";
> +};
> diff --git a/arch/arm64/boot/dts/hisilicon/hip07.dtsi b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
> new file mode 100644
> index 0000000..5144eb1
> --- /dev/null
> +++ b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
> @@ -0,0 +1,1059 @@
> +/**
> + * dts file for Hisilicon D05 Development Board
> + *
> + * Copyright (C) 2016 Hisilicon Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * publishhed by the Free Software Foundation.
> + *
> + */
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +/ {
> + compatible = "hisilicon,hip07-d05";
> + interrupt-parent = <&gic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + psci {
> + compatible = "arm,psci-0.2";
> + method = "smc";
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu-map {
> + cluster0 {
> + core0 {
> + cpu = <&cpu0>;
> + };
> + core1 {
> + cpu = <&cpu1>;
> + };
> + core2 {
> + cpu = <&cpu2>;
> + };
> + core3 {
> + cpu = <&cpu3>;
> + };
> + };
> +
> + cluster1 {
> + core0 {
> + cpu = <&cpu4>;
> + };
> + core1 {
> + cpu = <&cpu5>;
> + };
> + core2 {
> + cpu = <&cpu6>;
> + };
> + core3 {
> + cpu = <&cpu7>;
> + };
> + };
> +
> + cluster2 {
> + core0 {
> + cpu = <&cpu8>;
> + };
> + core1 {
> + cpu = <&cpu9>;
> + };
> + core2 {
> + cpu = <&cpu10>;
> + };
> + core3 {
> + cpu = <&cpu11>;
> + };
> + };
> +
> + cluster3 {
> + core0 {
> + cpu = <&cpu12>;
> + };
> + core1 {
> + cpu = <&cpu13>;
> + };
> + core2 {
> + cpu = <&cpu14>;
> + };
> + core3 {
> + cpu = <&cpu15>;
> + };
> + };
> +
> + cluster4 {
> + core0 {
> + cpu = <&cpu16>;
> + };
> + core1 {
> + cpu = <&cpu17>;
> + };
> + core2 {
> + cpu = <&cpu18>;
> + };
> + core3 {
> + cpu = <&cpu19>;
> + };
> + };
> +
> + cluster5 {
> + core0 {
> + cpu = <&cpu20>;
> + };
> + core1 {
> + cpu = <&cpu21>;
> + };
> + core2 {
> + cpu = <&cpu22>;
> + };
> + core3 {
> + cpu = <&cpu23>;
> + };
> + };
> +
> + cluster6 {
> + core0 {
> + cpu = <&cpu24>;
> + };
> + core1 {
> + cpu = <&cpu25>;
> + };
> + core2 {
> + cpu = <&cpu26>;
> + };
> + core3 {
> + cpu = <&cpu27>;
> + };
> + };
> +
> + cluster7 {
> + core0 {
> + cpu = <&cpu28>;
> + };
> + core1 {
> + cpu = <&cpu29>;
> + };
> + core2 {
> + cpu = <&cpu30>;
> + };
> + core3 {
> + cpu = <&cpu31>;
> + };
> + };
> +
> + cluster8 {
> + core0 {
> + cpu = <&cpu32>;
> + };
> + core1 {
> + cpu = <&cpu33>;
> + };
> + core2 {
> + cpu = <&cpu34>;
> + };
> + core3 {
> + cpu = <&cpu35>;
> + };
> + };
> +
> + cluster9 {
> + core0 {
> + cpu = <&cpu36>;
> + };
> + core1 {
> + cpu = <&cpu37>;
> + };
> + core2 {
> + cpu = <&cpu38>;
> + };
> + core3 {
> + cpu = <&cpu39>;
> + };
> + };
> +
> + cluster10 {
> + core0 {
> + cpu = <&cpu40>;
> + };
> + core1 {
> + cpu = <&cpu41>;
> + };
> + core2 {
> + cpu = <&cpu42>;
> + };
> + core3 {
> + cpu = <&cpu43>;
> + };
> + };
> +
> + cluster11 {
> + core0 {
> + cpu = <&cpu44>;
> + };
> + core1 {
> + cpu = <&cpu45>;
> + };
> + core2 {
> + cpu = <&cpu46>;
> + };
> + core3 {
> + cpu = <&cpu47>;
> + };
> + };
> +
> + cluster12 {
> + core0 {
> + cpu = <&cpu48>;
> + };
> + core1 {
> + cpu = <&cpu49>;
> + };
> + core2 {
> + cpu = <&cpu50>;
> + };
> + core3 {
> + cpu = <&cpu51>;
> + };
> + };
> +
> + cluster13 {
> + core0 {
> + cpu = <&cpu52>;
> + };
> + core1 {
> + cpu = <&cpu53>;
> + };
> + core2 {
> + cpu = <&cpu54>;
> + };
> + core3 {
> + cpu = <&cpu55>;
> + };
> + };
> +
> + cluster14 {
> + core0 {
> + cpu = <&cpu56>;
> + };
> + core1 {
> + cpu = <&cpu57>;
> + };
> + core2 {
> + cpu = <&cpu58>;
> + };
> + core3 {
> + cpu = <&cpu59>;
> + };
> + };
> +
> + cluster15 {
> + core0 {
> + cpu = <&cpu60>;
> + };
> + core1 {
> + cpu = <&cpu61>;
> + };
> + core2 {
> + cpu = <&cpu62>;
> + };
> + core3 {
> + cpu = <&cpu63>;
> + };
> + };
> + };
> +
> + cpu0: cpu at 10000 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x10000>;
> + enable-method = "psci";
> + next-level-cache = <&cluster0_l2>;
> + numa-node-id = <0>;
> + };
> +
> + cpu1: cpu at 10001 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x10001>;
> + enable-method = "psci";
> + next-level-cache = <&cluster0_l2>;
> + numa-node-id = <0>;
> + };
> +
> + cpu2: cpu at 10002 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x10002>;
> + enable-method = "psci";
> + next-level-cache = <&cluster0_l2>;
> + numa-node-id = <0>;
> + };
> +
> + cpu3: cpu at 10003 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x10003>;
> + enable-method = "psci";
> + next-level-cache = <&cluster0_l2>;
> + numa-node-id = <0>;
> + };
> +
> + cpu4: cpu at 10100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x10100>;
> + enable-method = "psci";
> + next-level-cache = <&cluster1_l2>;
> + numa-node-id = <0>;
> + };
> +
> + cpu5: cpu at 10101 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x10101>;
> + enable-method = "psci";
> + next-level-cache = <&cluster1_l2>;
> + numa-node-id = <0>;
> + };
> +
> + cpu6: cpu at 10102 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x10102>;
> + enable-method = "psci";
> + next-level-cache = <&cluster1_l2>;
> + numa-node-id = <0>;
> + };
> +
> + cpu7: cpu at 10103 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x10103>;
> + enable-method = "psci";
> + next-level-cache = <&cluster1_l2>;
> + numa-node-id = <0>;
> + };
> +
> + cpu8: cpu at 10200 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x10200>;
> + enable-method = "psci";
> + next-level-cache = <&cluster2_l2>;
> + numa-node-id = <0>;
> + };
> +
> + cpu9: cpu at 10201 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x10201>;
> + enable-method = "psci";
> + next-level-cache = <&cluster2_l2>;
> + numa-node-id = <0>;
> + };
> +
> + cpu10: cpu at 10202 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x10202>;
> + enable-method = "psci";
> + next-level-cache = <&cluster2_l2>;
> + numa-node-id = <0>;
> + };
> +
> + cpu11: cpu at 10203 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x10203>;
> + enable-method = "psci";
> + next-level-cache = <&cluster2_l2>;
> + numa-node-id = <0>;
> + };
> +
> + cpu12: cpu at 10300 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x10300>;
> + enable-method = "psci";
> + next-level-cache = <&cluster3_l2>;
> + numa-node-id = <0>;
> + };
> +
> + cpu13: cpu at 10301 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x10301>;
> + enable-method = "psci";
> + next-level-cache = <&cluster3_l2>;
> + numa-node-id = <0>;
> + };
> +
> + cpu14: cpu at 10302 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x10302>;
> + enable-method = "psci";
> + next-level-cache = <&cluster3_l2>;
> + numa-node-id = <0>;
> + };
> +
> + cpu15: cpu at 10303 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x10303>;
> + enable-method = "psci";
> + next-level-cache = <&cluster3_l2>;
> + numa-node-id = <0>;
> + };
> +
> + cpu16: cpu at 30000 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x30000>;
> + enable-method = "psci";
> + next-level-cache = <&cluster4_l2>;
> + numa-node-id = <1>;
> + };
> +
> + cpu17: cpu at 30001 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x30001>;
> + enable-method = "psci";
> + next-level-cache = <&cluster4_l2>;
> + numa-node-id = <1>;
> + };
> +
> + cpu18: cpu at 30002 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x30002>;
> + enable-method = "psci";
> + next-level-cache = <&cluster4_l2>;
> + numa-node-id = <1>;
> + };
> +
> + cpu19: cpu at 30003 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x30003>;
> + enable-method = "psci";
> + next-level-cache = <&cluster4_l2>;
> + numa-node-id = <1>;
> + };
> +
> + cpu20: cpu at 30100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x30100>;
> + enable-method = "psci";
> + next-level-cache = <&cluster5_l2>;
> + numa-node-id = <1>;
> + };
> +
> + cpu21: cpu at 30101 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x30101>;
> + enable-method = "psci";
> + next-level-cache = <&cluster5_l2>;
> + numa-node-id = <1>;
> + };
> +
> + cpu22: cpu at 30102 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x30102>;
> + enable-method = "psci";
> + next-level-cache = <&cluster5_l2>;
> + numa-node-id = <1>;
> + };
> +
> + cpu23: cpu at 30103 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x30103>;
> + enable-method = "psci";
> + next-level-cache = <&cluster5_l2>;
> + numa-node-id = <1>;
> + };
> +
> + cpu24: cpu at 30200 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x30200>;
> + enable-method = "psci";
> + next-level-cache = <&cluster6_l2>;
> + numa-node-id = <1>;
> + };
> +
> + cpu25: cpu at 30201 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x30201>;
> + enable-method = "psci";
> + next-level-cache = <&cluster6_l2>;
> + numa-node-id = <1>;
> + };
> +
> + cpu26: cpu at 30202 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x30202>;
> + enable-method = "psci";
> + next-level-cache = <&cluster6_l2>;
> + numa-node-id = <1>;
> + };
> +
> + cpu27: cpu at 30203 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x30203>;
> + enable-method = "psci";
> + next-level-cache = <&cluster6_l2>;
> + numa-node-id = <1>;
> + };
> +
> + cpu28: cpu at 30300 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x30300>;
> + enable-method = "psci";
> + next-level-cache = <&cluster7_l2>;
> + numa-node-id = <1>;
> + };
> +
> + cpu29: cpu at 30301 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x30301>;
> + enable-method = "psci";
> + next-level-cache = <&cluster7_l2>;
> + numa-node-id = <1>;
> + };
> +
> + cpu30: cpu at 30302 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x30302>;
> + enable-method = "psci";
> + next-level-cache = <&cluster7_l2>;
> + numa-node-id = <1>;
> + };
> +
> + cpu31: cpu at 30303 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x30303>;
> + enable-method = "psci";
> + next-level-cache = <&cluster7_l2>;
> + numa-node-id = <1>;
> + };
> +
> + cpu32: cpu at 50000 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x50000>;
> + enable-method = "psci";
> + next-level-cache = <&cluster8_l2>;
> + numa-node-id = <2>;
> + };
> +
> + cpu33: cpu at 50001 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x50001>;
> + enable-method = "psci";
> + next-level-cache = <&cluster8_l2>;
> + numa-node-id = <2>;
> + };
> +
> + cpu34: cpu at 50002 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x50002>;
> + enable-method = "psci";
> + next-level-cache = <&cluster8_l2>;
> + numa-node-id = <2>;
> + };
> +
> + cpu35: cpu at 50003 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x50003>;
> + enable-method = "psci";
> + next-level-cache = <&cluster8_l2>;
> + numa-node-id = <2>;
> + };
> +
> + cpu36: cpu at 50100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x50100>;
> + enable-method = "psci";
> + next-level-cache = <&cluster9_l2>;
> + numa-node-id = <2>;
> + };
> +
> + cpu37: cpu at 50101 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x50101>;
> + enable-method = "psci";
> + next-level-cache = <&cluster9_l2>;
> + numa-node-id = <2>;
> + };
> +
> + cpu38: cpu at 50102 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x50102>;
> + enable-method = "psci";
> + next-level-cache = <&cluster9_l2>;
> + numa-node-id = <2>;
> + };
> +
> + cpu39: cpu at 50103 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x50103>;
> + enable-method = "psci";
> + next-level-cache = <&cluster9_l2>;
> + numa-node-id = <2>;
> + };
> +
> + cpu40: cpu at 50200 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x50200>;
> + enable-method = "psci";
> + next-level-cache = <&cluster10_l2>;
> + numa-node-id = <2>;
> + };
> +
> + cpu41: cpu at 50201 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x50201>;
> + enable-method = "psci";
> + next-level-cache = <&cluster10_l2>;
> + numa-node-id = <2>;
> + };
> +
> + cpu42: cpu at 50202 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x50202>;
> + enable-method = "psci";
> + next-level-cache = <&cluster10_l2>;
> + numa-node-id = <2>;
> + };
> +
> + cpu43: cpu at 50203 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x50203>;
> + enable-method = "psci";
> + next-level-cache = <&cluster10_l2>;
> + numa-node-id = <2>;
> + };
> +
> + cpu44: cpu at 50300 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x50300>;
> + enable-method = "psci";
> + next-level-cache = <&cluster11_l2>;
> + numa-node-id = <2>;
> + };
> +
> + cpu45: cpu at 50301 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x50301>;
> + enable-method = "psci";
> + next-level-cache = <&cluster11_l2>;
> + numa-node-id = <2>;
> + };
> +
> + cpu46: cpu at 50302 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x50302>;
> + enable-method = "psci";
> + next-level-cache = <&cluster11_l2>;
> + numa-node-id = <2>;
> + };
> +
> + cpu47: cpu at 50303 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x50303>;
> + enable-method = "psci";
> + next-level-cache = <&cluster11_l2>;
> + numa-node-id = <2>;
> + };
> +
> + cpu48: cpu at 70000 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x70000>;
> + enable-method = "psci";
> + next-level-cache = <&cluster12_l2>;
> + numa-node-id = <3>;
> + };
> +
> + cpu49: cpu at 70001 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x70001>;
> + enable-method = "psci";
> + next-level-cache = <&cluster12_l2>;
> + numa-node-id = <3>;
> + };
> +
> + cpu50: cpu at 70002 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x70002>;
> + enable-method = "psci";
> + next-level-cache = <&cluster12_l2>;
> + numa-node-id = <3>;
> + };
> +
> + cpu51: cpu at 70003 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x70003>;
> + enable-method = "psci";
> + next-level-cache = <&cluster12_l2>;
> + numa-node-id = <3>;
> + };
> +
> + cpu52: cpu at 70100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x70100>;
> + enable-method = "psci";
> + next-level-cache = <&cluster13_l2>;
> + numa-node-id = <3>;
> + };
> +
> + cpu53: cpu at 70101 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x70101>;
> + enable-method = "psci";
> + next-level-cache = <&cluster13_l2>;
> + numa-node-id = <3>;
> + };
> +
> + cpu54: cpu at 70102 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x70102>;
> + enable-method = "psci";
> + next-level-cache = <&cluster13_l2>;
> + numa-node-id = <3>;
> + };
> +
> + cpu55: cpu at 70103 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x70103>;
> + enable-method = "psci";
> + next-level-cache = <&cluster13_l2>;
> + numa-node-id = <3>;
> + };
> +
> + cpu56: cpu at 70200 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x70200>;
> + enable-method = "psci";
> + next-level-cache = <&cluster14_l2>;
> + numa-node-id = <3>;
> + };
> +
> + cpu57: cpu at 70201 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x70201>;
> + enable-method = "psci";
> + next-level-cache = <&cluster14_l2>;
> + numa-node-id = <3>;
> + };
> +
> + cpu58: cpu at 70202 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x70202>;
> + enable-method = "psci";
> + next-level-cache = <&cluster14_l2>;
> + numa-node-id = <3>;
> + };
> +
> + cpu59: cpu at 70203 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x70203>;
> + enable-method = "psci";
> + next-level-cache = <&cluster14_l2>;
> + numa-node-id = <3>;
> + };
> +
> + cpu60: cpu at 70300 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x70300>;
> + enable-method = "psci";
> + next-level-cache = <&cluster15_l2>;
> + numa-node-id = <3>;
> + };
> +
> + cpu61: cpu at 70301 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x70301>;
> + enable-method = "psci";
> + next-level-cache = <&cluster15_l2>;
> + numa-node-id = <3>;
> + };
> +
> + cpu62: cpu at 70302 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x70302>;
> + enable-method = "psci";
> + next-level-cache = <&cluster15_l2>;
> + numa-node-id = <3>;
> + };
> +
> + cpu63: cpu at 70303 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72", "arm,armv8";
> + reg = <0x70303>;
> + enable-method = "psci";
> + next-level-cache = <&cluster15_l2>;
> + numa-node-id = <3>;
> + };
> +
> + cluster0_l2: l2-cache0 {
> + compatible = "cache";
> + };
> +
> + cluster1_l2: l2-cache1 {
> + compatible = "cache";
> + };
> +
> + cluster2_l2: l2-cache2 {
> + compatible = "cache";
> + };
> +
> + cluster3_l2: l2-cache3 {
> + compatible = "cache";
> + };
> +
> + cluster4_l2: l2-cache4 {
> + compatible = "cache";
> + };
> +
> + cluster5_l2: l2-cache5 {
> + compatible = "cache";
> + };
> +
> + cluster6_l2: l2-cache6 {
> + compatible = "cache";
> + };
> +
> + cluster7_l2: l2-cache7 {
> + compatible = "cache";
> + };
> +
> + cluster8_l2: l2-cache8 {
> + compatible = "cache";
> + };
> +
> + cluster9_l2: l2-cache9 {
> + compatible = "cache";
> + };
> +
> + cluster10_l2: l2-cache10 {
> + compatible = "cache";
> + };
> +
> + cluster11_l2: l2-cache11 {
> + compatible = "cache";
> + };
> +
> + cluster12_l2: l2-cache12 {
> + compatible = "cache";
> + };
> +
> + cluster13_l2: l2-cache13 {
> + compatible = "cache";
> + };
> +
> + cluster14_l2: l2-cache14 {
> + compatible = "cache";
> + };
> +
> + cluster15_l2: l2-cache15 {
> + compatible = "cache";
> + };
> + };
> +
> + gic: interrupt-controller at 4d000000 {
> + compatible = "arm,gic-v3";
> + #interrupt-cells = <3>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> + interrupt-controller;
> + #redistributor-regions = <4>;
> + redistributor-stride = <0x0 0x40000>;
> + reg = <0x0 0x4d000000 0x0 0x10000>, /* GICD */
> + <0x0 0x4d100000 0x0 0x400000>, /* p0 GICR node 0 */
> + <0x0 0x6d100000 0x0 0x400000>, /* p0 GICR node 1 */
> + <0x400 0x4d100000 0x0 0x400000>, /* p1 GICR node 2 */
> + <0x400 0x6d100000 0x0 0x400000>, /* p1 GICR node 3 */
> + <0x0 0xfe000000 0x0 0x10000>, /* GICC */
> + <0x0 0xfe010000 0x0 0x10000>, /* GICH */
> + <0x0 0xfe020000 0x0 0x10000>; /* GICV */
> + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> +
> + p0_its_peri_a: interrupt-controller at 4c000000 {
> + compatible = "arm,gic-v3-its";
> + msi-controller;
> + #msi-cells = <1>;
> + reg = <0x0 0x4c000000 0x0 0x40000>;
> + };
> +
> + p0_its_peri_b: interrupt-controller at 6c000000 {
> + compatible = "arm,gic-v3-its";
> + msi-controller;
> + #msi-cells = <1>;
> + reg = <0x0 0x6c000000 0x0 0x40000>;
> + };
> +
> + p0_its_dsa_a: interrupt-controller at c6000000 {
> + compatible = "arm,gic-v3-its";
> + msi-controller;
> + #msi-cells = <1>;
> + reg = <0x0 0xc6000000 0x0 0x40000>;
> + };
> +
> + p0_its_dsa_b: interrupt-controller at 8,c6000000 {
> + compatible = "arm,gic-v3-its";
> + msi-controller;
> + #msi-cells = <1>;
> + reg = <0x8 0xc6000000 0x0 0x40000>;
> + };
> +
> + p1_its_peri_a: interrupt-controller at 400,4c000000 {
> + compatible = "arm,gic-v3-its";
> + msi-controller;
> + #msi-cells = <1>;
> + reg = <0x400 0x4c000000 0x0 0x40000>;
> + };
> +
> + p1_its_peri_b: interrupt-controller at 400,6c000000 {
> + compatible = "arm,gic-v3-its";
> + msi-controller;
> + #msi-cells = <1>;
> + reg = <0x400 0x6c000000 0x0 0x40000>;
> + };
> +
> + p1_its_dsa_a: interrupt-controller at 400,c6000000 {
> + compatible = "arm,gic-v3-its";
> + msi-controller;
> + #msi-cells = <1>;
> + reg = <0x400 0xc6000000 0x0 0x40000>;
> + };
> +
> + p1_its_dsa_b: interrupt-controller at 408,c6000000 {
> + compatible = "arm,gic-v3-its";
> + msi-controller;
> + #msi-cells = <1>;
> + reg = <0x408 0xc6000000 0x0 0x40000>;
> + };
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
> + };
> +
> + pmu {
> + compatible = "arm,cortex-a72-pmu";
> + interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + p0_mbigen_peri_b: interrupt-controller at 60080000 {
> + compatible = "hisilicon,mbigen-v2";
> + reg = <0x0 0x60080000 0x0 0x10000>;
> +
> + mbigen_uart: uart_intc {
> + msi-parent = <&p0_its_peri_b 0x120c7>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + num-pins = <1>;
> + };
> + };
> +
> + p0_mbigen_pcie_a: interrupt-controller at a0080000 {
> + compatible = "hisilicon,mbigen-v2";
> + reg = <0x0 0xa0080000 0x0 0x10000>;
> +
> + mbigen_usb: intc_usb {
> + msi-parent = <&p0_its_dsa_a 0x40080>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + num-pins = <2>;
> + };
> + };
> +
> + soc {
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + uart0: uart at 602b0000 {
> + compatible = "arm,sbsa-uart";
> + reg = <0x0 0x602b0000 0x0 0x1000>;
> + interrupt-parent = <&mbigen_uart>;
> + interrupts = <807 4>;
> + current-speed = <115200>;
> + reg-io-width = <4>;
> + status = "disabled";
> + };
> +
> + usb_ohci: ohci at a7030000 {
> + compatible = "generic-ohci";
> + reg = <0x0 0xa7030000 0x0 0x10000>;
> + interrupt-parent = <&mbigen_usb>;
> + interrupts = <640 4>;
> + dma-coherent;
> + status = "disabled";
> + };
> +
> + usb_ehci: ehci at a7020000 {
> + compatible = "generic-ehci";
> + reg = <0x0 0xa7020000 0x0 0x10000>;
> + interrupt-parent = <&mbigen_usb>;
> + interrupts = <641 4>;
> + dma-coherent;
> + status = "disabled";
> + };
> + };
> +};
>
^ permalink raw reply
* [PATCH 1/3] ARM: dts: hip01: Remove skeleton.dtsi inclusion
From: Wei Xu @ 2016-11-15 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477297890-34899-1-git-send-email-wangkefeng.wang@huawei.com>
Hi Kefeng,
On 2016/10/24 9:31, Kefeng Wang wrote:
> Since commit 9c0da3cc61f1233c ("ARM: dts: explicitly mark skeleton.dtsi
> as deprecated"), remove deprecated skeleton.dtsi.
>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> ---
Applied all the 3 patches to the hisilicon soc tree.
Thanks!
Best Regards,
Wei
> arch/arm/boot/dts/hip01.dtsi | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/hip01.dtsi b/arch/arm/boot/dts/hip01.dtsi
> index 4e9562f..9d5fd5c 100644
> --- a/arch/arm/boot/dts/hip01.dtsi
> +++ b/arch/arm/boot/dts/hip01.dtsi
> @@ -11,8 +11,6 @@
> * published by the Free Software Foundation.
> */
>
> -#include "skeleton.dtsi"
> -
> / {
> interrupt-parent = <&gic>;
> #address-cells = <1>;
>
^ permalink raw reply
* [PATCH] ata: xgene: Enable NCQ support for APM X-Gene SATA controller hardware v1.1
From: Tejun Heo @ 2016-11-15 16:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFd313ycmpdp7wHCVRJrigJV31hLwBGOo=FNENwgFnNKyVkQBA@mail.gmail.com>
Hello, Rameshwar.
On Fri, Nov 11, 2016 at 01:36:28PM +0530, Rameshwar Sahu wrote:
> Hi Tejun,
>
> On Wed, Nov 9, 2016 at 10:15 PM, Tejun Heo <tj@kernel.org> wrote:
> > Hello,
> >
> > On Wed, Sep 14, 2016 at 04:15:00PM +0530, Rameshwar Sahu wrote:
> >> > @@ -821,8 +823,6 @@ static int xgene_ahci_probe(struct platform_device
> >> > *pdev)
> >> > dev_warn(&pdev->dev, "%s: Error reading
> >> > device info. Assume version1\n",
> >> > __func__);
> >> > version = XGENE_AHCI_V1;
> >> > - } else if (info->valid & ACPI_VALID_CID) {
> >> > - version = XGENE_AHCI_V2;
> >
> > Can you please explain this part a bit? Everything else looks good to
> > me.
>
> Here we should not assume XGENE_AHCI_V2 always in case of having valid
> _CID in ACPI table.
> I need to remove this assumption because V1_1 has also valid _CID for
> backward compatibly with v1.
Can you please repost with the above explanation added to the commit
message?
Thanks!
--
tejun
^ permalink raw reply
* [PATCH] iommu/dma: Stop getting dma_32bit_pfn wrong
From: Robin Murphy @ 2016-11-15 16:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115114909.GC24857@8bytes.org>
On 15/11/16 11:49, Joerg Roedel wrote:
> On Fri, Nov 11, 2016 at 06:30:45PM +0000, Robin Murphy wrote:
>> iommu_dma_init_domain() was originally written under the misconception
>> that dma_32bit_pfn represented some sort of size limit for IOVA domains.
>> Since the truth is almost the exact opposite of that, rework the logic
>> and comments to reflect its real purpose of optimising lookups when
>> allocating from a subset of the available space.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>> drivers/iommu/dma-iommu.c | 23 ++++++++++++++++++-----
>> 1 file changed, 18 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
>> index c5ab8667e6f2..ae045a14b530 100644
>> --- a/drivers/iommu/dma-iommu.c
>> +++ b/drivers/iommu/dma-iommu.c
>> @@ -139,6 +139,7 @@ int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
>> {
>> struct iova_domain *iovad = cookie_iovad(domain);
>> unsigned long order, base_pfn, end_pfn;
>> + bool pci = dev && dev_is_pci(dev);
>>
>> if (!iovad)
>> return -ENODEV;
>> @@ -161,19 +162,31 @@ int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
>> end_pfn = min_t(unsigned long, end_pfn,
>> domain->geometry.aperture_end >> order);
>> }
>> + /*
>> + * PCI devices may have larger DMA masks, but still prefer allocating
>> + * within a 32-bit mask to avoid DAC addressing. Such limitations don't
>> + * apply to the typical platform device, so for those we may as well
>> + * leave the cache limit at the top of the range they're likely to use.
>> + */
>> + if (pci)
>> + end_pfn = min_t(unsigned long, end_pfn,
>> + DMA_BIT_MASK(32) >> order);
>
> Question, does it actually hurt platform devices to follow the same
> allocation strategy as pci devices? I mean, does it hurt enough to
> special-case the code here?
It hurts them in the sense that they get absolutely no benefit from
trying a lower limit first (the device simply has as many address lines
wired to the interconnect as it needs/can drive), therefore there's
nothing to offset the cost of every allocation becoming
try-fail-and-try-again once <32-bits fills up with, say, big GPU
mappings. The maintenance cost of a couple of one-liner if statements
doesn't seem big enough to prevent a significant set of devices - bear
in mind that the first products really using this code in anger don't
have PCI@all (MT8173) - from having straightforward and optimal
allocation behaviour all the time, every time.
I suppose it might bear saying that as a Cambridge Water customer, I do
tend to view PCI in the same light as USB/I2C/etc. as "just another
external bus controller on the outside edge of 'the system'". From that
perspective, avoiding DAC overhead really does look like the minority
special case, although I appreciate that the view from the x86 angle is
rather different. I also suspect that, whether we want to or not, we may
continue to see more on-chip 'PCI' devices which don't really need this
either (because they're really just 'platform' devices talking directly
to whatever coherent interconnect with a config space bolted on somewhere).
Robin.
^ permalink raw reply
* [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options
From: Andrew Lunn @ 2016-11-15 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479220154-25851-2-git-send-email-jbrunet@baylibre.com>
On Tue, Nov 15, 2016 at 03:29:12PM +0100, Jerome Brunet wrote:
> On some platforms, energy efficient ethernet with rtl8211 devices is
> causing issue, like throughput drop or broken link.
>
> This was reported on the OdroidC2 (DWMAC + RTL8211F). While the issue root
> cause is not fully understood yet, disabling EEE advertisement prevent auto
> negotiation from enabling EEE.
>
> This patch provides options to disable 1000T and 100TX EEE advertisement
> individually for the realtek phys supporting this feature.
Looking at the code, i don't see anything specific to RealTek
here. This all seems generic. So should it be in phy.c and made a
generic OF property which can be applied to any PHY which supports
EEE.
Andrew
^ permalink raw reply
* [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol
From: Sudeep Holla @ 2016-11-15 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4e31f1d9-61b9-53a9-bd0c-dd5e452faece@arm.com>
On 11/11/16 14:19, Sudeep Holla wrote:
>
>
> On 11/11/16 13:34, Rob Herring wrote:
>> On Fri, Nov 11, 2016 at 1:48 AM, Sudeep Holla <sudeep.holla@arm.com>
>> wrote:
[...]
>>>
>>> True and I agree, how about "arm,scpi-pre-1.0" instead ?
>>
>> That's still meaningless. Convince me that multiple implementations
>> are identical, then we can have a common property. For example, how
>> many releases did ARM make before 1.0.
>>
>
> None officially, so I tend to agree with you on this.
>
> But so far we have seen some commonality between Rockchip and Amlogic
> implementations, which in fact shares some commonality with early
> release of SCPI from ARM (there are based on the same SCP code base,
> which is closed source and released to partners only). ARM improved the
> specification and the code base before the official release but by then
> it was adopted(as usual we were late ;))
>
> IMO, it's might be useful to have more generic say "arm,scpi-pre-1.0"
> and platform specific "amlogic,meson-gxbb-scpi"
>
Rob and Olof, is it convincing enough reason to have generic compatible?
Or you prefer to drop it ?
I prefer to have "arm,scpi-pre-1.0". IMO it's useful, let me know. I
need to send PR as it's getting late now.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options
From: Florian Fainelli @ 2016-11-15 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115163036.GB23231@lunn.ch>
On 11/15/2016 08:30 AM, Andrew Lunn wrote:
> On Tue, Nov 15, 2016 at 03:29:12PM +0100, Jerome Brunet wrote:
>> On some platforms, energy efficient ethernet with rtl8211 devices is
>> causing issue, like throughput drop or broken link.
>>
>> This was reported on the OdroidC2 (DWMAC + RTL8211F). While the issue root
>> cause is not fully understood yet, disabling EEE advertisement prevent auto
>> negotiation from enabling EEE.
>>
>> This patch provides options to disable 1000T and 100TX EEE advertisement
>> individually for the realtek phys supporting this feature.
>
> Looking at the code, i don't see anything specific to RealTek
> here. This all seems generic. So should it be in phy.c and made a
> generic OF property which can be applied to any PHY which supports
> EEE.
Agreed. Just to be sure, Jerome, you did verify that with EEE no longer
advertised, ethtool --set-eee fails, right? The point is that you may be
able to disable EEE on boot, but if there is a way to re-enable it later
on, we would want to disable that too.
--
Florian
^ permalink raw reply
* [PATCH 2/2] ARM: bcm2835: Add names for the Raspberry Pi Zero GPIO lines
From: Eric Anholt @ 2016-11-15 17:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479060729-25769-3-git-send-email-stefan.wahren@i2se.com>
Stefan Wahren <stefan.wahren@i2se.com> writes:
> This adds the GPIO names for the Raspberry Pi Zero. Since there are no
> schematics for the RPi Zero use the same as the Model A+.
These look good to me. I don't have a Zero schematic, but I compared to
dt-blob.
I've pulled these two to -next.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161115/e97dda27/attachment.sig>
^ permalink raw reply
* [PATCH v2 0/3] ARM: dts: sun7i: BPI-M1+ USB support
From: Maxime Ripard @ 2016-11-15 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115135106.438-1-wens@csie.org>
On Tue, Nov 15, 2016 at 09:51:03PM +0800, Chen-Yu Tsai wrote:
> Hi Maxime,
>
> These are the remaining patches of my BPI-M1+ fixes series from July.
>
> Changes since v1:
>
> - Split out USB PHY enable patch.
>
> - Dropped custom OPP table. Tested the A20 default one with
> cpufreq-ljt-stress-test and it seemed stable.
>
> - Dropped voltage range for cpu supply regulator to normal 1.0V ~ 1.4V.
>
> - Dropped pinmux setting for OTG ID pin.
Applied all three, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161115/a949c517/attachment.sig>
^ permalink raw reply
* [PATCH V7 1/3] ACPI: Retry IRQ conversion if it failed previously
From: Agustin Vega-Frias @ 2016-11-15 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115154833.GA16906@red-moon>
Hi Lorenzo,
On 2016-11-15 10:48, Lorenzo Pieralisi wrote:
> On Sun, Nov 13, 2016 at 04:59:33PM -0500, Agustin Vega-Frias wrote:
>> This allows probe deferral to work properly when a dependent device
>> fails to get a valid IRQ because the IRQ domain was not registered
>> at the time the resources were added to the platform_device.
>>
>> Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
>> ---
>> drivers/acpi/resource.c | 59
>> +++++++++++++++++++++++++++++++++++++++++++++++++
>> drivers/base/platform.c | 9 +++++++-
>> include/linux/acpi.h | 7 ++++++
>> 3 files changed, 74 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
>> index 56241eb..4beda15 100644
>> --- a/drivers/acpi/resource.c
>> +++ b/drivers/acpi/resource.c
>> @@ -664,3 +664,62 @@ int acpi_dev_filter_resource_type(struct
>> acpi_resource *ares,
>> return (type & types) ? 0 : 1;
>> }
>> EXPORT_SYMBOL_GPL(acpi_dev_filter_resource_type);
>> +
>> +struct acpi_irq_get_ctx {
>> + unsigned int index;
>> + struct resource *res;
>> +};
>> +
>> +static acpi_status acpi_irq_get_cb(struct acpi_resource *ares, void
>> *context)
>> +{
>> + struct acpi_irq_get_ctx *ctx = context;
>> + struct acpi_resource_irq *irq;
>> + struct acpi_resource_extended_irq *ext_irq;
>> +
>> + switch (ares->type) {
>> + case ACPI_RESOURCE_TYPE_IRQ:
>> + irq = &ares->data.irq;
>> + if (ctx->index < irq->interrupt_count) {
>> + acpi_dev_resource_interrupt(ares, ctx->index, ctx->res);
>> + return AE_CTRL_TERMINATE;
>> + }
>> + ctx->index -= irq->interrupt_count;
>
> I do not understand this code, mind explaining what it is meant to do ?
>
> In particular I do not understand the logic behind the index decrement,
> I think I am missing something here.
>
ACPI IRQ resources can be encoded into two types of structures:
struct acpi_resource_irq,
struct acpi_resource_extended_irq.
In theory only the extended version can contain multiple IRQs, but the
Linux
ACPI core accommodates non-compliant DSDT tables that have regular IRQ
resources
contain multiple IRQs.
To better explain, suppose you have a device that handles two GSIs and
one
other IRQ form a separate device:
Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, 0x00, )
{ 130, 131 }
Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, 0x00,
"\\_SB.TCS0.QIC0", )
{ 4 }
These are encoded into two separate structures with their own interrupts
array:
res0.interrupts[] = { 130, 131 }
res1.interrupts[] = { 4 }
However, from the perspective of a client driver these are indexed into
a flat space:
[0] -> 130
[1] -> 131
[2] -> 4
Now say mapping of IRQ 4 failed during bus scan. When acpi_irq_get
retries to map
it, the client code will pass index 2. acpi_walk_resources will call
acpi_irq_get_cb
with the first IRQ resource. If the index is less than the number of
IRQs, we know
this IRQ resource contains the IRQ we want so we call
acpi_dev_resource_interrupt
to do the actual mapping and return AE_CTRL_TERMINATE so
acpi_walk_resources does
not continue walking the resource buffer. On the other hand if the index
is equal
or larger it means we need to skip this IRQ resource and look at the
next one,
but we need to adjust the lookup index to that of the next IRQ resource.
Makes sense?
>> + break;
>> + case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
>> + ext_irq = &ares->data.extended_irq;
>> + if (ctx->index < ext_irq->interrupt_count) {
>> + acpi_dev_resource_interrupt(ares, ctx->index, ctx->res);
>> + return AE_CTRL_TERMINATE;
>> + }
>> + ctx->index -= ext_irq->interrupt_count;
>
> Ditto.
The same logic is used for both types of resources because they are
handled in
the same way by the ACPI core when it comes to indexing.
Thanks,
Agustin
>
> Thanks,
> Lorenzo
>
>> + break;
>> + }
>> +
>> + return AE_OK;
>> +}
>> +
>> +/**
>> + * acpi_irq_get - Look for the ACPI IRQ resource with the given index
>> and
>> + * use it to initialize the given Linux IRQ resource.
>> + * @handle ACPI device handle
>> + * @index ACPI IRQ resource index to lookup
>> + * @res Linux IRQ resource to initialize
>> + *
>> + * Return: 0 on success
>> + * -EINVAL if an error occurs
>> + * -EPROBE_DEFER if the IRQ lookup/conversion failed
>> + */
>> +int acpi_irq_get(acpi_handle handle, unsigned int index, struct
>> resource *res)
>> +{
>> + struct acpi_irq_get_ctx ctx = { index, res };
>> + acpi_status status;
>> +
>> + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
>> + acpi_irq_get_cb, &ctx);
>> + if (ACPI_FAILURE(status))
>> + return -EINVAL;
>> + if (res->flags & IORESOURCE_DISABLED)
>> + return -EPROBE_DEFER;
>> + return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(acpi_irq_get);
>> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
>> index c4af003..61423d2 100644
>> --- a/drivers/base/platform.c
>> +++ b/drivers/base/platform.c
>> @@ -102,6 +102,14 @@ int platform_get_irq(struct platform_device *dev,
>> unsigned int num)
>> }
>>
>> r = platform_get_resource(dev, IORESOURCE_IRQ, num);
>> + if (r && r->flags & IORESOURCE_DISABLED &&
>> ACPI_COMPANION(&dev->dev)) {
>> + int ret;
>> +
>> + ret = acpi_irq_get(ACPI_HANDLE(&dev->dev), num, r);
>> + if (ret)
>> + return ret;
>> + }
>> +
>> /*
>> * The resources may pass trigger flags to the irqs that need
>> * to be set up. It so happens that the trigger flags for
>> @@ -1450,4 +1458,3 @@ void __init early_platform_cleanup(void)
>> memset(&pd->dev.devres_head, 0, sizeof(pd->dev.devres_head));
>> }
>> }
>> -
>> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
>> index 689a8b9..325bdb9 100644
>> --- a/include/linux/acpi.h
>> +++ b/include/linux/acpi.h
>> @@ -406,6 +406,7 @@ bool acpi_dev_resource_ext_address_space(struct
>> acpi_resource *ares,
>> unsigned int acpi_dev_get_irq_type(int triggering, int polarity);
>> bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int
>> index,
>> struct resource *res);
>> +int acpi_irq_get(acpi_handle handle, unsigned int index, struct
>> resource *res);
>>
>> void acpi_dev_free_resource_list(struct list_head *list);
>> int acpi_dev_get_resources(struct acpi_device *adev, struct list_head
>> *list,
>> @@ -763,6 +764,12 @@ static inline int
>> acpi_reconfig_notifier_unregister(struct notifier_block *nb)
>> return -EINVAL;
>> }
>>
>> +static inline int acpi_irq_get(acpi_handle handle, unsigned int
>> index,
>> + struct resource *res)
>> +{
>> + return -EINVAL;
>> +}
>> +
>> #endif /* !CONFIG_ACPI */
>>
>> #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
>> --
>> Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm
>> Technologies, Inc.
>> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a
>> Linux Foundation Collaborative Project.
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
>> in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v3 00/11] soc: renesas: Identify SoC and register with the SoC bus
From: Simon Horman @ 2016-11-15 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479148637-5399-1-git-send-email-geert+renesas@glider.be>
On Mon, Nov 14, 2016 at 07:37:06PM +0100, Geert Uytterhoeven wrote:
> Hi Simon, Magnus,
>
> Some Renesas SoCs may exist in different revisions, providing slightly
> different functionalities (e.g. R-Car H3 ES1.x and ES2.0), and behavior
> (errate and quirks). This needs to be catered for by drivers and/or
> platform code. The recently proposed soc_device_match() API is a good
> fit to handle this.
>
> This patch series implements the core infrastructure to provide SoC and
> revision information through the SoC bus for Renesas ARM SoCs.
For the record I have queued this up.
^ permalink raw reply
* [PATCH v6 0/7] Add R8A7743/SK-RZG1M board support
From: Simon Horman @ 2016-11-15 17:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1746536.qobnGdHRfV@wasted.cogentembedded.com>
On Mon, Oct 31, 2016 at 10:52:25PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> Here's the set of 7 patches against Simon Horman's 'renesas.git' repo's
> 'renesas-devel-20161031-v4.9-rc3' tag. I'm adding the device tree support for
> the R8A7743-based SK-RZG1M board. The SoC is close to R8A7791 and the board
> seems identical to the R8A7791/Porter board. The device tree patches depend on
> the R8A7743 CPG/MSSR driver series in order to compile and work. Already merged
> patches from this series won't be re-posted.
>
> [1/7] ARM: dts: r8a7743: initial SoC device tree
> [2/7] ARM: dts: r8a7743: add SYS-DMAC support
> [3/7] ARM: dts: r8a7743: add [H]SCIF{A|B} support
> [4/7] ARM: dts: r8a7743: add Ether support
> [5/7] ARM: dts: r8a7743: add IRQC support
> [6/7] ARM: dts: sk-rzg1m: initial device tree
> [7/7] ARM: dts: sk-rzg1m: add Ether support
Thanks, I have queued this up.
^ permalink raw reply
* [PATCH v6 3/7] ARM: dts: r8a7743: add [H]SCIF{A|B} support
From: Simon Horman @ 2016-11-15 17:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <29562553.JmvzVUkhx3@wasted.cogentembedded.com>
On Mon, Oct 31, 2016 at 10:55:39PM +0300, Sergei Shtylyov wrote:
> Describe [H]SCIF{|A|B} ports in the R8A7743 device tree.
>
> Based on the original (and large) patch by Dmitry Shifrin
> <dmitry.shifrin@cogentembedded.com>.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
I have queued this up after updating the indentation to use
tabs where possible.
^ permalink raw reply
* [PATCH v2 0/11] Add R8A7745/SK-RZG1E board support
From: Simon Horman @ 2016-11-15 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2368353.xfo5beGC5E@wasted.cogentembedded.com>
On Sat, Nov 05, 2016 at 12:42:33AM +0300, Sergei Shtylyov wrote:
> Hello.
>
> Here's the set of 11 patches against Simon Horman's 'renesas.git' repo's
> 'renesas-devel-201611104-v4.9-rc3' tag plus the R8A7743/SK-RZG1M patch series
> posted earlier. I'm adding the device tree support for the R8A7745-based
> SK-RZG1E board. The SoC is close to R8A7794 and the board seems identical to the
> R8A7794/SILK board. The device tree patches depend on the R8A7745 CPG/MSSR
> driver series in order to compile and work.
Thanks, I have queued this up.
^ permalink raw reply
* [PATCH 06/11] ARM: dts: r8a7745: add [H]SCIF{A|B} support
From: Simon Horman @ 2016-11-15 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2366203.iKt2DUneo7@wasted.cogentembedded.com>
On Sat, Oct 29, 2016 at 01:19:40AM +0300, Sergei Shtylyov wrote:
> Describe [H]SCIF{|A|B} ports in the R8A7745 device tree.
>
> Based on the original (and large) patch by Dmitry Shifrin
> <dmitry.shifrin@cogentembedded.com>.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
I have queued this up after updating the indentation to use
tabs where possible.
^ permalink raw reply
* [PATCH 2/2] ARM: zynq: Fix W=1 dtc 1.4 warnings
From: Michal Simek @ 2016-11-15 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115154608.GH30999@jcartwri.amer.corp.natinst.com>
Hi,
On 15.11.2016 16:46, Julia Cartwright wrote:
> On Tue, Nov 15, 2016 at 03:07:27PM +0100, Michal Simek wrote:
>> The patch removes these warnings reported by dtc 1.4:
>> Warning (unit_address_vs_reg): Node /pmu has a reg or ranges property,
>> but no unit name
>> Warning (unit_address_vs_reg): Node /fixedregulator at 0 has a unit name,
>> but no reg property
>> Warning (unit_address_vs_reg): Node /memory has a reg or ranges
>> property, but no unit name
>>
>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
>
> Reviewed-by: Julia Cartwright <julia@ni.com>
>>
>> ---
>>
>> arch/arm/boot/dts/zynq-7000.dtsi | 4 ++--
>> arch/arm/boot/dts/zynq-parallella.dts | 2 +-
>> arch/arm/boot/dts/zynq-zc702.dts | 2 +-
>> arch/arm/boot/dts/zynq-zc706.dts | 2 +-
>> arch/arm/boot/dts/zynq-zed.dts | 2 +-
>> arch/arm/boot/dts/zynq-zybo.dts | 2 +-
>> 6 files changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
>> index f47a6c1cc752..402b5bbe3b5b 100644
>> --- a/arch/arm/boot/dts/zynq-7000.dtsi
>> +++ b/arch/arm/boot/dts/zynq-7000.dtsi
>> @@ -42,14 +42,14 @@
>> };
>> };
>>
>> - pmu {
>> + pmu at f8891000 {
>> compatible = "arm,cortex-a9-pmu";
>> interrupts = <0 5 4>, <0 6 4>;
>> interrupt-parent = <&intc>;
>> reg = < 0xf8891000 0x1000 0xf8893000 0x1000 >;
>
> Style nit: we should drop the space before/after '<' and '>'; and,
> perhaps separate the entries to be a bit more readable:
>
> reg = <0xf8891000 0x1000>,
> <0xf8893000 0x1000>;
yes we can do it. Do you want to send separate patch for it?
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161115/a15ffc5e/attachment.sig>
^ permalink raw reply
* [PATCH 03/15] net: bcm63xx_enet: Utilize phy_ethtool_nway_reset
From: Florian Fainelli @ 2016-11-15 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115180644.3941-1-f.fainelli@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/broadcom/bcm63xx_enet.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
index 5c7acef1de2e..a43ab90c051e 100644
--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
@@ -1434,11 +1434,8 @@ static int bcm_enet_nway_reset(struct net_device *dev)
struct bcm_enet_priv *priv;
priv = netdev_priv(dev);
- if (priv->has_phy) {
- if (!dev->phydev)
- return -ENODEV;
- return genphy_restart_aneg(dev->phydev);
- }
+ if (priv->has_phy)
+ return phy_ethtool_nway_reset(dev),
return -EOPNOTSUPP;
}
--
2.9.3
^ permalink raw reply related
* [PATCH 07/15] net: ethernet: ll_temac: Utilize phy_ethtool_nway_reset
From: Florian Fainelli @ 2016-11-15 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115180644.3941-1-f.fainelli@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/xilinx/ll_temac_main.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/ll_temac_main.c b/drivers/net/ethernet/xilinx/ll_temac_main.c
index a9bd665fd122..bcd7b76dde9f 100644
--- a/drivers/net/ethernet/xilinx/ll_temac_main.c
+++ b/drivers/net/ethernet/xilinx/ll_temac_main.c
@@ -967,13 +967,8 @@ static const struct attribute_group temac_attr_group = {
};
/* ethtool support */
-static int temac_nway_reset(struct net_device *ndev)
-{
- return phy_start_aneg(ndev->phydev);
-}
-
static const struct ethtool_ops temac_ethtool_ops = {
- .nway_reset = temac_nway_reset,
+ .nway_reset = phy_ethtool_nway_reset,
.get_link = ethtool_op_get_link,
.get_ts_info = ethtool_op_get_ts_info,
.get_link_ksettings = phy_ethtool_get_link_ksettings,
--
2.9.3
^ permalink raw reply related
* [PATCH fpga 1/9] fpga zynq: Add missing \n to messages
From: Jason Gunthorpe @ 2016-11-15 18:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0aebdb59-86d7-2569-c49d-de5d45b5cac0@suse.com>
On Tue, Nov 15, 2016 at 12:05:15PM +0100, Matthias Brugger wrote:
> On 09/11/16 23:58, Jason Gunthorpe wrote:
> >Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
>
> Please add a commit message, although it is cristal clear what this patch
> does :)
As you say, it is crystal clear already, and this is an acceptable commit
message.. Please suggest a text if you want to see something
different.
Jason
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: Add ARM PMU node for exynos7
From: Krzysztof Kozlowski @ 2016-11-15 18:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9327f863-7fa3-a967-892c-67158b2471a9@osg.samsung.com>
On Sat, Nov 12, 2016 at 11:33:18AM -0300, Javier Martinez Canillas wrote:
> Hello Alim,
>
> On 11/12/2016 07:17 AM, Alim Akhtar wrote:
> > This patch adds ARM Performance Monitor Unit dt node for exynos7.
> > PMU provides various statistics on the operation of the CPU and
> > memory system at runtime, which are very useful when debugging or
> > profiling code. This enables the same.
> >
> > Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
> > ---
> > arch/arm64/boot/dts/exynos/exynos7.dtsi | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> >
> > Changes since v1:
> > * Added "interrupt-affinity" property as per Robin Murphy review comment.
> >
> > diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> > index 396ffb9..09e7a05b 100644
> > --- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
> > +++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> > @@ -472,6 +472,16 @@
> > status = "disabled";
> > };
> >
> > + arm-pmu {
> > + compatible = "arm,cortex-a57-pmu", "arm,armv8-pmuv3";
> > + interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
> > + interrupt-affinity = <&cpu_atlas0>, <&cpu_atlas1>,
> > + <&cpu_atlas2>, <&cpu_atlas3>;
> > + };
> > +
>
> I didn't double check if these are the correct IRQs because I don't have
> an Exynos7 user manual, but the change looks good to me.
>
> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Squashed 1/2 with this and applied. Thanks!
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2] arm64: SMMU-v2: Workaround for Cavium ThunderX erratum 28168
From: David Daney @ 2016-11-15 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0414d797-7134-8192-d373-b14b26edd023@arm.com>
On 11/15/2016 01:26 AM, Marc Zyngier wrote:
> On 15/11/16 07:00, Geetha sowjanya wrote:
>> From: Tirumalesh Chalamarla <Tirumalesh.Chalamarla@cavium.com>
>>
>> This patch implements Cavium ThunderX erratum 28168.
>>
>> PCI requires stores complete in order. Due to erratum #28168
>> PCI-inbound MSI-X store to the interrupt controller are delivered
>> to the interrupt controller before older PCI-inbound memory stores
>> are committed.
>> Doing a sync on SMMU will make sure all prior data transfers are
>> completed before invoking ISR.
>>
>> Signed-off-by: Tirumalesh Chalamarla <Tirumalesh.Chalamarla@cavium.com>
>> Signed-off-by: Geetha sowjanya <gakula@caviumnetworks.com>
[...]
>> --- a/drivers/irqchip/irq-gic-v3.c
>> +++ b/drivers/irqchip/irq-gic-v3.c
>> @@ -28,6 +28,8 @@
>> #include <linux/of_irq.h>
>> #include <linux/percpu.h>
>> #include <linux/slab.h>
>> +#include <linux/msi.h>
>> +#include <linux/pci.h>
>>
>> #include <linux/irqchip.h>
>> #include <linux/irqchip/arm-gic-common.h>
>> @@ -736,6 +738,20 @@ static inline void gic_cpu_pm_init(void) { }
>>
>> #define GIC_ID_NR (1U << gic_data.rdists.id_bits)
>>
>> +/*
>> + * Due to #28168 erratum in ThunderX,
>> + * we need to make sure DMA data transfer is done before MSIX.
>> + */
>> +static void cavium_irq_perflow_handler(struct irq_data *data)
>> +{
>> + struct pci_dev *pdev;
>> +
>> + pdev = msi_desc_to_pci_dev(irq_data_get_msi_desc(data));
>
> What happens if this is not a PCI device?
>
>> + if ((pdev->vendor != 0x177d) &&
>> + ((pdev->device & 0xA000) != 0xA000))
>> + cavium_arm_smmu_tlb_sync(&pdev->dev);
>
> I've asked that before. What makes Cavium devices so special that they
> are not sensitive to this bug?
This is a heuristic for devices connected to external PCIe buses as
opposed to on-SoC devices (which don't suffer from the erratum).
In any event what would happen if we got rid of this check and ...
>
>> +}
>> +
>> static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq,
>> irq_hw_number_t hw)
>> {
>> @@ -773,6 +789,9 @@ static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq,
>> return -EPERM;
>> irq_domain_set_info(d, irq, hw, chip, d->host_data,
>> handle_fasteoi_irq, NULL, NULL);
>> + if (cpus_have_cap(ARM64_WORKAROUND_CAVIUM_28168))
>> + __irq_set_preflow_handler(irq,
>> + cavium_irq_perflow_handler);
>
... move the registration of the preflow_handler into a
msi_domain_ops.msi_finish() handler in irq-git-v3-its-pic-msi.c?
There we will know that it is a pci device, and can walk up the bus
hierarchy to see if there is a Cavium PCIe root port present. If such a
port is found, we know we are on an external Cavium PCIe bus, and can
register the preflow_handler without having to check the device identifiers.
> What happens if SMMUv2 is not compiled in? Also, since this only affects
> LPI signaling, why is this in the core GICv3 code and not in the ITS.
> And more specifically, in the PCI part of the ITS, since you seem to
> exclusively consider PCI?
>
>> }
>>
>> return 0;
>>
>
> Thanks,
>
> M.
>
^ permalink raw reply
* [RFCv2 PATCH 1/5] video: add HDMI state notifier support
From: Philipp Zabel @ 2016-11-15 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479136968-24477-2-git-send-email-hverkuil@xs4all.nl>
Hi Hans,
Am Montag, den 14.11.2016, 16:22 +0100 schrieb Hans Verkuil:
> From: Hans Verkuil <hans.verkuil@cisco.com>
>
> Add support for HDMI hotplug and EDID notifiers, which is used to convey
> information from HDMI drivers to their CEC and audio counterparts.
>
> Based on an earlier version from Russell King:
>
> https://patchwork.kernel.org/patch/9277043/
>
> The hdmi_notifier is a reference counted object containing the HDMI state
> of an HDMI device.
>
> When a new notifier is registered the current state will be reported to
> that notifier at registration time.
>
> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> ---
> drivers/video/Kconfig | 3 +
> drivers/video/Makefile | 1 +
> drivers/video/hdmi-notifier.c | 136 ++++++++++++++++++++++++++++++++++++++++++
> include/linux/hdmi-notifier.h | 43 +++++++++++++
> 4 files changed, 183 insertions(+)
> create mode 100644 drivers/video/hdmi-notifier.c
> create mode 100644 include/linux/hdmi-notifier.h
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 3c20af9..1ee7b9f 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -36,6 +36,9 @@ config VIDEOMODE_HELPERS
> config HDMI
> bool
>
> +config HDMI_NOTIFIERS
> + bool
> +
> if VT
> source "drivers/video/console/Kconfig"
> endif
> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> index 9ad3c17..65f5649 100644
> --- a/drivers/video/Makefile
> +++ b/drivers/video/Makefile
> @@ -1,5 +1,6 @@
> obj-$(CONFIG_VGASTATE) += vgastate.o
> obj-$(CONFIG_HDMI) += hdmi.o
> +obj-$(CONFIG_HDMI_NOTIFIERS) += hdmi-notifier.o
>
> obj-$(CONFIG_VT) += console/
> obj-$(CONFIG_LOGO) += logo/
> diff --git a/drivers/video/hdmi-notifier.c b/drivers/video/hdmi-notifier.c
> new file mode 100644
> index 0000000..c2a4f1b
> --- /dev/null
> +++ b/drivers/video/hdmi-notifier.c
> @@ -0,0 +1,136 @@
> +#include <linux/export.h>
> +#include <linux/hdmi-notifier.h>
> +#include <linux/string.h>
> +#include <linux/slab.h>
> +#include <linux/list.h>
> +
> +struct hdmi_notifiers {
> + struct list_head head;
> + struct device *dev;
> + struct hdmi_notifier *n;
> +};
This struct is not used, can be removed.
> +static LIST_HEAD(hdmi_notifiers);
> +static DEFINE_MUTEX(hdmi_notifiers_lock);
> +
> +struct hdmi_notifier *hdmi_notifier_get(struct device *dev)
> +{
> + struct hdmi_notifier *n;
> +
> + mutex_lock(&hdmi_notifiers_lock);
> + list_for_each_entry(n, &hdmi_notifiers, head) {
> + if (n->dev == dev) {
> + mutex_unlock(&hdmi_notifiers_lock);
> + kref_get(&n->kref);
> + return n;
> + }
> + }
> + n = kzalloc(sizeof(*n), GFP_KERNEL);
> + if (!n)
> + goto unlock;
> + mutex_init(&n->lock);
> + BLOCKING_INIT_NOTIFIER_HEAD(&n->notifiers);
> + kref_init(&n->kref);
+ n->dev = dev;
Currently n->dev is never set, so every caller of this function gets its
own hdmi_notifier.
> + list_add_tail(&n->head, &hdmi_notifiers);
> +unlock:
> + mutex_unlock(&hdmi_notifiers_lock);
> + return n;
> +}
> +EXPORT_SYMBOL_GPL(hdmi_notifier_get);
> +
> +static void hdmi_notifier_release(struct kref *kref)
> +{
> + struct hdmi_notifier *n =
> + container_of(kref, struct hdmi_notifier, kref);
> +
> + kfree(n->edid);
> + kfree(n);
> +}
> +
> +void hdmi_notifier_put(struct hdmi_notifier *n)
> +{
> + kref_put(&n->kref, hdmi_notifier_release);
> +}
> +EXPORT_SYMBOL_GPL(hdmi_notifier_put);
> +
> +int hdmi_notifier_register(struct hdmi_notifier *n, struct notifier_block *nb)
> +{
> + int ret = blocking_notifier_chain_register(&n->notifiers, nb);
> +
> + if (ret)
> + return ret;
> + kref_get(&n->kref);
> + mutex_lock(&n->lock);
> + if (n->connected) {
> + blocking_notifier_call_chain(&n->notifiers, HDMI_CONNECTED, n);
> + if (n->edid_size)
> + blocking_notifier_call_chain(&n->notifiers, HDMI_NEW_EDID, n);
> + if (n->has_eld)
> + blocking_notifier_call_chain(&n->notifiers, HDMI_NEW_ELD, n);
> + }
> + mutex_unlock(&n->lock);
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(hdmi_notifier_register);
> +
> +int hdmi_notifier_unregister(struct hdmi_notifier *n, struct notifier_block *nb)
> +{
> + int ret = blocking_notifier_chain_unregister(&n->notifiers, nb);
> +
> + if (ret == 0)
> + hdmi_notifier_put(n);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(hdmi_notifier_unregister);
> +
> +void hdmi_event_connect(struct hdmi_notifier *n)
> +{
> + mutex_lock(&n->lock);
> + n->connected = true;
> + blocking_notifier_call_chain(&n->notifiers, HDMI_CONNECTED, n);
> + mutex_unlock(&n->lock);
> +}
> +EXPORT_SYMBOL_GPL(hdmi_event_connect);
> +
> +void hdmi_event_disconnect(struct hdmi_notifier *n)
> +{
> + mutex_lock(&n->lock);
> + n->connected = false;
> + n->has_eld = false;
> + n->edid_size = 0;
> + blocking_notifier_call_chain(&n->notifiers, HDMI_DISCONNECTED, n);
> + mutex_unlock(&n->lock);
> +}
> +EXPORT_SYMBOL_GPL(hdmi_event_disconnect);
> +
> +int hdmi_event_new_edid(struct hdmi_notifier *n, const void *edid, size_t size)
> +{
> + mutex_lock(&n->lock);
> + if (n->edid_allocated_size < size) {
> + void *p = kmalloc(size, GFP_KERNEL);
> +
> + if (p == NULL) {
> + mutex_unlock(&n->lock);
> + return -ENOMEM;
> + }
> + kfree(n->edid);
> + n->edid = p;
> + n->edid_allocated_size = size;
> + }
> + memcpy(n->edid, edid, size);
> + n->edid_size = size;
> + blocking_notifier_call_chain(&n->notifiers, HDMI_NEW_EDID, n);
> + mutex_unlock(&n->lock);
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(hdmi_event_new_edid);
> +
> +void hdmi_event_new_eld(struct hdmi_notifier *n, const u8 eld[128])
> +{
> + mutex_lock(&n->lock);
> + memcpy(n->eld, eld, sizeof(n->eld));
> + n->has_eld = true;
> + blocking_notifier_call_chain(&n->notifiers, HDMI_NEW_ELD, n);
> + mutex_unlock(&n->lock);
> +}
> +EXPORT_SYMBOL_GPL(hdmi_event_new_eld);
> diff --git a/include/linux/hdmi-notifier.h b/include/linux/hdmi-notifier.h
> new file mode 100644
> index 0000000..f7fc405
> --- /dev/null
> +++ b/include/linux/hdmi-notifier.h
> @@ -0,0 +1,43 @@
> +#ifndef LINUX_HDMI_NOTIFIER_H
> +#define LINUX_HDMI_NOTIFIER_H
> +
> +#include <linux/types.h>
> +#include <linux/notifier.h>
> +#include <linux/kref.h>
> +
> +enum {
> + HDMI_CONNECTED,
> + HDMI_DISCONNECTED,
> + HDMI_NEW_EDID,
> + HDMI_NEW_ELD,
> +};
> +
> +struct device;
> +
> +struct hdmi_notifier {
> + struct mutex lock;
> + struct list_head head;
> + struct kref kref;
> + struct blocking_notifier_head notifiers;
> + struct device *dev;
> +
> + /* Current state */
> + bool connected;
> + bool has_eld;
> + unsigned char eld[128];
> + void *edid;
> + size_t edid_size;
> + size_t edid_allocated_size;
> +};
> +
> +struct hdmi_notifier *hdmi_notifier_get(struct device *dev);
> +void hdmi_notifier_put(struct hdmi_notifier *n);
> +int hdmi_notifier_register(struct hdmi_notifier *n, struct notifier_block *nb);
> +int hdmi_notifier_unregister(struct hdmi_notifier *n, struct notifier_block *nb);
> +
> +void hdmi_event_connect(struct hdmi_notifier *n);
> +void hdmi_event_disconnect(struct hdmi_notifier *n);
> +int hdmi_event_new_edid(struct hdmi_notifier *n, const void *edid, size_t size);
> +void hdmi_event_new_eld(struct hdmi_notifier *n, const u8 eld[128]);
> +
> +#endif
With the above change,
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de> (on MT8173)
I'll send the patches for mediatek-drm and hdmi-codec that I used for
testing in a bit.
regards
Philipp
^ 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