On Thu, Feb 13, 2014 at 9:34 PM, Ben Dooks <ben.do...@codethink.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? Thanks, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
