linux-kernel - Re: [PATCH 1/4] pinctrl: add a driver for NVIDIA Tegra

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: <CACRpkdb5eu+5k98XKkZXA0m0FHEP4XjVGwD9F=Ezm5gVP5WrQQ@mail.gmail.com>
Date:	Wed, 25 Jan 2012 00:27:31 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Stephen Warren <swarren@...dia.com>
Cc:	Olof Johansson <olof@...om.net>, Colin Cross <ccross@...roid.com>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/4] pinctrl: add a driver for NVIDIA Tegra

On Wed, Jan 25, 2012 at 12:09 AM, Stephen Warren <swarren@...dia.com> wrote:
> [Me]
>> Why are all of these things (reg bank bit ets) signed?
>
> The basic issue is that all of these features are optional for any
> given pin group. I used -1 to indicate an unsupported feature.

Ahyeah. Makes sense. Well do it any way that makes sense
to you. Plus note in the kerneldoc that this is the reason these
are signed.

>> Also, things named  *_bit are a bit (no pun intended) binary,
>> are they containing a single bit? In that case say
>
> They're the bit number/shift within a register. Range 0..31

Can that thing really be negative then?
Or is it really: u8 foo_bit:5 ?

>> u8 foo:1
>>
>> To mark that it's only one bit wide, or u8 foo:4 for four bits
>> etc.
>
> I guess I could be explicit about the max range for each value. It might
> save up to about 8 bytes per pin group, perhaps less based on how well
> things pack to u32 boundaries.

Nah I think you would have to pack the struct with #pragmas for that
and I don't even know if it'd pack below byte limits. Probably not.

The valid usecase is for static code analyzers like people tend to
run on military systems and such and loop over every state
of a code path, this restricts the search space.

But it's admittedly *very* esoteric.

>> func_safe doesn't look like an int either when I look at
>> the code. It's something else, u8?
>
> It's a "enum tegra_mux", which IIRC is technically an int, but unsigned
> is more consistent with the rest of pinctrl.

Hm "enum tegra_mux foo" should work fine too then,
what am I missing here...

> On Tegra20, each of these features is configured at a pin group level;
> there is a single register field that affects multiple pins at once.
> (...)
> Tegra30 is somewhat simpler; each pin can be mux'd separately,
> (...)
> some advanced
> drive-strength-related parameters are still configured at a pin-group
> level not a per-pin level, and again not all groups support every
> parameter.

This actually makes me understand what makes Tegra so special
when it comes to muxing, it's the mix of group-level control in
one architecture and pin-level control in another.

For my systems U300 is a pure Tegra20 type, Nomadik is
pure per-pin controlled. This mixture of group and pin-level
control is what makes the Tegra30 so special, with all effects
on how we model it etc...

Yours,
Linus Walleij
--
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/