On Wed, Nov 5, 2014 at 6:48 PM, Liu, Chuansheng <[email protected]> wrote: > Hello Bjorn, > >> -----Original Message----- >> From: Bjorn Helgaas [mailto:[email protected]] >> Sent: Thursday, November 06, 2014 3:04 AM >> To: Barto >> Cc: Liu, Chuansheng; Lu, Aaron; Tejun Heo; Rafael Wysocki; >> [email protected]; [email protected] >> Subject: Re: [PATCH] PCI: Do not enable async suspend for JMicron chips >> >> On Wed, Nov 5, 2014 at 11:46 AM, Barto <[email protected]> >> wrote: >> > this patch solves these 2 bug reports : >> > >> > https://bugzilla.kernel.org/show_bug.cgi?id=84861 >> > >> > https://bugzilla.kernel.org/show_bug.cgi?id=81551 >> >> Those bugs were already mentioned. But e6b7e41cdd8c claims to solve >> https://bugzilla.kernel.org/show_bug.cgi?id=81551, and 84861 is a >> duplicate of 81551, so it should also be fixed by e6b7e41cdd8c. >> >> So the question is, why was e6b7e41cdd8c insufficient? Presumably it >> was tested and somebody thought it did fix the problem. > > The first patch e6b7e41cdd8c which is just exclude some of JMicron > chips(363/361) out of async_suspend, > then Barto found the same issue on JMicron 368, so we need one more general > patch to let JMicron chips > out of async_suspend, so we make this patch. > > Bjorn, tj, > Could you kindly take this patch? As Barto said, it effected the user > experience indeed, thanks.
Thanks for clarifying the changelog as far as the different chips and the different bugzillas. But you haven't addressed my concerns about (1) putting a PCI vendor ID check in the generic PCI core code, and (2) applying this to *all* JMicron devices. You might want to explore a quirk-type solution or maybe just add the JMicron 368 to the checks added by e6b7e41cdd8c. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
