* [PATCH] net: phy: dp83867: Fix for automatically detected PHYs @ 2017-02-03 16:52 ` Alexey Brodkin 0 siblings, 0 replies; 12+ messages in thread From: Alexey Brodkin @ 2017-02-03 16:52 UTC (permalink / raw) To: linux-snps-arc 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. So that's what I saw: --- Booing --------------->8------------------------- libphy: Fixed MDIO Bus: probed stmmaceth f0008000.ethernet: no reset control found stmmac - user ID: 0x10, Synopsys ID: 0x37 stmmaceth f0008000.ethernet: Ring mode enabled stmmaceth f0008000.ethernet: DMA HW capability register supported stmmaceth f0008000.ethernet: Normal descriptors stmmaceth f0008000.ethernet: RX Checksum Offload Engine supported stmmaceth f0008000.ethernet: COE Type 2 stmmaceth f0008000.ethernet: TX Checksum insertion supported stmmaceth f0008000.ethernet: Enable RX Mitigation via HW Watchdog Timer libphy: stmmac: probed stmmaceth f0008000.ethernet (unnamed net_device) (uninitialized): PHY ID 2000a231 at 0 IRQ POLL (stmmac-0:00) active --- Bringing up eth0 ----->8------------------------- Starting network: stmmaceth f0008000.ethernet eth0: device MAC address b6:43:6b:1d:50:cf stmmaceth f0008000.ethernet eth0: Could not attach to PHY stmmaceth f0008000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) ip: SIOCSIFFLAGS: No such device -------------------------->8------------------------- Note PHY is detected properly but right after that we're getting -ENODEV. That makes no sense at all. So let's silently exit with 0 if there's no DT node for the PHY. That's what I'm seeing now: -------------------------->8------------------------- Starting network: stmmaceth f0008000.ethernet eth0: device MAC address de:1f:a9:f7:8d:88 stmmaceth f0008000.ethernet eth0: fail to init PTP. IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready udhcpc: started, v1.25.1 udhcpc: sending discover udhcpc: sending discover stmmaceth f0008000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready udhcpc: sending discover Link is Up - 100/Full udhcpc: sending select for x.x.x.x udhcpc: lease of x.x.x.x obtained, lease time 3600 deleting routers adding dns x.x.x.x -------------------------->8------------------------- Signed-off-by: Alexey Brodkin <abrodkin at synopsys.com> Cc: Murali Karicheri <m-karicheri2 at ti.com> Cc: Sekhar Nori <nsekhar at ti.com> Cc: David S. Miller <davem at davemloft.net> Cc: Grygorii Strashko <grygorii.strashko at ti.com> Cc: Florian Fainelli <f.fainelli at gmail.com> Cc: Mugunthan V N <mugunthanvnm at ti.com> Cc: Andrew Lunn <andrew at lunn.ch> --- drivers/net/phy/dp83867.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c index ca1b462..c44259b 100644 --- a/drivers/net/phy/dp83867.c +++ b/drivers/net/phy/dp83867.c @@ -120,7 +120,7 @@ static int dp83867_of_init(struct phy_device *phydev) int ret; if (!of_node) - return -ENODEV; + return 0; dp83867->io_impedance = -EINVAL; -- 2.10.2 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH] net: phy: dp83867: Fix for automatically detected PHYs @ 2017-02-03 16:52 ` Alexey Brodkin 0 siblings, 0 replies; 12+ messages in thread From: Alexey Brodkin @ 2017-02-03 16:52 UTC (permalink / raw) To: netdev Cc: linux-snps-arc, linux-kernel, Alexey Brodkin, Murali Karicheri, Sekhar Nori, David S . Miller, Grygorii Strashko, Florian Fainelli, Mugunthan V N, Andrew Lunn 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. So that's what I saw: --- Booing --------------->8------------------------- libphy: Fixed MDIO Bus: probed stmmaceth f0008000.ethernet: no reset control found stmmac - user ID: 0x10, Synopsys ID: 0x37 stmmaceth f0008000.ethernet: Ring mode enabled stmmaceth f0008000.ethernet: DMA HW capability register supported stmmaceth f0008000.ethernet: Normal descriptors stmmaceth f0008000.ethernet: RX Checksum Offload Engine supported stmmaceth f0008000.ethernet: COE Type 2 stmmaceth f0008000.ethernet: TX Checksum insertion supported stmmaceth f0008000.ethernet: Enable RX Mitigation via HW Watchdog Timer libphy: stmmac: probed stmmaceth f0008000.ethernet (unnamed net_device) (uninitialized): PHY ID 2000a231 at 0 IRQ POLL (stmmac-0:00) active --- Bringing up eth0 ----->8------------------------- Starting network: stmmaceth f0008000.ethernet eth0: device MAC address b6:43:6b:1d:50:cf stmmaceth f0008000.ethernet eth0: Could not attach to PHY stmmaceth f0008000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) ip: SIOCSIFFLAGS: No such device -------------------------->8------------------------- Note PHY is detected properly but right after that we're getting -ENODEV. That makes no sense at all. So let's silently exit with 0 if there's no DT node for the PHY. That's what I'm seeing now: -------------------------->8------------------------- Starting network: stmmaceth f0008000.ethernet eth0: device MAC address de:1f:a9:f7:8d:88 stmmaceth f0008000.ethernet eth0: fail to init PTP. IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready udhcpc: started, v1.25.1 udhcpc: sending discover udhcpc: sending discover stmmaceth f0008000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready udhcpc: sending discover Link is Up - 100/Full udhcpc: sending select for x.x.x.x udhcpc: lease of x.x.x.x obtained, lease time 3600 deleting routers adding dns x.x.x.x -------------------------->8------------------------- Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Murali Karicheri <m-karicheri2@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Cc: David S. Miller <davem@davemloft.net> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Mugunthan V N <mugunthanvnm@ti.com> Cc: Andrew Lunn <andrew@lunn.ch> --- drivers/net/phy/dp83867.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c index ca1b462..c44259b 100644 --- a/drivers/net/phy/dp83867.c +++ b/drivers/net/phy/dp83867.c @@ -120,7 +120,7 @@ static int dp83867_of_init(struct phy_device *phydev) int ret; if (!of_node) - return -ENODEV; + return 0; dp83867->io_impedance = -EINVAL; -- 2.10.2 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH] net: phy: dp83867: Fix for automatically detected PHYs 2017-02-03 16:52 ` Alexey Brodkin @ 2017-02-03 17:10 ` Andrew Lunn -1 siblings, 0 replies; 12+ messages in thread From: Andrew Lunn @ 2017-02-03 17:10 UTC (permalink / raw) To: linux-snps-arc 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. Having said that, your patch looks O.K. Reviewed-by: Andrew Lunn <andrew at lunn.ch> Andrew ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] net: phy: dp83867: Fix for automatically detected PHYs @ 2017-02-03 17:10 ` Andrew Lunn 0 siblings, 0 replies; 12+ messages in thread From: Andrew Lunn @ 2017-02-03 17:10 UTC (permalink / raw) To: Alexey Brodkin Cc: netdev, linux-snps-arc, linux-kernel, Murali Karicheri, Sekhar Nori, David S . Miller, Grygorii Strashko, Florian Fainelli, Mugunthan V N 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. Having said that, your patch looks O.K. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Andrew ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] net: phy: dp83867: Fix for automatically detected PHYs 2017-02-03 17:10 ` Andrew Lunn @ 2017-02-03 17:30 ` Alexey Brodkin -1 siblings, 0 replies; 12+ messages in thread From: Alexey Brodkin @ 2017-02-03 17:30 UTC (permalink / raw) To: linux-snps-arc 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. Well in case if default settings work fine - which up until now was the case for us. 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. -Alexey ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] net: phy: dp83867: Fix for automatically detected PHYs @ 2017-02-03 17:30 ` Alexey Brodkin 0 siblings, 0 replies; 12+ messages in thread From: Alexey Brodkin @ 2017-02-03 17:30 UTC (permalink / raw) To: andrew@lunn.ch Cc: nsekhar@ti.com, linux-kernel@vger.kernel.org, m-karicheri2@ti.com, linux-snps-arc@lists.infradead.org, grygorii.strashko@ti.com, f.fainelli@gmail.com, netdev@vger.kernel.org, davem@davemloft.net 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. Well in case if default settings work fine - which up until now was the case for us. 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. -Alexey ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] net: phy: dp83867: Fix for automatically detected PHYs 2017-02-03 17:30 ` Alexey Brodkin @ 2017-02-03 17:54 ` Andrew Lunn -1 siblings, 0 replies; 12+ messages in thread From: Andrew Lunn @ 2017-02-03 17:54 UTC (permalink / raw) To: linux-snps-arc > 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 device tree node does not prevent this. It will still load the driver based on the PHY ID in the PHY. You might run into problems if the address on the MDIO bus changes, but it is also possible to not have a reg property, and it will match the node to whatever PHY it finds during the scan of the bus. Andrew ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] net: phy: dp83867: Fix for automatically detected PHYs @ 2017-02-03 17:54 ` Andrew Lunn 0 siblings, 0 replies; 12+ messages in thread From: Andrew Lunn @ 2017-02-03 17:54 UTC (permalink / raw) To: Alexey Brodkin Cc: nsekhar@ti.com, linux-kernel@vger.kernel.org, m-karicheri2@ti.com, linux-snps-arc@lists.infradead.org, grygorii.strashko@ti.com, f.fainelli@gmail.com, netdev@vger.kernel.org, davem@davemloft.net > 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 device tree node does not prevent this. It will still load the driver based on the PHY ID in the PHY. You might run into problems if the address on the MDIO bus changes, but it is also possible to not have a reg property, and it will match the node to whatever PHY it finds during the scan of the bus. Andrew ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] net: phy: dp83867: Fix for automatically detected PHYs 2017-02-03 17:30 ` Alexey Brodkin @ 2017-02-03 18:34 ` Florian Fainelli -1 siblings, 0 replies; 12+ messages in thread From: Florian Fainelli @ 2017-02-03 18:34 UTC (permalink / raw) To: linux-snps-arc 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] net: phy: dp83867: Fix for automatically detected PHYs @ 2017-02-03 18:34 ` Florian Fainelli 0 siblings, 0 replies; 12+ messages in thread From: Florian Fainelli @ 2017-02-03 18:34 UTC (permalink / raw) To: Alexey Brodkin, andrew@lunn.ch Cc: nsekhar@ti.com, linux-kernel@vger.kernel.org, m-karicheri2@ti.com, linux-snps-arc@lists.infradead.org, grygorii.strashko@ti.com, netdev@vger.kernel.org, davem@davemloft.net 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] net: phy: dp83867: Fix for automatically detected PHYs 2017-02-03 18:34 ` Florian Fainelli @ 2017-02-06 19:16 ` Alexey Brodkin -1 siblings, 0 replies; 12+ messages in thread From: Alexey Brodkin @ 2017-02-06 19:16 UTC (permalink / raw) To: linux-snps-arc Hi Florian, all, On Fri, 2017-02-03@10:34 -0800, Florian Fainelli wrote: > 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 ;) Agree :) > > > > 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. Agree here as well, indeed I'm going to update my .dts because that is supposed to reflect real HW and it will be that way. But still I'm wondering if that's a must? In that case we need to update drivers for other PHYs and probably start from the genphy to align requirements. Otherwise poor guys like me who switched from one PHY to another will end up frustrating why stuff that used to work no longer works :) -Alexey ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] net: phy: dp83867: Fix for automatically detected PHYs @ 2017-02-06 19:16 ` Alexey Brodkin 0 siblings, 0 replies; 12+ messages in thread From: Alexey Brodkin @ 2017-02-06 19:16 UTC (permalink / raw) To: f.fainelli@gmail.com Cc: andrew@lunn.ch, linux-kernel@vger.kernel.org, nsekhar@ti.com, m-karicheri2@ti.com, linux-snps-arc@lists.infradead.org, grygorii.strashko@ti.com, netdev@vger.kernel.org, davem@davemloft.net Hi Florian, all, On Fri, 2017-02-03 at 10:34 -0800, Florian Fainelli wrote: > 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 ;) Agree :) > > > > 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. Agree here as well, indeed I'm going to update my .dts because that is supposed to reflect real HW and it will be that way. But still I'm wondering if that's a must? In that case we need to update drivers for other PHYs and probably start from the genphy to align requirements. Otherwise poor guys like me who switched from one PHY to another will end up frustrating why stuff that used to work no longer works :) -Alexey ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2017-02-06 19:16 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 2017-02-03 18:34 ` Florian Fainelli 2017-02-06 19:16 ` Alexey Brodkin 2017-02-06 19:16 ` Alexey Brodkin
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.