All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <bhelgaas@google.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arm-kernel@lists.infradead.org,
	Rob Herring <robherring2@gmail.com>,
	devicetree@vger.kernel.org,
	Peter Maydell <peter.maydell@linaro.org>,
	Russell King <linux@arm.linux.org.uk>,
	Rob Herring <robh@kernel.org>,
	linux-pci@vger.kernel.org,
	Linus Walleij <linus.walleij@linaro.org>,
	arm@kernel.org
Subject: Re: [PATCH 4/9] pci: add DT based ARM Versatile PCI host driver
Date: Fri, 23 Jan 2015 19:01:27 -0600	[thread overview]
Message-ID: <20150124010127.GA29776@google.com> (raw)
In-Reply-To: <2308474.mrIrUSfiTv@wuerfel>

On Tue, Dec 30, 2014 at 10:58:00PM +0100, Arnd Bergmann wrote:
> On Tuesday 30 December 2014 13:28:33 Rob Herring wrote:
> > +	list_for_each_entry(win, res, list) {
> > +		struct resource *parent, *res = win->res;
> > +
> > +		switch (resource_type(res)) {
> > +		case IORESOURCE_IO:
> > +			parent = &ioport_resource;
> > +			err = pci_remap_iospace(res, iobase);
> > +			if (err) {
> > +				dev_warn(dev, "error %d: failed to map resource %pR\n",
> > +					 err, res);
> > +				continue;
> > +			}
> > +			break;
> > +		case IORESOURCE_MEM:
> > +			parent = &iomem_resource;
> > +			res_valid |= !(res->flags & IORESOURCE_PREFETCH);
> > +
> > +			writel(res->start >> 28, PCI_IMAP(mem));
> > +			writel(PHYS_OFFSET >> 28, PCI_SMAP(mem));
> > +			mem++;
> > +
> > +			break;
> > +		case IORESOURCE_BUS:
> > +		default:
> > +			continue;
> > +		}
> > +
> > +		err = devm_request_resource(dev, parent, res);
> > +		if (err)
> > +			goto out_release_res;
> > +	}
> 
> I wonder if we should also request the physical resource for the I/O space
> window to have it show up in /proc/iomem. We are rather inconsistent in this
> regard between drivers.

I'd like that.  We are inconsistent, but I think it's useful to have this
information in /proc/iomem.  After all, it is physical address space that
we can't use for anything else, so I guess you could argue that it's
actually a bug to omit it.

> > +	pci_add_flags(PCI_ENABLE_PROC_DOMAINS);
> > +	pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
> > +
> > +	bus = pci_scan_root_bus(&pdev->dev, 0, &pci_versatile_ops, &sys, &pci_res);
> > +	if (!bus)
> > +		return -ENOMEM;
> > +
> > +	pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
> > +	pci_assign_unassigned_bus_resources(bus);
> > +
> > +	return 0;
> 
> One general question, mainly for Bjorn: pci_scan_root_bus adds all the devices
> at the Linux driver level by calling pci_bus_add_devices(), but then we call
> pci_fixup_irqs and pci_assign_unassigned_bus_resources after that, which will
> change the devices again. Is this how it's meant to work? How do we ensure
> that we have the correct irq number and resources by the time we enter the
> probe() function of the PCI device driver that gets bound to a device here?

Nope, that isn't how it's meant to work.  After pci_bus_add_devices()
completes, drivers can be already bound to the device, and the PCI core
should keep its mitts off things the driver could be using.  But I think
we've had this problem for a long time, and I haven't looked at it recently
to see how hard it would be to fix.

Bjorn

WARNING: multiple messages have this Message-ID (diff)
From: bhelgaas@google.com (Bjorn Helgaas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/9] pci: add DT based ARM Versatile PCI host driver
Date: Fri, 23 Jan 2015 19:01:27 -0600	[thread overview]
Message-ID: <20150124010127.GA29776@google.com> (raw)
In-Reply-To: <2308474.mrIrUSfiTv@wuerfel>

