From: 松本博郎 <matsumoto.hiroo@jp.fujitsu.com>
To: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>,
Bjorn Helgaas <bhelgaas@google.com>
Cc: jbarnes@virtuousgeek.org, linux-pci@vger.kernel.org
Subject: Re: [RFC] pciehp: Add archdata setting
Date: Wed, 04 Apr 2012 17:03:07 +0900 [thread overview]
Message-ID: <4F7C003B.4040208@jp.fujitsu.com> (raw)
In-Reply-To: <4F7AA3A2.1080900@jp.fujitsu.com>
Hi, Bjorn and Kaneshige
Thanks for your comments and proposal.
I will rethink a way of setting archdata with pcibios_xxx() hook or bus
notifier.
Regards.
Hiroo MATSUMOTO
>>> I'm trying to use pciehp on powerpc platform.
>>> I set e1000e card to PCI Express bridge that has PCI Express HotPlug
>>> Capability.
>>>
>>> There is problem when poweron PCI Express HotPlug slot with pciehp.
>>> e1000e driver needs dma_ops in struct dev_archdata, but archdata isn't
>>> set (dma_ops is NULL) when probe from pciehp.
>>> Then e1000e driver returns error as below.
>>>
>>> -sh-3.2# echo 1> /sys/bus/pci/slots/1/power
>>> <snip>
>>> [ 65.493662] pci 0000:03:00.0: BAR 2: set to [io
>>> 0xff7ee000-0xff7ee01f] (PCI address [0x1000-0x101f])
>>> [ 65.502890] pcieport 0000:02:01.0: PCI bridge to [bus 03-03]
>>> [ 65.508555] pcieport 0000:02:01.0: bridge window [io
>>> 0xff7ee000-0xff7eefff]
>>> [ 65.515785] pcieport 0000:02:01.0: bridge window [mem
>>> 0xa0100000-0xa01fffff]
>>> [ 65.523015] pcieport 0000:02:01.0: bridge window [mem
>>> 0xa0200000-0xa02fffff 64bit pref]
>>> [ 65.531238] pci 0000:03:00.0: no hotplug settings from platform
>>> [ 65.538361] e1000e 0000:03:00.0: Disabling ASPM L1
>>> [ 65.543616] e1000e 0000:03:00.0: enabling device (0000 -> 0002)
>>> [ 65.549876] e1000e 0000:03:00.0: No usable DMA configuration,
>>> aborting
>>> [ 65.557194] e1000e: probe of 0000:03:00.0 failed with error -5
>>> -sh-3.2# lspci
>>> <snip>
>>> 0000:03:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit
>>> Ethernet Controller (Copper) (rev 06)
>>> <snip>
>>> -sh-3.2# ifconfig -a
>>> <snip> // There is no network interface for 82572EI
>>>
>>> If archdata.dma_ops is NULL on x86 platform, e1000e will get dma_ops
>>> without archdata.
>>> So e1000e driver doesn't return error.
>>>
>>> I think that archdata should be set before driver probe (e.g pciehp).
>>> I tried to fix it (pciehp-add-archdata.patch), but I'm not good at PCI
>>> driver..., so please give better way.
>>
>> Interesting. It would be nice if we could set archdata the same way
>> for both devices present at boot and those hot-added later.
>
> Yes. But it might be not so easy...
>
>> Can you
>> figure out where archdata is set for devices present at boot?
>
> I read some x86 and powerpc code to setup archdata. x86 and powerpc
> have different way to setup archdata. And it seems archdata is not
> set in one location, each member in the archdata is setup in the
> different locations.
>
> On x86, archdata.dma_ops is set in the pci_iommu_init() code path, which
> is called through rootfs_initcall(). On powerpc, archdata.dma_ops is set
> in pcibios_fixup_bus() code path.
>
> Here are my notes.
>
> x86 (calgary iommu)
> ===================
> rootfs_initcall()
> => pci_iommu_init()
> => x86_init.iommu.iommu_init() (== calgary_iommu_init())
> => calgary_init()
>
> calgary_init()
> {
> for_each_pci_dev() {
> dev->dev.archdata.dma_ops = &calgary_dma_ops;
> }
> }
>
> x86 (amd iommu)
> ===============
> rootfs_initcall()
> => pci_iommu_init()
> => x86_init.iommu.iommu_init() (== amd_iommu_init())
> => amd_iommu_init_dma_ops()
> => device_dma_ops_init()
>
> device_dma_ops_init()
> {
> for_each_pci_dev() {
> pdev->dev.archdata.dma_ops = &amd_iommu_dma_ops;
> }
>
> PowerPC
> =======
> pci_scan_child_bus()
> => pcibios_fixup_bus()
> => pcibios_setup_bus_devices()
> => set_dma_ops() # for each device on the bus
> (default)
> => ppc_md.pci_dma_dev_setup() # for each device on the bus
> (machine depend)
>
> static inline void set_dma_ops(struct device *dev, struct dma_map_ops *ops)
> {
> dev->archdata.dma_ops = ops;
> }
>
>
> One possible idea is that to setup archdata in the pcibios_xxx() hook.
> (for example, use existing pcibios_enable_device(), or provide new
> hook like pcibios_setup_device() which is called by pci_setup_device).
>
> Another idea is that to add support for hot-plug to each iommu (dma)
> code. Maybe it can be implemented by using bus notifier.
>
> Regards,
> Kenji Kaneshige
>
next prev parent reply other threads:[~2012-04-04 8:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-02 7:42 [RFC] pciehp: Add archdata setting 松本博郎
2012-04-02 14:13 ` Bjorn Helgaas
2012-04-03 6:26 ` 松本博郎
2012-04-03 7:53 ` Kenji Kaneshige
2012-04-03 7:15 ` Kenji Kaneshige
2012-04-04 8:03 ` 松本博郎 [this message]
2012-04-12 5:00 ` Hiroo Matsumoto
2012-04-12 13:12 ` Bjorn Helgaas
2012-04-12 23:59 ` Hiroo Matsumoto
2012-04-16 6:32 ` Hiroo Matsumoto
2012-04-23 17:21 ` Bjorn Helgaas
2012-04-26 10:00 ` Hiroo Matsumoto
2012-05-10 10:38 ` Hiroo Matsumoto
2012-05-10 12:09 ` Kenji Kaneshige
2012-05-15 23:20 ` Bjorn Helgaas
2012-05-23 1:33 ` Hiroo Matsumoto
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=4F7C003B.4040208@jp.fujitsu.com \
--to=matsumoto.hiroo@jp.fujitsu.com \
--cc=bhelgaas@google.com \
--cc=jbarnes@virtuousgeek.org \
--cc=kaneshige.kenji@jp.fujitsu.com \
--cc=linux-pci@vger.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.