Heiko, On Wed, Nov 19, 2014 at 10:46 AM, Heiko Stübner <heiko@xxxxxxxxx> wrote: > Am Mittwoch, 19. November 2014, 09:54:13 schrieb Doug Anderson: >> Hi, >> >> On Tue, Nov 18, 2014 at 3:49 PM, Doug Anderson <dianders@xxxxxxxxxxxx> > wrote: >> > +static void rockchip_irq_disable(struct irq_data *d) >> > +{ >> > + struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d); >> > + u32 val; >> > + >> > + irq_gc_lock(gc); >> > + val = irq_reg_readl(gc, GPIO_INTEN); >> > + irq_reg_writel(gc, val & ~d->mask, GPIO_INTEN); >> > + irq_gc_unlock(gc); >> > +} >> >> Off list, Dmitry asked me why I didn't use irq_gc_mask_disable_reg() >> and irq_gc_unmask_enable_reg() (AKA why I coded up my own function >> here). Originally I tried to use irq_gc_mask_disable_reg() and >> irq_gc_unmask_enable_reg(). ..but they're really not designed to work >> in tandem with the irq_gc_mask_set_bit() and irq_gc_mask_clr_bit(). >> >> Specifically if you try to use one set of functions for your >> mask/unmask and the other for your disable/enable you'll find that >> they stomp on each other. Both functions upkeep the exact same >> "mask_cache" variable. >> >> Personally I'm totally baffled by how irq_gc_mask_disable_reg() and >> irq_gc_unmask_enable_reg() could actually be sane, but that's maybe a >> topic for another discussion. > > I don't think irq_gc_mask_disable_reg and irq_gc_unmask_enable_reg are meant > as callbacks for irq_enable/irq_disable. As the name implies they are > standardized callbacks for irq_mask/irq_unmask on machines using a different > scheme for masking. So I would expected that they operate on the same > mask_cache because both types of functions handle masking on different types of > interrupt controllers. Agreed that they aren't meant for irq_enable / irq_disable and that it's not a bug. It was just so tempting to use them and Dmitry wondered the same thing, so I wrote an email detailing this. Even though these aren't for use as enable/disable, I will point out that they don't seem sane (to me) for masking... > There don't seem to be any generalized callbacks for irq_enable/irq_disable > themself, probably because machines do the most uncommon things there :-) Fair enough. If it becomes common someone can move my functions somewhere common. ;) Do you think this patch is something that should land? Do I need to prove that it's useful before we actually land it? Right now I just posted it because it seemed better, not because it fixes anything that I know of. -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html