linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: masonccyang@mxic.com.tw
To: "Miquel Raynal" <miquel.raynal@bootlin.com>
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
	christophe.kerello@st.com, bbrezillon@kernel.org,
	juliensu@mxic.com.tw, lee.jones@linaro.org,
	linux-kernel@vger.kernel.org, robh+dt@kernel.org,
	linux-spi@vger.kernel.org, marcel.ziswiler@toradex.com,
	paul.burton@mips.com, broonie@kernel.org, geert@linux-m68k.org,
	stefan@agner.ch, linux-mtd@lists.infradead.org, richard@nod.at,
	liang.yang@amlogic.com, computersforpeace@gmail.com,
	dwmw2@infradead.org, marek.vasut@gmail.com,
	zhengxunli@mxic.com.tw
Subject: Re: [PATCH v3 2/4] mtd: rawnand: Add Macronix MX25F0A NAND controller
Date: Wed, 15 May 2019 16:48:46 +0800	[thread overview]
Message-ID: <OF8A566F14.A2F0F576-ON482583FB.002E7E32-482583FB.003068BA@mxic.com.tw> (raw)
In-Reply-To: <20190512151820.4f2dd9da@xps13>


Hi Miquel,

> > +// SPDX-License-Identifier: GPL-2.0
> > +//
> > +// Copyright (C) 2019 Macronix International Co., Ltd.
> > +//
> > +// Authors:
> > +//   Mason Yang <masonccyang@mxic.com.tw>
> > +//   zhengxunli <zhengxunli@mxic.com.tw>
> 
> This is not a valid name.
> 
> Also if he appears here I suppose he should be credited in the
> module_authors() macro too.

I think Li should maintain this NAND driver later, 
anyway, I may remove him.

> 
> > +//
> 
> As a personal taste, I prefer when the header uses /* */ and only the
> SPDX tag uses //.

okay, only SPDX tag use //

> 
> > +
> > +#include <linux/mfd/mxic-mx25f0a.h>
> > +#include <linux/mtd/rawnand.h>
> > +#include <linux/mtd/nand_ecc.h>
> > +
> > +#include "internals.h"
> > +
> > +struct mxic_nand_ctlr {
> > +   struct mx25f0a_mfd *mfd;
> > +   struct nand_controller base;
> > +   struct nand_chip nand;
> 
> Even if this controller only supports one CS (and then, one chip),
> please have a clear separation between the NAND controller and the NAND
> chip by having one structure for the NAND chips and one structure for
> the NAND controller.

okay, will patch it.

> 
> > +};
> > +
> > +static void mxic_host_init(struct mxic_nand_ctlr *mxic)
> 
> Please choose a constant prefix for all functions, right now there is:
> mxic_
> mxic_nand_
> mx25f0a_nand_
> 
> I think mxic_nand_ or mx25f0a_nand_ is wise.

okay, will use mxic_nand_ as prefix. 

