linux-kernel - Re: [PATCH 2/2] ARM: pci: Allow passing per-controller private data

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAErSpo591Ybuf95nU-O38=PrqtuJHWkWcce+5Owbc8YAprAUBw@mail.gmail.com>
Date:	Tue, 18 Sep 2012 12:38:53 -0600
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Thierry Reding <thierry.reding@...onic-design.de>
Cc:	Russell King <linux@....linux.org.uk>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] ARM: pci: Allow passing per-controller private data

On Tue, Sep 18, 2012 at 12:34 PM, Thierry Reding
<thierry.reding@...onic-design.de> wrote:
> On Tue, Sep 18, 2012 at 11:21:21AM -0600, Bjorn Helgaas wrote:
>> On Fri, Sep 14, 2012 at 3:11 PM, Thierry Reding
>> <thierry.reding@...onic-design.de> wrote:
>> > In order to allow drivers to specify private data for each controller,
>> > this commit adds a private_data field to the struct hw_pci. This field
>> > is an array of nr_controllers pointers that will be used to initialize
>> > the private_data field of the corresponding controller's pci_sys_data
>> > structure.
>>
>> I guess you aren't changing the design here because struct hw_pci
>> already includes "nr_controllers," but having nr_controllers and a
>> private_data[] array sounds like something that might make it hard to
>> hot-add a host bridge after boot.
>
> What I do in the Tegra PCIe driver is to pass each of the root ports to
> pci_common_init() individually because they can be enabled or disabled
> by device tree data. I suppose to some degree you can consider that hot-
> adding. Not that Tegra is likely to ever need to support that. I don't
> know how likely it is for any ARM platform to ever need support for hot-
> adding a host bridge.
>
> Eventually I think it would be advantageous for this to be generalized
> further such that PCI initialization can be shared across architectures.
> That's probably not an easy task so I was going to start by making
> incremental changes that enable the Tegra code to work and, if time
> allows, help further with subsequent improvements.
>
> It also seems that parts of the PCI core aren't ready yet for hot-adding
> host bridges. One thing I came across while working on the Tegra code is
> that MSI setup and teardown needs to be done by the arch_setup_msi_irq()
> and arch_teardown_msi_irq() respectively, which are expected to be
> builtin. That was also the last issue that keeps the Tegra PCIe driver
> from being built as a module. I think that will also make it impossible
> to hot-add host bridges. On x86 this seems to be handled by platform
> code, but on Tegra for example MSI setup and teardown is tightly coupled
> to the PCIe controller. That was one of the things I thought I could
> take a look at eventually, but getting Tegra support cleaned up is
> higher priority right now.

The PCI core doesn't support hot-add of host bridges yet, but there's
a lot of work in that area right now, which is why it's on my mind :)
I'm not suggesting you change anything here; just keep it in the back
of your mind for the future.  Thanks for the arch_setup_msi_irq() tip;
I'll look into that.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/