From: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>, Matthew Wilcox <matthew@wil.cx>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>,
rdh@east.sun.com, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org
Subject: Re: [PATCH] pci/pcie: Avoid unnecessary PCIe link retrains
Date: Fri, 06 Nov 2009 10:15:02 +0900 [thread overview]
Message-ID: <4AF37896.4070406@jp.fujitsu.com> (raw)
In-Reply-To: <200911051329.41893.bjorn.helgaas@hp.com>
Bjorn Helgaas wrote:
> On Thursday 05 November 2009 12:07:07 pm Matthew Wilcox wrote:
>> On Thu, Nov 05, 2009 at 12:59:25PM -0600, Bjorn Helgaas wrote:
>>> Here's another possibility, the idea being to collect all the PCIe
>>> stuff in one place. This would require a lot of changes in the PCIe
>>> driver code, but most of them would be trivial.
>> I don't like the idea of kmallocing a 6- or 10-byte data structure
>> ... better to keep it in the pci_dev. Maybe embedding a pcie_dev inside
>> the pci_dev would be a good idea, but unless there're more things to
>> move to it, this seems like a net loss to me.
>
> That's true, it's not worth it for such a small structure. I figured
> there would probably be more PCIe-related stuff that could go there,
> e.g., embedding the link_state directly. But I haven't looked to
> see whether there actually is enough PCIe stuff to make it worthwhile.
>
In my understanding, there are the following PCIe specific data in
struct pci_dev. It is not many.
u8 pcie_cap; *I added this time
u8 pcie_type;
struct pcie_link_state *link_state;
unsigned int ari_enabled:1;
unsigned int is_pcie:1; *No longer needed and will be removed.
unsigned int aer_firmware_first:1;
How about keeping cap offset in pci_dev so far and introducing the
following wrapper function?
static inline pcie_cap(struct pci_dev *pdev)
{
return pdev->pcie_cap;
}
When we actually need a new data structure for PCIe-related stuff in the
future, all we need to do would be changing this wrapper like below.
static inline pcie_cap(struct pci_dev *pdev)
{
struct pcie_dev *pcie = pdev->pcie;
if (pcie)
return pcie->cap;
return 0;
}
Thanks,
Kenji Kaneshige
next prev parent reply other threads:[~2009-11-06 1:15 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-03 21:38 [PATCH] pci/pcie: Avoid unnecessary PCIe link retrains RDH
2009-11-04 19:03 ` Jesse Barnes
2009-11-04 23:28 ` Bjorn Helgaas
2009-11-05 3:05 ` Kenji Kaneshige
2009-11-05 18:59 ` Bjorn Helgaas
2009-11-05 19:07 ` Matthew Wilcox
2009-11-05 20:29 ` Bjorn Helgaas
2009-11-06 1:15 ` Kenji Kaneshige [this message]
2009-11-05 19:11 ` Matthew Wilcox
2009-11-06 2:48 ` Kenji Kaneshige
2009-11-06 22:00 ` Jesse Barnes
2009-11-05 1:38 ` Kenji Kaneshige
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=4AF37896.4070406@jp.fujitsu.com \
--to=kaneshige.kenji@jp.fujitsu.com \
--cc=bjorn.helgaas@hp.com \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=rdh@east.sun.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.