linux-kernel - Re: [PATCH V2] i2c: tegra: disable irq in tegra_i2c_xfer

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: <61c2dbcd-85f2-2094-7596-78ac01f55421@nvidia.com>
Date:   Tue, 18 Jun 2019 10:13:54 +0100
From:   Jon Hunter <jonathanh@...dia.com>
To:     Bitan Biswas <bbiswas@...dia.com>,
        Laxman Dewangan <ldewangan@...dia.com>,
        Thierry Reding <treding@...dia.com>,
        <linux-i2c@...r.kernel.org>, <linux-tegra@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, Peter Rosin <peda@...ntia.se>,
        Wolfram Sang <wsa@...-dreams.de>,
        Dmitry Osipenko <digetx@...il.com>
CC:     Shardar Mohammed <smohammed@...dia.com>,
        Sowjanya Komatineni <skomatineni@...dia.com>,
        Mantravadi Karthik <mkarthik@...dia.com>
Subject: Re: [PATCH V2] i2c: tegra: disable irq in tegra_i2c_xfer_msg


On 18/06/2019 09:42, Bitan Biswas wrote:
> tegra_i2c_xfer_msg initiates the I2C transfer in DMA
> or PIO mode. It involves steps that need FIFO register
> access, DMA API calls like dma_sync_single_for_device, etc.
> Tegra I2C ISR has calls to tegra_i2c_empty_rx_fifo in PIO mode
> and in DMA/PIO mode writes different I2C registers including
> I2C interrupt status. ISR cannot start processing
> before the preparation step at tegra_i2c_xfer_msg is complete.
> Hence, a synchronization between ISR and tegra_i2c_xfer_msg
> is in place today using spinlock.
> 
> Spinlock busy waits and can add avoidable delays.
> 
> In this patch needed synchronization is achieved by disabling
> I2C interrupt during preparation step and enabling interrupt
> once preparation is over and spinlock is no longer needed.
Sorry but I still don't understand the problem you are trying to solve.
Yes spinlocks are busy waits but is this busy wait an actual problem? If
so what is the problem with this?

It appears that the spinlock was added to prevent error interrupts
occurring until the transfer has started. If this is for error cases,
then probably it is not often that the CPU is stuck busy waiting on the
spinlock.

Furthermore, in addition to the spinlock we also have calls to
tegra_i2c_unmask_irq/tegra_i2c_mask_irq. Therefore, if we are going to
change this it would seem like a good idea to consolidate the
masking/unmasking of IRQs and the spinlock, if possible.

Finally, I still see that we have a spinlock in the downstream kernels
we are shipping and so I would prefer to see such a change also be
tested in the downstream kernels we are releasing.

Cheers
Jon

-- 
nvpublic