All of lore.kernel.org
 help / color / mirror / Atom feed
From: f.fainelli@gmail.com (Florian Fainelli)
To: linux-snps-arc@lists.infradead.org
Subject: [PATCH] net: phy: dp83867: Fix for automatically detected PHYs
Date: Fri, 3 Feb 2017 10:34:26 -0800	[thread overview]
Message-ID: <9d81d661-de8d-5854-e352-d570bbb3aa43@gmail.com> (raw)
In-Reply-To: <1486143058.2853.27.camel@synopsys.com>

On 02/03/2017 09:30 AM, Alexey Brodkin wrote:
> Hi Andrew,
> 
> On Fri, 2017-02-03@18:10 +0100, Andrew Lunn wrote:
>> On Fri, Feb 03, 2017@07:52:37PM +0300, Alexey Brodkin wrote:
>>>
>>> Current implemntation returns ENODEV if device tree node for
>>> phy is absent. But in reality there're many boards with the one
>>> and only PHY on board and MACs that may find a PHY by querying
>>> MDIO bus. One good example is STMMAC.
>>
>> Humm, not so sure about that. That check for an OF node has always
>> been there, since day one for this driver.
>>
>> What has changed recently is where it looks for these device tree
>> properties. It used to wrongly look in the MAC node. It was changed to
>> look in the PHY node. So this is probably the reason you are having
>> problems.
> 
> Well we don't mention PHY node in our device trees because with
> 1 PHY connected via MDIO bus there's no point in spending electrons
> on adding extra stuff. 

That's a terrible justification, you are running Linux on devices, if
you care about electrons run a tiny RTOS ;)

> Well in case if default settings work fine -
> which up until now was the case for us.

You should really consider listing your Ethernet PHY as a child node of
dwmac MDIO bus because that will be a correct and accurate
representation of the hardware, and if the PHY driver needs specific
properties to be given (e.g: random TX/RX delays, etc.) that is the only
way you could communicate those properly to the PHY driver.

> 
> Just in case that's a typical example:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arc/boot/dts/axs10x_mb.dtsi#n58
> 
> ----------------------->8-----------------------
> 	ethernet at 0x18000 {
> 		#interrupt-cells = <1>;
> 		compatible = "snps,dwmac";
> 		reg = < 0x18000 0x2000 >;
> 		interrupts = < 4 >;
> 		interrupt-names = "macirq";
> 		phy-mode = "rgmii";
> 		snps,pbl = < 32 >;
> 		clocks = <&apbclk>;
> 		clock-names = "stmmaceth";
> 		max-speed = <100>;
> 	};
> ----------------------->8-----------------------
> 
> This is especially nice because we may change the base-board and use
> there another PHY and as long we have drivers for all possible PHY built
> in the kernel (or available via modules) proper driver will be instantiated
> based on PHY ID read from MDIO. I.e. having no PHY node in DT adds flexibility.

The of_mdio code can automatically scan PHYs on the bus, and try to
associate them with a proper Device Tree node reference, would that
exist, but this is really fragile.
-- 
Florian

WARNING: multiple messages have this Message-ID (diff)
From: Florian Fainelli <f.fainelli@gmail.com>
To: Alexey Brodkin <Alexey.Brodkin@synopsys.com>,
	"andrew@lunn.ch" <andrew@lunn.ch>
Cc: "nsekhar@ti.com" <nsekhar@ti.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"m-karicheri2@ti.com" <m-karicheri2@ti.com>,
	"linux-snps-arc@lists.infradead.org" 
	<linux-snps-arc@lists.infradead.org>,
	"grygorii.strashko@ti.com" <grygorii.strashko@ti.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: [PATCH] net: phy: dp83867: Fix for automatically detected PHYs
Date: Fri, 3 Feb 2017 10:34:26 -0800	[thread overview]
Message-ID: <9d81d661-de8d-5854-e352-d570bbb3aa43@gmail.com> (raw)
In-Reply-To: <1486143058.2853.27.camel@synopsys.com>

On 02/03/2017 09:30 AM, Alexey Brodkin wrote:
> Hi Andrew,
> 
> On Fri, 2017-02-03 at 18:10 +0100, Andrew Lunn wrote:
>> On Fri, Feb 03, 2017 at 07:52:37PM +0300, Alexey Brodkin wrote:
>>>
>>> Current implemntation returns ENODEV if device tree node for
>>> phy is absent. But in reality there're many boards with the one
>>> and only PHY on board and MACs that may find a PHY by querying
>>> MDIO bus. One good example is STMMAC.
>>
>> Humm, not so sure about that. That check for an OF node has always
>> been there, since day one for this driver.
>>
>> What has changed recently is where it looks for these device tree
>> properties. It used to wrongly look in the MAC node. It was changed to
>> look in the PHY node. So this is probably the reason you are having
>> problems.
> 
> Well we don't mention PHY node in our device trees because with
> 1 PHY connected via MDIO bus there's no point in spending electrons
> on adding extra stuff. 

That's a terrible justification, you are running Linux on devices, if
you care about electrons run a tiny RTOS ;)

> Well in case if default settings work fine -
> which up until now was the case for us.

You should really consider listing your Ethernet PHY as a child node of
dwmac MDIO bus because that will be a correct and accurate
representation of the hardware, and if the PHY driver needs specific
properties to be given (e.g: random TX/RX delays, etc.) that is the only
way you could communicate those properly to the PHY driver.

> 
> Just in case that's a typical example:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arc/boot/dts/axs10x_mb.dtsi#n58
> 
> ----------------------->8-----------------------
> 	ethernet@0x18000 {
> 		#interrupt-cells = <1>;
> 		compatible = "snps,dwmac";
> 		reg = < 0x18000 0x2000 >;
> 		interrupts = < 4 >;
> 		interrupt-names = "macirq";
> 		phy-mode = "rgmii";
> 		snps,pbl = < 32 >;
> 		clocks = <&apbclk>;
> 		clock-names = "stmmaceth";
> 		max-speed = <100>;
> 	};
> ----------------------->8-----------------------
> 
> This is especially nice because we may change the base-board and use
> there another PHY and as long we have drivers for all possible PHY built
> in the kernel (or available via modules) proper driver will be instantiated
> based on PHY ID read from MDIO. I.e. having no PHY node in DT adds flexibility.

The of_mdio code can automatically scan PHYs on the bus, and try to
associate them with a proper Device Tree node reference, would that
exist, but this is really fragile.
-- 
Florian

  parent reply	other threads:[~2017-02-03 18:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-03 16:52 [PATCH] net: phy: dp83867: Fix for automatically detected PHYs Alexey Brodkin
2017-02-03 16:52 ` Alexey Brodkin
2017-02-03 17:10 ` Andrew Lunn
2017-02-03 17:10   ` Andrew Lunn
2017-02-03 17:30   ` Alexey Brodkin
2017-02-03 17:30     ` Alexey Brodkin
2017-02-03 17:54     ` Andrew Lunn
2017-02-03 17:54       ` Andrew Lunn
2017-02-03 18:34     ` Florian Fainelli [this message]
2017-02-03 18:34       ` Florian Fainelli
2017-02-06 19:16       ` Alexey Brodkin
2017-02-06 19:16         ` Alexey Brodkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9d81d661-de8d-5854-e352-d570bbb3aa43@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=linux-snps-arc@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.