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: <4d67d5627921b0f7ca6579b81f97691c53ef0c34.camel@aerq.com>
Date:   Tue, 16 Feb 2021 16:37:49 +0000
From:   "Bedel, Alban" <alban.bedel@...q.com>
To:     "andy.shevchenko@...il.com" <andy.shevchenko@...il.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 Mon, 2021-02-15 at 14:53 +0200, Andy Shevchenko wrote:
> Hint: don't forget to include reviewers from previous version

I added you to the CC list for the new patch, did I miss someone else?

> On Thu, Feb 11, 2021 at 7:52 PM Alban Bedel <alban.bedel@...q.com>
> wrote:
> > From a quick glance at various datasheets the PCAL6524 and the
> > PCAL6534 seems to be the only chips in this family that support
> > setting the drive mode of single pins. Other chips either don't
> > support it at all, or can only set the drive mode of whole banks,
> > which doesn't map to the GPIO API.
> > 
> > Add a new flag, PCAL65xx_REGS, to mark chips that have the extra
> > registers needed for this feature. Then mark the needed register
> > banks
> > as readable and writable, here we don't set OUT_CONF as writable,
> > although it is, as we only need to read it. Finally add a function
> > that configures the OUT_INDCONF register when the GPIO API sets the
> > drive mode of the pins.
> 
> ...
> 
> > +#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. These are
accessed using the PCA_CHIP_TYPE() and are used as an integer value,
not as bit-field like the above ones. If we had a struct instead of a
packed integer that would be a different field.

I'll change it to PCAL65xx_TYPE if you insist, but that seems very
wrong to me to use the same naming convention for macros meant for
different fields.

> 
> > +#define PCAL65xx_BANK_INDOUT_CONF BIT(8 + 12)
> 
> IND is a bit ambiguous based on the description below.
> After you elaborate, I probably can propose better naming.

It's derived from the register name in the datasheet which is
"Individual pin output port X configuration register".

> > + *   - PCAL65xx with individual pin configuration
> > + *     Individual pin output config    0x40 + 12 * bank_size   RW
> 
> Not sure I understand what "individual" means here (no, I haven't
> looked into the datasheet).

"individual" mean that each pin can be configured individually as
opposed to other chips that only allow to configure a whole bank of
pins.

> > +       if (config == PIN_CONFIG_DRIVE_OPEN_DRAIN)
> > +               val = mask;
> > +       else if (config == PIN_CONFIG_DRIVE_PUSH_PULL)
> > +               val = 0;
> > +       else
> > +               return -EINVAL;
> 
> Switch-case will look more naturally here (despite being longer in
> terms of LOCs).

Ok.


> > +exit:
> 
> exit_unlock:

Will do.

> > +       mutex_unlock(&chip->i2c_lock);
> > +       return ret;
> 
> ...
> 
> > +#define OF_L65XX(__nrgpio) OF_953X(__nrgpio, PCA_LATCH_INT |
> > PCAL65xx_REGS)
> 
> When you change to the type, it will go accordingly. Don't add
> LATCH_INT to the macro.

As explained above all chips with these registers also have the
registers indicated by PCA_LATCH_INT.

Alban

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