All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] ARM: dts: BCM5301X: Specify MDIO bus in the DT
@ 2017-04-02 21:08 ` Rafał Miłecki
  0 siblings, 0 replies; 18+ messages in thread
From: Rafał Miłecki @ 2017-04-02 21:08 UTC (permalink / raw)
  To: Florian Fainelli
  Cc: Hauke Mehrtens, Rob Herring, Mark Rutland, Russell King,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki

From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>

Northstar devices have MDIO bus that may contain various PHYs attached.
A common example is USB 3.0 PHY (that doesn't have an MDIO driver yet).

Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
 arch/arm/boot/dts/bcm5301x.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
index acee36a61004..6a2afe7880ae 100644
--- a/arch/arm/boot/dts/bcm5301x.dtsi
+++ b/arch/arm/boot/dts/bcm5301x.dtsi
@@ -320,6 +320,13 @@
 		};
 	};
 
+	mdio@18003000 {
+		compatible = "brcm,iproc-mdio";
+		reg = <0x18003000 0x8>;
+		#size-cells = <1>;
+		#address-cells = <0>;
+	};
+
 	i2c0: i2c@18009000 {
 		compatible = "brcm,iproc-i2c";
 		reg = <0x18009000 0x50>;
-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related	[flat|nested] 18+ messages in thread

* [PATCH] ARM: dts: BCM5301X: Specify MDIO bus in the DT
@ 2017-04-02 21:08 ` Rafał Miłecki
  0 siblings, 0 replies; 18+ messages in thread
From: Rafał Miłecki @ 2017-04-02 21:08 UTC (permalink / raw)
  To: linux-arm-kernel

From: Rafa? Mi?ecki <rafal@milecki.pl>

Northstar devices have MDIO bus that may contain various PHYs attached.
A common example is USB 3.0 PHY (that doesn't have an MDIO driver yet).

Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
---
 arch/arm/boot/dts/bcm5301x.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
index acee36a61004..6a2afe7880ae 100644
--- a/arch/arm/boot/dts/bcm5301x.dtsi
+++ b/arch/arm/boot/dts/bcm5301x.dtsi
@@ -320,6 +320,13 @@
 		};
 	};
 
+	mdio at 18003000 {
+		compatible = "brcm,iproc-mdio";
+		reg = <0x18003000 0x8>;
+		#size-cells = <1>;
+		#address-cells = <0>;
+	};
+
 	i2c0: i2c at 18009000 {
 		compatible = "brcm,iproc-i2c";
 		reg = <0x18009000 0x50>;
-- 
2.11.0

^ permalink raw reply related	[flat|nested] 18+ messages in thread

* Re: [PATCH] ARM: dts: BCM5301X: Specify MDIO bus in the DT
  2017-04-02 21:08 ` Rafał Miłecki
@ 2017-04-02 21:14     ` Florian Fainelli
  -1 siblings, 0 replies; 18+ messages in thread
From: Florian Fainelli @ 2017-04-02 21:14 UTC (permalink / raw)
  To: Rafał Miłecki
  Cc: Hauke Mehrtens, Rob Herring, Mark Rutland, Russell King,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki

Le 04/02/17 à 14:08, Rafał Miłecki a écrit :
> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> 
> Northstar devices have MDIO bus that may contain various PHYs attached.
> A common example is USB 3.0 PHY (that doesn't have an MDIO driver yet).
> 
> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> ---
>  arch/arm/boot/dts/bcm5301x.dtsi | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
> index acee36a61004..6a2afe7880ae 100644
> --- a/arch/arm/boot/dts/bcm5301x.dtsi
> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
> @@ -320,6 +320,13 @@
>  		};
>  	};
>  
> +	mdio@18003000 {
> +		compatible = "brcm,iproc-mdio";
> +		reg = <0x18003000 0x8>;
> +		#size-cells = <1>;
> +		#address-cells = <0>;
> +	};

This looks fine, but usually the block should be enabled on a per-board
basis, such that there should be a status = "disabled" property here by
default.
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [PATCH] ARM: dts: BCM5301X: Specify MDIO bus in the DT
@ 2017-04-02 21:14     ` Florian Fainelli
  0 siblings, 0 replies; 18+ messages in thread
From: Florian Fainelli @ 2017-04-02 21:14 UTC (permalink / raw)
  To: linux-arm-kernel

Le 04/02/17 ? 14:08, Rafa? Mi?ecki a ?crit :
> From: Rafa? Mi?ecki <rafal@milecki.pl>
> 
> Northstar devices have MDIO bus that may contain various PHYs attached.
> A common example is USB 3.0 PHY (that doesn't have an MDIO driver yet).
> 
> Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
> ---
>  arch/arm/boot/dts/bcm5301x.dtsi | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
> index acee36a61004..6a2afe7880ae 100644
> --- a/arch/arm/boot/dts/bcm5301x.dtsi
> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
> @@ -320,6 +320,13 @@
>  		};
>  	};
>  
> +	mdio at 18003000 {
> +		compatible = "brcm,iproc-mdio";
> +		reg = <0x18003000 0x8>;
> +		#size-cells = <1>;
> +		#address-cells = <0>;
> +	};

This looks fine, but usually the block should be enabled on a per-board
basis, such that there should be a status = "disabled" property here by
default.
-- 
Florian

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] ARM: dts: BCM5301X: Specify MDIO bus in the DT
  2017-04-02 21:14     ` Florian Fainelli
@ 2017-04-02 21:25         ` Rafał Miłecki
  -1 siblings, 0 replies; 18+ messages in thread
From: Rafał Miłecki @ 2017-04-02 21:25 UTC (permalink / raw)
  To: Florian Fainelli, Rafał Miłecki
  Cc: Hauke Mehrtens, Rob Herring, Mark Rutland, Russell King,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
	devicetree-u79uwXL29TY76Z2rM5mHXA

On 04/02/2017 11:14 PM, Florian Fainelli wrote:
> Le 04/02/17 à 14:08, Rafał Miłecki a écrit :
>> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>>
>> Northstar devices have MDIO bus that may contain various PHYs attached.
>> A common example is USB 3.0 PHY (that doesn't have an MDIO driver yet).
>>
>> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>> ---
>>  arch/arm/boot/dts/bcm5301x.dtsi | 7 +++++++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
>> index acee36a61004..6a2afe7880ae 100644
>> --- a/arch/arm/boot/dts/bcm5301x.dtsi
>> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
>> @@ -320,6 +320,13 @@
>>  		};
>>  	};
>>
>> +	mdio@18003000 {
>> +		compatible = "brcm,iproc-mdio";
>> +		reg = <0x18003000 0x8>;
>> +		#size-cells = <1>;
>> +		#address-cells = <0>;
>> +	};
>
> This looks fine, but usually the block should be enabled on a per-board
> basis, such that there should be a status = "disabled" property here by
> default.

I think we have few blocks in bcm5301x.dtsi enabled by default. I guess it's
for stuff that is always present on every SoC family board: rng, nand, spi to
name few.

It makes some sense, consider e.g. spi. Every Northstar board has SPI
controller so it's enabled by default. Not every board has SPI flash, so it's
disabled by default.

It's there and it make sense to me. Is that OK or not?

I find MDIO situation quite simiar. It seems every Northstar board has MDIO bus
just devices may differ and should not be enabled by default.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [PATCH] ARM: dts: BCM5301X: Specify MDIO bus in the DT
@ 2017-04-02 21:25         ` Rafał Miłecki
  0 siblings, 0 replies; 18+ messages in thread
