Re: [PATCH v3] gpio: add GPIO support for F71882FG and F71889F

[Matthew Garrett <mjg59@srcf.ucam.org>]

On Thu, Aug 29, 2013 at 02:39:33PM +0200, Linus Walleij wrote:

> I think Rafael said something about it being possible for us
> to register our own kernel ACPI PNP IDs (as if: there is no
> road here, but if someone starts to walk here, a road will
> soon become, and we take the first step then).

It'd be straightforward to register the LNX PnP prefix and have someone 
take responsibility for assigning numbers, but really a generic vendor 
string should only be used when defining programming models rather than 
specific devices.

> But overall I am a bit confused: I am hearing from one end
> of the x86 community that ACPI is the way to go for
> configuring platform devices on x86, yet stuff like this is
> popping up from independent vendors, and get integrated
> on boards with no ACPI tables in sight.

ACPI is usually used to describe systems, and the normal ACPI way of 
handling GPIO devices is to expose the device at the other end of the 
GPIO lines and then provide AML for toggling the lines. Attaching an 
actual driver to the device would interfere with that, so nobody writes 
an actual driver.

> Over at ksummit-discuss we have had a thread about
> whether device tree should be used in such cases, but
> that is not clear either.

If a vendor doesn't provide any way to autoprobe a device, there's no 
way to autoprobe a device. That usually means that you're not expected 
to use that device.

> Basically I'm a bit confused because the x86 community
> is talking with so many voices and I'm not used to it,
> and I don't know if they actually have a common vision.

x86 is driven by the vendors, not us. If the vendors don't provide ACPI 
entries for a device then the choices are to either use port probing or 
refuse to support that device. We've traditionally gone for the former.

-- 
Matthew Garrett | mjg59@srcf.ucam.org