From: Barto <mister.freeman@laposte.net>
To: Bjorn Helgaas <bhelgaas@google.com>,
Chuansheng Liu <chuansheng.liu@intel.com>
Cc: Aaron Lu <aaron.lu@intel.com>, Tejun Heo <tj@kernel.org>,
Rafael Wysocki <rjw@rjwysocki.net>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] PCI: Do not enable async suspend for JMicron chips
Date: Wed, 05 Nov 2014 19:46:31 +0100 [thread overview]
Message-ID: <545A7087.3050802@laposte.net> (raw)
In-Reply-To: <CAErSpo6cWP2ngErLVzqASkeQOLsB7JjgCC8UuA-S=Lz=AJyf6Q@mail.gmail.com>
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
in simple words : JMicron IDE/Sata controlers family ( JMBxxx ) are not
fully compatible with async_suspend feature, when a user tries to put
his PC on standby mode then at wake-up JMicron IDE/Sata controlers will
not work, because of a brother-relation between the SATA and IDE part on
this JMicron PCI card
Le 05/11/2014 19:01, Bjorn Helgaas a écrit :
> On Tue, Nov 4, 2014 at 6:31 PM, Chuansheng Liu <chuansheng.liu@intel.com> 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@vger.kernel.org # 3.15+
>> Acked-by: Aaron Lu <aaron.lu@intel.com>
>> Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
>> ---
>> 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
>>
>
next prev parent reply other threads:[~2014-11-05 18:46 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-05 1:31 [PATCH] PCI: Do not enable async suspend for JMicron chips Chuansheng Liu
2014-11-05 18:01 ` Bjorn Helgaas
2014-11-05 18:46 ` Barto [this message]
2014-11-05 19:03 ` Bjorn Helgaas
2014-11-06 1:36 ` Barto
2014-11-06 1:48 ` Liu, Chuansheng
2014-11-06 1:48 ` Liu, Chuansheng
2014-11-06 4:08 ` Bjorn Helgaas
2014-11-06 5:29 ` Barto
2014-11-06 5:29 ` Liu, Chuansheng
2014-11-06 5:29 ` Liu, Chuansheng
2014-11-06 5:36 ` Aaron Lu
2014-11-06 6:39 ` Liu, Chuansheng
2014-11-06 6:39 ` Liu, Chuansheng
2014-11-06 8:25 ` Barto
2014-11-06 17:39 ` Bjorn Helgaas
2014-11-06 21:02 ` Barto
2014-11-07 1:09 ` Liu, Chuansheng
2014-11-07 1:09 ` Liu, Chuansheng
-- strict thread matches above, loose matches on Subject: below --
2014-11-05 1:07 Chuansheng Liu
2014-11-05 1:33 ` Aaron Lu
2014-11-05 1:35 ` Aaron Lu
2014-11-05 16:31 ` Tejun Heo
2014-11-05 17:58 ` Barto
2014-11-05 18:04 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=545A7087.3050802@laposte.net \
--to=mister.freeman@laposte.net \
--cc=aaron.lu@intel.com \
--cc=bhelgaas@google.com \
--cc=chuansheng.liu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.