From mboxrd@z Thu Jan 1 00:00:00 1970 From: dkota@codeaurora.org Subject: Re: [PATCH V3] spi: spi-geni-qcom: Add SPI driver support for GENI based QUP Date: Mon, 10 Sep 2018 19:54:27 +0530 Message-ID: <2c2260787f4c02702b02b8a85cd63187@codeaurora.org> References: <1535107336-2214-1-git-send-email-dkota@codeaurora.org> <2493fc3fa3f6e5d2bcdde27cee1c33df@codeaurora.org> <20180910112633.GC5856@sirena.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20180910112633.GC5856@sirena.org.uk> Sender: linux-kernel-owner@vger.kernel.org To: Mark Brown Cc: Doug Anderson , Stephen Boyd , Matthias Kaehlcke , LKML , linux-spi , Andy Gross , David Brown , Rob Herring , Mark Rutland , linux-arm-msm , "open list:ARM/QUALCOMM SUPPORT" , devicetree@vger.kernel.org, Girish Mahadevan List-Id: linux-arm-msm@vger.kernel.org On 2018-09-10 16:56, Mark Brown wrote: > On Mon, Sep 10, 2018 at 09:27:09AM +0530, dkota@codeaurora.org wrote: > >> > The thing is, we want it to be 100% reliable, not 99.9% reliable. Is >> > it somehow wrong to add the spinlock? ...or are you noticing >> > performance problems with the spinlock there? It's just nice not to >> > have to think about it. > >> As I said, timeout will be handled after the calculated time as per >> data >> size and speed. Enough time is given for interrupt, there is no chance >> of >> interrupt occurrence during the handle_fifo_timeout(). So there is no >> need >> of spinlock. > > Assuming nothing goes wrong - the system isn't under unusually heavy > load for example, there's some oversight in the code, there's no impact > from power management causing things to run more slowly than you were > expecting, someone uses the driver on a new bit of hardware where there > are extra considerations or whatever else might go wrong. Like Doug > says unless we're in some performance critical situation where it's > worth thinking *really* hard about how things really are actually safe > even though they might not look it it's both easier and more > maintainable to just write software that's obviously safe to > inspection. Agree with this perspective. There wont be any performance impact with spinlock. I will include the spinlock in the code.