linux-kernel - Re: [PATCH V3] spi: spi-geni-qcom: Add SPI driver support for GENI based QUP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2c2260787f4c02702b02b8a85cd63187@codeaurora.org>
Date:   Mon, 10 Sep 2018 19:54:27 +0530
From:   dkota@...eaurora.org
To:     Mark Brown <broonie@...nel.org>
Cc:     Doug Anderson <dianders@...omium.org>,
        Stephen Boyd <swboyd@...omium.org>,
        Matthias Kaehlcke <mka@...omium.org>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-spi <linux-spi@...r.kernel.org>,
        Andy Gross <andy.gross@...aro.org>,
        David Brown <david.brown@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        "open list:ARM/QUALCOMM SUPPORT" <linux-soc@...r.kernel.org>,
        devicetree@...r.kernel.org,
        Girish Mahadevan <girishm@...eaurora.org>
Subject: Re: [PATCH V3] spi: spi-geni-qcom: Add SPI driver support for GENI
 based QUP

On 2018-09-10 16:56, Mark Brown wrote:
> On Mon, Sep 10, 2018 at 09:27:09AM +0530, dkota@...eaurora.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.