netdev - Re: [PATCH net-next 2/3] net: atlantic: implement phy downshift feature

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]

Message-ID: <0f71cbca-a8b3-5180-2cf8-391e73e2ee53@marvell.com>
Date:   Wed, 30 Sep 2020 11:34:21 +0300
From:   Igor Russkikh <irusskikh@...vell.com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     <netdev@...r.kernel.org>, "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>
Subject: Re: [PATCH net-next 2/3] net: atlantic: implement phy downshift
 feature



> 
> Hi Igor
> 
> I think all other implementations return -EINVAL or -E2BIG or similar
> when the value is not supported.
> 
> Also, given that a u8 is being passed, is cfg->downshift_counter > 255
> possible? I'm not even sure 255 makes any sense. Autoneg takes around
> 1.5s, maybe longer. Do you really want to wait 255 * 1.5 seconds
> before downshifting? Even 15*1.5 seems a long time.

Hi Andrew, here I'm just blindly follow the value limits of firmware interface
(two device revisions have different counter field width here).

To make behavior consistent you are right, we probably can leave 15 max and
return EINVAL otherwise.

Igor