On Tue, Dec 30, 2014 at 10:58:00PM +0100, Arnd Bergmann wrote:
> On Tuesday 30 December 2014 13:28:33 Rob Herring wrote:
> > +	list_for_each_entry(win, res, list) {
> > +		struct resource *parent, *res = win->res;
> > +
> > +		switch (resource_type(res)) {
> > +		case IORESOURCE_IO:
> > +			parent = &ioport_resource;
> > +			err = pci_remap_iospace(res, iobase);
> > +			if (err) {
> > +				dev_warn(dev, "error %d: failed to map resource %pR\n",
> > +					 err, res);
> > +				continue;
> > +			}
> > +			break;
> > +		case IORESOURCE_MEM:
> > +			parent = &iomem_resource;
> > +			res_valid |= !(res->flags & IORESOURCE_PREFETCH);
> > +
> > +			writel(res->start >> 28, PCI_IMAP(mem));
> > +			writel(PHYS_OFFSET >> 28, PCI_SMAP(mem));
> > +			mem++;
> > +
> > +			break;
> > +		case IORESOURCE_BUS:
> > +		default:
> > +			continue;
> > +		}
> > +
> > +		err = devm_request_resource(dev, parent, res);
> > +		if (err)
> > +			goto out_release_res;
> > +	}
> 
> I wonder if we should also request the physical resource for the I/O space
> window to have it show up in /proc/iomem. We are rather inconsistent in this
> regard between drivers.

I'd like that.  We are inconsistent, but I think it's useful to have this
information in /proc/iomem.  After all, it is physical address space that
we can't use for anything else, so I guess you could argue that it's
actually a bug to omit it.

> > +	pci_add_flags(PCI_ENABLE_PROC_DOMAINS);
> > +	pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
> > +
> > +	bus = pci_scan_root_bus(&pdev->dev, 0, &pci_versatile_ops, &sys, &pci_res);
> > +	if (!bus)
> > +		return -ENOMEM;
> > +
> > +	pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
> > +	pci_assign_unassigned_bus_resources(bus);
> > +
> > +	return 0;
> 
> One general question, mainly for Bjorn: pci_scan_root_bus adds all the devices
> at the Linux driver level by calling pci_bus_add_devices(), but then we call
> pci_fixup_irqs and pci_assign_unassigned_bus_resources after that, which will
> change the devices again. Is this how it's meant to work? How do we ensure
> that we have the correct irq number and resources by the time we enter the
> probe() function of the PCI device driver that gets bound to a device here?

Nope, that isn't how it's meant to work.  After pci_bus_add_devices()
completes, drivers can be already bound to the device, and the PCI core
should keep its mitts off things the driver could be using.  But I think
we've had this problem for a long time, and I haven't looked at it recently
to see how hard it would be to fix.

Bjorn

  parent reply	other threads:[~2015-01-24  1:01 UTC|newest]