> 
> > +{
> > +   writel(DATA_STROB_EDO_EN, mxic->mfd->regs + DATA_STROB);
> > +   writel(INT_STS_ALL, mxic->mfd->regs + INT_STS_EN);
> > +   writel(0x0, mxic->mfd->regs + ONFI_DIN_CNT(0));
> > +   writel(HC_CFG_NIO(8) | HC_CFG_SLV_ACT(0) | HC_CFG_IDLE_SIO_LVL(1) 
|
> > +          HC_CFG_TYPE(1, HC_CFG_TYPE_RAW_NAND) | HC_CFG_MAN_CS_EN,
> > +          mxic->mfd->regs + HC_CFG);
> > +   writel(0x0, mxic->mfd->regs + HC_EN);
> > +}
> > +
> > +static int  mxic_nand_wait_ready(struct nand_chip *chip)
> > +{
> > +   struct mxic_nand_ctlr *mxic = nand_get_controller_data(chip);
> > +   u32 sts;
> > +
> > +   return readl_poll_timeout(mxic->mfd->regs + INT_STS, sts,
> > +              sts & INT_RDY_PIN, 0, USEC_PER_SEC);
> > +}
> > +
> > +static void mxic_nand_select_chip(struct nand_chip *chip, int chipnr)
> 
> _select_target() is preferred now
> 
> > +{
> > +   struct mxic_nand_ctlr *mxic = nand_get_controller_data(chip);
> > +
> > +   switch (chipnr) {
> > +   case 0:
> > +   case 1:
> > +      writel(HC_EN_BIT, mxic->mfd->regs + HC_EN);
> > +      writel(HC_CFG_MAN_CS_ASSERT | readl(mxic->mfd->regs + HC_CFG),
> > +             mxic->mfd->regs + HC_CFG);
> 
> In both case I would prefer a:
> 
>         reg = readl(...);
>         reg &= ~xxx;
>    reg |= yyy;
>    writel(reg, ...);
> 
> Much easier to read.
> 
> > +      break;
> > +
> > +   case -1:
> > +      writel(~HC_CFG_MAN_CS_ASSERT & readl(mxic->mfd->regs + HC_CFG),
> > +             mxic->mfd->regs + HC_CFG);
> > +      writel(0, mxic->mfd->regs + HC_EN);
> > +      break;
> > +
> > +   default:
> 
> Error?
> 
> > +      break;
> > +   }
> > +}
> > +
> > +static int mxic_nand_data_xfer(struct mxic_nand_ctlr *mxic, const 
void *txbuf,
> > +                void *rxbuf, unsigned int len)
> > +{
> 
> There is not so much code shared, why not separating this function for
> rx and tx cases?
> 
> > +   unsigned int pos = 0;
> > +
> > +   while (pos < len) {
> > +      unsigned int nbytes = len - pos;
> > +      u32 data = 0xffffffff;
> > +      u32 sts;
> > +      int ret;
> > +
> > +      if (nbytes > 4)
> > +         nbytes = 4;
> > +
> > +      if (txbuf)
> > +         memcpy(&data, txbuf + pos, nbytes);
> > +
> > +      ret = readl_poll_timeout(mxic->mfd->regs + INT_STS, sts,
> > +                sts & INT_TX_EMPTY, 0, USEC_PER_SEC);
> 
> Using USEC_PER_SEC for a delay is weird
> 
> > +      if (ret)
> > +         return ret;
> > +
> > +      writel(data, mxic->mfd->regs + TXD(nbytes % 4));
> > +
> > +      if (rxbuf) {
> > +         ret = readl_poll_timeout(mxic->mfd->regs + INT_STS, sts,
> > +                   sts & INT_TX_EMPTY, 0,
> > +                   USEC_PER_SEC);
> > +         if (ret)
> > +            return ret;
> > +
> > +         ret = readl_poll_timeout(mxic->mfd->regs + INT_STS, sts,
> > +                   sts & INT_RX_NOT_EMPTY, 0,
> > +                   USEC_PER_SEC);
> > +         if (ret)
> > +            return ret;
> > +
> > +         data = readl(mxic->mfd->regs + RXD);
> > +         data >>= (8 * (4 - nbytes));
> 
> What is this? Are you trying to handle some endianness issue?

yes,

> 
> > +         memcpy(rxbuf + pos, &data, nbytes);
> > +         WARN_ON(readl(mxic->mfd->regs + INT_STS) &
> > +            INT_RX_NOT_EMPTY);
> > +      } else {
> > +         readl(mxic->mfd->regs + RXD);
> > +      }
> > +      WARN_ON(readl(mxic->mfd->regs + INT_STS) & INT_RX_NOT_EMPTY);
> > +
> > +      pos += nbytes;
> > +   }
> > +
> > +   return 0;
> > +}






