netdev - Re: [Ipw2100-devel] [RFC] Runtime power management on ipw2100

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: <1170925306.19089.125.camel@debian.sh.intel.com>
Date:	Thu, 08 Feb 2007 17:01:46 +0800
From:	Zhu Yi <yi.zhu@...el.com>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	ipw2100-devel@...ts.sourceforge.net, netdev@...r.kernel.org,
	linux-pm@...ts.osdl.org
Subject: Re: [Ipw2100-devel] [RFC] Runtime power management on ipw2100

On Tue, 2007-02-06 at 21:44 +0000, Matthew Garrett wrote:
> I'm reluctant to drop the IRQ because PCMCIA seems to have 
> a nasty habit of grabbing free looking IRQs and setting them to be
> edge triggered, which would obviously be bad. 

Can you provide more details for this problem and why we should
workaround it here instead of fixing the PCMCIA driver (hardware)?

A generic requirement for dynamic power management is the hardware
resource should not be touched when you put it in a low power state. In
this case, ipw2100 interrupt handler is possibly called (for example, it
shares the same IRQ with other devies) and it touches the card register,
which will cause problem. A possible workaround is to check the suspend
state in the beginning of the ISR and returns IRQ_NONE. But I think
freeing the irq handler before suspend should be the right way to go.

Thanks,
-yi
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html