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