linux-kernel - Re: [PATCH 5/5] Ath5k: suspend/resume fixes

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 for Android: free password hash cracker in your pocket

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

Message-Id: <1216229703.29744.23.camel@dv>
Date:	Wed, 16 Jul 2008 13:35:03 -0400
From:	Pavel Roskin <proski@....org>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
Cc:	Nick Kossifidis <mickflemm@...il.com>,
	Jiri Slaby <jirislaby@...il.com>, linville@...driver.com,
	linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org,
	"Luis R. Rodriguez" <mcgrof@...il.com>
Subject: Re: [PATCH 5/5] Ath5k: suspend/resume fixes

On Wed, 2008-07-16 at 09:31 -0700, Jesse Barnes wrote:
> On Wednesday, July 16, 2008 9:15 am Nick Kossifidis wrote:
> > It's ok for now, but have in mind that on my upcoming patch series i'm
> > disabling msi (commented out) since it results no interrupts on pci-e
> > cards (seems there is a bug in kernel's msi implementation).
> 
> Hm, would be good to get details here.  MSI is being used by other drivers 
> successfully...

That's true, but no driver uses the same interrupt handler with and
without MSI.  Either it's different handlers or the handler checks if
MSI is enabled and does something differently.

Checks is any interrupts are pending are different for MSI.  It may be
not hard to do (it's probably easier than for real interrupts), but it
has to be figured out.  Somebody has to do it right.  Until MSI is
supported by the interrupt handler, it should not be enabled by the
driver, or we get a non-functioning driver for AR5006.

I see that MSI is enabled in wireless-testing, but I think we should try
to avoid this mistake when the commit goes upstream.  I'm not sure what
the procedure there, but it would be nice to keep the tree bisectable,
i.e. avoid known regressions in any revision.  Maybe an amended commit
should go upstream, and we'll drop the original patch when rebasing to
the upstream branch?

-- 
Regards,
Pavel Roskin
--
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/