linux-kernel - Re: [PATCH] phy: Add a driver for dm816x USB 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: <20150317021919.GA31346@atomide.com>
Date:	Mon, 16 Mar 2015 19:19:19 -0700
From:	Tony Lindgren <tony@...mide.com>
To:	Matthijs van Duin <matthijsvanduin@...il.com>
Cc:	Bin Liu <binmlist@...il.com>, Felipe Balbi <balbi@...com>,
	Kishon Vijay Abraham I <kishon@...com>,
	linux-kernel@...r.kernel.org,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	linux-usb <linux-usb@...r.kernel.org>,
	Brian Hutchinson <b.hutchman@...il.com>
Subject: Re: [PATCH] phy: Add a driver for dm816x USB PHY

* Matthijs van Duin <matthijsvanduin@...il.com> [150316 14:17]:
> *gets increasingly confused*

:)
 
> The datasheet (sprs614e) only contains register addresses, and they
> seem to match the TRM's USB chapter.  The only disagreement I can spot
> is related to USB_CTRL register(s) in the control module (offsets
> 0x620 and 0x628) where
> * the TRM claims both exist in the control module chapter (1.16.1.3),
> one for each both
> * the TRM's USB chapter claims only one exists, and its layout
> (24.9.8.2) doesn't resemble the former one

Yes the second entry is the closest thing to a documentation
here it seems.

> * the datasheet agrees only one exists (but gives no layout)
> * reality seems to disagree with both: I booted up our evm816x,
> plugged in a mouse to confirm USB is functional, and attached JTAG:
> both registers read as zero (contradicting both layouts) and appear to
> ignore writes.

Yes so it seem here too, this is dm816x rev c, what do you have?

Anyways, I'll add a note that at least rev c does not seems to do
anything with USB_CTRL but that we follow what the TI tree is doing
in case some other revisions of the hardware use it.
 
> There doesn't seem to be any disagreement in the docs about the
> USBPHY_CTRL regs (offsets 0x624 and 0x62c in control module) as far as
> I can tell, and the documented reset values also match what I see via
> JTAG.

Yes agreed.

> > But dm814x [..] seems to be wired up like am335x.
> 
> This I mentioned: the only difference is related to GPIO mode (which
> on the dm814x yields exactly that: GPIO, while the am335x uses it to
> hook up UARTs).
> 
> > Yes I checked am3517 trm, and that too mentions Synopsys once
> 
> Only in its ECHI/OCHI host controller, not the OTG one...

Oh OK I missed that part.
 
> Anyhow, I didn't expect this small observation to end up becoming a
> device archeology expedition, sorry about that ;-)

Well thanks for spotting the weirdness :) 
 
> >> BTW, da850? Is that yet another instance of Primus? (i.e.
> >> omap-L1xx/c674x/am1xxx with odd final digit, also da830/da828)
> >
> > Yes it's the arm926 based series, l-138 is da850 I believe.
> 
> Ah, but there are two such series: Freon and Primus. Just to be
> different, their part numbers are both allocated from the omap-L1xx
> (arm+dsp) / tms320c674x (dsp only) / am1xxx (arm only) ranges, but
> distinguished by Freon having even final digit while Primus has odd
> final digit. Of course this doesn't hold for the da8xx parts, that
> would be too consistent.

I can't keep up with these part numbers..
 
> But you're right, da850 indeed seems to be a Freon rather than a
> Primus based on some more googling (apparently da850 has SATA --
> Primus doesn't).

OK

Regards,

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