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]

Date:	Mon, 10 Oct 2011 12:26:15 +0300
From:	Felipe Balbi <balbi@...com>
To:	"Munegowda, Keshava" <keshava_mgowda@...com>
Cc:	balbi@...com, Paul Walmsley <paul@...an.com>,
	linux-usb@...r.kernel.org, linux-omap@...r.kernel.org,
	linux-kernel@...r.kernel.org, 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

On Mon, Oct 10, 2011 at 02:47:42PM +0530, Munegowda, Keshava wrote:
> On Mon, Oct 10, 2011 at 2:33 PM, Felipe Balbi <balbi@...com> wrote:
> > Hi,
> >
> > On Mon, Oct 10, 2011 at 02:22:23PM +0530, Munegowda, Keshava wrote:
> >> Hi paul and Felipe
> >>
> >> Here is the highlights of the change in the design of  USB Host which
> >> we can do after kernel 3.2 release;
> >>
> >> 1. separate the TLL changes  from UHH
> >> 2. The TLL is be a new platform driver in ./drivers/mfd
> >> 3. the TLL platform driver will export apis  for enable/disable clocks
> >> and settings.
> >
> > TLL should control its clocks through pm_runtime APIs like anything
> > else. If you really must export APIs to be used by UHH, you need to have
> > an API so that you can claim/release a TLL channel and get/put for
> > increasing/decreasing PM counters.
> >
> > I still think though, you should try to avoid exporting OMAP-specific
> > APIs all over the place. Ideally, we would be able to have some way of
> > saying that UHH and TLL are closely related... something like having the
> > ability to say e.g. two devices are sibblings of each other, so that we
> > could ask for a sibbling to wakeup/sleep depending if we need it or not.
> 
> do we have sibling structures today? I dont think so.

no we don't.

> > Dunno, maybe I'm drifting here, but I don't think exposing OMAP-specific
> > APIs is wise.
> 
> so, it means , if we can have sibling structure, then we can
> conditionally enable it right?

the conditional would still lie in UHH driver, but at least it would be
made into a generic API. I mean, you could create a generic way of
defining sibbling devices, and a generic way to make them talk to each
other.

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)