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. 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. 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. 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.
