[PATCH] PCI: add missing DT binding for linux,pci-domain property

[PATCH] PCI: add missing DT binding for linux,pci-domain property

[Lucas Stach]

This property was added by 41e5c0f81d3e
(of/pci: Add pci_get_new_domain_nr() and of_get_pci_domain_nr())
without the required binding documentation. As this property
will be supported by a number of host bridge drivers going forward,
add it to the common PCI binding doc.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
This is a non-critical fix, but may still qualify for 3.18-rc as
the property was added in this release cycle.
---
 Documentation/devicetree/bindings/pci/pci.txt | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/pci.txt b/Documentation/devicetree/bindings/pci/pci.txt
index 41aeed38926d..b754f786ed5e 100644
--- a/Documentation/devicetree/bindings/pci/pci.txt
+++ b/Documentation/devicetree/bindings/pci/pci.txt
@@ -7,3 +7,13 @@ And for the interrupt mapping part:
 
 Open Firmware Recommended Practice: Interrupt Mapping
 http://www.openfirmware.org/1275/practice/imap/imap0_9d.pdf
+
+Additionally to the properties specified in the above standards a host bridge
+driver implementation may support the following properties:
+
+- linux,pci-domain:
+   If present this property assigns a fixed PCI domain number to a host bridge,
+   otherwise an unstable (across boots) unique number will be assigned.
+   It is recommended to either not set this property at all or set it for all
+   host bridges in the system, otherwise potentially conflicting domain numbers
+   may be assigned to root buses behind different host bridges.
-- 
2.1.1

Re: [PATCH] PCI: add missing DT binding for linux,pci-domain property

[Liviu Dudau]

On Tue, Nov 04, 2014 at 11:47:40AM +0000, Lucas Stach wrote:
> This property was added by 41e5c0f81d3e
> (of/pci: Add pci_get_new_domain_nr() and of_get_pci_domain_nr())
> without the required binding documentation. As this property
> will be supported by a number of host bridge drivers going forward,
> add it to the common PCI binding doc.
> 
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> This is a non-critical fix, but may still qualify for 3.18-rc as
> the property was added in this release cycle.

Hi Lucas,

Thanks for taking care of this, sorry it slipped through the cracks
of last minute changes in this area.

> ---
>  Documentation/devicetree/bindings/pci/pci.txt | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/pci.txt b/Documentation/devicetree/bindings/pci/pci.txt
> index 41aeed38926d..b754f786ed5e 100644
> --- a/Documentation/devicetree/bindings/pci/pci.txt
> +++ b/Documentation/devicetree/bindings/pci/pci.txt
> @@ -7,3 +7,13 @@ And for the interrupt mapping part:
>  
>  Open Firmware Recommended Practice: Interrupt Mapping
>  http://www.openfirmware.org/1275/practice/imap/imap0_9d.pdf
> +
> +Additionally to the properties specified in the above standards a host bridge
> +driver implementation may support the following properties:
> +
> +- linux,pci-domain:
> +   If present this property assigns a fixed PCI domain number to a host bridge,
> +   otherwise an unstable (across boots) unique number will be assigned.
> +   It is recommended to either not set this property at all or set it for all
> +   host bridges in the system, otherwise potentially conflicting domain numbers
> +   may be assigned to root buses behind different host bridges.
> -- 
> 2.1.1
> 

While the description is potentially correct, what it fails to explain is that the
choice of using the property or generating an unstable (across boots) unique
number is actually the choice of the host bridge driver at the moment. I know that
my earlier implementations were defaulting to the automatic numbering, but that has
been dropped from the final series as Rob Herring was objecting to it.

There is still scope to adopt a wide policy here, but for now it should say something
to the tune:

   If present this property assigns a fixed PCI domain number to a host bridge,
   otherwise an unstable (across boots) unique number will be assigned.
   If you decide to use the property to assign a fixed PCI domain number to a host
   bridge you have to ensure that all the host bridge drivers present in the system
   follow the same policy. Otherwise, potentially conflicting domain numbers
   may be assigned to root busses behind different host bridges.

Best regards,
Liviu
-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

Re: [PATCH] PCI: add missing DT binding for linux,pci-domain property

[Arnd Bergmann]

On Tuesday 04 November 2014 12:00:52 Liviu Dudau wrote:
> 
> While the description is potentially correct, what it fails to explain is that the
> choice of using the property or generating an unstable (across boots) unique
> number is actually the choice of the host bridge driver at the moment. I know that
> my earlier implementations were defaulting to the automatic numbering, but that has
> been dropped from the final series as Rob Herring was objecting to it.
> 
> There is still scope to adopt a wide policy here, but for now it should say something
> to the tune:
> 
>    If present this property assigns a fixed PCI domain number to a host bridge,
>    otherwise an unstable (across boots) unique number will be assigned.
>    If you decide to use the property to assign a fixed PCI domain number to a host
>    bridge you have to ensure that all the host bridge drivers present in the system
>    follow the same policy. Otherwise, potentially conflicting domain numbers
>    may be assigned to root busses behind different host bridges.

But with the latest change to the domain handling, all drivers would implement
this. I would just mention that Linux kernels older than 3.19 are probably
going to ignore this property.

	Arnd

Re: [PATCH] PCI: add missing DT binding for linux,pci-domain property

[Lucas Stach]

