Re: [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 12, 2015 at 11:34 AM, Lorenzo Pieralisi
<lorenzo.pieralisi@xxxxxxx> wrote:
> On Tue, May 12, 2015 at 02:34:31PM +0100, Bjorn Helgaas wrote:
>
> [...]
>
>> > +void pci_claim_one_bus(struct pci_bus *b)
>> > +{
>> > +   struct pci_dev *pdev;
>> > +   struct pci_bus *child_bus;
>> > +
>> > +   list_for_each_entry(pdev, &b->devices, bus_list) {
>> > +           int i;
>> > +
>> > +           for (i = 0; i < PCI_NUM_RESOURCES; i++) {
>> > +                   struct resource *r = &pdev->resource[i];
>> > +
>> > +                   if (r->parent || !r->start || !r->flags)
>> > +                           continue;
>> > +
>> > +                   if (pci_has_flag(PCI_PROBE_ONLY) ||
>> > +                       (r->flags & IORESOURCE_PCI_FIXED)) {
>> > +                           if (pci_claim_resource(pdev, i) == 0)
>> > +                                   continue;
>> > +
>> > +                           pci_claim_bridge_resource(pdev, i);
>> > +                   }
>> > +           }
>> > +   }
>> > +
>> > +   list_for_each_entry(child_bus, &b->children, node) {
>> > +           pci_claim_one_bus(child_bus);
>> > +   }
>> > +}
>> > +EXPORT_SYMBOL(pci_claim_one_bus);
>>
>> I'm not a fan of pci_claim_one_bus(), on the philosophical grounds that
>> claiming resources is a per-device thing, and I don't want to encourage
>> people to do it on a per-bus level.
>>
>> I'd rather claim them somewhere in the pci_device_add() path, as s390 does
>> in pcibios_add_device().  In fact, I'd *like* to do it even earlier, when
>> we read each BAR, so we could identify invalid or unassigned BARs
>> immediately.
>
> You mean claiming the resources in __pci_read_base (and unset the resource
> if claiming it fails ?) regardless of PCI_PROBE_ONLY ?

That's what I'm thinking, but only in the long term.  I doubt we're
ready to go that far yet.  I was thinking more along the lines of just
getting it uniformly into the core first, maybe even incrementally,
and only after that moving it around inside the core.

I don't think it would work right now because I think we read device
BARs before we read the apertures of the upstream bridge.

> We could claim the resources in pcibios_add_device on arm64, but this
> means arm code should be patched too since I am not happy at all to let
> arm and arm64 diverge even more.

I agree, it'd be nice to have arm and arm64 be similar, but from my
point of view, they wouldn't have to be changed at the same time.  To
me, they just look like two different arches.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux