Re: [PATCH 12/16] tile/PCI: Factor 'pcibios_setup()' out of tile

From: Chris Metcalf
Date: Thu Jun 28 2012 - 13:44:22 EST


On 6/28/2012 1:30 PM, Myron Stowe wrote:
> On Tue, 2012-06-26 at 09:18 -0400, Chris Metcalf wrote:
>> On 6/25/2012 11:32 PM, Myron Stowe wrote:
>>> The PCI core provides a generic (__weak) 'pcibios_setup()' routine
>>> that can be used by all architectures as a default. Drop tile's
>>> architecture specific version in favor of that as it does not need to be
>>> over-ridden.
>>>
>>> Signed-off-by: Myron Stowe <myron.stowe@xxxxxxxxxx>
>>> ---
>>>
>>> arch/tile/kernel/pci.c | 10 ----------
>>> 1 files changed, 0 insertions(+), 10 deletions(-)
>> [...]
>> In our internal tree we have x86-like support for "pci=off" here. [...]
>> But perhaps it would make sense
>> to move the support for "pci=off" to common code, since multiple
>> architectures handle this the same way?
> Looking at the tree I only see three of the architectures currently
> using/implementing "pci=off" (four with the 'tile' addition). Perhaps
> there is a way to avoid such but it seems like adding this to the core
> would require introducing the global variable 'pci_probe' which seems
> like unnecessary pollution?

I'd argue that the core might expose a pci_probing_disabled() function that
returns whether "pci=off" was seen, and modify the other architectures that
already support pci_probe to call that function instead. It's true that
x86 has a much more elaborate use of pci_probe than the other
architectures, which means x86 would probably want to keep the variable
as-is and just call pci_probing_disabled() to set pci_probe to zero and return.

All that said, I'm not volunteering to make this change, so if it doesn't
seem right to you, I certainly won't insist. :-)

--
Chris Metcalf, Tilera Corp.
http://www.tilera.com



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