On Thu, Aug 1, 2013 at 3:46 PM, Simon Guinot <simon.gui...@sequanux.org> wrote:
> On Mon, Jul 29, 2013 at 05:59:08PM +0200, Linus Walleij wrote:
>> - So we should atleast support ACPI probing with the
>> port-based detection as a final fallback if all else fails.
>>
>> Why can I not get something like:
>>
>> #include <linux/acpi.h>
>> (...)
>> static const struct acpi_device_id gpio_acpi_match[] = {
>> { "FOOBAR", 0 },
>
> After some checks on my boards, it appears that there is no PNP ID
> available for the Super-I/O GPIO functionality (or any others). Moreover
> I think this IDs don't have been registered to Microsoft by Fintech
> (the super-I/O manufacturer).
>
> How do you envisage the follow-up ?
Well shall we just apply this as-is then, with ISA-style port
IO probing and all?
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).
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.
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.
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.
So I'm cc:ing some of my x86 friends to see if they
are OK with this port-probing approach before I merge
the driver.... Rafael, HPA, Matthew?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
