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
| ||
|
Date: Thu, 29 Aug 2013 06:41:41 -0700 From: Guenter Roeck <linux@...ck-us.net> To: Matthew Garrett <mjg59@...f.ucam.org> CC: Linus Walleij <linus.walleij@...aro.org>, Simon Guinot <simon.guinot@...uanux.org>, "Rafael J. Wysocki" <rjw@...k.pl>, 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>, "H. Peter Anvin" <hpa@...ux.intel.com> Subject: Re: [PATCH v3] gpio: add GPIO support for F71882FG and F71889F 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 -- 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/
Powered by blists - more mailing lists