From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: "Bedel, Alban" <alban.bedel@aerq.com>
Cc: "linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
"bgolaszewski@baylibre.com" <bgolaszewski@baylibre.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linus.walleij@linaro.org" <linus.walleij@linaro.org>
Subject: Re: [PATCH v2] gpio: pca953x: add support for open drain pins on PCAL6524
Date: Tue, 16 Feb 2021 19:50:59 +0200 [thread overview]
Message-ID: <CAHp75Vczzhs=8k9G1FQYvqOV+Xg3GHp2=TykJX+E5ypT8puFqw@mail.gmail.com> (raw)
In-Reply-To: <4d67d5627921b0f7ca6579b81f97691c53ef0c34.camel@aerq.com>
On Tue, Feb 16, 2021 at 6:37 PM Bedel, Alban <alban.bedel@aerq.com> wrote:
> 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?
Then we are fine, thanks!
> > On Thu, Feb 11, 2021 at 7:52 PM Alban Bedel <alban.bedel@aerq.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.
Before continuing on this, have you considered to split this
particular chip to a real pin controller and use the existing driver
only for GPIO part of the functionality?
...
> > > +#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).
> 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.
How come? It's a bitmask.
> 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.
To me it's the opposite. The 6524 defines a new type (which has some
registers others don't have). We even have already definitions of
those special registers. I think TYPE is a better approach here.
> > > +#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".
Since we have already register definitions, if should follow existing
pattern, i.e. OUT_INDCONF.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2021-02-16 17:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-11 17:51 [PATCH v2] gpio: pca953x: add support for open drain pins on PCAL6524 Alban Bedel
2021-02-15 12:53 ` Andy Shevchenko
2021-02-16 16:37 ` Bedel, Alban
2021-02-16 17:50 ` Andy Shevchenko [this message]
2021-02-17 13:11 ` Bedel, Alban
2021-02-17 14:19 ` Andy Shevchenko
2021-02-17 18:57 ` Bedel, Alban
2021-02-18 14:14 ` 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='CAHp75Vczzhs=8k9G1FQYvqOV+Xg3GHp2=TykJX+E5ypT8puFqw@mail.gmail.com' \
--to=andy.shevchenko@gmail.com \
--cc=alban.bedel@aerq.com \
--cc=bgolaszewski@baylibre.com \
--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).