Am Dienstag, den 04.11.2014, 13:07 +0100 schrieb Arnd Bergmann:
> On Tuesday 04 November 2014 12:00:52 Liviu Dudau wrote:
> > 
> > While the description is potentially correct, what it fails to explain is that the
> > choice of using the property or generating an unstable (across boots) unique
> > number is actually the choice of the host bridge driver at the moment. I know that
> > my earlier implementations were defaulting to the automatic numbering, but that has
> > been dropped from the final series as Rob Herring was objecting to it.
> > 
> > There is still scope to adopt a wide policy here, but for now it should say something
> > to the tune:
> > 
> >    If present this property assigns a fixed PCI domain number to a host bridge,
> >    otherwise an unstable (across boots) unique number will be assigned.
> >    If you decide to use the property to assign a fixed PCI domain number to a host
> >    bridge you have to ensure that all the host bridge drivers present in the system
> >    follow the same policy. Otherwise, potentially conflicting domain numbers
> >    may be assigned to root busses behind different host bridges.
> 
> But with the latest change to the domain handling, all drivers would implement
> this. I would just mention that Linux kernels older than 3.19 are probably
> going to ignore this property.
> 
Right, this further complicates the semantics of this property, so I
would rather leave this out. Host bridge drivers using the generic PCI
domain code will work as documented and IMHO it's reasonable to enforce
this behavior for all new drivers.

Regards,
Lucas
-- 
Pengutronix e.K.             | Lucas Stach                 |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

Re: [PATCH] PCI: add missing DT binding for linux,pci-domain property

[Lucas Stach]

Am Dienstag, den 04.11.2014, 13:07 +0100 schrieb Arnd Bergmann:
> On Tuesday 04 November 2014 12:00:52 Liviu Dudau wrote:
> > 
> > While the description is potentially correct, what it fails to explain is that the
> > choice of using the property or generating an unstable (across boots) unique
> > number is actually the choice of the host bridge driver at the moment. I know that
> > my earlier implementations were defaulting to the automatic numbering, but that has
> > been dropped from the final series as Rob Herring was objecting to it.
> > 
> > There is still scope to adopt a wide policy here, but for now it should say something
> > to the tune:
> > 
> >    If present this property assigns a fixed PCI domain number to a host bridge,
> >    otherwise an unstable (across boots) unique number will be assigned.
> >    If you decide to use the property to assign a fixed PCI domain number to a host
> >    bridge you have to ensure that all the host bridge drivers present in the system
> >    follow the same policy. Otherwise, potentially conflicting domain numbers
> >    may be assigned to root busses behind different host bridges.
> 
> But with the latest change to the domain handling, all drivers would implement
> this. I would just mention that Linux kernels older than 3.19 are probably
> going to ignore this property.
> 
Hm, I don't think we should stick those things into the binding docs, as
those should not be Linux specific. IMHO the time when the parsing of a
property gets implemented is a implementation detail that has nothing to
do with the binding. Besides vendors always screw with this timeframes
by doing backports.

Regards,
Lucas

-- 
Pengutronix e.K.             | Lucas Stach                 |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PCI: add missing DT binding for linux,pci-domain property

[Arnd Bergmann]

On Thursday 06 November 2014 16:08:57 Lucas Stach wrote:
> Am Dienstag, den 04.11.2014, 13:07 +0100 schrieb Arnd Bergmann:
> > On Tuesday 04 November 2014 12:00:52 Liviu Dudau wrote:
> > > 
> > > While the description is potentially correct, what it fails to explain is that the
> > > choice of using the property or generating an unstable (across boots) unique
> > > number is actually the choice of the host bridge driver at the moment. I know that
> > > my earlier implementations were defaulting to the automatic numbering, but that has
> > > been dropped from the final series as Rob Herring was objecting to it.
> > > 
> > > There is still scope to adopt a wide policy here, but for now it should say something
> > > to the tune:
> > > 
> > >    If present this property assigns a fixed PCI domain number to a host bridge,
> > >    otherwise an unstable (across boots) unique number will be assigned.
> > >    If you decide to use the property to assign a fixed PCI domain number to a host
> > >    bridge you have to ensure that all the host bridge drivers present in the system
> > >    follow the same policy. Otherwise, potentially conflicting domain numbers
> > >    may be assigned to root busses behind different host bridges.
> > 
> > But with the latest change to the domain handling, all drivers would implement
> > this. I would just mention that Linux kernels older than 3.19 are probably
> > going to ignore this property.
> > 
> Hm, I don't think we should stick those things into the binding docs, as
> those should not be Linux specific. IMHO the time when the parsing of a
> property gets implemented is a implementation detail that has nothing to
> do with the binding. Besides vendors always screw with this timeframes
> by doing backports.

Well, unlike most properties, this one is explicitly Linux-specific,
at least that is what the name implies.

	Arnd

Re: [PATCH] PCI: add missing DT binding for linux,pci-domain property

[Kumar Gala]

On Nov 4, 2014, at 5:47 AM, Lucas Stach <l.stach@pengutronix.de> wrote:

> This property was added by 41e5c0f81d3e
> (of/pci: Add pci_get_new_domain_nr() and of_get_pci_domain_nr())
> without the required binding documentation. As this property
> will be supported by a number of host bridge drivers going forward,
> add it to the common PCI binding doc.
> 
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> This is a non-critical fix, but may still qualify for 3.18-rc as
> the property was added in this release cycle.
> ---
> Documentation/devicetree/bindings/pci/pci.txt | 10 ++++++++++
> 1 file changed, 10 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/pci.txt b/Documentation/devicetree/bindings/pci/pci.txt
> index 41aeed38926d..b754f786ed5e 100644
> --- a/Documentation/devicetree/bindings/pci/pci.txt
> +++ b/Documentation/devicetree/bindings/pci/pci.txt
> @@ -7,3 +7,13 @@ And for the interrupt mapping part:
> 
> Open Firmware Recommended Practice: Interrupt Mapping
> http://www.openfirmware.org/1275/practice/imap/imap0_9d.pdf
> +
> +Additionally to the properties specified in the above standards a host bridge
> +driver implementation may support the following properties:
> +
> +- linux,pci-domain:
> +   If present this property assigns a fixed PCI domain number to a host bridge,
> +   otherwise an unstable (across boots) unique number will be assigned.
> +   It is recommended to either not set this property at all or set it for all
> +   host bridges in the system, otherwise potentially conflicting domain numbers
> +   may be assigned to root buses behind different host bridges.

