From: Guenter Roeck <linux@roeck-us.net>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Simon Guinot <simon.guinot@sequanux.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
Grant Likely <grant.likely@secretlab.ca>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
"H. Peter Anvin" <hpa@linux.intel.com>
Subject: Re: [PATCH v3] gpio: add GPIO support for F71882FG and F71889F
Date: Thu, 29 Aug 2013 06:41:41 -0700 [thread overview]
Message-ID: <521F4F95.5080103@roeck-us.net> (raw)
In-Reply-To: <20130829125754.GA8813@srcf.ucam.org>
On 08/29/2013 05:57 AM, Matthew Garrett wrote:
> 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.
>
Pretty radical. Following your advice, should we remove all watchdog
and hwmon drivers for all SuperIO chips out there, plus any existing
gpio drivers (drivers/char/pc8736x_gpio.c might be a candidate) ?
Oh, and the parallel port driver also detects super-io chips directly,
so maybe the respective code should be removed as well. I am sure there
is more code that can be removed.
Or is the idea to say "no acpi, no new driver" ? Just wondering -
I have a GPIO driver for Nuvoton chips on my back-burner; that would be
necessary to access some fan controls connected to gpio pins on some boards.
If this is a no-go, I'll happily drop it from my list of things to do,
and just tell the user community that Linux won't support their hardware
due to policy reasons.
Guenter
next prev parent reply other threads:[~2013-08-29 13:41 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-22 9:50 [PATCH v3] gpio: add GPIO support for F71882FG and F71889F Simon Guinot
2013-07-29 15:59 ` Linus Walleij
2013-07-29 20:26 ` Rafael J. Wysocki
2013-08-01 13:46 ` Simon Guinot
2013-08-01 15:52 ` Guenter Roeck
2013-08-26 15:15 ` Simon Guinot
2013-08-29 12:39 ` Linus Walleij
2013-08-29 12:57 ` Matthew Garrett
2013-08-29 13:41 ` Guenter Roeck [this message]
2013-08-29 15:37 ` Matthew Garrett
2013-08-29 16:08 ` Guenter Roeck
2013-08-29 16:25 ` Matthew Garrett
2013-08-29 17:31 ` Guenter Roeck
2013-08-29 22:20 ` Simon Guinot
2013-08-29 22:22 ` Matthew Garrett
2013-08-29 17:32 ` Linus Walleij
2013-08-29 17:35 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=521F4F95.5080103@roeck-us.net \
--to=linux@roeck-us.net \
--cc=grant.likely@secretlab.ca \
--cc=hpa@linux.intel.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=rjw@sisk.pl \
--cc=simon.guinot@sequanux.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.