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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180910112633.GC5856@sirena.org.uk>
Date:   Mon, 10 Sep 2018 12:26:33 +0100
From:   Mark Brown <broonie@...nel.org>
To:     dkota@...eaurora.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 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.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)