Probably should add something about domain numbers being unique across all host bridgse.

- k

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] PCI: add missing DT binding for linux,pci-domain property

[Bjorn Helgaas]

On Tue, Nov 04, 2014 at 12:47:40PM +0100, Lucas Stach wrote:
> This property was added by 41e5c0f81d3e
> (of/pci: Add pci_get_new_domain_nr() and of_get_pci_domain_nr())
> without the required binding documentation. As this property
> will be supported by a number of host bridge drivers going forward,
> add it to the common PCI binding doc.
> 
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>

I merged 41e5c0f81d3e through my tree, and I could merge something like
this if a consensus develops with some acks.  But I'll just let you guys
handle it unless you poke me again.

> ---
> This is a non-critical fix, but may still qualify for 3.18-rc as
> the property was added in this release cycle.
> ---
>  Documentation/devicetree/bindings/pci/pci.txt | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/pci.txt b/Documentation/devicetree/bindings/pci/pci.txt
> index 41aeed38926d..b754f786ed5e 100644
> --- a/Documentation/devicetree/bindings/pci/pci.txt
> +++ b/Documentation/devicetree/bindings/pci/pci.txt
> @@ -7,3 +7,13 @@ And for the interrupt mapping part:
>  
>  Open Firmware Recommended Practice: Interrupt Mapping
>  http://www.openfirmware.org/1275/practice/imap/imap0_9d.pdf
> +
> +Additionally to the properties specified in the above standards a host bridge
> +driver implementation may support the following properties:
> +
> +- linux,pci-domain:
> +   If present this property assigns a fixed PCI domain number to a host bridge,
> +   otherwise an unstable (across boots) unique number will be assigned.
> +   It is recommended to either not set this property at all or set it for all
> +   host bridges in the system, otherwise potentially conflicting domain numbers
> +   may be assigned to root buses behind different host bridges.
> -- 
> 2.1.1
> 

Re: [PATCH] PCI: add missing DT binding for linux,pci-domain property

[Liviu Dudau]

On Wed, Nov 05, 2014 at 11:17:43PM +0000, Bjorn Helgaas wrote:
> On Tue, Nov 04, 2014 at 12:47:40PM +0100, Lucas Stach wrote:
> > This property was added by 41e5c0f81d3e
> > (of/pci: Add pci_get_new_domain_nr() and of_get_pci_domain_nr())
> > without the required binding documentation. As this property
> > will be supported by a number of host bridge drivers going forward,
> > add it to the common PCI binding doc.
> > 
> > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> 
> I merged 41e5c0f81d3e through my tree, and I could merge something like
> this if a consensus develops with some acks.  But I'll just let you guys
> handle it unless you poke me again.

While I think the "linux,pci-domain" property *must* be documented, I
would like to get a consensus first on the usage. If we agree that
the property is mandatory to all host bridge drivers that use OF then
we need to patch existing drivers (partially done through Lorenzo's
patches, but other arches are ignoring it). If we say all *new* drivers
need to use it then we also need to come up with a strategy on how to
deal with old vs new school drivers.

My preferred approach is the 3rd way: "linux,pci-domain" becomes part of
the core PCI infrastructure (and we find the common ground with ACPI).
That way the host bridge drivers don't have to do anything, but the DT
creators have to specify a value.

Pinging Rob to try to get a peek on this thoughts.

Best regards,
Liviu

> 
> > ---
> > This is a non-critical fix, but may still qualify for 3.18-rc as
> > the property was added in this release cycle.
> > ---
> >  Documentation/devicetree/bindings/pci/pci.txt | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/pci/pci.txt b/Documentation/devicetree/bindings/pci/pci.txt
> > index 41aeed38926d..b754f786ed5e 100644
> > --- a/Documentation/devicetree/bindings/pci/pci.txt
> > +++ b/Documentation/devicetree/bindings/pci/pci.txt
> > @@ -7,3 +7,13 @@ And for the interrupt mapping part:
> >  
> >  Open Firmware Recommended Practice: Interrupt Mapping
> >  http://www.openfirmware.org/1275/practice/imap/imap0_9d.pdf
> > +
> > +Additionally to the properties specified in the above standards a host bridge
> > +driver implementation may support the following properties:
> > +
> > +- linux,pci-domain:
> > +   If present this property assigns a fixed PCI domain number to a host bridge,
> > +   otherwise an unstable (across boots) unique number will be assigned.
> > +   It is recommended to either not set this property at all or set it for all
> > +   host bridges in the system, otherwise potentially conflicting domain numbers
> > +   may be assigned to root buses behind different host bridges.
> > -- 
> > 2.1.1
> > 
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

Re: [PATCH] PCI: add missing DT binding for linux,pci-domain property

[Arnd Bergmann]

