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] [day] [month] [year] [list]

Message-ID: <CACRpkdYQcqSNcCU3FVe7tPeqmC4=HRk=yXDP7WvOLFBVtND12g@mail.gmail.com>
Date:	Fri, 2 May 2014 15:31:06 -0700
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Timur Tabi <timur@...eaurora.org>
Cc:	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	"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" <rjw@...ysocki.net>
Subject: Re: [PATCH v3 1/1] pinctrl: add Intel BayTrail GPIO/pinctrl support

On Fri, Apr 25, 2014 at 9:31 AM, Timur Tabi <timur@...eaurora.org> wrote:
> Rafael J. Wysocki wrote:
>>
>> I would be interested in understanding what exactly the flow is in that
>> situation, so care to educate me?  What does the driver do to trigger
>> this and what exactly does happen in response to that?
>
>
> I only just learned some of this myself, so I'm no expert.  My understanding
> is that the all of the pinctrl-* properties and nodes are scanned by the
> pinctrl layer itself.  So you could have a SATA controller node that points
> to a pin control node (via phandles).  When the SATA driver is probed, the
> pinctrl layer notices the phandles and automatically calls the pinctrl layer
> to configure the pins and pin muxes.

There is a global pin control map for the system spanning all possible
pin controller instances.

Right before a device probe() function is called, the device core will
attempt to grab and activate a pin control setting tied to this device
and named "default". (It can also handle some PM states.)

The table of states can come from:
(a) Platform data or
(b) Device tree

And if there was an ACPI pin controller it would be case (c) and need
to have intelligent bindings allowing such a table to be built so that
the device core can make use of it.

When the different states (such as "default") are enabled, this
results in calls into the pin control driver. In most cases that ends
up with simple register writes but I guess an ACPI driver would
result in calling some esoteric bytecode or whatever or both.

There is no escape from the fact that this needs being
handled from the pin control subsystem though, it can't
be sneaked into the ACPI core or something. You may want
to add new states apart from the ones defined in
include/linux/pinctrl/pinctrl-state.h, as I know ACPI is
a bit picky about it's states and what they are named
(D-states right?)

Yours,
Linus Walleij (pretending to understand ACPI)
--
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/