On Tue, Nov 4, 2014 at 6:31 PM, Chuansheng Liu <chuansheng.liu@xxxxxxxxx> wrote: > The JMicron chip 361/363/368 contains one SATA controller and > one PATA controller, they are brother-relation ship in PCI tree, > but for powering on these both controller, we must follow the > sequence one by one, otherwise one of them can not be powered on > successfully. This should mention what's broken and what problem a user would see. This changelog sounds a lot like the one for e6b7e41cdd8c, so I don't know if this is for a new, related problem, or what. > So here we disable the async suspend method for Jmicron chip. > > Bug link: > https://bugzilla.kernel.org/show_bug.cgi?id=81551 > https://bugzilla.kernel.org/show_bug.cgi?id=84861 > > And we can revert the below commit after this patch is applied: > e6b7e41(ata: Disabling the async PM for JMicron chip 363/361) > > Cc: stable@xxxxxxxxxxxxxxx # 3.15+ > Acked-by: Aaron Lu <aaron.lu@xxxxxxxxx> > Signed-off-by: Chuansheng Liu <chuansheng.liu@xxxxxxxxx> > --- > drivers/pci/pci.c | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c > index 625a4ac..53128f0 100644 > --- a/drivers/pci/pci.c > +++ b/drivers/pci/pci.c > @@ -2046,7 +2046,17 @@ void pci_pm_init(struct pci_dev *dev) > pm_runtime_forbid(&dev->dev); > pm_runtime_set_active(&dev->dev); > pm_runtime_enable(&dev->dev); > - device_enable_async_suspend(&dev->dev); > + > + /* > + * The JMicron chip 361/363/368 contains one SATA controller and > + * one PATA controller, they are brother-relation ship in PCI tree, > + * but for powering on these both controller, we must follow the > + * sequence one by one, otherwise one of them can not be powered on > + * successfully, so here we disable the async suspend method for > + * Jmicron chip. > + */ > + if (dev->vendor != PCI_VENDOR_ID_JMICRON) > + device_enable_async_suspend(&dev->dev); I don't like littering the core PCI code with vendor tests like this. This would be the only one, except for an ancient DECchip 21050 bridge erratum. And why would we want a test for *all* JMicron devices here, when you claim the problem only affects a few specific ones? And what's the story with the e6b7e41cdd8c ("ata: Disabling the async PM for JMicron chip 363/361") connection? Is something broken even with e6b7e41cdd8c, and this is a better fix? Or is this simply a different way of fixing the same problem? > dev->wakeup_prepared = false; > > dev->pm_cap = 0; > -- > 1.7.9.5 > -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
