Messages in this thread | | | Date | Tue, 10 Apr 2012 14:23:04 +0100 | From | Alan Cox <> | Subject | Re: [PATCH RESEND] gpio: add MSIC gpio driver |
| |
On Tue, 10 Apr 2012 14:10:56 +0100 Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> On Tue, Apr 10, 2012 at 02:18:04PM +0100, Alan Cox wrote: > > > + if (mg->trig_change_mask) { > > + offset = __ffs(mg->trig_change_mask); > > + > > + reg = msic_gpio_to_ireg(offset); > > + if (reg < 0) > > + goto out; > > + > > + if (mg->trig_type & IRQ_TYPE_EDGE_RISING) > > + trig |= MSIC_GPIO_TRIG_RISE; > > + if (mg->trig_type & IRQ_TYPE_EDGE_FALLING) > > + trig |= MSIC_GPIO_TRIG_FALL; > > + > > + intel_msic_reg_update(reg, trig, MSIC_GPIO_INTCNT_MASK); > > + mg->trig_change_mask = 0; > > + } > > What happens if we manage to get more than one change flagged while the > lock is held?
It breaks. 8-). I will take a look at that.
> > +/* Firmware does all the masking and unmasking for us, no masking here. */ > > +static void msic_irq_unmask(struct irq_data *data) { } > > > +static void msic_irq_mask(struct irq_data *data) { } > > Shouldn't these just be omitted if they don't do anything (or > alternatively, how does the firmware figure out that it needs to do the > masking and unmasking)?
The IRQ layer requires they are present and calls them without NULL checks on many paths. I imagine it's better for the normal cases to avoid the conditional checks on those fast paths.
The gpio code is talking to the firmware controller (via intel_msic_reg_*) and effectively its poking GPIOs on a separate device via a messaging interface.
I'll go fix the type change to just keep a per gpio type.
> > + mg = kzalloc(sizeof(*mg), GFP_KERNEL); > > + if (!mg) > > + return -ENOMEM; > > devm_kzalloc()
No point - the driver isn't unloadable. Nor does it make sense to make it so.
Alan
| |