On Fri, 2012-12-28 at 00:52 +0100, Ben Hutchings wrote: > On Thu, 2012-12-27 at 22:47 +0000, Malcolm Priestley wrote: > > On Thu, 2012-12-27 at 20:09 +0100, Ben Hutchings wrote: > > > On Thu, 2012-12-27 at 13:01 +0000, Malcolm Priestley wrote: > > > > upstream > > > > commit e2efba763b472835fdface597fe2216b3403967e > > > > > > > > Tested on kernels 2.6.35, 3.0, 3.2, 3.5 & 3.7 > > > > > > > > staging: vt6656: 64 bit- Correctly address void structure. > > > > > > > > Fixes 64 bit deadlock on successful association. > > > > > > > > Cc: [email protected] # 2.6.35+ > > > > Signed-off-by: Malcolm Priestley <[email protected]> > > > > Signed-off-by: Greg Kroah-Hartman <[email protected]> > > > > > > > > diff --git a/drivers/staging/vt6656/rxtx.c > > > > b/drivers/staging/vt6656/rxtx.c > > > > index 0f35a9a..1f87213 100644 > > > > --- a/drivers/staging/vt6656/rxtx.c > > > > +++ b/drivers/staging/vt6656/rxtx.c > > > > @@ -1452,12 +1452,10 @@ s_bPacketToWirelessUsb( > > > > > > > > > Hi Ben, > > > > Ah, you are correct. > > > > However, as it stands, reverting upstream on 64 bit will cause > > a regression. > > I don't understand why you think this has something to do with '64 bit'. > > > I haven't found any regressions on 32bit and it is only a > > condition check. Only WEP 256 users affected and the chances > > of the address hitting TRUE(1) during WEP/WPA negotiation. > > > > I would prefer to submit a patch to correct upstream. > > It's not my decision, anyway. But if this is reverted first then we can > cherry-pick just the real fix for stable. >
Hmm, something has already fix it upstream on the driver. So, both upstream commits e2efba763b472835fdface597fe2216b3403967e and eb304bddc47b59927b650d43c3f35b9266c807a9 need to be reversed. I will try and find out what fixed it. Regards Malcolm > Ben. > -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
