On Tue, 2017-12-12 at 14:27 -0600, Timur Tabi wrote:

On 12/12/2017 05:07 AM, Andy Shevchenko wrote:

quoted

Not ACPI standards as of my knowledge. ACPI standard defines a
common
scheme how to define properties, it doesn't tell anything about
property
names or any mappings between names to values or names to "OS
subsystem").

There was an attempt a while back to standardize this like we do for 
device tree, but it fell apart.  Device-specific ACPI-only properties 
are not standarized.  This driver is initialized only on ACPI
systems. 
It has no device tree binding.

It should follow DT *de facto* standard bindings like "ngpios" (though
it's not needed in ACPI case IIRC) and other properties.

quoted

As for GPIO we just follow *de facto* what DT has right now, i.e.
"xxx-
gpio" or "xxx-gpios" pattern is used to map ACPI standard resource
to a
GPIO name. That's how GPIO ACPI lib is being developed.

GPIOs in device tree are defined completely differently than in ACPI. 
On DT, the kernel controls the pin muxing.  On ACPI, pins are muxed
by 
firmware and never re-muxed by the operating system.  So all this
driver 
does is expose a few pins as simple GPIOs.

Wait, runtime muxing is a matter of requesting another function (usually
GPIO) and putting it back afterwards. Do you really need anything like
this at *runtime*?

Pin control design is not compatible with hardware (too abstract), but
that is the problem of DT as well: I'm referring here to not carefully
designed so called "pin states". This is another story and has nothing
specific for ACPI.

-- 
Andy Shevchenko [off-list ref]
Intel Finland Oy