From: Jarod Wilson
Date: Thu, 20 Oct 2016 23:25:27 -0400
> These few drivers call ether_setup(), but have no ndo_change_mtu, and thus
> were overlooked for changes to MTU range checking behavior. They
> previously had no range checks, so for feature-parity, set their min_mtu
> to 0 and max_mtu to
> I'm all for fine-tuning things to be more correct, but my initial
> approach here was to restore the ranges that were previously there,
> and DSA had no upper or lower bounds checks. I'm not at all familiar
> with DSA either way.
Please just restore the old behaviour.
We can consider changes la
On Fri, Oct 21, 2016 at 10:44:41AM +0200, Andrew Lunn wrote:
> On Thu, Oct 20, 2016 at 08:42:46PM -0700, Florian Fainelli wrote:
> > Le 20/10/2016 à 20:25, Jarod Wilson a écrit :
> > > These few drivers call ether_setup(), but have no ndo_change_mtu, and thus
> > > were overlooked for changes to MT
On Thu, Oct 20, 2016 at 08:42:46PM -0700, Florian Fainelli wrote:
> Le 20/10/2016 à 20:25, Jarod Wilson a écrit :
> > These few drivers call ether_setup(), but have no ndo_change_mtu, and thus
> > were overlooked for changes to MTU range checking behavior. They
> > previously had no range checks, s
Le 20/10/2016 à 20:25, Jarod Wilson a écrit :
> These few drivers call ether_setup(), but have no ndo_change_mtu, and thus
> were overlooked for changes to MTU range checking behavior. They
> previously had no range checks, so for feature-parity, set their min_mtu
> to 0 and max_mtu to ETH_MAX_MTU
These few drivers call ether_setup(), but have no ndo_change_mtu, and thus
were overlooked for changes to MTU range checking behavior. They
previously had no range checks, so for feature-parity, set their min_mtu
to 0 and max_mtu to ETH_MAX_MTU (65535), instead of the 68 and 1500
inherited from the