From: Rafał Miłecki @ 2017-04-02 21:25 UTC (permalink / raw)
  To: linux-arm-kernel

On 04/02/2017 11:14 PM, Florian Fainelli wrote:
> Le 04/02/17 ? 14:08, Rafa? Mi?ecki a ?crit :
>> From: Rafa? Mi?ecki <rafal@milecki.pl>
>>
>> Northstar devices have MDIO bus that may contain various PHYs attached.
>> A common example is USB 3.0 PHY (that doesn't have an MDIO driver yet).
>>
>> Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
>> ---
>>  arch/arm/boot/dts/bcm5301x.dtsi | 7 +++++++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
>> index acee36a61004..6a2afe7880ae 100644
>> --- a/arch/arm/boot/dts/bcm5301x.dtsi
>> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
>> @@ -320,6 +320,13 @@
>>  		};
>>  	};
>>
>> +	mdio at 18003000 {
>> +		compatible = "brcm,iproc-mdio";
>> +		reg = <0x18003000 0x8>;
>> +		#size-cells = <1>;
>> +		#address-cells = <0>;
>> +	};
>
> This looks fine, but usually the block should be enabled on a per-board
> basis, such that there should be a status = "disabled" property here by
> default.

I think we have few blocks in bcm5301x.dtsi enabled by default. I guess it's
for stuff that is always present on every SoC family board: rng, nand, spi to
name few.

It makes some sense, consider e.g. spi. Every Northstar board has SPI
controller so it's enabled by default. Not every board has SPI flash, so it's
disabled by default.

It's there and it make sense to me. Is that OK or not?

I find MDIO situation quite simiar. It seems every Northstar board has MDIO bus
just devices may differ and should not be enabled by default.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] ARM: dts: BCM5301X: Specify MDIO bus in the DT
  2017-04-02 21:25         ` Rafał Miłecki
@ 2017-04-19 16:43             ` Florian Fainelli
  -1 siblings, 0 replies; 18+ messages in thread
From: Florian Fainelli @ 2017-04-19 16:43 UTC (permalink / raw)
  To: Rafał Miłecki, Florian Fainelli, Rafał Miłecki
  Cc: Hauke Mehrtens, Rob Herring, Mark Rutland, Russell King,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
	devicetree-u79uwXL29TY76Z2rM5mHXA

On 04/02/2017 02:25 PM, Rafał Miłecki wrote:
> On 04/02/2017 11:14 PM, Florian Fainelli wrote:
>> Le 04/02/17 à 14:08, Rafał Miłecki a écrit :
>>> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>>>
>>> Northstar devices have MDIO bus that may contain various PHYs attached.
>>> A common example is USB 3.0 PHY (that doesn't have an MDIO driver yet).
>>>
>>> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>>> ---
>>>  arch/arm/boot/dts/bcm5301x.dtsi | 7 +++++++
>>>  1 file changed, 7 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi
>>> b/arch/arm/boot/dts/bcm5301x.dtsi
>>> index acee36a61004..6a2afe7880ae 100644
>>> --- a/arch/arm/boot/dts/bcm5301x.dtsi
>>> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
>>> @@ -320,6 +320,13 @@
>>>          };
>>>      };
>>>
>>> +    mdio@18003000 {
>>> +        compatible = "brcm,iproc-mdio";
>>> +        reg = <0x18003000 0x8>;
>>> +        #size-cells = <1>;
>>> +        #address-cells = <0>;
>>> +    };
>>
>> This looks fine, but usually the block should be enabled on a per-board
>> basis, such that there should be a status = "disabled" property here by
>> default.
> 
> I think we have few blocks in bcm5301x.dtsi enabled by default. I guess
> it's
> for stuff that is always present on every SoC family board: rng, nand,
> spi to
> name few.
> 
> It makes some sense, consider e.g. spi. Every Northstar board has SPI
> controller so it's enabled by default. Not every board has SPI flash, so
> it's
> disabled by default.
> 
> It's there and it make sense to me. Is that OK or not?

Even though there are devices that are always enabled on a given SoC,
because the board designs are always consistent does not necessarily
make them good candidates to be enabled at the .dtsi level. This is
particularly true when there are external connections to blocks (SPI,
NAND, USB, Ethernet, MDIO to name a few), having them disabled by
default is safer as a starting point to begin with.

> 
> I find MDIO situation quite simiar. It seems every Northstar board has
> MDIO bus
> just devices may differ and should not be enabled by default.

In which case, the only difference, for you would be to do to, at the
board-level DTS:

&mdio {
	status = "okay";

	phy@0 {
		reg = <0>;
		...
	};
};

versus:

&mdio {
	phy@0 {
		reg = <0>;
		...
	};
};

I think we can afford putting the mdio node's status property in each
board-level DTS and make it clear that way that it is enabled because
there are child nodes enabled?

NB: with a CONFIG_OF system, there is no automatic probing of MDIO child
devices because it relies on child nodes being declared, but you would
still get the driver to be probed and enabled, which is a waste of
resources at best.

Thanks
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [PATCH] ARM: dts: BCM5301X: Specify MDIO bus in the DT
@ 2017-04-19 16:43             ` Florian Fainelli
  0 siblings, 0 replies; 18+ messages in thread
From: Florian Fainelli @ 2017-04-19 16:43 UTC (permalink / raw)
  To: linux-arm-kernel

On 04/02/2017 02:25 PM, Rafa? Mi?ecki wrote:
> On 04/02/2017 11:14 PM, Florian Fainelli wrote:
>> Le 04/02/17 ? 14:08, Rafa? Mi?ecki a ?crit :
>>> From: Rafa? Mi?ecki <rafal@milecki.pl>
>>>
>>> Northstar devices have MDIO bus that may contain various PHYs attached.
>>> A common example is USB 3.0 PHY (that doesn't have an MDIO driver yet).
>>>
>>> Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
>>> ---
>>>  arch/arm/boot/dts/bcm5301x.dtsi | 7 +++++++
>>>  1 file changed, 7 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi
>>> b/arch/arm/boot/dts/bcm5301x.dtsi
>>> index acee36a61004..6a2afe7880ae 100644
>>> --- a/arch/arm/boot/dts/bcm5301x.dtsi
>>> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
>>> @@ -320,6 +320,13 @@
>>>          };
>>>      };
>>>
>>> +    mdio at 18003000 {
>>> +        compatible = "brcm,iproc-mdio";
>>> +        reg = <0x18003000 0x8>;
>>> +        #size-cells = <1>;
>>> +        #address-cells = <0>;
>>> +    };
>>
>> This looks fine, but usually the block should be enabled on a per-board
>> basis, such that there should be a status = "disabled" property here by
>> default.
> 
> I think we have few blocks in bcm5301x.dtsi enabled by default. I guess
> it's
> for stuff that is always present on every SoC family board: rng, nand,
> spi to
> name few.
> 
> It makes some sense, consider e.g. spi. Every Northstar board has SPI
> controller so it's enabled by default. Not every board has SPI flash, so
> it's
> disabled by default.
> 
> It's there and it make sense to me. Is that OK or not?

Even though there are devices that are always enabled on a given SoC,
because the board designs are always consistent does not necessarily
make them good candidates to be enabled at the .dtsi level. This is
particularly true when there are external connections to blocks (SPI,
NAND, USB, Ethernet, MDIO to name a few), having them disabled by
default is safer as a starting point to begin with.

> 
> I find MDIO situation quite simiar. It seems every Northstar board has
> MDIO bus
> just devices may differ and should not be enabled by default.

In which case, the only difference, for you would be to do to, at the
board-level DTS:

&mdio {
	status = "okay";

	phy at 0 {
		reg = <0>;
		...
	};
};

versus:

&mdio {
	phy at 0 {
		reg = <0>;
		...
	};
};

I think we can afford putting the mdio node's status property in each
board-level DTS and make it clear that way that it is enabled because
there are child nodes enabled?

NB: with a CONFIG_OF system, there is no automatic probing of MDIO child
devices because it relies on child nodes being declared, but you would
still get the driver to be probed and enabled, which is a waste of
resources at best.

Thanks
-- 
Florian

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] ARM: dts: BCM5301X: Specify MDIO bus in the DT
  2017-04-19 16:43             ` Florian Fainelli
