From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Brezillon Subject: Re: [PATCH v4 2/2] mtd: mediatek: driver for MTK Smart Device Gen1 NAND Date: Tue, 10 May 2016 16:59:43 +0200 Message-ID: <20160510165943.0322b374@bbrezillon> References: <1461946642-1842-1-git-send-email-jorge.ramirez-ortiz@linaro.org> <1461946642-1842-3-git-send-email-jorge.ramirez-ortiz@linaro.org> <20160510141335.442d3d7b@bbrezillon> <5731F40B.801@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5731F40B.801-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+glpam-linux-mediatek=m.gmane.org-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org To: Jorge Ramirez Cc: robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, daniel.thompson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, erin.lo-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, xiaolei.li-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org, computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org, blogic-p3rKhJxN3npAfugRpC6u6w@public.gmane.org List-Id: linux-mediatek@lists.infradead.org On Tue, 10 May 2016 10:45:31 -0400 Jorge Ramirez 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