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