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> <20220216153632.40981-1-nick.hawkins@hpe.com>
 <CAK8P3a0NmyxrzxgfwfDXuFvhmc3OL_-yBj8PDdEHh-2qm4NVkw@mail.gmail.com>
 <PH0PR84MB17185157544CFEB1D8AE267088359@PH0PR84MB1718.NAMPRD84.PROD.OUTLOOK.COM>
 <CAK8P3a1HuTMt5WmOw3aQcLwGZd_WQ5nsKZ2HFDPQ0CHFvKsygA@mail.gmail.com>
In-Reply-To: <CAK8P3a1HuTMt5WmOw3aQcLwGZd_WQ5nsKZ2HFDPQ0CHFvKsygA@mail.gmail.com>
From:   Joel Stanley <joel@jms.id.au>
Date:   Mon, 21 Feb 2022 08:31:49 +0000
Message-ID: <CACPK8XdXV4j=0kYbEJRki9ug6VeeK02ZrXRgqFd9gUu6kSpA=Q@mail.gmail.com>
Subject: Re: [PATCH] [v3] arch: arm: boot: dts: Create HPE GXP Device Tree
To:     Arnd Bergmann <arnd@arndb.de>
Cc:     "Hawkins, Nick" <nick.hawkins@hpe.com>,
        "Verdun, Jean-Marie" <verdun@hpe.com>,
        Olof Johansson <olof@lixom.net>, SoC Team <soc@kernel.org>,
        Rob Herring <robh+dt@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        DTML <devicetree@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, 16 Feb 2022 at 16:51, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Wed, Feb 16, 2022 at 5:29 PM Hawkins, Nick <nick.hawkins@hpe.com> wrote:

> > > +
> > > +               vrom@58000000 {
> > > +                       compatible = "mtd-ram";
> >
> > Same thing here, "vrom" is clearly not a standard name.
> >
> > NH: VROM is a Virtual ROM device that we use to create a memory mapping of a SPI flash content copy that is served to a host system. How should I rename it?
>
> Not sure, I don't remember seeing this case so far. Adding Joel to Cc,
> maybe he knows of
> another BMC that does the same thing.

We have something similar. The aspeed systems map this over LPC, using
FW cycles (aka memory accesses) over the LPC bus to read from the
BMC's SPI NOR devices, or DRAM.

The device tree bindings we have are in the LPC document:

 Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml

It's the aspeed,ast2400-lpc-ctrl specifically. It takes a phandle to a
reserved-memory node.

The kernel driver is at drivers/soc/aspeed/aspeed-lpc-ctrl.c. It
exposes a character device that allows userspace to read and write to
the memory window.

We have this very aspeed specific design because it was the first
implementation in the kernel. Where possible, we should create a new
unified API for doing this type of access, where each BMC can
implement a backend. Now that we have GXP, Nuvoton and ASPEED it
should be easier to pick out common functionality.

Cheers,

Joel