Hi Conor,
On Thu, Jul 6, 2023 at 2:45 PM Conor Dooley <conor.dooley@xxxxxxxxxxxxx> wrote:
>
> On Thu, Jul 06, 2023 at 11:43:55AM +0800, 运辉崔 wrote:
> > On Wed, Jul 5, 2023 at 11:07 PM Conor Dooley <conor@xxxxxxxxxx> 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@xxxxxxxxxxxxx>
> > > > ---
> > > > .../devicetree/bindings/firmware/ffitbl.txt | 27 +++++++++++++++++++
> > > > MAINTAINERS | 1 +
> > > > 2 files changed, 28 insertions(+)
> > > > create mode 100644 Documentation/devicetree/bindings/firmware/ffitbl.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 binding,
> > > 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 being
> > > used to store the revision...
> >
> > Okay, If so，I'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 = "";
>
> 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 = < 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 = <2>;
#size-cells = <0>;
smbios@entry1 {
compatible = "smbios";
reg = <entry1>;
version = <2>;
};
smbios@entry2 {
compatible = "smbios";
reg = <entry2>;
version = <3>;
};
acpi@entry {
compatible = "acpi";
reg = <entry>;
version = <6>;
};
}
The reason why #size-cells is 0 is because only one item is needed,
#address-cells = <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 = "";
> > version = < 0x06 >;
> > }
> > }
>
> Thanks,
> Conor.
Thanks,
Yunhui
