linux-kernel - Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.

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: <YfB91lWAtBgNLaGQ@lunn.ch>
Date:   Tue, 25 Jan 2022 23:46:46 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     nick.hawkins@....com
Cc:     verdun@....com, Rob Herring <robh+dt@...nel.org>,
        Russell King <linux@...linux.org.uk>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
        Shawn Guo <shawnguo@...nel.org>,
        Stanislav Jakubek <stano.jakubek@...il.com>,
        Sam Ravnborg <sam@...nborg.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Hao Fang <fanghao11@...wei.com>, Arnd Bergmann <arnd@...db.de>,
        "Russell King (Oracle)" <rmk+kernel@...linux.org.uk>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Mark Rutland <mark.rutland@....com>,
        Ard Biesheuvel <ardb@...nel.org>,
        Anshuman Khandual <anshuman.khandual@....com>,
        Lukas Bulwahn <lukas.bulwahn@...il.com>,
        Masahiro Yamada <masahiroy@...nel.org>,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is
 the first of a series of patches to support HPE's BMC with Linux Kernel.

> +		umac0: umac@...04000 {
> +			compatible = "hpe, gxp-umac";
> +			reg = <0xc0004000 0x80>;
> +			interrupts = <10>;
> +			interrupt-parent = <&vic0>;
> +			mac-address = [94 18 82 16 04 d8];
> +			phy-handle = <&ext_phy0>;
> +			int-phy-handle = <&int_phy0>;
> +		};

I suggest you don't add any DT for drivers which have not been
accepted yet. When you MAC driver is posted to netdev, the DT binding
will get reviewed. And i expect int-phy-handle will be rejected.

Often the first dtsi and dts submission for a new SoC have just the
CPUs and the serial port, since none of the other drivers have been
reviewed yet, unless they reuse existing drivers. The additional nodes
are then added one by one as the drivers get accepted.

	 Andrew