netdev - RE: [EXT] Re: [PATCH 2/5] dt-bindings: net: add schema for NXP S32CC dwmac glue driver

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: <AM9PR04MB85064E7C90938308B9C69015E23E9@AM9PR04MB8506.eurprd04.prod.outlook.com>
Date:   Wed, 9 Nov 2022 22:55:19 +0000
From:   Jan Petrous <jan.petrous@....com>
To:     Andreas Färber <afaerber@...e.de>,
        Rob Herring <robh@...nel.org>, Chester Lin <clin@...e.com>
CC:     "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        dl-S32 <S32@....com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Matthias Brugger <mbrugger@...e.com>
Subject: RE: [EXT] Re: [PATCH 2/5] dt-bindings: net: add schema for NXP S32CC
 dwmac glue driver

Hi Andreas,

> Hi Rob,
> 
> On 02.11.22 16:55, Rob Herring wrote:
> > On Mon, Oct 31, 2022 at 06:10:49PM +0800, Chester Lin wrote:
> >> Add the DT schema for the DWMAC Ethernet controller on NXP S32
> Common
> >> Chassis.
> >>
> >> Signed-off-by: Jan Petrous <jan.petrous@....com>
> >> Signed-off-by: Chester Lin <clin@...e.com>
> >> ---
> >>   .../bindings/net/nxp,s32cc-dwmac.yaml         | 145 ++++++++++++++++++
> >>   1 file changed, 145 insertions(+)
> >>   create mode 100644 Documentation/devicetree/bindings/net/nxp,s32cc-
> dwmac.yaml
> >>
> >> diff --git a/Documentation/devicetree/bindings/net/nxp,s32cc-
> dwmac.yaml b/Documentation/devicetree/bindings/net/nxp,s32cc-
> dwmac.yaml
> >> new file mode 100644
> >> index 000000000000..f6b8486f9d42
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/net/nxp,s32cc-dwmac.yaml
> >> @@ -0,0 +1,145 @@
> >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >> +# Copyright 2021-2022 NXP
> >> +%YAML 1.2
> >> +---
> >> +$id:
[...]
> >> +title: NXP S32CC DWMAC Ethernet controller
> >> +
> >> +maintainers:
> >> +  - Jan Petrous <jan.petrous@....com>
> >> +  - Chester Lin <clin@...e.com>
> [...]
> >> +properties:
> >> +  compatible:
> >> +    contains:
> >
> > Drop 'contains'.
> >
> >> +      enum:
> >> +        - nxp,s32cc-dwmac
> 
> In the past you were adamant that we use concrete SoC-specific strings.
> Here that would mean s32g2 or s32g274 instead of s32cc (which aims to
> share with S32G3 IIUC).
> 
> [...]
> >> +  clocks:
> >> +    items:
> >> +      - description: Main GMAC clock
> >> +      - description: Peripheral registers clock
> >> +      - description: Transmit SGMII clock
> >> +      - description: Transmit RGMII clock
> >> +      - description: Transmit RMII clock
> >> +      - description: Transmit MII clock
> >> +      - description: Receive SGMII clock
> >> +      - description: Receive RGMII clock
> >> +      - description: Receive RMII clock
> >> +      - description: Receive MII clock
> >> +      - description:
> >> +          PTP reference clock. This clock is used for programming the
> >> +          Timestamp Addend Register. If not passed then the system
> >> +          clock will be used.
> >
> > If optional, then you need 'minItems'.
> [snip]
> 
> Do we have any precedence of bindings with *MII clocks like these?
> 
> AFAIU the reason there are so many here is that there are in fact
> physically just five, but different parent clock configurations that
> SCMI does not currently expose to Linux. Thus I was raising that we may

Correct. The different clock names represent different configs of the same
clocks.

> want to extend the SCMI protocol with some SET_PARENT operation that
> could allow us to use less input clocks here, but obviously such a
> standardization process will take time...
> 
> What are your thoughts on how to best handle this here?
> 
> Not clear to me has been whether the PHY mode can be switched at runtime
> (like DPAA2 on Layerscape allows for SFPs) or whether this is fixed by
> board design. If the latter, the two out of six SCMI IDs could get
> selected in TF-A, to have only physical clocks here in the binding.

The eval board allows to use different PHYs/switches connected by RGMII
or SGMII to the GMAC. Some combinations require change of board's
hw switches, but not all of them. Anyway, until we get a board with SFP,
the connection type can be treated as fixed (declared in DT). 

/Jan

--
NXP Czechia, AP Ethernet