linux-kernel - Re: [PATCH 3/4] tty: serial: 8250: omap: convert to using cyclic transfers

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

Message-ID: <56A3EF8E.6020204@hurleysoftware.com>
Date:	Sat, 23 Jan 2016 13:24:30 -0800
From:	Peter Hurley <peter@...leysoftware.com>
To:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	John Ogness <john.ogness@...utronix.de>,
	gregkh@...uxfoundation.org, vinod.koul@...el.com
Cc:	dan.j.williams@...el.com, tony@...mide.com, nsekhar@...com,
	peter.ujfalusi@...com, dmaengine@...r.kernel.org,
	linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/4] tty: serial: 8250: omap: convert to using cyclic
 transfers

On 01/23/2016 12:14 PM, Sebastian Andrzej Siewior wrote:
> On 01/22/2016 05:31 PM, Peter Hurley wrote:
>> Hi John,
>>
>> On 01/22/2016 02:27 AM, John Ogness wrote:
>>> Note that an ugly device-tree lookup hack is implemented in order
>>> to detect if the sDMA engine is being used. This is necessary
>>> because the sDMA driver does not implement pause/resume correctly
>>> and therefore requires slightly different logic for the UART
>>> driver.
>>
>> No, this is not acceptable.
>>
>> Please work with Vinod to refine the dma_get_slave_caps() interface
>> so that dmaengine drivers that don't provide the _documented_ pause/resume
>> support can be identified generically.
> 
> But we could implement the pause/resume bits correctly wait until it is
> merge and post this and rely on the fact that it works (including error
> checking). RMK requested that he wants the UART driver fixed before
> touching the DMA driver and this has been done in meantime. So we could
> go ahead and add the missing pieces to SDMA.

There is zero chance of backporting this.
Let's move forward and fix the problem.

At a minimum, the reason this code needs to know which DMA slave driver
is because the sDMA driver lies about pause support. Rather than continuing
to hide this broken behavior behind the dmaengine API, expose a method
of generically determining what the slave driver actually does.
It's the only sane choice.

Regards,
Peter Hurley

FWIW, I'm not convinced about cyclic transfers. But doing a complete review
of that is a bit off.