Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Avoid lock collision b/w SerialBase & UARTSerial #4538
Fixes issue #4537. SerialBase and UARTSerial happened to have same names
Doesn't change behaviour.
tx_irq_enabled is false to start with. It's only true when we find we managed to fill the hardware buffers in a write.
I guess you could deduce we're probably writable if tx_irq_enabled is false, but that isn't 100% I think - Iwould have to ponder exact buffer fills.
And it doesn't solve the original problem or lock confusion - we're also calling SerialBase::writeable() from interrupt, not just that write call. I think we have to do it like that to ensure we fill the serial buffer to deassert and retrigger the interrupt, if it's edge-based. Writing 1 byte per interrupt may not be sufficient - IRQ as we became writable, after writing a byte still still writable, no new interrupt.
The interrupt enable/disable logic and pump flow was largely copied from the original BufferedSerial - basically because I had good confidence that it had worked with a wide variety of serial HALs. I didn't fancy trying anything new, figuring that it was managing to avoid any API landmines.
Hi @kjbracey-arm, that is understandable. I think buffered serial got around the problem by not having a lock at all.
As for the call to writeable, this is only done in tx_irq(). If there isn't a transfer in progress, write() simulates an isr by calling tx_irq() in a critical section, which is where the problem comes in. If you remove the check of writeable from tx_irq then it would fix both write() and the isr.
I'm not saying you need to go with this change. I just wanted to propose it, since could potentially be a smaller and more straight forward change. The lock and unlock functions of SerialBase could be used as the lock for both. I'll leave the call to if you want to do it this way, or with the existing implementation up to you and @hasnainvirk. Either way works for me.
I don't believe any changes are required to this PR.
@c1728p9 has been suggesting some different ways of implementing the data pump, but they're as yet unproven. And he said "Either way works for me."
This PR avoids the new asserts without changing the proven data pump behaviour. It was never intended that there be any SerialBase mutex claims, and during development the accidental mutex claims just failed silently, as they do now with debug off.