On 18/04/18 14:34, Alban wrote:
On Wed, 18 Apr 2018 13:53:56 +0100
Srinivas Kandagatla <srinivas.kandagatla@xxxxxxxxxx> wrote:
On 18/04/18 13:32, Alban wrote:
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
No, the root cause is because of passing wrong device instance to nvmem
core. And trying to workaround is the actual issue.
The data is stored on the MTD, so the nvmem provider is the MTD device.
I don't think it is a good idea to have a virtual device in the DT to
accommodate the nvmem API.
Yep, I agree! this is same issue if we make nvmem-cells a child of nvmem
provider too.
However, I would like to see this moving forward.
I can think of one possible solution here, which is, adding
"nvmem-mtd-cell" or "nvmem-cell" compatible string to each cell. The
problem you mentioned regarding #address-cells and #size-cells with
provider need to be addressed in nvmem core.
Currently nvmem core only support offsets of 32 bits, if you are
expecting a 64 bit offsets then we should add that as a feature to nvmem
core.
nvmem core as it is today should work fine with 32 bit offsets for mtd
cases.
what do you think?
thanks,
srini
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
