linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martyn Welch <martyn.welch@collabora.com>
To: Andy Shevchenko <andriy.shevchenko@intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Bartosz Golaszewski <brgl@bgdev.pl>,
	linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 5/5] gpio: pca953x: Add support for PCAL6534
Date: Tue, 06 Sep 2022 15:01:51 +0100	[thread overview]
Message-ID: <a71dec127a2e188b1eb7df1e385f71410051acca.camel@collabora.com> (raw)
In-Reply-To: <Yxc8GgUnHOuMIn4p@smile.fi.intel.com>

On Tue, 2022-09-06 at 15:24 +0300, Andy Shevchenko wrote:
> On Tue, Sep 06, 2022 at 09:28:19AM +0100, Martyn Welch wrote:
> > From: Martyn Welch <martyn.welch@collabora.com>
> > 
> > Add support for the NXP PCAL6534. This device is broadly a 34-bit
> > version
> > of the PCAL6524. However, whilst the registers are broadly what
> > you'd
> > expect for a 34-bit version of the PCAL6524, the spacing of the
> > registers
> > has been compacted. This has the unfortunate effect of breaking the
> > bit
> > shift based mechanism that is employed to work out register
> > locations used
> > by the other chips supported by this driver. To accommodate ths,
> > callback
> > functions have been added to allow alterate implementations of
> > pca953x_recalc_addr() and pca953x_check_register() for the
> > PCAL6534.
> 
> 
> This looks much cleaner!
> 
> ...
> 
> > @@ -107,6 +109,7 @@ static const struct i2c_device_id pca953x_id[]
> > = {
> >         { "tca9539", 16 | PCA953X_TYPE | PCA_INT, },
> >         { "tca9554", 8  | PCA953X_TYPE | PCA_INT, },
> >         { "xra1202", 8  | PCA953X_TYPE },
> > +
> >         { }
> 
> Missed Diodes?
> 

Dropped as it is expected for the DTBs of devices with a pi4ioe5v6534q
also have a compatible for pcal6534. hence it's not needed in the
driver (at least until someone finds a difference which needs to be
explicitly handled for one and not the other).

> >  };
> >  MODULE_DEVICE_TABLE(i2c, pca953x_id);
> 
> ...
> 
> > +       u8 (*recalc_addr)(struct pca953x_chip *chip, int reg , int
> > off);
> > +       bool (*check_reg)(struct pca953x_chip *chip, unsigned int
> > reg,
> > +                         u32 checkbank);
> 
> I would think of splitting this change. Like in a separate patch you
> simply
> create this interface and only add what you need in the next one.
> 

Can do, though I didn't feel you were particularly fussed about me
having split that out...

> ...
> 
> > +static bool pcal6534_check_register(struct pca953x_chip *chip,
> > unsigned int reg,
> > +                                   u32 checkbank)
> > +{
> > +       int bank;
> > +       int offset;
> > +
> > +       if (reg > 0x2f) {
> 
> I guess code read and generation wise the
> 
>         if (reg >= 0x30) {
> 
> is slightly better.

OK.

> 
> > +               /*
> > +                * Reserved block between 14h and 2Fh does not
> > align on
> > +                * expected bank boundaries like other devices.
> > +                */
> > +               int temp = reg - 0x30;
> > +
> > +               bank = temp / NBANK(chip);
> > +               offset = temp - (bank * NBANK(chip));
> 
> Parentheses are not needed fur multiplication, but if you insist...
> 



> > +               bank += 8;
> 
> > +       } else if (reg > 0x53) {
> 
> In the similar way...
> 
> > +               /* Handle lack of reserved registers after output
> > port
> > +                * configuration register to form a bank.
> > +                */
> 
> Comment style
> 
> /*
>  * Handle...
>  */
> 

ack

> > +               int temp = reg - 0x54;
> > +
> > +               bank = temp / NBANK(chip);
> > +               offset = temp - (bank * NBANK(chip));
> > +               bank += 16;
> > +       } else {
> > +               bank = reg / NBANK(chip);
> > +               offset = reg - (bank * NBANK(chip));
> > +       }
> > +
> > +       /* Register is not in the matching bank. */
> > +       if (!(BIT(bank) & checkbank))
> > +               return false;
> > +
> > +       /* Register is not within allowed range of bank. */
> > +       if (offset >= NBANK(chip))
> > +               return false;
> > +
> > +       return true;
> > +}
> 
> ...
> 
> > -       u8 regaddr = pinctrl | addr | (off / BANK_SZ);
> >  
> > -       return regaddr;
> > +       return pinctrl | addr | (off / BANK_SZ);
> 
> Stray change, or anything I have missed?
> 

Yeah, can remove that change...

> ...
> 
> > +/* The PCAL6534 and compatible chips have altered bank alignment
> > that doesn't
> > + * fit within the bit shifting scheme used for other devices.
> > + */
> 
> Comment style.
> 
> ...
> 
> > @@ -1240,6 +1335,7 @@ static const struct of_device_id
> > pca953x_dt_ids[] = {
> >  
> >         { .compatible = "nxp,pcal6416", .data = OF_953X(16,
> > PCA_LATCH_INT), },
> >         { .compatible = "nxp,pcal6524", .data = OF_953X(24,
> > PCA_LATCH_INT), },
> > +       { .compatible = "nxp,pcal6534", .data = OF_653X(34,
> > PCA_LATCH_INT), },
> >         { .compatible = "nxp,pcal9535", .data = OF_953X(16,
> > PCA_LATCH_INT), },
> >         { .compatible = "nxp,pcal9554b", .data = OF_953X( 8,
> > PCA_LATCH_INT), },
> >         { .compatible = "nxp,pcal9555a", .data = OF_953X(16,
> > PCA_LATCH_INT), },
> 
> Do you decide to drop Diodes compatible from the code?
> 


  reply	other threads:[~2022-09-06 14:43 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20220906082820.4030401-1-martyn.welch@collabora.co.uk>
2022-09-06  8:28 ` [PATCH v2 2/5] dt-bindings: gpio: pca95xx: add entry for pcal6534 and PI4IOE5V6534Q Martyn Welch
2022-09-06  8:37   ` Krzysztof Kozlowski
2022-09-06 12:19   ` Andy Shevchenko
2022-09-06 13:08     ` Linus Walleij
2022-09-06 13:19       ` Andy Shevchenko
2022-09-06 13:33         ` Linus Walleij
2022-09-06 13:53           ` Andy Shevchenko
2022-09-06 14:19           ` Rob Herring
2022-09-06 14:31             ` Andy Shevchenko
2022-09-06 13:05   ` Linus Walleij
2022-09-06 13:40   ` Rob Herring
2022-09-06  8:28 ` [PATCH v2 3/5] gpio: pca953x: Fix pca953x_gpio_set_pull_up_down() Martyn Welch
2022-09-06  8:28 ` [PATCH v2 4/5] gpio: pca953x: Swap if statements to save later complexity Martyn Welch
2022-09-06  8:28 ` [PATCH v2 5/5] gpio: pca953x: Add support for PCAL6534 Martyn Welch
2022-09-06 12:24   ` Andy Shevchenko
2022-09-06 14:01     ` Martyn Welch [this message]
2022-09-06 14:28       ` Andy Shevchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a71dec127a2e188b1eb7df1e385f71410051acca.camel@collabora.com \
    --to=martyn.welch@collabora.com \
    --cc=andriy.shevchenko@intel.com \
    --cc=brgl@bgdev.pl \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).