linux-kernel - Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3

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:	Fri, 30 Sep 2011 12:16:17 -0600 (MDT)
From:	Paul Walmsley <paul@...an.com>
To:	"Munegowda, Keshava" <keshava_mgowda@...com>
cc:	Benoit Cousson <b-cousson@...com>, parthab@...ia.ti.com,
	linux-usb@...r.kernel.org, linux-omap@...r.kernel.org,
	linux-kernel@...r.kernel.org, balbi@...com, gadiyar@...com,
	sameo@...ux.intel.com, tony@...mide.com, khilman@...com,
	johnstul@...ibm.com, vishwanath.bs@...com
Subject: Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures
 for omap3

On Fri, 30 Sep 2011, Munegowda, Keshava wrote:

> On Fri, Sep 30, 2011 at 2:02 PM, Paul Walmsley <paul@...an.com> wrote:
> > On Wed, 28 Sep 2011, Munegowda, Keshava wrote:
> >
> >> Thanks paul,
> >>
> >> But In USB Host case, there is a challenge!
> >>
> >> I need both usbhost_48m_fck and usbhost_120m_fck to be turned on when
> >> I invoke pm_runtime_get_sync ; so there are couple of options to do this
> >>
> >> 1. use clk_get with hard coded  usbhost_120m_fck name in  usbhs driver
> >>        enable this clock after invoking pm_runtime_get_sync
> >>
> >> 2. add an additional flag in hwmod ; so that pm_runtime_get_sync will enable
> >>            main clock as well as optional clocks
> >>
> >> please comment on these two approaches..
> >
> > Looks like you picked approach #1 which is fine with me.
> >
> > Here's what I don't understand about how this clock is used, though.
> > According to the 34xx TRM vZR Section 24.2.3.1.2 "High-Speed USB Host
> > Subsystem Clocks", this is only used to "clock EHCI controller internal
> > logic".  So if EHCI is not being used, it would seem to me that this clock
> > shouldn't be enabled?  But patch #5 seems to enable and disable it
> > unconditionally.  Am I missing something here?
> 
> OK. are you suggesting that this clock should be enabled/disabled; only
> if atleast one port is selected for ehci?

Seems to make sense to me?  If the clock really isn't needed for OHCI, 
then it shouldn't be enabled when only OHCI is in use?


- Paul