linux-kernel - Re: [PATCH 07/16] spi: bcm63xx-hsspi: Add polling mode support

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: <Y73rl8feUOnChWKF@sirena.org.uk>
Date:   Tue, 10 Jan 2023 22:49:59 +0000
From:   Mark Brown <broonie@...nel.org>
To:     William Zhang <william.zhang@...adcom.com>
Cc:     Linux SPI List <linux-spi@...r.kernel.org>,
        Broadcom Kernel List <bcm-kernel-feedback-list@...adcom.com>,
        anand.gore@...adcom.com, tomer.yacoby@...adcom.com,
        dan.beygelman@...adcom.com, joel.peshkin@...adcom.com,
        f.fainelli@...il.com, jonas.gorski@...il.com,
        kursad.oney@...adcom.com, dregan@...l.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 07/16] spi: bcm63xx-hsspi: Add polling mode support

On Mon, Jan 09, 2023 at 12:10:30PM -0800, William Zhang wrote:
> On 01/09/2023 11:06 AM, Mark Brown wrote:

> > You can put whatever logic is needed in the code - for something like
> > this an architecture based define isn't ideal but is probably good
> > enough if need be (though I'd not be surprised if it turned out that
> > there was also some performance benefit for the MIPS systems too, at
> > least for smaller transfers).

> I just don't know what other logic I can put in the driver to select
> interrupt or polling mode.  Only the end user know if performance or cpu
> usage is more important to their application.

Usually you can take a reasonable guess as to what would be a good point
to start switching, typically for short enough transfers the overhead of
setting up DMA, waiting for interrupts and tearing things down is very
much larger than the cost of just doing PIO - a bunch of other drivers
have pick a number logic of some kind, often things like FIFO sizes are
a good key for where to look.  A lot of the time this is good enough,
and it means that users have much better facilities for making tradeoffs
if they have a range of transfer sizes available - it's not an either/or
thing but based on some features of the individual message/transfer.

It is true that for people with heavy SPI traffic or otherwise very
demanding requirements for a specific system and software stack
additional tuning might produce better results, exposing some sysfs
knobs to allow tuning of parameters at runtime would be helpful for them
and I'd certainly be happy to see that added.

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