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: <552B72DF.7060006@mentor.com>
Date:	Mon, 13 Apr 2015 16:40:15 +0900
From:	jiwang <jiada_wang@...tor.com>
To:	Sebastian Andrzej Siewior <sebastian@...akpoint.cc>
CC:	<gregkh@...uxfoundation.org>, <jslaby@...e.cz>,
	<linux-serial@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<anton_bondarenko@...tor.com>, <dirk.behme@...bosch.com>
Subject: Re: [PATCH v1 11/15] serial: imx: initialized DMA w/o HW flow enabled

Hi Sebastian

On 04/09/2015 09:00 PM, Sebastian Andrzej Siewior wrote:
> On 2014-12-09 18:11:32 [+0900], Jiada Wang wrote:
>> From: Anton Bondarenko <anton_bondarenko@...tor.com>
>>
>> DMA mode for UART can be used even w/o HW flow control with RTS/CTS.
>> So it need to be initialized and enabled earlier.
>>
>> Signed-off-by: Anton Bondarenko <anton_bondarenko@...tor.com>
>> Signed-off-by: Jiada Wang <jiada_wang@...tor.com>
> How was this tested? I read you used the Sambe IMX6Q. I have here the
> Wandboard which is IMX6D and a PBAB01 which is IMX6Q. Both have the same
> issue with this patch, that is once DMA is enabled I receive the data in
> question plus one extra byte which is 0x00.
> That extra byte was not part of transaction. After that, the SDMA driver
> is handling interrupts like crazing and feeding one byte data (usually
> 0x00 but sometimes 0x02 not sure if this new or whatever was there
> before) to the core. Those one byte transaction are bogus of course.
>
> My question is how was this tested. Before your patch none of my boards
> were using DMA because RTS/CTS is not in use and this was a key
> requirement. Now SDMA goes crazy. Is there a SDMA firmware required for
> this to work?
We tested the patch set with our modified kernel tree,
and I find upstream kernel is not building SDMA firmware,
I will submit another patch to add it.

Thanks,
Jiada
> Sebastian

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