Re: [PATCH v4 2/2] mtd: mediatek: driver for MTK Smart Device Gen1 NAND

[Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>]

On Tue, 10 May 2016 10:45:31 -0400
Jorge Ramirez <jorge.ramirez-ortiz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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