linux-kernel - Re: [PATCH 2/2] regmap: irq: do not write mask register if it is not supported

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130214113531.GC13249@opensource.wolfsonmicro.com>
Date:	Thu, 14 Feb 2013 11:35:31 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Laxman Dewangan <ldewangan@...dia.com>
Cc:	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] regmap: irq: do not write mask register if it is not
 supported

On Thu, Feb 14, 2013 at 04:36:08PM +0530, Laxman Dewangan wrote:
> On Wednesday 13 February 2013 07:50 PM, Mark Brown wrote:

> >>  	for (i = 0; i < d->chip->num_regs; i++) {
> >>+		if (!d->chip->mask_base)
> >>+			goto skip_mask_reg_update;

> >Why is this inside the loop?

You appear to have ignored this question.

> >I'd also expect us to return an error if a caller tries to enable or
> >disable an interrupt, or possibly to give different ops to the IRQ
> >subsystem, rather than just silently claim we did what we were asked.

> I tried to use regmap-irq for the gpio submodule and it has two sets
> of register:
> GPIOx_CNFG: bit[7:6] interrupt rising/falling.
> GPIO_INT_STS where each bit shows the interrupt status whether it
> occured or not.
> There is no mask register.

> In regmap-irq_thread() we see the interrupt status and compare
> against mask enable buffer wther this is enabled or not and
> accordingly call the handler.

> hence I am still require irq_mask()/irq_unmask() to reflect the mask
> with interrupt status and type for actually configuring the
> GPIOx_CNFG.

> if I remove the mask_buf at all then how do we tell the int_sts
> register is corresponding to which gpio handler?

This doesn't sound like something that should be open coded in
individual interrupt controller drivers, obviously it's a bit rubbish
that there's no way to enable or disable the interrupt but presumably
other hardware has the same "feature" and the IRQ subsystem ought to
understand it.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)