linux-kernel - Re: use IORESOURCE_REG resource type for non-translatable addresses in DT

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:	Wed, 27 Aug 2014 11:24:49 -0700
From:	Bjorn Andersson <bjorn@...o.se>
To:	Stephen Boyd <sboyd@...eaurora.org>
Cc:	Rob Herring <robherring2@...il.com>,
	Grant Likely <grant.likely@...aro.org>,
	Stanimir Varbanov <svarbanov@...sol.com>,
	Arnd Bergmann <arnd@...db.de>,
	Rob Herring <rob.herring@...aro.org>,
	Lee Jones <lee.jones@...aro.org>,
	"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Mark Brown <broonie@...aro.org>
Subject: Re: use IORESOURCE_REG resource type for non-translatable addresses
 in DT

On Tue, Jul 29, 2014 at 11:06 PM, Stephen Boyd <sboyd@...eaurora.org> wrote:
> On 07/29, Rob Herring wrote:
[..]
>>
>> You might as well do of_property_read_u32 in the below example.
>>
>
> Fair enough. The example is probably too simple. Things are
> sometimes slightly more complicated and a simple
> of_property_read_u32() isn't going to work in the case of
> multiple reg values or when reg-names is in play.
>

But do we have such cases in the Qualcomm PMICs?

The only case I've hit so far is for gpios and mpps, where it feels
like reg should be base, size and not simply base reg of first gpio -
but that's a different thing.

Also, so far it seems like most drivers just code the base address in
the driver, as we have very specific compatibles.

How about we stop trying so hard to make this "perfect" and just merge
something close to Josh's original proposal and ignore this problem?
Currently all we're doing is delaying any possibility of getting
drivers for the individual blocks merged.
If we have the dt bindings require the reg to be there, we can discuss
and change this all we want later!

Regards,
Bjorn
--
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/