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: <20150130103039.GF2570@kuha.fi.intel.com>
Date:	Fri, 30 Jan 2015 12:30:39 +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>,
	david.e.box@...ux.intel.com
Subject: Re: [PATCH 8/8] phy: add driver for TI TUSB1210 ULPI PHY

> > > > > > Also, I was chatting in private with David and, apparently, there's a
> > > > > > way to request for eye diagram data from BIOS straight. That's more
> > > > > > in-line with what we would do for DT-based boots, passing that
> > > > > > eye-diagram data as a DT attribute.
> > > > > > 
> > > > > > Care to comment ? If that's the case, I'd rather use that BIOS hook and
> > > > > > remove ulpi_read() from probe().
> > > > > 
> > > > > I'm not familiar with such method. But if there is one, I'm not
> > > > > against it. I need to check it.
> > > > 
> > > > David ? Care to comment ?
> > > 
> > > I agree with Heikki's proposal to use BIOS hook and remove ulpi_read()
> > > from probe(). That address one of my chicken/egg concerns.
> > 
> > Oops. I misinterpreted the thread. Heikki didn't propose that :)
> > Let me get things mature and reply to here.
> 
> I talked to David Box (CC'ed him to this reply).
> We can add an integer value to ACPI and request it during phy's probe
> using ACPI's Device Specific Data (_DSD). That would end the need to
> have phy functional during probe (being compatible to BYT-CR and to
> module support) and would be more compatible to DT as well.

You can still make modifications to the DSDT?!

I am familiar with _DSD, and it does not just allow us to add integer
values, but complete named key to value properties compatible with dt,
including strings. And in case you guys were not familiar with the
unified device property interface, it's a wrapper for apci and dt, and
should btw. be used instead of acpi_* or of_* to get properties in
drivers from now on.

So if we add these properties for the dwc3 device object:
"ulpi,vendor", "ulpi,product", we can check them in ULPI bus driver as
an alternative for reading the vendor and product registers, and
indeed be able to bind the PHY to a driver before it's powered on!

P.S. We should not mix BIOS to ACPI.


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/