All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: Liviu Dudau <Liviu.Dudau@arm.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	linaro-kernel <linaro-kernel@lists.linaro.org>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	linux-pci <linux-pci@vger.kernel.org>,
	Will Deacon <Will.Deacon@arm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Tanmay Inamdar <tinamdar@apm.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH v6 6/6] pci: Add support for creating a generic host_bridge from device tree
Date: Mon, 10 Mar 2014 16:21:01 +0100	[thread overview]
Message-ID: <2115856.ZTdgp5fkma@wuerfel> (raw)
In-Reply-To: <20140310144414.GT6457@e106497-lin.cambridge.arm.com>

On Monday 10 March 2014 14:44:14 Liviu Dudau wrote:
> I will try to improve the error handling in the next patchset version.
> However I am still confused about the earlier discussion on
> pci_register_io_range(). Your suggestion initially was to return an
> error in the default weak implementation, but in your last email you
> are talking about returning 'port'.

You can do either one: 'port' should be positive or zero, while the
error would always be negative. We do the same thing in many interfaces
in the kernel.

> My idea when I've introduced the
> helper function was that it would return an error if it fails to
> register the IO range and zero otherwise. I agree that we can treat
> the default 'do nothing with the IO range' case as an error, with
> the caveat that will force architectures that use this code to
> provide their own implementation of pci_register_io_range() in order
> to avoid failure, even for the cases where the architecture has a 1:1
> mapping between IO and CPU addresses.

Which architectures are you thinking of? The only one I know that
does this is ia64, and we won't ever have to support this helper
on that architecture.

I did not ask to treat 'do nothing with the IO range' as an error,
what I meant is that we should treat 'architecture cannot translate
from I/O space to memory space but DT lists a translation anyway'
as an error. On x86, you should never see an entry for the I/O space
in "ranges", so we will not call this function unless there is a
bug in DT.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 6/6] pci: Add support for creating a generic host_bridge from device tree
Date: Mon, 10 Mar 2014 16:21:01 +0100	[thread overview]
Message-ID: <2115856.ZTdgp5fkma@wuerfel> (raw)
In-Reply-To: <20140310144414.GT6457@e106497-lin.cambridge.arm.com>

On Monday 10 March 2014 14:44:14 Liviu Dudau wrote:
> I will try to improve the error handling in the next patchset version.
> However I am still confused about the earlier discussion on
> pci_register_io_range(). Your suggestion initially was to return an
> error in the default weak implementation, but in your last email you
> are talking about returning 'port'.

You can do either one: 'port' should be positive or zero, while the
error would always be negative. We do the same thing in many interfaces
in the kernel.

> My idea when I've introduced the
> helper function was that it would return an error if it fails to
> register the IO range and zero otherwise. I agree that we can treat
> the default 'do nothing with the IO range' case as an error, with
> the caveat that will force architectures that use this code to
> provide their own implementation of pci_register_io_range() in order
> to avoid failure, even for the cases where the architecture has a 1:1
> mapping between IO and CPU addresses.

Which architectures are you thinking of? The only one I know that
does this is ia64, and we won't ever have to support this helper
on that architecture.

I did not ask to treat 'do nothing with the IO range' as an error,
what I meant is that we should treat 'architecture cannot translate
from I/O space to memory space but DT lists a translation anyway'
as an error. On x86, you should never see an entry for the I/O space
in "ranges", so we will not call this function unless there is a
bug in DT.

	Arnd

  reply	other threads:[~2014-03-10 15:21 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-05 11:48 [PATCH v6 0/6] [RFC] Support for creating generic host_bridge from device tree Liviu Dudau
2014-03-05 11:48 ` Liviu Dudau
2014-03-05 11:48 ` [PATCH v6 1/6] pci: Introduce pci_register_io_range() helper function Liviu Dudau
2014-03-05 11:48   ` Liviu Dudau
2014-03-05 11:48   ` Liviu Dudau
2014-03-07 19:35   ` Grant Likely
2014-03-07 19:35     ` Grant Likely
2014-03-07 19:35     ` Grant Likely
2014-03-05 11:48 ` [PATCH v6 2/6] pci: OF: Fix the conversion of IO ranges into IO resources Liviu Dudau
2014-03-05 11:48   ` Liviu Dudau
2014-03-05 11:48   ` Liviu Dudau
2014-03-07 21:06   ` Grant Likely
2014-03-07 21:06     ` Grant Likely
2014-03-08 17:17   ` Arnd Bergmann
2014-03-08 17:17     ` Arnd Bergmann
2014-03-05 11:48 ` [PATCH v6 3/6] pci: Create pci_host_bridge before its associated bus in pci_create_root_bus Liviu Dudau
2014-03-05 11:48   ` Liviu Dudau
2014-03-07 21:07   ` Grant Likely
2014-03-07 21:07     ` Grant Likely
2014-03-05 11:48 ` [PATCH v6 4/6] pci: Introduce a domain number for pci_host_bridge Liviu Dudau
2014-03-05 11:48   ` Liviu Dudau
2014-03-07 21:09   ` Grant Likely
2014-03-07 21:09     ` Grant Likely
2014-03-05 11:48 ` [PATCH v6 5/6] pci: Export find_pci_host_bridge() function Liviu Dudau
2014-03-05 11:48   ` Liviu Dudau
2014-03-05 11:48 ` [PATCH v6 6/6] pci: Add support for creating a generic host_bridge from device tree Liviu Dudau
2014-03-05 11:48   ` Liviu Dudau
2014-03-07 21:14   ` Grant Likely
2014-03-07 21:14     ` Grant Likely
2014-03-08 10:29     ` Liviu Dudau
2014-03-08 10:29       ` Liviu Dudau
2014-03-08 10:29       ` Liviu Dudau
2014-03-08 17:15   ` Arnd Bergmann
2014-03-08 17:15     ` Arnd Bergmann
2014-03-10 14:44     ` Liviu Dudau
2014-03-10 14:44       ` Liviu Dudau
2014-03-10 15:21       ` Arnd Bergmann [this message]
2014-03-10 15:21         ` Arnd Bergmann
2014-03-10 16:33         ` Liviu Dudau
2014-03-10 16:33           ` Liviu Dudau
2014-03-10 18:59           ` Arnd Bergmann
2014-03-10 18:59             ` Arnd Bergmann
2014-03-10 19:16             ` Geert Uytterhoeven
2014-03-10 19:16               ` Geert Uytterhoeven
2014-03-10 19:28               ` Arnd Bergmann
2014-03-10 19:28                 ` Arnd Bergmann
2014-03-10 19:28                 ` Arnd Bergmann
2014-03-10 21:56             ` Liviu Dudau
2014-03-10 21:56               ` Liviu Dudau
2014-03-10 21:56               ` Liviu Dudau
2014-03-11  6:50               ` Arnd Bergmann
2014-03-11  6:50                 ` Arnd Bergmann
2014-03-11  6:50                 ` Arnd Bergmann
2014-03-11  9:46                 ` Liviu Dudau
2014-03-11  9:46                   ` Liviu Dudau
2014-03-11 10:43                   ` Arnd Bergmann
2014-03-11 10:43                     ` Arnd Bergmann

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=2115856.ZTdgp5fkma@wuerfel \
    --to=arnd@arndb.de \
    --cc=Catalin.Marinas@arm.com \
    --cc=Liviu.Dudau@arm.com \
    --cc=Will.Deacon@arm.com \
    --cc=benh@kernel.crashing.org \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=tinamdar@apm.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.