[PATCH] mtd: Fallback to ->_read/write_oob() when ->_read/write() is missing
Boris Brezillon
boris.brezillon at free-electrons.com
Sun Jun 25 08:01:58 PDT 2017
Le Sat, 24 Jun 2017 22:12:19 +0200,
Boris Brezillon <boris.brezillon at free-electrons.com> a écrit :
> Le Thu, 22 Jun 2017 14:26:06 -0700,
> Brian Norris <computersforpeace at gmail.com> a écrit :
>
> > On Sun, Jun 11, 2017 at 10:42:55PM +0200, Boris Brezillon wrote:
> > > Some MTD sublayers/drivers are implementing ->_read/write_oob() and
> > > providing dummy wrappers for their ->_read/write() implementations.
> > > Let the core handle this case instead of duplicating the logic.
> > >
> > > Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
> > > ---
> > > Note that the goldfish_nand driver (currently in staging) has not been
> > > updated because some the ops->len != mtd->writesize check done in
> > > goldfish_nand_read/write_oob() prevents us from using this function as
> > > a fallback for ->_read/write().
> > >
> > > This behavior is buggy anyway, because the core expects drivers
> > > implementing ->_read_oob() to support reading more than ->writesize in
> > > a single call. Probably something we should fix.
> >
> > Looks OK to me:
> >
> > Acked-by: Brian Norris <computersforpeace at gmail.com>
> >
> > This touches NAND drivers more than core MTD stuff, so feel free to take
> > it in your branch.
>
> Applied to nand/next.
It seems that this patch is triggering a NULL pointer exception,
probably because some code is calling ->_read/write() directly instead
of using mtd_read/write() wrappers.
Removed the from nand/next until I figure out what's happening and come
up with a better solution: either remove direct ->_read/write() calls or
implement a default _read/_write() -> _read/write_oob() wrapper instead
of handling that in the mtd_read/write() function.
More information about the linux-mtd
mailing list