| 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
| ||
|
Message-ID: <20130607052353.GB11878@intel.com> Date: Fri, 7 Jun 2013 08:23:53 +0300 From: Mika Westerberg <mika.westerberg@...ux.intel.com> To: Christian Ruppert <christian.ruppert@...lis.com> Cc: Wolfram Sang <wsa@...-dreams.de>, Jean Delvare <khali@...ux-fr.org>, Pierrick Hascoet <pierrick.hascoet@...lis.com>, linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH 1/2] i2c: designware: fix race between subsequent xfers Hi Christian, On Thu, Jun 06, 2013 at 03:43:35PM +0200, Christian Ruppert wrote: > The designware block is not always properly disabled in the case of > transfer errors. Interrupts from aborted transfers might be handled > after the data structures for the following transfer are initialised but > before the hardware is set up. This might corrupt the data structures to > the point that the system is stuck in an infinite interrupt loop (where > FIFOs are never emptied). > This patch cleanly disables the designware-i2c hardware at the end of > every transfer, successful or not. Have you tried with the latest mainline driver? There is a commit that solves similar problem: 2a2d95e9d6d29e7 i2c: designware: always clear interrupts before enabling them Maybe it helps? -- 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/
Powered by blists - more mailing lists