Re: [PATCH AUTOSEL 5.8 08/29] net: dsa: microchip: look for phy-mode in port nodes

2020-09-28 Thread Helmut Grohne
Hi Sascha, On Tue, Sep 29, 2020 at 03:30:05AM +0200, Sasha Levin wrote: > From: Helmut Grohne > > [ Upstream commit edecfa98f602a597666e3c5cab2677ada38d93c5 ] > > Documentation/devicetree/bindings/net/dsa/dsa.txt says that the phy-mode > property should be specified on port n

[PATCH] net: dsa: microchip: really look for phy-mode in port nodes

2020-09-24 Thread Helmut Grohne
The previous implementation failed to account for the "ports" node. The actual port nodes are not child nodes of the switch node, but a "ports" node sits in between. Fixes: edecfa98f602 ("net: dsa: microchip: look for phy-mode in port nodes") Signed-off-by: Helmu

[PATCH v3] net: dsa: microchip: look for phy-mode in port nodes

2020-09-08 Thread Helmut Grohne
-off-by: Helmut Grohne Link: https://lore.kernel.org/netdev/20200617082235.GA1523@laureti-dev/ Acked-by: Alexandre Belloni --- arch/arm/boot/dts/at91-sama5d2_icp.dts | 2 +- drivers/net/dsa/microchip/ksz8795.c| 18 +++- drivers/net/dsa/microchip/ksz9477.c| 29

Re: [PATCH v2] net: dsa: microchip: look for phy-mode in port nodes

