On Mon, 2008-12-15 at 15:22 +0200, Felipe Balbi wrote: > Hi, > > one comment below > > On Mon, Dec 15, 2008 at 02:08:16PM +0200, ext Jani Nikula wrote: > > +int omap_update_gpio_switch(const struct omap_gpio_switch *cfg) > > +{ > > + unsigned long flags; > > + struct gpio_switch *sw = find_switch(cfg->gpio, cfg->name); > > + > > + if (!sw) > > + return -EINVAL; > > + > > + spin_lock_irqsave(&sw->lock, flags); > > + sw->debounce_rising = cfg->debounce_rising; > > + sw->debounce_falling = cfg->debounce_falling; > > + sw->notify = cfg->notify; > > + sw->notify_data = cfg->notify_data; > > + spin_unlock_irqrestore(&sw->lock, flags); > > + > > + return 0; > > +} > > +EXPORT_SYMBOL(omap_update_gpio_switch); > > how about you only change what's not null ?? then you could only change > the notify callback and keep the same debounce_rising/falling ?? That's a nice idea, but gpio_sw_irq_handler() actually supports having 0 debounce timeouts, i.e. no settling time. Of course, I could use -1 for "don't update". However, the semantics above is exactly the same as in add_board_switches() for the update case. I'm not sure if it would be a good idea to deviate from this - what do you think? Jani. -- 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