Messages in this thread | | | Date | Tue, 15 Feb 2011 17:19:15 +0000 | From | Alan Cox <> | Subject | Re: [PATCH 1/3] gpiolib: Add ability to get GPIO pin direction |
| |
> + if (chip->get_direction) { > + /* chip->get_direction may sleep */ > + spin_unlock_irqrestore(&gpio_lock, flags); > + if (chip->get_direction(chip, gpio - chip->base) > 0) > + set_bit(FLAG_IS_OUT, &desc->flags); > + spin_lock_irqsave(&gpio_lock, flags); > + } else { > + set_bit(FLAG_IS_UNKNOWN, &desc->flags); > + } > > This would have the side effect of having nearly all GPIO drivers > default to an "unknown" direction until they implement the new > get_direction() function, which I think is an improvement over the
This doesn't solve anything. If the hardware supports alt_func state then it now can't implement get_direction, so that's useless.
> For the "unavailable" state, I didn't think it would be necessary. As > is, if someone calls gpio_request() on an invalid or alt_use pin, they > shouldn't get access to the GPIO, which makes the "unavailable value > moot since they couldn't access the GPIO in the first place.
In a word 'sysfs'
We need FLAG_IS_UNKNOWN (or saner would be FLAG_IS_IN to go with FLAG_IS_OUT) to make the sysfs code report properly (and some other spots fixing to make it work right)
If you add FLAG_IS_UNKNOWN then the other change you need is in
gpio_direction_show() which needs to also check the UNKNOWN bit and report appropriately. That would fix that problem and at least allow the reporting side of GPIO in use for something else to be handled as a platform thing even though it can't be handled properly.
The combination of RESERVED & EXPORTED is also busted but is actually sensible - that I gues should report reserved and fail the set operations.
| |