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

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]

Date:	Thu, 29 Aug 2013 14:39:33 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Simon Guinot <simon.guinot@...uanux.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	Grant Likely <grant.likely@...retlab.ca>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	Guenter Roeck <linux@...ck-us.net>,
	"H. Peter Anvin" <hpa@...ux.intel.com>
Subject: Re: [PATCH v3] gpio: add GPIO support for F71882FG and F71889F

On Thu, Aug 1, 2013 at 3:46 PM, Simon Guinot <simon.guinot@...uanux.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 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/