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

[Heikki Krogerus <heikki.krogerus@linux.intel.com>]

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