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 for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 23 Mar 2020 14:31:03 +0000
From:   Christian Herber <christian.herber@....com>
To:     Rob Herring <robh@...nel.org>,
        Florian Fainelli <f.fainelli@...il.com>
CC:     Oleksij Rempel <o.rempel@...gutronix.de>,
        Mark Rutland <mark.rutland@....com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Andrew Lunn <andrew@...n.ch>, Marek Vasut <marex@...x.de>,
        netdev <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        David Jander <david@...tonic.nl>,
        "David S. Miller" <davem@...emloft.net>,
        Heiner Kallweit <hkallweit1@...il.com>
Subject: RE: Re: [PATCH v4 1/4] dt-bindings: net: phy: Add support for NXP
 TJA11xx

>On Sun, Mar 22, 2020 at 3:09 PM Florian Fainelli <f.fainelli@...il.com> wrote:
>>
>> On 3/20/2020 4:05 PM, Rob Herring wrote:
>> >>>> Because the primary PHY0 can be autodetected by the bus scan.
>> >>>> But I have nothing against your suggestions. Please, some one should say the
>> >>>> last word here, how exactly it should be implemented?
>> >>
>> >> It's not for me to decide, I was hoping the Device Tree maintainers
>> >> could chime in, your current approach would certainly work although it
>> >> feels visually awkward.
>> >
>> > Something like this is what I'd do:
>> >
>> > ethernet-phy@4 {
>> >   compatible = "nxp,tja1102";
>> >   reg = <4 5>;
>> > };
>>
>> But the parent (MDIO bus controller) has #address-cells = 1 and
>> #size-cells = 0, so how can this be made to work without creating two
>> nodes or a first node encapsulating another one?
>
>That is the size of the address, not how many addresses there are. If
>the device has 2 addresses, then 2 address entries seems entirely
>appropriate.
>
>Rob

Yes, it is one device with two address. This is if you call the entire IC a device. If you look at it from a PHY perspective, it is two devices with 1 address.
If you just look at it as a single device, it gets difficult to add PHY specific properties in the future, e.g. master/slave selection.
In my opinion its important to have some kind of container for the entire IC, but likewise for the individual PHYs.

Christian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