@ 2017-04-19 17:35                 ` Rafał Miłecki
  -1 siblings, 0 replies; 18+ messages in thread
From: Rafał Miłecki @ 2017-04-19 17:35 UTC (permalink / raw)
  To: Florian Fainelli, Rafał Miłecki
  Cc: Hauke Mehrtens, Rob Herring, Mark Rutland, Russell King,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
	devicetree-u79uwXL29TY76Z2rM5mHXA

On 04/19/2017 06:43 PM, Florian Fainelli wrote:
> On 04/02/2017 02:25 PM, Rafał Miłecki wrote:
>> On 04/02/2017 11:14 PM, Florian Fainelli wrote:
>>> Le 04/02/17 à 14:08, Rafał Miłecki a écrit :
>>>> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>>>>
>>>> Northstar devices have MDIO bus that may contain various PHYs attached.
>>>> A common example is USB 3.0 PHY (that doesn't have an MDIO driver yet).
>>>>
>>>> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>>>> ---
>>>>  arch/arm/boot/dts/bcm5301x.dtsi | 7 +++++++
>>>>  1 file changed, 7 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi
>>>> b/arch/arm/boot/dts/bcm5301x.dtsi
>>>> index acee36a61004..6a2afe7880ae 100644
>>>> --- a/arch/arm/boot/dts/bcm5301x.dtsi
>>>> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
>>>> @@ -320,6 +320,13 @@
>>>>          };
>>>>      };
>>>>
>>>> +    mdio@18003000 {
>>>> +        compatible = "brcm,iproc-mdio";
>>>> +        reg = <0x18003000 0x8>;
>>>> +        #size-cells = <1>;
>>>> +        #address-cells = <0>;
>>>> +    };
>>>
>>> This looks fine, but usually the block should be enabled on a per-board
>>> basis, such that there should be a status = "disabled" property here by
>>> default.
>>
>> I think we have few blocks in bcm5301x.dtsi enabled by default. I guess
>> it's
>> for stuff that is always present on every SoC family board: rng, nand,
>> spi to
>> name few.
>>
>> It makes some sense, consider e.g. spi. Every Northstar board has SPI
>> controller so it's enabled by default. Not every board has SPI flash, so
>> it's
>> disabled by default.
>>
>> It's there and it make sense to me. Is that OK or not?
>
> Even though there are devices that are always enabled on a given SoC,
> because the board designs are always consistent does not necessarily
> make them good candidates to be enabled at the .dtsi level. This is
> particularly true when there are external connections to blocks (SPI,
> NAND, USB, Ethernet, MDIO to name a few), having them disabled by
> default is safer as a starting point to begin with.

In case of Northstar there is USB 3.0 PHY connected *internally* to this MDIO.
I don't think any board manufacturer is able to rip SoC out of the MDIO or the
USB 3.0 PHY.


>> I find MDIO situation quite simiar. It seems every Northstar board has
>> MDIO bus
>> just devices may differ and should not be enabled by default.
>
> In which case, the only difference, for you would be to do to, at the
> board-level DTS:
>
> &mdio {
> 	status = "okay";
>
> 	phy@0 {
> 		reg = <0>;
> 		...
> 	};
> };
>
> versus:
>
> &mdio {
> 	phy@0 {
> 		reg = <0>;
> 		...
> 	};
> };
>
> I think we can afford putting the mdio node's status property in each
> board-level DTS and make it clear that way that it is enabled because
> there are child nodes enabled?

This will be a pretty big effort because every Northstar device I know has USB
3.0 PHY in the SoC.


> NB: with a CONFIG_OF system, there is no automatic probing of MDIO child
> devices because it relies on child nodes being declared, but you would
> still get the driver to be probed and enabled, which is a waste of
> resources at best.

Right, but DT role is to describe device/board and not really care if operating
system handles that efficiently.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [PATCH] ARM: dts: BCM5301X: Specify MDIO bus in the DT
@ 2017-04-19 17:35                 ` Rafał Miłecki
  0 siblings, 0 replies; 18+ messages in thread
From: Rafał Miłecki @ 2017-04-19 17:35 UTC (permalink / raw)
  To: linux-arm-kernel

On 04/19/2017 06:43 PM, Florian Fainelli wrote:
> On 04/02/2017 02:25 PM, Rafa? Mi?ecki wrote:
>> On 04/02/2017 11:14 PM, Florian Fainelli wrote:
>>> Le 04/02/17 ? 14:08, Rafa? Mi?ecki a ?crit :
>>>> From: Rafa? Mi?ecki <rafal@milecki.pl>
>>>>
>>>> Northstar devices have MDIO bus that may contain various PHYs attached.
>>>> A common example is USB 3.0 PHY (that doesn't have an MDIO driver yet).
>>>>
>>>> Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
>>>> ---
>>>>  arch/arm/boot/dts/bcm5301x.dtsi | 7 +++++++
>>>>  1 file changed, 7 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi
>>>> b/arch/arm/boot/dts/bcm5301x.dtsi
>>>> index acee36a61004..6a2afe7880ae 100644
>>>> --- a/arch/arm/boot/dts/bcm5301x.dtsi
>>>> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
>>>> @@ -320,6 +320,13 @@
>>>>          };
>>>>      };
>>>>
>>>> +    mdio at 18003000 {
>>>> +        compatible = "brcm,iproc-mdio";
>>>> +        reg = <0x18003000 0x8>;
>>>> +        #size-cells = <1>;
>>>> +        #address-cells = <0>;
>>>> +    };
>>>
>>> This looks fine, but usually the block should be enabled on a per-board
>>> basis, such that there should be a status = "disabled" property here by
>>> default.
>>
>> I think we have few blocks in bcm5301x.dtsi enabled by default. I guess
>> it's
>> for stuff that is always present on every SoC family board: rng, nand,
>> spi to
>> name few.
>>
>> It makes some sense, consider e.g. spi. Every Northstar board has SPI
>> controller so it's enabled by default. Not every board has SPI flash, so
>> it's
>> disabled by default.
>>
>> It's there and it make sense to me. Is that OK or not?
>
> Even though there are devices that are always enabled on a given SoC,
> because the board designs are always consistent does not necessarily
> make them good candidates to be enabled at the .dtsi level. This is
> particularly true when there are external connections to blocks (SPI,
> NAND, USB, Ethernet, MDIO to name a few), having them disabled by
> default is safer as a starting point to begin with.

