[PATCH v4 2/2] mtd: mediatek: driver for MTK Smart Device Gen1 NAND
Boris Brezillon
boris.brezillon at free-electrons.com
Tue May 10 07:59:43 PDT 2016
On Tue, 10 May 2016 10:45:31 -0400
Jorge Ramirez <jorge.ramirez-ortiz at linaro.org> wrote:
> On 05/10/2016 08:13 AM, Boris Brezillon wrote:
> >> +struct mtk_ecc {
> >> >+ struct device *dev;
> >> >+ void __iomem *regs;
> >> >+ struct clk *clk;
> >> >+
> >> >+ struct completion done;
> >> >+ struct semaphore sem;
> > You tried to explain me why you decided to go for a semaphore instead of
> > a mutex, but I don't remember. Could you explain it again?
> > If that's all about being interruptible, then you can use
>
> Just for flexibility, no other reason really.
> Neither the mutex nor the semaphore are actually needed in this driver.
> Not knowing how things are going to evolve in the upper layers of MTD I
> didn't feel comfortable taking a lock in a function and unlocking the
> mutex in a different function (which is the way this driver operates).
> with that in mind I opted for a semaphore since it can always be
> unlocked -if needed be- by a different thread.
But that has nothing to do with possible evolutions in the MTD layer.
The ECC engine resource can only have a single user at a time, hence
the mutex approach. Sorry, but I don't understand the "flexibility"
argument, but maybe I'm misunderstanding the different between a
semaphore and a mutex.
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
More information about the Linux-mediatek
mailing list