linux-kernel - Re: [PATCH v3 1/1] pinctrl: add Intel BayTrail GPIO/pinctrl support

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: <53584491.6000604@codeaurora.org>
Date:	Wed, 23 Apr 2014 17:54:09 -0500
From:	Timur Tabi <timur@...eaurora.org>
To:	Linus Walleij <linus.walleij@...aro.org>
CC:	"Westerberg, Mika" <mika.westerberg@...el.com>,
	Mathias Nyman <mathias.nyman@...ux.intel.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	lkml <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>
Subject: Re: [PATCH v3 1/1] pinctrl: add Intel BayTrail GPIO/pinctrl support

Linus Walleij wrote:
>> >  All of our GPIOs have a
>> >pinmux on them, and so if you want to use the pin for the non-default
>> >functionality, you need to configure the mux.  Isn't that supposed to happen
>> >with the through the pinctrl driver?  That is, when the kernel parses the
>> >ASL, and it seems a command to configure pin #3 to function #4, it calls the
>> >local pinctrl driver to do that?
> Let's suspect this is true. That is how GPIO work after all is it not?

With device trees, function groups are defined by name in the driver, 
and the device tree contains these same names as links between nodes. 
This works well.

In ACPI, it appears that no such infrastructure exists.

> I guess the other option would be that all systems must come with a
> tailored set-up written in ASL, specific for each board configuration.

That makes sense (U-Boot does fixups of the device tree based on actual 
board config, so it's conceivable that UEFI could do the same for ASL). 
  However, that would require either

1) UEFI programs the GPIO muxes directly, without specifying any mux 
information in ASL and without using the Linux driver to program the muxes.

or

2) ASL contains code to program the muxes, and Linux parses that ASL and 
calls the pinctrl driver to program the hardware.

I don't know which direction the Community wants to use.  If we go with 
option #1, then there is no need for the pinctrl driver to specify 
function groups at all.  This means we would not need a separate pinctrl 
driver for each SOC, like we do today.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.
--
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/