devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
	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
Subject: Re: [PATCH v4 1/2] ARM: shmobile: r8a7790: add internal PCI bridge nodes
Date: Sat, 21 Jun 2014 11:15:39 +0200	[thread overview]
Message-ID: <4805472.0q1PyyoD4W@wuerfel> (raw)
In-Reply-To: <53A4A6C6.9000703@cogentembedded.com>

On Saturday 21 June 2014 01:25:26 Sergei Shtylyov wrote:
> On 06/21/2014 01:10 AM, Arnd Bergmann wrote:

> >>> It also needs a device_type property.
> 
> >>      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 probably made more sense on real Open Firmware than it does on FDT, but
we're trying to follow the bindings anyway.

I believe the "device_type=pci" originally indicated a device that has
a readable config space (through the OF client interface), which is true
for both the host and the devices.

> >>> I realize that the driver doesn't currently use them, but you should
> >>> adhere to the binding anyway, so we can fix the driver at some point.
> 
> >>      Sigh, agreed about the need to fix the driver. Too bad you've spoken up
> >> only now though. And you've ACKed the DT bindings without those properties
> >> documented or even present in an example...
> 
> > Yes, I realized that too late as well, sorry about it. For some reason
> > I only looked at the interrupt-map being done right and forgot to
> > check the ranges.
> 
> > We definitely need to move the code handling the ranges into a common
> > location to avoid this mistake in the future.
> 
>     It is already in the common location, AFAIK; what's lacking there is the 
> code that parses "dma-ranges" as well but that should be pretty easy to add...

We have some common helpers for "ranges" parsing already, but we should
improve them so a driver has to do much less in the future.

For "dma-ranges", we still to write need most of the code. For platform
devices, we can now calculate the offset for the simple (no IOMMU) case,
but we still need to calculate the dma mask correctly (that part should
be simple, maybe you can help there as you have an immediate need),
and we need to handle the IOMMU and swiotlb cases better.

For PCI devices, we need to do all the same things we do for platform
devices, and we can probably share most of the code.

	Arnd

  reply	other threads:[~2014-06-21  9:15 UTC|newest]

Thread overview: 10+ 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:36 ` [PATCH v4 1/2] ARM: shmobile: r8a7790: add internal PCI bridge nodes Sergei Shtylyov
2014-06-20 20:51   ` Arnd Bergmann
2014-06-20 21:00     ` Sergei Shtylyov
2014-06-20 21:10       ` Arnd Bergmann
2014-06-20 21:25         ` Sergei Shtylyov
2014-06-21  9:15           ` Arnd Bergmann [this message]
2014-06-23 20:40           ` Jason Gunthorpe
2014-06-20 21:16       ` Sergei Shtylyov
2014-06-20 20:38 ` [PATCH v4 2/2] ARM: shmobile: lager: enable internal PCI 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=4805472.0q1PyyoD4W@wuerfel \
    --to=arnd@arndb.de \
    --cc=ben.dooks@codethink.co.uk \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=horms@verge.net.au \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=magnus.damm@gmail.com \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=sergei.shtylyov@cogentembedded.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 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).