On Thursday 06 November 2014 10:05:18 Liviu Dudau wrote:
> On Wed, Nov 05, 2014 at 11:17:43PM +0000, Bjorn Helgaas wrote:
> > On Tue, Nov 04, 2014 at 12:47:40PM +0100, Lucas Stach wrote:
> > > This property was added by 41e5c0f81d3e
> > > (of/pci: Add pci_get_new_domain_nr() and of_get_pci_domain_nr())
> > > without the required binding documentation. As this property
> > > will be supported by a number of host bridge drivers going forward,
> > > add it to the common PCI binding doc.
> > > 
> > > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> > 
> > I merged 41e5c0f81d3e through my tree, and I could merge something like
> > this if a consensus develops with some acks.  But I'll just let you guys
> > handle it unless you poke me again.
> 
> While I think the "linux,pci-domain" property *must* be documented, I
> would like to get a consensus first on the usage. If we agree that
> the property is mandatory to all host bridge drivers that use OF then
> we need to patch existing drivers (partially done through Lorenzo's
> patches, but other arches are ignoring it). If we say all *new* drivers
> need to use it then we also need to come up with a strategy on how to
> deal with old vs new school drivers.
> 
> My preferred approach is the 3rd way: "linux,pci-domain" becomes part of
> the core PCI infrastructure (and we find the common ground with ACPI).
> That way the host bridge drivers don't have to do anything, but the DT
> creators have to specify a value.
> 
> Pinging Rob to try to get a peek on this thoughts.

Parsing "linux,pci-domain" from the PCI core code seems like the best
solution to me, but we still have to support dtbs that don't contain
it. Lorenzo's patch gets this right I think.

ACPI is easy here, because it already requires the domain to be
explicit.

	Arnd

Re: [PATCH] PCI: add missing DT binding for linux,pci-domain property

[Liviu Dudau]

On Thu, Nov 06, 2014 at 11:42:41AM +0000, Arnd Bergmann wrote:
> On Thursday 06 November 2014 10:05:18 Liviu Dudau wrote:
> > On Wed, Nov 05, 2014 at 11:17:43PM +0000, Bjorn Helgaas wrote:
> > > On Tue, Nov 04, 2014 at 12:47:40PM +0100, Lucas Stach wrote:
> > > > This property was added by 41e5c0f81d3e
> > > > (of/pci: Add pci_get_new_domain_nr() and of_get_pci_domain_nr())
> > > > without the required binding documentation. As this property
> > > > will be supported by a number of host bridge drivers going forward,
> > > > add it to the common PCI binding doc.
> > > > 
> > > > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> > > 
> > > I merged 41e5c0f81d3e through my tree, and I could merge something like
> > > this if a consensus develops with some acks.  But I'll just let you guys
> > > handle it unless you poke me again.
> > 
> > While I think the "linux,pci-domain" property *must* be documented, I
> > would like to get a consensus first on the usage. If we agree that
> > the property is mandatory to all host bridge drivers that use OF then
> > we need to patch existing drivers (partially done through Lorenzo's
> > patches, but other arches are ignoring it). If we say all *new* drivers
> > need to use it then we also need to come up with a strategy on how to
> > deal with old vs new school drivers.
> > 
> > My preferred approach is the 3rd way: "linux,pci-domain" becomes part of
> > the core PCI infrastructure (and we find the common ground with ACPI).
> > That way the host bridge drivers don't have to do anything, but the DT
> > creators have to specify a value.
> > 
> > Pinging Rob to try to get a peek on this thoughts.
> 
> Parsing "linux,pci-domain" from the PCI core code seems like the best
> solution to me, but we still have to support dtbs that don't contain
> it. Lorenzo's patch gets this right I think.

Agree. But we are not covering other architectures that use OF yet.

> 
> ACPI is easy here, because it already requires the domain to be
> explicit.

I was thinking more along the line of code sharing.

Best regards,
Liviu

> 
> 	Arnd
> 
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

Re: [PATCH] PCI: add missing DT binding for linux,pci-domain property

[Arnd Bergmann]

On Thursday 06 November 2014 12:36:42 Liviu Dudau wrote:
> > ACPI is easy here, because it already requires the domain to be
> > explicit.
> 
> I was thinking more along the line of code sharing.
> 

I don't think it's worth it here. In general, it's a good idea,
but the way that ACPI represents PCI is very different. In particular,
it doesn't support multiple kinds of host controllers, only ECAM
config space registers with no special setup code for other hardware
registers. The domain is part of the addressing mechanism for finding
the right ECAM register.

	Arnd

Re: [PATCH] PCI: add missing DT binding for linux,pci-domain property

[Rob Herring]

On Thu, Nov 6, 2014 at 4:05 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> On Wed, Nov 05, 2014 at 11:17:43PM +0000, Bjorn Helgaas wrote:
>> On Tue, Nov 04, 2014 at 12:47:40PM +0100, Lucas Stach wrote:
>> > This property was added by 41e5c0f81d3e
>> > (of/pci: Add pci_get_new_domain_nr() and of_get_pci_domain_nr())
>> > without the required binding documentation. As this property
>> > will be supported by a number of host bridge drivers going forward,
>> > add it to the common PCI binding doc.
>> >
>> > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
>>
>> I merged 41e5c0f81d3e through my tree, and I could merge something like
>> this if a consensus develops with some acks.  But I'll just let you guys
>> handle it unless you poke me again.
>
> While I think the "linux,pci-domain" property *must* be documented, I
> would like to get a consensus first on the usage. If we agree that
> the property is mandatory to all host bridge drivers that use OF then
> we need to patch existing drivers (partially done through Lorenzo's
> patches, but other arches are ignoring it). If we say all *new* drivers
> need to use it then we also need to come up with a strategy on how to
> deal with old vs new school drivers.
>
> My preferred approach is the 3rd way: "linux,pci-domain" becomes part of
> the core PCI infrastructure (and we find the common ground with ACPI).
> That way the host bridge drivers don't have to do anything, but the DT
> creators have to specify a value.

I'm okay with it being in the core. It was the mixture of using the
property and automatic numbering that I had issues with. Any mixture
whether in DT or in drivers should be an error. Also, I think having a
mixture of root bus host drivers would be rare, so I'm not too
concerned about some drivers supporting the property and others not.
In any case, these issues are all with the kernel and not really the
concern for the binding. For the binding, simply all hosts set the
domain or none of them do.

