linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 1/7] pci: Introduce pci_register_io_range() helper function.
Date: Fri, 7 Mar 2014 01:24:12 +0100	[thread overview]
Message-ID: <201403070124.13139.arnd@arndb.de> (raw)
In-Reply-To: <20140306160442.GG6457@e106497-lin.cambridge.arm.com>

On Thursday 06 March 2014, Liviu Dudau wrote:
> On Tue, Mar 04, 2014 at 10:30:09PM +0000, Arnd Bergmann wrote:
> > On Tuesday 04 March 2014, Liviu Dudau wrote:
> > > +int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
> > > +{
> > > +       return 0;
> > > +}
> > > +
> > 
> > How about returning an error here? You don't actually register the range.
> 
> That's not the intention here. I basically want a nop, as by default (read x86)
> we do nothing with the IO range.

I think x86 is a bad default though, because that is the exception rather than
the rule. I also think that on x86, you shouldn't have an entry for the I/O
space in the "ranges" property since there is no translation, and then we don't
call this function.

PCI devices described in DT on x86 would still be able to list their I/O BARs
in DT, but you don't ever translate them into MMIO ranges.

	Arnd

  reply	other threads:[~2014-03-07  0:24 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-04 15:49 [PATCH v5 0/7] [RFC] Support for creating generic host_bridge from device tree Liviu Dudau
2014-03-04 15:49 ` [PATCH v5 1/7] pci: Introduce pci_register_io_range() helper function Liviu Dudau
2014-03-04 22:30   ` Arnd Bergmann
2014-03-06 16:04     ` Liviu Dudau
2014-03-07  0:24       ` Arnd Bergmann [this message]
2014-03-07  0:58         ` Liviu Dudau
2014-03-10 14:45         ` Liviu Dudau
2014-03-10 15:57           ` Arnd Bergmann
2014-03-04 15:49 ` [PATCH v5 2/7] pci: OF: Fix the conversion of IO ranges into IO resources Liviu Dudau
2014-03-04 15:50 ` [PATCH v5 3/7] pci: Create pci_host_bridge before its associated bus in pci_create_root_bus Liviu Dudau
2014-03-05  3:48   ` Yijing Wang
2014-03-05  4:41     ` Jingoo Han
2014-03-05  8:19       ` Liviu Dudau
2014-03-04 15:50 ` [PATCH v5 4/7] pci: Introduce a domain number for pci_host_bridge Liviu Dudau
2014-03-04 15:50 ` [PATCH v5 5/7] pci: Use parent domain number when allocating child busses Liviu Dudau
2014-03-05  1:49   ` Tanmay Inamdar
2014-03-05  8:16     ` Liviu Dudau
2014-03-04 15:50 ` [PATCH v5 6/7] pci: Export find_pci_host_bridge() function Liviu Dudau
2014-03-04 15:50 ` [PATCH v5 7/7] pci: Add support for creating a generic host_bridge from device tree Liviu Dudau
2014-03-05  1:20   ` Jingoo Han
2014-03-05  8:33     ` Liviu Dudau
2014-03-05  8:58       ` Jingoo Han
2014-03-05  1:53 ` [PATCH v5 0/7] [RFC] Support for creating " Tanmay Inamdar
2014-03-05  8:18   ` Liviu Dudau
2014-03-05 17:51     ` Tanmay Inamdar
2014-03-05 11:40   ` Liviu Dudau
2014-03-05 17:49     ` Tanmay Inamdar

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=201403070124.13139.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).