> > By "use case" I mean our particular platform and firmware requirements > > -- or rather, the realities of building devices with widely > > multi-sourced LPDDR parts. One cannot efficiently build firmware that > > can pass an exact vendor-and-part-specific compatible string to Linux > > for this binding for every single LPDDR part used on such a platform. > > Why cannot? You want to pass them as numerical values which directly map > to vendor ID and some part, don't they? Yes, but the current compatible string format also requires the exact part number, of which there are many thousands and it's impossible to build a list in advance. Even for vendors, hardcoding 255 strings in a tight firmware space would be an unnecessary burden. There's also an update problem -- firmware may be built and signed and burned into ROM long before the assembly of the final mainboard. Board manufacturers want to be able to just drop-in replace a newly-sourced LPDDR part in their existing production line without having to worry if the existing (and possibly no longer changeable) firmware contains a string table entry for this part. If you just want the compatible string to be unique, encoding the numbers like Doug suggested (e.g. jedec,lpddr3-ff-0100) would work for us. > If we talk about standard, then DT purpose is not for autodetectable > pieces. These values are autodetectable, so such properties should not > be encoded in DT. But the DT is the only interface that we have to pass information from firmware to kernel and userspace. Where else should these properties be encoded? They are auto-detectable, but not for the kernel itself (only for memory-training firmware running in SRAM). Maybe the usual rules of thumb don't apply here, because unlike all other peripheral controllers the memory controller is special in that the kernel cannot simply reinitialize it and get the same information from the original source again.
