All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hiroo Matsumoto <matsumoto.hiroo@jp.fujitsu.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>,
	jbarnes@virtuousgeek.org, linux-pci@vger.kernel.org
Subject: Re: [RFC] pciehp: Add archdata setting
Date: Fri, 13 Apr 2012 08:59:16 +0900	[thread overview]
Message-ID: <4F876C54.5040408@jp.fujitsu.com> (raw)
In-Reply-To: <CAErSpo6Xb6rbZ757VHuQnWWsXbnygTM9JQFzvOnOiM895D+R-g@mail.gmail.com>

Hi, Bjorn


Thanks for your research and comment.

As you said, a way of registering code with bus_register_notifier(), 
which will be called in device_add(), is better one than 
pcibios_enable_device().
I will try to write code with bus_register_notifier().


Regards.

Hiroo MATSUMOTO

> On Wed, Apr 11, 2012 at 11:00 PM, Hiroo Matsumoto
> <matsumoto.hiroo@jp.fujitsu.com> wrote:
>> Hi, Kaneshige
>>
>>
>> You are right!
>> Setting dma_ops in pcibios_enable_device is a nice way.
>> In PCI driver, pci_enable_device_xxx that calls pcibios_enable_device is
>> called before checking archdata.dma_ops.
>>
>> I added code of checking and setting dma_ops to pcibios_enable_device in
>> arch/powerpc/kernel/pci-common.c.
>> It works good.
> 
> When I researched this, I thought the best route was to use the
> bus_register_notifier() path, as amd_iommu_init_notifier() does.
> 
> We're filling in a struct device field, not a PCI field, and
> bus_register_notifier() seems like a more generic path than relying on
> pcibios_enable_device().
> 
> Bjorn
> 
> 


  reply	other threads:[~2012-04-12 23:59 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     ` 松本博郎
2012-04-12  5:00       ` Hiroo Matsumoto
2012-04-12 13:12         ` Bjorn Helgaas
2012-04-12 23:59           ` Hiroo Matsumoto [this message]
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=4F876C54.5040408@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.