On 12/17/2018 05:30 PM, Ezequiel Garcia wrote: > On Sun, 16 Dec 2018 at 19:35, Paul Burton <paul.burton@xxxxxxxx> 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@xxxxxxxx> 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
