linux-kernel - Re: [PATCH v7 4/5] ARM: tegra: Add efuse and apbmisc bindings

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: <5390F55A.8090207@wwwdotorg.org>
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/