linux-kernel - Re: [PATCH 8/8] phy: add driver for TI TUSB1210 ULPI PHY

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: <20150211131255.GA10985@kuha.fi.intel.com>
Date:	Wed, 11 Feb 2015 15:12:55 +0200
From:	Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:	David Cohen <david.a.cohen@...ux.intel.com>
Cc:	Felipe Balbi <balbi@...com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Baolu Lu <baolu.lu@...ux.intel.com>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Kishon Vijay Abraham I <kishon@...com>
Subject: Re: [PATCH 8/8] phy: add driver for TI TUSB1210 ULPI PHY

Hi David,

> > > > In order for phy to be functional, it does not depend only on toggling
> > > > GPIOs. It depends on DWC3 going to reset state, then phy executes power
> > > > on sequence, then DWC3 going out of reset state to sync clocks with phy.
> > > > You're saying we should tell BIOS is concurrently mess with dwc3
> > > > together with dwc3 driver?
> > > 
> > > I don't understand what you are saying here?
> > 
> > TUSB1210 needs to come out of reset only when DWC3 is in reset state.
> > This is how current code works in dwc3_core_soft_reset():
> > - dwc3 goes to reset
> > - phy goes to reset
> > - phy gets out of reset
> > - dwc3 gets out of reset
> > 
> > This is how you're proposing:
> > - phy goes to reset (DSDT code, when loading module)
> > - phy gets out of reset (DSDT code, when loading module)
> > 
> > - dwc3 goes to reset (dwc3_core_soft_reset())
> > - dwc3 gets our of reset (dwc3_core_soft_reset())
> > 
> > Felipe, do you see a problem with this new context? If not, I'm
> > satisfied with Heikki's ULPI bus proposal considering my comment below.
> 
> Sorry, guess I spoke too soon :/
> I am satisfied with the phy case, but I forgot about the chicken/egg
> problem I reported earlier:
> DWC3 will not be functional when reloading the module after it went to
> reset state. Then ULPI enumeration can't happen regardless DSDT code
> powered on phy.

One point here. If we have DSDT handling the gpios with the operation
region, those gpio resources don't need to be given to any device
(actually I think they really shouldn't be given to anything in that
case).

> Heikki, do you have a proposal for that? IMHO that's the main missing
> point if we forget about BYT-CR legacy.

I'm sorry but I'm still not sure about the scenario you are talking
about.

When we load dwc3, we end up autoloading phy-tusb1210 in this case and
increasing the phy devices ref count i.e. preventing phy-tusb1210
module from being unloaded before dwc3 is unloaded.

If we unload dwc3 we can also unload phy-tusb1210 if we like but if
after that we load dwc3 again, the ULPI will be accessible the moment
we register the ulpi interface as it was before.

That I believe is actually a must in case of ULPI. When dwc3 is reset
with GCTL or DCTL SoftReset, it will first write to the ULPI
FunctionControl register's reset bit in order to but the PHY to reset
(PHYSoftRst has no effect in case of ULPI), so ULPI really has to be
accessible before the core is soft reset.

Thanks,

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