Re: [PATCH RESEND] gpio: add MSIC gpio driver

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

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