netdev - Re: [EXT] Re: [PATCH net-next v3 2/7] dt-bindings: net: add backplane dt bindings

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: <b62166dc-c38c-3287-f469-342ca81b4f6f@gmail.com>
Date:   Fri, 26 Jun 2020 11:55:47 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Florinel Iordache <florinel.iordache@....com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "andrew@...n.ch" <andrew@...n.ch>,
        "hkallweit1@...il.com" <hkallweit1@...il.com>,
        "linux@...linux.org.uk" <linux@...linux.org.uk>
Cc:     "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "corbet@....net" <corbet@....net>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        Leo Li <leoyang.li@....com>,
        "Madalin Bucur (OSS)" <madalin.bucur@....nxp.com>,
        Ioana Ciornei <ioana.ciornei@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [EXT] Re: [PATCH net-next v3 2/7] dt-bindings: net: add backplane
 dt bindings

On 6/24/20 5:55 AM, Florinel Iordache wrote:
>> -----Original Message-----
>> From: Florian Fainelli <f.fainelli@...il.com>
>> Sent: Tuesday, June 23, 2020 1:21 AM
>> To: Florinel Iordache <florinel.iordache@....com>; davem@...emloft.net;
>> netdev@...r.kernel.org; andrew@...n.ch; hkallweit1@...il.com;
>> linux@...linux.org.uk
>> Cc: devicetree@...r.kernel.org; linux-doc@...r.kernel.org;
>> robh+dt@...nel.org; mark.rutland@....com; kuba@...nel.org;
>> corbet@....net; shawnguo@...nel.org; Leo Li <leoyang.li@....com>; Madalin
>> Bucur (OSS) <madalin.bucur@....nxp.com>; Ioana Ciornei
>> <ioana.ciornei@....com>; linux-kernel@...r.kernel.org
>> Subject: [EXT] Re: [PATCH net-next v3 2/7] dt-bindings: net: add backplane dt
>> bindings
>>
>> Caution: EXT Email
>>
>> On 6/22/20 6:35 AM, Florinel Iordache wrote:
>>> Add ethernet backplane device tree bindings
>>>
>>> Signed-off-by: Florinel Iordache <florinel.iordache@....com>
>>> ---
>>
>> [snip]
>>
>>> +properties:
>>> +  $nodename:
>>> +    pattern: "^serdes(@[a-f0-9]+)?$"
>>> +
>>> +  compatible:
>>> +    oneOf:
>>> +      - const: serdes-10g
>>> +        description: SerDes module type of 10G
>>
>> Since this appears to be memory mapped in your case, it does not sound like
>> "serdes-10g" alone is going to be sufficient, should not we have a SoC specific
>> compatible string if nothing else?
> 
> My intention was to make it generic enough to be used by any SerDes (Serializer/Deserializer) block.
> So I was thinking that specifying serdes as HW block and the type: 10g (or 28g for example) should be enough.
> I could add SoC specific (or family of SoC) to the compatible string
> like for example Freescale/NXP QorIQ Soc: "fsl,ls1046a-serdes-10g" or "fsl,qoriq-serdes-10g"

It does not seem to me that the register interface is going to be
anything but generic, therefore using SoC specific compatible strings
would be a safer and forward looking approach. If a generic/fall back
compatibility string can be added, it can be added later on, that is
much less problematic than the opposite.

> 
>>
>>> +
>>> +  reg:
>>> +    description:
>>> +      Registers memory map offset and size for this serdes module
>>> +
>>> +  reg-names:
>>> +    description:
>>> +      Names of the register map given in "reg" node.
>>
>> You would also need to describe how many of these two properties are
>> expected.
> 
> Only one memory map is required since the memory maps for lanes are individually described
> (as it is documented in serdes-lane.yaml).
> I will specify this.

Then I believe you need to advertise that with maxItems property to
denote how many.

> 
>>
>>> +
>>> +  little-endian:
>>> +    description:
>>> +      Specifies the endianness of serdes module
>>> +      For complete definition see
>>> +      Documentation/devicetree/bindings/common-properties.txt
>>
>> This is redundant with the default binding then, and if it is not already in the
>> common YAML binding, can you please add little-endian and native-endian
>> added there?
> 
> The endianness of the serdes block must be specified as little-endian or big-endian.
> The serdes endianness may be different than the cores endianness.
> This is also the case for QorIQ LS1043/LS1046 platforms with ARM cores which
> are little endian but serdes block is big endian.
> So endianness must be specified in device tree in order for the driver to know how to access it.

I understand that part, my point was more than these properties are
generic properties, therefore it should not be necessary to provide a
description, and their definition belongs in the common properties
binding. If the common binding does not have a definition for those
(that is, in a YAML way), then please add them there.
-- 
Florian