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: <Y6G22e06gQ2+kM+G@lunn.ch>
Date:   Tue, 20 Dec 2022 14:21:29 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Michael Walle <michael@...le.cc>
Cc:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Rob Herring <robh@...nel.org>, Xu Liang <lxu@...linear.com>,
        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

>  (2) Krzysztof pointed out that there is still the issue raised by
>      Rob, that the schemas haven't any compatible and cannot be
>      validated. I think that applies to all the network PHY bindings
>      in the tree right now. I don't know how to fix them.

i've been offline for a while, i sabotaged my own mail server...

You can always add an unneeded compatible, using the PHY devices ID:

      - pattern: "^ethernet-phy-id[a-f0-9]{4}\\.[a-f0-9]{4}$"
        description:
          If the PHY reports an incorrect ID (or none at all) then the
          compatible list may contain an entry with the correct PHY ID
          in the above form.
          The first group of digits is the 16 bit Phy Identifier 1
          register, this is the chip vendor OUI bits 3:18. The
          second group of digits is the Phy Identifier 2 register,
          this is the chip vendor OUI bits 19:24, followed by 10
          bits of a vendor specific ID.

It would be fine to do this in the example in the binding, but i would
add a comment something like:

"Compatible generally only needed to make DT lint tools work. Mostly
not needed for real DT descriptions"

Examples often get cut/paste without thinking, and we don't really
want the compatible used unless it is really needed.

This is however a bigger problem than just PHYs. It applies to any
device which can be enumerated on a bus, e.g. USB, PCI. So maybe this
limitation of the DT linting tools should be fixed once at a higher
level?

>  (3) The main problem with the broken interrupt handling of the PHY
>      is that it will disturb other devices on that interrupt line.
>      IOW if the interrupt line is shared the PHY should fall back
>      to polling mode. I haven't found anything in the interrupt
>      subsys to query if a line is shared and I guess it's also
>      conceptually impossible to do such a thing, because there
>      might be any driver probed at a later time which also uses
>      that line.
>      Rob had the idea to walk the device tree and determine if
>      a particular interrupt is used by other devices, too. If
>      feasable, this sounds like a good enough heuristic for our
>      problem. Although there might be some edge cases, like
>      DT overlays loaded at linux runtime (?!).

My humble opinion is that it is not worth the complexity for just one
PHY which should work in polling mode without problems. I think the
boolean property you propose is KISS and does what is needed.

	Andrew