[ +Rafael ] On 11/13/2015 02:32 PM, Gabriel Krisman Bertazi wrote: > 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? I think this PCI error is the only way that userspace could ever see a suspended serial device. I could be wrong though. Regards, Peter Hurley -- 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
