Re: [PATCH] mtd: Fallback to ->_read/write_oob() when ->_read/write() is missing

[Boris Brezillon <boris.brezillon@free-electrons.com>]

Le Sat, 24 Jun 2017 22:12:19 +0200,
Boris Brezillon <boris.brezillon@free-electrons.com> a écrit :

> Le Thu, 22 Jun 2017 14:26:06 -0700,
> Brian Norris <computersforpeace@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@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@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.