linux-kernel - Re: [PATCH] ARM: dts: mvebu: linksys: enable buffer manager support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8760jafiy8.fsf@free-electrons.com>
Date:   Wed, 15 Mar 2017 20:17:35 +0100
From:   Gregory CLEMENT <gregory.clement@...e-electrons.com>
To:     Ralph Sennhauser <ralph.sennhauser@...il.com>
Cc:     Jason Cooper <jason@...edaemon.net>, Andrew Lunn <andrew@...n.ch>,
        Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Russell King <linux@...linux.org.uk>,
        linux-arm-kernel@...ts.infradead.org (moderated list:ARM/Marvell
        Kirkwood and Armada 370, 375, 38x,...),
        devicetree@...r.kernel.org (open list:OPEN FIRMWARE AND FLATTENED
        DEVICE TREE BINDINGS), linux-kernel@...r.kernel.org (open list)
Subject: Re: [PATCH] ARM: dts: mvebu: linksys: enable buffer manager support

Hi Ralph,
 
 On mer., mars 08 2017, Ralph Sennhauser <ralph.sennhauser@...il.com> wrote:

> Add appropriate properties to devices in the Linksys WRT AC Series for the
> mvneta driver to use hardware buffer management.
>
> Also update "soc" ranges property and set the status of bm and bm-bppi
> to "okay" (SRAM).
>
> Signed-off-by: Ralph Sennhauser <ralph.sennhauser@...il.com>
> ---
>  arch/arm/boot/dts/armada-385-linksys.dtsi     | 17 ++++++++++++++++-
>  arch/arm/boot/dts/armada-xp-linksys-mamba.dts | 17 ++++++++++++++++-
>  2 files changed, 32 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/armada-385-linksys.dtsi b/arch/arm/boot/dts/armada-385-linksys.dtsi
> index df47bf1..4aac375 100644
> --- a/arch/arm/boot/dts/armada-385-linksys.dtsi
> +++ b/arch/arm/boot/dts/armada-385-linksys.dtsi
> @@ -59,7 +59,8 @@
>  		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
>  			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
>  			  MBUS_ID(0x09, 0x19) 0 0xf1100000 0x10000
> -			  MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000>;
> +			  MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000
> +			  MBUS_ID(0x0c, 0x04) 0 0xf1200000 0x100000>;
>  
>  		internal-regs {
>  			i2c@...00 {
> @@ -88,6 +89,9 @@
>  			ethernet@...00 {
>  				status = "okay";
>  				phy-mode = "rgmii-id";
> +				buffer-manager = <&bm>;
> +				bm,pool-long = <1>;
> +				bm,pool-short = <3>;
>  				fixed-link {
>  					speed = <1000>;
>  					full-duplex;
> @@ -97,6 +101,9 @@
>  			ethernet@...00 {
>  				status = "okay";
>  				phy-mode = "sgmii";
> +				buffer-manager = <&bm>;
> +				bm,pool-long = <0>;
> +				bm,pool-short = <3>;
Any reason to reuse the same pool than the other port?

As only two ports are used here, then each of them can have use 2 of the
4 availables pools. 

>  				fixed-link {
>  					speed = <1000>;
>  					full-duplex;
> @@ -159,6 +166,10 @@
>  				status = "okay";
>  			};
>  
> +			bm@...00 {
> +				status = "okay";
> +			};
> +
>  			/* USB part of the eSATA/USB 2.0 port */
>  			usb@...00 {
>  				status = "okay";
> @@ -241,6 +252,10 @@
>  			};
>  		};
>  
> +		bm-bppi {
> +			status = "okay";
> +		};
> +
>  		pcie-controller {
>  			status = "okay";
>  
> diff --git a/arch/arm/boot/dts/armada-xp-linksys-mamba.dts b/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
> index 3744ba3..b188a4dc 100644
> --- a/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
> +++ b/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
> @@ -71,7 +71,8 @@
>  		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000
>  			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
>  			  MBUS_ID(0x09, 0x09) 0 0 0xf1100000 0x10000
> -			  MBUS_ID(0x09, 0x05) 0 0 0xf1110000 0x10000>;
> +			  MBUS_ID(0x09, 0x05) 0 0 0xf1110000 0x10000
> +			  MBUS_ID(0x0c, 0x04) 0 0 0xf1200000 0x100000>;
>  
>  		internal-regs {
>  
> @@ -95,6 +96,9 @@
>  				pinctrl-names = "default";
>  				status = "okay";
>  				phy-mode = "rgmii-id";
> +				buffer-manager = <&bm>;
> +				bm,pool-long = <0>;
> +				bm,pool-short = <3>;
>  				fixed-link {
>  					speed = <1000>;
>  					full-duplex;
> @@ -106,6 +110,9 @@
>  				pinctrl-names = "default";
>  				status = "okay";
>  				phy-mode = "rgmii-id";
> +				buffer-manager = <&bm>;
> +				bm,pool-long = <1>;
> +				bm,pool-short = <3>;
Same question that above.

Gregory

>  				fixed-link {
>  					speed = <1000>;
>  					full-duplex;
> @@ -186,6 +193,10 @@
>  				};
>  			};
>  
> +			bm@...00 {
> +				status = "okay";
> +			};
> +
>  			nand@...00 {
>  				status = "okay";
>  				num-cs = <1>;
> @@ -259,6 +270,10 @@
>  				};
>  			};
>  		};
> +
> +		bm-bppi {
> +			status = "okay";
> +		};
>  	};
>  
>  	gpio_keys {
> -- 
> 2.10.2
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com