In case of Northstar there is USB 3.0 PHY connected *internally* to this MDIO.
I don't think any board manufacturer is able to rip SoC out of the MDIO or the
USB 3.0 PHY.


>> I find MDIO situation quite simiar. It seems every Northstar board has
>> MDIO bus
>> just devices may differ and should not be enabled by default.
>
> In which case, the only difference, for you would be to do to, at the
> board-level DTS:
>
> &mdio {
> 	status = "okay";
>
> 	phy at 0 {
> 		reg = <0>;
> 		...
> 	};
> };
>
> versus:
>
> &mdio {
> 	phy at 0 {
> 		reg = <0>;
> 		...
> 	};
> };
>
> I think we can afford putting the mdio node's status property in each
> board-level DTS and make it clear that way that it is enabled because
> there are child nodes enabled?

This will be a pretty big effort because every Northstar device I know has USB
3.0 PHY in the SoC.


> NB: with a CONFIG_OF system, there is no automatic probing of MDIO child
> devices because it relies on child nodes being declared, but you would
> still get the driver to be probed and enabled, which is a waste of
> resources at best.

Right, but DT role is to describe device/board and not really care if operating
system handles that efficiently.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] ARM: dts: BCM5301X: Specify MDIO bus in the DT
  2017-04-19 17:35                 ` Rafał Miłecki
@ 2017-04-19 17:52                     ` Florian Fainelli
  -1 siblings, 0 replies; 18+ messages in thread
From: Florian Fainelli @ 2017-04-19 17:52 UTC (permalink / raw)
  To: Rafał Miłecki, Florian Fainelli, Rafał Miłecki
  Cc: Hauke Mehrtens, Rob Herring, Mark Rutland, Russell King,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
	devicetree-u79uwXL29TY76Z2rM5mHXA

On 04/19/2017 10:35 AM, Rafał Miłecki wrote:
> On 04/19/2017 06:43 PM, Florian Fainelli wrote:
>> On 04/02/2017 02:25 PM, Rafał Miłecki wrote:
>>> On 04/02/2017 11:14 PM, Florian Fainelli wrote:
>>>> Le 04/02/17 à 14:08, Rafał Miłecki a écrit :
>>>>> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>>>>>
>>>>> Northstar devices have MDIO bus that may contain various PHYs
>>>>> attached.
>>>>> A common example is USB 3.0 PHY (that doesn't have an MDIO driver
>>>>> yet).
>>>>>
>>>>> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>>>>> ---
>>>>>  arch/arm/boot/dts/bcm5301x.dtsi | 7 +++++++
>>>>>  1 file changed, 7 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi
>>>>> b/arch/arm/boot/dts/bcm5301x.dtsi
>>>>> index acee36a61004..6a2afe7880ae 100644
>>>>> --- a/arch/arm/boot/dts/bcm5301x.dtsi
>>>>> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
>>>>> @@ -320,6 +320,13 @@
>>>>>          };
>>>>>      };
>>>>>
>>>>> +    mdio@18003000 {
>>>>> +        compatible = "brcm,iproc-mdio";
>>>>> +        reg = <0x18003000 0x8>;
>>>>> +        #size-cells = <1>;
>>>>> +        #address-cells = <0>;
>>>>> +    };
>>>>
>>>> This looks fine, but usually the block should be enabled on a per-board
>>>> basis, such that there should be a status = "disabled" property here by
>>>> default.
>>>
>>> I think we have few blocks in bcm5301x.dtsi enabled by default. I guess
>>> it's
>>> for stuff that is always present on every SoC family board: rng, nand,
>>> spi to
>>> name few.
>>>
>>> It makes some sense, consider e.g. spi. Every Northstar board has SPI
>>> controller so it's enabled by default. Not every board has SPI flash, so
>>> it's
>>> disabled by default.
>>>
>>> It's there and it make sense to me. Is that OK or not?
>>
>> Even though there are devices that are always enabled on a given SoC,
>> because the board designs are always consistent does not necessarily
>> make them good candidates to be enabled at the .dtsi level. This is
>> particularly true when there are external connections to blocks (SPI,
>> NAND, USB, Ethernet, MDIO to name a few), having them disabled by
>> default is safer as a starting point to begin with.
> 
> In case of Northstar there is USB 3.0 PHY connected *internally* to this
> MDIO.
> I don't think any board manufacturer is able to rip SoC out of the MDIO
> or the
> USB 3.0 PHY.

OK, then can you still resubmit a proper patch that a) puts that
information in the commit message, and b) also adds a proper label to
the mdio node such that it can later on be referenced by label in
board-level DTS files? By that I mean:

