----- Original Message ----- > From: "Andy Shevchenko" <andriy.shevchenko@xxxxxxxxxxxxxxx> > To: "Aaron Sierra" <asierra@xxxxxxxxxxx> > Sent: Tuesday, July 30, 2019 4:01:59 AM > On Mon, Jul 29, 2019 at 10:11:51AM -0500, Aaron Sierra wrote: >> ----- Original Message ----- >> > From: "Andy Shevchenko" <andriy.shevchenko@xxxxxxxxxxxxxxx> >> > To: "Aaron Sierra" <asierra@xxxxxxxxxxx> >> > Sent: Monday, July 29, 2019 7:00:59 AM >> > On Sun, Jul 28, 2019 at 05:12:09PM -0500, Aaron Sierra wrote: >> >> ----- Original Message ----- >> >> > From: "Andy Shevchenko" <andriy.shevchenko@xxxxxxxxxxxxxxx> >> >> > Sent: Sunday, July 21, 2019 9:26:59 AM > >> > I'm not so familiar with the hardware, will it not give any side-effects? >> >> Clearing INT0 prevents PCI interrupts from getting stuck, either on in the >> case of level-sensitive interrupts (e.g. INTx) or apparently-off in the case >> of edge-sensitive interrupts (e.g. MSI), due to sources outside of the >> typical 8250 serial port scope. Interrupts due to port wake-up after >> idle/sleep are the best documented problem case. >> >> I do not think it was ever ideal that each port cleared INT0 multiple times >> during startup. Clearing INT0 after we register the interrupt handler >> responsible for INT0 should be enough to ensure that we won't run into either >> case. The handler runs even if no ports are "up", so individual ports don't >> have to worry so much. >> >> My original suggestion was incomplete in its handling of PCI device >> suspense/resume. A complete solution would read INT0 in exar_resume(), too. > > Thanks for explanation, perhaps you can prepare a follow up on top on my series. Andy, Sure, I can do that. You're saying that you'd submit a patch for the INT0 removal as the last patch in your series? >> > So, I prefer do this in a separate change, so we may see how it goes. >> >> I think it's fine to defer this change to a later patch, but I would like to >> see the commit message body for the current patch be more explicit that it is >> not moving *all* Exar quirks. I wonder, too, if these should be broken >> down into separate patches for the three classes of quirks that you move: >> >> * autoconfig_16550a() >> * serial8250_do_[get|set]_divisor() >> * serial8250_set_sleep() > > Yes, this will be better in case if some problems would be discovered in the > future, hope none. > > So, let me split this to three, and then, if you have a chance to provide the > one described above, I will chain it to the series. I'll send it to you privately. Aaron > -- > With Best Regards, > Andy Shevchenko
