linux-kernel - Re: [PATCH 1/4] gpiolib: make gpio_to

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

Message-Id: <200809241440.43978.david-b@pacbell.net>
Date:	Wed, 24 Sep 2008 14:40:43 -0700
From:	David Brownell <david-b@...bell.net>
To:	Anton Vorontsov <avorontsov@...mvista.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Greg Kroah-Hartman <greg@...ah.com>,
	Kumar Gala <galak@...nel.crashing.org>,
	Timur Tabi <timur@...escale.com>,
	Li Yang <leoli@...escale.com>,
	Laurent Pinchart <laurentp@...-semaphore.com>,
	linuxppc-dev@...abs.org, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] gpiolib: make gpio_to_chip() public

On Wednesday 24 September 2008, Anton Vorontsov wrote:
> We'll need this function to write platform-specific hooks to deal
> with pin's dedicated functions. Quite obviously this will work only
> for the platforms with 1-to-1 GPIO to PIN mapping.
> 
> This is stopgap solution till we think out and implement a proper
> api (pinlib?).
> 
> p.s. This patch actually exports gpio_desc and places gpio_to_chip
> into the asm-generic/gpio.h as `static inline'. This is needed
> to not cause function calls for this trivial translation.
> 
> Also, the patch does not export FLAG_*s... the names are too
> generic, and nobody is using them outside of gpiolib.c.

For the record:  NAK, still.  The concept has problems,
there is no "need" for this.  I sketched a cleaner way
to address the issues of the QE USB driver; I'm sure it
would only take an hour or two to code, using what's
already present.

And if I were to approve something like this it would
be a lot simpler, not exposing internals, and with
appropriate kerneldoc.  Simpler such as

	struct gpio_chip *gpio_to_gpiochip(unsigned gpio)
	{
		return gpio_to_chip(gpio);
	}
	EXPORT_SYMBOL_NOTREALLY(gpio_to_gpiochip);

with a declaration in a header.  It's not like THIS
version would be performance-critical (unlike the one
inside gpiolib).

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