netdev - Re: [PATCH] net: phy: DP83811: Add support for the phy

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:   Tue, 8 May 2018 12:21:12 -0500
From:   Dan Murphy <dmurphy@...com>
To:     Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>
CC:     <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] net: phy: DP83811: Add support for the phy

Florian

On 05/08/2018 12:14 PM, Florian Fainelli wrote:
> On 05/08/2018 10:13 AM, Dan Murphy wrote:
>> Andrew
>>
>> On 05/08/2018 11:49 AM, Andrew Lunn wrote:
>>> On Tue, May 08, 2018 at 10:56:55AM -0500, Dan Murphy wrote:
>>>> All
>>>>
>>>> On 05/08/2018 09:11 AM, Dan Murphy wrote:
>>>>> Add support for the DP83811 phy by extending
>>>>> the DP83822 driver to recognize the PHY IDs.
>>>>>
>>>>> The DP83811 supports both rgmii and sgmii interfaces.
>>>>> There are 2 part numbers for this the DP83811R does not
>>>>> reliably support the SGMII interface but the DP83811S will.
>>>>>
>>>>> There is not a way to differentiate these parts from the
>>>>> hardware or register set.  So this is controlled via the DT
>>>>> to indicate which phy mode is required.  Or the part can be
>>>>> strapped to a certain interface.
>>>>>
>>>>> Data sheet can be found here:
>>>>> http://www.ti.com/product/DP83TC811S-Q1/description
>>>>> http://www.ti.com/product/DP83TC811R-Q1/description
>>>>>
>>>>
>>>> I am withdrawing this patch for comment.
>>>> Some of the future features have varying register definitions between the DP83811
>>>> and DP83822
>>>
>>> Hi Dan
>>>
>>> It might be worth talking to the ASIC engineers and the
>>> test/qualification engineers. There are sometime undocumented
>>> registers for testing. You might be able to identify the exact device
>>> from these registers.
>>>
>>
>> Thanks.  I talked to them prior to submitting this patch about determining which part is on the board.
>> I will ping them again and poke a little harder.
>>
>> It turns out that we will probably need a new driver for this part anyway as there are
>> additional features that need to be supported that the 811 just does not support.
>>
>> They want to support Master/Slave configurations.
>> The 822 supports fiber and eee while the 811 does not.
>> The 811 supports the IEEE802.3bw specific fields in MMD1 and MMD3, which are not in the 822.
>> The 811 does not support auto-negotiation on the MDI so all the auto-neg registers are invalid for the 811 but are valid for the 822.
>>
>> Our Customer engineers felt that combining these two devices into a single driver may confuse the customer.
> 
> Why? Having a single Kconfig option to enable and "automatically"
> gaining support for new hardware is nice.
> 

I do agree that it is nice to have.  But with additional features or lack of features the driver source will get pretty messy
differentiating between devices.

What I added was just the basic if 811 & SGMII check.

Dan 

-- 
------------------
Dan Murphy