lkml.org 
[lkml]   [2018]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2 06/29] mtd: Add support for reading MTD devices via the nvmem API
    On Mon, 20 Aug 2018 20:50:55 +0200
    Bartosz Golaszewski <brgl@bgdev.pl> wrote:

    > 2018-08-20 20:20 GMT+02:00 Boris Brezillon <boris.brezillon@bootlin.com>:
    > > On Mon, 20 Aug 2018 11:43:34 +0100
    > > Srinivas Kandagatla <srinivas.kandagatla@linaro.org> wrote:
    > >
    > >>
    > >> 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!!
    > >
    > > Something along those lines:
    > >
    > > mtdnode {
    > > nvmem-cells {
    > > #address-cells = <1>;
    > > #size-cells = <1>;
    > >
    > > cell@0 {
    > > reg = <0x0 0x14>;
    > > };
    > > };
    > >
    > > partitions {
    > > compatible = "fixed-partitions";
    > > #address-cells = <1>;
    > > #size-cells = <1>;
    > >
    > > partition@0 {
    > > reg = <0x0 0x20000>;
    > >
    > > nvmem-cells {
    > > #address-cells = <1>;
    > > #size-cells = <1>;
    > >
    > > cell@0 {
    > > reg = <0x0 0x10>;
    > > };
    > > };
    > > };
    > > };
    > > };
    >
    > If there'll be an agreement on the bindings: will you be willing to
    > merge Alban's patch even without support in the code for the above
    > (with the assumption that it will be added later)?

    No, because Alban's patch actually allows people to define and
    reference nvmem cells in a DT, but without documenting it (see my first
    reply).

    > My use-case is on
    > non-DT systems and creating nvmem devices corresponding to MTD
    > partitions if fine by me.

    What you propose is option #1 in my list of proposals, and it requires
    some changes to avoid automatically assigning nvmem->dev.of_node to
    parent->of_node (which will be != NULL when the MTD device has been
    instantiated from a DT node).

    > I also don't have the means to test the
    > support for these bindings if I were to actually write them myself.

    And that's the very reason I proposed #1. I don't want to block this
    stuff, but in its current state, I'm not willing to accept it either.
    Either we agree on the binding and patch the nvmem framework to support
    this new binding, or we find a way to hide the fact that the mtd
    device (the nvmem parent) has a DT node attached to it.

    \
     
     \ /
      Last update: 2018-08-20 21:06    [W:4.508 / U:0.056 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site