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: <20230705114251.661-1-cuiyunhui@bytedance.com> <20230705114251.661-5-cuiyunhui@bytedance.com>
 <20230705-oblivious-unstuffed-8e028a5b243c@spud> <CAEEQ3wmG1OiE3GFqQp9SP+oKUbTfuTPx=rNGd-sjKsW7vv3bew@mail.gmail.com>
 <20230706-syndrome-wise-c1097518f2c6@wendy>
In-Reply-To: <20230706-syndrome-wise-c1097518f2c6@wendy>
From:   =?UTF-8?B?6L+Q6L6J5bSU?= <cuiyunhui@bytedance.com>
Date:   Thu, 6 Jul 2023 17:02:56 +0800
Message-ID: <CAEEQ3wk5AnesBhgHVkCqQbjC=ALShzJnRnppmFQfSeAxZ-51pw@mail.gmail.com>
Subject: Re: [External] Re: [PATCH v3 4/4] dt-bindings: firmware: Document
 ffitbl binding
To:     Conor Dooley <conor.dooley@microchip.com>
Cc:     Conor Dooley <conor@kernel.org>, robh+dt@kernel.org,
        krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
        devicetree@vger.kernel.org, sunilvl@ventanamicro.com,
        ardb@kernel.org, palmer@dabbelt.com, paul.walmsley@sifive.com,
        aou@eecs.berkeley.edu, linux-riscv@lists.infradead.org,
        rminnich@gmail.com, mark.rutland@arm.com, lpieralisi@kernel.org,
        rafael@kernel.org, lenb@kernel.org, jdelvare@suse.com,
        yc.hung@mediatek.com, angelogioacchino.delregno@collabora.com,
        allen-kh.cheng@mediatek.com, pierre-louis.bossart@linux.intel.com,
        tinghan.shen@mediatek.com, linux-kernel@vger.kernel.org,
        linux-acpi@vger.kernel.org, geshijian@bytedance.com,
        weidong.wd@bytedance.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi Conor,

On Thu, Jul 6, 2023 at 2:45=E2=80=AFPM Conor Dooley <conor.dooley@microchip=
.com> wrote:
>
> On Thu, Jul 06, 2023 at 11:43:55AM +0800, =E8=BF=90=E8=BE=89=E5=B4=94 wro=
te:
> > On Wed, Jul 5, 2023 at 11:07=E2=80=AFPM Conor Dooley <conor@kernel.org>=
 wrote:
> > > On Wed, Jul 05, 2023 at 07:42:51PM +0800, Yunhui Cui wrote:
> > > > Add the description for ffitbl subnode.
> > > >
> > > > Signed-off-by: Yunhui Cui <cuiyunhui@bytedance.com>
> > > > ---
> > > >  .../devicetree/bindings/firmware/ffitbl.txt   | 27 +++++++++++++++=
++++
> > > >  MAINTAINERS                                   |  1 +
> > > >  2 files changed, 28 insertions(+)
> > > >  create mode 100644 Documentation/devicetree/bindings/firmware/ffit=
bl.txt
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/firmware/ffitbl.txt =
b/Documentation/devicetree/bindings/firmware/ffitbl.txt
> > > > new file mode 100644
> > > > index 000000000000..c42368626199
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/firmware/ffitbl.txt
> > >
> > > Firstly, new dt-bindings need to be done in yaml, not in text form.
> > > Secondly, you didn't re-run get_maintainer.pl after adding this bindi=
ng,
> > > so you have not CCed any of the other dt-binding maintainers nor the
> > > devicetree mailing list.
> >
> > Re-run get_maintainer.pl and added maintainers into the maillist.
> > emm.. There is some *txt in
> > Documentation/devicetree/bindings/firmware/, isn't it?
>
> There might be, but that's not an excuse for adding _new_ ones, sorry.

Okay, I'll update it on v4.


> > > > +FFI(FDT FIRMWARE INTERFACE) driver
> > > > +
> > > > +Required properties:
> > > > + - entry             : acpi or smbios root pointer, u64
> > > > + - reg                       : acpi or smbios version, u32
> > >
> > > Please go look at any other dt-binding (or the example schema) as to =
how
> > > these properties should be used. A "reg" certainly should not be bein=
g
> > > used to store the revision...
> >
> > Okay, If so=EF=BC=8CI'll add a property "version" into the dts instead =
of
> > "reg", just like, WDYT?
> > ffitbl {
>
> Firstly, I'd much rather you spelt this out, like "ffi-table".
>
> >     smbios {
> >         entry =3D "";
>
> I still don't understand why "entry", which is an address, is being
> represented by an empty string.
> I also don't really get why you have not used "reg" to describe its
> start address and size.
>
> >         version =3D < 0x02 >;
>
> Probably missing a vendor prefix, and the spaces are unusual, but better
> than it was, yes.

Based on your review, I plan to modify it as follows:

ffi-table {
#address-cells =3D <2>;
#size-cells =3D <0>;
        smbios@entry1 {
                compatible =3D "smbios";
                reg =3D <entry1>;
                version =3D <2>;
        };
        smbios@entry2 {
                compatible =3D "smbios";
                reg =3D <entry2>;
                version =3D <3>;
        };
        acpi@entry {
                compatible =3D "acpi";
                reg =3D <entry>;
                version =3D <6>;
        };
}

The reason why #size-cells is 0 is because only one item is needed,
#address-cells =3D <2>; because two u32 are needed to express the 64-bit
address.
The memory for the SMBIOS table itself will be preserved in "reserved
memory" , so we don't have to worry about this piece of memory getting
corrupted. ACPI as well. WDYT?

> >     }
> >    acpi {
> >          entry =3D "";
> >          version =3D < 0x06 >;
> >   }
> > }
>
> Thanks,
> Conor.

Thanks,
Yunhui