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
| ||
|
Date: Wed, 2 Nov 2022 03:28:43 +0900 From: Hector Martin <marcan@...can.st> To: Arminder Singh <arminders208@...look.com>, linux-kernel@...r.kernel.org Cc: linux-i2c@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, asahi@...ts.linux.dev, linuxppc-dev@...ts.ozlabs.org, Alyssa Rosenzweig <alyssa@...enzweig.io>, Sven Peter <sven@...npeter.dev>, Christophe Leroy <christophe.leroy@...roup.eu>, Nicholas Piggin <npiggin@...il.com>, Michael Ellerman <mpe@...erman.id.au> Subject: Re: [PATCH v3] i2c/pasemi: PASemi I2C controller IRQ enablement On 07/10/2022 09.42, Arminder Singh wrote: > This patch adds IRQ support to the PASemi I2C controller driver to > increase the performace of I2C transactions on platforms with PASemi I2C > controllers. While primarily intended for Apple silicon platforms, this > patch should also help in enabling IRQ support for older PASemi hardware > as well should the need arise. > > Signed-off-by: Arminder Singh <arminders208@...look.com> > --- > This version of the patch has been tested on an M1 Ultra Mac Studio, > as well as an M1 MacBook Pro, and userspace launches successfully > while using the IRQ path for I2C transactions. > [...] Please increase the timeout to 100ms for v4. 10ms was always wrong (the datasheet says the hardware clock stretching timeout is 25ms, and most i2c drivers have much larger timeouts), and with the tighter timing achievable with the IRQ patchset we are seeing timeouts in tipd controller requests which can clock-stretch for ~10ms themselves, followed by a spiral of errors as the driver has pretty poor error recovery. Increasing the timeout fixes the immediate problem/regression. Other than that, I now have a patch that makes the whole timeout/error detection/recovery much more robust, but I can submit it after this goes in :) - Hector
Powered by blists - more mailing lists