Messages in this thread | | | Date | Thu, 15 Nov 2007 08:32:43 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: [patch 2.6.24-rc2 1/3] generic gpio -- gpio_chip support |
| |
On Wed, 14 Nov 2007, David Brownell wrote: > > The protection of the chip list can be converted to a mutex and > > does not need to be a spinlock at all. > > No, we still need to use a spinlock to protect table changes. > The reason for that is briefly: > > - gpio_request()/gpio_free() have so far been optional. Most > platforms implement them as NOPs, not all drivers use them. > (Having gpiolib in place should help change that ...)
By magically doing the request of the pin ? See below.
> - gpio_direction_input()/gpio_direction_output() implicitly > request the pins, if they weren't already requested.
Eek, that's completely wrong. Allowing to access a resource _before_ it is assigned and then doing the assignment implicit is a really bad idea.
> - Those input/output direction-setting calls may be called > in IRQ contexts, which means (on non-RT kernels) no mutex.
There is no reason to do that if you actually have a useful reference to the chip _before_ accessing the pin.
> So we're actually in good shape; just take out a bit of code > (or turn it into debugging instrumentation) and I don't think > anyone will complain about the locking any more.
This still does not solve the lookup, which is done for each operation on a pin (direction setting, read, write).
tglx
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |