linux-kernel - Re: [PATCH] gpio: New driver for the Intel 82801 (ICH) GPIO pins

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]

Message-ID: <20110419165746.2857c56f@lxorguk.ukuu.org.uk>
Date:	Tue, 19 Apr 2011 16:57:46 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	Jean Delvare <khali@...ux-fr.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] gpio: New driver for the Intel 82801 (ICH) GPIO pins

> Doing a platform device is one solution that is pretty simple to
> implement and I don't think adding child devices is at all a problem.
> However, I'm not mandating that approach, and if you or Jean prefer to
> abstract out the gpio accessors from basic_mmio_gpio(), then that is
> fine by me.  The key issue it to avoid merging yet another, probably
> subtly broken, set of GPIO accessor functions if it can at all be
> avoided.

As is adding a set of subtly broken attempts to create device stacks that
then get into funny sysfs and power management tangles. As well as being
about 12K larger due to the need to suck in an extra module.

I can see the point of splitting out the accessors but if thats a module
of its own then thats another 8K we don't need to waste on a few hundred
bytes of utterly trivial code.

--
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/