linux-kernel - Re: [PATCH] gpio: pca953x: Improve interrupt support

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: <CAHp75VcUoLnXEypFuGF2Tzz3ncOi9daEVLdg+Vp4BwkFyGM1hg@mail.gmail.com>
Date: Mon, 27 Jan 2025 20:58:19 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: lakabd <lakabd.work@...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 6:45 PM lakabd <lakabd.work@...il.com> wrote:
> > On Mon, Jan 27, 2025 at 09:47:17AM +0200, Andy Shevchenko wrote:

...

> > 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.

As I said, we can do optimisations later on. The non-PCAL code is
widely tested, so I prefer to have a slower but tested approach. On
top of that bitmap operations for the chips up to 32 lines are just
operations on one register, which are quite fast even on slow CPUs
(like Intel Quark), in comparison to I²C transactions.

-- 
With Best Regards,
Andy Shevchenko