Hi Marco, > > > > Overall I think the idea of getting rid of these misc/ drivers is goes > > > > into the right direction, but registering directly into NVMEM makes > > > > more sense IMO. > > > > > > So you propose to have two places for the partition handling (one for > > > MTD and one for NVMEM) instead of one and moving the code into NVMEM > > > directly? > > > > Why two places for the partitions handling? Just one, in NVMEM. Also > > Without checking the details I think that converting the MTD > partitioning code into NVMEM partitioning code is a bigger task. As you > said below there are many legacy code paths you need to consider so they > still work afterwards as well. > > > usually EEPROMs don't require very advanced partitioning schemes, > > unlike flashes (which are the most common MTD devices today). > > As said in my cover letter EEPROMs can become quite large and MTD > supports partitioning storage devices which is very handy for large > EEPROMs as well. Did you had a look at nvmem-layouts ? In particular the fixed-layout. Is there anything you would like to achieve already that is not possible with nvmem but is with mtd? Thanks, Miquèl
