>> >> I don't think it makes sense to have this one-off in a particular >> >> driver. If at all, this should be handled in the core. Sorry, but >> >> this really looks like an ugly hack. >> >> >> > >> > Because the EUI identifier within the SFDP is unique to the >> > SST26VF064BEUI flash, I opted to handle it here rather than in the core. >> > >> > Also here the MAC address data resides within the 0x260-0x26F range, I >> > will resize the nvmem_config.size to 0x10 instead of registering the >> > full SFDP region as NVMEM. >> >> Open question to all parties in this thread: how do we give an offset in >> the device tree that is relative to the sfdp region and not the data >> region? I believe we care not to mix these areas while describing. > > You don't do it, because there is not even a relative offset that is > fixed. There should be a pointer to the vendor table inside the SFDP > structure. Thus, you need to properly parse it. If there is nothing static and the location can be derived by reading the chip tables, I'd suggest to offload this out of the spi-nor core and instead use some kind of an nvmem layout driver to retrieve the corresponding region? > Regarding how to reference it within the device tree, I'd assume > something along 'compatible = "jedec,sfdp-vendor-table-NNN";' or > similar. But no static/relative offsets. I see. We need to invoke our DT binding gurus. Cheers, Miquèl
