On Tue, 17 Apr 2018 18:00:40 +0200
Alban <albeu@xxxxxxx> wrote:
> On Tue, 17 Apr 2018 16:44:01 +0100
> Srinivas Kandagatla <srinivas.kandagatla@xxxxxxxxxx> 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.
Alban
Attachment:
pgp_hVdytAFg8.pgp
Description: OpenPGP digital signature
