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-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
