Re: [PATCH] Revert "serial: 8250: Fix clearing FIFOs in RS485 mode again"

From: Marek Vasut <marex@denx.de>
To: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>,
	Paul Burton <paul.burton@mips.com>
Cc: "linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Burton <pburton@wavecomp.com>,
	Daniel Jedrychowski <avistel@gmail.com>,
	"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
	stable <stable@vger.kernel.org>,
	Ezequiel Garcia <ezequiel@collabora.com>
Subject: Re: [PATCH] Revert "serial: 8250: Fix clearing FIFOs in RS485 mode again"
Date: Mon, 17 Dec 2018 18:20:15 +0100	[thread overview]
Message-ID: <61a3177f-4e8d-fc51-1e81-95af3baab3a8@denx.de> (raw)
In-Reply-To: <CAAEAJfDHvGTPN9u4zwWRFvK1WmpLmz87CjsjzmyhcExTGHQPmA@mail.gmail.com>

On 12/17/2018 05:30 PM, Ezequiel Garcia wrote:
> On Sun, 16 Dec 2018 at 19:35, Paul Burton <paul.burton@mips.com> wrote:
>>
>> Hi Ezequiel,
>>
>> On Sun, Dec 16, 2018 at 07:28:22PM -0300, Ezequiel Garcia wrote:
>>> On Sun, 16 Dec 2018 at 19:24, Paul Burton <paul.burton@mips.com> wrote:
>>>> This helps, but it only addresses one part of one of the 4 reasons I
>>>> listed as motivation for my revert. For example serial8250_do_shutdown()
>>>> also clearly intends to disable the FIFOs.
>>>>
>>>
>>> OK. So, let's fix that :-)
>>
>> I already did, or at least tried to, on Thursday [1].
>>
>>> By all means, it would be really nice to push forward and fix the garbage
>>> issue on JZ4780, as well as the transmission issue on AM335x.
>>>
>>> AM335x is a wildly popular platform, and it's not funny to break it.
>>
>> Well, clearly not if it was broken in v4.10 & only just fixed..? And
>> from Marek's commit message the patch in v4.10 doesn't break the whole
>> system just RS485.
>>
> 
> Careful here. It's naive to consider v4.10 as old in this context.
> 
> AM335x is used in hundreds of thousands of products, probably
> "industrial" products.
> Manufacturers don't always follow the kernel, and it's entirely
> likely that they notice a regression only when developing a new product,
> or when rebasing on top of a newer longterm kernel.
> 
> Then again, I don't have any details about what is Marek's original fix
> actually fixing.
> 
> Marek: could you please post the test case that you used to validate your fix?
> I can't find that anywhere.

I can't share the testcase itself because it has no license and I didn't
write it, but I can tell you what it's doing. (I'll check if I can share
the testcase verbatim too, I just sent an email to the author)

The test spawns two threads, one sending , one receiving. The sending
thread sends 8 bytes of data from /dev/ttyS4 , the receiving thread
receives the data on /dev/ttyS2 and compares the pattern. The port
settings is B1000000 8N1 with rs485conf.flags set to SER_RS485_ENABLED
and SER_RS485_RTS_AFTER_SEND. Sometimes the received data do not match
the sent data, but rather look as if one character was left over from
the previous transmission in the FIFO.

Those two UARTs are connected together by two wires, without any real
RS485 hardware to minimize the hardware complexity (it's easy to
implement that on the pocketbeagle, which is the cheap option here).

-- 
Best regards,
Marek Vasut