linux-kernel - Re: [PATCH net-next v1 3/4] dt-bindings: net: phy: add MaxLinear GPY2xx 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: <9c0506a6f654f72ea62fed864c1b2a26@walle.cc>
Date:   Tue, 06 Dec 2022 09:29:15 +0100
From:   Michael Walle <michael@...le.cc>
To:     Rob Herring <robh@...nel.org>
Cc:     Xu Liang <lxu@...linear.com>, Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        "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, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org
Subject: Re: [PATCH net-next v1 3/4] dt-bindings: net: phy: add MaxLinear
 GPY2xx bindings

Am 2022-12-05 22:53, schrieb Michael Walle:
> Am 2022-12-05 22:29, schrieb Rob Herring:
>> On Fri, Dec 02, 2022 at 04:12:03PM +0100, Michael Walle wrote:
>>> Add the device tree bindings for the MaxLinear GPY2xx PHYs.
>>> 
>>> Signed-off-by: Michael Walle <michael@...le.cc>
>>> ---
>>> 
>>> Is the filename ok? I was unsure because that flag is only for the 
>>> GPY215
>>> for now. But it might also apply to others. Also there is no 
>>> compatible
>>> string, so..
>>> 
>>>  .../bindings/net/maxlinear,gpy2xx.yaml        | 47 
>>> +++++++++++++++++++
>>>  1 file changed, 47 insertions(+)
>>>  create mode 100644 
>>> Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml
>>> 
>>> diff --git 
>>> a/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml 
>>> b/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml
>>> new file mode 100644
>>> index 000000000000..d71fa9de2b64
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml
>>> @@ -0,0 +1,47 @@
>>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/net/maxlinear,gpy2xx.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: MaxLinear GPY2xx PHY
>>> +
>>> +maintainers:
>>> +  - Andrew Lunn <andrew@...n.ch>
>>> +  - Michael Walle <michael@...le.cc>
>>> +
>>> +allOf:
>>> +  - $ref: ethernet-phy.yaml#
>>> +
>>> +properties:
>>> +  maxlinear,use-broken-interrupts:
>>> +    description: |
>>> +      Interrupts are broken on some GPY2xx PHYs in that they keep 
>>> the
>>> +      interrupt line asserted even after the interrupt status 
>>> register is
>>> +      cleared. Thus it is blocking the interrupt line which is 
>>> usually bad
>>> +      for shared lines. By default interrupts are disabled for this 
>>> PHY and
>>> +      polling mode is used. If one can live with the consequences, 
>>> this
>>> +      property can be used to enable interrupt handling.
>> 
>> Just omit the interrupt property if you don't want interrupts and add 
>> it
>> if you do.
> 
> How does that work together with "the device tree describes
> the hardware and not the configuration". The interrupt line
> is there, its just broken sometimes and thus it's disabled
> by default for these PHY revisions/firmwares. With this
> flag the user can say, "hey on this hardware it is not
> relevant because we don't have shared interrupts or because
> I know what I'm doing".

Specifically you can't do the following: Have the same device
tree and still being able to use it with a future PHY firmware
update/revision. Because according to your suggestion, this
won't have the interrupt property set. With this flag you can
have the following cases:
  (1) the interrupt information is there and can be used in the
      future by non-broken PHY revisions,
  (2) broken PHYs will ignore the interrupt line
  (3) except the system designer opts-in with this flag (because
      maybe this is the only PHY on the interrupt line etc).

-michael