linux-kernel - Re: [PATCH 4/6] usb: phy: tegra: Program new PHY parameters

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: <51FAD020.8090306@wwwdotorg.org>
Date:	Thu, 01 Aug 2013 15:16:16 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Tuomas Tynkkynen <ttynkkynen@...dia.com>
CC:	balbi@...com, linux-tegra@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
	gregkh@...uxfoundation.org, stern@...land.harvard.edu
Subject: Re: [PATCH 4/6] usb: phy: tegra: Program new PHY parameters

On 07/31/2013 11:42 AM, Tuomas Tynkkynen wrote:
> The Tegra30 TRM recommends configuration of certain PHY parameters for
> optimal quality. Program the following registers based on device tree
> parameters:
> 
> - UTMIP_XCVR_HSSLEW: HS slew rate control.
> - UTMIP_HSSQUELCH_LEVEL: HS squelch detector level
> - UTMIP_HSDISCON_LEVEL: HS disconnect detector level.
> 
> These registers exist in Tegra20, but programming them hasn't been
> necessary, so these parameters won't be set on Tegra20 to keep the
> device trees backward compatible.
> 
> Additionally, the UTMIP_XCVR_SETUP parameter can be set from fuses
> instead of a software-programmed value, as the optimal value can
> vary between invidual boards. The boolean property
> nvidia,xcvr-setup-use-fuses can be used to enable this behaviour.

> diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c

> -#define   UTMIP_XCVR_HSSLEW_MSB(x)		(((x) & 0x7f) << 25)
> +#define   UTMIP_XCVR_HSSLEW(x)			(((x) & 0x3) << 4)
> +#define   UTMIP_XCVR_HSSLEW_MSB(x)		((((x) & 0x1ff) >> 2) << 25)

Similarly, may as well s/0x1ff/0x1fc/ there too.

> @@ -262,7 +267,14 @@ static void utmip_pad_power_on(struct tegra_usb_phy *phy)
>  
>  	if (utmip_pad_count++ == 0) {
>  		val = readl(base + UTMIP_BIAS_CFG0);
> -		val &= ~(UTMIP_OTGPD | UTMIP_BIASPD);
> +		val &= ~(UTMIP_OTGPD | UTMIP_BIASPD |
> +			UTMIP_HSSQUELCH_LEVEL(~0) |
> +			UTMIP_HSDISCON_LEVEL(~0) |
> +			UTMIP_HSDISCON_LEVEL_MSB(~0));
> +
> +		val |= UTMIP_HSSQUELCH_LEVEL(config->hssquelch_level);
> +		val |= UTMIP_HSDISCON_LEVEL(config->hsdiscon_level);
> +		val |= UTMIP_HSDISCON_LEVEL_MSB(config->hsdiscon_level);
>  		writel(val, base + UTMIP_BIAS_CFG0);
>  	}
>  
> @@ -432,11 +444,16 @@ static int utmi_phy_power_on(struct tegra_usb_phy *phy)
>  		 UTMIP_FORCE_PDZI_POWERDOWN | UTMIP_XCVR_LSBIAS_SEL |
>  		 UTMIP_XCVR_SETUP(~0) | UTMIP_XCVR_SETUP_MSB(~0) |
>  		 UTMIP_XCVR_LSFSLEW(~0) | UTMIP_XCVR_LSRSLEW(~0) |
> -		 UTMIP_XCVR_HSSLEW_MSB(~0));
> -	val |= UTMIP_XCVR_SETUP(config->xcvr_setup);
> -	val |= UTMIP_XCVR_SETUP_MSB(config->xcvr_setup);
> +		 UTMIP_XCVR_HSSLEW(~0) | UTMIP_XCVR_HSSLEW_MSB(~0));
> +
> +	if (!config->xcvr_setup_use_fuses) {
> +		val |= UTMIP_XCVR_SETUP(config->xcvr_setup);
> +		val |= UTMIP_XCVR_SETUP_MSB(config->xcvr_setup);
> +	}
>  	val |= UTMIP_XCVR_LSFSLEW(config->xcvr_lsfslew);
>  	val |= UTMIP_XCVR_LSRSLEW(config->xcvr_lsrslew);
> +	val |= UTMIP_XCVR_HSSLEW(config->xcvr_hsslew);
> +	val |= UTMIP_XCVR_HSSLEW_MSB(config->xcvr_hsslew);

Those two chunks end up clearing some fields in the register now even on
earlier chips, whereas before their values were maintained when doing
the read/modify/write. Yet, the commit description says the new fields
aren't changed on Tegra20. Do the changes above need to be guarded by if
(requires_extra_tuning_parameters)?

(When I tested this series, I only tested Tegra30/114; I didn't any
Tegra20 devices...)
--
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/