All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Brian Masney <masneyb@onstation.org>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Jacek Anaszewski <jacek.anaszewski@gmail.com>,
	Pavel Machek <pavel@ucw.cz>, Lee Jones <lee.jones@linaro.org>,
	Sebastian Reichel <sre@kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	Linux Input <linux-input@vger.kernel.org>,
	Linux LED Subsystem <linux-leds@vger.kernel.org>,
	Linux PM list <linux-pm@vger.kernel.org>
Subject: Re: [PATCH 10/13] gpio: max77650: add GPIO support
Date: Thu, 24 Jan 2019 11:30:18 +0100	[thread overview]
Message-ID: <CACRpkdacfOLSs1GPew4gMtL_BX0OTXqBQNWzWZMwAkk+Ah2ETQ@mail.gmail.com> (raw)
In-Reply-To: <CAMRc=Me6OSKDk7bN4++M68DjoeArd+gZx16o0oQBXfRoCWBt2A@mail.gmail.com>

On Mon, Jan 21, 2019 at 6:07 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:

> Thank you for your review. While I think you're right about the issue
> being present in this driver, I'm not sure it's really a problem. Do
> we actually require every gpio-controller to also be a stand-alone
> interrupt-controller?

Absolutely not :D

Just GPIO is fine.

> The binding document for the GPIO module doesn't
> mention this - it only requires the gpio-controller property. Without
> the "interrupt-controller" property dtc will bail-out if anyone uses
> this node as the interrupt parent.
>
> If I'm wrong and we do require it, then I think we need to update
> Documentation/devicetree/bindings/gpio/gpio.txt.

What is weird is if a driver with DT bindings not mentioning IRQ
and only probing from DT start implementing IRQ support, that
becomes quite inconsistent. So then max77650_gpio_to_irq()
should just return -ENOTSUPP
or something for now, then it's fine.

We can add the (complicated) IRQ handling later.

I am trying to eat my own dogfood here, I was sweating all
last night trying to implement a hierarchical IRQ controller.
There is no running away from that now. :/

Apparently doing hierarchical IRQs demand that all irq
controllers up to the top-level SoC IRQ controller support
hierarchical interrupts using the v2 version of the irqdomain
API, and currently it seems like the ARM
GIC seems like the only top level IRQ controller that can
do that.

Yours,
Linus Walleij

WARNING: multiple messages have this Message-ID (diff)
From: Linus Walleij <linus.walleij@linaro.org>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Brian Masney <masneyb@onstation.org>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Jacek Anaszewski <jacek.anaszewski@gmail.com>,
	Pavel Machek <pavel@ucw.cz>, Lee Jones <lee.jones@linaro.org>,
	Sebastian Reichel <sre@kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	Linux Input <linux-input@vger.kernel.org>,
	Linux LED Subsystem <linux-leds@vger.kernel.org>,
	Linux PM list <linux-pm@vger.kernel.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>
Subject: Re: [PATCH 10/13] gpio: max77650: add GPIO support
Date: Thu, 24 Jan 2019 11:30:18 +0100	[thread overview]
Message-ID: <CACRpkdacfOLSs1GPew4gMtL_BX0OTXqBQNWzWZMwAkk+Ah2ETQ@mail.gmail.com> (raw)
In-Reply-To: <CAMRc=Me6OSKDk7bN4++M68DjoeArd+gZx16o0oQBXfRoCWBt2A@mail.gmail.com>

On Mon, Jan 21, 2019 at 6:07 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:

> Thank you for your review. While I think you're right about the issue
> being present in this driver, I'm not sure it's really a problem. Do
> we actually require every gpio-controller to also be a stand-alone
> interrupt-controller?

Absolutely not :D

Just GPIO is fine.

> The binding document for the GPIO module doesn't
> mention this - it only requires the gpio-controller property. Without
> the "interrupt-controller" property dtc will bail-out if anyone uses
> this node as the interrupt parent.
>
> If I'm wrong and we do require it, then I think we need to update
> Documentation/devicetree/bindings/gpio/gpio.txt.

What is weird is if a driver with DT bindings not mentioning IRQ
and only probing from DT start implementing IRQ support, that
becomes quite inconsistent. So then max77650_gpio_to_irq()
should just return -ENOTSUPP
or something for now, then it's fine.

