Re: [PATCH 04/11] nand: spi: Add read function support

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

On Tue, 21 Feb 2017 18:06:03 +0800
Peter Pan <peterpansjtu@gmail.com> wrote:

[...]

> >> +static int spi_nand_get_device(struct mtd_info *mtd, int new_state)
> >> +{
> >> +     struct spi_nand_chip *this = mtd_to_spi_nand(mtd);
> >> +     DECLARE_WAITQUEUE(wait, current);
> >> +
> >> +     /*
> >> +      * Grab the lock and see if the device is available
> >> +      */
> >> +     while (1) {
> >> +             spin_lock(&this->chip_lock);
> >> +             if (this->state == FL_READY) {
> >> +                     this->state = new_state;
> >> +                     spin_unlock(&this->chip_lock);
> >> +                     break;
> >> +             }
> >> +             if (new_state == FL_PM_SUSPENDED) {
> >> +                     spin_unlock(&this->chip_lock);
> >> +                     return (this->state == FL_PM_SUSPENDED) ? 0 : -EAGAIN;
> >> +             }
> >> +             set_current_state(TASK_UNINTERRUPTIBLE);
> >> +             add_wait_queue(&this->wq, &wait);
> >> +             spin_unlock(&this->chip_lock);
> >> +             schedule();
> >> +             remove_wait_queue(&this->wq, &wait);
> >> +     }  
> >
> > Do we really need this fl_state dance? It could be replaced with a
> > simple mutex that is taken for the whole flash operation. This leaves
> > the suspended case which could be handled with:
> >
> > static void spinand_suspend(struct mtd_info *mtd)
> > {
> >         struct spi_nand_chip *this = mtd_to_spinand(mtd);
> >
> >         if (!mutex_trylock(&this->lock))
> >                 return -EAGAIN;
> >
> >         return 0;
> > }
> >
> > For other operations (read, write, lock, unlock, ...), you just have to
> > take the lock before accessing the NAND and release it when you're done.
> >
> > Again, I'm saying that because I don't want to end up with something
> > that is overly complex for no real reason, but maybe I'm missing
> > something.  
> 
> This code refers old NAND framework two years ago. I just check the latest
> nand_base.c you already remove it. Let's make it simple. Fix this in v2.

Nope, it's still here [1], but I'm pretty sure this complexity is
actually not needed, and anyway, I plan to delegate this serialization
to the NAND controller in the future (some operations can be done
in //, for example, on multi-die NANDs, you can read something on a die,
while you're programming something on the other die).

[1]http://lxr.free-electrons.com/source/drivers/mtd/nand/nand_base.c#L851