lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 15 Dec 2019 17:14:23 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Baruch Siach <baruch@...s.co.il>
Cc:     Marek Behun <marek.behun@....cz>,
        Vivien Didelot <vivien.didelot@...il.com>,
        netdev@...r.kernel.org,
        Denis Odintsov <d.odintsov@...viangames.com>,
        Hubert Feurstein <h.feurstein@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>
Subject: Re: [BUG] mv88e6xxx: tx regression in v5.3

On Sun, Dec 15, 2019 at 05:08:01PM +0200, Baruch Siach wrote:
> Hi Andrew,
> 
> On Sun, Dec 15 2019, Andrew Lunn wrote:
> >> This fixes cpu port configuration for me:
> >>
> >> diff --git a/drivers/net/dsa/mv88e6xxx/port.c b/drivers/net/dsa/mv88e6xxx/port.c
> >> index 7fe256c5739d..a6c320978bcf 100644
> >> --- a/drivers/net/dsa/mv88e6xxx/port.c
> >> +++ b/drivers/net/dsa/mv88e6xxx/port.c
> >> @@ -427,10 +427,6 @@ static int mv88e6xxx_port_set_cmode(struct mv88e6xxx_chip *chip, int port,
> >>  		cmode = 0;
> >>  	}
> >>
> >> -	/* cmode doesn't change, nothing to do for us */
> >> -	if (cmode == chip->ports[port].cmode)
> >> -		return 0;
> >> -
> >>  	lane = mv88e6xxx_serdes_get_lane(chip, port);
> >>  	if (lane) {
> >>  		if (chip->ports[port].serdes_irq) {
> >>
> >> Does that make sense?
> >
> > This needs testing on a 6390, with a port 9 or 10 using fixed link. We
> > have had issues in the past where mac_config() has been called once
> > per second, and each time it reconfigured the MAC, causing the link to
> > go down/up. So we try to avoid doing work which is not requires and
> > which could upset the link.
> 
> You refer to ed8fe20205ac ("net: dsa: mv88e6xxx: prevent interrupt storm
> caused by mv88e6390x_port_set_cmode") that introduced this code.
> 
> The alternative is to call ->port_get_cmode() to refresh the cmode cache
> after mv88e6xxx_port_hidden_write().

Refreshing the cmode after mv88e6xxx_port_hidden_write() sounds like a
good idea. But please limit it to just switches which need to make
cmode writable. cmode is rather fragile and the 6390 family is easy to
break in this area.

      Thanks
		Andrew

Powered by blists - more mailing lists