linux-kernel - RE: [PWM PATCH 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin

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: <BD79186B4FD85F4B8E60E381CAEE190902153826@mi8nycmail19.Mi8.com>
Date:	Tue, 16 Feb 2010 13:12:23 -0500
From:	"H Hartley Sweeten" <hartleys@...ionengravers.com>
To:	"Bill Gatliff" <bgat@...lgatliff.com>
Cc:	"Pavel Machek" <pavel@....cz>, <linux-embedded@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: RE: [PWM PATCH 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin

On Friday, February 12, 2010 9:27 AM, Bill Gatliff wrote:
> H Hartley Sweeten wrote:
>>
>> FWIW, the gpiolib API will accept any non-zero value to "set" a gpio pin
>> and a zero value to "clear" the pin.
>>   
>
> It makes me sort of cringe to say this, but I'm going to assume that the
> API is intended to work that way so that I can take advantage of it. 
> But I'd love to someday have the reassurance that gpiolib really *is*
> intended to work that way (might be a bad idea though, see below).  Call
> me paranoid, but I've lost a lot of hair over the years undoing the
> damage of similar failed assumptions.
>
> I've found the Linux kernel code to be refreshingly forgiving of such
> things, however, so I'm willing to risk it this time.  :)
>
>> For that matter, some of the gpiolib drivers end up returning the bit
>> position mask for a given gpio pin and not 1 or 0.  For instance if the
>> gpio pin in question is bit 6 in an 8-bit register and it is set, a
>> __gpio_get_value will end up returning 0x40 and not '1'.
>>   
>
> Who's to say that gpios should always be boolean?  On the output side, a
> "gpio" that's four bits wide might be a useful way of dealing with bar
> graphs, seven-segment displays, etc. (but more specialized abstractions
> might be more appropriate, of course).

I think the original intention of gpiolib was to deal with individual pins.

> A two-bit "gpio" input might make it easier to deal with rotary encoders.

True.  But a two-bit "gpio" is no longer a "pin" it's now a "port".

I have been messing with a "port" extension for gpiolib but it's not even
close to being mergable yet.  But, that's a different topic...

> But for now, GPIOs are assumed to be booleans and that's why I'm
> hesitant to feed the API non-boolean values.  Someday, those values
> might mean something subtly but disastrously different.  And given my
> luck lately with such things...

True.  As such just use ! and !! to make the values boolean.

gpio is bit 6
val = 0x40 -> !(0x40) = 0
val = 0x40 -> !!(0x40) = 1

Just my .02... Regards,
Hartley
--
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/