From: Rob Herring <robh@kernel.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>,
linux-renesas-soc@vger.kernel.org, linux-i2c@vger.kernel.org,
devicetree-spec@vger.kernel.org
Subject: Re: [PATCH dt-schema] schemas: i2c: add optional GPIO binding for SMBALERT# line
Date: Mon, 9 Sep 2024 08:39:52 -0500 [thread overview]
Message-ID: <CAL_Jsq+cFb56e5WvipL1nR-0TDz+v6vnFDvz9F9JbXinxkEt1Q@mail.gmail.com> (raw)
In-Reply-To: <CAMuHMdWGtuAuQ3M3HonY8zfODTTz_izV6g9555iwuPLSY+P9_g@mail.gmail.com>
On Mon, Sep 9, 2024 at 8:31 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Rob,
>
> On Mon, Sep 9, 2024 at 3:07 PM Rob Herring <robh@kernel.org> wrote:
> > On Mon, Sep 9, 2024 at 5:58 AM Wolfram Sang
> > <wsa+renesas@sang-engineering.com> wrote:
> > >
> > > Most I2C controllers do not have a dedicated pin for SMBus Alerts. Allow
> > > them to define a GPIO as a side-channel.
> >
> > Most GPIOs are also interrupts, so shouldn't the existing binding be
> > sufficient? The exception is if the GPIO needs to be polled.
>
> If the GPIO pin supports multiple functions, it must be configured as
> a GPIO first. devm_gpiod_get() takes care of that. Just calling
> request_irq() does not. In addition, the mapping from GPIO to IRQ
> number may not be fixed, e.g. in case the GPIO controller supports
> less interrupt inputs than GPIOs, and needs to map them when requested.
All sounds like Linux problems...
> See also the different handling of interrupts and gpios by gpio-keys.
I believe "gpios" is what was originally supported, but now it is
preferred if GPIOs are used as interrupts then we use interrupts in
DT.
Rob
next prev parent reply other threads:[~2024-09-09 13:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-09 10:58 [PATCH dt-schema] schemas: i2c: add optional GPIO binding for SMBALERT# line Wolfram Sang
2024-09-09 13:07 ` Rob Herring
2024-09-09 13:30 ` Geert Uytterhoeven
2024-09-09 13:39 ` Rob Herring [this message]
2024-09-09 14:27 ` Geert Uytterhoeven
2024-09-09 18:24 ` Geert Uytterhoeven
2024-09-10 7:38 ` Wolfram Sang
2024-09-12 6:35 ` Wolfram Sang
2024-09-30 10:58 ` Wolfram Sang
2024-10-01 23:05 ` Rob Herring
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=CAL_Jsq+cFb56e5WvipL1nR-0TDz+v6vnFDvz9F9JbXinxkEt1Q@mail.gmail.com \
--to=robh@kernel.org \
--cc=devicetree-spec@vger.kernel.org \
--cc=geert@linux-m68k.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=wsa+renesas@sang-engineering.com \
/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).