* [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
@ 2018-05-18 18:34 ` Scott Branden
0 siblings, 0 replies; 24+ messages in thread
From: Scott Branden @ 2018-05-18 18:34 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Catalin Marinas, Will Deacon, Ray Jui
Cc: BCM Kernel Feedback, devicetree, linux-arm-kernel, linux-kernel,
Scott Branden
Move remaining sata configuration to stingray-sata.dtsi and enable
ports based on NUM_SATA defined.
Now, all that needs to be done is define NUM_SATA per board.
Signed-off-by: Scott Branden <scott.branden@broadcom.com>
---
.../boot/dts/broadcom/stingray/bcm958742-base.dtsi | 64 --------------------
.../boot/dts/broadcom/stingray/bcm958742k.dts | 2 +
.../boot/dts/broadcom/stingray/bcm958742t.dts | 2 +
.../boot/dts/broadcom/stingray/stingray-sata.dtsi | 68 ++++++++++++++++++++++
4 files changed, 72 insertions(+), 64 deletions(-)
diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
index 8862ec9..cacc25e 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
@@ -72,70 +72,6 @@
<0x00000008 0x80000000 0x1 0x80000000>; /* 6G @ 34G */
};
-&sata0 {
- status = "okay";
-};
-
-&sata_phy0{
- status = "okay";
-};
-
-&sata1 {
- status = "okay";
-};
-
-&sata_phy1{
- status = "okay";
-};
-
-&sata2 {
- status = "okay";
-};
-
-&sata_phy2{
- status = "okay";
-};
-
-&sata3 {
- status = "okay";
-};
-
-&sata_phy3{
- status = "okay";
-};
-
-&sata4 {
- status = "okay";
-};
-
-&sata_phy4{
- status = "okay";
-};
-
-&sata5 {
- status = "okay";
-};
-
-&sata_phy5{
- status = "okay";
-};
-
-&sata6 {
- status = "okay";
-};
-
-&sata_phy6{
- status = "okay";
-};
-
-&sata7 {
- status = "okay";
-};
-
-&sata_phy7{
- status = "okay";
-};
-
&mdio_mux_iproc {
mdio@10 {
gphy0: eth-phy@10 {
diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
index 77efa28..a515346 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
@@ -32,6 +32,8 @@
/dts-v1/;
+#define NUM_SATA 8
+
#include "bcm958742-base.dtsi"
/ {
diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts b/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
index 5084b03..6a4d19e 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
@@ -32,6 +32,8 @@
/dts-v1/;
+#define NUM_SATA 8
+
#include "bcm958742-base.dtsi"
/ {
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
index 8c68e0c..7f6d176 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
@@ -43,7 +43,11 @@
interrupts = <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 0)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata0_port0: sata-port@0 {
reg = <0>;
@@ -58,7 +62,11 @@
reg-names = "phy";
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 0)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata0_phy0: sata-phy@0 {
reg = <0>;
@@ -73,7 +81,11 @@
interrupts = <GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 1)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata1_port0: sata-port@0 {
reg = <0>;
@@ -88,7 +100,11 @@
reg-names = "phy";
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 1)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata1_phy0: sata-phy@0 {
reg = <0>;
@@ -103,7 +119,11 @@
interrupts = <GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 2)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata2_port0: sata-port@0 {
reg = <0>;
@@ -118,7 +138,11 @@
reg-names = "phy";
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 2)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata2_phy0: sata-phy@0 {
reg = <0>;
@@ -133,7 +157,11 @@
interrupts = <GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 3)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata3_port0: sata-port@0 {
reg = <0>;
@@ -148,7 +176,11 @@
reg-names = "phy";
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 3)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata3_phy0: sata-phy@0 {
reg = <0>;
@@ -163,7 +195,11 @@
interrupts = <GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 4)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata4_port0: sata-port@0 {
reg = <0>;
@@ -178,7 +214,11 @@
reg-names = "phy";
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 4)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata4_phy0: sata-phy@0 {
reg = <0>;
@@ -193,7 +233,11 @@
interrupts = <GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 5)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata5_port0: sata-port@0 {
reg = <0>;
@@ -208,7 +252,11 @@
reg-names = "phy";
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 5)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata5_phy0: sata-phy@0 {
reg = <0>;
@@ -223,7 +271,11 @@
interrupts = <GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 6)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata6_port0: sata-port@0 {
reg = <0>;
@@ -238,7 +290,11 @@
reg-names = "phy";
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 6)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata6_phy0: sata-phy@0 {
reg = <0>;
@@ -253,7 +309,11 @@
interrupts = <GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 7)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata7_port0: sata-port@0 {
reg = <0>;
@@ -268,11 +328,19 @@
reg-names = "phy";
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 7)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata7_phy0: sata-phy@0 {
reg = <0>;
#phy-cells = <0>;
};
};
+
+#if (NUM_SATA > 8)
+#error "NUM_SATA > 8"
+#endif
};
--
2.5.0
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
@ 2018-05-18 18:34 ` Scott Branden
0 siblings, 0 replies; 24+ messages in thread
From: Scott Branden @ 2018-05-18 18:34 UTC (permalink / raw)
To: linux-arm-kernel
Move remaining sata configuration to stingray-sata.dtsi and enable
ports based on NUM_SATA defined.
Now, all that needs to be done is define NUM_SATA per board.
Signed-off-by: Scott Branden <scott.branden@broadcom.com>
---
.../boot/dts/broadcom/stingray/bcm958742-base.dtsi | 64 --------------------
.../boot/dts/broadcom/stingray/bcm958742k.dts | 2 +
.../boot/dts/broadcom/stingray/bcm958742t.dts | 2 +
.../boot/dts/broadcom/stingray/stingray-sata.dtsi | 68 ++++++++++++++++++++++
4 files changed, 72 insertions(+), 64 deletions(-)
diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
index 8862ec9..cacc25e 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
@@ -72,70 +72,6 @@
<0x00000008 0x80000000 0x1 0x80000000>; /* 6G @ 34G */
};
-&sata0 {
- status = "okay";
-};
-
-&sata_phy0{
- status = "okay";
-};
-
-&sata1 {
- status = "okay";
-};
-
-&sata_phy1{
- status = "okay";
-};
-
-&sata2 {
- status = "okay";
-};
-
-&sata_phy2{
- status = "okay";
-};
-
-&sata3 {
- status = "okay";
-};
-
-&sata_phy3{
- status = "okay";
-};
-
-&sata4 {
- status = "okay";
-};
-
-&sata_phy4{
- status = "okay";
-};
-
-&sata5 {
- status = "okay";
-};
-
-&sata_phy5{
- status = "okay";
-};
-
-&sata6 {
- status = "okay";
-};
-
-&sata_phy6{
- status = "okay";
-};
-
-&sata7 {
- status = "okay";
-};
-
-&sata_phy7{
- status = "okay";
-};
-
&mdio_mux_iproc {
mdio at 10 {
gphy0: eth-phy at 10 {
diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
index 77efa28..a515346 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
@@ -32,6 +32,8 @@
/dts-v1/;
+#define NUM_SATA 8
+
#include "bcm958742-base.dtsi"
/ {
diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts b/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
index 5084b03..6a4d19e 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
@@ -32,6 +32,8 @@
/dts-v1/;
+#define NUM_SATA 8
+
#include "bcm958742-base.dtsi"
/ {
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
index 8c68e0c..7f6d176 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
@@ -43,7 +43,11 @@
interrupts = <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 0)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata0_port0: sata-port at 0 {
reg = <0>;
@@ -58,7 +62,11 @@
reg-names = "phy";
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 0)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata0_phy0: sata-phy at 0 {
reg = <0>;
@@ -73,7 +81,11 @@
interrupts = <GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 1)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata1_port0: sata-port at 0 {
reg = <0>;
@@ -88,7 +100,11 @@
reg-names = "phy";
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 1)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata1_phy0: sata-phy at 0 {
reg = <0>;
@@ -103,7 +119,11 @@
interrupts = <GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 2)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata2_port0: sata-port at 0 {
reg = <0>;
@@ -118,7 +138,11 @@
reg-names = "phy";
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 2)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata2_phy0: sata-phy at 0 {
reg = <0>;
@@ -133,7 +157,11 @@
interrupts = <GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 3)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata3_port0: sata-port at 0 {
reg = <0>;
@@ -148,7 +176,11 @@
reg-names = "phy";
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 3)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata3_phy0: sata-phy at 0 {
reg = <0>;
@@ -163,7 +195,11 @@
interrupts = <GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 4)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata4_port0: sata-port at 0 {
reg = <0>;
@@ -178,7 +214,11 @@
reg-names = "phy";
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 4)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata4_phy0: sata-phy at 0 {
reg = <0>;
@@ -193,7 +233,11 @@
interrupts = <GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 5)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata5_port0: sata-port at 0 {
reg = <0>;
@@ -208,7 +252,11 @@
reg-names = "phy";
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 5)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata5_phy0: sata-phy at 0 {
reg = <0>;
@@ -223,7 +271,11 @@
interrupts = <GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 6)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata6_port0: sata-port at 0 {
reg = <0>;
@@ -238,7 +290,11 @@
reg-names = "phy";
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 6)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata6_phy0: sata-phy at 0 {
reg = <0>;
@@ -253,7 +309,11 @@
interrupts = <GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 7)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata7_port0: sata-port at 0 {
reg = <0>;
@@ -268,11 +328,19 @@
reg-names = "phy";
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 7)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata7_phy0: sata-phy at 0 {
reg = <0>;
#phy-cells = <0>;
};
};
+
+#if (NUM_SATA > 8)
+#error "NUM_SATA > 8"
+#endif
};
--
2.5.0
^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
2018-05-18 18:34 ` Scott Branden
@ 2018-06-04 16:22 ` Florian Fainelli
-1 siblings, 0 replies; 24+ messages in thread
From: Florian Fainelli @ 2018-06-04 16:22 UTC (permalink / raw)
To: Scott Branden, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Ray Jui
Cc: BCM Kernel Feedback, devicetree, linux-arm-kernel, linux-kernel
On 05/18/2018 11:34 AM, Scott Branden wrote:
> Move remaining sata configuration to stingray-sata.dtsi and enable
> ports based on NUM_SATA defined.
> Now, all that needs to be done is define NUM_SATA per board.
Rob could you review this and let us know if this approach is okay or
not? Thank you!
>
> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
> ---
> .../boot/dts/broadcom/stingray/bcm958742-base.dtsi | 64 --------------------
> .../boot/dts/broadcom/stingray/bcm958742k.dts | 2 +
> .../boot/dts/broadcom/stingray/bcm958742t.dts | 2 +
> .../boot/dts/broadcom/stingray/stingray-sata.dtsi | 68 ++++++++++++++++++++++
> 4 files changed, 72 insertions(+), 64 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
> index 8862ec9..cacc25e 100644
> --- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
> +++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
> @@ -72,70 +72,6 @@
> <0x00000008 0x80000000 0x1 0x80000000>; /* 6G @ 34G */
> };
>
> -&sata0 {
> - status = "okay";
> -};
> -
> -&sata_phy0{
> - status = "okay";
> -};
> -
> -&sata1 {
> - status = "okay";
> -};
> -
> -&sata_phy1{
> - status = "okay";
> -};
> -
> -&sata2 {
> - status = "okay";
> -};
> -
> -&sata_phy2{
> - status = "okay";
> -};
> -
> -&sata3 {
> - status = "okay";
> -};
> -
> -&sata_phy3{
> - status = "okay";
> -};
> -
> -&sata4 {
> - status = "okay";
> -};
> -
> -&sata_phy4{
> - status = "okay";
> -};
> -
> -&sata5 {
> - status = "okay";
> -};
> -
> -&sata_phy5{
> - status = "okay";
> -};
> -
> -&sata6 {
> - status = "okay";
> -};
> -
> -&sata_phy6{
> - status = "okay";
> -};
> -
> -&sata7 {
> - status = "okay";
> -};
> -
> -&sata_phy7{
> - status = "okay";
> -};
> -
> &mdio_mux_iproc {
> mdio@10 {
> gphy0: eth-phy@10 {
> diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
> index 77efa28..a515346 100644
> --- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
> +++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
> @@ -32,6 +32,8 @@
>
> /dts-v1/;
>
> +#define NUM_SATA 8
> +
> #include "bcm958742-base.dtsi"
>
> / {
> diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts b/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
> index 5084b03..6a4d19e 100644
> --- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
> +++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
> @@ -32,6 +32,8 @@
>
> /dts-v1/;
>
> +#define NUM_SATA 8
> +
> #include "bcm958742-base.dtsi"
>
> / {
> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
> index 8c68e0c..7f6d176 100644
> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
> @@ -43,7 +43,11 @@
> interrupts = <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 0)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata0_port0: sata-port@0 {
> reg = <0>;
> @@ -58,7 +62,11 @@
> reg-names = "phy";
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 0)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata0_phy0: sata-phy@0 {
> reg = <0>;
> @@ -73,7 +81,11 @@
> interrupts = <GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 1)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata1_port0: sata-port@0 {
> reg = <0>;
> @@ -88,7 +100,11 @@
> reg-names = "phy";
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 1)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata1_phy0: sata-phy@0 {
> reg = <0>;
> @@ -103,7 +119,11 @@
> interrupts = <GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 2)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata2_port0: sata-port@0 {
> reg = <0>;
> @@ -118,7 +138,11 @@
> reg-names = "phy";
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 2)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata2_phy0: sata-phy@0 {
> reg = <0>;
> @@ -133,7 +157,11 @@
> interrupts = <GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 3)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata3_port0: sata-port@0 {
> reg = <0>;
> @@ -148,7 +176,11 @@
> reg-names = "phy";
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 3)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata3_phy0: sata-phy@0 {
> reg = <0>;
> @@ -163,7 +195,11 @@
> interrupts = <GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 4)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata4_port0: sata-port@0 {
> reg = <0>;
> @@ -178,7 +214,11 @@
> reg-names = "phy";
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 4)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata4_phy0: sata-phy@0 {
> reg = <0>;
> @@ -193,7 +233,11 @@
> interrupts = <GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 5)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata5_port0: sata-port@0 {
> reg = <0>;
> @@ -208,7 +252,11 @@
> reg-names = "phy";
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 5)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata5_phy0: sata-phy@0 {
> reg = <0>;
> @@ -223,7 +271,11 @@
> interrupts = <GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 6)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata6_port0: sata-port@0 {
> reg = <0>;
> @@ -238,7 +290,11 @@
> reg-names = "phy";
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 6)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata6_phy0: sata-phy@0 {
> reg = <0>;
> @@ -253,7 +309,11 @@
> interrupts = <GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 7)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata7_port0: sata-port@0 {
> reg = <0>;
> @@ -268,11 +328,19 @@
> reg-names = "phy";
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 7)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata7_phy0: sata-phy@0 {
> reg = <0>;
> #phy-cells = <0>;
> };
> };
> +
> +#if (NUM_SATA > 8)
> +#error "NUM_SATA > 8"
> +#endif
> };
>
--
Florian
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
@ 2018-06-04 16:22 ` Florian Fainelli
0 siblings, 0 replies; 24+ messages in thread
From: Florian Fainelli @ 2018-06-04 16:22 UTC (permalink / raw)
To: linux-arm-kernel
On 05/18/2018 11:34 AM, Scott Branden wrote:
> Move remaining sata configuration to stingray-sata.dtsi and enable
> ports based on NUM_SATA defined.
> Now, all that needs to be done is define NUM_SATA per board.
Rob could you review this and let us know if this approach is okay or
not? Thank you!
>
> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
> ---
> .../boot/dts/broadcom/stingray/bcm958742-base.dtsi | 64 --------------------
> .../boot/dts/broadcom/stingray/bcm958742k.dts | 2 +
> .../boot/dts/broadcom/stingray/bcm958742t.dts | 2 +
> .../boot/dts/broadcom/stingray/stingray-sata.dtsi | 68 ++++++++++++++++++++++
> 4 files changed, 72 insertions(+), 64 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
> index 8862ec9..cacc25e 100644
> --- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
> +++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
> @@ -72,70 +72,6 @@
> <0x00000008 0x80000000 0x1 0x80000000>; /* 6G @ 34G */
> };
>
> -&sata0 {
> - status = "okay";
> -};
> -
> -&sata_phy0{
> - status = "okay";
> -};
> -
> -&sata1 {
> - status = "okay";
> -};
> -
> -&sata_phy1{
> - status = "okay";
> -};
> -
> -&sata2 {
> - status = "okay";
> -};
> -
> -&sata_phy2{
> - status = "okay";
> -};
> -
> -&sata3 {
> - status = "okay";
> -};
> -
> -&sata_phy3{
> - status = "okay";
> -};
> -
> -&sata4 {
> - status = "okay";
> -};
> -
> -&sata_phy4{
> - status = "okay";
> -};
> -
> -&sata5 {
> - status = "okay";
> -};
> -
> -&sata_phy5{
> - status = "okay";
> -};
> -
> -&sata6 {
> - status = "okay";
> -};
> -
> -&sata_phy6{
> - status = "okay";
> -};
> -
> -&sata7 {
> - status = "okay";
> -};
> -
> -&sata_phy7{
> - status = "okay";
> -};
> -
> &mdio_mux_iproc {
> mdio at 10 {
> gphy0: eth-phy at 10 {
> diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
> index 77efa28..a515346 100644
> --- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
> +++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
> @@ -32,6 +32,8 @@
>
> /dts-v1/;
>
> +#define NUM_SATA 8
> +
> #include "bcm958742-base.dtsi"
>
> / {
> diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts b/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
> index 5084b03..6a4d19e 100644
> --- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
> +++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
> @@ -32,6 +32,8 @@
>
> /dts-v1/;
>
> +#define NUM_SATA 8
> +
> #include "bcm958742-base.dtsi"
>
> / {
> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
> index 8c68e0c..7f6d176 100644
> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
> @@ -43,7 +43,11 @@
> interrupts = <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 0)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata0_port0: sata-port at 0 {
> reg = <0>;
> @@ -58,7 +62,11 @@
> reg-names = "phy";
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 0)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata0_phy0: sata-phy at 0 {
> reg = <0>;
> @@ -73,7 +81,11 @@
> interrupts = <GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 1)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata1_port0: sata-port at 0 {
> reg = <0>;
> @@ -88,7 +100,11 @@
> reg-names = "phy";
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 1)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata1_phy0: sata-phy at 0 {
> reg = <0>;
> @@ -103,7 +119,11 @@
> interrupts = <GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 2)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata2_port0: sata-port at 0 {
> reg = <0>;
> @@ -118,7 +138,11 @@
> reg-names = "phy";
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 2)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata2_phy0: sata-phy at 0 {
> reg = <0>;
> @@ -133,7 +157,11 @@
> interrupts = <GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 3)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata3_port0: sata-port at 0 {
> reg = <0>;
> @@ -148,7 +176,11 @@
> reg-names = "phy";
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 3)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata3_phy0: sata-phy at 0 {
> reg = <0>;
> @@ -163,7 +195,11 @@
> interrupts = <GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 4)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata4_port0: sata-port at 0 {
> reg = <0>;
> @@ -178,7 +214,11 @@
> reg-names = "phy";
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 4)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata4_phy0: sata-phy at 0 {
> reg = <0>;
> @@ -193,7 +233,11 @@
> interrupts = <GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 5)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata5_port0: sata-port at 0 {
> reg = <0>;
> @@ -208,7 +252,11 @@
> reg-names = "phy";
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 5)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata5_phy0: sata-phy at 0 {
> reg = <0>;
> @@ -223,7 +271,11 @@
> interrupts = <GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 6)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata6_port0: sata-port at 0 {
> reg = <0>;
> @@ -238,7 +290,11 @@
> reg-names = "phy";
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 6)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata6_phy0: sata-phy at 0 {
> reg = <0>;
> @@ -253,7 +309,11 @@
> interrupts = <GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 7)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata7_port0: sata-port at 0 {
> reg = <0>;
> @@ -268,11 +328,19 @@
> reg-names = "phy";
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 7)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata7_phy0: sata-phy at 0 {
> reg = <0>;
> #phy-cells = <0>;
> };
> };
> +
> +#if (NUM_SATA > 8)
> +#error "NUM_SATA > 8"
> +#endif
> };
>
--
Florian
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
2018-06-04 16:22 ` Florian Fainelli
@ 2018-06-07 18:53 ` Scott Branden
-1 siblings, 0 replies; 24+ messages in thread
From: Scott Branden @ 2018-06-07 18:53 UTC (permalink / raw)
To: Florian Fainelli, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Ray Jui
Cc: BCM Kernel Feedback, devicetree, linux-arm-kernel, linux-kernel
Hi Rob,
Could you please kindly comment on change below.
It allows board variants to be added easily via a simple define for
different number of SATA ports.
On 18-06-04 09:22 AM, Florian Fainelli wrote:
> On 05/18/2018 11:34 AM, Scott Branden wrote:
>> Move remaining sata configuration to stingray-sata.dtsi and enable
>> ports based on NUM_SATA defined.
>> Now, all that needs to be done is define NUM_SATA per board.
> Rob could you review this and let us know if this approach is okay or
> not? Thank you!
>
>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>> ---
>> .../boot/dts/broadcom/stingray/bcm958742-base.dtsi | 64 --------------------
>> .../boot/dts/broadcom/stingray/bcm958742k.dts | 2 +
>> .../boot/dts/broadcom/stingray/bcm958742t.dts | 2 +
>> .../boot/dts/broadcom/stingray/stingray-sata.dtsi | 68 ++++++++++++++++++++++
>> 4 files changed, 72 insertions(+), 64 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
>> index 8862ec9..cacc25e 100644
>> --- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
>> +++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
>> @@ -72,70 +72,6 @@
>> <0x00000008 0x80000000 0x1 0x80000000>; /* 6G @ 34G */
>> };
>>
>> -&sata0 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy0{
>> - status = "okay";
>> -};
>> -
>> -&sata1 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy1{
>> - status = "okay";
>> -};
>> -
>> -&sata2 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy2{
>> - status = "okay";
>> -};
>> -
>> -&sata3 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy3{
>> - status = "okay";
>> -};
>> -
>> -&sata4 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy4{
>> - status = "okay";
>> -};
>> -
>> -&sata5 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy5{
>> - status = "okay";
>> -};
>> -
>> -&sata6 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy6{
>> - status = "okay";
>> -};
>> -
>> -&sata7 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy7{
>> - status = "okay";
>> -};
>> -
>> &mdio_mux_iproc {
>> mdio@10 {
>> gphy0: eth-phy@10 {
>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
>> index 77efa28..a515346 100644
>> --- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
>> +++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
>> @@ -32,6 +32,8 @@
>>
>> /dts-v1/;
>>
>> +#define NUM_SATA 8
>> +
>> #include "bcm958742-base.dtsi"
>>
>> / {
>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts b/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
>> index 5084b03..6a4d19e 100644
>> --- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
>> +++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
>> @@ -32,6 +32,8 @@
>>
>> /dts-v1/;
>>
>> +#define NUM_SATA 8
>> +
>> #include "bcm958742-base.dtsi"
>>
>> / {
>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>> index 8c68e0c..7f6d176 100644
>> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>> @@ -43,7 +43,11 @@
>> interrupts = <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 0)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata0_port0: sata-port@0 {
>> reg = <0>;
>> @@ -58,7 +62,11 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 0)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata0_phy0: sata-phy@0 {
>> reg = <0>;
>> @@ -73,7 +81,11 @@
>> interrupts = <GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 1)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata1_port0: sata-port@0 {
>> reg = <0>;
>> @@ -88,7 +100,11 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 1)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata1_phy0: sata-phy@0 {
>> reg = <0>;
>> @@ -103,7 +119,11 @@
>> interrupts = <GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 2)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata2_port0: sata-port@0 {
>> reg = <0>;
>> @@ -118,7 +138,11 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 2)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata2_phy0: sata-phy@0 {
>> reg = <0>;
>> @@ -133,7 +157,11 @@
>> interrupts = <GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 3)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata3_port0: sata-port@0 {
>> reg = <0>;
>> @@ -148,7 +176,11 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 3)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata3_phy0: sata-phy@0 {
>> reg = <0>;
>> @@ -163,7 +195,11 @@
>> interrupts = <GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 4)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata4_port0: sata-port@0 {
>> reg = <0>;
>> @@ -178,7 +214,11 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 4)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata4_phy0: sata-phy@0 {
>> reg = <0>;
>> @@ -193,7 +233,11 @@
>> interrupts = <GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 5)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata5_port0: sata-port@0 {
>> reg = <0>;
>> @@ -208,7 +252,11 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 5)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata5_phy0: sata-phy@0 {
>> reg = <0>;
>> @@ -223,7 +271,11 @@
>> interrupts = <GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 6)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata6_port0: sata-port@0 {
>> reg = <0>;
>> @@ -238,7 +290,11 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 6)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata6_phy0: sata-phy@0 {
>> reg = <0>;
>> @@ -253,7 +309,11 @@
>> interrupts = <GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 7)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata7_port0: sata-port@0 {
>> reg = <0>;
>> @@ -268,11 +328,19 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 7)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata7_phy0: sata-phy@0 {
>> reg = <0>;
>> #phy-cells = <0>;
>> };
>> };
>> +
>> +#if (NUM_SATA > 8)
>> +#error "NUM_SATA > 8"
>> +#endif
>> };
>>
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
@ 2018-06-07 18:53 ` Scott Branden
0 siblings, 0 replies; 24+ messages in thread
From: Scott Branden @ 2018-06-07 18:53 UTC (permalink / raw)
To: linux-arm-kernel
Hi Rob,
Could you please kindly comment on change below.
It allows board variants to be added easily via a simple define for
different number of SATA ports.
On 18-06-04 09:22 AM, Florian Fainelli wrote:
> On 05/18/2018 11:34 AM, Scott Branden wrote:
>> Move remaining sata configuration to stingray-sata.dtsi and enable
>> ports based on NUM_SATA defined.
>> Now, all that needs to be done is define NUM_SATA per board.
> Rob could you review this and let us know if this approach is okay or
> not? Thank you!
>
>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>> ---
>> .../boot/dts/broadcom/stingray/bcm958742-base.dtsi | 64 --------------------
>> .../boot/dts/broadcom/stingray/bcm958742k.dts | 2 +
>> .../boot/dts/broadcom/stingray/bcm958742t.dts | 2 +
>> .../boot/dts/broadcom/stingray/stingray-sata.dtsi | 68 ++++++++++++++++++++++
>> 4 files changed, 72 insertions(+), 64 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
>> index 8862ec9..cacc25e 100644
>> --- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
>> +++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
>> @@ -72,70 +72,6 @@
>> <0x00000008 0x80000000 0x1 0x80000000>; /* 6G @ 34G */
>> };
>>
>> -&sata0 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy0{
>> - status = "okay";
>> -};
>> -
>> -&sata1 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy1{
>> - status = "okay";
>> -};
>> -
>> -&sata2 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy2{
>> - status = "okay";
>> -};
>> -
>> -&sata3 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy3{
>> - status = "okay";
>> -};
>> -
>> -&sata4 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy4{
>> - status = "okay";
>> -};
>> -
>> -&sata5 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy5{
>> - status = "okay";
>> -};
>> -
>> -&sata6 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy6{
>> - status = "okay";
>> -};
>> -
>> -&sata7 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy7{
>> - status = "okay";
>> -};
>> -
>> &mdio_mux_iproc {
>> mdio at 10 {
>> gphy0: eth-phy at 10 {
>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
>> index 77efa28..a515346 100644
>> --- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
>> +++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
>> @@ -32,6 +32,8 @@
>>
>> /dts-v1/;
>>
>> +#define NUM_SATA 8
>> +
>> #include "bcm958742-base.dtsi"
>>
>> / {
>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts b/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
>> index 5084b03..6a4d19e 100644
>> --- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
>> +++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
>> @@ -32,6 +32,8 @@
>>
>> /dts-v1/;
>>
>> +#define NUM_SATA 8
>> +
>> #include "bcm958742-base.dtsi"
>>
>> / {
>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>> index 8c68e0c..7f6d176 100644
>> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>> @@ -43,7 +43,11 @@
>> interrupts = <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 0)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata0_port0: sata-port at 0 {
>> reg = <0>;
>> @@ -58,7 +62,11 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 0)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata0_phy0: sata-phy at 0 {
>> reg = <0>;
>> @@ -73,7 +81,11 @@
>> interrupts = <GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 1)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata1_port0: sata-port at 0 {
>> reg = <0>;
>> @@ -88,7 +100,11 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 1)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata1_phy0: sata-phy at 0 {
>> reg = <0>;
>> @@ -103,7 +119,11 @@
>> interrupts = <GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 2)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata2_port0: sata-port at 0 {
>> reg = <0>;
>> @@ -118,7 +138,11 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 2)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata2_phy0: sata-phy at 0 {
>> reg = <0>;
>> @@ -133,7 +157,11 @@
>> interrupts = <GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 3)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata3_port0: sata-port at 0 {
>> reg = <0>;
>> @@ -148,7 +176,11 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 3)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata3_phy0: sata-phy at 0 {
>> reg = <0>;
>> @@ -163,7 +195,11 @@
>> interrupts = <GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 4)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata4_port0: sata-port at 0 {
>> reg = <0>;
>> @@ -178,7 +214,11 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 4)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata4_phy0: sata-phy at 0 {
>> reg = <0>;
>> @@ -193,7 +233,11 @@
>> interrupts = <GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 5)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata5_port0: sata-port at 0 {
>> reg = <0>;
>> @@ -208,7 +252,11 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 5)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata5_phy0: sata-phy at 0 {
>> reg = <0>;
>> @@ -223,7 +271,11 @@
>> interrupts = <GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 6)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata6_port0: sata-port at 0 {
>> reg = <0>;
>> @@ -238,7 +290,11 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 6)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata6_phy0: sata-phy at 0 {
>> reg = <0>;
>> @@ -253,7 +309,11 @@
>> interrupts = <GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 7)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata7_port0: sata-port at 0 {
>> reg = <0>;
>> @@ -268,11 +328,19 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 7)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata7_phy0: sata-phy at 0 {
>> reg = <0>;
>> #phy-cells = <0>;
>> };
>> };
>> +
>> +#if (NUM_SATA > 8)
>> +#error "NUM_SATA > 8"
>> +#endif
>> };
>>
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
2018-06-07 18:53 ` Scott Branden
(?)
@ 2018-06-12 22:54 ` Rob Herring
-1 siblings, 0 replies; 24+ messages in thread
From: Rob Herring @ 2018-06-12 22:54 UTC (permalink / raw)
To: Scott Branden
Cc: Florian Fainelli, Mark Rutland, Catalin Marinas, Will Deacon,
Ray Jui, BCM Kernel Feedback, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-kernel
On Thu, Jun 7, 2018 at 12:53 PM, Scott Branden
<scott.branden@broadcom.com> wrote:
> Hi Rob,
>
> Could you please kindly comment on change below.
>
> It allows board variants to be added easily via a simple define for
> different number of SATA ports.
>
>
>
> On 18-06-04 09:22 AM, Florian Fainelli wrote:
>>
>> On 05/18/2018 11:34 AM, Scott Branden wrote:
>>>
>>> Move remaining sata configuration to stingray-sata.dtsi and enable
>>> ports based on NUM_SATA defined.
>>> Now, all that needs to be done is define NUM_SATA per board.
>>
>> Rob could you review this and let us know if this approach is okay or
>> not? Thank you!
>>
>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>> ---
>>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>> b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>> index 8c68e0c..7f6d176 100644
>>> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>> @@ -43,7 +43,11 @@
>>> interrupts = <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>;
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>> +#if (NUM_SATA > 0)
>>> + status = "okay";
>>> +#else
>>> status = "disabled";
>>> +#endif
This only works if ports are contiguously enabled (0-N). You might not
care, but it is not a pattern that works in general. And I'm not a fan
of C preprocessing in DT files in general beyond just defines for
single numbers.
Rob
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
@ 2018-06-12 22:54 ` Rob Herring
0 siblings, 0 replies; 24+ messages in thread
From: Rob Herring @ 2018-06-12 22:54 UTC (permalink / raw)
To: Scott Branden
Cc: Florian Fainelli, Mark Rutland, Catalin Marinas, Will Deacon,
Ray Jui, BCM Kernel Feedback, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-kernel
On Thu, Jun 7, 2018 at 12:53 PM, Scott Branden
<scott.branden@broadcom.com> wrote:
> Hi Rob,
>
> Could you please kindly comment on change below.
>
> It allows board variants to be added easily via a simple define for
> different number of SATA ports.
>
>
>
> On 18-06-04 09:22 AM, Florian Fainelli wrote:
>>
>> On 05/18/2018 11:34 AM, Scott Branden wrote:
>>>
>>> Move remaining sata configuration to stingray-sata.dtsi and enable
>>> ports based on NUM_SATA defined.
>>> Now, all that needs to be done is define NUM_SATA per board.
>>
>> Rob could you review this and let us know if this approach is okay or
>> not? Thank you!
>>
>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>> ---
>>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>> b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>> index 8c68e0c..7f6d176 100644
>>> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>> @@ -43,7 +43,11 @@
>>> interrupts = <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>;
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>> +#if (NUM_SATA > 0)
>>> + status = "okay";
>>> +#else
>>> status = "disabled";
>>> +#endif
This only works if ports are contiguously enabled (0-N). You might not
care, but it is not a pattern that works in general. And I'm not a fan
of C preprocessing in DT files in general beyond just defines for
single numbers.
Rob
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
@ 2018-06-12 22:54 ` Rob Herring
0 siblings, 0 replies; 24+ messages in thread
From: Rob Herring @ 2018-06-12 22:54 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jun 7, 2018 at 12:53 PM, Scott Branden
<scott.branden@broadcom.com> wrote:
> Hi Rob,
>
> Could you please kindly comment on change below.
>
> It allows board variants to be added easily via a simple define for
> different number of SATA ports.
>
>
>
> On 18-06-04 09:22 AM, Florian Fainelli wrote:
>>
>> On 05/18/2018 11:34 AM, Scott Branden wrote:
>>>
>>> Move remaining sata configuration to stingray-sata.dtsi and enable
>>> ports based on NUM_SATA defined.
>>> Now, all that needs to be done is define NUM_SATA per board.
>>
>> Rob could you review this and let us know if this approach is okay or
>> not? Thank you!
>>
>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>> ---
>>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>> b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>> index 8c68e0c..7f6d176 100644
>>> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>> @@ -43,7 +43,11 @@
>>> interrupts = <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>;
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>> +#if (NUM_SATA > 0)
>>> + status = "okay";
>>> +#else
>>> status = "disabled";
>>> +#endif
This only works if ports are contiguously enabled (0-N). You might not
care, but it is not a pattern that works in general. And I'm not a fan
of C preprocessing in DT files in general beyond just defines for
single numbers.
Rob
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
2018-06-12 22:54 ` Rob Herring
(?)
@ 2018-06-13 19:31 ` Florian Fainelli
-1 siblings, 0 replies; 24+ messages in thread
From: Florian Fainelli @ 2018-06-13 19:31 UTC (permalink / raw)
To: Rob Herring, Scott Branden
Cc: Florian Fainelli, Mark Rutland, Catalin Marinas, Will Deacon,
Ray Jui, BCM Kernel Feedback, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-kernel
On 06/12/2018 03:54 PM, Rob Herring wrote:
> On Thu, Jun 7, 2018 at 12:53 PM, Scott Branden
> <scott.branden@broadcom.com> wrote:
>> Hi Rob,
>>
>> Could you please kindly comment on change below.
>>
>> It allows board variants to be added easily via a simple define for
>> different number of SATA ports.
>>
>>
>>
>> On 18-06-04 09:22 AM, Florian Fainelli wrote:
>>>
>>> On 05/18/2018 11:34 AM, Scott Branden wrote:
>>>>
>>>> Move remaining sata configuration to stingray-sata.dtsi and enable
>>>> ports based on NUM_SATA defined.
>>>> Now, all that needs to be done is define NUM_SATA per board.
>>>
>>> Rob could you review this and let us know if this approach is okay or
>>> not? Thank you!
>>>
>>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>>> ---
>
>>>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>> b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>> index 8c68e0c..7f6d176 100644
>>>> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>> @@ -43,7 +43,11 @@
>>>> interrupts = <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>;
>>>> #address-cells = <1>;
>>>> #size-cells = <0>;
>>>> +#if (NUM_SATA > 0)
>>>> + status = "okay";
>>>> +#else
>>>> status = "disabled";
>>>> +#endif
>
> This only works if ports are contiguously enabled (0-N). You might not
> care, but it is not a pattern that works in general. And I'm not a fan
> of C preprocessing in DT files in general beyond just defines for
> single numbers.
Should we interpret this as a formal NAK?
--
Florian
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
@ 2018-06-13 19:31 ` Florian Fainelli
0 siblings, 0 replies; 24+ messages in thread
From: Florian Fainelli @ 2018-06-13 19:31 UTC (permalink / raw)
To: Rob Herring, Scott Branden
Cc: Florian Fainelli, Mark Rutland, Catalin Marinas, Will Deacon,
Ray Jui, BCM Kernel Feedback, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-kernel
On 06/12/2018 03:54 PM, Rob Herring wrote:
> On Thu, Jun 7, 2018 at 12:53 PM, Scott Branden
> <scott.branden@broadcom.com> wrote:
>> Hi Rob,
>>
>> Could you please kindly comment on change below.
>>
>> It allows board variants to be added easily via a simple define for
>> different number of SATA ports.
>>
>>
>>
>> On 18-06-04 09:22 AM, Florian Fainelli wrote:
>>>
>>> On 05/18/2018 11:34 AM, Scott Branden wrote:
>>>>
>>>> Move remaining sata configuration to stingray-sata.dtsi and enable
>>>> ports based on NUM_SATA defined.
>>>> Now, all that needs to be done is define NUM_SATA per board.
>>>
>>> Rob could you review this and let us know if this approach is okay or
>>> not? Thank you!
>>>
>>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>>> ---
>
>>>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>> b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>> index 8c68e0c..7f6d176 100644
>>>> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>> @@ -43,7 +43,11 @@
>>>> interrupts = <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>;
>>>> #address-cells = <1>;
>>>> #size-cells = <0>;
>>>> +#if (NUM_SATA > 0)
>>>> + status = "okay";
>>>> +#else
>>>> status = "disabled";
>>>> +#endif
>
> This only works if ports are contiguously enabled (0-N). You might not
> care, but it is not a pattern that works in general. And I'm not a fan
> of C preprocessing in DT files in general beyond just defines for
> single numbers.
Should we interpret this as a formal NAK?
--
Florian
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
@ 2018-06-13 19:31 ` Florian Fainelli
0 siblings, 0 replies; 24+ messages in thread
From: Florian Fainelli @ 2018-06-13 19:31 UTC (permalink / raw)
To: linux-arm-kernel
On 06/12/2018 03:54 PM, Rob Herring wrote:
> On Thu, Jun 7, 2018 at 12:53 PM, Scott Branden
> <scott.branden@broadcom.com> wrote:
>> Hi Rob,
>>
>> Could you please kindly comment on change below.
>>
>> It allows board variants to be added easily via a simple define for
>> different number of SATA ports.
>>
>>
>>
>> On 18-06-04 09:22 AM, Florian Fainelli wrote:
>>>
>>> On 05/18/2018 11:34 AM, Scott Branden wrote:
>>>>
>>>> Move remaining sata configuration to stingray-sata.dtsi and enable
>>>> ports based on NUM_SATA defined.
>>>> Now, all that needs to be done is define NUM_SATA per board.
>>>
>>> Rob could you review this and let us know if this approach is okay or
>>> not? Thank you!
>>>
>>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>>> ---
>
>>>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>> b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>> index 8c68e0c..7f6d176 100644
>>>> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>> @@ -43,7 +43,11 @@
>>>> interrupts = <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>;
>>>> #address-cells = <1>;
>>>> #size-cells = <0>;
>>>> +#if (NUM_SATA > 0)
>>>> + status = "okay";
>>>> +#else
>>>> status = "disabled";
>>>> +#endif
>
> This only works if ports are contiguously enabled (0-N). You might not
> care, but it is not a pattern that works in general. And I'm not a fan
> of C preprocessing in DT files in general beyond just defines for
> single numbers.
Should we interpret this as a formal NAK?
--
Florian
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
2018-06-13 19:31 ` Florian Fainelli
(?)
@ 2018-06-13 20:18 ` Scott Branden
-1 siblings, 0 replies; 24+ messages in thread
From: Scott Branden @ 2018-06-13 20:18 UTC (permalink / raw)
To: Florian Fainelli, Rob Herring
Cc: Mark Rutland, Catalin Marinas, Will Deacon, Ray Jui,
BCM Kernel Feedback, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-kernel
Hi Rob,
Thanks for comment - reply inline.
On 18-06-13 12:31 PM, Florian Fainelli wrote:
> On 06/12/2018 03:54 PM, Rob Herring wrote:
>> On Thu, Jun 7, 2018 at 12:53 PM, Scott Branden
>> <scott.branden@broadcom.com> wrote:
>>> Hi Rob,
>>>
>>> Could you please kindly comment on change below.
>>>
>>> It allows board variants to be added easily via a simple define for
>>> different number of SATA ports.
>>>
>>>
>>>
>>> On 18-06-04 09:22 AM, Florian Fainelli wrote:
>>>> On 05/18/2018 11:34 AM, Scott Branden wrote:
>>>>> Move remaining sata configuration to stingray-sata.dtsi and enable
>>>>> ports based on NUM_SATA defined.
>>>>> Now, all that needs to be done is define NUM_SATA per board.
>>>> Rob could you review this and let us know if this approach is okay or
>>>> not? Thank you!
>>>>
>>>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>>>> ---
>>>>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>> b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>> index 8c68e0c..7f6d176 100644
>>>>> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>> @@ -43,7 +43,11 @@
>>>>> interrupts = <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>;
>>>>> #address-cells = <1>;
>>>>> #size-cells = <0>;
>>>>> +#if (NUM_SATA > 0)
>>>>> + status = "okay";
>>>>> +#else
>>>>> status = "disabled";
>>>>> +#endif
>> This only works if ports are contiguously enabled (0-N). You might not
>> care, but it is not a pattern that works in general.
Correct - all board designs that include this dtsi file follow such
commonality (ie. design with SATA0 first, etc). By having common board
designs it allows for commonality in dts files rather than duplicating
information everywhere. If somebody designs a bizarro board they are
free to create their own dts file of course.
>> And I'm not a fan
>> of C preprocessing in DT files in general beyond just defines for
>> single numbers.
The use of a define to specify the number of SATA ports in the board
design meets our requirements of being able to maintain many boards. We
need a method to specify the number of ports in the board design rather
than copying and pasting the information in many dts files. If you have
an alternative upstreamable mechanism to manage the configuration of
many boards without copy and paste that would be ideal?
> Should we interpret this as a formal NAK?
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
@ 2018-06-13 20:18 ` Scott Branden
0 siblings, 0 replies; 24+ messages in thread
From: Scott Branden @ 2018-06-13 20:18 UTC (permalink / raw)
To: Florian Fainelli, Rob Herring
Cc: Mark Rutland, Catalin Marinas, Will Deacon, Ray Jui,
BCM Kernel Feedback, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-kernel
Hi Rob,
Thanks for comment - reply inline.
On 18-06-13 12:31 PM, Florian Fainelli wrote:
> On 06/12/2018 03:54 PM, Rob Herring wrote:
>> On Thu, Jun 7, 2018 at 12:53 PM, Scott Branden
>> <scott.branden@broadcom.com> wrote:
>>> Hi Rob,
>>>
>>> Could you please kindly comment on change below.
>>>
>>> It allows board variants to be added easily via a simple define for
>>> different number of SATA ports.
>>>
>>>
>>>
>>> On 18-06-04 09:22 AM, Florian Fainelli wrote:
>>>> On 05/18/2018 11:34 AM, Scott Branden wrote:
>>>>> Move remaining sata configuration to stingray-sata.dtsi and enable
>>>>> ports based on NUM_SATA defined.
>>>>> Now, all that needs to be done is define NUM_SATA per board.
>>>> Rob could you review this and let us know if this approach is okay or
>>>> not? Thank you!
>>>>
>>>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>>>> ---
>>>>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>> b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>> index 8c68e0c..7f6d176 100644
>>>>> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>> @@ -43,7 +43,11 @@
>>>>> interrupts = <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>;
>>>>> #address-cells = <1>;
>>>>> #size-cells = <0>;
>>>>> +#if (NUM_SATA > 0)
>>>>> + status = "okay";
>>>>> +#else
>>>>> status = "disabled";
>>>>> +#endif
>> This only works if ports are contiguously enabled (0-N). You might not
>> care, but it is not a pattern that works in general.
Correct - all board designs that include this dtsi file follow such
commonality (ie. design with SATA0 first, etc). By having common board
designs it allows for commonality in dts files rather than duplicating
information everywhere. If somebody designs a bizarro board they are
free to create their own dts file of course.
>> And I'm not a fan
>> of C preprocessing in DT files in general beyond just defines for
>> single numbers.
The use of a define to specify the number of SATA ports in the board
design meets our requirements of being able to maintain many boards. We
need a method to specify the number of ports in the board design rather
than copying and pasting the information in many dts files. If you have
an alternative upstreamable mechanism to manage the configuration of
many boards without copy and paste that would be ideal?
> Should we interpret this as a formal NAK?
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
@ 2018-06-13 20:18 ` Scott Branden
0 siblings, 0 replies; 24+ messages in thread
From: Scott Branden @ 2018-06-13 20:18 UTC (permalink / raw)
To: linux-arm-kernel
Hi Rob,
Thanks for comment - reply inline.
On 18-06-13 12:31 PM, Florian Fainelli wrote:
> On 06/12/2018 03:54 PM, Rob Herring wrote:
>> On Thu, Jun 7, 2018 at 12:53 PM, Scott Branden
>> <scott.branden@broadcom.com> wrote:
>>> Hi Rob,
>>>
>>> Could you please kindly comment on change below.
>>>
>>> It allows board variants to be added easily via a simple define for
>>> different number of SATA ports.
>>>
>>>
>>>
>>> On 18-06-04 09:22 AM, Florian Fainelli wrote:
>>>> On 05/18/2018 11:34 AM, Scott Branden wrote:
>>>>> Move remaining sata configuration to stingray-sata.dtsi and enable
>>>>> ports based on NUM_SATA defined.
>>>>> Now, all that needs to be done is define NUM_SATA per board.
>>>> Rob could you review this and let us know if this approach is okay or
>>>> not? Thank you!
>>>>
>>>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>>>> ---
>>>>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>> b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>> index 8c68e0c..7f6d176 100644
>>>>> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>> @@ -43,7 +43,11 @@
>>>>> interrupts = <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>;
>>>>> #address-cells = <1>;
>>>>> #size-cells = <0>;
>>>>> +#if (NUM_SATA > 0)
>>>>> + status = "okay";
>>>>> +#else
>>>>> status = "disabled";
>>>>> +#endif
>> This only works if ports are contiguously enabled (0-N). You might not
>> care, but it is not a pattern that works in general.
Correct - all board designs that include this dtsi file follow such
commonality (ie. design with SATA0 first, etc).? By having common board
designs it allows for commonality in dts files rather than duplicating
information everywhere.? If somebody designs a bizarro board they are
free to create their own dts file of course.
>> And I'm not a fan
>> of C preprocessing in DT files in general beyond just defines for
>> single numbers.
The use of a define to specify the number of SATA ports in the board
design meets our requirements of being able to maintain many boards.? We
need a method to specify the number of ports in the board design rather
than copying and pasting the information in many dts files.? If you have
an alternative upstreamable mechanism to manage the configuration of
many boards without copy and paste that would be ideal?
> Should we interpret this as a formal NAK?
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
2018-06-13 20:18 ` Scott Branden
(?)
@ 2018-06-13 22:06 ` Rob Herring
-1 siblings, 0 replies; 24+ messages in thread
From: Rob Herring @ 2018-06-13 22:06 UTC (permalink / raw)
To: Scott Branden
Cc: Florian Fainelli, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Ray Jui, BCM Kernel Feedback, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-kernel
On Wed, Jun 13, 2018 at 2:18 PM, Scott Branden
<scott.branden@broadcom.com> wrote:
> Hi Rob,
>
> Thanks for comment - reply inline.
>
>
>
> On 18-06-13 12:31 PM, Florian Fainelli wrote:
>>
>> On 06/12/2018 03:54 PM, Rob Herring wrote:
>>>
>>> On Thu, Jun 7, 2018 at 12:53 PM, Scott Branden
>>> <scott.branden@broadcom.com> wrote:
>>>>
>>>> Hi Rob,
>>>>
>>>> Could you please kindly comment on change below.
>>>>
>>>> It allows board variants to be added easily via a simple define for
>>>> different number of SATA ports.
>>>>
>>>>
>>>>
>>>> On 18-06-04 09:22 AM, Florian Fainelli wrote:
>>>>>
>>>>> On 05/18/2018 11:34 AM, Scott Branden wrote:
>>>>>>
>>>>>> Move remaining sata configuration to stingray-sata.dtsi and enable
>>>>>> ports based on NUM_SATA defined.
>>>>>> Now, all that needs to be done is define NUM_SATA per board.
>>>>>
>>>>> Rob could you review this and let us know if this approach is okay or
>>>>> not? Thank you!
>>>>>
>>>>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>>>>> ---
>>>>>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> index 8c68e0c..7f6d176 100644
>>>>>> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> @@ -43,7 +43,11 @@
>>>>>> interrupts = <GIC_SPI 321
>>>>>> IRQ_TYPE_LEVEL_HIGH>;
>>>>>> #address-cells = <1>;
>>>>>> #size-cells = <0>;
>>>>>> +#if (NUM_SATA > 0)
>>>>>> + status = "okay";
>>>>>> +#else
>>>>>> status = "disabled";
>>>>>> +#endif
>>>
>>> This only works if ports are contiguously enabled (0-N). You might not
>>> care, but it is not a pattern that works in general.
>
> Correct - all board designs that include this dtsi file follow such
> commonality (ie. design with SATA0 first, etc). By having common board
> designs it allows for commonality in dts files rather than duplicating
> information everywhere. If somebody designs a bizarro board they are free
> to create their own dts file of course.
>>>
>>> And I'm not a fan
>>> of C preprocessing in DT files in general beyond just defines for
>>> single numbers.
>
> The use of a define to specify the number of SATA ports in the board design
> meets our requirements of being able to maintain many boards. We need a
> method to specify the number of ports in the board design rather than
> copying and pasting the information in many dts files. If you have an
> alternative upstreamable mechanism to manage the configuration of many
> boards without copy and paste that would be ideal?
Is this really the only problem with maintaining lots of boards? What
about all the other nodes that are conditionally enabled? Really, I
don't see the problem with 3 lines per node.
Does having an unused port enabled cause problems? If not, you could
handle it all at run-time and just shutdown ports which have no link.
You'd want to do that anyway for boards with a port, but is not
connected to a drive (except for hotplug capable ports).
Maybe we could add a property in /chosen that is a list of nodes to
enable and either the bootloader or kernel could update their
'status'. Or It could even be done in dtc perhaps with some
/directive/.
Rob
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
@ 2018-06-13 22:06 ` Rob Herring
0 siblings, 0 replies; 24+ messages in thread
From: Rob Herring @ 2018-06-13 22:06 UTC (permalink / raw)
To: Scott Branden
Cc: Florian Fainelli, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Ray Jui, BCM Kernel Feedback, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-kernel
On Wed, Jun 13, 2018 at 2:18 PM, Scott Branden
<scott.branden@broadcom.com> wrote:
> Hi Rob,
>
> Thanks for comment - reply inline.
>
>
>
> On 18-06-13 12:31 PM, Florian Fainelli wrote:
>>
>> On 06/12/2018 03:54 PM, Rob Herring wrote:
>>>
>>> On Thu, Jun 7, 2018 at 12:53 PM, Scott Branden
>>> <scott.branden@broadcom.com> wrote:
>>>>
>>>> Hi Rob,
>>>>
>>>> Could you please kindly comment on change below.
>>>>
>>>> It allows board variants to be added easily via a simple define for
>>>> different number of SATA ports.
>>>>
>>>>
>>>>
>>>> On 18-06-04 09:22 AM, Florian Fainelli wrote:
>>>>>
>>>>> On 05/18/2018 11:34 AM, Scott Branden wrote:
>>>>>>
>>>>>> Move remaining sata configuration to stingray-sata.dtsi and enable
>>>>>> ports based on NUM_SATA defined.
>>>>>> Now, all that needs to be done is define NUM_SATA per board.
>>>>>
>>>>> Rob could you review this and let us know if this approach is okay or
>>>>> not? Thank you!
>>>>>
>>>>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>>>>> ---
>>>>>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> index 8c68e0c..7f6d176 100644
>>>>>> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> @@ -43,7 +43,11 @@
>>>>>> interrupts = <GIC_SPI 321
>>>>>> IRQ_TYPE_LEVEL_HIGH>;
>>>>>> #address-cells = <1>;
>>>>>> #size-cells = <0>;
>>>>>> +#if (NUM_SATA > 0)
>>>>>> + status = "okay";
>>>>>> +#else
>>>>>> status = "disabled";
>>>>>> +#endif
>>>
>>> This only works if ports are contiguously enabled (0-N). You might not
>>> care, but it is not a pattern that works in general.
>
> Correct - all board designs that include this dtsi file follow such
> commonality (ie. design with SATA0 first, etc). By having common board
> designs it allows for commonality in dts files rather than duplicating
> information everywhere. If somebody designs a bizarro board they are free
> to create their own dts file of course.
>>>
>>> And I'm not a fan
>>> of C preprocessing in DT files in general beyond just defines for
>>> single numbers.
>
> The use of a define to specify the number of SATA ports in the board design
> meets our requirements of being able to maintain many boards. We need a
> method to specify the number of ports in the board design rather than
> copying and pasting the information in many dts files. If you have an
> alternative upstreamable mechanism to manage the configuration of many
> boards without copy and paste that would be ideal?
Is this really the only problem with maintaining lots of boards? What
about all the other nodes that are conditionally enabled? Really, I
don't see the problem with 3 lines per node.
Does having an unused port enabled cause problems? If not, you could
handle it all at run-time and just shutdown ports which have no link.
You'd want to do that anyway for boards with a port, but is not
connected to a drive (except for hotplug capable ports).
Maybe we could add a property in /chosen that is a list of nodes to
enable and either the bootloader or kernel could update their
'status'. Or It could even be done in dtc perhaps with some
/directive/.
Rob
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
@ 2018-06-13 22:06 ` Rob Herring
0 siblings, 0 replies; 24+ messages in thread
From: Rob Herring @ 2018-06-13 22:06 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Jun 13, 2018 at 2:18 PM, Scott Branden
<scott.branden@broadcom.com> wrote:
> Hi Rob,
>
> Thanks for comment - reply inline.
>
>
>
> On 18-06-13 12:31 PM, Florian Fainelli wrote:
>>
>> On 06/12/2018 03:54 PM, Rob Herring wrote:
>>>
>>> On Thu, Jun 7, 2018 at 12:53 PM, Scott Branden
>>> <scott.branden@broadcom.com> wrote:
>>>>
>>>> Hi Rob,
>>>>
>>>> Could you please kindly comment on change below.
>>>>
>>>> It allows board variants to be added easily via a simple define for
>>>> different number of SATA ports.
>>>>
>>>>
>>>>
>>>> On 18-06-04 09:22 AM, Florian Fainelli wrote:
>>>>>
>>>>> On 05/18/2018 11:34 AM, Scott Branden wrote:
>>>>>>
>>>>>> Move remaining sata configuration to stingray-sata.dtsi and enable
>>>>>> ports based on NUM_SATA defined.
>>>>>> Now, all that needs to be done is define NUM_SATA per board.
>>>>>
>>>>> Rob could you review this and let us know if this approach is okay or
>>>>> not? Thank you!
>>>>>
>>>>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>>>>> ---
>>>>>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> index 8c68e0c..7f6d176 100644
>>>>>> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> @@ -43,7 +43,11 @@
>>>>>> interrupts = <GIC_SPI 321
>>>>>> IRQ_TYPE_LEVEL_HIGH>;
>>>>>> #address-cells = <1>;
>>>>>> #size-cells = <0>;
>>>>>> +#if (NUM_SATA > 0)
>>>>>> + status = "okay";
>>>>>> +#else
>>>>>> status = "disabled";
>>>>>> +#endif
>>>
>>> This only works if ports are contiguously enabled (0-N). You might not
>>> care, but it is not a pattern that works in general.
>
> Correct - all board designs that include this dtsi file follow such
> commonality (ie. design with SATA0 first, etc). By having common board
> designs it allows for commonality in dts files rather than duplicating
> information everywhere. If somebody designs a bizarro board they are free
> to create their own dts file of course.
>>>
>>> And I'm not a fan
>>> of C preprocessing in DT files in general beyond just defines for
>>> single numbers.
>
> The use of a define to specify the number of SATA ports in the board design
> meets our requirements of being able to maintain many boards. We need a
> method to specify the number of ports in the board design rather than
> copying and pasting the information in many dts files. If you have an
> alternative upstreamable mechanism to manage the configuration of many
> boards without copy and paste that would be ideal?
Is this really the only problem with maintaining lots of boards? What
about all the other nodes that are conditionally enabled? Really, I
don't see the problem with 3 lines per node.
Does having an unused port enabled cause problems? If not, you could
handle it all at run-time and just shutdown ports which have no link.
You'd want to do that anyway for boards with a port, but is not
connected to a drive (except for hotplug capable ports).
Maybe we could add a property in /chosen that is a list of nodes to
enable and either the bootloader or kernel could update their
'status'. Or It could even be done in dtc perhaps with some
/directive/.
Rob
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
2018-06-13 20:18 ` Scott Branden
(?)
@ 2018-06-14 0:46 ` Florian Fainelli
-1 siblings, 0 replies; 24+ messages in thread
From: Florian Fainelli @ 2018-06-14 0:46 UTC (permalink / raw)
To: Scott Branden, Rob Herring
Cc: Mark Rutland, Catalin Marinas, Will Deacon, Ray Jui,
BCM Kernel Feedback, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-kernel
On 06/13/2018 01:18 PM, Scott Branden wrote:
> Hi Rob,
>
> Thanks for comment - reply inline.
>
>
> On 18-06-13 12:31 PM, Florian Fainelli wrote:
>> On 06/12/2018 03:54 PM, Rob Herring wrote:
>>> On Thu, Jun 7, 2018 at 12:53 PM, Scott Branden
>>> <scott.branden@broadcom.com> wrote:
>>>> Hi Rob,
>>>>
>>>> Could you please kindly comment on change below.
>>>>
>>>> It allows board variants to be added easily via a simple define for
>>>> different number of SATA ports.
>>>>
>>>>
>>>>
>>>> On 18-06-04 09:22 AM, Florian Fainelli wrote:
>>>>> On 05/18/2018 11:34 AM, Scott Branden wrote:
>>>>>> Move remaining sata configuration to stingray-sata.dtsi and enable
>>>>>> ports based on NUM_SATA defined.
>>>>>> Now, all that needs to be done is define NUM_SATA per board.
>>>>> Rob could you review this and let us know if this approach is okay or
>>>>> not? Thank you!
>>>>>
>>>>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>>>>> ---
>>>>>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> index 8c68e0c..7f6d176 100644
>>>>>> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> @@ -43,7 +43,11 @@
>>>>>> interrupts = <GIC_SPI 321
>>>>>> IRQ_TYPE_LEVEL_HIGH>;
>>>>>> #address-cells = <1>;
>>>>>> #size-cells = <0>;
>>>>>> +#if (NUM_SATA > 0)
>>>>>> + status = "okay";
>>>>>> +#else
>>>>>> status = "disabled";
>>>>>> +#endif
>>> This only works if ports are contiguously enabled (0-N). You might not
>>> care, but it is not a pattern that works in general.
> Correct - all board designs that include this dtsi file follow such
> commonality (ie. design with SATA0 first, etc). By having common board
> designs it allows for commonality in dts files rather than duplicating
> information everywhere. If somebody designs a bizarro board they are
> free to create their own dts file of course.
>>> And I'm not a fan
>>> of C preprocessing in DT files in general beyond just defines for
>>> single numbers.
> The use of a define to specify the number of SATA ports in the board
> design meets our requirements of being able to maintain many boards. We
> need a method to specify the number of ports in the board design rather
> than copying and pasting the information in many dts files. If you have
> an alternative upstreamable mechanism to manage the configuration of
> many boards without copy and paste that would be ideal?
We had discussed this off-list, but I really think you should be having
some sort of higher level scripting engine which is able to generate
valid per-board DTS files and not have the kernel and its use of the C
pre-processor attempt to solve your problems because a) it's the wrong
place, and b) it is limited.
--
Florian
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
@ 2018-06-14 0:46 ` Florian Fainelli
0 siblings, 0 replies; 24+ messages in thread
From: Florian Fainelli @ 2018-06-14 0:46 UTC (permalink / raw)
To: Scott Branden, Rob Herring
Cc: Mark Rutland, Catalin Marinas, Will Deacon, Ray Jui,
BCM Kernel Feedback, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-kernel
On 06/13/2018 01:18 PM, Scott Branden wrote:
> Hi Rob,
>
> Thanks for comment - reply inline.
>
>
> On 18-06-13 12:31 PM, Florian Fainelli wrote:
>> On 06/12/2018 03:54 PM, Rob Herring wrote:
>>> On Thu, Jun 7, 2018 at 12:53 PM, Scott Branden
>>> <scott.branden@broadcom.com> wrote:
>>>> Hi Rob,
>>>>
>>>> Could you please kindly comment on change below.
>>>>
>>>> It allows board variants to be added easily via a simple define for
>>>> different number of SATA ports.
>>>>
>>>>
>>>>
>>>> On 18-06-04 09:22 AM, Florian Fainelli wrote:
>>>>> On 05/18/2018 11:34 AM, Scott Branden wrote:
>>>>>> Move remaining sata configuration to stingray-sata.dtsi and enable
>>>>>> ports based on NUM_SATA defined.
>>>>>> Now, all that needs to be done is define NUM_SATA per board.
>>>>> Rob could you review this and let us know if this approach is okay or
>>>>> not? Thank you!
>>>>>
>>>>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>>>>> ---
>>>>>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> index 8c68e0c..7f6d176 100644
>>>>>> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> @@ -43,7 +43,11 @@
>>>>>> interrupts = <GIC_SPI 321
>>>>>> IRQ_TYPE_LEVEL_HIGH>;
>>>>>> #address-cells = <1>;
>>>>>> #size-cells = <0>;
>>>>>> +#if (NUM_SATA > 0)
>>>>>> + status = "okay";
>>>>>> +#else
>>>>>> status = "disabled";
>>>>>> +#endif
>>> This only works if ports are contiguously enabled (0-N). You might not
>>> care, but it is not a pattern that works in general.
> Correct - all board designs that include this dtsi file follow such
> commonality (ie. design with SATA0 first, etc). By having common board
> designs it allows for commonality in dts files rather than duplicating
> information everywhere. If somebody designs a bizarro board they are
> free to create their own dts file of course.
>>> And I'm not a fan
>>> of C preprocessing in DT files in general beyond just defines for
>>> single numbers.
> The use of a define to specify the number of SATA ports in the board
> design meets our requirements of being able to maintain many boards. We
> need a method to specify the number of ports in the board design rather
> than copying and pasting the information in many dts files. If you have
> an alternative upstreamable mechanism to manage the configuration of
> many boards without copy and paste that would be ideal?
We had discussed this off-list, but I really think you should be having
some sort of higher level scripting engine which is able to generate
valid per-board DTS files and not have the kernel and its use of the C
pre-processor attempt to solve your problems because a) it's the wrong
place, and b) it is limited.
--
Florian
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
@ 2018-06-14 0:46 ` Florian Fainelli
0 siblings, 0 replies; 24+ messages in thread
From: Florian Fainelli @ 2018-06-14 0:46 UTC (permalink / raw)
To: linux-arm-kernel
On 06/13/2018 01:18 PM, Scott Branden wrote:
> Hi Rob,
>
> Thanks for comment - reply inline.
>
>
> On 18-06-13 12:31 PM, Florian Fainelli wrote:
>> On 06/12/2018 03:54 PM, Rob Herring wrote:
>>> On Thu, Jun 7, 2018 at 12:53 PM, Scott Branden
>>> <scott.branden@broadcom.com> wrote:
>>>> Hi Rob,
>>>>
>>>> Could you please kindly comment on change below.
>>>>
>>>> It allows board variants to be added easily via a simple define for
>>>> different number of SATA ports.
>>>>
>>>>
>>>>
>>>> On 18-06-04 09:22 AM, Florian Fainelli wrote:
>>>>> On 05/18/2018 11:34 AM, Scott Branden wrote:
>>>>>> Move remaining sata configuration to stingray-sata.dtsi and enable
>>>>>> ports based on NUM_SATA defined.
>>>>>> Now, all that needs to be done is define NUM_SATA per board.
>>>>> Rob could you review this and let us know if this approach is okay or
>>>>> not? Thank you!
>>>>>
>>>>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>>>>> ---
>>>>>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> index 8c68e0c..7f6d176 100644
>>>>>> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> @@ -43,7 +43,11 @@
>>>>>> ???????????????????????? interrupts = <GIC_SPI 321
>>>>>> IRQ_TYPE_LEVEL_HIGH>;
>>>>>> ???????????????????????? #address-cells = <1>;
>>>>>> ???????????????????????? #size-cells = <0>;
>>>>>> +#if (NUM_SATA > 0)
>>>>>> +?????????????????????? status = "okay";
>>>>>> +#else
>>>>>> ???????????????????????? status = "disabled";
>>>>>> +#endif
>>> This only works if ports are contiguously enabled (0-N). You might not
>>> care, but it is not a pattern that works in general.
> Correct - all board designs that include this dtsi file follow such
> commonality (ie. design with SATA0 first, etc).? By having common board
> designs it allows for commonality in dts files rather than duplicating
> information everywhere.? If somebody designs a bizarro board they are
> free to create their own dts file of course.
>>> ? And I'm not a fan
>>> of C preprocessing in DT files in general beyond just defines for
>>> single numbers.
> The use of a define to specify the number of SATA ports in the board
> design meets our requirements of being able to maintain many boards.? We
> need a method to specify the number of ports in the board design rather
> than copying and pasting the information in many dts files.? If you have
> an alternative upstreamable mechanism to manage the configuration of
> many boards without copy and paste that would be ideal?
We had discussed this off-list, but I really think you should be having
some sort of higher level scripting engine which is able to generate
valid per-board DTS files and not have the kernel and its use of the C
pre-processor attempt to solve your problems because a) it's the wrong
place, and b) it is limited.
--
Florian
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
2018-06-13 22:06 ` Rob Herring
(?)
@ 2018-06-14 18:53 ` Scott Branden
-1 siblings, 0 replies; 24+ messages in thread
From: Scott Branden @ 2018-06-14 18:53 UTC (permalink / raw)
To: Rob Herring
Cc: Florian Fainelli, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Ray Jui, BCM Kernel Feedback, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-kernel
On 18-06-13 03:06 PM, Rob Herring wrote:
> On Wed, Jun 13, 2018 at 2:18 PM, Scott Branden
> <scott.branden@broadcom.com> wrote:
>> Hi Rob,
>>
>> Thanks for comment - reply inline.
>>
>>
>>
>> On 18-06-13 12:31 PM, Florian Fainelli wrote:
>>> On 06/12/2018 03:54 PM, Rob Herring wrote:
>>>> On Thu, Jun 7, 2018 at 12:53 PM, Scott Branden
>>>> <scott.branden@broadcom.com> wrote:
>>>>> Hi Rob,
>>>>>
>>>>> Could you please kindly comment on change below.
>>>>>
>>>>> It allows board variants to be added easily via a simple define for
>>>>> different number of SATA ports.
>>>>>
>>>>>
>>>>>
>>>>> On 18-06-04 09:22 AM, Florian Fainelli wrote:
>>>>>> On 05/18/2018 11:34 AM, Scott Branden wrote:
>>>>>>> Move remaining sata configuration to stingray-sata.dtsi and enable
>>>>>>> ports based on NUM_SATA defined.
>>>>>>> Now, all that needs to be done is define NUM_SATA per board.
>>>>>> Rob could you review this and let us know if this approach is okay or
>>>>>> not? Thank you!
>>>>>>
>>>>>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>>>>>> ---
>>>>>>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>>> b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>>> index 8c68e0c..7f6d176 100644
>>>>>>> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>>> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>>> @@ -43,7 +43,11 @@
>>>>>>> interrupts = <GIC_SPI 321
>>>>>>> IRQ_TYPE_LEVEL_HIGH>;
>>>>>>> #address-cells = <1>;
>>>>>>> #size-cells = <0>;
>>>>>>> +#if (NUM_SATA > 0)
>>>>>>> + status = "okay";
>>>>>>> +#else
>>>>>>> status = "disabled";
>>>>>>> +#endif
>>>> This only works if ports are contiguously enabled (0-N). You might not
>>>> care, but it is not a pattern that works in general.
>> Correct - all board designs that include this dtsi file follow such
>> commonality (ie. design with SATA0 first, etc). By having common board
>> designs it allows for commonality in dts files rather than duplicating
>> information everywhere. If somebody designs a bizarro board they are free
>> to create their own dts file of course.
>>>> And I'm not a fan
>>>> of C preprocessing in DT files in general beyond just defines for
>>>> single numbers.
>> The use of a define to specify the number of SATA ports in the board design
>> meets our requirements of being able to maintain many boards. We need a
>> method to specify the number of ports in the board design rather than
>> copying and pasting the information in many dts files. If you have an
>> alternative upstreamable mechanism to manage the configuration of many
>> boards without copy and paste that would be ideal?
> Is this really the only problem with maintaining lots of boards? What
> about all the other nodes that are conditionally enabled? Really, I
> don't see the problem with 3 lines per node.
Yes - the problem with maintaining lots of boards is having to copy and
paste duplicated lines per nodes in many files which can be maintained
with a single define.
>
> Does having an unused port enabled cause problems? If not, you could
> handle it all at run-time and just shutdown ports which have no link.
> You'd want to do that anyway for boards with a port, but is not
> connected to a drive (except for hotplug capable ports).
SATA is not the only place we use defines. This is one change for
review to see if there are any "real" problems with doing it upstream
and get comment. All the board variations simply add a few defines and
don't need to do anything else using my approach. No out-of-tree
special tools or scripts required to generate dts files, no run-time
bootloader or kernel changes necessary.
>
> Maybe we could add a property in /chosen that is a list of nodes to
> enable and either the bootloader or kernel could update their
> 'status'. Or It could even be done in dtc perhaps with some
> /directive/.
Sure, if it is a single line change needed through a "chosen" or
"directive" instead of a "define" that sounds fine. How would I do that
in the SATA example?
I am looking for an in-tree solution to managing the boards in a simpler
manner than what is available by cutting and pasting nodes in many files.
The use of the defines allows such without any special script or tool or
repo needing to be maintained out of tree.
>
> Rob
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
@ 2018-06-14 18:53 ` Scott Branden
0 siblings, 0 replies; 24+ messages in thread
From: Scott Branden @ 2018-06-14 18:53 UTC (permalink / raw)
To: Rob Herring
Cc: Florian Fainelli, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Ray Jui, BCM Kernel Feedback, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-kernel
On 18-06-13 03:06 PM, Rob Herring wrote:
> On Wed, Jun 13, 2018 at 2:18 PM, Scott Branden
> <scott.branden@broadcom.com> wrote:
>> Hi Rob,
>>
>> Thanks for comment - reply inline.
>>
>>
>>
>> On 18-06-13 12:31 PM, Florian Fainelli wrote:
>>> On 06/12/2018 03:54 PM, Rob Herring wrote:
>>>> On Thu, Jun 7, 2018 at 12:53 PM, Scott Branden
>>>> <scott.branden@broadcom.com> wrote:
>>>>> Hi Rob,
>>>>>
>>>>> Could you please kindly comment on change below.
>>>>>
>>>>> It allows board variants to be added easily via a simple define for
>>>>> different number of SATA ports.
>>>>>
>>>>>
>>>>>
>>>>> On 18-06-04 09:22 AM, Florian Fainelli wrote:
>>>>>> On 05/18/2018 11:34 AM, Scott Branden wrote:
>>>>>>> Move remaining sata configuration to stingray-sata.dtsi and enable
>>>>>>> ports based on NUM_SATA defined.
>>>>>>> Now, all that needs to be done is define NUM_SATA per board.
>>>>>> Rob could you review this and let us know if this approach is okay or
>>>>>> not? Thank you!
>>>>>>
>>>>>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>>>>>> ---
>>>>>>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>>> b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>>> index 8c68e0c..7f6d176 100644
>>>>>>> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>>> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>>> @@ -43,7 +43,11 @@
>>>>>>> interrupts = <GIC_SPI 321
>>>>>>> IRQ_TYPE_LEVEL_HIGH>;
>>>>>>> #address-cells = <1>;
>>>>>>> #size-cells = <0>;
>>>>>>> +#if (NUM_SATA > 0)
>>>>>>> + status = "okay";
>>>>>>> +#else
>>>>>>> status = "disabled";
>>>>>>> +#endif
>>>> This only works if ports are contiguously enabled (0-N). You might not
>>>> care, but it is not a pattern that works in general.
>> Correct - all board designs that include this dtsi file follow such
>> commonality (ie. design with SATA0 first, etc). By having common board
>> designs it allows for commonality in dts files rather than duplicating
>> information everywhere. If somebody designs a bizarro board they are free
>> to create their own dts file of course.
>>>> And I'm not a fan
>>>> of C preprocessing in DT files in general beyond just defines for
>>>> single numbers.
>> The use of a define to specify the number of SATA ports in the board design
>> meets our requirements of being able to maintain many boards. We need a
>> method to specify the number of ports in the board design rather than
>> copying and pasting the information in many dts files. If you have an
>> alternative upstreamable mechanism to manage the configuration of many
>> boards without copy and paste that would be ideal?
> Is this really the only problem with maintaining lots of boards? What
> about all the other nodes that are conditionally enabled? Really, I
> don't see the problem with 3 lines per node.
Yes - the problem with maintaining lots of boards is having to copy and
paste duplicated lines per nodes in many files which can be maintained
with a single define.
>
> Does having an unused port enabled cause problems? If not, you could
> handle it all at run-time and just shutdown ports which have no link.
> You'd want to do that anyway for boards with a port, but is not
> connected to a drive (except for hotplug capable ports).
SATA is not the only place we use defines. This is one change for
review to see if there are any "real" problems with doing it upstream
and get comment. All the board variations simply add a few defines and
don't need to do anything else using my approach. No out-of-tree
special tools or scripts required to generate dts files, no run-time
bootloader or kernel changes necessary.
>
> Maybe we could add a property in /chosen that is a list of nodes to
> enable and either the bootloader or kernel could update their
> 'status'. Or It could even be done in dtc perhaps with some
> /directive/.
Sure, if it is a single line change needed through a "chosen" or
"directive" instead of a "define" that sounds fine. How would I do that
in the SATA example?
I am looking for an in-tree solution to managing the boards in a simpler
manner than what is available by cutting and pasting nodes in many files.
The use of the defines allows such without any special script or tool or
repo needing to be maintained out of tree.
>
> Rob
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
@ 2018-06-14 18:53 ` Scott Branden
0 siblings, 0 replies; 24+ messages in thread
From: Scott Branden @ 2018-06-14 18:53 UTC (permalink / raw)
To: linux-arm-kernel
On 18-06-13 03:06 PM, Rob Herring wrote:
> On Wed, Jun 13, 2018 at 2:18 PM, Scott Branden
> <scott.branden@broadcom.com> wrote:
>> Hi Rob,
>>
>> Thanks for comment - reply inline.
>>
>>
>>
>> On 18-06-13 12:31 PM, Florian Fainelli wrote:
>>> On 06/12/2018 03:54 PM, Rob Herring wrote:
>>>> On Thu, Jun 7, 2018 at 12:53 PM, Scott Branden
>>>> <scott.branden@broadcom.com> wrote:
>>>>> Hi Rob,
>>>>>
>>>>> Could you please kindly comment on change below.
>>>>>
>>>>> It allows board variants to be added easily via a simple define for
>>>>> different number of SATA ports.
>>>>>
>>>>>
>>>>>
>>>>> On 18-06-04 09:22 AM, Florian Fainelli wrote:
>>>>>> On 05/18/2018 11:34 AM, Scott Branden wrote:
>>>>>>> Move remaining sata configuration to stingray-sata.dtsi and enable
>>>>>>> ports based on NUM_SATA defined.
>>>>>>> Now, all that needs to be done is define NUM_SATA per board.
>>>>>> Rob could you review this and let us know if this approach is okay or
>>>>>> not? Thank you!
>>>>>>
>>>>>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>>>>>> ---
>>>>>>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>>> b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>>> index 8c68e0c..7f6d176 100644
>>>>>>> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>>> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>>> @@ -43,7 +43,11 @@
>>>>>>> interrupts = <GIC_SPI 321
>>>>>>> IRQ_TYPE_LEVEL_HIGH>;
>>>>>>> #address-cells = <1>;
>>>>>>> #size-cells = <0>;
>>>>>>> +#if (NUM_SATA > 0)
>>>>>>> + status = "okay";
>>>>>>> +#else
>>>>>>> status = "disabled";
>>>>>>> +#endif
>>>> This only works if ports are contiguously enabled (0-N). You might not
>>>> care, but it is not a pattern that works in general.
>> Correct - all board designs that include this dtsi file follow such
>> commonality (ie. design with SATA0 first, etc). By having common board
>> designs it allows for commonality in dts files rather than duplicating
>> information everywhere. If somebody designs a bizarro board they are free
>> to create their own dts file of course.
>>>> And I'm not a fan
>>>> of C preprocessing in DT files in general beyond just defines for
>>>> single numbers.
>> The use of a define to specify the number of SATA ports in the board design
>> meets our requirements of being able to maintain many boards. We need a
>> method to specify the number of ports in the board design rather than
>> copying and pasting the information in many dts files. If you have an
>> alternative upstreamable mechanism to manage the configuration of many
>> boards without copy and paste that would be ideal?
> Is this really the only problem with maintaining lots of boards? What
> about all the other nodes that are conditionally enabled? Really, I
> don't see the problem with 3 lines per node.
Yes - the problem with maintaining lots of boards is having to copy and
paste duplicated lines per nodes in many files which can be maintained
with a single define.
>
> Does having an unused port enabled cause problems? If not, you could
> handle it all at run-time and just shutdown ports which have no link.
> You'd want to do that anyway for boards with a port, but is not
> connected to a drive (except for hotplug capable ports).
SATA is not the only place we use defines.? This is one change for
review to see if there are any "real" problems with doing it upstream
and get comment.? All the board variations simply add a few defines and
don't need to do anything else using my approach.? No out-of-tree
special tools or scripts required to generate dts files, no run-time
bootloader or kernel changes necessary.
>
> Maybe we could add a property in /chosen that is a list of nodes to
> enable and either the bootloader or kernel could update their
> 'status'. Or It could even be done in dtc perhaps with some
> /directive/.
Sure, if it is a single line change needed through a "chosen" or
"directive" instead of a "define" that sounds fine.? How would I do that
in the SATA example?
I am looking for an in-tree solution to managing the boards in a simpler
manner than what is available by cutting and pasting nodes in many files.
The use of the defines allows such without any special script or tool or
repo needing to be maintained out of tree.
>
> Rob
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2018-06-14 18:53 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-18 18:34 [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports Scott Branden
2018-05-18 18:34 ` Scott Branden
2018-06-04 16:22 ` Florian Fainelli
2018-06-04 16:22 ` Florian Fainelli
2018-06-07 18:53 ` Scott Branden
2018-06-07 18:53 ` Scott Branden
2018-06-12 22:54 ` Rob Herring
2018-06-12 22:54 ` Rob Herring
2018-06-12 22:54 ` Rob Herring
2018-06-13 19:31 ` Florian Fainelli
2018-06-13 19:31 ` Florian Fainelli
2018-06-13 19:31 ` Florian Fainelli
2018-06-13 20:18 ` Scott Branden
2018-06-13 20:18 ` Scott Branden
2018-06-13 20:18 ` Scott Branden
2018-06-13 22:06 ` Rob Herring
2018-06-13 22:06 ` Rob Herring
2018-06-13 22:06 ` Rob Herring
2018-06-14 18:53 ` Scott Branden
2018-06-14 18:53 ` Scott Branden
2018-06-14 18:53 ` Scott Branden
2018-06-14 0:46 ` Florian Fainelli
2018-06-14 0:46 ` Florian Fainelli
2018-06-14 0:46 ` Florian Fainelli
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.