[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200217100124.6ff71191@xps13>
Date: Mon, 17 Feb 2020 10:01:24 +0100
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: masonccyang@...c.com.tw
Cc: "Boris Brezillon" <boris.brezillon@...labora.com>,
bbrezillon@...nel.org, computersforpeace@...il.com,
dwmw2@...radead.org, juliensu@...c.com.tw,
linux-kernel@...r.kernel.org, linux-mtd@...ts.infradead.org,
marek.vasut@...il.com, richard@....at, vigneshr@...com
Subject: Re: [PATCH v2 1/4] mtd: rawnand: Add support manufacturer specific
lock/unlock operatoin
Hi Mason,
masonccyang@...c.com.tw wrote on Mon, 17 Feb 2020 16:14:23 +0800:
> Hi Boris,
>
> >
> > > /* Set default functions */
> > > static void nand_set_defaults(struct nand_chip *chip)
> > > {
> > > @@ -5782,8 +5810,8 @@ static int nand_scan_tail(struct nand_chip
> *chip)
> > > mtd->_read_oob = nand_read_oob;
> > > mtd->_write_oob = nand_write_oob;
> > > mtd->_sync = nand_sync;
> > > - mtd->_lock = NULL;
> > > - mtd->_unlock = NULL;
> > > + mtd->_lock = nand_lock;
> > > + mtd->_unlock = nand_unlock;
> > > mtd->_suspend = nand_suspend;
> > > mtd->_resume = nand_resume;
> > > mtd->_reboot = nand_shutdown;
> > > diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
> > > index 4ab9bcc..2430ecd 100644
> > > --- a/include/linux/mtd/rawnand.h
> > > +++ b/include/linux/mtd/rawnand.h
> > > @@ -1136,6 +1136,9 @@ struct nand_chip {
> > > const struct nand_manufacturer *desc;
> > > void *priv;
> > > } manufacturer;
> > > +
> > > + int (*_lock)(struct nand_chip *chip, loff_t ofs, uint64_t len);
> > > + int (*_unlock)(struct nand_chip *chip, loff_t ofs, uint64_t len);
> >
> > Please drop this _ prefix.
>
> Drop _ prefix of _lock will get compile error due to there is already
> defined "struct mutex lock" in struct nand_chip.
Right!
>
> What about keep this _ prefix or patch it to blocklock/blockunlock,
> i.e.,
> int (*blocklock)(struct nand_chip *chip, loff_t ofs, uint64_t len);
> int (*blockunlock)(struct nand_chip *chip, loff_t ofs, uint64_t len);
What about lock_area() unlock_area() ? Seems more accurate to me, tell
me if I'm wrong.
>
>
> thanks for your time & comments.
> Mason
Thanks,
Miquèl
Powered by blists - more mailing lists