= > Devicetree bindings should be in vendor,prefix format. This doesn'= t
> represent every aspect of coreboot, so it needs a more descriptive
> string.

Any particular suggestion? I suppose this is Google's inter= pretation of
coreboot tables, so "google,coreboot"?

No. This binding is for the coreboot project in general and has nothi= ng to do with Google. coreboot is both the vendor and the product, so I thi= nk "coreboot" would look better than "coreboot,coreboot"= ;. And yes, it is supposed to represent every aspect of coreboot (right now= the "coreboot tables" are already sort of a catch-all data struc= ture used by coreboot to pass on any sort of info it wants later stages to = know... and if we ever have any additional things we'd like to pass on,= we'd probably want to add them to this binding as well).

=C2= =A0

> > + - reg: Address and length of the following two memory regions, = in order:
> > +=C2=A0 =C2=A01.) The coreboot table. This is a list of variable-= sized descriptors
> > +=C2=A0 =C2=A0that contain various compile- and run-time generate= d firmware
> > +=C2=A0 =C2=A0parameters. It is identified by the magic string &q= uot;LBIO" in its first
> > +=C2=A0 =C2=A0four bytes.
> > +=C2=A0 =C2=A0See coreboot's src/commonlib/include/commo= nlib/coreboot_tables.h for
> > +=C2=A0 =C2=A0details.
>
> Given this is a memory region, it should be described under the
> reserved-memory node.

We've painted this bikeshed before. I guess the result was eithe= r to use
/reserved-memory or /memreserve/. I believe we've been using
/memreserve/. I suppose we could document a method to use either, but
the main "agreement" was to use the /firmware/coreboot path inste= ad of
/reserved-memory/coreboot.

See the old = thread Brian linked for some arguments for and against this. I think partic= ularly because we want this node to represent every aspect of coreboot (whi= ch I think makes more sense than spreading stuff all over the place), treat= ing it as reserved memory would not work well if we might later add other f= ields.

Also, since we didn't get any more resp= onses the last time we tried to upstream this and had schedules to keep, we= had to go ahead with what we had. So right now there are already millions = of devices shipped with this binding in firmware, and the only question we = still have left to decide is whether Linux wants to support them upstream o= r not.

--001a1140338a2e3d61054b7f0dee--