All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masahiro Yamada <yamada.masahiro@socionext.com>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Boris Brezillon <bbrezillon@kernel.org>,
	Richard Weinberger <richard@nod.at>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Marek Vasut <marek.vasut@gmail.com>,
	linux-mtd <linux-mtd@lists.infradead.org>,
	Brian Norris <computersforpeace@gmail.com>,
	David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH v3 2/9] mtd: rawnand: denali: refactor syndrome layout handling for raw access
Date: Fri, 29 Mar 2019 16:02:00 +0900	[thread overview]
Message-ID: <CAK7LNAQ08gL3ABaRwmbVZGgYwr54ahqLpvDGDP+0aRaUpZzcdQ@mail.gmail.com> (raw)
In-Reply-To: <20190315093429.35137adb@xps13>

Hi Miquel,


On Fri, Mar 15, 2019 at 5:34 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Masahiro,
>
> Masahiro Yamada <yamada.masahiro@socionext.com> wrote on Thu, 14 Mar
> 2019 17:24:41 +0900:
>
> > Hi Miquel,
> >
> > On Tue, Mar 12, 2019 at 10:13 PM Miquel Raynal
> > <miquel.raynal@bootlin.com> wrote:
> > >
> > > Hi Masahiro,
> > >
> > > Masahiro Yamada <yamada.masahiro@socionext.com> wrote on Tue, 12 Mar
> > > 2019 20:07:27 +0900:
> > >
> > > > Hi Miquel,
> > > >
> > > >
> > > > On Tue, Mar 12, 2019 at 7:54 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > >
> > > > > Hi Masahiro,
> > > > >
> > > > > Masahiro Yamada <yamada.masahiro@socionext.com> wrote on Tue, 12 Mar
> > > > > 2019 19:51:21 +0900:
> > > > >
> > > > > > On Tue, Mar 12, 2019 at 7:28 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > > > >
> > > > > > > Hi Masahiro,
> > > > > > >
> > > > > > > Masahiro Yamada <yamada.masahiro@socionext.com> wrote on Tue, 12 Mar
> > > > > > > 2019 17:44:43 +0900:
> > > > > > >
> > > > > > > > The Denali IP adopts the syndrome page layout (payload and ECC are
> > > > > > > > interleaved). The *_page_raw() and *_oob() callbacks are complicated
> > > > > > > > because they must hide the underlying layout used by the hardware,
> > > > > > > > and always return contiguous in-band and out-of-band data.
> > > > > > > >
> > > > > > > > Currently, similar code is duplicated to reorganize the data layout.
> > > > > > > > For example, denali_read_page_raw() and denali_write_page_raw() look
> > > > > > > > almost the same.
> > > > > > > >
> > > > > > > > The idea for refactoring is to split the code into two parts:
> > > > > > > >   [1] conversion of page layout
> > > > > > > >   [2] what to do at every ECC chunk boundary
> > > > > > > >
> > > > > > > > For [1], I wrote denali_raw_payload_op() and denali_raw_oob_op().
> > > > > > > > They manipulate data for the Denali controller's specific page layout
> > > > > > > > of in-band, out-of-band, respectively.
> > > > > > > >
> > > > > > > > The difference between write and read is just the operation at
> > > > > > > > ECC chunk boundaries. For example, denali_read_oob() calls
> > > > > > > > nand_change_read_column_op(), whereas denali_write_oob() calls
> > > > > > > > nand_change_write_column_op(). So, I implemented [2] as a callback
> > > > > > > > passed into [1].
> > > > > > > >
> > > > > > > > Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> > > > > > > > ---
> > > > > > > >
> > > > > > >
> > > > > > > [...]
> > > > > > >
> > > > > > > >  static int denali_read_page_raw(struct nand_chip *chip, uint8_t *buf,
> > > > > > > >                               int oob_required, int page)
> > > > > > > >  {
> > > > > > > > +     struct denali_nand_info *denali = to_denali(chip);
> > > > > > > >       struct mtd_info *mtd = nand_to_mtd(chip);
> > > > > > > > -     struct denali_nand_info *denali = mtd_to_denali(mtd);
> > > > > > > > -     int writesize = mtd->writesize;
> > > > > > > > -     int oobsize = mtd->oobsize;
> > > > > > > > -     int ecc_steps = chip->ecc.steps;
> > > > > > > > -     int ecc_size = chip->ecc.size;
> > > > > > > > -     int ecc_bytes = chip->ecc.bytes;
> > > > > > > >       void *tmp_buf = denali->buf;
> > > > > > > > -     int oob_skip = denali->oob_skip_bytes;
> > > > > > > > -     size_t size = writesize + oobsize;
> > > > > > > > -     int ret, i, pos, len;
> > > > > > > > +     size_t size = mtd->writesize + mtd->oobsize;
> > > > > > > > +     int ret;
> > > > > > > > +
> > > > > > > > +     if (!buf)
> > > > > > > > +             return -EINVAL;
> > > > > > > >
> > > > > > > >       ret = denali_data_xfer(chip, tmp_buf, size, page, 1, 0);
> > > > > > > >       if (ret)
> > > > > > > >               return ret;
> > > > > > > >
> > > > > > > > -     /* Arrange the buffer for syndrome payload/ecc layout */
> > > > > > > > -     if (buf) {
> > > > > > > > -             for (i = 0; i < ecc_steps; i++) {
> > > > > > > > -                     pos = i * (ecc_size + ecc_bytes);
> > > > > > > > -                     len = ecc_size;
> > > > > > > > -
> > > > > > > > -                     if (pos >= writesize)
> > > > > > > > -                             pos += oob_skip;
> > > > > > > > -                     else if (pos + len > writesize)
> > > > > > > > -                             len = writesize - pos;
> > > > > > > > -
> > > > > > > > -                     memcpy(buf, tmp_buf + pos, len);
> > > > > > > > -                     buf += len;
> > > > > > > > -                     if (len < ecc_size) {
> > > > > > > > -                             len = ecc_size - len;
> > > > > > > > -                             memcpy(buf, tmp_buf + writesize + oob_skip,
> > > > > > > > -                                    len);
> > > > > > > > -                             buf += len;
> > > > > > > > -                     }
> > > > > > > > -             }
> > > > > > > > -     }
> > > > > > > > +     ret = denali_raw_payload_op(chip, buf, denali_memcpy_in, tmp_buf);
> > > > > > >
> > > > > > > Honestly, I still don't like passing denali_memcpy_in/out as parameter.
> > > > > > >
> > > > > > > Besides that, once you'll have added helpers to avoid abusing the
> > > > > > > ternary operator in 4/9, the rest looks fine by me.
> > > > > > >
> > > > > >
> > > > > >
> > > > > > Do you have any suggestion?
> > > > >
> > > > > Maybe register these two helpers at probe as controller specific hooks,
> > > > > then just pass an in/out boolean to the function?
> > > > >
> > > >
> > > > Sorry, I do not understand.
> > > >
> > > > Are you suggesting to do like follows in probe ?
> > > >
> > > > denali->change_column_read_raw = denali_memcpy_in;
> > > > denali->change_column_write_raw = denali_memcpy_out;
> > > > denali->change_column_read_oob = denali_change_read_column_op;
> > > > denali->change_column_write_oob = denali_change_write_column_op;
> > > >
> > > >
> > > > All the 4 hooks are always needed
> > > > regardless of any probed features.
> > > >
> > > >
> > > > The result is just textual replacement
> > > > denali_* with denali->*.
> > > >
> > > > What's the point of copying fixed function addresses
> > > > to denali structure?
> > > >
> > > >
> > >
> > > What I don't like is the function pointer as a function parameter.
> >
> > This is a usual way to handle callback.
> >
> > > You
> > > can use the functions defined statically if you prefer as long as the
> > > parameter is just a boolean for instance?
> >
> >
> >
> > I still do not understand your concern,
> > but if you ban the use of function pointer,
> > the following is the best I can do
> > since there are 4 hooks depending on the
> > combination of oob/raw, write/read.
> >
> >
> >
> > if (oob) {
> >         if (write)
> >                 return nand_change_write_column_op(chip, offset, buf,
> >                                                    len, false);
> >         else
> >                 return nand_change_read_column_op(chip, offset, buf,
> >                                                   len, false);
> > }
> >
> > if (write)
> >         memcpy(denali->buf + offset, buf, len);
> > else
> >         memcpy(buf, denali->buf + offset, len);
> >
> > return 0;
>
> No, I meant passing a boolean to denali_raw_payload_op() instead of a
> function pointer. Then from denali_raw_payload_op(), intead of doing
>
> ret = cb();
> if (ret)
>         ...
>
> doing:
>
> if (read)
>         ret = denali_memcpy_in()
> else
>         ret = denali_memcpy_out()
>
> if (ret)
>         ...


If you look at my code closely,
you will notice 4 callbacks passed in
denali_raw_payload_op().

So, if-conditional would end up like follows:


    if (oob) {
            if (write)
                    ret = nand_change_write_column_op(chip, offset, buf,
                                                   len, false);
            else
                    ret = nand_change_read_column_op(chip, offset, buf,
                                                  len, false);
            if (ret)
                    return ret;
     } else {
            if (write)
                  memcpy(denali->buf + offset, buf, len);
            else
                  memcpy(buf, denali->buf + offset, len);
     }


This is extremely ugly.
That's why I passed a function pointer
instead of two boolean parameters 'oob', 'write'.




> But nevermind, if this is bothering you too much let's keep the current
> form, it's fine.
>
> >
> >
> > BTW, when are .read_page_raw / .write_page_raw used?
>
> I'm not sure what is the question here but these hooks are important
> and allow to test the driver. nandbiterrs use them (although we do
> not care about the performance in these hooks).


Currently, I use DMA transfer + memcpy()
in order to get better performance for
.read_page_raw() and .write_page_raw()


nand_change_write_column_op() and
nand_change_read_column_op() are slow
since they are low-level hardware accesses.


If we do not have to care about the performance,
I will only use nand_change_{write,read}_column_op().




> >
> > Currently, I use "whole page access && memcpy" for better performance.
> >
> > If those hooks are rarely used, I use
> > nand_change_write_column_op / nand_change_read_column_op,
> > which will reduce the if-conditional.
>
> Yes you can. We do not care about performance in raw accessors.

OK, I will do this in v4.




> Thanks,
> Miquèl
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/



-- 
Best Regards
Masahiro Yamada

WARNING: multiple messages have this Message-ID (diff)
From: Masahiro Yamada <yamada.masahiro@socionext.com>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Boris Brezillon <bbrezillon@kernel.org>,
	Richard Weinberger <richard@nod.at>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Marek Vasut <marek.vasut@gmail.com>,
	linux-mtd <linux-mtd@lists.infradead.org>,
	Brian Norris <computersforpeace@gmail.com>,
	David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH v3 2/9] mtd: rawnand: denali: refactor syndrome layout handling for raw access
