From: Yijing Wang <wangyijing@huawei.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
linux-fbdev@vger.kernel.org
Subject: Re: [PATCH 9/9] radeon: use pdev->pm_cap instead of pci_find_capability(..,PCI_CAP_ID_PM)
Date: Thu, 27 Jun 2013 06:50:01 +0000 [thread overview]
Message-ID: <51CBE099.9040802@huawei.com> (raw)
In-Reply-To: <51CBDCE5.1020301@ti.com>
On 2013/6/27 14:34, Tomi Valkeinen wrote:
> On 27/06/13 04:51, Yijing Wang wrote:
>> On 2013/6/26 21:15, Tomi Valkeinen wrote:
>
>>> I couldn't find the rest of this series, and I'm not familiar with PCI.
>>> So: is this patch and "aty128fb: use pdev->pm_cap instead of
>>> pci_find_capability(..,PCI_CAP_ID_PM)" safe to apply for fbdev-3.11
>>> without anything else? I.e. has the PCI core changes been merged in 3.10
>>> or ealier?
>>
>> Hi Tomi,
>> Thanks for your reply. Yes, it's safe, because PCI core has been use pdev->pm_cap to save
>> the pm capability offset already. And PCI core changes related this pm init code has been merged
>> long long ago(since year 2008). This series changes just to simplifier driver code about pm code.
>> It's not necessary to access pci device register to get pm cap again, drivers can use pci device pm_cap
>> member. and this series had no changes in PCI core. The rest of this series like for bnx2, bnx2x etc has
>> been tested and accepted by other subsystems.
>
> Ok, thanks. I'll apply the two patches to my fbdev-3.11 branch.
>
> Tomi
>
>
Thanks very much!
--
Thanks!
Yijing
WARNING: multiple messages have this Message-ID (diff)
From: Yijing Wang <wangyijing@huawei.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
<linux-kernel@vger.kernel.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
<linux-fbdev@vger.kernel.org>
Subject: Re: [PATCH 9/9] radeon: use pdev->pm_cap instead of pci_find_capability(..,PCI_CAP_ID_PM)
Date: Thu, 27 Jun 2013 14:50:01 +0800 [thread overview]
Message-ID: <51CBE099.9040802@huawei.com> (raw)
In-Reply-To: <51CBDCE5.1020301@ti.com>
On 2013/6/27 14:34, Tomi Valkeinen wrote:
> On 27/06/13 04:51, Yijing Wang wrote:
>> On 2013/6/26 21:15, Tomi Valkeinen wrote:
>
>>> I couldn't find the rest of this series, and I'm not familiar with PCI.
>>> So: is this patch and "aty128fb: use pdev->pm_cap instead of
>>> pci_find_capability(..,PCI_CAP_ID_PM)" safe to apply for fbdev-3.11
>>> without anything else? I.e. has the PCI core changes been merged in 3.10
>>> or ealier?
>>
>> Hi Tomi,
>> Thanks for your reply. Yes, it's safe, because PCI core has been use pdev->pm_cap to save
>> the pm capability offset already. And PCI core changes related this pm init code has been merged
>> long long ago(since year 2008). This series changes just to simplifier driver code about pm code.
>> It's not necessary to access pci device register to get pm cap again, drivers can use pci device pm_cap
>> member. and this series had no changes in PCI core. The rest of this series like for bnx2, bnx2x etc has
>> been tested and accepted by other subsystems.
>
> Ok, thanks. I'll apply the two patches to my fbdev-3.11 branch.
>
> Tomi
>
>
Thanks very much!
--
Thanks!
Yijing
next prev parent reply other threads:[~2013-06-27 6:50 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-18 8:24 [PATCH 9/9] radeon: use pdev->pm_cap instead of pci_find_capability(..,PCI_CAP_ID_PM) Yijing Wang
2013-06-18 8:24 ` Yijing Wang
2013-06-25 12:06 ` Yijing Wang
2013-06-25 12:06 ` Yijing Wang
2013-06-26 1:13 ` Yijing Wang
2013-06-26 1:13 ` Yijing Wang
2013-06-26 13:15 ` Tomi Valkeinen
2013-06-26 13:15 ` Tomi Valkeinen
2013-06-27 1:51 ` Yijing Wang
2013-06-27 1:51 ` Yijing Wang
2013-06-27 6:34 ` Tomi Valkeinen
2013-06-27 6:34 ` Tomi Valkeinen
2013-06-27 6:50 ` Yijing Wang [this message]
2013-06-27 6:50 ` Yijing Wang
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=51CBE099.9040802@huawei.com \
--to=wangyijing@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=plagnioj@jcrosoft.com \
--cc=tomi.valkeinen@ti.com \
/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.