linux-kernel - Re: [PATCH 1/2] gpio: add pin biasing and drive mode to gpiolib

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: <20110420162958.09286aa7@lxorguk.ukuu.org.uk>
Date:	Wed, 20 Apr 2011 16:29:58 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Linus Walleij <linus.ml.walleij@...il.com>
Cc:	Haojian Zhuang <haojian.zhuang@...il.com>,
	Kyungmin Park <kmpark@...radead.org>,
	Ben Nizette <bn@...sdigital.com>, linux-kernel@...r.kernel.org,
	Grant Likely <grant.likely@...retlab.ca>,
	Lee Jones <lee.jones@...aro.org>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 1/2] gpio: add pin biasing and drive mode to gpiolib

> Some people inevitably think that GPIO and pin/padmux are
> intertwined, but as far as I have seen they are not. However there

It's not just pin muxing - gpio pins are sometimes shared between
firmware and OS and belong to one or the other depending upon what is
going on. For example the OS may need to own the pin for things like
updating or eeprom writing but the firmware or another device owns it for
day to day processing.

> may be a cross dependency so that a GPIO driver may need to
> export an additional pin/padmux interface or so, e.g we have
> a separate chip in I2C which can mux pins...

Would it not make sense to assume that given a situation where you have a
GPIO that can be routed four ways that you actually implement it like the
rest of the kernel - ie

	r = gpio_request(n);	/* n, n+1, n+2, n+3 are the four ways
				*/

	if (r < 0) 	/* EBUSY - someone else is using one of the
				four */ 
		return -EBUSY;
	/* Succeeded - will also have set the mux for us */

At that point drivers don't need to know if a GPIO is muxed it'll just be
busy if someone else is using it.

It seems to me that if the goal of the gpio layer is to provide an
abstraction then it can abstract muxes just fine and without needing
drivers to know.

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