All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 1/2] ARM: shmobile: r8a7790: add internal PCI bridge nodes
Date: Mon, 23 Jun 2014 20:40:36 +0000	[thread overview]
Message-ID: <20140623204036.GA12793@obsidianresearch.com> (raw)
In-Reply-To: <53A4A6C6.9000703@cogentembedded.com>


> >>     Hm, are you sure about that? I thought only PCI devices should have it...
> 
> >Yes, pretty sure it's needed in both the host controller and the
> >devices.
> 
>     I don't understand the case of the PCI devices, honestly.
> Shouldn't the "device_type" prop reflect the device's functionality
> rather than the bus where it's located?

It is confusingly named, but it is required on the host bridge OF node.

The spec says ' .. corresponding to a device that implements a PCI bus',
which includes the host bridge.

The key element is that it must be present on the node that introduces
the PCI 3 dword address encoding scheme, and then on all nodes below
it that use the 3 dword scheme.

Otherwise Linux common OF PCI code does not work properly.

Jason

WARNING: multiple messages have this Message-ID (diff)
From: jgunthorpe@obsidianresearch.com (Jason Gunthorpe)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 1/2] ARM: shmobile: r8a7790: add internal PCI bridge nodes
Date: Mon, 23 Jun 2014 14:40:36 -0600	[thread overview]
Message-ID: <20140623204036.GA12793@obsidianresearch.com> (raw)
In-Reply-To: <53A4A6C6.9000703@cogentembedded.com>


> >>     Hm, are you sure about that? I thought only PCI devices should have it...
> 
> >Yes, pretty sure it's needed in both the host controller and the
> >devices.
> 
>     I don't understand the case of the PCI devices, honestly.
> Shouldn't the "device_type" prop reflect the device's functionality
> rather than the bus where it's located?

It is confusingly named, but it is required on the host bridge OF node.

The spec says ' .. corresponding to a device that implements a PCI bus',
which includes the host bridge.

The key element is that it must be present on the node that introduces
the PCI 3 dword address encoding scheme, and then on all nodes below
it that use the 3 dword scheme.

Otherwise Linux common OF PCI code does not work properly.

Jason

WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
	mark.rutland@arm.com, devicetree@vger.kernel.org,
	linux@arm.linux.org.uk, pawel.moll@arm.com,
	ijc+devicetree@hellion.org.uk, linux-sh@vger.kernel.org,
	magnus.damm@gmail.com, robh+dt@kernel.org, horms@verge.net.au,
	galak@codeaurora.org, ben.dooks@codethink.co.uk,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 1/2] ARM: shmobile: r8a7790: add internal PCI bridge nodes
Date: Mon, 23 Jun 2014 14:40:36 -0600	[thread overview]
Message-ID: <20140623204036.GA12793@obsidianresearch.com> (raw)
In-Reply-To: <53A4A6C6.9000703@cogentembedded.com>


> >>     Hm, are you sure about that? I thought only PCI devices should have it...
> 
> >Yes, pretty sure it's needed in both the host controller and the
> >devices.
> 
>     I don't understand the case of the PCI devices, honestly.
> Shouldn't the "device_type" prop reflect the device's functionality
> rather than the bus where it's located?

It is confusingly named, but it is required on the host bridge OF node.

The spec says ' .. corresponding to a device that implements a PCI bus',
which includes the host bridge.

The key element is that it must be present on the node that introduces
the PCI 3 dword address encoding scheme, and then on all nodes below
it that use the 3 dword scheme.

Otherwise Linux common OF PCI code does not work properly.

Jason

  parent reply	other threads:[~2014-06-23 20:40 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-20 20:34 [PATCH v4 0/2] Add R8A7790/Lager board PCI USB DT support Sergei Shtylyov
2014-06-20 20:34 ` Sergei Shtylyov
2014-06-20 20:34 ` Sergei Shtylyov
2014-06-20 20:36 ` [PATCH v4 1/2] ARM: shmobile: r8a7790: add internal PCI bridge nodes Sergei Shtylyov
2014-06-20 20:36   ` Sergei Shtylyov
2014-06-20 20:36   ` Sergei Shtylyov
2014-06-20 20:51   ` Arnd Bergmann
2014-06-20 20:51     ` Arnd Bergmann
2014-06-20 20:51     ` Arnd Bergmann
2014-06-20 21:00     ` Sergei Shtylyov
2014-06-20 21:00       ` Sergei Shtylyov
2014-06-20 21:00       ` Sergei Shtylyov
2014-06-20 21:10       ` Arnd Bergmann
2014-06-20 21:10         ` Arnd Bergmann
2014-06-20 21:10         ` Arnd Bergmann
2014-06-20 21:25         ` Sergei Shtylyov
2014-06-20 21:25           ` Sergei Shtylyov
2014-06-20 21:25           ` Sergei Shtylyov
2014-06-21  9:15           ` Arnd Bergmann
2014-06-21  9:15             ` Arnd Bergmann
2014-06-21  9:15             ` Arnd Bergmann
2014-06-23 20:40           ` Jason Gunthorpe [this message]
2014-06-23 20:40             ` Jason Gunthorpe
2014-06-23 20:40             ` Jason Gunthorpe
2014-06-20 21:16       ` Sergei Shtylyov
2014-06-20 21:16         ` Sergei Shtylyov
2014-06-20 21:16         ` Sergei Shtylyov
2014-06-20 20:38 ` [PATCH v4 2/2] ARM: shmobile: lager: enable internal PCI Sergei Shtylyov
2014-06-20 20:38   ` Sergei Shtylyov
2014-06-20 20:38   ` Sergei Shtylyov

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=20140623204036.GA12793@obsidianresearch.com \
    --to=jgunthorpe@obsidianresearch.com \
    --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 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.