On Mon, Dec 15, 2008 at 04:52:32PM +0200, Jani Nikula wrote: > > Why do they need to be changed? GPIO switches related to the board schematics, > > which do not hopefully change dynamically. > > The switches themselves don't change (nor does this patch support > changing them), but different kinds of external devices may be connected > to the GPIO swiches. It would be useful to be able to change the > notification callbacks and debounce timeouts according to the device. Could you give an example use-case? If the gpio-switch framework starts getting extended and used more, it might be sensible to convert it to the general GPIO API, as Trilok suggested. > Umm, I suppose I was more worried that the write might not be an atomic > operation, messing up the read as well. But I'll take your word for it > if you say the write is okay. :) Integer reads/writes are atomic, unless the system has some serious cache coherency issues. And in that case, spinlocks won't save you either -- only the HW engineers can. =) > > What if omap_update_gpio_switch() is called just before the check for > > notify != NULL from another (hypothetical =)) CPU? Then you end up with the > > function completing, but still having the old notify callback called with > > old notify_data. > > I was, of course, making sure a NULL pointer is not called and there's > no mismatch between old/new notify/notify_data. Your scenario might > theoretically actually occur on a single processor system as well, don't > you think? Ah, yes. I was under the impression that gpio_sw_handler() was called from IRQ context, but since it's a work handler, the function certainly can be preempted. > But is it actually a problem or not? And if yes, do you have any > suggestions as to handling the case? If there's no need to lock for > reading the debounce timeouts in gpio_sw_irq_handler() as you say above, > do you think I could switch to a mutex and call notify callback holding > that? Especially in the case of frameworks, it's good to make things as correct as possible. A mutex is safe. Cheers, Juha -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
