On 21/07/2022 01:42, Julius Werner wrote: > Sorry, got distracted from this for a bit. Sounds like we were pretty > much on the same page about how the updated binding should look like > here, the remaining question was just about the compatible string. > >>>> Yes, we can. You still would need to generate the compatible according >>>> to the current bindings. Whether we can change it I am not sure. I think >>>> it depends how much customization is possible per vendor, according to >>>> JEDEC spec. If we never ever have to identify specific part, because >>>> JEDEC spec and registers tell us everything, then we could skip it, >>>> similarly to lpddr2 and jedec,spi-nor. >>> >>> Shouldn't that be decided per use case? In general LPDDR is a pretty >>> rigid set of standards and memory controllers are generally compatible >>> with any vendor without hardcoding vendor-specific behavior, so I >>> don't anticipate that this would be likely (particularly since there >>> is no "real" kernel device driver that needs to initialize the full >>> memory controller, after all, these bindings are mostly >>> informational). >> >> If decided per use case understood as "decided depending how to use the >> bindings" then answer is rather not. For example Linux implementation is >> usually not the best argument to shape the bindings and usually to such >> arguments answer is: "implementation does not matter". >> >> If by "use case" you mean actual hardware or specification >> characteristics, then yes, of course. This is why I wrote "it depends". > > 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? > And I don't see why that should be needed, either... that's kinda the > point of having an interoperability standard, after all, that you can > just assume the devices all work according to the same spec and don't > need to hardcode details about each specific instance. 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. > > The existing bindings seem to have clearly been designed for platforms > that only ever use a single specific LPDDR part, and in those cases > these issues don't come up, so I assume this choice had just been made > without much thought. True. > But now I would like to reuse them on platforms > where this is a problem, and that's why I would like to either expand > or change the binding to (also) allow a generic compatible string to > solve it. (Whether that means moving all platforms to only use this > generic compatible string, or allowing it side-by-side with the > existing part-specific compatible strings is up to you -- I don't want > to preclude other platforms from doing what they prefer, I just want > to make sure there's some form of workable solution for my platform. > But if you would prefer this to be an all-or-nothing thing, we could > change everything over to a generic compatible string too if you > want.) > >>> Of course there may always be mistakes and broken >>> devices that need custom handling, and if someone has a platform with >>> such a case I of course don't want to preclude them from tying special >>> behavior to a custom compatible string. But why would that mean we >>> need to make this mandatory for all platforms even if it's not >>> relevant (and not practically feasible) for them? Why not allow both? >> >> Depends. If generic compatible is not enough (works only for your case) >> then it should have never been added alone. > > No, I don't think it would work only for my case -- in fact I think > it's pretty unlikely that we'll ever find a case where this doesn't > work. LPDDR is a very rigid standard that generally needs to be able > to interoperate (at the memory controller and firmware training code > level) without any vendor-specific software quirks. I was just trying > to say that I wouldn't want to stop anybody from adding > vendor-specific quirks for a platform if they really needed to -- but > I don't know of any such case in practice and I doubt it actually > exists. The few existing uses of this binding don't use the compatible > string for anything more than to parse out the manufacturer ID, which > I think would make much more sense to model as a property. Best regards, Krzysztof
