linux-kernel - Re: [RFC PATCH 05/10] ARM: tegra: Export function to read USB calibration data

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]

Date:	Thu, 15 May 2014 14:39:07 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Andrew Bresticker <abrestic@...omium.org>,
	linux-tegra@...r.kernel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-usb@...r.kernel.org
CC:	Mark Rutland <mark.rutland@....com>,
	Prashant Gaikwad <pgaikwad@...dia.com>,
	Russell King <linux@....linux.org.uk>,
	Mathias Nyman <mathias.nyman@...el.com>,
	Pawel Moll <pawel.moll@....com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Peter De Schrijver <pdeschrijver@...dia.com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kishon Vijay Abraham I <kishon@...com>,
	Rob Herring <robh+dt@...nel.org>,
	Thierry Reding <thierry.reding@...il.com>,
	Randy Dunlap <rdunlap@...radead.org>,
	Kumar Gala <galak@...eaurora.org>,
	Grant Likely <grant.likely@...aro.org>,
	Mike Turquette <mturquette@...aro.org>
Subject: Re: [RFC PATCH 05/10] ARM: tegra: Export function to read USB calibration
 data

On 05/14/2014 06:33 PM, Andrew Bresticker wrote:
> Board-specific USB configuration data is stored in FUSE_SKU_CALIB_0.
> Export a function to read it so the PHY can be properly configured.

This patch seems conceptually fine to me. Presumably once Peter's fuse
driver is fleshed out, it can expose the exact same semantic interface
to drivers.

I suppose one could argue that we should create/use an explicit fuse
subsystem with a standard API that drivers can call into, rather than a
custom API. We can get the appropriate handle to use for that API from a
phandle (plus fuse IDs?) in a DT property (in the XHCI device node,
pointing at the fuse device node) much like any other cross-device
resource reference. I'm not too bothered whether the code actually does
that in the first instance, although we should make sure we add that DT
property (containing all required fuse ID information) so that the code
/can/ work that way if we want it to in the future.
--
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/