linux-kernel - Re: [PATCH v6 07/12] usb: chipidea: add a usb2 driver for ci13xxx

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2990737.4KzKXPZhaB@wuerfel>
Date:	Wed, 24 Sep 2014 09:44:19 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Peter Chen <peter.chen@...escale.com>
Cc:	balbi@...com, Antoine Tenart <antoine.tenart@...e-electrons.com>,
	linux-arm-kernel@...ts.infradead.org,
	sebastian.hesselbarth@...il.com, p.zabel@...gutronix.de,
	thomas.petazzoni@...e-electrons.com, zmxu@...vell.com,
	devicetree@...r.kernel.org, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org, alexandre.belloni@...e-electrons.com,
	jszhang@...vell.com
Subject: Re: [PATCH v6 07/12] usb: chipidea: add a usb2 driver for ci13xxx

On Wednesday 24 September 2014 10:27:52 Peter Chen wrote:
> 
> Antoine is adding a generic chipdea glue layer driver, which like ehci generic
> platform driver: drivers/usb/host/ehci-platform.c, since other architectures
> like MIPS (Someone submitted mips chipidea driver before) may not have device
> tree support, I think non-dt support is also needed.

Right.

> It is a good suggestion for adding DT support for core driver, Since we did
> not do it at the first, it is a little embarrass at current situation.
> 
> - For the new chipidea glue drivers, it is ok we can have a child node
> for core device at glue device node, and some common entries can be there
> like: phy, vbus, dr_mode, etc. We need to add support for getting
> these common things for both through device tree and platform data
> (parent is DT support and parent is non-DT support) at core driver.

I don't really want to see the child devices show up in DT, as this is
really an implementation detail of the way that the driver currently works,
and IMHO we should change that.

I know that Felipe disagrees with me on this, but almost every other
driver that has soc-specific specializations does not use parent/child
nodes, neither in DT nor in Linux. Instead you have a single device
node that gets distinguished by "compatible" string.

> - For the existing glue drivers, since we can't change existed dts, we can
> only do it from future SoC support. Then, in this kinds of glue drivers,
> we need to support for both create core driver by node and by current
> calling platform_device_add way.

We should be able to easily change the ci_hdrc_add_device call into
a different exported function that calls a version of the probe()
code directly, as we do in all sorts of other drivers (ehci, ohci,
dwc2, ..., but not dwc3 and musb as they are maintained by Felipe).

We can also gradually move in some of the other glue drivers into
the main driver if the differences are small enough.

Moving the PCI driver over to this model requires a little more
work but is absolutely doable (again, see ehci, ahci, sdhci examples)
by moving the platform_device handling out of core.c and changing
it just operate on the plain 'struct device', with an exported
probe function that gets called on either the platform device
or the pci device.

	Arnd
--
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/