Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <nick.hawkins@hpe.com> <20220125194609.32314-1-nick.hawkins@hpe.com>
 <CAK8P3a0ccoH_sNE9eWxQnWHEWNBPFL6k4k6mku=cHs_fRfnL-w@mail.gmail.com>
 <CA8148A1-578E-4621-9714-45AB391C353A@hpe.com> <2f4dd91a-e4ad-2559-f65e-914561de4047@canonical.com>
 <015EB9CD-ADB9-4C12-BD3F-78268E849884@hpe.com> <CAK8P3a3AUdQ94yu5An0-MhOuY2bOsr=zFWhtqVHk6E_+hBUCZQ@mail.gmail.com>
In-Reply-To: <CAK8P3a3AUdQ94yu5An0-MhOuY2bOsr=zFWhtqVHk6E_+hBUCZQ@mail.gmail.com>
From:   Joel Stanley <joel@jms.id.au>
Date:   Mon, 21 Feb 2022 08:39:47 +0000
Message-ID: <CACPK8XfgbQvAN+RzXWV0zJ_s9u3huyqA-1rofpf__3ifyB_Vzw@mail.gmail.com>
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.
To:     Arnd Bergmann <arnd@arndb.de>
Cc:     "Verdun, Jean-Marie" <verdun@hpe.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>,
        "Hawkins, Nick" <nick.hawkins@hpe.com>,
        Rob Herring <robh+dt@kernel.org>,
        Russell King <linux@armlinux.org.uk>,
        Shawn Guo <shawnguo@kernel.org>,
        Stanislav Jakubek <stano.jakubek@gmail.com>,
        Sam Ravnborg <sam@ravnborg.org>,
        Linus Walleij <linus.walleij@linaro.org>,
        Hao Fang <fanghao11@huawei.com>,
        "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>,
        Geert Uytterhoeven <geert+renesas@glider.be>,
        Mark Rutland <mark.rutland@arm.com>,
        Ard Biesheuvel <ardb@kernel.org>,
        Anshuman Khandual <anshuman.khandual@arm.com>,
        Lukas Bulwahn <lukas.bulwahn@gmail.com>,
        Masahiro Yamada <masahiroy@kernel.org>,
        DTML <devicetree@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        OpenBMC Maillist <openbmc@lists.ozlabs.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, 1 Feb 2022 at 09:00, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Mon, Jan 31, 2022 at 7:52 PM Verdun, Jean-Marie <verdun@hpe.com> wrote=
:
> >
> > - GXP is the name of the SoC. It has multiple implementations, which ar=
e currently compatibles. I don't think for the moment that we need to disti=
nguished them. We might have a GXP v2 coming up but not before a certain am=
ount of time which is far enough.
> > - This SoC is used to implement BMC features of HPE servers (all ProLia=
nt, many Apollo, and Superdome machines)
>
> Is there any more specific name of the chip that can be used to identify =
the
> exact generation after a new one comes out? The normal way we handle
> compatible strings for devices is to start with a specific model number o=
f
> the chip that integrates it, and then have later chips refer to the devic=
e by
> its new name, with the old one as a fallback. This makes drivers work out=
 of
> the box when the device is unchanged, but gives you a way to distinguish =
them
> if a difference gets noticed after both revisions are already used.
>
> As with some of points that Krzysztof and others made previously, the goa=
l
> here is to avoid binding incompatibilities in the future: anything that w=
orks
> in an upstream kernel should keep working in later versions, ideally
> allowing any combination of old and new dtb blobs in the bootloader
> with old or new kernel versions.
>
> > It does support many features including:
> > - ARMv7 architecture, and it is based on a Cortex A9 core
> > - Use an AXI bus to which
> >         - a memory controller is attached, as well as multiple SPI inte=
rfaces to connect boot flash, and ROM flash, a 10/100/1000 Mac engine which=
 supports SGMII (2 ports) and RMII
> >         - Multiple I2C engines to drive connectivity with a host infras=
tructure
> >         - A video engine which support VGA and DP, as well as an hardwa=
re video encder
> >         - Multiple PCIe ports
> >                 - A PECI interface, and LPC eSPI
> >         - Multiple UART for debug purpose, and Virtual UART for host co=
nnectivity
> >         - A GPIO engine
>
> Thanks for the description. This seems quite normal then, similar to the
> aspeed and npcm BMC platforms that we support already. You can
> probably drop some of the people on the Cc list, but I would suggest you =
add
> the openbmc list and Joel Stanley (Cc'd now) in your next submissions, Jo=
el
> would be the best person to review the parts that are BMC specific.

I had a call with some of the HPE developers a while back. It's good
to hear from you again.

As Arnd said, please cc me on your submissions and I'll provide
review. You can also cc openbmc@lists.ozlabs.org to reach a wider
audience of BMC developers.

After our call the other month, I took a look at your latest kernel
tree and started teasing out something that could be submitted:

https://github.com/shenki/linux/commits/gxp

Hopefully this helps illustrate what we mean about breaking down the
patches into small logical chunks. Don't take what I've done there as
correct, but it's an indication. Feel free to re-use.

I encourage you to take a look at the aspeed device trees for
inspiration. The way they are organised into generations - 2400, 2500,
2600 - illistrate's Arnd's points about supporting multiple
generations of SoC with the one code base.

Cheers,

Joel