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, 05 Jun 2014 16:55:22 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Peter De Schrijver <pdeschrijver@...dia.com>
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 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.
--
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