linux-kernel - Re: [PATCH RESEND] gpio: add MSIC gpio driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 10 Apr 2012 14:23:04 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	grant.likely@...retlab.ca, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RESEND] gpio: add MSIC gpio driver

On Tue, 10 Apr 2012 14:10:56 +0100
Mark Brown <broonie@...nsource.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/