Hi Anders, Sorry to cause you trouble. > > I really don't know what to do here, sorry. Are you saying a specific > > commit has broken this? If so, did you test if you made a change it > > fixed the issue? > > Yes, commit 366f6c955d4d1a5125ffcd6875ead26a3c7a2a1c broke the one to one > correspondence > between programmed and actual baudrate; reverting it (and > 9c5c8aaed50bf3478073ab51b8b1f3f5327d3cfa > that builds on that patch) restores the expected functionality (i.e. you get > the baudrate you ask for) > on 5.19.8. I have implemented the calculation using parameters from original OxSemi datasheets and verified this code across three architectures available to me (POWER9, RISC-V, 32-bit x86) and a couple of cards made by different manufacturers connected to a non-OxSemi serial device each at the other end. I have checked the usual baud rates of up to 460800bps. Higher baud rates work too, though I could only try them between OxSemi devices, so actual rates were not verified for correctness. And offhand I can say it works just fine at 230400bps with 6.0.0-rc2 as at commit 10d4879f9ef0 and my RISC-V machine (using an EXSYS EX-44171 1S+1P port PCIe option card, built around the OXPCIe952 too) talking to a remote console server in my lab. I don't have an oscilloscope available to check actual waveforms produced. > > What do you suggest happen here? > Either there is a bug in the code, or the chipset on my card (a Delock 2xRS232 > card) is not a true oxford > chipset (the package and PCI id's says that they are). A bug can never be ruled out. I doubt that Delock would use a fake chip or indeed that anyone would choose to clone an OxSemi part, which seems fairly complex to me for a serial port. > Since the chip seems to be discontinued since 2014 (see > https://www.mouser.com/PCN/PLX_Technology_2013_8.pdf), > I think a revert would not be uncalled for. The problem is the original calculation is inaccurate enough for the serial interface not to communicate correctly at higher baud rates. I found setting two stop bits while talking to a remote end that has one stop bit set a possible workaround for some cases, but why not do the calculation correctly in the first place? If you're willing to debug it, then I'll be more than happy to supply you with diagnostic patches, some of which I made in the development of the fix. Also what processor architecture do you use the interface with? Maciej
