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  linux-hardening  linux-cve-announce  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:08:01 +0200
From:   Baruch Siach <baruch@...s.co.il>
To:     Andrew Lunn <andrew@...n.ch>
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

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().

What do you think?

Thanks,
baruch

--
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@...s.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