linux-kernel - Re: Sluggish AT91 I2C driver causes SMBus timeouts

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: <20171017075807.tsh5walc3sla3pth@rfolt0960.corp.atmel.com>
Date:   Tue, 17 Oct 2017 09:58:07 +0200
From:   Ludovic Desroches <ludovic.desroches@...rochip.com>
To:     Peter Rosin <peda@...ntia.se>
CC:     Alan Cox <gnomes@...rguk.ukuu.org.uk>,
        Ludovic Desroches <ludovic.desroches@...rochip.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>
Subject: Re: Sluggish AT91 I2C driver causes SMBus timeouts

Hi Peter,

On Fri, Oct 13, 2017 at 05:01:04PM +0200, Peter Rosin wrote:
> On 2017-10-13 15:29, Alan Cox wrote:
> > On Thu, 12 Oct 2017 13:35:17 +0200
> > Peter Rosin <peda@...ntia.se> wrote:
> > 
> >> Hi!
> >>
> >> I have encountered an "interesting" bug. It silently corrupts data
> >> and is generally nasty...
> >>
> >> On an I2C bus, driven by the at91 driver and DMA (an Atmel
> >> sama5d31 chip), I have an 256 byte eeprom (NXP SE97BTP). I'm using
> >> Linux v4.13.
> > 
> > If your force the transfer to PIO does it behave ? Does the controller in
> > fact need to siwtch to PIO for SMBUS ?
> 
> Like, what if I disable DMA?
> 
> I saw no way to do that, short of short-cutting a few things in the
> driver code. So, did that and I cannot tickle the bug. But I don't
> know if that makes me safe?
> 
> Ludovic, any reason to believe disabling DMA will prevent these
> stalls, or will they just appear under different circumstances?

Sorry I am currently on vacation. I outlined this discussion.

As you noticed, there are some hardware constraints when using DMA.
Switching from DMA to PIO to handle the end of the transfer is probably the
root cause of the delay you get.

I read you added traces, did you manage to get some information about
timings? Do we waste time waiting for the dma callback? for the RXRDY
interrupt?

If we spend time waiting for the dma callback for sure, disabling DMA
should prevent these stalls. If the stall is inbetween the two last
RXRDY interrupts, it seems it can appear under different circumstances.

> 
> I used this dirty "patch" to i2c-at91.c:at91_twi_configure_dma() for
> testing:
> 
> -	dev->use_dma = true;
> +	//dev->use_dma = true;
> 

You can simply remove dma bindings from the i2c node to force the i2c
controller to use the PIO mode.

Regards

Ludovic

> Cheers,
> Peter