[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52FDF564.1070904@codethink.co.uk>
Date: Fri, 14 Feb 2014 10:52:20 +0000
From: Ben Dooks <ben.dooks@...ethink.co.uk>
To: Magnus Damm <magnus.damm@...il.com>
CC: linux-pci@...r.kernel.org,
"Simon Horman [Horms]" <horms@...ge.net.au>,
SH-Linux <linux-sh@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Valentine Barshak <valentine.barshak@...entembedded.com>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Bjorn Helgaas <bhelgaas@...gle.com>
Subject: Re: [PATCH 00/08] PCI: rcar: Recent driver patches from Ben Dooks
and me
On 14/02/14 05:40, Magnus Damm wrote:
> On Thu, Feb 13, 2014 at 9:34 PM, Ben Dooks <ben.dooks@...ethink.co.uk> wrote:
>> On 13/02/14 03:03, Magnus Damm wrote:
>>>
>>> PCI: rcar: Recent driver patches from Ben Dooks and me
>>>
>>> [PATCH 01/08] PCI: rcar: check platform_get_irq() return code
>>> [PATCH v2 02/08] PCI: rcar: add error interrupt handling
>>> [PATCH 03/08] PCI: rcar: fix bridge logic configuration accesses
>>> [PATCH v2 04/08] PCI: rcar: Register each instance independently
>>> [PATCH v2 05/08] PCI: rcar: Break out window size handling
>>> [PATCH v2 06/08] PCI: rcar: Add DMABOUNCE support
>>> [PATCH 07/08] PCI: rcar: Enable BOUNCE in case of HIGHMEM
>>> [PATCH 08/08] PCI: rcar: Make the Kconfig dependencies more generic
>>>
>>> These patches update the pci-rcar-gen2.c driver with patches from
>>> Ben Dooks and me. The first 3 are written by Ben (thanks!) and are
>>> included here to show what I would like to have merged and what I
>>> rebased my patches on. The following 4 are updated versions of
>>>
>>> [PATCH 00/04] PCI: rcar: Driver model and physical address space update
>>>
>>> The final patch is a new one that fixes up the Kconfig dependencies.
>>
>>
>> Thanks. Is there any chance of getting this driver device-tree
>> enabled too?
>
> I think so! The DT bindings proposed by you looked good for this device.
>
> The only question is how to handle the PHY hardware in a sane way. The
> PHY is the central problematic point so to say, since it ties these
> PCI USB2.0 devices together with USBHS and for some SoCs USB 3.0 as
> well.
>
> I'm thinking of something along these lines:
>
> 1) To use DT to describe the full hardware topology
> 2) Enable all or some device drivers in the kernel configuration
> 3) Have a sane default but use the bind interface to reassign
> driver-to-port configuration.
>
> What is your intended use case?
I think we can describe this all from the PHY node or links to
the PHY node. I was going to look at sorting out the bindings
next week, due to this week being mostly consumed by chasing
bugs.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists