On Wed, 25 Jul 2018 10:56:22 +0200, Michael Allwright wrote: > In some hardware I am developing, I have used the SC16IS7XX to connect > two AVR microcontrollers back to my main processor running Linux. > These microcontrollers implement an control interface which is > modelled in Linux as a multi-function device. The set up is based on > the driver for the RAVE Supervisory Processor: > https://lwn.net/Articles/724765/ > > One issue during initialisation when using serdev with SC16IS7XX is > that after uart_add_one_port has been called, the child driver may be > started on a different kernel thread and may start calling the startup > or set_termios functions of the serial driver before it has finished > probing. I temporarily resolved this issue with a hack which involved > adding a "ready" boolean to the driver. However, there are two proper > solutions to this problem that I can think of: either serdev should > somehow check that the probe was completed (successfully) before > trying to load child drivers or the SC16IS7XX should have a mutex that > better enforces the order in which its functions are called > (particularly during initialization). My testing suggests that the > latter may be the better solution, since even outside of the > initialization context and when using the two ttys heavily at the same > time, it is not hard to knock the SC16IS7XX device into a state where, > at a minimum, the silicon stops sending interrupts. I think this > ordering of function calls may also be partly responsible for > "sc16is7xx 1-0048: ttySC0: Unexpected interrupt: 8" kernel messages > that are mentioned in other threads. Hm.. I'm probably wrong, but wouldn't it help to move uart_add_one_port() way down in sc16is7xx_probe() so that it's the last performed action? And only done when probe is actually finished? -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
