From: Boris Brezillon <boris.brezillon@collabora.com>
To: masonccyang@mxic.com.tw
Cc: richard@nod.at, bbrezillon@kernel.org, juliensu@mxic.com.tw,
gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
frieder.schrempf@kontron.de, marcel.ziswiler@toradex.com,
linux-mtd@lists.infradead.org,
Miquel Raynal <miquel.raynal@bootlin.com>,
tglx@linutronix.de, computersforpeace@gmail.com,
dwmw2@infradead.org, marek.vasut@gmail.com, vigneshr@ti.com
Subject: Re: [PATCH RFC 2/3] mtd: rawnand: Add support Macronix Block Protection function
Date: Mon, 21 Oct 2019 10:56:32 +0200 [thread overview]
Message-ID: <20191021105632.3fa7b3ce@collabora.com> (raw)
In-Reply-To: <OF94EDFFB1.AFAD9C25-ON4825849A.002E2815-4825849A.002FB1CE@mxic.com.tw>
On Mon, 21 Oct 2019 16:40:57 +0800
masonccyang@mxic.com.tw wrote:
> Hi Boris,
>
>
> > > > > > > Then fill-in these two hooks from the manufacturer code,
> without
> > > the
> > > > > > > postponed init.
> > > > > > >
> > > > > >
> > > > > > But in the final of nand_scan_tail(), mtd->_lock/_unlock will be
> > > > > > filled by NULL, right ?
> > > > >
> > > > > The NAND core should set mtd->_lock/_unlock() to NAND specific
> hooks
> > > so
> > > > > that the MTD layer is abstracted and and drivers do not see it.
> Then,
> > > > > in the NAND helper, either there is no specific hook defined by a
> > > > > manufacturer driver and you return -ENOTSUPP, or you execute the
> > > > > defined hook.
> > > >
> > > > okay, patch specific manufacturer _lock/_unlock driver
> > > > in nand_manufacturer_init();
> > > >
> > > > and in the final of nand_scan_tail()
> > > > if (!mtd->_lock)
> > > > mtd->_lock = NULL;
> > > > if (!mtd->_unlock)
> > > > mtd->_unlock = NULL;
> > >
> > >
> > > I'm still considering of post_init() in nand_scan_tail() for
> > > MTD layer default call-back function replacement because
> > > there would be more call-back functions need it.
> > > i.e.,
> > > MTD->_lock/_unlokc
> > > MTD->_suspend/_resume
> >
> > Again, that's something that needs to be abstracted so that both the
> > NAND manufacturer driver and the NAND controller driver can take
> > appropriate actions on suspend/resume operations.
> >
> > > NTD->_point/_unpoint
> >
> > ->_point/_unpoint() are irrelevant for a NAND chip.
> >
> > > ...
> > >
> > >
> > > actually, my patch series are including MTD->_locl/_unlock and
> > > MTD->_suspend/_resume. how do you think ?
> >
> > Miquel was suggesting to add nand_chip->{lock,unlock,is_locked}()
> > methods that would be implemented by the NAND manufacturer drivers, and
> > have generic wrappers implemented in nand_base.c:
> >
> > static int nand_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
> > {
> > struct nand_chip *chip = mtd_to_nand(mtd);
> >
> > if (!chip->lock)
> > return -ENOTSUPP;
> >
> > return chip->lock(chip, ofs, len);
> > }
> >
> > ...
> >
> > If you do that, you won't need this post_init() hook.
>
> got it, but ...
> user space program flash_lock/flash_unlock are calling
> mtd_lock() & mtd_unlock().
> i.e.,
> int mtd_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
> {
> if (!mtd->_lock)
> return -EOPNOTSUPP;
> if (ofs < 0 || ofs >= mtd->size || len > mtd->size - ofs)
> return -EINVAL;
> if (!len)
> return 0;
> return mtd->_lock(mtd, ofs, len);
> }
>
Assign mtd lock/unlock/is_locked hooks to the generic wrappers in
nand_scan_tail():
mtd->_lock = nand_lock;
mtd->_unlock = nand_unlock;
mtd->_is_locked = nand_is_locked;
Seriously, we've almost implemented the thing for you with all the
details we've given. At some point you have to look more closely at how
things are done/designed in the NAND framework if you want to
contribute core changes. I'm fine giving hints but we're far beyond
that point here.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@collabora.com>
To: masonccyang@mxic.com.tw
Cc: bbrezillon@kernel.org, computersforpeace@gmail.com,
dwmw2@infradead.org, frieder.schrempf@kontron.de,
gregkh@linuxfoundation.org, juliensu@mxic.com.tw,
linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
marcel.ziswiler@toradex.com, marek.vasut@gmail.com,
"Miquel Raynal" <miquel.raynal@bootlin.com>,
richard@nod.at, tglx@linutronix.de, vigneshr@ti.com
Subject: Re: [PATCH RFC 2/3] mtd: rawnand: Add support Macronix Block Protection function
Date: Mon, 21 Oct 2019 10:56:32 +0200 [thread overview]
Message-ID: <20191021105632.3fa7b3ce@collabora.com> (raw)
In-Reply-To: <OF94EDFFB1.AFAD9C25-ON4825849A.002E2815-4825849A.002FB1CE@mxic.com.tw>
On Mon, 21 Oct 2019 16:40:57 +0800
masonccyang@mxic.com.tw wrote:
> Hi Boris,
>
>
> > > > > > > Then fill-in these two hooks from the manufacturer code,
> without
> > > the
> > > > > > > postponed init.
> > > > > > >
> > > > > >
> > > > > > But in the final of nand_scan_tail(), mtd->_lock/_unlock will be
> > > > > > filled by NULL, right ?
> > > > >
> > > > > The NAND core should set mtd->_lock/_unlock() to NAND specific
> hooks
> > > so
> > > > > that the MTD layer is abstracted and and drivers do not see it.
> Then,
> > > > > in the NAND helper, either there is no specific hook defined by a
> > > > > manufacturer driver and you return -ENOTSUPP, or you execute the
> > > > > defined hook.
> > > >
> > > > okay, patch specific manufacturer _lock/_unlock driver
> > > > in nand_manufacturer_init();
> > > >
> > > > and in the final of nand_scan_tail()
> > > > if (!mtd->_lock)
> > > > mtd->_lock = NULL;
> > > > if (!mtd->_unlock)
> > > > mtd->_unlock = NULL;
> > >
> > >
> > > I'm still considering of post_init() in nand_scan_tail() for
> > > MTD layer default call-back function replacement because
> > > there would be more call-back functions need it.
> > > i.e.,
> > > MTD->_lock/_unlokc
> > > MTD->_suspend/_resume
> >
> > Again, that's something that needs to be abstracted so that both the
> > NAND manufacturer driver and the NAND controller driver can take
> > appropriate actions on suspend/resume operations.
> >
> > > NTD->_point/_unpoint
> >
> > ->_point/_unpoint() are irrelevant for a NAND chip.
> >
> > > ...
> > >
> > >
> > > actually, my patch series are including MTD->_locl/_unlock and
> > > MTD->_suspend/_resume. how do you think ?
> >
> > Miquel was suggesting to add nand_chip->{lock,unlock,is_locked}()
> > methods that would be implemented by the NAND manufacturer drivers, and
> > have generic wrappers implemented in nand_base.c:
> >
> > static int nand_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
> > {
> > struct nand_chip *chip = mtd_to_nand(mtd);
> >
> > if (!chip->lock)
> > return -ENOTSUPP;
> >
> > return chip->lock(chip, ofs, len);
> > }
> >
> > ...
> >
> > If you do that, you won't need this post_init() hook.
>
> got it, but ...
> user space program flash_lock/flash_unlock are calling
> mtd_lock() & mtd_unlock().
> i.e.,
> int mtd_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
> {
> if (!mtd->_lock)
> return -EOPNOTSUPP;
> if (ofs < 0 || ofs >= mtd->size || len > mtd->size - ofs)
> return -EINVAL;
> if (!len)
> return 0;
> return mtd->_lock(mtd, ofs, len);
> }
>
Assign mtd lock/unlock/is_locked hooks to the generic wrappers in
nand_scan_tail():
mtd->_lock = nand_lock;
mtd->_unlock = nand_unlock;
mtd->_is_locked = nand_is_locked;
Seriously, we've almost implemented the thing for you with all the
details we've given. At some point you have to look more closely at how
things are done/designed in the NAND framework if you want to
contribute core changes. I'm fine giving hints but we're far beyond
that point here.
next prev parent reply other threads:[~2019-10-21 8:56 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-18 7:56 [PATCH RFC 1/3] mtd: rawnand: Add support manufacturer postponed initialization Mason Yang
2019-09-18 7:56 ` Mason Yang
2019-09-18 7:56 ` [PATCH RFC 2/3] mtd: rawnand: Add support Macronix Block Protection function Mason Yang
2019-09-18 7:56 ` Mason Yang
2019-10-07 8:45 ` Miquel Raynal
2019-10-07 8:45 ` Miquel Raynal
2019-10-07 9:24 ` Miquel Raynal
2019-10-07 9:24 ` Miquel Raynal
2019-10-08 2:33 ` masonccyang
2019-10-08 2:33 ` masonccyang
2019-10-08 15:02 ` Miquel Raynal
2019-10-08 15:02 ` Miquel Raynal
2019-10-15 6:47 ` masonccyang
2019-10-15 6:47 ` masonccyang
[not found] ` <OFB4F10613.467EB346-ON48258494.0020403E-48258494.002550A2@LocalDomain>
2019-10-21 7:23 ` masonccyang
2019-10-21 7:23 ` masonccyang
2019-10-21 7:44 ` Boris Brezillon
2019-10-21 7:44 ` Boris Brezillon
2019-10-21 8:40 ` masonccyang
2019-10-21 8:40 ` masonccyang
2019-10-21 8:56 ` Boris Brezillon [this message]
2019-10-21 8:56 ` Boris Brezillon
2019-10-21 9:07 ` masonccyang
2019-10-21 9:07 ` masonccyang
2019-09-18 7:56 ` [PATCH RFC 3/3] mtd: rawnand: Add support Macronix power down mode Mason Yang
2019-09-18 7:56 ` Mason Yang
2019-10-07 8:45 ` Miquel Raynal
2019-10-07 8:45 ` Miquel Raynal
2019-10-08 2:06 ` masonccyang
2019-10-08 2:06 ` masonccyang
2019-10-08 7:28 ` Boris Brezillon
2019-10-08 7:28 ` Boris Brezillon
2019-10-15 2:33 ` masonccyang
2019-10-15 2:33 ` masonccyang
2019-10-15 7:56 ` Miquel Raynal
2019-10-15 7:56 ` Miquel Raynal
2019-10-16 6:55 ` masonccyang
2019-10-16 6:55 ` masonccyang
2019-10-25 3:11 ` masonccyang
2019-10-25 3:11 ` 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=20191021105632.3fa7b3ce@collabora.com \
--to=boris.brezillon@collabora.com \
--cc=bbrezillon@kernel.org \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=frieder.schrempf@kontron.de \
--cc=gregkh@linuxfoundation.org \
--cc=juliensu@mxic.com.tw \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marcel.ziswiler@toradex.com \
--cc=marek.vasut@gmail.com \
--cc=masonccyang@mxic.com.tw \
--cc=miquel.raynal@bootlin.com \
--cc=richard@nod.at \
--cc=tglx@linutronix.de \
--cc=vigneshr@ti.com \
/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.