linux-kernel - Re: [PATCH V3 3/3] mfd: palmas: Add support for optional wakeup

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: <20140919195738.GR14505@atomide.com>
Date:	Fri, 19 Sep 2014 12:57:38 -0700
From:	Tony Lindgren <tony@...mide.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Nishanth Menon <nm@...com>, lee.jones@...aro.org,
	LKML <linux-kernel@...r.kernel.org>, devicetree@...r.kernel.org,
	Keerthy <j-keerthy@...com>, Mark Brown <broonie@...aro.org>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	linux-omap@...r.kernel.org,
	LAK <linux-arm-kernel@...ts.infradead.org>,
	Kevin Hilman <khilman@...aro.org>
Subject: Re: [PATCH V3 3/3] mfd: palmas: Add support for optional wakeup

* Thomas Gleixner <tglx@...utronix.de> [140919 12:47]:
> On Fri, 19 Sep 2014, Tony Lindgren wrote:
> > * Thomas Gleixner <tglx@...utronix.de> [140919 10:37]:
> > >From hardware point of view the wake-up events behave like interrupts
> > and could also be used as the only interrupt in some messed up cases.
> > That avoids all kinds of custom APIs from driver point.
> > 
> > The re-entrancy problem we've most likely had ever since we enabled
> > the PRCM interrupts, and maybe that's why I did not even consider
> > that part. I think before that we were calling the driver interrupt
> > after waking up from the PM code..
> > 
> > Anyways, how about the following to deal with the re-entrancy problem:
> > 
> > 1. The wake-up interrupt handler must have a separate interrupt
> >    handler that just calls tasklet_schedule()
> > 
> > 2. The device interrupt handler also just calls tasklet_schedule()
> > 
> > 3. The tasklet then does pm_runtime_get, handles the registers, and
> >    so on.
> > 
> > Or would we still have a re-entrancy problem somewhere else with
> > that?
> 
> Why on earth are you wanting tasklets in there? That's just silly,
> really.

Lack of a framework on driver side to cope with this in a generic
way? :p
 
> The wakeup handler is supposed to bring the thing out of deep sleep
> and nothing else. All you want it to do is to mask itself and save the
> information that the real device irq is pending.

Yes that is enough.
 
> A stub handler for the wakeup irq is enough. We can have that in the
> irq/pm core and all it would do is simply:
> 
> irqreturn_t handle_jinxed_wakeup_irq(unsigned irq, void *dev_id)
> {
> 	unsigned device_irq = get_dev_irq(dev_id);
> 
> 	force_mask(irq);
> 	set_irq_pending(device_irq);
> 	return HANDLED;	
> }
> 
> So on resume_device_irqs() the real device interrupt gets reenabled
> and unmasked (if it was masked) and the interrupt gets resent either
> in hardware (level or retrigger) or by the software resend mechanism.
> 
> That completely avoids tasklets, reentrant irq handlers and all other
> crap which might be required.

Okie dokie, that sounds good to me. Having this generic for the
drivers would be excellent, that's the missing piece.

Thanks,

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