lkml.org 
[lkml]   [2022]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [PATCH net-next v2 1/1] net: dsa: microchip: ksz9477: implement MTU configuration
On Thu, Feb 24, 2022 at 01:38:33AM +0200, Vladimir Oltean wrote:
> On Wed, Feb 23, 2022 at 09:40:55AM +0100, Oleksij Rempel wrote:
> > This chips supports two ways to configure max MTU size:
> > - by setting SW_LEGAL_PACKET_DISABLE bit: if this bit is 0 allowed packed size
> > will be between 64 and bytes 1518. If this bit is 1, it will accept
> > packets up to 2000 bytes.
> > - by setting SW_JUMBO_PACKET bit. If this bit is set, the chip will
> > ignore SW_LEGAL_PACKET_DISABLE value and use REG_SW_MTU__2 register to
> > configure MTU size.
> >
> > Current driver has disabled SW_JUMBO_PACKET bit and activates
> > SW_LEGAL_PACKET_DISABLE. So the switch will pass all packets up to 2000 without
> > any way to configure it.
> >
> > By providing port_change_mtu we are switch to SW_JUMBO_PACKET way and will
> > be able to configure MTU up to ~9000.
> >
> > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> > ---
> > changes v2:
> > - rename max_mtu to max_frame and new_mtu to frame_size
> > - use max() instead of if(>)
> > ---
> > drivers/net/dsa/microchip/ksz9477.c | 40 +++++++++++++++++++++++--
> > drivers/net/dsa/microchip/ksz9477_reg.h | 4 +++
> > drivers/net/dsa/microchip/ksz_common.h | 1 +
> > 3 files changed, 43 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/dsa/microchip/ksz9477.c b/drivers/net/dsa/microchip/ksz9477.c
> > index 18ffc8ded7ee..5c5f78cb970e 100644
> > --- a/drivers/net/dsa/microchip/ksz9477.c
> > +++ b/drivers/net/dsa/microchip/ksz9477.c
> > @@ -11,6 +11,7 @@
> > #include <linux/platform_data/microchip-ksz.h>
> > #include <linux/phy.h>
> > #include <linux/if_bridge.h>
> > +#include <linux/if_vlan.h>
> > #include <net/dsa.h>
> > #include <net/switchdev.h>
> >
> > @@ -182,6 +183,33 @@ static void ksz9477_port_cfg32(struct ksz_device *dev, int port, int offset,
> > bits, set ? bits : 0);
> > }
> >
> > +static int ksz9477_change_mtu(struct dsa_switch *ds, int port, int mtu)
> > +{
> > + struct ksz_device *dev = ds->priv;
> > + u16 frame_size, max_frame = 0;
> > + int i;
> > +
> > + frame_size = mtu + ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN;
>
> Are you sure the unit of measurement is ok? My KSZ9477 documentation
> says this about register 0x0308:
>
> Maximum Frame Length (MTU)
> Specifies the maximum transmission unit (MTU), which is the maximum
> frame payload size. Frames which exceed this maximum are truncated. This
> value can be set as high as 9000 (= 0x2328) if jumbo frame support is
> required.
>
> "frame payload" to me means what MTU should mean. And ETH_HLEN +
> VLAN_HLEN + ETH_FCS_LEN isn't part of that meaning.

if I set this value to anything less then 1522, it breaks the NFS boot. Since
my NFS server is configured with MTU 1500, i tried to guess how
frame size is calculated on this chip.

> > +
> > + if (dsa_is_cpu_port(ds, port))
> > + frame_size += KSZ9477_INGRESS_TAG_LEN;
> > +
> > + /* Cache the per-port MTU setting */
> > + dev->ports[port].max_frame = frame_size;
> > +
> > + for (i = 0; i < dev->port_cnt; i++)
> > + max_frame = max(max_frame, dev->ports[i].max_frame);
> > +
> > + return regmap_update_bits(dev->regmap[1], REG_SW_MTU__2,
> > + REG_SW_MTU_MASK, max_frame);
> > +}
> > +
> > +static int ksz9477_max_mtu(struct dsa_switch *ds, int port)
> > +{
> > + return KSZ9477_MAX_FRAME_SIZE - ETH_HLEN - ETH_FCS_LEN - VLAN_HLEN -
> > + KSZ9477_INGRESS_TAG_LEN;
> > +}
> > +
> > static int ksz9477_wait_vlan_ctrl_ready(struct ksz_device *dev)
> > {
> > unsigned int val;
> > @@ -1412,8 +1440,14 @@ static int ksz9477_setup(struct dsa_switch *ds)
> > /* Do not work correctly with tail tagging. */
> > ksz_cfg(dev, REG_SW_MAC_CTRL_0, SW_CHECK_LENGTH, false);
> >
> > - /* accept packet up to 2000bytes */
> > - ksz_cfg(dev, REG_SW_MAC_CTRL_1, SW_LEGAL_PACKET_DISABLE, true);
> > + /* Enable REG_SW_MTU__2 reg by setting SW_JUMBO_PACKET */
> > + ksz_cfg(dev, REG_SW_MAC_CTRL_1, SW_JUMBO_PACKET, true);
> > +
> > + /* Now we can configure default MTU value */
> > + ret = regmap_update_bits(dev->regmap[1], REG_SW_MTU__2, REG_SW_MTU_MASK,
> > + VLAN_ETH_FRAME_LEN + ETH_FCS_LEN);
>
> Why do you need this? Doesn't DSA call dsa_slave_create() ->
> dsa_slave_change_mtu(ETH_DATA_LEN) on probe?

This was my initial assumption as well, but cadence macb driver provides
buggy max MTU == -18. I hardcoded bigger MTU for now[1], but was not able to
find proper way to fix it. To avoid this kinds of regressions I decided
to keep some sane default configuration.

[1] - my workaround.
commit 5f8385e9641a383478a65f96ccee8fd992201f68
Author: Oleksij Rempel <linux@rempel-privat.de>
Date: Mon Feb 14 14:41:06 2022 +0100

WIP: net: macb: fix max mtu size

The gem_readl(bp, JML) will return 0, so we get max_mtu size of -18,
this is breaking MTU configuration for DSA

Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>

diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index a363da928e8b..454d811991bb 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -4727,7 +4727,7 @@ static int macb_probe(struct platform_device *pdev)
/* MTU range: 68 - 1500 or 10240 */
dev->min_mtu = GEM_MTU_MIN_SIZE;
if (bp->caps & MACB_CAPS_JUMBO)
- dev->max_mtu = gem_readl(bp, JML) - ETH_HLEN - ETH_FCS_LEN;
+ dev->max_mtu = 10240 - ETH_HLEN - ETH_FCS_LEN;
else
dev->max_mtu = ETH_DATA_LEN;

--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
\
 
 \ /
  Last update: 2022-02-24 06:00    [W:0.087 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site