Rob

Re: [PATCH] PCI: add missing DT binding for linux,pci-domain property

[Liviu Dudau]

On Thu, Nov 06, 2014 at 02:57:35PM +0000, Rob Herring wrote:
> On Thu, Nov 6, 2014 at 4:05 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> > On Wed, Nov 05, 2014 at 11:17:43PM +0000, Bjorn Helgaas wrote:
> >> On Tue, Nov 04, 2014 at 12:47:40PM +0100, Lucas Stach wrote:
> >> > This property was added by 41e5c0f81d3e
> >> > (of/pci: Add pci_get_new_domain_nr() and of_get_pci_domain_nr())
> >> > without the required binding documentation. As this property
> >> > will be supported by a number of host bridge drivers going forward,
> >> > add it to the common PCI binding doc.
> >> >
> >> > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> >>
> >> I merged 41e5c0f81d3e through my tree, and I could merge something like
> >> this if a consensus develops with some acks.  But I'll just let you guys
> >> handle it unless you poke me again.
> >
> > While I think the "linux,pci-domain" property *must* be documented, I
> > would like to get a consensus first on the usage. If we agree that
> > the property is mandatory to all host bridge drivers that use OF then
> > we need to patch existing drivers (partially done through Lorenzo's
> > patches, but other arches are ignoring it). If we say all *new* drivers
> > need to use it then we also need to come up with a strategy on how to
> > deal with old vs new school drivers.
> >
> > My preferred approach is the 3rd way: "linux,pci-domain" becomes part of
> > the core PCI infrastructure (and we find the common ground with ACPI).
> > That way the host bridge drivers don't have to do anything, but the DT
> > creators have to specify a value.
> 
> I'm okay with it being in the core. It was the mixture of using the
> property and automatic numbering that I had issues with. Any mixture
> whether in DT or in drivers should be an error. Also, I think having a
> mixture of root bus host drivers would be rare, so I'm not too
> concerned about some drivers supporting the property and others not.
> In any case, these issues are all with the kernel and not really the
> concern for the binding. For the binding, simply all hosts set the
> domain or none of them do.

Repeating what you've said to verify my understanding: you are OK with
the "linux,pci-domain" being handled in the PCI framework and mandatory
to all OF-based host bridges and architectures. Failure to include
the property should be an error and no host bridge driver should default
to the auto-generation of domain numbers.

Is that correct?

Thanks,
Liviu

> 
> Rob
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

Re: [PATCH] PCI: add missing DT binding for linux,pci-domain property

[Rob Herring]

On Thu, Nov 6, 2014 at 9:30 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> On Thu, Nov 06, 2014 at 02:57:35PM +0000, Rob Herring wrote:
>> On Thu, Nov 6, 2014 at 4:05 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
>> > On Wed, Nov 05, 2014 at 11:17:43PM +0000, Bjorn Helgaas wrote:
>> >> On Tue, Nov 04, 2014 at 12:47:40PM +0100, Lucas Stach wrote:
>> >> > This property was added by 41e5c0f81d3e
>> >> > (of/pci: Add pci_get_new_domain_nr() and of_get_pci_domain_nr())
>> >> > without the required binding documentation. As this property
>> >> > will be supported by a number of host bridge drivers going forward,
>> >> > add it to the common PCI binding doc.
>> >> >
>> >> > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
>> >>
>> >> I merged 41e5c0f81d3e through my tree, and I could merge something like
>> >> this if a consensus develops with some acks.  But I'll just let you guys
>> >> handle it unless you poke me again.
>> >
>> > While I think the "linux,pci-domain" property *must* be documented, I
>> > would like to get a consensus first on the usage. If we agree that
>> > the property is mandatory to all host bridge drivers that use OF then
>> > we need to patch existing drivers (partially done through Lorenzo's
>> > patches, but other arches are ignoring it). If we say all *new* drivers
>> > need to use it then we also need to come up with a strategy on how to
>> > deal with old vs new school drivers.
>> >
>> > My preferred approach is the 3rd way: "linux,pci-domain" becomes part of
>> > the core PCI infrastructure (and we find the common ground with ACPI).
>> > That way the host bridge drivers don't have to do anything, but the DT
>> > creators have to specify a value.
>>
>> I'm okay with it being in the core. It was the mixture of using the
>> property and automatic numbering that I had issues with. Any mixture
>> whether in DT or in drivers should be an error. Also, I think having a
>> mixture of root bus host drivers would be rare, so I'm not too
>> concerned about some drivers supporting the property and others not.
>> In any case, these issues are all with the kernel and not really the
>> concern for the binding. For the binding, simply all hosts set the
>> domain or none of them do.
>
> Repeating what you've said to verify my understanding: you are OK with
> the "linux,pci-domain" being handled in the PCI framework and mandatory
> to all OF-based host bridges and architectures. Failure to include
> the property should be an error and no host bridge driver should default
> to the auto-generation of domain numbers.
>
> Is that correct?

Not exactly. It is only mandatory when you have multiple root buses.
But we can't say an existing dtb is in error, so it has to remain
optional for compatibility. Also, given it is a Linux property, you
can't really say it is mandatory for all PCI bindings from a DT
perspective.

While we could have issues in theory if this is handled in the
drivers, I don't think we will in practice as having root buses with
different drivers is unlikely.

Rob

Re: [PATCH] PCI: add missing DT binding for linux,pci-domain property

[Liviu Dudau]

