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: <ca22c9af-34bc-e857-881c-263f70a405e8@broadcom.com>
Date:   Mon, 9 Jan 2023 12:10:30 -0800
From:   William Zhang <william.zhang@...adcom.com>
To:     Mark Brown <broonie@...nel.org>
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 01/09/2023 11:06 AM, Mark Brown wrote:
> On Fri, Jan 06, 2023 at 07:35:59PM -0800, William Zhang wrote:
>> On 01/06/2023 01:47 PM, Mark Brown wrote:
>>> On Fri, Jan 06, 2023 at 12:07:59PM -0800, William Zhang wrote:
> 
>>>> When interrupt is not defined in the HSSPI dts node, driver switches to
>>>> polling mode for controller SPI message processing.  Also add driver
>>>> banner message when the driver is loaded successfully.
> 
>>> This should not be something the user selects via the DT, if the polling
>>> mode is better then the driver should just use it regardless of there
>>> being an interrupt wired up.  Generally there's some point at which the
>>> benefits of polling become minimal (and the costs more impactful) but if
>>> the DMA setup is as bad as it sounds then the driver should just ignore
>>> the interrupt.
> 
>> I agree but this is more for backward compatibility as the original driver
>> uses interrupt to work with MIPS based SoC and I do not want to change that
>> behavior.  For newer devices I added, they work in polling mode by default
>> with the dts I supplied.  IMHO it is also good to have this fallback option
>> to use interrupt in case user is sensitive to cpu usage.
> 
> 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.

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4212 bytes)