2020-09-06 Thread Helmut Grohne
Hi Andrew, On Fri, Sep 04, 2020 at 03:52:55PM +0200, Andrew Lunn wrote: > > + dev_warn(dev->dev, > > +"Using legacy switch \"phy-mode\" missing on > > port %d node. Please update your device tree.\n", This is inside ksz8795_port_setup. > That messag

[PATCH v2] net: dsa: microchip: look for phy-mode in port nodes

2020-09-04 Thread Helmut Grohne
-off-by: Helmut Grohne Link: https://lore.kernel.org/netdev/20200617082235.GA1523@laureti-dev/ --- arch/arm/boot/dts/at91-sama5d2_icp.dts | 2 +- drivers/net/dsa/microchip/ksz8795.c| 17 +++- drivers/net/dsa/microchip/ksz9477.c| 28 +- drivers/net/dsa

[RESEND PATCH] net: dsa: microchip: look for phy-mode in port nodes

2020-08-19 Thread Helmut Grohne
-off-by: Helmut Grohne Link: https://lore.kernel.org/netdev/20200617082235.GA1523@laureti-dev/ --- arch/arm/boot/dts/at91-sama5d2_icp.dts | 2 +- drivers/net/dsa/microchip/ksz8795.c| 17 +++- drivers/net/dsa/microchip/ksz9477.c| 28 +- drivers/net/dsa

Re: [PATCH v2 0/6] net: dsa: microchip: delete dead code

2020-08-18 Thread Helmut Grohne
Hi Florian, On Mon, Aug 17, 2020 at 08:18:41AM -0700, Florian Fainelli wrote: > net-next is currently closed at the moment, and these patches are clearly > targeted at that tree: I agree that these are clearly net-next material. > http://vger.kernel.org/~davem/net-next.html It says "Come in we'

[PATCH v2 6/6] net: dsa: microchip: delete unused member ksz_device.overrides

2020-08-17 Thread Helmut Grohne
Link: https://lore.kernel.org/netdev/20200721083300.GA12970@laureti-dev/ Signed-off-by: Helmut Grohne --- drivers/net/dsa/microchip/ksz_common.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/dsa/microchip/ksz_common.h b/drivers/net/dsa/microchip/ksz_common.h index 0120f2b72091

[PATCH v2 5/6] net: dsa: microchip: delete unused member ksz_device.regs_size

2020-08-17 Thread Helmut Grohne
Link: https://lore.kernel.org/netdev/20200721083300.GA12970@laureti-dev/ Signed-off-by: Helmut Grohne --- drivers/net/dsa/microchip/ksz_common.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/dsa/microchip/ksz_common.h b/drivers/net/dsa/microchip/ksz_common.h index 1791442f04ee

[PATCH v2 3/6] net: dsa: microchip: delete unused member ksz_port.force

2020-08-17 Thread Helmut Grohne
Link: https://lore.kernel.org/netdev/20200721083300.GA12970@laureti-dev/ Signed-off-by: Helmut Grohne --- drivers/net/dsa/microchip/ksz_common.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/dsa/microchip/ksz_common.h b/drivers/net/dsa/microchip/ksz_common.h index 83247140b784

[PATCH v2 0/6] net: dsa: microchip: delete dead code

2020-08-17 Thread Helmut Grohne
=b20a6b29a811bee0e44b64958d415eb50436154c All other structure members are read at least once. Helmut Helmut Grohne (6): net: dsa: microchip: delete unused member ksz_port.phy net: dsa: microchip: delete unused member ksz_port.sgmii net: dsa: microchip: delete unused member ksz_port.force net: dsa: microchip: delete

[PATCH v2 1/6] net: dsa: microchip: delete unused member ksz_port.phy

2020-08-17 Thread Helmut Grohne
Link: https://lore.kernel.org/netdev/20200721083300.GA12970@laureti-dev/ Signed-off-by: Helmut Grohne --- drivers/net/dsa/microchip/ksz8795.c| 1 - drivers/net/dsa/microchip/ksz9477.c| 8 +--- drivers/net/dsa/microchip/ksz_common.h | 1 - 3 files changed, 1 insertion(+), 9 deletions

[PATCH v2 2/6] net: dsa: microchip: delete unused member ksz_port.sgmii

2020-08-17 Thread Helmut Grohne
Link: https://lore.kernel.org/netdev/20200721083300.GA12970@laureti-dev/ Signed-off-by: Helmut Grohne --- drivers/net/dsa/microchip/ksz9477.c| 2 -- drivers/net/dsa/microchip/ksz_common.h | 1 - 2 files changed, 3 deletions(-) diff --git a/drivers/net/dsa/microchip/ksz9477.c b/drivers/net

[PATCH v2 4/6] net: dsa: microchip: delete unused member ksz_device.last_port

2020-08-17 Thread Helmut Grohne
Link: https://lore.kernel.org/netdev/20200721083300.GA12970@laureti-dev/ Signed-off-by: Helmut Grohne --- drivers/net/dsa/microchip/ksz8795.c| 1 - drivers/net/dsa/microchip/ksz_common.h | 1 - 2 files changed, 2 deletions(-) diff --git a/drivers/net/dsa/microchip/ksz8795.c b/drivers/net

Re: [RFC PATCH] net: dsa: microchip: delete dead code

2020-07-22 Thread Helmut Grohne
Hi Andrew, On Wed, Jul 22, 2020 at 04:39:53PM +0200, Andrew Lunn wrote: > This patch probably is correct. But it is not obviously correct, > because there are so many changes at once. Please could you break it > up. >From my pov, it is less a question of whether it is correct, but whether it goes

[PATCH v4] net: dsa: microchip: call phy_remove_link_mode during probe

2020-07-21 Thread Helmut Grohne
2fc6a4c613019 ("net: dsa: microchip: prepare PHY for proper advertisement") Signed-off-by: Helmut Grohne --- drivers/net/dsa/microchip/ksz9477.c| 42 ++ drivers/net/dsa/microchip/ksz_common.c | 2 -- drivers/net/dsa/microchip/ksz_common.h | 2 -- 3 files

[RFC PATCH] net: dsa: microchip: delete dead code

2020-07-21 Thread Helmut Grohne
None of the removed assignments is ever read back and never influences logic. Signed-off-by: Helmut Grohne --- drivers/net/dsa/microchip/ksz8795.c| 26 ++ drivers/net/dsa/microchip/ksz9477.c| 30 +- drivers/net/dsa/microchip/ksz_common.c | 23

Re: [PATCH v3] net: dsa: microchip: call phy_remove_link_mode during probe

2020-07-21 Thread Helmut Grohne
Hi Andrew, Your persistence on this matter is much appreciated. On Mon, Jul 20, 2020 at 11:04:49PM +0200, Andrew Lunn wrote: > > The dev->ports[i].phydev is not actually exposed beyond the driver. The > > driver sets the phydev.speed in a few places and even reads it back in > > one place. It als

[PATCH v3] net: dsa: microchip: call phy_remove_link_mode during probe

2020-07-20 Thread Helmut Grohne
2fc6a4c613019 ("net: dsa: microchip: prepare PHY for proper advertisement") Signed-off-by: Helmut Grohne --- drivers/net/dsa/microchip/ksz9477.c| 39 +- drivers/net/dsa/microchip/ksz_common.c | 2 -- drivers/net/dsa/microchip/ksz_common.h | 2 -- 3 files

Re: [PATCH v2] net: dsa: microchip: call phy_remove_link_mode during probe

2020-07-17 Thread Helmut Grohne
On Thu, Jul 16, 2020 at 04:10:44PM +0200, Andrew Lunn wrote: > However, i'm having trouble understanding how PHYs actually work in > this driver. > > We have: > > struct ksz_port { > u16 member; > u16 vid_member; > int stp_state; > struct phy_device phydev; > > w

[PATCH v2] net: dsa: microchip: call phy_remove_link_mode during probe

2020-07-16 Thread Helmut Grohne
omes after ksz9477_switch_detect, which initializes dev->features. Remove phy_setup from ksz_dev_ops as no users remain. Link: https://lore.kernel.org/netdev/20200715192722.gd1256...@lunn.ch/ Fixes: 42fc6a4c613019 ("net: dsa: microchip: prepare PHY for proper advertisement") Signe

Re: [PATCH] net: dsa: microchip: look for phy-mode in port nodes

2020-07-16 Thread Helmut Grohne
On Thu, Jul 16, 2020 at 09:00:00AM +0200, Helmut Grohne wrote: > I've prepared a patch based one the one-CPU-port assumption. It really > becomes way simpler that way. I'd like to give it a little more testing > before sending it. I'm sorry, but it is not that simple.

Re: [PATCH] net: dsa: microchip: look for phy-mode in port nodes

2020-07-16 Thread Helmut Grohne
On Wed, Jul 15, 2020 at 03:00:46PM +0200, Andrew Lunn wrote: > On Wed, Jul 15, 2020 at 09:31:12AM +0200, Helmut Grohne wrote: > > You seem to be in favour of more deeply encoding the "there can be only > > one CPU port" assumption. Based on that assumption, the rest of

Re: [PATCH] net: dsa: microchip: look for phy-mode in port nodes

2020-07-15 Thread Helmut Grohne
Hi Andrew, Thank you for the quick reply. On Wed, Jul 15, 2020 at 12:27:16AM +0200, Andrew Lunn wrote: > I think this change is more complex than it needs to be. Only the CPU > port supports different interface modes. So i don't see the need to > handle both dev->interface and p->interface. Just

Re: [PATCH] net: phy: phy_remove_link_mode should not advertise new modes

2020-07-15 Thread Helmut Grohne
On Tue, Jul 14, 2020 at 11:07:10PM +0200, David Miller wrote: > From: Helmut Grohne > Date: Tue, 14 Jul 2020 10:25:42 +0200 > > > When doing "ip link set dev ... up" for a ksz9477 backed link, > > ksz9477_phy_setup is called and it calls phy_remove_link_mode to r

[PATCH] net: dsa: microchip: look for phy-mode in port nodes

2020-07-14 Thread Helmut Grohne
-off-by: Helmut Grohne Link: https://lore.kernel.org/netdev/20200617082235.GA1523@laureti-dev/ --- arch/arm/boot/dts/at91-sama5d2_icp.dts | 2 +- drivers/net/dsa/microchip/ksz8795.c| 17 +++- drivers/net/dsa/microchip/ksz9477.c| 28 +- drivers/net/dsa

[PATCH] net: phy: phy_remove_link_mode should not advertise new modes

2020-07-14 Thread Helmut Grohne
ode enable advertising bits and it does not match its description in any way. Instead of calling phy_advertise_supported, we should simply clear the link mode to be removed from both supported and advertising. Signed-off-by: Helmut Grohne Fixes: 41124fa64d4b29 ("net: ethernet: Add helper to rem

[PATCH] net: dsa: microchip: enable ksz9893 via i2c in the ksz9477 driver

2020-07-01 Thread Helmut Grohne
The KSZ9893 3-Port Gigabit Ethernet Switch can be controlled via SPI, I²C or MDIO (very limited and not supported by this driver). While there is already a compatible entry for the SPI bus, it was missing for I²C. Signed-off-by: Helmut Grohne --- drivers/net/dsa/microchip/ksz9477_i2c.c | 1 + 1

Re: [PATCH] net: macb: reject unsupported rgmii delays

2020-06-18 Thread Helmut Grohne
On Thu, Jun 18, 2020 at 10:45:54AM +0200, Russell King - ARM Linux admin wrote: > Why do we need that complexity? If we decide that we can allow > phy-mode = "rgmii" and introduce new properties to control the > delay, then we just need: > > rgmii-tx-delay-ps = ; > rgmii-rx-delay-ps = ; > >

Re: [PATCH] net: macb: reject unsupported rgmii delays

2020-06-18 Thread Helmut Grohne
On Wed, Jun 17, 2020 at 02:08:09PM +0200, Russell King - ARM Linux admin wrote: > With a fixed link, we could be in either a MAC-to-PHY or MAC-to-MAC > setup; we just don't know. However, we don't have is access to the > PHY (if it exists) in the fixed link case to configure it for the > delay. L

Re: [PATCH] net: macb: reject unsupported rgmii delays

2020-06-17 Thread Helmut Grohne
On Wed, Jun 17, 2020 at 01:40:25PM +0200, Russell King - ARM Linux admin wrote: > > For a fixed-link, the validation function is never called. Therefore, it > > cannot reject PHY_INTERFACE_MODE_RGMII. It works in practice. > > Hmm, I'm not so sure, but then I don't know exactly what code you're >

Re: [PATCH] net: macb: reject unsupported rgmii delays

2020-06-17 Thread Helmut Grohne
On Wed, Jun 17, 2020 at 12:55:18PM +0200, Russell King - ARM Linux admin wrote: > The individual RGMII delay modes are more about what the PHY itself is > asked to do with respect to inserting delays, so I don't think your > patch makes sense. This seems to be the same aspect that Vladimir Oltean

Re: [PATCH] net: macb: reject unsupported rgmii delays

2020-06-17 Thread Helmut Grohne
Hi Vladimir, On Wed, Jun 17, 2020 at 11:57:23AM +0200, Vladimir Oltean wrote: > On Tue, 16 Jun 2020 at 11:00, Helmut Grohne wrote: > > --- a/drivers/net/ethernet/cadence/macb_main.c > > +++ b/drivers/net/ethernet/cadence/macb_main.c > > @@ -514,7 +514,7 @@ static void

net/dsa/microchip: correct placement of dt property phy-mode?

2020-06-17 Thread Helmut Grohne
Hi, According to Documentation/devicetree/bindings/net/dsa/dsa.txt, the phy-mode property should be specified on port nodes rather than the enclosing switch node. In drivers/net/dsa/microchip/ksz_common.c, ksz_switch_register parses the phy-mode property from the switch node instead: | int ksz_sw

[PATCH] net: macb: reject unsupported rgmii delays

2020-06-16 Thread Helmut Grohne
/ Signed-off-by: Helmut Grohne --- drivers/net/ethernet/cadence/macb_main.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c index 5b9d7c60eebc..bee5bf65e8b3 100644 --- a/drivers/net/ethernet

Re: correct use of PHY_INTERFACE_MODE_RGMII{,_TXID,_RXID,_ID}

2020-06-10 Thread Helmut Grohne
Hi Ioana, On Wed, Jun 10, 2020 at 11:10:23AM +0200, Ioana Ciornei wrote: > > freescale/dpaa2/dpaa2-mac.c is interesting. It checks whether any rgmii mode > > other than PHY_INTERFACE_MODE_RGMII is used and complains that delays are > > not supported in that case. The above comment says that the MA

correct use of PHY_INTERFACE_MODE_RGMII{,_TXID,_RXID,_ID}

2020-06-10 Thread Helmut Grohne
Hi, I've been trying to write a dt for a board and got quite confused about the RGMII delays. That's why I looked into it and got even more confused by what I found. Different drivers handle this quite differently. Let me summarize. Some drivers handle the RGMII modes individually. This is how I