All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.