On Thu, 3 Dec 2015 10:04:42 -0500, Peter Hurley wrote: > >> 3. I'd like to split this patch into two patches: > >> a. the core functionality tied to a port->realtime steering knob w/o a > >> userspace interface, and > >> b. the userspace interface for configuring > >> > >> 4. I think the kthread should be per-port. The input handling for the > >> N_TTY line discipline can block for a number of a reasons that I think > >> should be per-tty (which means per-port). Note that the core already > >> allows multiple concurrent flush_to_ldisc() operations on different > >> ttys. > > > > I'm for per-port. Do you envision sharing the kthread with drivers? > > It would be nice if drivers were allowed to schedule their work items > > on the same kthread since some of them (SPI, I2C ones) already have > > kthreads for async work. > > I'm not understanding why uart drivers are using RT kthreads. Devices on async buses (SPI, I2C etc.) cannot do register accesses under spin lock, so anything they do have to be done from kthread (or workqueue if they don't care about RT). -- 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
