linux-kernel - Re: [PATCH] gpio: stmpe: Add DT support for stmpe gpio

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: <CACRpkda6=UPW+Xy9ztkAtFvCMySt4iR8YabYNNTdnZBpVc98rQ@mail.gmail.com>
Date:	Sat, 1 Dec 2012 20:34:37 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Lee Jones <lee.jones@...aro.org>
Cc:	Shiraz Hashim <shiraz.hashim@...com>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	grant.likely@...retlab.ca, devicetree-discuss@...ts.ozlabs.org,
	linux-kernel@...r.kernel.org, spear-devel@...t.st.com,
	Vipul Kumar Samar <vipulkumar.samar@...com>,
	Rabin VINCENT <rabin.vincent@...ricsson.com>
Subject: Re: [PATCH] gpio: stmpe: Add DT support for stmpe gpio

On Mon, Nov 26, 2012 at 12:28 PM, Lee Jones <lee.jones@...aro.org> wrote:
> On Fri, 23 Nov 2012, Shiraz Hashim wrote:

[About st-norequest-mask]
>> This is a board dependent parameter which just informs gpio driver
>> about pins, which must not be requested. It may happen for a stmpe
>> variant where such gpio pins are multiplexed with some other
>> function.
>>
>> Hence it must be part of DT itself.
>
> Doesn't pinctrl normally handle this kind of stuff?

So this is a signal that something might be strange about the
driver architecture at large.

The datasheet for STMPE1601 says:

"The STMPE1601 offers great flexibility, as each
I/O can be configured as input, output or specific
functions."

Hm hm. Well this driver existed before the pin control
system so we have to live with this. We *could* assume
that the above DT property could be set beacause someone
connected a GPIO to ground and trying to use it
would burn the system or something. But if it's actually
dealing with the sideeffects of pinmuxing it's done in the
wrong place.

Apart from the pinctrl API another way to handle these
beasts is what I do in the drivers/mfd/tps6105x.c,
where the hardware is such that you basically always
nail down the hardware for one specific use case
of 3 possible. Then it's done by configuring the root
MFD device.

The crucial question is: can the STMPE controllers be
used for GPIO, PWM, keypad and touchscreen at the
*same time* or are they nailed to *one* usecase during
electronics design?

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/