From: Miquel Raynal <miquel.raynal@bootlin.com>
To: masonccyang@mxic.com.tw
Cc: vigneshr@ti.com, 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, richard@nod.at,
tglx@linutronix.de, computersforpeace@gmail.com,
dwmw2@infradead.org, marek.vasut@gmail.com
Subject: Re: [PATCH RFC 2/3] mtd: rawnand: Add support Macronix Block Protection function
Date: Tue, 8 Oct 2019 17:02:49 +0200 [thread overview]
Message-ID: <20191008170249.06bd45ce@xps13> (raw)
In-Reply-To: <OFEDE76FEE.8BC48D9E-ON4825848D.000BCC94-4825848D.000E0643@mxic.com.tw>
Hi Mason,
masonccyang@mxic.com.tw wrote on Tue, 8 Oct 2019 10:33:11 +0800:
> Hi Miquel,
>
> > >
> > > > Macronix AC series support using SET/GET_FEATURES to change
> > > > Block Protection and Unprotection.
> > > >
> > > > MTD default _lock/_unlock function replacement by manufacturer
> > > > postponed initialization.
> > >
> > > Why would we do that?
> > >
> > > Anyway your solution looks overkill, if we ever decide to
> > > implement these hooks for raw nand, it is better just to not
> > > overwrite them in nand_scan_tail() if they have been filled
> > > previously (ie. by the manufacturer code).
> >
> > Actually you should add two NAND hooks that do the interface with the
> > MTD hooks. In the NAND hooks, check that the request is to lock all the
> > device, otherwise return -ENOTSUPP.
>
> sorry, can't get your point.
>
> Because the NAND entire chip will be protected if PT(protection) pin
> is active high at power-on.
In your implementation of the locking, you should check that the
locking request is over the entire device, unless you can lock a
smaller portion of course.
>
> >
> > 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.
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.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,
richard@nod.at, tglx@linutronix.de, vigneshr@ti.com
Subject: Re: [PATCH RFC 2/3] mtd: rawnand: Add support Macronix Block Protection function
Date: Tue, 8 Oct 2019 17:02:49 +0200 [thread overview]
Message-ID: <20191008170249.06bd45ce@xps13> (raw)
In-Reply-To: <OFEDE76FEE.8BC48D9E-ON4825848D.000BCC94-4825848D.000E0643@mxic.com.tw>
Hi Mason,
masonccyang@mxic.com.tw wrote on Tue, 8 Oct 2019 10:33:11 +0800:
> Hi Miquel,
>
> > >
> > > > Macronix AC series support using SET/GET_FEATURES to change
> > > > Block Protection and Unprotection.
> > > >
> > > > MTD default _lock/_unlock function replacement by manufacturer
> > > > postponed initialization.
> > >
> > > Why would we do that?
> > >
> > > Anyway your solution looks overkill, if we ever decide to
> > > implement these hooks for raw nand, it is better just to not
> > > overwrite them in nand_scan_tail() if they have been filled
> > > previously (ie. by the manufacturer code).
> >
> > Actually you should add two NAND hooks that do the interface with the
> > MTD hooks. In the NAND hooks, check that the request is to lock all the
> > device, otherwise return -ENOTSUPP.
>
> sorry, can't get your point.
>
> Because the NAND entire chip will be protected if PT(protection) pin
> is active high at power-on.
In your implementation of the locking, you should check that the
locking request is over the entire device, unless you can lock a
smaller portion of course.
>
> >
> > 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.
Thanks,
Miquèl
next prev parent reply other threads:[~2019-10-08 15:03 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 [this message]
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
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=20191008170249.06bd45ce@xps13 \
--to=miquel.raynal@bootlin.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=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.