linux-kernel - Re: [PATCH v10 4/9] phy: Add Tegra XUSB pad controller support

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: <20160406172616.GB28843@ulmo.ba.sec>
Date:	Wed, 6 Apr 2016 19:26:16 +0200
From:	Thierry Reding <thierry.reding@...il.com>
To:	Kishon Vijay Abraham I <kishon@...com>
Cc:	Stephen Warren <swarren@...dotorg.org>,
	Alexandre Courbot <gnurou@...il.com>,
	Andrew Bresticker <abrestic@...omium.org>,
	linux-tegra@...r.kernel.org, devicetree@...r.kernel.org,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [PATCH v10 4/9] phy: Add Tegra XUSB pad controller support

On Wed, Apr 06, 2016 at 06:13:42PM +0530, Kishon Vijay Abraham I wrote:
> On Friday 04 March 2016 09:49 PM, Thierry Reding wrote:
[...]
> > +struct tegra124_xusb_fuse_calibration {
> > +	u32 hs_curr_level[3];
> > +	u32 hs_iref_cap;
> > +	u32 hs_term_range_adj;
> > +	u32 hs_squelch_level;
> > +};
> 
> All these calibration data can come from dt and a generic PHY function to set
> these data to registers.

This calibration data is actually read from fuses within the chip. As I
understand it the process is that these values are characterized during
chip development and written to the fuses at the fab (or perhaps they
are characterized even as late as at the fab). There should be no need
to read these from DT.

> > +static const char * const tegra124_ulpi_functions[] = {
> > +	"snps",
> > +	"xusb",
> > +};
> > +
> > +static const struct tegra_xusb_lane_soc tegra124_ulpi_lanes[] = {
> > +	TEGRA124_LANE("ulpi-0", 0x004, 12, 0x1, ulpi),
> > +};
> > +
> > +static struct tegra_xusb_lane *
> > +tegra124_ulpi_lane_probe(struct tegra_xusb_pad *pad, struct device_node *np,
> > +			 unsigned int index)
> > +{
> > +	struct tegra_xusb_ulpi_lane *ulpi;
> > +	int err;
> > +
> > +	ulpi = kzalloc(sizeof(*ulpi), GFP_KERNEL);
> > +	if (!ulpi)
> > +		return ERR_PTR(-ENOMEM);
> > +
> > +	INIT_LIST_HEAD(&ulpi->base.list);
> > +	ulpi->base.soc = &pad->soc->lanes[index];
> > +	ulpi->base.index = index;
> > +	ulpi->base.pad = pad;
> > +	ulpi->base.np = np;
> > +
> 
> ulpi PHY's can be found dynamically right? Should this use the ulpi
> phy library?

I don't think that would work here. The registered accessed by this code
are all very Tegra specific as far as I can tell. I doubt that any kind
of generic library would work here.

Perhaps you can point me at the exact code you're thinking of. I only
found drivers/phy/ulpi_phy.h and drivers/usb/common/ulpi.c in a quick
search, neither of which seem to provide anything that would be useful
in this context. The former contains a couple of small helpers that I
don't think are appropriate here, whereas the latter seems to want the
driver to implement a ULPI interface, something which the Tegra XUSB pad
controller doesn't expose.

Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)