netdev - Re: [PATCH net-next 2/5] net: phy: mscc: Add EEE init sequence

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:   Mon, 1 Oct 2018 09:27:10 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Quentin Schulz <quentin.schulz@...tlin.com>
Cc:     davem@...emloft.net, andrew@...n.ch, allan.nielsen@...rochip.com,
        linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
        thomas.petazzoni@...tlin.com,
        Raju Lakkaraju <Raju.Lakkaraju@...rochip.com>
Subject: Re: [PATCH net-next 2/5] net: phy: mscc: Add EEE init sequence

On 10/01/2018 01:51 AM, Quentin Schulz wrote:
> Hi Florian,
> 
> On Fri, Sep 14, 2018 at 07:21:09PM -0700, Florian Fainelli wrote:
>>
>>
>> On 09/14/18 01:33, Quentin Schulz wrote:
>>> From: Raju Lakkaraju <Raju.Lakkaraju@...rochip.com>
>>>
>>> Microsemi PHYs (VSC 8530/31/40/41) need to update the Energy Efficient
>>> Ethernet initialization sequence.
>>> In order to avoid certain link state errors that could result in link
>>> drops and packet loss, the physical coding sublayer (PCS) must be
>>> updated with settings related to EEE in order to improve performance.
>>>
>>> Signed-off-by: Raju Lakkaraju <Raju.Lakkaraju@...rochip.com>
>>> Signed-off-by: Quentin Schulz <quentin.schulz@...tlin.com>
>>> ---
>>
>> [snip]
>>
>>> +	vsc85xx_tr_write(phydev, 0x0f82, 0x0012b00a);
>>
>> Can you just make this an array of register + value pair? That would be
> 
> Sure, I'll.
> 
>> less error prone in case you need to update that sequence in the future.
>>
> 
> I'm curious about the kind of errors you're worrying about or have
> experienced. Do you have any particular example or thought in mind?

Since this is just a completely non documented sequence likely given
as-is by the vendor, there could be in the future an arbitrary number of
changes made to that sequence because reasons. It seems to me that
putting that sequence in an array, instead of having to produce the
right sequence of calls, inlined in the source, is more manageable, and
will lead to an easier process if back porting/forward porting is necessary.
-- 
Florian