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: <CAHN=yaaYiyPOM6-T8_126N=rBdS-Qzf7_yAg=oWB_DxBsg6fuw@mail.gmail.com>
Date: Mon, 27 Jan 2025 17:45:39 +0100
From: lakabd <lakabd.work@...il.com>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: mark.tomlinson@...iedtelesis.co.nz, brgl@...ev.pl, 
	linus.walleij@...aro.org, linux-gpio@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Abderrahim LAKBIR <abderrahim.lakbir@...ia.fr>
Subject: Re: [PATCH] gpio: pca953x: Improve interrupt support

> On Mon, Jan 27, 2025 at 09:47:17AM +0200, Andy Shevchenko wrote:
> > On Tue, Jan 21, 2025 at 12:12 PM lakabd <lakabd.work@...il.com> wrote:
> > > Le mar. 14 janv. 2025 à 16:44, work work <lakabd.work@...il.com> a écrit :
> > > > Le mar. 14 janv. 2025 à 10:37, Andy Shevchenko
> > > > <andy.shevchenko@...il.com> a écrit :
> > > > > On Tue, Jan 14, 2025 at 12:03 AM lakabd <lakabd.work@...il.com> wrote:
>
> ...
>
> Okay, I have read a lot the datasheet (PCAL9535A), and while Fig.12 shows
> an example of what happens in practice, neither the schematic on Fig.6 nor
> the description of the interrupt status register doesn't clarify this
> behaviour. The bottom line is that the latch helps only to keep the input data
> for longer and doesn't anyhow affect the input change on another pin while
> servicing the one that asserts the interrupt. Basically what they should have
> said is that the interrupt status register snapshot is made on the very first
> event and doesn't reflect the actual status anymore in case more input changes
> are coming. Hence there is no practical use of the interrupt status register.

Indeed, I came to the same conclusion i.e., if reading the interrupt
status register doesn't reset the interrupt line it is not practical
and can be considered a HW design flaw.

>
> Seems to me a good candidate for errata. Does anybody inform NXP about this?
>
> Meanwhile looking into the code I'm wondering why we can't actually use
> just input port register data with the logic as for PCAL. Nonetheless this
> can be optimized later. I think Mark's patch is good enough as current fix.
>

If we accept Mark's patch there will be no difference between PCA_PCAL
and regular chips in IRQ handling.
Looking at pca953x_irq_pending() the process for non-PCA_PCAL is quite
slower; there is one I2C read in addition, plus multiple bitmap
operations. I think that the solution I proposed at least helps in
keeping the leverage for PCA_PCAL chips.

--
Best Regards,
Abderrahim LAKBIR

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