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:	Fri, 6 Jun 2014 10:35:43 +0300
From:	Peter De Schrijver <pdeschrijver@...dia.com>
To:	Stephen Warren <swarren@...dotorg.org>
CC:	Russell King <linux@....linux.org.uk>,
	Thierry Reding <thierry.reding@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Linus Walleij" <linus.walleij@...aro.org>,
	Wolfram Sang <wsa@...-dreams.de>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v7 4/5] ARM: tegra: Add efuse and apbmisc bindings

On Fri, Jun 06, 2014 at 12:55:22AM +0200, Stephen Warren wrote:
> On 06/05/2014 04:13 PM, Peter De Schrijver wrote:
> > On Thu, Jun 05, 2014 at 08:41:55PM +0200, Stephen Warren wrote:
> >> On 06/05/2014 07:09 AM, Peter De Schrijver wrote:
> >>> Add efuse and apbmisc bindings for Tegra20, Tegra30, Tegra114 and Tegra124.
> >>
> >>> diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
> >>
> >>> +	apbmisc@...00800 {
> >>> +		compatible = "nvidia,tegra114-apbmisc", "nvidia,tegra20-apbmisc";
> >>
> >> Is the Tegra114 APBMISC register layout 100% a backwards-compatible
> >> superset of that in Tegra20? For both registers the code currently uses
> >> *and* all possible registers the code could ever use? Since the APB MISC
> >> is a bit of a dumping ground for random registers, that feels unlikely,
> >> but perhaps it's possible.
> > 
> > For all I can see it is. At least for the registers the kernel is likely to
> > use.
> 
> But that's ("At least for the registers the kernel is likely to  use")
> not how compatible values are defined. We need to explicitly look at all
> the registers and actively decide that it really is compatible in order
> to mark it so. If we don't want to do that, it's best just to use a
> separate compatible value for each SoC, and add a couple more entries
> into the match table.

All the other registers are for all I can see only useful in emulation
environments.

Cheers,

Peter.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