linux-kernel - [RFC] IT87xx GPIO and other drivers

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-next>] [day] [month] [year] [list]

Date:	Mon, 16 Apr 2012 12:51:21 -0700
From:	Diego Elio Pettenò <flameeyes@...meeyes.eu>
To:	Grant Likely <grant.likely@...retlab.ca>,
	guillaume ligneul <guillaume.ligneul@...lis.com>,
	Linus Walleij <linus.walleij@...ricsson.com>,
	Guenter Roeck <guenter.roeck@...csson.com>,
	Jean Delvare <khali@...ux-fr.org>,
	Wim Van Sebroeck <wim@...ana.be>,
	Denis Turischev <denis@...pulab.co.il>
CC:	linux-kernel@...r.kernel.org, linux-watchdog@...r.kernel.org
Subject: [RFC] IT87xx GPIO and other drivers

Hi all, sorry if I'm mailing lots of you at once, but I'm afraid I got
my hands on a can of worms right now...

As some of you remember I've been working on a driver for supporting the
GPIO functions of the IT8728F Super I/O chip, as well as making the WDT
driver to work on this chip.

After trying to make a bit of sense of it all, I'm concerned that the
only _correct_ way to handle this would be to ahve a set of drivers that
work together, rather than a number of drivers that all do their own
part. Currently we have:

 - hwmon/it87 which supports most it87xx chips;
 - it87_wdt for most it87xx chips (including it8712);
 - it8712f_wdt which supports the "Smart Guardian" watchdog;
 - gpio_it8761e for that single IT87xx gpio;
 - my gpio_it87 driver that works with it8728f and should work with
it8761e (for what I can tell from the other driver), and Guillaume has
code for IT8712 as well (which variant?).

What issues are there with this situation?

All these drivers use to some extent the Super I/O addresses (0x2e/0x2f)
to read and write to its registers, including detection code which is
replicated for each of them. The functions to read and write superio
registers is also duplicate.

Only some of these drivers (namely gpio-it8761e for what I can tell)
support checking both 0x2e/0x2f and 0x4e/0x4f, which is an alternative
addressing for the superio register handling.

The GPIO pins on most of the it87xx chips are also multi-function, and
_should not_ be user-visible, but for some of them it might make sense
to (for instance it should be possible to drive some of the LEDs on
it8728f-based motherboards by replacing the functions of some PINs to GPIO).

For what I can tell, it should probably be a good idea to have something
along these lines, but I'm _not_ a driver expert:

 - mfd-it87xx: a platform driver, which probes the superio to check it
to be an it87xx chip, and then reserve resources for the other drivers;
 - hwmon/it87: no longer probes autonomously for which chip it is, and
where it is;
 - it87_wdt: ibidem;
 - it8712_wdt: no clue about it, but I guess the same;
 - gpio-it87: ibidem again;
 - pinctrl-it87: abstracts support for the various pin-choice registers;
 - led-it87: possibly to drive the power/network/hdd leds, akin to what
happens with some laptops, and embedded systems.

Does a plan like this make sense? Denis have you still access to an
it8761e board?

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@...meeyes.eu — http://blog.flameeyes.eu/
--
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/