On Fri, 15 Sep 2023, Thomas Gleixner wrote: > >> Patches 2-74 switch all uart port locking call sites to use the new > >> wrappers. These patches were automatically generated using coccinelle. > > > > Hmm, no need to do this for drivers/tty/serial/zs.c? > > zs.c does not use port lock at all. It has like a couple of other > drivers a local homebrewn spinlock. Ah, right, that's because there are registers shared between two ports within one SCC, so the spinlock has to be shared as well. This also indicates that dz.c is wrong and shouldn't be using a per-port spinlock as the DZ has a shared register set between all the four ports (it's a serial line multiplexer rather than a set discrete ports; up to 8 lines are architecturally supported, though we don't have support in Linux for systems having those), e.g. there's only one 16-bit receiver buffer register for all the four ports, supplying the 8-bit character received along with the receive status and the number of the line this data arrived on, and similarly there's only one transmit data register, which supplies data to the next enabled line whose transmit buffer needs servicing, and the chip routes the data itself. Therefore the driver ought to use a shared spinlock too. I guess it wasn't noticed so far because DZ devices aren't that common (and my usual test machine is currently broken too, pending an SRAM chip replacement, hopefully in the next few weeks) and then hardly ever more than one serial line has been used at a time with these devices. It looks like the first issue for me to look into once the machine has been fixed. Maybe dz.c shouldn't be touched by this series then? (Though obviously both drivers will have to be eventually adapted for the ultimate console rework.) Thanks for your input, as it turns out it has had an unexpected outcome. Maciej
