Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> writes: > On 11/11/2015 09:18 AM, Peter Hurley wrote: > > Re-checking the 8250_pci sub-driver, I see it goes right through > serial8250_suspend_port() which assumes the 8250 port will not be unregistered > concurrently, so I assume the PCI subsystem serializes i/o error handling > with device removal, in which case the translation from > line => uart_8250_port => uart_port is straightforward. > > Below is the serial core machinery that can be used to tick TTY_IO_ERROR. > Peter, Thanks for your help with this issue. ticking TTY_IO_ERROR seems a far superior solution that I admit I even considered, but disregarded for some reason. Thanks also for implementing the machinery to do that. I'll follow up with a patch that uses your new interface early next week, as soon as I do some error injection tests to validate the new version. On the other hand, it seems to me that TIOCMGET and TIOCMSET calls shouldn't get to a suspended device by any reason, even if TTY_IO_ERROR is not set. Not sure if this scenario is possible outside of the PCI error context, though. I'm still getting familiar with the tty stack so I might be wrong. If this is the really the case, maybe we should include my previous fix even though we also pursue the TTY_IO_ERROR fix. What do you think? Thanks, -- Gabriel Krisman Bertazi -- 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