mdio: mdio@18003000 {

Thank you

> 
> 
>>> I find MDIO situation quite simiar. It seems every Northstar board has
>>> MDIO bus
>>> just devices may differ and should not be enabled by default.
>>
>> In which case, the only difference, for you would be to do to, at the
>> board-level DTS:
>>
>> &mdio {
>>     status = "okay";
>>
>>     phy@0 {
>>         reg = <0>;
>>         ...
>>     };
>> };
>>
>> versus:
>>
>> &mdio {
>>     phy@0 {
>>         reg = <0>;
>>         ...
>>     };
>> };
>>
>> I think we can afford putting the mdio node's status property in each
>> board-level DTS and make it clear that way that it is enabled because
>> there are child nodes enabled?
> 
> This will be a pretty big effort because every Northstar device I know
> has USB
> 3.0 PHY in the SoC.

Adding a one liner is a "pretty big effort", for sure.

> 
> 
>> NB: with a CONFIG_OF system, there is no automatic probing of MDIO child
>> devices because it relies on child nodes being declared, but you would
>> still get the driver to be probed and enabled, which is a waste of
>> resources at best.
> 
> Right, but DT role is to describe device/board and not really care if
> operating
> system handles that efficiently.


-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [PATCH] ARM: dts: BCM5301X: Specify MDIO bus in the DT
@ 2017-04-19 17:52                     ` Florian Fainelli
  0 siblings, 0 replies; 18+ messages in thread
From: Florian Fainelli @ 2017-04-19 17:52 UTC (permalink / raw)
  To: linux-arm-kernel

On 04/19/2017 10:35 AM, Rafa? Mi?ecki wrote:
> On 04/19/2017 06:43 PM, Florian Fainelli wrote:
>> On 04/02/2017 02:25 PM, Rafa? Mi?ecki wrote:
>>> On 04/02/2017 11:14 PM, Florian Fainelli wrote:
>>>> Le 04/02/17 ? 14:08, Rafa? Mi?ecki a ?crit :
>>>>> From: Rafa? Mi?ecki <rafal@milecki.pl>
>>>>>
>>>>> Northstar devices have MDIO bus that may contain various PHYs
>>>>> attached.
>>>>> A common example is USB 3.0 PHY (that doesn't have an MDIO driver
>>>>> yet).
>>>>>
>>>>> Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
>>>>> ---
>>>>>  arch/arm/boot/dts/bcm5301x.dtsi | 7 +++++++
>>>>>  1 file changed, 7 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi
>>>>> b/arch/arm/boot/dts/bcm5301x.dtsi
>>>>> index acee36a61004..6a2afe7880ae 100644
>>>>> --- a/arch/arm/boot/dts/bcm5301x.dtsi
>>>>> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
>>>>> @@ -320,6 +320,13 @@
>>>>>          };
>>>>>      };
>>>>>
>>>>> +    mdio at 18003000 {
>>>>> +        compatible = "brcm,iproc-mdio";
>>>>> +        reg = <0x18003000 0x8>;
>>>>> +        #size-cells = <1>;
>>>>> +        #address-cells = <0>;
>>>>> +    };
>>>>
>>>> This looks fine, but usually the block should be enabled on a per-board
>>>> basis, such that there should be a status = "disabled" property here by
>>>> default.
>>>
>>> I think we have few blocks in bcm5301x.dtsi enabled by default. I guess
>>> it's
>>> for stuff that is always present on every SoC family board: rng, nand,
>>> spi to
>>> name few.
>>>
>>> It makes some sense, consider e.g. spi. Every Northstar board has SPI
>>> controller so it's enabled by default. Not every board has SPI flash, so
>>> it's
>>> disabled by default.
>>>
>>> It's there and it make sense to me. Is that OK or not?
>>
>> Even though there are devices that are always enabled on a given SoC,
>> because the board designs are always consistent does not necessarily
>> make them good candidates to be enabled at the .dtsi level. This is
>> particularly true when there are external connections to blocks (SPI,
>> NAND, USB, Ethernet, MDIO to name a few), having them disabled by
>> default is safer as a starting point to begin with.
> 
> In case of Northstar there is USB 3.0 PHY connected *internally* to this
> MDIO.
> I don't think any board manufacturer is able to rip SoC out of the MDIO
> or the
> USB 3.0 PHY.

OK, then can you still resubmit a proper patch that a) puts that
information in the commit message, and b) also adds a proper label to
the mdio node such that it can later on be referenced by label in
board-level DTS files? By that I mean:

mdio: mdio at 18003000 {

Thank you

> 
> 
>>> I find MDIO situation quite simiar. It seems every Northstar board has
>>> MDIO bus
>>> just devices may differ and should not be enabled by default.
>>
>> In which case, the only difference, for you would be to do to, at the
>> board-level DTS:
>>
>> &mdio {
>>     status = "okay";
>>
>>     phy at 0 {
>>         reg = <0>;
>>         ...
>>     };
>> };
>>
>> versus:
>>
>> &mdio {
>>     phy at 0 {
>>         reg = <0>;
>>         ...
>>     };
>> };
>>
>> I think we can afford putting the mdio node's status property in each
>> board-level DTS and make it clear that way that it is enabled because
>> there are child nodes enabled?
> 
> This will be a pretty big effort because every Northstar device I know
> has USB
> 3.0 PHY in the SoC.

Adding a one liner is a "pretty big effort", for sure.

> 
> 
>> NB: with a CONFIG_OF system, there is no automatic probing of MDIO child
>> devices because it relies on child nodes being declared, but you would
>> still get the driver to be probed and enabled, which is a waste of
>> resources at best.
> 
> Right, but DT role is to describe device/board and not really care if
> operating
> system handles that efficiently.


-- 
Florian

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] ARM: dts: BCM5301X: Specify MDIO bus in the DT
  2017-04-19 17:52                     ` Florian Fainelli
@ 2017-04-19 18:10                       ` Rafał Miłecki
  -1 siblings, 0 replies; 18+ messages in thread
From: Rafał Miłecki @ 2017-04-19 18:10 UTC (permalink / raw)
  To: Florian Fainelli, Rafał Miłecki
  Cc: Mark Rutland, devicetree, Hauke Mehrtens, Russell King,
	Rob Herring, bcm-kernel-feedback-list, linux-arm-kernel

On 04/19/2017 07:52 PM, Florian Fainelli wrote:
> On 04/19/2017 10:35 AM, Rafał Miłecki wrote:
>> On 04/19/2017 06:43 PM, Florian Fainelli wrote:
>>> On 04/02/2017 02:25 PM, Rafał Miłecki wrote:
>>>> On 04/02/2017 11:14 PM, Florian Fainelli wrote:
>>>>> Le 04/02/17 à 14:08, Rafał Miłecki a écrit :
>>>>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>>>>
>>>>>> Northstar devices have MDIO bus that may contain various PHYs
>>>>>> attached.
>>>>>> A common example is USB 3.0 PHY (that doesn't have an MDIO driver
>>>>>> yet).
>>>>>>
>>>>>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
>>>>>> ---
>>>>>>  arch/arm/boot/dts/bcm5301x.dtsi | 7 +++++++
>>>>>>  1 file changed, 7 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi
>>>>>> b/arch/arm/boot/dts/bcm5301x.dtsi
>>>>>> index acee36a61004..6a2afe7880ae 100644
>>>>>> --- a/arch/arm/boot/dts/bcm5301x.dtsi
>>>>>> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
>>>>>> @@ -320,6 +320,13 @@
>>>>>>          };
>>>>>>      };
>>>>>>
>>>>>> +    mdio@18003000 {
>>>>>> +        compatible = "brcm,iproc-mdio";
>>>>>> +        reg = <0x18003000 0x8>;
>>>>>> +        #size-cells = <1>;
>>>>>> +        #address-cells = <0>;
>>>>>> +    };
>>>>>
>>>>> This looks fine, but usually the block should be enabled on a per-board
>>>>> basis, such that there should be a status = "disabled" property here by
>>>>> default.
>>>>
>>>> I think we have few blocks in bcm5301x.dtsi enabled by default. I guess
>>>> it's
>>>> for stuff that is always present on every SoC family board: rng, nand,
>>>> spi to
>>>> name few.
>>>>
>>>> It makes some sense, consider e.g. spi. Every Northstar board has SPI
>>>> controller so it's enabled by default. Not every board has SPI flash, so
>>>> it's
>>>> disabled by default.
>>>>
>>>> It's there and it make sense to me. Is that OK or not?
>>>
>>> Even though there are devices that are always enabled on a given SoC,
>>> because the board designs are always consistent does not necessarily
>>> make them good candidates to be enabled at the .dtsi level. This is
>>> particularly true when there are external connections to blocks (SPI,
>>> NAND, USB, Ethernet, MDIO to name a few), having them disabled by
>>> default is safer as a starting point to begin with.
>>
>> In case of Northstar there is USB 3.0 PHY connected *internally* to this
>> MDIO.
>> I don't think any board manufacturer is able to rip SoC out of the MDIO
>> or the
>> USB 3.0 PHY.
>
> OK, then can you still resubmit a proper patch that a) puts that
> information in the commit message, and b) also adds a proper label to
> the mdio node such that it can later on be referenced by label in
> board-level DTS files? By that I mean:
>
> mdio: mdio@18003000 {
>
> Thank you
>
>>
>>
>>>> I find MDIO situation quite simiar. It seems every Northstar board has
>>>> MDIO bus
>>>> just devices may differ and should not be enabled by default.
>>>
>>> In which case, the only difference, for you would be to do to, at the
>>> board-level DTS:
>>>
>>> &mdio {
>>>     status = "okay";
>>>
>>>     phy@0 {
>>>         reg = <0>;
>>>         ...
>>>     };
>>> };
>>>
>>> versus:
>>>
>>> &mdio {
>>>     phy@0 {
>>>         reg = <0>;
>>>         ...
>>>     };
>>> };
>>>
>>> I think we can afford putting the mdio node's status property in each
>>> board-level DTS and make it clear that way that it is enabled because
>>> there are child nodes enabled?
>>
>> This will be a pretty big effort because every Northstar device I know
>> has USB
>> 3.0 PHY in the SoC.
>
> Adding a one liner is a "pretty big effort", for sure.

Sorry, we got a misunderstanding here.

I thought you meant adding something like this for every device:

&mdio {
	status = "okay";

	usb3_phy: usb-phy@10 {
		compatible = "brcm,ns-ax-usb3-phy";
		reg = <0x10>;
		usb3-dmp-syscon = <&usb3_dmp>;
		#phy-cells = <0>;
	};
};

usb3_dmp: syscon@18105000 {
	reg = <0x18105000 0x1000>;
};

So I clearly missed something important. Did you want to have USB 3.0 PHY
defined in the dtsi file?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [PATCH] ARM: dts: BCM5301X: Specify MDIO bus in the DT
@ 2017-04-19 18:10                       ` Rafał Miłecki
  0 siblings, 0 replies; 18+ messages in thread
From: Rafał Miłecki @ 2017-04-19 18:10 UTC (permalink / raw)
  To: linux-arm-kernel

On 04/19/2017 07:52 PM, Florian Fainelli wrote:
> On 04/19/2017 10:35 AM, Rafa? Mi?ecki wrote:
>> On 04/19/2017 06:43 PM, Florian Fainelli wrote:
>>> On 04/02/2017 02:25 PM, Rafa? Mi?ecki wrote:
>>>> On 04/02/2017 11:14 PM, Florian Fainelli wrote:
>>>>> Le 04/02/17 ? 14:08, Rafa? Mi?ecki a ?crit :
>>>>>> From: Rafa? Mi?ecki <rafal@milecki.pl>
>>>>>>
>>>>>> Northstar devices have MDIO bus that may contain various PHYs
>>>>>> attached.
>>>>>> A common example is USB 3.0 PHY (that doesn't have an MDIO driver
>>>>>> yet).
>>>>>>
>>>>>> Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
>>>>>> ---
>>>>>>  arch/arm/boot/dts/bcm5301x.dtsi | 7 +++++++
>>>>>>  1 file changed, 7 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi
>>>>>> b/arch/arm/boot/dts/bcm5301x.dtsi
>>>>>> index acee36a61004..6a2afe7880ae 100644
>>>>>> --- a/arch/arm/boot/dts/bcm5301x.dtsi
>>>>>> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
>>>>>> @@ -320,6 +320,13 @@
>>>>>>          };
>>>>>>      };
>>>>>>
>>>>>> +    mdio at 18003000 {
>>>>>> +        compatible = "brcm,iproc-mdio";
>>>>>> +        reg = <0x18003000 0x8>;
>>>>>> +        #size-cells = <1>;
>>>>>> +        #address-cells = <0>;
>>>>>> +    };
>>>>>
>>>>> This looks fine, but usually the block should be enabled on a per-board
>>>>> basis, such that there should be a status = "disabled" property here by
>>>>> default.
>>>>
>>>> I think we have few blocks in bcm5301x.dtsi enabled by default. I guess
>>>> it's
>>>> for stuff that is always present on every SoC family board: rng, nand,
>>>> spi to
>>>> name few.
>>>>
>>>> It makes some sense, consider e.g. spi. Every Northstar board has SPI
>>>> controller so it's enabled by default. Not every board has SPI flash, so
>>>> it's
>>>> disabled by default.
>>>>
>>>> It's there and it make sense to me. Is that OK or not?
>>>
>>> Even though there are devices that are always enabled on a given SoC,
>>> because the board designs are always consistent does not necessarily
>>> make them good candidates to be enabled at the .dtsi level. This is
>>> particularly true when there are external connections to blocks (SPI,
>>> NAND, USB, Ethernet, MDIO to name a few), having them disabled by
>>> default is safer as a starting point to begin with.
>>
>> In case of Northstar there is USB 3.0 PHY connected *internally* to this
>> MDIO.
>> I don't think any board manufacturer is able to rip SoC out of the MDIO
>> or the
>> USB 3.0 PHY.
>
> OK, then can you still resubmit a proper patch that a) puts that
> information in the commit message, and b) also adds a proper label to
> the mdio node such that it can later on be referenced by label in
> board-level DTS files? By that I mean:
>
> mdio: mdio at 18003000 {
>
> Thank you
>
>>
>>
>>>> I find MDIO situation quite simiar. It seems every Northstar board has
>>>> MDIO bus
>>>> just devices may differ and should not be enabled by default.
>>>
>>> In which case, the only difference, for you would be to do to, at the
>>> board-level DTS:
>>>
>>> &mdio {
>>>     status = "okay";
>>>
>>>     phy at 0 {
>>>         reg = <0>;
>>>         ...
>>>     };
>>> };
>>>
>>> versus:
>>>
>>> &mdio {
>>>     phy at 0 {
>>>         reg = <0>;
>>>         ...
>>>     };
>>> };
>>>
>>> I think we can afford putting the mdio node's status property in each
>>> board-level DTS and make it clear that way that it is enabled because
>>> there are child nodes enabled?
>>
>> This will be a pretty big effort because every Northstar device I know
>> has USB
>> 3.0 PHY in the SoC.
>
> Adding a one liner is a "pretty big effort", for sure.

Sorry, we got a misunderstanding here.

I thought you meant adding something like this for every device:

&mdio {
	status = "okay";

	usb3_phy: usb-phy at 10 {
		compatible = "brcm,ns-ax-usb3-phy";
		reg = <0x10>;
		usb3-dmp-syscon = <&usb3_dmp>;
		#phy-cells = <0>;
	};
};

usb3_dmp: syscon at 18105000 {
	reg = <0x18105000 0x1000>;
};

So I clearly missed something important. Did you want to have USB 3.0 PHY
defined in the dtsi file?

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] ARM: dts: BCM5301X: Specify MDIO bus in the DT
  2017-04-19 18:10                       ` Rafał Miłecki
@ 2017-04-19 18:13                           ` Florian Fainelli
  -1 siblings, 0 replies; 18+ messages in thread
