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
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
-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
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
-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
-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
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'
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
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
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
=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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
-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
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
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
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 = ;
>
>
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
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
>
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
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
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
/
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
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
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
37 matches
Mail list logo