netdev - Re: [PATCH net-next 1/2] dt-bindings: dp83td510: Add binding for DP83TD510 Ethernet 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <cb44ea1f-4c7a-98c6-6206-526169d8f24b@ti.com>
Date:   Thu, 8 Oct 2020 13:18:09 -0500
From:   Dan Murphy <dmurphy@...com>
To:     Florian Fainelli <f.fainelli@...il.com>, <davem@...emloft.net>,
        <andrew@...n.ch>, <hkallweit1@...il.com>
CC:     <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next 1/2] dt-bindings: dp83td510: Add binding for
 DP83TD510 Ethernet PHY

Florian

Thanks for the review

On 10/8/20 12:11 PM, Florian Fainelli wrote:
>
>
> On 10/8/2020 9:23 AM, Dan Murphy wrote:
>> The DP83TD510 is a 10M single twisted pair Ethernet PHY
>>
>> Signed-off-by: Dan Murphy <dmurphy@...com>
>> ---
>>   .../devicetree/bindings/net/ti,dp83td510.yaml | 70 +++++++++++++++++++
>>   1 file changed, 70 insertions(+)
>>   create mode 100644 
>> Documentation/devicetree/bindings/net/ti,dp83td510.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/net/ti,dp83td510.yaml 
>> b/Documentation/devicetree/bindings/net/ti,dp83td510.yaml
>> new file mode 100644
>> index 000000000000..0f0eac77a11a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/ti,dp83td510.yaml
>> @@ -0,0 +1,70 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +# Copyright (C) 2020 Texas Instruments Incorporated
>> +%YAML 1.2
>> +---
>> +$id: "http://devicetree.org/schemas/net/ti,dp83td510.yaml#"
>> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
>> +
>> +title: TI DP83TD510 ethernet PHY
>> +
>> +allOf:
>> +  - $ref: "ethernet-controller.yaml#"
>> +
>> +maintainers:
>> +  - Dan Murphy <dmurphy@...com>
>> +
>> +description: |
>> +  The PHY is an twisted pair 10Mbps Ethernet PHY that support MII, 
>> RMII and
>> +  RGMII interfaces.
>> +
>> +  Specifications about the Ethernet PHY can be found at:
>> +    http://www.ti.com/lit/ds/symlink/dp83td510e.pdf
>> +
>> +properties:
>> +  reg:
>> +    maxItems: 1
>> +
>> +  tx-fifo-depth:
>> +    description: |
>> +       Transmitt FIFO depth for RMII mode.  The PHY only exposes 4 
>> nibble
>> +       depths. The valid nibble depths are 4, 5, 6 and 8.
>> +    default: 5
>> +
>> +  rx-internal-delay-ps:
>> +    description: |
>> +       Setting this property to a non-zero number sets the RX 
>> internal delay
>> +       for the PHY.  The internal delay for the PHY is fixed to 30ns 
>> relative
>> +       to receive data.
>> +
>> +  tx-internal-delay-ps:
>> +    description: |
>> +       Setting this property to a non-zero number sets the TX 
>> internal delay
>> +       for the PHY.  The internal delay for the PHY has a range of 
>> -4 to 4ns
>> +       relative to transmit data.
>
> Those two properties are already defined as part of 
> Documentation/devicetree/bindings/net/ethernet-phy.yaml, so you can 
> reference that binding, too.

OK I referenced the ethernet-controller.yaml for the delay. I am 
wondering if we should add rx/tx-fifo-depth to the ethernet-phy.yaml as 
well. That way PHYs only have to reference ethernet-phy.yaml.

Or maybe remove the internal-delay from the ethernet-phy.yaml and 
reference the ethernet-controller.yaml in the ethernet-phy.yaml so we 
don't have to maintain duplicate properties

>
>> +
>> +  ti,master-slave-mode:
>> +    $ref: /schemas/types.yaml#definitions/uint32
>> +    default: 0
>> +    description: |
>> +      Force the PHY to be configured to a specific mode.
>> +      Force Auto Negotiation - 0
>> +      Force Master mode at 1v p2p - 1
>> +      Force Master mode at 2.4v p2p - 2
>> +      Force Slave mode at 1v p2p - 3
>> +      Force Slave mode at 2.4v p2p - 4
>
> If you accept different values you should be indicating which values 
> are supported with an enumeration.

Ah yes forgot the min/max