From: Florian Fainelli @ 2017-04-19 18:13 UTC (permalink / raw)
  To: Rafał Miłecki, Florian Fainelli, Rafał Miłecki
  Cc: Hauke Mehrtens, Rob Herring, Mark Rutland, Russell King,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
	devicetree-u79uwXL29TY76Z2rM5mHXA

On 04/19/2017 11:10 AM, Rafał Miłecki wrote:
> On 04/19/2017 07:52 PM, Florian Fainelli wrote:
>> On 04/19/2017 10:35 AM, Rafał Miłecki wrote:
>>> On 04/19/2017 06:43 PM, Florian Fainelli wrote:
>>>> On 04/02/2017 02:25 PM, Rafał Miłecki wrote:
>>>>> On 04/02/2017 11:14 PM, Florian Fainelli wrote:
>>>>>> Le 04/02/17 à 14:08, Rafał Miłecki a écrit :
>>>>>>> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>>>>>>>
>>>>>>> Northstar devices have MDIO bus that may contain various PHYs
>>>>>>> attached.
>>>>>>> A common example is USB 3.0 PHY (that doesn't have an MDIO driver
>>>>>>> yet).
>>>>>>>
>>>>>>> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>>>>>>> ---
>>>>>>>  arch/arm/boot/dts/bcm5301x.dtsi | 7 +++++++
>>>>>>>  1 file changed, 7 insertions(+)
>>>>>>>
>>>>>>> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi
>>>>>>> b/arch/arm/boot/dts/bcm5301x.dtsi
>>>>>>> index acee36a61004..6a2afe7880ae 100644
>>>>>>> --- a/arch/arm/boot/dts/bcm5301x.dtsi
>>>>>>> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
>>>>>>> @@ -320,6 +320,13 @@
>>>>>>>          };
>>>>>>>      };
>>>>>>>
>>>>>>> +    mdio@18003000 {
>>>>>>> +        compatible = "brcm,iproc-mdio";
>>>>>>> +        reg = <0x18003000 0x8>;
>>>>>>> +        #size-cells = <1>;
>>>>>>> +        #address-cells = <0>;
>>>>>>> +    };
>>>>>>
>>>>>> This looks fine, but usually the block should be enabled on a
>>>>>> per-board
>>>>>> basis, such that there should be a status = "disabled" property
>>>>>> here by
>>>>>> default.
>>>>>
>>>>> I think we have few blocks in bcm5301x.dtsi enabled by default. I
>>>>> guess
>>>>> it's
>>>>> for stuff that is always present on every SoC family board: rng, nand,
>>>>> spi to
>>>>> name few.
>>>>>
>>>>> It makes some sense, consider e.g. spi. Every Northstar board has SPI
>>>>> controller so it's enabled by default. Not every board has SPI
>>>>> flash, so
>>>>> it's
>>>>> disabled by default.
>>>>>
>>>>> It's there and it make sense to me. Is that OK or not?
>>>>
>>>> Even though there are devices that are always enabled on a given SoC,
>>>> because the board designs are always consistent does not necessarily
>>>> make them good candidates to be enabled at the .dtsi level. This is
>>>> particularly true when there are external connections to blocks (SPI,
>>>> NAND, USB, Ethernet, MDIO to name a few), having them disabled by
>>>> default is safer as a starting point to begin with.
>>>
>>> In case of Northstar there is USB 3.0 PHY connected *internally* to this
>>> MDIO.
>>> I don't think any board manufacturer is able to rip SoC out of the MDIO
>>> or the
>>> USB 3.0 PHY.
>>
>> OK, then can you still resubmit a proper patch that a) puts that
>> information in the commit message, and b) also adds a proper label to
>> the mdio node such that it can later on be referenced by label in
>> board-level DTS files? By that I mean:
>>
>> mdio: mdio@18003000 {
>>
>> Thank you
>>
>>>
>>>
>>>>> I find MDIO situation quite simiar. It seems every Northstar board has
>>>>> MDIO bus
>>>>> just devices may differ and should not be enabled by default.
>>>>
>>>> In which case, the only difference, for you would be to do to, at the
>>>> board-level DTS:
>>>>
>>>> &mdio {
>>>>     status = "okay";
>>>>
>>>>     phy@0 {
>>>>         reg = <0>;
>>>>         ...
>>>>     };
>>>> };
>>>>
>>>> versus:
>>>>
>>>> &mdio {
>>>>     phy@0 {
>>>>         reg = <0>;
>>>>         ...
>>>>     };
>>>> };
>>>>
>>>> I think we can afford putting the mdio node's status property in each
>>>> board-level DTS and make it clear that way that it is enabled because
>>>> there are child nodes enabled?
>>>
>>> This will be a pretty big effort because every Northstar device I know
>>> has USB
>>> 3.0 PHY in the SoC.
>>
>> Adding a one liner is a "pretty big effort", for sure.
> 
> Sorry, we got a misunderstanding here.
> 
> I thought you meant adding something like this for every device:
> 
> &mdio {
>     status = "okay";
> 
>     usb3_phy: usb-phy@10 {
>         compatible = "brcm,ns-ax-usb3-phy";
>         reg = <0x10>;
>         usb3-dmp-syscon = <&usb3_dmp>;
>         #phy-cells = <0>;
>     };
> };

Ah no, I would have just done the following in the per-board DTS:

&mdio {
	status = "okay";
};

&usb3_phy {
	status = "okay";
};

&xhci {
	status = "okay";
};

Something like that.

> 
> usb3_dmp: syscon@18105000 {
>     reg = <0x18105000 0x1000>;
> };
> 
> So I clearly missed something important. Did you want to have USB 3.0 PHY
> defined in the dtsi file?

Yes, I think it does make sense to have it defined in the .dtsi file
because it's internal to the SoC, however it should probably be marked
disabled by default, unless a board enables its xHCI controller, does
that make sense?
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [PATCH] ARM: dts: BCM5301X: Specify MDIO bus in the DT
@ 2017-04-19 18:13                           ` Florian Fainelli
  0 siblings, 0 replies; 18+ messages in thread
From: Florian Fainelli @ 2017-04-19 18:13 UTC (permalink / raw)
  To: linux-arm-kernel

On 04/19/2017 11:10 AM, Rafa? Mi?ecki wrote:
> On 04/19/2017 07:52 PM, Florian Fainelli wrote:
>> On 04/19/2017 10:35 AM, Rafa? Mi?ecki wrote:
>>> On 04/19/2017 06:43 PM, Florian Fainelli wrote:
>>>> On 04/02/2017 02:25 PM, Rafa? Mi?ecki wrote:
>>>>> On 04/02/2017 11:14 PM, Florian Fainelli wrote:
>>>>>> Le 04/02/17 ? 14:08, Rafa? Mi?ecki a ?crit :
>>>>>>> From: Rafa? Mi?ecki <rafal@milecki.pl>
>>>>>>>
>>>>>>> Northstar devices have MDIO bus that may contain various PHYs
>>>>>>> attached.
>>>>>>> A common example is USB 3.0 PHY (that doesn't have an MDIO driver
>>>>>>> yet).
>>>>>>>
>>>>>>> Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
>>>>>>> ---
>>>>>>>  arch/arm/boot/dts/bcm5301x.dtsi | 7 +++++++
>>>>>>>  1 file changed, 7 insertions(+)
>>>>>>>
>>>>>>> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi
>>>>>>> b/arch/arm/boot/dts/bcm5301x.dtsi
>>>>>>> index acee36a61004..6a2afe7880ae 100644
>>>>>>> --- a/arch/arm/boot/dts/bcm5301x.dtsi
>>>>>>> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
>>>>>>> @@ -320,6 +320,13 @@
>>>>>>>          };
>>>>>>>      };
>>>>>>>
>>>>>>> +    mdio at 18003000 {
>>>>>>> +        compatible = "brcm,iproc-mdio";
>>>>>>> +        reg = <0x18003000 0x8>;
>>>>>>> +        #size-cells = <1>;
>>>>>>> +        #address-cells = <0>;
>>>>>>> +    };
>>>>>>
>>>>>> This looks fine, but usually the block should be enabled on a
>>>>>> per-board
>>>>>> basis, such that there should be a status = "disabled" property
>>>>>> here by
>>>>>> default.
>>>>>
>>>>> I think we have few blocks in bcm5301x.dtsi enabled by default. I
>>>>> guess
>>>>> it's
>>>>> for stuff that is always present on every SoC family board: rng, nand,
>>>>> spi to
>>>>> name few.
>>>>>
>>>>> It makes some sense, consider e.g. spi. Every Northstar board has SPI
>>>>> controller so it's enabled by default. Not every board has SPI
>>>>> flash, so
>>>>> it's
>>>>> disabled by default.
>>>>>
>>>>> It's there and it make sense to me. Is that OK or not?
>>>>
>>>> Even though there are devices that are always enabled on a given SoC,
>>>> because the board designs are always consistent does not necessarily
>>>> make them good candidates to be enabled at the .dtsi level. This is
>>>> particularly true when there are external connections to blocks (SPI,
>>>> NAND, USB, Ethernet, MDIO to name a few), having them disabled by
>>>> default is safer as a starting point to begin with.
>>>
>>> In case of Northstar there is USB 3.0 PHY connected *internally* to this
>>> MDIO.
>>> I don't think any board manufacturer is able to rip SoC out of the MDIO
>>> or the
>>> USB 3.0 PHY.
>>
>> OK, then can you still resubmit a proper patch that a) puts that
>> information in the commit message, and b) also adds a proper label to
>> the mdio node such that it can later on be referenced by label in
>> board-level DTS files? By that I mean:
>>
>> mdio: mdio at 18003000 {
>>
>> Thank you
>>
>>>
>>>
>>>>> I find MDIO situation quite simiar. It seems every Northstar board has
>>>>> MDIO bus
>>>>> just devices may differ and should not be enabled by default.
>>>>
>>>> In which case, the only difference, for you would be to do to, at the
>>>> board-level DTS:
>>>>
>>>> &mdio {
>>>>     status = "okay";
>>>>
>>>>     phy at 0 {
>>>>         reg = <0>;
>>>>         ...
>>>>     };
>>>> };
>>>>
>>>> versus:
>>>>
>>>> &mdio {
>>>>     phy at 0 {
>>>>         reg = <0>;
>>>>         ...
>>>>     };
>>>> };
>>>>
>>>> I think we can afford putting the mdio node's status property in each
>>>> board-level DTS and make it clear that way that it is enabled because
>>>> there are child nodes enabled?
>>>
>>> This will be a pretty big effort because every Northstar device I know
>>> has USB
>>> 3.0 PHY in the SoC.
>>
>> Adding a one liner is a "pretty big effort", for sure.
> 
> Sorry, we got a misunderstanding here.
> 
> I thought you meant adding something like this for every device:
> 
> &mdio {
>     status = "okay";
> 
>     usb3_phy: usb-phy at 10 {
>         compatible = "brcm,ns-ax-usb3-phy";
>         reg = <0x10>;
>         usb3-dmp-syscon = <&usb3_dmp>;
>         #phy-cells = <0>;
>     };
> };

Ah no, I would have just done the following in the per-board DTS:

&mdio {
	status = "okay";
};

&usb3_phy {
	status = "okay";
};

&xhci {
	status = "okay";
};

Something like that.

> 
> usb3_dmp: syscon at 18105000 {
>     reg = <0x18105000 0x1000>;
> };
> 
> So I clearly missed something important. Did you want to have USB 3.0 PHY
> defined in the dtsi file?

Yes, I think it does make sense to have it defined in the .dtsi file
because it's internal to the SoC, however it should probably be marked
disabled by default, unless a board enables its xHCI controller, does
that make sense?
-- 
Florian

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [PATCH V2] ARM: dts: BCM5301X: Specify MDIO bus in the DT
  2017-04-02 21:08 ` Rafał Miłecki
@ 2017-04-19 21:54     ` Rafał Miłecki
  -1 siblings, 0 replies; 18+ messages in thread
From: Rafał Miłecki @ 2017-04-19 21:54 UTC (permalink / raw)
  To: Florian Fainelli
  Cc: Hauke Mehrtens, Rob Herring, Mark Rutland, Russell King,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki

From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>

Northstar devices have MDIO bus that may contain various PHYs attached.
A common example is USB 3.0 PHY (that doesn't have an MDIO driver yet).

Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
V2: Disable MDIO bus by default.
    Add mdio label to allow enabling it easily per board
---
 arch/arm/boot/dts/bcm5301x.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
index acee36a61004..1f34bc6905f2 100644
--- a/arch/arm/boot/dts/bcm5301x.dtsi
+++ b/arch/arm/boot/dts/bcm5301x.dtsi
@@ -320,6 +320,14 @@
 		};
 	};
 
+	mdio: mdio@18003000 {
+		compatible = "brcm,iproc-mdio";
+		reg = <0x18003000 0x8>;
+		#size-cells = <1>;
+		#address-cells = <0>;
+		status = "disabled";
+	};
+
 	i2c0: i2c@18009000 {
 		compatible = "brcm,iproc-i2c";
 		reg = <0x18009000 0x50>;
-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related	[flat|nested] 18+ messages in thread

* [PATCH V2] ARM: dts: BCM5301X: Specify MDIO bus in the DT
@ 2017-04-19 21:54     ` Rafał Miłecki
  0 siblings, 0 replies; 18+ messages in thread
From: Rafał Miłecki @ 2017-04-19 21:54 UTC (permalink / raw)
  To: linux-arm-kernel

From: Rafa? Mi?ecki <rafal@milecki.pl>

Northstar devices have MDIO bus that may contain various PHYs attached.
A common example is USB 3.0 PHY (that doesn't have an MDIO driver yet).

Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
---
V2: Disable MDIO bus by default.
    Add mdio label to allow enabling it easily per board
---
 arch/arm/boot/dts/bcm5301x.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
index acee36a61004..1f34bc6905f2 100644
--- a/arch/arm/boot/dts/bcm5301x.dtsi
+++ b/arch/arm/boot/dts/bcm5301x.dtsi
@@ -320,6 +320,14 @@
 		};
 	};
 