On Thu, Nov 06, 2014 at 07:46:33PM +0000, Rob Herring wrote:
> On Thu, Nov 6, 2014 at 9:30 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> > On Thu, Nov 06, 2014 at 02:57:35PM +0000, Rob Herring wrote:
> >> On Thu, Nov 6, 2014 at 4:05 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> >> > On Wed, Nov 05, 2014 at 11:17:43PM +0000, Bjorn Helgaas wrote:
> >> >> On Tue, Nov 04, 2014 at 12:47:40PM +0100, Lucas Stach wrote:
> >> >> > This property was added by 41e5c0f81d3e
> >> >> > (of/pci: Add pci_get_new_domain_nr() and of_get_pci_domain_nr())
> >> >> > without the required binding documentation. As this property
> >> >> > will be supported by a number of host bridge drivers going forward,
> >> >> > add it to the common PCI binding doc.
> >> >> >
> >> >> > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> >> >>
> >> >> I merged 41e5c0f81d3e through my tree, and I could merge something like
> >> >> this if a consensus develops with some acks.  But I'll just let you guys
> >> >> handle it unless you poke me again.
> >> >
> >> > While I think the "linux,pci-domain" property *must* be documented, I
> >> > would like to get a consensus first on the usage. If we agree that
> >> > the property is mandatory to all host bridge drivers that use OF then
> >> > we need to patch existing drivers (partially done through Lorenzo's
> >> > patches, but other arches are ignoring it). If we say all *new* drivers
> >> > need to use it then we also need to come up with a strategy on how to
> >> > deal with old vs new school drivers.
> >> >
> >> > My preferred approach is the 3rd way: "linux,pci-domain" becomes part of
> >> > the core PCI infrastructure (and we find the common ground with ACPI).
> >> > That way the host bridge drivers don't have to do anything, but the DT
> >> > creators have to specify a value.
> >>
> >> I'm okay with it being in the core. It was the mixture of using the
> >> property and automatic numbering that I had issues with. Any mixture
> >> whether in DT or in drivers should be an error. Also, I think having a
> >> mixture of root bus host drivers would be rare, so I'm not too
> >> concerned about some drivers supporting the property and others not.
> >> In any case, these issues are all with the kernel and not really the
> >> concern for the binding. For the binding, simply all hosts set the
> >> domain or none of them do.
> >
> > Repeating what you've said to verify my understanding: you are OK with
> > the "linux,pci-domain" being handled in the PCI framework and mandatory
> > to all OF-based host bridges and architectures. Failure to include
> > the property should be an error and no host bridge driver should default
> > to the auto-generation of domain numbers.
> >
> > Is that correct?
> 
> Not exactly. It is only mandatory when you have multiple root buses.
> But we can't say an existing dtb is in error, so it has to remain
> optional for compatibility. Also, given it is a Linux property, you
> can't really say it is mandatory for all PCI bindings from a DT
> perspective.
> 
> While we could have issues in theory if this is handled in the
> drivers, I don't think we will in practice as having root buses with
> different drivers is unlikely.

That's correct. However, I would like to bring to you attention that as
long as the property is treated as optional in certain cases we will need,
in the framework code, to mix the assignment of a domain number coming from
parsing of the property with the auto-numbering scheme in order to support
old DT files. And that was one of your major concerns when reviewing the
series. Any suggestions or clarifications?

Best regards,
Liviu

> 
> Rob
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

Re: [PATCH] PCI: add missing DT binding for linux,pci-domain property

[Rob Herring]

On Fri, Nov 7, 2014 at 4:17 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> On Thu, Nov 06, 2014 at 07:46:33PM +0000, Rob Herring wrote:
>> On Thu, Nov 6, 2014 at 9:30 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
>> > On Thu, Nov 06, 2014 at 02:57:35PM +0000, Rob Herring wrote:
>> >> On Thu, Nov 6, 2014 at 4:05 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
>> >> > On Wed, Nov 05, 2014 at 11:17:43PM +0000, Bjorn Helgaas wrote:
>> >> >> On Tue, Nov 04, 2014 at 12:47:40PM +0100, Lucas Stach wrote:
>> >> >> > This property was added by 41e5c0f81d3e
>> >> >> > (of/pci: Add pci_get_new_domain_nr() and of_get_pci_domain_nr())
>> >> >> > without the required binding documentation. As this property
>> >> >> > will be supported by a number of host bridge drivers going forward,
>> >> >> > add it to the common PCI binding doc.
>> >> >> >
>> >> >> > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
>> >> >>
>> >> >> I merged 41e5c0f81d3e through my tree, and I could merge something like
>> >> >> this if a consensus develops with some acks.  But I'll just let you guys
>> >> >> handle it unless you poke me again.
>> >> >
>> >> > While I think the "linux,pci-domain" property *must* be documented, I
>> >> > would like to get a consensus first on the usage. If we agree that
>> >> > the property is mandatory to all host bridge drivers that use OF then
>> >> > we need to patch existing drivers (partially done through Lorenzo's
>> >> > patches, but other arches are ignoring it). If we say all *new* drivers
>> >> > need to use it then we also need to come up with a strategy on how to
>> >> > deal with old vs new school drivers.
>> >> >
>> >> > My preferred approach is the 3rd way: "linux,pci-domain" becomes part of
>> >> > the core PCI infrastructure (and we find the common ground with ACPI).
>> >> > That way the host bridge drivers don't have to do anything, but the DT
>> >> > creators have to specify a value.
>> >>
>> >> I'm okay with it being in the core. It was the mixture of using the
>> >> property and automatic numbering that I had issues with. Any mixture
>> >> whether in DT or in drivers should be an error. Also, I think having a
>> >> mixture of root bus host drivers would be rare, so I'm not too
>> >> concerned about some drivers supporting the property and others not.
>> >> In any case, these issues are all with the kernel and not really the
>> >> concern for the binding. For the binding, simply all hosts set the
>> >> domain or none of them do.
>> >
>> > Repeating what you've said to verify my understanding: you are OK with
>> > the "linux,pci-domain" being handled in the PCI framework and mandatory
>> > to all OF-based host bridges and architectures. Failure to include
>> > the property should be an error and no host bridge driver should default
>> > to the auto-generation of domain numbers.
>> >
>> > Is that correct?
>>
>> Not exactly. It is only mandatory when you have multiple root buses.
>> But we can't say an existing dtb is in error, so it has to remain
>> optional for compatibility. Also, given it is a Linux property, you
>> can't really say it is mandatory for all PCI bindings from a DT
>> perspective.
>>
>> While we could have issues in theory if this is handled in the
>> drivers, I don't think we will in practice as having root buses with
>> different drivers is unlikely.
>
> That's correct. However, I would like to bring to you attention that as
> long as the property is treated as optional in certain cases we will need,
> in the framework code, to mix the assignment of a domain number coming from
> parsing of the property with the auto-numbering scheme in order to support
> old DT files. And that was one of your major concerns when reviewing the
> series. Any suggestions or clarifications?

