Re: [PATCH v5 3/9] dt-bindings: memory: lpddr2: Add revision-id properties

[Dmitry Osipenko <digetx@gmail.com>]

В Wed, 9 Feb 2022 16:32:25 -0800
Julius Werner <jwerner@chromium.org> пишет:

> > I don't mind, but I also don't see where the revision-id property of
> > LPDDR3 is used at all. I can't find any device-tree with LPDDR3
> > revision-id and don't see it being used in the code either. Maybe
> > it's the LPDDR3 binding that needs to be changed?  
> 
> We are using the revision ID in userspace (read through
> /proc/device-tree) for runtime memory identification. We don't have a
> kernel driver bound to it. Our boot firmware is inserting this value
> at runtime into the FDT (that's basically the reason we have this, our
> firmware auto-detects memory during boot and we use the FDT to report
> what it found to userspace), that's why you can't find it anywhere in
> the static device trees in boot/dts/.

Thank you for the clarification. Which device is that and why userspace
needs to know so much about memory?

> > I made each LPDDR2 revision-id property to correspond to a
> > dedicated MR of LPDDR, which feels okay to me to since it matches
> > h/w.  
> 
> I'm not super married to my solution, so if that makes things easier
> we can standardize on the two-property version as well. I mostly
> designed it my way because I thought we may one day also want to do
> something like this for the 8-byte LPDDR5 serial-id, and then it would
> get kinda cumbersome to have serial-id1 through serial-id8 all as
> separate properties. But that's also a bridge we can cross when we get
> there.
> 
> My use case is in a position where we could still change this now
> without requiring backwards-compatibility. Krzysztof, would you be
> okay if I instead changed the "jedec,lpddr3" to the same thing
> "jedec,lpddr2" does -- seeing as the original patch was from me, my
> use case could handle the switch, there has never been any actual
> kernel code using the property, and it seems very unlikely that anyone
> else has silently started using the same thing in the time it's been
> in the tree? Or do we also need to go the official deprecation route
> for that?

If you're going to use multiple cells for other properties, then indeed
will be better to keep it consistent.