> > +
> > +static int mxic_nand_exec_op(struct nand_chip *chip,
> > +              const struct nand_operation *op, bool check_only)
> > +{
> > +   struct mxic_nand_ctlr *mxic = nand_get_controller_data(chip);
> > +   const struct nand_op_instr *instr = NULL;
> > +   int i, len = 0, ret = 0;
> > +   unsigned int op_id;
> > +   unsigned char cmdcnt = 0, addr_cnt = 0, cmd_addr[8] = {0};
> > +
> > +   for (op_id = 0; op_id < op->ninstrs; op_id++) {
> > +      instr = &op->instrs[op_id];
> > +
> > +      switch (instr->type) {
> > +      case NAND_OP_CMD_INSTR:
> > +         cmd_addr[len++] = instr->ctx.cmd.opcode;
> > +         cmdcnt++;
> > +         break;
> > +
> > +      case NAND_OP_ADDR_INSTR:
> > +         for (i = 0; i < instr->ctx.addr.naddrs; i++)
> > +            cmd_addr[len++] = instr->ctx.addr.addrs[i];
> > +         addr_cnt = i;
> > +         break;
> > +
> > +      case NAND_OP_DATA_IN_INSTR:
> > +         break;
> > +
> > +      case NAND_OP_DATA_OUT_INSTR:
> > +         writel(instr->ctx.data.len,
> > +                mxic->mfd->regs + ONFI_DIN_CNT(0));
> > +         break;
> > +
> > +      case NAND_OP_WAITRDY_INSTR:
> > +         break;
> > +      }
> > +   }
> > +
> > +   if (op_id == 5 && instr->type == NAND_OP_WAITRDY_INSTR) {
> > +      /*
> > +       * In case cmd-addr-data-cmd-wait in a sequence,
> > +       * separate the 2'nd command, i.e,. nand_prog_page_op()
> > +       */
> 
> I think this is the kind of limitation that could be described very
> easily with a nand_op_parser structure and used by
> nand_op_parser_exec_op() (see marvell_nand.c).

okay, thanks for your information.
Will check and patch it.

> 
> > +      writel(OP_CMD_BUSW(OP_BUSW_8) | OP_ADDR_BUSW(OP_BUSW_8) |
> > +             OP_DATA_BUSW(OP_BUSW_8) | OP_DUMMY_CYC(0x3F) |
> > +             OP_ADDR_BYTES(addr_cnt) |
> > +             OP_CMD_BYTES(1), mxic->mfd->regs + SS_CTRL(0));
> > +      writel(0, mxic->mfd->regs + HC_EN);
> > +      writel(HC_EN_BIT, mxic->mfd->regs + HC_EN);
> > +
> > +      mxic_nand_data_xfer(mxic, cmd_addr, NULL, len - 1);
> > +
> > +      mxic_nand_data_xfer(mxic, instr->ctx.data.buf.out, NULL,
> > +                instr->ctx.data.len);
> > +
> > +      writel(0, mxic->mfd->regs + HC_EN);
> > +      writel(HC_EN_BIT, mxic->mfd->regs + HC_EN);
> > +      mxic_nand_data_xfer(mxic, &cmd_addr[--len], NULL, 1);
> > +      ret = mxic_nand_wait_ready(chip);
> > +      if (ret)
> > +         goto err_out;
> > +      return ret;
> > +   }
> > +
> > +   if (len) {
> > +      writel(OP_CMD_BUSW(OP_BUSW_8) | OP_ADDR_BUSW(OP_BUSW_8) |
> > +             OP_DATA_BUSW(OP_BUSW_8) | OP_DUMMY_CYC(0x3F) |
> > +             OP_ADDR_BYTES(addr_cnt) |
> > +             OP_CMD_BYTES(cmdcnt > 0 ? cmdcnt : 0),
> > +             mxic->mfd->regs + SS_CTRL(0));
> > +      writel(0, mxic->mfd->regs + HC_EN);
> > +      writel(HC_EN_BIT, mxic->mfd->regs + HC_EN);
> > +
> > +      mxic_nand_data_xfer(mxic, cmd_addr, NULL, len);
> > +   }
> > +
> > +   for (op_id = 0; op_id < op->ninstrs; op_id++) {
> > +      instr = &op->instrs[op_id];
> > +
> > +      switch (instr->type) {
> > +      case NAND_OP_CMD_INSTR:
> > +      case NAND_OP_ADDR_INSTR:
> > +         break;
> > +
> > +      case NAND_OP_DATA_IN_INSTR:
> > +         writel(0x0, mxic->mfd->regs + ONFI_DIN_CNT(0));
> > +         writel(readl(mxic->mfd->regs + SS_CTRL(0)) | OP_READ,
> > +                mxic->mfd->regs + SS_CTRL(0));
> > +         mxic_nand_data_xfer(mxic, NULL, instr->ctx.data.buf.in,
> > +                   instr->ctx.data.len);
> > +         break;
> > +
> > +      case NAND_OP_DATA_OUT_INSTR:
> > +         mxic_nand_data_xfer(mxic, instr->ctx.data.buf.out, NULL,
> > +                   instr->ctx.data.len);
> > +         break;
> > +
> > +      case NAND_OP_WAITRDY_INSTR:
> > +         ret = mxic_nand_wait_ready(chip);
> > +         if (ret)
> > +            goto err_out;
> > +         break;
> > +      }
> > +   }
> > +
> > +err_out:
> > +   return ret;
> 
> Ditto, please return directly if there is nothing in the error path.

okay

> 
> > +}
> > +
> > +static const struct nand_controller_ops mxic_nand_controller_ops = {
> > +   .exec_op = mxic_nand_exec_op,
> > +};
> > +
> > +static int mx25f0a_nand_probe(struct platform_device *pdev)
> > +{
> > +   struct mtd_info *mtd;
> > +   struct mx25f0a_mfd *mfd = dev_get_drvdata(pdev->dev.parent);
> > +   struct mxic_nand_ctlr *mxic;
> > +   struct nand_chip *nand_chip;
> > +   int err;
> > +
> > +   mxic = devm_kzalloc(&pdev->dev, sizeof(struct mxic_nand_ctlr),
> > +             GFP_KERNEL);
> 
> mxic for a NAND controller structure is probably not a name meaningful
> enough.

How about *fmc or *mxic_fmc ?

> 
> > +   if (!mxic)
> > +      return -ENOMEM;
> > +
> > +   nand_chip = &mxic->nand;
> > +   mtd = nand_to_mtd(nand_chip);
> > +   mtd->dev.parent = pdev->dev.parent;
> > +   nand_chip->ecc.priv = NULL;
> > +   nand_set_flash_node(nand_chip, pdev->dev.parent->of_node);
> > +   nand_chip->priv = mxic;
> > +
> > +   mxic->mfd = mfd;
> > +
> > +   nand_chip->legacy.select_chip = mxic_nand_select_chip;
> 
> Please don't implement legacy interfaces. You can check in
> marvell_nand.c how this is handled now:
> 
> b25251414f6e mtd: rawnand: marvell: Stop implementing ->select_chip()

got it, will check & patch.

> 
> > +   mxic->base.ops = &mxic_nand_controller_ops;
> > +   nand_controller_init(&mxic->base);
> > +   nand_chip->controller = &mxic->base;
> > +
> > +   mxic_host_init(mxic);
> > +
> > +   err = nand_scan(nand_chip, 1);
> > +   if (err)
> > +      goto fail;
> 
> You can return directly as there is nothing to clean in the error path.
> 
> > +
> > +   err = mtd_device_register(mtd, NULL, 0);
> > +   if (err)
> > +      goto fail;
> 
> Ditto
> 
> > +
> > +   platform_set_drvdata(pdev, mxic);
> > +
> > +   return 0;
> > +fail:
> > +   return err;
> > +}
> > +
> > +static int mx25f0a_nand_remove(struct platform_device *pdev)
> > +{
> > +   struct mxic_nand_ctlr *mxic = platform_get_drvdata(pdev);
> > +
> > +   nand_release(&mxic->nand);
> > +
> > +   return 0;
> > +}
> > +
> > +static struct platform_driver mx25f0a_nand_driver = {
> > +   .probe      = mx25f0a_nand_probe,
> 
> Please don't align '=' on tabs.

okay, will fix and also remove "mx25f0a" char.
patch to:
mxic_nand_driver & mxic_nand_probe.


thanks for your review.
best regards,
Mason

--






CONFIDENTIALITY NOTE:

This e-mail and any attachments may contain confidential information 
and/or personal data, which is protected by applicable laws. Please be 
reminded that duplication, disclosure, distribution, or use of this e-mail 
(and/or its attachments) or any part thereof is prohibited. If you receive 
this e-mail in error, please notify us immediately and delete this mail as 
well as its attachment(s) from your system. In addition, please be 
informed that collection, processing, and/or use of personal data is 
prohibited unless expressly permitted by personal data protection laws. 
Thank you for your attention and cooperation.

Macronix International Co., Ltd.

=====================================================================



============================================================================

CONFIDENTIALITY NOTE:

This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation.

Macronix International Co., Ltd.

=====================================================================


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

  reply	other threads:[~2019-05-15  8:49 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-15  9:23 [PATCH v3 0/4] Add Macronix MX25F0A MFD driver for raw nand and spi Mason Yang
2019-04-15  9:23 ` [PATCH v3 1/4] mfd: Add Macronix MX25F0A MFD controller driver Mason Yang
2019-05-12 13:08   ` Miquel Raynal
2019-05-15  6:46     ` masonccyang
2019-04-15  9:23 ` [PATCH v3 2/4] mtd: rawnand: Add Macronix MX25F0A NAND controller Mason Yang
2019-05-12 13:18   ` Miquel Raynal
2019-05-15  8:48     ` masonccyang [this message]
2019-05-15 12:08       ` Miquel Raynal
     [not found]     ` <OF8A566F14.A2F0F576-ON482583FB.002E7E32-482583FB.003068B1@LocalDomain>
2019-05-15  9:18       ` masonccyang
2019-05-17  9:30     ` masonccyang
2019-05-20 12:23       ` Miquel Raynal
2019-05-23  8:58         ` masonccyang
2019-05-27 12:42           ` Miquel Raynal
2019-05-29  3:12             ` masonccyang
2019-06-17 12:35               ` Miquel Raynal
2019-06-18  1:24                 ` masonccyang
2019-06-18  6:14                   ` Boris Brezillon
2019-06-18  7:29                     ` Boris Brezillon
2019-06-19  8:04                       ` masonccyang
2019-06-19  8:09                         ` Miquel Raynal
2019-06-19  8:48                           ` masonccyang
2019-06-24  9:05                           ` masonccyang
2019-06-19  8:15                         ` Boris Brezillon
2019-06-19  8:55                           ` masonccyang
2019-06-19  9:06                             ` Boris Brezillon
2019-06-24  8:55                               ` masonccyang
2019-04-15  9:23 ` [PATCH v3 3/4] spi: Patch Macronix SPI controller driver according to MX25F0A MFD driver Mason Yang
2019-04-19 14:51   ` Mark Brown
     [not found]     ` <OF7742B4A9.445066F6-ON482583EC.0037E377-482583EC.0039125B@mxic.com.tw>
2019-05-02  2:41       ` Mark Brown
2019-04-15  9:23 ` [PATCH v3 4/4] dt-bindings: mfd: Document Macronix MX25F0A controller bindings Mason Yang
2019-04-26 22:41   ` Rob Herring
2019-05-12 13:23   ` Miquel Raynal
2019-05-15  7:36     ` masonccyang

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=OF8A566F14.A2F0F576-ON482583FB.002E7E32-482583FB.003068BA@mxic.com.tw \
    --to=masonccyang@mxic.com.tw \
    --cc=bbrezillon@kernel.org \
    --cc=broonie@kernel.org \
    --cc=christophe.kerello@st.com \
    --cc=computersforpeace@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=geert@linux-m68k.org \
    --cc=juliensu@mxic.com.tw \
    --cc=lee.jones@linaro.org \
    --cc=liang.yang@amlogic.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=marcel.ziswiler@toradex.com \
    --cc=marek.vasut@gmail.com \
    --cc=mark.rutland@arm.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=paul.burton@mips.com \
    --cc=richard@nod.at \
    --cc=robh+dt@kernel.org \
    --cc=stefan@agner.ch \
    --cc=zhengxunli@mxic.com.tw \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).