linux-kernel - Re: Seeking clarity on IRQCHIP_MASK_ON

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]

Date:	Tue, 11 Sep 2012 15:20:53 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	NeilBrown <neilb@...e.de>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	"Shilimkar, Santosh" <santosh.shilimkar@...com>,
	lkml <linux-kernel@...r.kernel.org>, linux-omap@...r.kernel.org,
	Kevin Hilman <khilman@...prootsystems.com>,
	Abhijeet Dharmapurikar <adharmap@...eaurora.org>
Subject: Re: Seeking clarity on IRQCHIP_MASK_ON_SUSPEND

On Tue, 11 Sep 2012, NeilBrown wrote:
> On Mon, 10 Sep 2012 12:28:35 +0200 (CEST) Thomas Gleixner
> <tglx@...utronix.de> wrote:
> > You might be looking for a different functionality. Can you explain
> > what you need?
> 
> I want as particular GPIO interrupt to be masked before entering suspend.
> I produced code to get the ->suspend() callback to perform this masking.
> Another developer (Santosh) felt that IRQCHIP_MASK_ON_SUSPEND was the
> preferred way to do this and on the surface this looks like it should be
> correct.  However it doesn't work as explained previously.
> I want a resolution to this difference of opinion that doesn't just sweep the
> issue under that carpet but provides a clear answer to this sort of issue.
> 
> My current opinion is that IRQCHIP_MASK_ON_SUSPEND should be discarded.  The
> patch which introduced it says:
> 
>     Rather than working around this in the affected interrupt chip
>     implementations we can solve this elegant in the core code itself.
>     
> It appears that the solution in core code, while elegant, is wrong.  It
> happens too late to be generally usable.  It is easy enough to handle this

Sigh. The flag was invented with the semantics to keep the current
"check for any interrupt" pending functionality alive and then mask it
right before going down, so only the designated wakeup interrupts can
wake the device. That was the result of the discussion back then and
that was what the developer wanted to achieve with his driver suspend
hackery.

> issue in the interrupt chip drivers so maybe that is the best place
> to handle it.

And have the same "keep track of wakeup interrupts" code over and over
in the drivers.
 
> The the very least I think we need a big comment saying the
> IRQCHIP_MASK_ON_SUSPEND can only be used for irqchips which can always be
> programmed, even when they are suspended from an runtime-PM perspective,
> and that those chips must handle masking in their 'suspend' callback.

Sigh, no. Either we make IRQCHIP_MASK_ON_SUSPEND into an
implementation which masks the interrupts early, if the existing users
find this acceptable or have a separate IRQCHIP_MASK_BEFORE_SUSPEND
flag.

This GPIO driver at hand is probably not the last one which requires
this and we really want to do stuff in the core code instead of having
random implementations of the same stuff all over the place.

Thanks,

	tglx
--
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/