Date: Fri, 29 Mar 2019 16:02:00 +0900	[thread overview]
Message-ID: <CAK7LNAQ08gL3ABaRwmbVZGgYwr54ahqLpvDGDP+0aRaUpZzcdQ@mail.gmail.com> (raw)
In-Reply-To: <20190315093429.35137adb@xps13>

Hi Miquel,


On Fri, Mar 15, 2019 at 5:34 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Masahiro,
>
> Masahiro Yamada <yamada.masahiro@socionext.com> wrote on Thu, 14 Mar
> 2019 17:24:41 +0900:
>
> > Hi Miquel,
> >
> > On Tue, Mar 12, 2019 at 10:13 PM Miquel Raynal
> > <miquel.raynal@bootlin.com> wrote:
> > >
> > > Hi Masahiro,
> > >
> > > Masahiro Yamada <yamada.masahiro@socionext.com> wrote on Tue, 12 Mar
> > > 2019 20:07:27 +0900:
> > >
> > > > Hi Miquel,
> > > >
> > > >
> > > > On Tue, Mar 12, 2019 at 7:54 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > >
> > > > > Hi Masahiro,
> > > > >
> > > > > Masahiro Yamada <yamada.masahiro@socionext.com> wrote on Tue, 12 Mar
> > > > > 2019 19:51:21 +0900:
> > > > >
> > > > > > On Tue, Mar 12, 2019 at 7:28 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > > > >
> > > > > > > Hi Masahiro,
> > > > > > >
> > > > > > > Masahiro Yamada <yamada.masahiro@socionext.com> wrote on Tue, 12 Mar
> > > > > > > 2019 17:44:43 +0900:
> > > > > > >
> > > > > > > > The Denali IP adopts the syndrome page layout (payload and ECC are
> > > > > > > > interleaved). The *_page_raw() and *_oob() callbacks are complicated
> > > > > > > > because they must hide the underlying layout used by the hardware,
> > > > > > > > and always return contiguous in-band and out-of-band data.
> > > > > > > >
> > > > > > > > Currently, similar code is duplicated to reorganize the data layout.
> > > > > > > > For example, denali_read_page_raw() and denali_write_page_raw() look
> > > > > > > > almost the same.
> > > > > > > >
> > > > > > > > The idea for refactoring is to split the code into two parts:
> > > > > > > >   [1] conversion of page layout
> > > > > > > >   [2] what to do at every ECC chunk boundary
> > > > > > > >
> > > > > > > > For [1], I wrote denali_raw_payload_op() and denali_raw_oob_op().
> > > > > > > > They manipulate data for the Denali controller's specific page layout
> > > > > > > > of in-band, out-of-band, respectively.
> > > > > > > >
> > > > > > > > The difference between write and read is just the operation at
> > > > > > > > ECC chunk boundaries. For example, denali_read_oob() calls
> > > > > > > > nand_change_read_column_op(), whereas denali_write_oob() calls
> > > > > > > > nand_change_write_column_op(). So, I implemented [2] as a callback
> > > > > > > > passed into [1].
> > > > > > > >
> > > > > > > > Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> > > > > > > > ---
> > > > > > > >
> > > > > > >
> > > > > > > [...]
> > > > > > >
> > > > > > > >  static int denali_read_page_raw(struct nand_chip *chip, uint8_t *buf,
> > > > > > > >                               int oob_required, int page)
> > > > > > > >  {
> > > > > > > > +     struct denali_nand_info *denali = to_denali(chip);
> > > > > > > >       struct mtd_info *mtd = nand_to_mtd(chip);
> > > > > > > > -     struct denali_nand_info *denali = mtd_to_denali(mtd);
> > > > > > > > -     int writesize = mtd->writesize;
> > > > > > > > -     int oobsize = mtd->oobsize;
> > > > > > > > -     int ecc_steps = chip->ecc.steps;
> > > > > > > > -     int ecc_size = chip->ecc.size;
> > > > > > > > -     int ecc_bytes = chip->ecc.bytes;
> > > > > > > >       void *tmp_buf = denali->buf;
> > > > > > > > -     int oob_skip = denali->oob_skip_bytes;
> > > > > > > > -     size_t size = writesize + oobsize;
> > > > > > > > -     int ret, i, pos, len;
> > > > > > > > +     size_t size = mtd->writesize + mtd->oobsize;
> > > > > > > > +     int ret;
> > > > > > > > +
> > > > > > > > +     if (!buf)
> > > > > > > > +             return -EINVAL;
> > > > > > > >
> > > > > > > >       ret = denali_data_xfer(chip, tmp_buf, size, page, 1, 0);
> > > > > > > >       if (ret)
> > > > > > > >               return ret;
> > > > > > > >
> > > > > > > > -     /* Arrange the buffer for syndrome payload/ecc layout */
> > > > > > > > -     if (buf) {
> > > > > > > > -             for (i = 0; i < ecc_steps; i++) {
> > > > > > > > -                     pos = i * (ecc_size + ecc_bytes);
> > > > > > > > -                     len = ecc_size;
> > > > > > > > -
> > > > > > > > -                     if (pos >= writesize)
> > > > > > > > -                             pos += oob_skip;
> > > > > > > > -                     else if (pos + len > writesize)
> > > > > > > > -                             len = writesize - pos;
> > > > > > > > -
> > > > > > > > -                     memcpy(buf, tmp_buf + pos, len);
> > > > > > > > -                     buf += len;
> > > > > > > > -                     if (len < ecc_size) {
> > > > > > > > -                             len = ecc_size - len;
> > > > > > > > -                             memcpy(buf, tmp_buf + writesize + oob_skip,
> > > > > > > > -                                    len);
> > > > > > > > -                             buf += len;
> > > > > > > > -                     }
> > > > > > > > -             }
> > > > > > > > -     }
> > > > > > > > +     ret = denali_raw_payload_op(chip, buf, denali_memcpy_in, tmp_buf);
> > > > > > >
> > > > > > > Honestly, I still don't like passing denali_memcpy_in/out as parameter.
> > > > > > >
> > > > > > > Besides that, once you'll have added helpers to avoid abusing the
> > > > > > > ternary operator in 4/9, the rest looks fine by me.
> > > > > > >
> > > > > >
> > > > > >
> > > > > > Do you have any suggestion?
> > > > >
> > > > > Maybe register these two helpers at probe as controller specific hooks,
> > > > > then just pass an in/out boolean to the function?
> > > > >
> > > >
> > > > Sorry, I do not understand.
> > > >
> > > > Are you suggesting to do like follows in probe ?
> > > >
> > > > denali->change_column_read_raw = denali_memcpy_in;
> > > > denali->change_column_write_raw = denali_memcpy_out;
> > > > denali->change_column_read_oob = denali_change_read_column_op;
> > > > denali->change_column_write_oob = denali_change_write_column_op;
> > > >
> > > >
> > > > All the 4 hooks are always needed
> > > > regardless of any probed features.
> > > >
> > > >
> > > > The result is just textual replacement
> > > > denali_* with denali->*.
> > > >
> > > > What's the point of copying fixed function addresses
> > > > to denali structure?
> > > >
> > > >
> > >
> > > What I don't like is the function pointer as a function parameter.
> >
> > This is a usual way to handle callback.
> >
> > > You
> > > can use the functions defined statically if you prefer as long as the
> > > parameter is just a boolean for instance?
> >
> >
> >
> > I still do not understand your concern,
> > but if you ban the use of function pointer,
> > the following is the best I can do
> > since there are 4 hooks depending on the
> > combination of oob/raw, write/read.
> >
> >
> >
> > if (oob) {
> >         if (write)
> >                 return nand_change_write_column_op(chip, offset, buf,
> >                                                    len, false);
> >         else
> >                 return nand_change_read_column_op(chip, offset, buf,
> >                                                   len, false);
> > }
> >
> > if (write)
> >         memcpy(denali->buf + offset, buf, len);
> > else
> >         memcpy(buf, denali->buf + offset, len);
> >
> > return 0;
>
> No, I meant passing a boolean to denali_raw_payload_op() instead of a
> function pointer. Then from denali_raw_payload_op(), intead of doing
>
> ret = cb();
> if (ret)
>         ...
>
> doing:
>
> if (read)
>         ret = denali_memcpy_in()
> else
>         ret = denali_memcpy_out()
>
> if (ret)
>         ...


If you look at my code closely,
you will notice 4 callbacks passed in
denali_raw_payload_op().

So, if-conditional would end up like follows:


    if (oob) {
            if (write)
                    ret = nand_change_write_column_op(chip, offset, buf,
                                                   len, false);
            else
                    ret = nand_change_read_column_op(chip, offset, buf,
                                                  len, false);
            if (ret)
                    return ret;
     } else {
            if (write)
                  memcpy(denali->buf + offset, buf, len);
            else
                  memcpy(buf, denali->buf + offset, len);
     }


This is extremely ugly.
That's why I passed a function pointer
instead of two boolean parameters 'oob', 'write'.




> But nevermind, if this is bothering you too much let's keep the current
> form, it's fine.
>
> >
> >
> > BTW, when are .read_page_raw / .write_page_raw used?
>
> I'm not sure what is the question here but these hooks are important
> and allow to test the driver. nandbiterrs use them (although we do
> not care about the performance in these hooks).


Currently, I use DMA transfer + memcpy()
in order to get better performance for
.read_page_raw() and .write_page_raw()


nand_change_write_column_op() and
nand_change_read_column_op() are slow
since they are low-level hardware accesses.


If we do not have to care about the performance,
I will only use nand_change_{write,read}_column_op().




> >
> > Currently, I use "whole page access && memcpy" for better performance.
> >
> > If those hooks are rarely used, I use
> > nand_change_write_column_op / nand_change_read_column_op,
> > which will reduce the if-conditional.
>
> Yes you can. We do not care about performance in raw accessors.

OK, I will do this in v4.




> Thanks,
> Miquèl
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/



-- 
Best Regards
Masahiro Yamada

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

  reply	other threads:[~2019-03-29  7:02 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-12  8:44 [PATCH v3 0/9] mtd: rawnand: denali: exec_op(), controller/chip separation, and cleanups Masahiro Yamada
2019-03-12  8:44 ` Masahiro Yamada
2019-03-12  8:44 ` [PATCH v3 1/9] mtd: rawnand: denali: use nand_chip pointer more for internal functions Masahiro Yamada
2019-03-12  8:44   ` Masahiro Yamada
2019-03-12  8:44 ` [PATCH v3 2/9] mtd: rawnand: denali: refactor syndrome layout handling for raw access Masahiro Yamada
2019-03-12  8:44   ` Masahiro Yamada
2019-03-12 10:28   ` Miquel Raynal
2019-03-12 10:28     ` Miquel Raynal
2019-03-12 10:51     ` Masahiro Yamada
2019-03-12 10:51       ` Masahiro Yamada
2019-03-12 10:54       ` Miquel Raynal
2019-03-12 10:54         ` Miquel Raynal
2019-03-12 11:07         ` Masahiro Yamada
2019-03-12 11:07           ` Masahiro Yamada
2019-03-12 13:13           ` Miquel Raynal
2019-03-12 13:13             ` Miquel Raynal
2019-03-14  8:24             ` Masahiro Yamada
2019-03-14  8:24               ` Masahiro Yamada
2019-03-15  8:34               ` Miquel Raynal
2019-03-15  8:34                 ` Miquel Raynal
2019-03-29  7:02                 ` Masahiro Yamada [this message]
2019-03-29  7:02                   ` Masahiro Yamada
2019-03-12  8:44 ` [PATCH v3 3/9] mtd: rawnand: denali: remove unneeded casts in denali_{read,write}_pio Masahiro Yamada
2019-03-12  8:44   ` [PATCH v3 3/9] mtd: rawnand: denali: remove unneeded casts in denali_{read, write}_pio Masahiro Yamada
2019-03-12  8:44 ` [PATCH v3 4/9] mtd: rawnand: denali: switch over to ->exec_op() from legacy hooks Masahiro Yamada
2019-03-12  8:44   ` Masahiro Yamada
2019-03-12  9:02   ` Boris Brezillon
2019-03-12  9:02     ` Boris Brezillon
2019-03-12  9:47     ` Masahiro Yamada
2019-03-12  9:47       ` Masahiro Yamada
2019-03-12  8:44 ` [PATCH v3 5/9] mtd: rawnand: denali: use bool type instead of int where appropriate Masahiro Yamada
2019-03-12  8:44   ` Masahiro Yamada
2019-03-12  8:44 ` [PATCH v3 6/9] mtd: rawnand: denali_pci: rename goto labels Masahiro Yamada
2019-03-12  8:44   ` Masahiro Yamada
2019-03-12  8:44 ` [PATCH v3 7/9] mtd: rawnand: denali: decouple controller and NAND chips Masahiro Yamada
2019-03-12  8:44   ` Masahiro Yamada
2019-03-12  8:44 ` [PATCH v3 8/9] mtd: rawnand: denali: remove DENALI_NR_BANKS macro Masahiro Yamada
2019-03-12  8:44   ` Masahiro Yamada
2019-03-12  8:44 ` [PATCH v3 9/9] mtd: rawnand: denali: clean up coding style Masahiro Yamada
2019-03-12  8:44   ` Masahiro Yamada

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAK7LNAQ08gL3ABaRwmbVZGgYwr54ahqLpvDGDP+0aRaUpZzcdQ@mail.gmail.com \
    --to=yamada.masahiro@socionext.com \
    --cc=bbrezillon@kernel.org \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marek.vasut@gmail.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.