From patchwork Thu Nov 6 06:39:14 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chuansheng Liu X-Patchwork-Id: 5239441 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: X-Original-To: patchwork-linux-pci@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id D59229F8B3 for ; Thu, 6 Nov 2014 06:41:42 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 118FC20107 for ; Thu, 6 Nov 2014 06:41:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 12433200F4 for ; Thu, 6 Nov 2014 06:41:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751063AbaKFGlj (ORCPT ); Thu, 6 Nov 2014 01:41:39 -0500 Received: from mga11.intel.com ([192.55.52.93]:17951 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750828AbaKFGli (ORCPT ); Thu, 6 Nov 2014 01:41:38 -0500 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 05 Nov 2014 22:41:38 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,324,1413270000"; d="scan'208";a="627479089" Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82]) by fmsmga002.fm.intel.com with ESMTP; 05 Nov 2014 22:41:34 -0800 Received: from kmsmsx153.gar.corp.intel.com (172.21.73.88) by PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 6 Nov 2014 14:39:17 +0800 Received: from shsmsx104.ccr.corp.intel.com (10.239.110.15) by KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 6 Nov 2014 14:39:16 +0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.174]) with mapi id 14.03.0195.001; Thu, 6 Nov 2014 14:39:15 +0800 From: "Liu, Chuansheng" To: "Lu, Aaron" , Bjorn Helgaas CC: Barto , "Tejun Heo (tj@kernel.org)" , Rafael Wysocki , "linux-pci@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: RE: [PATCH] PCI: Do not enable async suspend for JMicron chips Thread-Topic: [PATCH] PCI: Do not enable async suspend for JMicron chips Thread-Index: AQHP+YOe9LB9XnS4YkW20ZDpwHx2W5xTJUyQ Date: Thu, 6 Nov 2014 06:39:14 +0000 Message-ID: <27240C0AC20F114CBF8149A2696CBE4A01EB7CC3@SHSMSX101.ccr.corp.intel.com> References: <1415151063-2530-1-git-send-email-chuansheng.liu@intel.com> <545A7087.3050802@laposte.net> <27240C0AC20F114CBF8149A2696CBE4A01EB7713@SHSMSX101.ccr.corp.intel.com> <27240C0AC20F114CBF8149A2696CBE4A01EB7B96@SHSMSX101.ccr.corp.intel.com> <545B08DF.2090608@intel.com> In-Reply-To: <545B08DF.2090608@intel.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP > -----Original Message----- > From: Lu, Aaron > Sent: Thursday, November 06, 2014 1:37 PM > To: Liu, Chuansheng; Bjorn Helgaas > Cc: Barto; Tejun Heo (tj@kernel.org); Rafael Wysocki; > linux-pci@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH] PCI: Do not enable async suspend for JMicron chips > > On 11/06/2014 01:29 PM, Liu, Chuansheng wrote: > > Hello Bjorn, > > > >> -----Original Message----- > >> From: Bjorn Helgaas [mailto:bhelgaas@google.com] > >> Sent: Thursday, November 06, 2014 12:09 PM > >> To: Liu, Chuansheng > >> Cc: Barto; Tejun Heo (tj@kernel.org); Lu, Aaron; Rafael Wysocki; > >> linux-pci@vger.kernel.org; linux-kernel@vger.kernel.org > >> Subject: Re: [PATCH] PCI: Do not enable async suspend for JMicron chips > >> > >> On Wed, Nov 5, 2014 at 6:48 PM, Liu, Chuansheng > >> wrote: > >>> Hello Bjorn, > >>> > >>>> -----Original Message----- > >>>> From: Bjorn Helgaas [mailto:bhelgaas@google.com] > >>>> Sent: Thursday, November 06, 2014 3:04 AM > >>>> To: Barto > >>>> Cc: Liu, Chuansheng; Lu, Aaron; Tejun Heo; Rafael Wysocki; > >>>> linux-pci@vger.kernel.org; linux-kernel@vger.kernel.org > >>>> Subject: Re: [PATCH] PCI: Do not enable async suspend for JMicron chips > >>>> > >>>> On Wed, Nov 5, 2014 at 11:46 AM, Barto > >>>> 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. > > Understand your point, in fact, before this patch submitted, I had written > another patch https://lkml.org/lkml/2014/9/24/68 > > which addressed to add the quirk-type solution in ATA code, and Aaron given > better suggestion that implemented at pci_pm_init(). > > How do you think of it? Thanks. > > I think Bjorn means that we should place the code as a fixup somewhere > in the quirks.c. I didn't take a closer look but DECLARE_PCI_FIXUP_FINAL > for those JMicron PCI devices seems to be a proper phase. Thanks Aaron, then how about below patch? Barto, Could you have a try on your side? Thanks. diff --git a/drivers/ata/pata_jmicron.c b/drivers/ata/pata_jmicron.c index 47e418b..9e85f86 100644 --- a/drivers/ata/pata_jmicron.c +++ b/drivers/ata/pata_jmicron.c @@ -158,6 +158,21 @@ static int jmicron_init_one (struct pci_dev *pdev, const struct pci_device_id *i return ata_pci_bmdma_init_one(pdev, ppi, &jmicron_sht, NULL, 0); } +/* + * For JMicron chips, we need to disable the async_suspend method, otherwise + * they will hit the power-on issue when doing device resume, add one quick + * solution to disable the async_suspend method. + */ +static void pci_async_suspend_fixup(struct pci_dev *pdev) +{ + /* + * disabling the async_suspend method for JMicron chips to + * avoid device resuming issue. + */ + device_disable_async_suspend(&pdev->dev); +} +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, pci_async_suspend_fixup); + static const struct pci_device_id jmicron_pci_tbl[] = { { PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_CLASS_STORAGE_IDE << 8, 0xffff00, 0 },