[PATCH v4 3/9] mtd: nand: add more helpers in nand.h

Boris Brezillon boris.brezillon at free-electrons.com
Thu Mar 30 01:40:05 PDT 2017


On Thu, 30 Mar 2017 16:04:44 +0800
Peter Pan <peterpansjtu at gmail.com> wrote:

> Hi Boris,
> 
> On Thu, Mar 30, 2017 at 3:57 AM, Boris Brezillon
> <boris.brezillon at free-electrons.com> wrote:
> > On Thu, 23 Mar 2017 17:43:40 +0800
> > Peter Pan <peterpandong at micron.com> wrote:
> >  
> >> This commit adds some helpers in nand.h
> >>     nand_size()
> >>     nand_check_address()
> >>     nand_check_oob_ops()
> >>     nand_oob_ops_across_page()
> >>     nand_check_erase_ops()
> >>
> >> Signed-off-by: Peter Pan <peterpandong at micron.com>
> >> ---
> >>  include/linux/mtd/nand.h | 62 ++++++++++++++++++++++++++++++++++++++++++++++++
> >>  1 file changed, 62 insertions(+)
> >>
> >> diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> >> index 54ded4c..0c52401 100644
> >> --- a/include/linux/mtd/nand.h
> >> +++ b/include/linux/mtd/nand.h
> >> @@ -434,6 +434,68 @@ static inline int nand_neraseblocks(struct nand_device *nand)
> >>  }
> >>
> >>  /**
> >> + * nand_size - Get NAND size
> >> + * @nand: NAND device
> >> + *
> >> + * Returns the total size exposed by @nand.
> >> + */
> >> +static inline u64 nand_size(struct nand_device *nand)
> >> +{
> >> +     return nand->memorg.ndies * nand->memorg.diesize;
> >> +}
> >> +  
> >
> > The nand_size() function should probably go in the commit introducing
> > the interface-agnostic NAND layer (in my own series).
> >
> > Since you'll be the first one to use the generic NAND layer, I propose
> > that you start maintaining my patch-set along with your SPI NAND
> > patches.  
> 
> You mean that I send your patch-set with SPI NAND patches? If so, you want
> me to do this in v5 or when SPI NAND patches is ready to merge?

No need to send the "interface-agnostic NAND layer" patches in future
versions of this series, let's wait until everyone is happy with the SPI
NAND patches.
But you can already create your own branch and maintain my patches
(rebase on newer kernel versions or nand/next if needed, squash changes
into existing commits if it makes sense, ...). It's also easier for
people who want to test your patches to have a branch containing
everything.




More information about the linux-mtd mailing list