linux-kernel - Re: [PATCH v2] gpio: pca953x: add support for open drain pins on PCAL6524

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: <6018d92d2fc91841e76324adaf9f285e39b6fc00.camel@aerq.com>
Date:   Wed, 17 Feb 2021 18:57:20 +0000
From:   "Bedel, Alban" <alban.bedel@...q.com>
To:     "andy.shevchenko@...il.com" <andy.shevchenko@...il.com>,
        "andriy.shevchenko@...ux.intel.com" 
        <andriy.shevchenko@...ux.intel.com>
CC:     "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "bgolaszewski@...libre.com" <bgolaszewski@...libre.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linus.walleij@...aro.org" <linus.walleij@...aro.org>
Subject: Re: [PATCH v2] gpio: pca953x: add support for open drain pins on
 PCAL6524

On Wed, 2021-02-17 at 16:19 +0200, Andy Shevchenko wrote:
> On Wed, Feb 17, 2021 at 3:11 PM Bedel, Alban <alban.bedel@...q.com>
> wrote:
> > On Tue, 2021-02-16 at 19:50 +0200, Andy Shevchenko wrote:
> > > On Tue, Feb 16, 2021 at 6:37 PM Bedel, Alban <
> > > alban.bedel@...q.com>
> > > wrote:
> > > > On Mon, 2021-02-15 at 14:53 +0200, Andy Shevchenko wrote:
> > > > > On Thu, Feb 11, 2021 at 7:52 PM Alban Bedel <
> > > > > alban.bedel@...q.com
> > > > > wrote:
> 
> ...
> 
> > > > > > +#define PCAL65xx_REGS          BIT(10)
> > > > > 
> > > > > Can we have it as a _TYPE, please?
> > > > 
> > > > Let's please take a closer look at these macros and what they
> > > > mean.
> > > > Currently we have 3 possible set of functions that are
> > > > indicated by
> > > > setting bits in driver_data using the PCA_xxx macros:
> > > > 
> > > > - Basic register only: 0
> > > > - With interrupt support: PCA_INT
> > > > - With latching interrupt regs: PCA_INT | PCA_PCAL =
> > > > PCA_LATCH_INT
> > > > 
> > > > This patch then add a forth case:
> > > > 
> > > > - With pin config regs: PCA_INT | PCA_PCAL |
> > > > $MACRO_WE_ARE_DICUSSING
> > > > 
> > > > Then there is the PCA953X_TYPE and PCA957X_TYPE macros which
> > > > indicate
> > > > the need for a different regmap config and register layout.
> > > 
> > > Exactly, and you have a different register layout (coincidentally
> > > overlaps with the original PCA953x).
> > 
> > We have 2 layout for the base registers, the "mixed up registers"
> > of
> > the PCA957x and the "standard" of the PCA953x. Then we have the
> > PCALxxxx chips which extend the base PCA953x registers with further
> > registers for better interrupt handling. These are not treated as a
> > new
> > type in the current code, but as an extra feature on top of the
> > PCA953x.
> 
> Yes, because they are about interrupts AFAICS.

This distinction seems arbitrary, each more advanced version of the
chip just has more features along with a new register block.

> >  The PCAL65xx we are talking about add a further register
> > block, so following the existing concept its not a new layout.
> 
> Yes, with one important detail, i.e. it extends the "mixed up"
> registers, it's not a separate "feature" in this sense. The separate
> "feature" can be, for example, PWM registers. I admit that this most
> of the angle of preference how to draw a line between the features.
> 
> I prefer to see it as a type because of two things (in the current
> code):
>  - OF_9*() macros take only two arguments, second of which is
> Interrupt related
>  - PCA_INT group of bits is about Interrupt only

No, the register set indicated by PCA_PCAL also allow setting pull
up/down which is supported by this driver. Furthermore the extra
registers of the PCAL65XX also allow configuring edge triggered mode
for interrupts. I really don't see why there should be 2 class of
features, that only make the code more complex.

> Your proposal will disrupt the code (more invasive).

I tried to implement what you like to see:

 1 file changed, 105 insertions(+), 20 deletions(-)

vs my proposal:

 1 file changed, 65 insertions(+), 3 deletions(-)

Alban


Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)