Re: [PATCH v2 06/29] mtd: Add support for reading MTD devices via the nvmem API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks Boris, for looking into this in more detail.

On 19/08/18 17:46, Boris Brezillon wrote:
On Sun, 19 Aug 2018 13:31:06 +0200
Alban <albeu@xxxxxxx> wrote:

On Fri, 17 Aug 2018 18:27:20 +0200
Boris Brezillon <boris.brezillon@xxxxxxxxxxx> wrote:

Hi Bartosz,

On Fri, 10 Aug 2018 10:05:03 +0200
Bartosz Golaszewski <brgl@xxxxxxxx> wrote:
From: Alban Bedel <albeu@xxxxxxx>

Allow drivers that use the nvmem API to read data stored on MTD devices.
For this the mtd devices are registered as read-only NVMEM providers.

Signed-off-by: Alban Bedel <albeu@xxxxxxx>
[Bartosz:
   - use the managed variant of nvmem_register(),
   - set the nvmem name]
Signed-off-by: Bartosz Golaszewski <bgolaszewski@xxxxxxxxxxxx>

What happened to the 2 other patches of Alban's series? I'd really
like the DT case to be handled/agreed on in the same patchset, but
IIRC, Alban and Srinivas disagreed on how this should be represented.
I hope this time we'll come to an agreement, because the MTD <-> NVMEM
glue has been floating around for quite some time...

These other patches were to fix what I consider a fundamental flaw in
the generic NVMEM bindings, however we couldn't agree on this point.
Bartosz later contacted me to take over this series and I suggested to
just change the MTD NVMEM binding to use a compatible string on the
NVMEM cells as an alternative solution to fix the clash with the old
style MTD partition.

However all this has no impact on the code needed to add NVMEM support
to MTD, so the above patch didn't change at all.

It does have an impact on the supported binding though.
nvmem->dev.of_node is automatically assigned to mtd->dev.of_node, which
means people will be able to define their NVMEM cells directly under
the MTD device and reference them from other nodes (even if it's not
documented), and as you said, it conflict with the old MTD partition
bindings. So we'd better agree on this binding before merging this
patch.


Yes, I agree with you!

I see several options:

1/ provide a way to tell the NVMEM framework not to use parent->of_node
    even if it's != NULL. This way we really don't support defining
    NVMEM cells in the DT, and also don't support referencing the nvmem
    device using a phandle.

Other options look much better than this one!

2/ define a new binding where all nvmem-cells are placed in an
    "nvmem" subnode (just like we have this "partitions" subnode for
    partitions), and then add a config->of_node field so that the
    nvmem provider can explicitly specify the DT node representing the
    nvmem device. We'll also need to set this field to ERR_PTR(-ENOENT)
    in case this node does not exist so that the nvmem framework knows
    that it should not assign nvmem->dev.of_node to parent->of_node

This one looks promising, One Question though..

Do we expect that there would be nvmem cells in any of the partitions?
or
nvmem cell are only valid for unpartioned area?

Am sure that the nvmem cells would be in multiple partitions, Is it okay to have some parts of partition to be in a separate subnode?

I would like this case to be considered too.

3/ only declare partitions as nvmem providers. This would solve the
    problem we have with partitions defined in the DT since
    defining sub-partitions in the DT is not (yet?) supported and
    partition nodes are supposed to be leaf nodes. Still, I'm not a big
    fan of this solution because it will prevent us from supporting
    sub-partitions if we ever want/need to.

This one is going to come back so, its better we

4/ Add a ->of_xlate() hook that would be called if present by the
    framework instead of using the default parsing we have right now.
This looks much cleaner! We could hook that up under __nvmem_device_get() to do that translation.


5/ Tell the nvmem framework the name of the subnode containing nvmem
    cell definitions (if NULL that means cells are directly defined
    under the nvmem provider node). We would set it to "nvmem-cells" (or
    whatever you like) for the MTD case.
Option 2 looks better than this.


There are probably other options (some were proposed by Alban and
Srinivas already), but I'd like to get this sorted out before we merge
this patch.

Alban, Srinivas, any opinion?

Overall am still not able to clear visualize on how MTD bindings with nvmem cells would look in both partition and un-partition usecases?
An example DT would be nice here!!

Option 4 looks like much generic solution to me, may be we should try this once bindings on MTD side w.r.t nvmem cells are decided.

Thanks,
Srini



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux