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]
Date:   Fri, 24 Jul 2020 15:39:31 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Jeremy Linton <jeremy.linton@....com>
Cc:     Calvin Johnson <calvin.johnson@....nxp.com>,
        Russell King - ARM Linux admin <linux@...linux.org.uk>,
        Jon <jon@...id-run.com>,
        Cristi Sovaiala <cristian.sovaiala@....com>,
        Ioana Ciornei <ioana.ciornei@....com>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Madalin Bucur <madalin.bucur@....nxp.com>,
        netdev@...r.kernel.org, linux.cj@...il.com,
        linux-acpi@...r.kernel.org
Subject: Re: [net-next PATCH v7 1/6] Documentation: ACPI: DSD: Document MDIO
 PHY

> Otherwise the MDIO bus and its phy should be a
> child of the nic/mac using it, with standardized behaviors/etc left up to
> the OSPM when it comes to MDIO bus enumeration/etc.

Hi Jeremy 

Could you be a bit more specific here please.

DT allows

        macb0: ethernet@...c4000 {
                compatible = "cdns,at32ap7000-macb";
                reg = <0xfffc4000 0x4000>;
                interrupts = <21>;
                phy-mode = "rmii";
                local-mac-address = [3a 0e 03 04 05 06];
                clock-names = "pclk", "hclk", "tx_clk";
                clocks = <&clkc 30>, <&clkc 30>, <&clkc 13>;
                ethernet-phy@1 {
                        reg = <0x1>;
                        reset-gpios = <&pioE 6 1>;
                };
        };

So the PHY is a direct child of the MAC. The MDIO bus is not modelled
at all. Although this is allowed, it is deprecated, because it results
in problems with advanced systems which have multiple different
children, and the need to differentiate them. So drivers are slowly
migrating to always modelling the MDIO bus. In that case, the
phy-handle is always used to point to the PHY:

        eth0: ethernet@...d0000 {
                compatible = "socionext,synquacer-netsec";
                reg = <0 0x522d0000 0x0 0x10000>, <0 0x10000000 0x0 0x10000>;
                interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
                clocks = <&clk_netsec>;
                clock-names = "phy_ref_clk";
                phy-mode = "rgmii";
                max-speed = <1000>;
                max-frame-size = <9000>;
                phy-handle = <&phy1>;

                mdio {
                        #address-cells = <1>;
                        #size-cells = <0>;
                        phy1: ethernet-phy@1 {
                                compatible = "ethernet-phy-ieee802.3-c22";
                                reg = <1>;
                        };
                };

"mdio-handle" is just half of phy-handle.

What you seem to be say is that although we have defined a generic
solution for ACPI which should work in all cases, it is suggested to
not use it? What exactly are you suggesting in its place?

	Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