+	mdio: mdio at 18003000 {
+		compatible = "brcm,iproc-mdio";
+		reg = <0x18003000 0x8>;
+		#size-cells = <1>;
+		#address-cells = <0>;
+		status = "disabled";
+	};
+
 	i2c0: i2c at 18009000 {
 		compatible = "brcm,iproc-i2c";
 		reg = <0x18009000 0x50>;
-- 
2.11.0

^ permalink raw reply related	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2017-04-19 21:54 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-04-02 21:08 [PATCH] ARM: dts: BCM5301X: Specify MDIO bus in the DT Rafał Miłecki
2017-04-02 21:08 ` Rafał Miłecki
     [not found] ` <20170402210840.11429-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-04-02 21:14   ` Florian Fainelli
2017-04-02 21:14     ` Florian Fainelli
     [not found]     ` <5a6ecda9-2cf6-2171-7210-6b3a1d4c6012-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-04-02 21:25       ` Rafał Miłecki
2017-04-02 21:25         ` Rafał Miłecki
     [not found]         ` <c3a0455a-821f-d8a8-bf8a-7ad06ad0466e-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
2017-04-19 16:43           ` Florian Fainelli
2017-04-19 16:43             ` Florian Fainelli
     [not found]             ` <94250925-7d5d-ac31-58ad-918406d904f1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-04-19 17:35               ` Rafał Miłecki
2017-04-19 17:35                 ` Rafał Miłecki
     [not found]                 ` <cd324440-ad88-0981-1577-822d39ee289d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-04-19 17:52                   ` Florian Fainelli
2017-04-19 17:52                     ` Florian Fainelli
2017-04-19 18:10                     ` Rafał Miłecki
2017-04-19 18:10                       ` Rafał Miłecki
     [not found]                       ` <ab696d24-3544-a554-82d1-18839b29caa0-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
2017-04-19 18:13                         ` Florian Fainelli
2017-04-19 18:13                           ` Florian Fainelli
2017-04-19 21:54   ` [PATCH V2] " Rafał Miłecki
2017-04-19 21:54     ` Rafał Miłecki

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.