Messages in this thread | | | Subject | Re: [PATCH v3 1/3] nvmem: Update the OF binding to use a subnode for the cells list | From | Srinivas Kandagatla <> | Date | Wed, 18 Apr 2018 13:12:48 +0100 |
| |
On 18/04/18 12:41, Alban wrote: > On Tue, 17 Apr 2018 18:00:40 +0200 > Alban <albeu@free.fr> wrote: > >> On Tue, 17 Apr 2018 16:44:01 +0100 >> Srinivas Kandagatla <srinivas.kandagatla@linaro.org> wrote: >> >>> Thanks for explaining, >>> >>> On 17/04/18 15:54, Alban wrote: >>>> This will not only allow reading the calibration data from nvmem, but >>>> will also create a partition on the MTD device, which is not acceptable. >>>> With my proposed binding this would become: >>>> >>>> flash@0 { >>>> #address-cells = <1>; >>>> #size-cells = <1>; >>>> compatible = "s25sl064a"; >>>> reg = <0>; >>>> >>>> nvmem-cells { >>>> compatible = "nvmem-cells"; >>>> #address-cells = <1>; >>>> #address-cells = <1>; >>>> >>>> calibration: calib@404 { >>>> reg = <0x404 0x10>; >>>> }; >>>> }; >>> >>> Why can't we make nvmem-cells node a nvmem provider in this case? >>> Which should work! >> >> TBH I just copied what have been done to fix the same problem with the >> MTD partitions. But yes we could also just extend the current binding >> to require a compatible string on each nvmem-cell, which would not >> require any code change to support. > > However this scheme will not work if the device node binding already > have subnodes with addresses. The addressing, as specified by > #address-cells and #size-cells, might be incompatible or might overlap. > Using the nvmem-cells subnode solve this problem. >
I was also suggesting you to use nvmem-cell subnode, but make it a proper nvmem provider device, rather than reusing its parent device.
You would end up some thing like this in dt.
flash@0 { #address-cells = <1>; #size-cells = <1>; compatible = "s25sl064a"; reg = <0>;
nvmem-cells { compatible = "mtd-nvmem"; #address-cells = <1>; #size-cells = <1>;
calibration: calib@404 { reg = <0x404 0x10>; }; }; };
--srini
> Alban >
| |