On Wed, 18 Apr 2018 13:12:48 +0100
Srinivas Kandagatla <srinivas.kandagatla@xxxxxxxxxx> wrote:
> On 18/04/18 12:41, Alban wrote:
> > 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.
> >
>
> 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>;
> };
> };
> };
But the root cause is in the nvmem binding, this conflict could exists
with any device type, not just MTD. I don't understand why we would want
such workarounds instead of just fixing the problem once and for all.
Alban
Attachment:
pgpMuNp1Vor_X.pgp
Description: OpenPGP digital signature
