Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 21 Apr 2020 15:27:32 +0200
From:   Andrew Lunn <andrew@lunn.ch>
To:     Oleksij Rempel <o.rempel@pengutronix.de>
Cc:     Vladimir Oltean <olteanv@gmail.com>, mkl@pengutronix.de,
        Vivien Didelot <vivien.didelot@gmail.com>,
        Florian Fainelli <f.fainelli@gmail.com>, kernel@pengutronix.de,
        netdev <netdev@vger.kernel.org>,
        lkml <linux-kernel@vger.kernel.org>,
        David Jander <david@protonic.nl>,
        Russell King - ARM Linux admin <linux@armlinux.org.uk>,
        "David S. Miller" <davem@davemloft.net>
Subject: Re: dsa: sja1105: regression after patch: "net: dsa: configure the
 MTU for switch ports"
Message-ID: <20200421132732.GC937199@lunn.ch>
References: <20200421113324.vxh2lyasylf5kgkz@pengutronix.de>
 <CA+h21ho2YnUfzMja1Y7=B7Yrqk=WD6jm-OoKKzX4uS3WJiU5aw@mail.gmail.com>
 <20200421125828.jb44qzfzgd7sh436@pengutronix.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200421125828.jb44qzfzgd7sh436@pengutronix.de>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

> > The code which is causing problems seems to be this one:
> > 
> >     mtu_limit = min_t(int, master->max_mtu, dev->max_mtu);
> >     old_master_mtu = master->mtu;
> >     new_master_mtu = largest_mtu + cpu_dp->tag_ops->overhead;
> >     if (new_master_mtu > mtu_limit)
> >         return -ERANGE;
> > 
> > called from
> > 
> >     rtnl_lock();
> >     ret = dsa_slave_change_mtu(slave_dev, ETH_DATA_LEN);
> >     rtnl_unlock();
> >     if (ret && ret != -EOPNOTSUPP) {
> >         dev_err(ds->dev, "error %d setting MTU on port %d\n",
> >             ret, port->index);
> >         goto out_free;
> >     }
> > 
> > Before this patch, it was silently failing, now it's preventing the
> > probing of the ports which I might agree with you is not better.
> > Andrew warned about this, and I guess that during probe, we should
> > warn but ignore any nonzero return code, not just EOPNOTSUPP. I'll
> > send a patch out shortly to correct this.
> > 
> > Out of curiosity, what DSA master port do you have? Does it not
> > support an MTU of 1504 bytes? Does MTU-sized traffic pass correctly
> > through your interface? (you can test with iperf3)
> 
> It is FEC@iMX6QP attached to the port 4 of the sja1105 switch.
> I'll try to make some tests tomorrow.

Ah, interesting. I've been testing recently on a Vybrid, so also
FEC. I had the warning, but it kept going.

I don't particularly like this warning in this case. We have hardware
which happy works, but is now issuing a warning on boot. I would
prefer if it warned when only trying to configure an MTU bigger than
the minimum needed for DSA, i.e. only the jumbo use case.

    Andrew