netdev - Re: [PATCH v7 net-next] net: phy: Add Edge-rate driver for Microsemi PHYs.

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]

Message-ID: <20161005085106.GI5575@lunn.ch>
Date:   Wed, 5 Oct 2016 10:51:06 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Raju Lakkaraju <Raju.Lakkaraju@...rosemi.com>
Cc:     netdev@...r.kernel.org, devicetree@...r.kernel.org,
        f.fainelli@...il.com, Allan.Nielsen@...rosemi.com
Subject: Re: [PATCH v7 net-next] net: phy: Add Edge-rate driver for Microsemi
 PHYs.

On Wed, Oct 05, 2016 at 02:06:43PM +0530, Raju Lakkaraju wrote:
> Hi Andrew,
> 
> Thank you for review comment.
> 
> On Tue, Oct 04, 2016 at 04:34:50PM +0200, Andrew Lunn wrote:
> > EXTERNAL EMAIL
> > 
> > 
> > > v7:
> > > - As per review comment, Removed '-'s (minus) sign in Edge rate table.
> > 
> > Still no exact match on the table.
> > 
> > So if i specify a voltage of 3301, 53% slowdown it looks i will
> > actually get 0% slowdown and no error message. That is not very
> > helpful.
> > 
> 
> According to my understanding, User should choose the right VDDMAC voltage
> (i.e. 3.3V or 2.5V or 1.8V or 1.5V).

And user do make typos, don't read the documentation, etc and get it
wrong. The way you have implemented this, does not help the user
figure out what they have wrong. It silently does something totally
unexpected.
 
> Do you want me to add an error trace which will inform the user that the 
> configured values can not be supported - or if the driver should pick 
> the "closest" value it can support (or both).

You should validate what the user has requested via DT is valid, and
it not, return -EINVAL during probe. That should cause the PHY driver
to fail to load, making it clear something is bad in the device tree.
A dev_err() call saying which parameter is invalid would also be nice.

  Andrew