netdev - Re: [EXT] Re: [PATCH net-next 3/3] net: atlantic: implement media detect feature via phy tunables

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] [day] [month] [year] [list]

Date:   Thu, 1 Oct 2020 14:56:59 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Igor Russkikh <irusskikh@...vell.com>
Cc:     netdev@...r.kernel.org, "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>
Subject: Re: [EXT] Re: [PATCH net-next 3/3] net: atlantic: implement media
 detect feature via phy tunables

On Thu, Oct 01, 2020 at 01:18:06PM +0300, Igor Russkikh wrote:
> Hi Andrew,
> 
> > Since this is your own PHY, not some magical black box, i assume you
> > actually know what value it is using? It probably even lists it in the
> > data sheet.
> > 
> > So just hard code that value in the driver. That has got to be better
> > than saying the incorrect value of 1ms.
> 
> You mean always return that value in get_, and ignore what we get in set_ ?
> That could be done, will investigate.

You should validate the set as well. Only two values are valid, 0 to
turn the feature off, and whatever the firmware is hard coded with.

This is where extack would be very useful. When the user initially
tries to set it to 42, you can return -EINVAL, plus a message listing
the acceptable values. The best you can do at the moment is write the
text to the kernel log.

    Andrew