We have to support both allocation schemes, but not on the same
system. A mixture on a given system is an error. So the cases to
handle are like this:

1 root bus w/ domain -> use domain prop
1 root bus w/o domain -> auto numbering
N root buses w/ domains -> use domain prop
N root buses w/o domains -> auto numbering
N root buses w/ and w/o domains -> error

I also had issues just around the implementation details, but we can
discuss those when there is another version.

Rob

Re: [PATCH] PCI: add missing DT binding for linux,pci-domain property

[Liviu Dudau]

On Fri, Nov 07, 2014 at 02:00:56PM +0000, Rob Herring wrote:
> On Fri, Nov 7, 2014 at 4:17 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> > On Thu, Nov 06, 2014 at 07:46:33PM +0000, Rob Herring wrote:
> >> On Thu, Nov 6, 2014 at 9:30 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> >> > On Thu, Nov 06, 2014 at 02:57:35PM +0000, Rob Herring wrote:
> >> >> On Thu, Nov 6, 2014 at 4:05 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> >> >> > On Wed, Nov 05, 2014 at 11:17:43PM +0000, Bjorn Helgaas wrote:
> >> >> >> On Tue, Nov 04, 2014 at 12:47:40PM +0100, Lucas Stach wrote:
> >> >> >> > This property was added by 41e5c0f81d3e
> >> >> >> > (of/pci: Add pci_get_new_domain_nr() and of_get_pci_domain_nr())
> >> >> >> > without the required binding documentation. As this property
> >> >> >> > will be supported by a number of host bridge drivers going forward,
> >> >> >> > add it to the common PCI binding doc.
> >> >> >> >
> >> >> >> > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> >> >> >>
> >> >> >> I merged 41e5c0f81d3e through my tree, and I could merge something like
> >> >> >> this if a consensus develops with some acks.  But I'll just let you guys
> >> >> >> handle it unless you poke me again.
> >> >> >
> >> >> > While I think the "linux,pci-domain" property *must* be documented, I
> >> >> > would like to get a consensus first on the usage. If we agree that
> >> >> > the property is mandatory to all host bridge drivers that use OF then
> >> >> > we need to patch existing drivers (partially done through Lorenzo's
> >> >> > patches, but other arches are ignoring it). If we say all *new* drivers
> >> >> > need to use it then we also need to come up with a strategy on how to
> >> >> > deal with old vs new school drivers.
> >> >> >
> >> >> > My preferred approach is the 3rd way: "linux,pci-domain" becomes part of
> >> >> > the core PCI infrastructure (and we find the common ground with ACPI).
> >> >> > That way the host bridge drivers don't have to do anything, but the DT
> >> >> > creators have to specify a value.
> >> >>
> >> >> I'm okay with it being in the core. It was the mixture of using the
> >> >> property and automatic numbering that I had issues with. Any mixture
> >> >> whether in DT or in drivers should be an error. Also, I think having a
> >> >> mixture of root bus host drivers would be rare, so I'm not too
> >> >> concerned about some drivers supporting the property and others not.
> >> >> In any case, these issues are all with the kernel and not really the
> >> >> concern for the binding. For the binding, simply all hosts set the
> >> >> domain or none of them do.
> >> >
> >> > Repeating what you've said to verify my understanding: you are OK with
> >> > the "linux,pci-domain" being handled in the PCI framework and mandatory
> >> > to all OF-based host bridges and architectures. Failure to include
> >> > the property should be an error and no host bridge driver should default
> >> > to the auto-generation of domain numbers.
> >> >
> >> > Is that correct?
> >>
> >> Not exactly. It is only mandatory when you have multiple root buses.
> >> But we can't say an existing dtb is in error, so it has to remain
> >> optional for compatibility. Also, given it is a Linux property, you
> >> can't really say it is mandatory for all PCI bindings from a DT
> >> perspective.
> >>
> >> While we could have issues in theory if this is handled in the
> >> drivers, I don't think we will in practice as having root buses with
> >> different drivers is unlikely.
> >
> > That's correct. However, I would like to bring to you attention that as
> > long as the property is treated as optional in certain cases we will need,
> > in the framework code, to mix the assignment of a domain number coming from
> > parsing of the property with the auto-numbering scheme in order to support
> > old DT files. And that was one of your major concerns when reviewing the
> > series. Any suggestions or clarifications?
> 
> We have to support both allocation schemes, but not on the same
> system. A mixture on a given system is an error. So the cases to
> handle are like this:
> 
> 1 root bus w/ domain -> use domain prop
> 1 root bus w/o domain -> auto numbering
> N root buses w/ domains -> use domain prop
> N root buses w/o domains -> auto numbering
> N root buses w/ and w/o domains -> error

