linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Conor Dooley <conor.dooley@microchip.com>, linux-kernel@vger.kernel.org
Cc: conor@kernel.org, Marc Zyngier <maz@kernel.org>,
	Daire McNamara <daire.mcnamara@microchip.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Bartosz Golaszewski <brgl@bgdev.pl>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	linux-riscv@lists.infradead.org, linux-gpio@vger.kernel.org,
	devicetree@vger.kernel.org
Subject: Re: [RFC v7 1/6] dt-bindings: gpio: fix microchip,mpfs-gpio interrupt descriptions
Date: Wed, 24 Jul 2024 15:25:38 +0200	[thread overview]
Message-ID: <b07538f3-44e4-4d98-b64d-0d15428e720f@kernel.org> (raw)
In-Reply-To: <20240723-trash-issuing-e2bdd55b764e@wendy>

On 23/07/2024 13:27, Conor Dooley wrote:
> The microchip,mpfs-gpio binding suffered greatly due to being written
> with a narrow minded view of the controller, and the interrupt bits
> ended up incorrect. It was mistakenly assumed that the interrupt
> configuration was set by platform firmware, based on the FPGA
> configuration, and that the GPIO DT nodes were the only way to really
> communicate interrupt configuration to software.
> 
> Instead, the mux should be a device in its own right, and the GPIO
> controllers should be connected to it, rather than to the PLIC.
> Now that a binding exists for that mux, try to fix the misconceptions
> in the GPIO controller binding.
> 
> Firstly, it's not possible for this controller to have fewer than 14
> GPIOs, and thus 14 interrupts also. There are three controllers, with
> 14, 24 & 32 GPIOs each.
> 
> The example is wacky too - it follows from the incorrect understanding
> that the GPIO controllers are connected to the PLIC directly. They are
> not however, with a mux sitting in between. Update the example to use
> the mux as a parent, and the interrupt numbers at the mux for GPIO2 as
> the example - rather than the strange looking, repeated <53>.
> 

You make ngpios required, which could be an ABI break except that there
is no Linux user for this, so there is no ABI break, right? If so, would
be nice to mention it. Rest looks good:

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Best regards,
Krzysztof


  reply	other threads:[~2024-07-24 13:25 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-23 11:27 [RFC v7 0/6] PolarFire SoC GPIO support Conor Dooley
2024-07-23 11:27 ` [RFC v7 1/6] dt-bindings: gpio: fix microchip,mpfs-gpio interrupt descriptions Conor Dooley
2024-07-24 13:25   ` Krzysztof Kozlowski [this message]
2024-07-24 14:29     ` Conor Dooley
2024-07-23 11:27 ` [RFC v7 2/6] dt-bindings: interrupt-controller: document PolarFire SoC's gpio interrupt mux Conor Dooley
2024-07-24 13:27   ` Krzysztof Kozlowski
2024-07-24 14:21     ` Conor Dooley
2024-07-23 11:27 ` [RFC v7 3/6] irqchip: add mpfs " Conor Dooley
2024-07-29 10:41   ` Thomas Gleixner
2024-08-01 15:09     ` Conor Dooley
2024-08-01 18:49       ` Thomas Gleixner
2024-08-02  8:08         ` Conor Dooley
2024-08-02 10:40           ` Thomas Gleixner
2024-07-23 11:27 ` [RFC v7 4/6] gpio: mpfs: add polarfire soc gpio support Conor Dooley
2024-08-05  8:00   ` Linus Walleij
2024-08-05  8:04   ` Linus Walleij
2024-08-06 17:18     ` Conor Dooley
2024-08-07 16:55       ` Linus Walleij
2024-08-07 17:22         ` Conor Dooley
2024-10-16  9:56     ` Conor Dooley
2024-10-16 10:29       ` Conor Dooley
2024-10-16 19:26         ` Linus Walleij
2024-10-16 19:42           ` Conor Dooley
2024-10-22 16:28             ` Conor Dooley
2024-10-23  9:58               ` Linus Walleij
2024-10-16 19:25       ` Linus Walleij
2024-07-23 11:27 ` [RFC v7 5/6] gpio: mpfs: pass gpio line number as irq data Conor Dooley
2024-08-05  8:11   ` Linus Walleij
2024-08-06 17:24     ` Conor Dooley
2024-07-23 11:27 ` [RFC v7 6/6] riscv: dts: microchip: update gpio interrupts to better match the SoC Conor Dooley

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=b07538f3-44e4-4d98-b64d-0d15428e720f@kernel.org \
    --to=krzk@kernel.org \
    --cc=brgl@bgdev.pl \
    --cc=conor.dooley@microchip.com \
    --cc=conor@kernel.org \
    --cc=daire.mcnamara@microchip.com \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=robh@kernel.org \
    --cc=tglx@linutronix.de \
    /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).