On Tue, 19 Nov 2024 12:01:54 +0100, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> said: > Hi Bartosz, > > On Mon, Oct 21, 2024 at 8:36 PM Bartosz Golaszewski <brgl@xxxxxxxx> wrote: >> On Mon, Oct 21, 2024 at 8:14 PM Rob Herring <robh@xxxxxxxxxx> wrote: >> > On Sun, Oct 20, 2024 at 06:29:13AM +0200, Marek Vasut wrote: >> > > On 10/18/24 3:27 PM, Rob Herring wrote: >> > > > On Thu, Oct 17, 2024 at 08:41:25PM +0200, Marek Vasut wrote: >> > > > > The ST M24256E behaves as a regular M24C256, except for the E variant >> > > > > which uses up another I2C address for Additional Write lockable page. >> > > > > This page is 64 Bytes long and can contain additional data. Add entry >> > > > > for it, so users can describe that page in DT. Note that users still >> > > > > have to describe the main M24C256 area separately as that is on separate >> > > > > I2C address from this page. >> > > > >> > > > I think this should be modelled as 1 node having 2 addresses, not 2 >> > > > nodes. >> > > We had the exact same discussion regarding M24C32D, see: >> > > >> > > https://lore.kernel.org/all/CAMRc=MdTu1gagX-L4_cHmN9aUCoKhN-b5i7yEeszKSdr+BuROg@xxxxxxxxxxxxxx/ >> > >> > Seems like kernel implementation details dictating the binding to me. >> >> Yeah, that's on me. I would have known better today but 8 years ago >> the DT situation was much more volatile. > > And there's no way we can fix that for new devices? Perhaps even > for old devices, by counting the number of entries in the "reg" > compatible value? > For sure. We can always deprecate old bindings after upstreaming new ones but we'd need to still carry the model ID in the compatible string and remain backward compatible with existing DTs. So an existing example of: at24c01@57 { compatible = "atmel,24c01"; reg = <0x57>; }; at24cs01@5f { compatible = "atmel,24cs01"; reg = <0x5f>; }; Would become: at24cs01@57 { compatible = "atmel,24cs01"; reg = <0x57>, <0x5f>; }; Now the driver takes the "atmel,24cs01" compatible and needs to count the 'reg' items to determine whether to create one or two nvmem sub-devices. It's nothing impossible but would be quite tedious and make the driver so much more complex. I, for sure, don't have the bandwidth right now to tackle it but I'd happily help with testing and reviewing. Bart