Agree.

> 
> I also had issues just around the implementation details, but we can
> discuss those when there is another version.

Well, there is a version already in arch/arm64/kernel/pci.c:
pci_bus_assign_domain_nr() and I believe it works on all the cases
listed above. Question is if you agree on making this the default
implementation for OF-based architectures. Lorenzo has already
copied it into arch/arm.

Best regards,
Liviu

> 
> Rob
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

Re: [PATCH] PCI: add missing DT binding for linux,pci-domain property

[Rob Herring]

On Fri, Nov 7, 2014 at 9:23 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> On Fri, Nov 07, 2014 at 02:00:56PM +0000, Rob Herring wrote:
>> On Fri, Nov 7, 2014 at 4:17 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
>> > On Thu, Nov 06, 2014 at 07:46:33PM +0000, Rob Herring wrote:
>> >> On Thu, Nov 6, 2014 at 9:30 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
>> >> > On Thu, Nov 06, 2014 at 02:57:35PM +0000, Rob Herring wrote:
>> >> >> On Thu, Nov 6, 2014 at 4:05 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
>> >> >> > On Wed, Nov 05, 2014 at 11:17:43PM +0000, Bjorn Helgaas wrote:
>> >> >> >> On Tue, Nov 04, 2014 at 12:47:40PM +0100, Lucas Stach wrote:
>> >> >> >> > This property was added by 41e5c0f81d3e
>> >> >> >> > (of/pci: Add pci_get_new_domain_nr() and of_get_pci_domain_nr())
>> >> >> >> > without the required binding documentation. As this property
>> >> >> >> > will be supported by a number of host bridge drivers going forward,
>> >> >> >> > add it to the common PCI binding doc.
>> >> >> >> >
>> >> >> >> > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
>> >> >> >>
>> >> >> >> I merged 41e5c0f81d3e through my tree, and I could merge something like
>> >> >> >> this if a consensus develops with some acks.  But I'll just let you guys
>> >> >> >> handle it unless you poke me again.
>> >> >> >
>> >> >> > While I think the "linux,pci-domain" property *must* be documented, I
>> >> >> > would like to get a consensus first on the usage. If we agree that
>> >> >> > the property is mandatory to all host bridge drivers that use OF then
>> >> >> > we need to patch existing drivers (partially done through Lorenzo's
>> >> >> > patches, but other arches are ignoring it). If we say all *new* drivers
>> >> >> > need to use it then we also need to come up with a strategy on how to
>> >> >> > deal with old vs new school drivers.
>> >> >> >
>> >> >> > My preferred approach is the 3rd way: "linux,pci-domain" becomes part of
>> >> >> > the core PCI infrastructure (and we find the common ground with ACPI).
>> >> >> > That way the host bridge drivers don't have to do anything, but the DT
>> >> >> > creators have to specify a value.
>> >> >>
>> >> >> I'm okay with it being in the core. It was the mixture of using the
>> >> >> property and automatic numbering that I had issues with. Any mixture
>> >> >> whether in DT or in drivers should be an error. Also, I think having a
>> >> >> mixture of root bus host drivers would be rare, so I'm not too
>> >> >> concerned about some drivers supporting the property and others not.
>> >> >> In any case, these issues are all with the kernel and not really the
>> >> >> concern for the binding. For the binding, simply all hosts set the
>> >> >> domain or none of them do.
>> >> >
>> >> > Repeating what you've said to verify my understanding: you are OK with
>> >> > the "linux,pci-domain" being handled in the PCI framework and mandatory
>> >> > to all OF-based host bridges and architectures. Failure to include
>> >> > the property should be an error and no host bridge driver should default
>> >> > to the auto-generation of domain numbers.
>> >> >
>> >> > Is that correct?
>> >>
>> >> Not exactly. It is only mandatory when you have multiple root buses.
>> >> But we can't say an existing dtb is in error, so it has to remain
>> >> optional for compatibility. Also, given it is a Linux property, you
>> >> can't really say it is mandatory for all PCI bindings from a DT
>> >> perspective.
>> >>
>> >> While we could have issues in theory if this is handled in the
>> >> drivers, I don't think we will in practice as having root buses with
>> >> different drivers is unlikely.
>> >
>> > That's correct. However, I would like to bring to you attention that as
>> > long as the property is treated as optional in certain cases we will need,
>> > in the framework code, to mix the assignment of a domain number coming from
>> > parsing of the property with the auto-numbering scheme in order to support
>> > old DT files. And that was one of your major concerns when reviewing the
>> > series. Any suggestions or clarifications?
>>
>> We have to support both allocation schemes, but not on the same
>> system. A mixture on a given system is an error. So the cases to
>> handle are like this:
>>
>> 1 root bus w/ domain -> use domain prop
>> 1 root bus w/o domain -> auto numbering
>> N root buses w/ domains -> use domain prop
>> N root buses w/o domains -> auto numbering
>> N root buses w/ and w/o domains -> error
>
> Agree.
>
>>
>> I also had issues just around the implementation details, but we can
>> discuss those when there is another version.
>
> Well, there is a version already in arch/arm64/kernel/pci.c:
> pci_bus_assign_domain_nr() and I believe it works on all the cases
> listed above. Question is if you agree on making this the default
> implementation for OF-based architectures. Lorenzo has already
> copied it into arch/arm.

I agree it is correct implementation for correct DTs, but it doesn't
handle some error cases. I'll comment on Lorenzo's ARM version about
specifics.

Rob