linux-kernel - Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

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: <alpine.DEB.2.00.1110101851570.5205@utopia.booyaka.com>
Date:	Mon, 10 Oct 2011 19:18:42 -0600 (MDT)
From:	Paul Walmsley <paul@...an.com>
To:	"Munegowda, Keshava" <keshava_mgowda@...com>
cc:	linux-usb@...r.kernel.org, linux-omap@...r.kernel.org,
	linux-kernel@...r.kernel.org, balbi@...com, khilman@...com,
	b-cousson@...com, gadiyar@...com, sameo@...ux.intel.com,
	parthab@...ia.ti.com, tony@...mide.com, johnstul@...ibm.com,
	vishwanath.bs@...com
Subject: Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures
 for omap4

Hi

On Mon, 10 Oct 2011, Paul Walmsley wrote:

> Basically, the existing OMAP USB subsystem MFD driver should create a TLL 
> device.  Then the existing Linux driver probing system can associate the 
> TLL driver with the TLL device.

This part isn't right.  After staring at the OMAP34xx TRM, it looks like 
the TLL modules have a separate interconnect port.  See for example the 
OMAP34xx TRM Rev. ZR Table 2-3 "L4-Core Memory Space Mapping".

So then the TLL device should be created by the code in 
arch/arm/mach-omap2/usb-host.c, as one of Keshava's patches does.  And 
indeed we have separate hwmods for the TLL IP blocks -- although both the 
OMAP3 and OMAP4 hwmod data that was posted are missing important fields.

So drivers/omap-usb-host.c shouldn't create a new TLL device.  You just 
need to pull all of the TLL code and data out of that MFD driver into a 
new TLL driver under drivers/usb somewhere.

Then you'll need some way for the EHCI/OHCI code to figure out which 
USBTLL device handles each port.  I'd suggest that, unless there is some 
explicit Linux USB core support for associating a TLL port with a host 
controller port, that the code in arch/arm/mach-omap2/usb-host.c register 
the USBTLL device first (the opposite of what it does now), then pass 
the pointer to the USBTLL's struct device via platform_data to 
drivers/mfd/omap-usb-host.c.  Then that can either be passed via 
platform_data to the EHCI/OHCI drivers, or the EHCI/OHCI drivers can call 
a drivers/mfd/omap-usb-host.c function to retrieve that struct device 
pointer.

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