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: <4D62CA32.5090007@bluewatersys.com>
Date:	Tue, 22 Feb 2011 09:25:22 +1300
From:	Ryan Mallon <ryan@...ewatersys.com>
To:	Alexander Stein <alexander.stein@...tec-electronic.com>
CC:	Wolfram Sang <w.sang@...gutronix.de>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Eric Miao <eric.y.miao@...il.com>,
	Peter Tyser <ptyser@...-inc.com>, linux-kernel@...r.kernel.org,
	Alek Du <alek.du@...el.com>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	David Brownell <dbrownell@...rs.sourceforge.net>,
	Uwe Kleine-K?nig <u.kleine-koenig@...gutronix.de>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Joe Perches <joe@...ches.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Grant Likely <grant.likely@...retlab.ca>
Subject: Re: [PATCH v2 1/4] gpiolib: Add "unknown" direction support

On 02/22/2011 12:38 AM, Alexander Stein wrote:
> On Monday 21 February 2011, 12:22:40 Wolfram Sang wrote:
>> On Mon, Feb 21, 2011 at 12:07:27PM +0100, Alexander Stein wrote:
>>> On Monday 21 February 2011, 10:47:56 Wolfram Sang wrote:
>>>>> We had exported our 5V_enable gpio to sysfs to allow a user-space
>>>>> application to enable/disable devices connected to 5V circuit.
>>>>> But on the other hand we had to read the current status of this gpio
>>>>> in the power-fail interrupt handler to distinguish between
>>>>> false-positive (5V disabled) and a correct detection.
>>>>
>>>> What about gpio_export() (description in Documentation/gpio.txt)?
>>>
>>> Ah, I didn't know about this. I just expected this is only used from
>>> sysfs part. But you have to make sure your .ko is loaded before
>>> userspace is accessing sysfs and tries to export the GPIO.
>>
>> Eh? Userspace doesn't export the GPIO in that case.
> 
> Sure, but you have to make sure you have it exported or userspace will fail.
> 
>>> Or is it "allowed" by the API convention to gpio_request and gpio_export
>>> (and set direction) a GPIO in the machine startup code which will later
>>> be used in a different place?
>>
>> different place = userspace? Well, that's the main intention of
>> gpio_export(). (I have the feeling we are missing each other here,
>> thoguh) I'd suggest looking a bit further in the docs/code. It should
>> make clear what is possible.
> 
> No, with different place I mean a kernel module driver which will be loaded 
> later using insmod. In this case this module is just expecting the GPIO has 
> already be exported and set proper direction without requesting the GPIO 
> itself.

If the module does the gpio_request, then it should also do the
gpio_export (and gpio_unexport/gpio_free on module exit). In this case
when the module is not loaded the gpio is not in use by the kernel and
user space is able to access it via sysfs. When the module is in use the
gpio_export call will make the gpio available via sysfs.

If the gpio_request is done in your platform code, then the gpio_export
should also go in the platform code. This way the gpio is always in use
by the kernel, but also exported to userspace so it will be available
via sysfs.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan@...ewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