We can add the (complicated) IRQ handling later.

I am trying to eat my own dogfood here, I was sweating all
last night trying to implement a hierarchical IRQ controller.
There is no running away from that now. :/

Apparently doing hierarchical IRQs demand that all irq
controllers up to the top-level SoC IRQ controller support
hierarchical interrupts using the v2 version of the irqdomain
API, and currently it seems like the ARM
GIC seems like the only top level IRQ controller that can
do that.

Yours,
Linus Walleij

  reply	other threads:[~2019-01-24 10:30 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-18 13:42 [PATCH 00/13] mfd: add support for max77650 PMIC Bartosz Golaszewski
2019-01-18 13:42 ` [PATCH 01/13] dt-bindings: mfd: add DT bindings for max77650 Bartosz Golaszewski
2019-01-18 13:42 ` [PATCH 02/13] dt-bindings: regulator: " Bartosz Golaszewski
2019-01-18 13:42 ` [PATCH 03/13] dt-bindings: power: supply: " Bartosz Golaszewski
2019-01-18 13:42 ` [PATCH 04/13] dt-bindings: gpio: " Bartosz Golaszewski
2019-01-21 14:04   ` Linus Walleij
2019-01-21 14:04     ` Linus Walleij
2019-01-18 13:42 ` [PATCH 05/13] dt-bindings: leds: " Bartosz Golaszewski
2019-01-20 16:28   ` Jacek Anaszewski
2019-01-18 13:42 ` [PATCH 06/13] dt-bindings: input: " Bartosz Golaszewski
2019-01-18 13:42 ` [PATCH 07/13] mfd: max77650: new core mfd driver Bartosz Golaszewski
2019-01-18 13:42 ` [PATCH 08/13] regulator: max77650: add regulator support Bartosz Golaszewski
2019-01-18 18:01   ` Mark Brown
2019-01-18 18:13     ` Bartosz Golaszewski
2019-01-18 18:36       ` Mark Brown
2019-01-18 18:18     ` Bartosz Golaszewski
2019-01-18 13:42 ` [PATCH 09/13] power: supply: max77650: add support for battery charger Bartosz Golaszewski
2019-01-23 18:27   ` Sebastian Reichel
2019-01-18 13:42 ` [PATCH 10/13] gpio: max77650: add GPIO support Bartosz Golaszewski
2019-01-21 14:20   ` Linus Walleij
2019-01-21 14:20     ` Linus Walleij
2019-01-21 17:07     ` Bartosz Golaszewski
2019-01-21 17:07       ` Bartosz Golaszewski
2019-01-24 10:30       ` Linus Walleij [this message]
2019-01-24 10:30         ` Linus Walleij
2019-01-29 11:00         ` Bartosz Golaszewski
2019-01-29 11:00           ` Bartosz Golaszewski
2019-01-29 13:22           ` Bartosz Golaszewski
2019-01-29 13:22             ` Bartosz Golaszewski
2019-01-18 13:42 ` [PATCH 11/13] leds: max77650: add LEDs support Bartosz Golaszewski
2019-01-20 16:39   ` Jacek Anaszewski
2019-01-18 13:42 ` [PATCH 12/13] input: max77650: add onkey support Bartosz Golaszewski
2019-01-19  9:03   ` Dmitry Torokhov
2019-01-21 10:52     ` Bartosz Golaszewski
2019-01-28 19:22       ` Dmitry Torokhov
2019-02-12 20:34     ` Lee Jones
2019-02-13  7:30       ` Dmitry Torokhov
2019-02-14  9:42         ` Lee Jones
2019-01-18 13:42 ` [PATCH 13/13] MAINTAINERS: add an entry for max77650 mfd driver Bartosz Golaszewski

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=CACRpkdacfOLSs1GPew4gMtL_BX0OTXqBQNWzWZMwAkk+Ah2ETQ@mail.gmail.com \
    --to=linus.walleij@linaro.org \
    --cc=brgl@bgdev.pl \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jacek.anaszewski@gmail.com \
    --cc=lee.jones@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=masneyb@onstation.org \
    --cc=pavel@ucw.cz \
    --cc=robh+dt@kernel.org \
    --cc=sre@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.