Thread overview: 86+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-30 19:28 [PATCH 0/9] ARM Versatile multi-platform support Rob Herring
2014-12-30 19:28 ` Rob Herring
2014-12-30 19:28 ` [PATCH 1/9] dt/bindings: add versatile PCI binding Rob Herring
2014-12-30 19:28   ` Rob Herring
2014-12-30 19:28 ` [PATCH 2/9] dts: versatile: add PCI controller binding Rob Herring
2014-12-30 19:28   ` Rob Herring
2014-12-30 19:28 ` [PATCH 3/9] ARM: versatile: add DT based PCI detection Rob Herring
2014-12-30 19:28   ` Rob Herring
2014-12-30 21:37   ` Arnd Bergmann
2014-12-30 21:37     ` Arnd Bergmann
2014-12-30 23:05     ` Rob Herring
2014-12-30 23:05       ` Rob Herring
2014-12-31 15:23       ` Arnd Bergmann
2014-12-31 15:23         ` Arnd Bergmann
2014-12-31 16:13         ` Peter Maydell
2014-12-31 16:13           ` Peter Maydell
2014-12-31 19:22           ` Rob Herring
2014-12-31 19:22             ` Rob Herring
2014-12-31 21:07             ` Peter Maydell
2014-12-31 21:07               ` Peter Maydell
2015-01-01 15:35               ` Arnd Bergmann
2015-01-01 15:35                 ` Arnd Bergmann
2015-01-01 15:52                 ` Peter Maydell
2015-01-01 15:52                   ` Peter Maydell
2015-01-08 19:37   ` Linus Walleij
2015-01-08 19:37     ` Linus Walleij
2015-01-08 21:34     ` Rob Herring
2015-01-08 21:34       ` Rob Herring
2014-12-30 19:28 ` [PATCH 4/9] pci: add DT based ARM Versatile PCI host driver Rob Herring
2014-12-30 19:28   ` Rob Herring
2014-12-30 21:58   ` Arnd Bergmann
2014-12-30 21:58     ` Arnd Bergmann
2015-01-02 18:14     ` Rob Herring
2015-01-02 18:14       ` Rob Herring
2015-01-02 20:52       ` Arnd Bergmann
2015-01-02 20:52         ` Arnd Bergmann
2015-01-02 23:13         ` Rob Herring
2015-01-02 23:13           ` Rob Herring
2015-01-05  9:35           ` Arnd Bergmann
2015-01-05  9:35             ` Arnd Bergmann
2015-01-24  1:01     ` Bjorn Helgaas [this message]
2015-01-24  1:01       ` Bjorn Helgaas
2015-01-24  0:54   ` Bjorn Helgaas
2015-01-24  0:54     ` Bjorn Helgaas
2014-12-30 19:28 ` [PATCH 5/9] dts: versatile: add sysregs nodes Rob Herring
2014-12-30 19:28   ` Rob Herring
2015-01-08 19:44   ` Linus Walleij
2015-01-08 19:44     ` Linus Walleij
2015-01-08 23:53     ` Rob Herring
2015-01-08 23:53       ` Rob Herring
2015-01-09  7:10       ` Linus Walleij
2015-01-09  7:10         ` Linus Walleij
2015-01-09 11:53         ` Lorenzo Pieralisi
2015-01-09 11:53           ` Lorenzo Pieralisi
2015-01-15 16:06       ` Lorenzo Pieralisi
2015-01-15 16:06         ` Lorenzo Pieralisi
2015-01-19 10:25         ` Linus Walleij
2015-01-19 10:25           ` Linus Walleij
2014-12-30 19:28 ` [PATCH 6/9] ARM: versatile: switch to DT only booting and remove legacy code Rob Herring
2014-12-30 19:28   ` Rob Herring
2014-12-30 19:28 ` [PATCH 7/9] ARM: versatile: move mach includes into mach directory Rob Herring
2014-12-30 19:28   ` Rob Herring
2014-12-30 22:05   ` Arnd Bergmann
2014-12-30 22:05     ` Arnd Bergmann
2014-12-30 19:28 ` [PATCH 8/9] ARM: versatile: convert to multi-platform Rob Herring
2014-12-30 19:28   ` Rob Herring
2014-12-30 19:28 ` [PATCH 9/9] ARM: versatile: consolidate code to single file Rob Herring
2014-12-30 19:28   ` Rob Herring
2014-12-30 22:08 ` [PATCH 0/9] ARM Versatile multi-platform support Arnd Bergmann
2014-12-30 22:08   ` Arnd Bergmann
2014-12-31  9:25 ` Peter Maydell
2014-12-31  9:25   ` Peter Maydell
2015-01-05  9:50   ` Marc Zyngier
2015-01-05  9:50     ` Marc Zyngier
2015-01-05 10:08     ` Peter Maydell
2015-01-05 10:08       ` Peter Maydell
2015-01-05 11:19       ` Marc Zyngier
2015-01-05 11:19         ` Marc Zyngier
2015-01-05 17:41         ` Peter Maydell
2015-01-05 17:41           ` Peter Maydell
2015-01-08 19:47 ` Linus Walleij
2015-01-08 19:47   ` Linus Walleij
2015-01-08 21:38   ` Rob Herring
2015-01-08 21:38     ` Rob Herring
     [not found]     ` <CAL_JsqKLNPVDCUELaZU8JW0roT3RcyqcxtJbvbYQrjzxjt3FeQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-01-09  8:34       ` Linus Walleij
2015-01-09  8:34         ` Linus Walleij

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=20150124010127.GA29776@google.com \
    --to=bhelgaas@google.com \
    --cc=arm@kernel.org \
    --cc=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=peter.maydell@linaro.org \
    --cc=robh@kernel.org \
    --cc=robherring2@gmail.com \
    /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.