From: "Mathieu Dubois-Briand" <mathieu.dubois-briand@bootlin.com>
To: "Andy Shevchenko" <andriy.shevchenko@intel.com>
Cc: "Lee Jones" <lee@kernel.org>, "Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Kamel Bouhara" <kamel.bouhara@bootlin.com>,
"Linus Walleij" <linus.walleij@linaro.org>,
"Bartosz Golaszewski" <brgl@bgdev.pl>,
"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
"Uwe Kleine-König" <ukleinek@kernel.org>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-input@vger.kernel.org,
linux-pwm@vger.kernel.org,
"Grégory Clement" <gregory.clement@bootlin.com>,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH v3 4/7] gpio: max7360: Add MAX7360 gpio support
Date: Wed, 12 Feb 2025 17:08:56 +0100 [thread overview]
Message-ID: <D7QLITNTXRUJ.3NA44E6PQMAUX@bootlin.com> (raw)
In-Reply-To: <Z6y65SnrprvnpKEa@smile.fi.intel.com>
On Wed Feb 12, 2025 at 4:14 PM CET, Andy Shevchenko wrote:
> On Wed, Feb 12, 2025 at 01:57:34PM +0100, Mathieu Dubois-Briand wrote:
> > On Mon Jan 27, 2025 at 2:07 PM CET, Andy Shevchenko wrote:
> > > On Mon, Jan 13, 2025 at 01:42:28PM +0100, Mathieu Dubois-Briand wrote:
>
> ...
>
> > > > + parent = to_platform_device(pdev->dev.parent);
> > >
> > > Why do you need this? Can't the fwnode be propagated to the children and then
> > > the respective APIs to be used?
> >
> > I'm not sure to understand this correctly, what do you mean by
> > propagating the fwnode to the children?
> >
> > Just a quick summary of the situation and what I try to do. The device
> > tree looks like this, only keeping the interesting properties:
> >
> > io-expander@38 {
> > ...
> > interrupts = <23 IRQ_TYPE_LEVEL_LOW>,
> > <24 IRQ_TYPE_LEVEL_LOW>;
> > interrupt-names = "inti", "intk";
> >
> > max7360_gpio: gpio {
> > ...
> > };
> >
> > max7360_gpo: gpo {
> > ...
> > };
> > };
> >
> > Our pdev fwnode points either to the "gpio" or "gpo" nodes, the one from
> > our parent device points to "io-expander@38". Here we need to get the
> > "inti" interrupt from the parent node. What would be the correct way to
> > do it?
>
> Ah, I see now. This is being used only for IRQs, but don't you want to call
> actually fwnode_irq_get_byname()? It will makes the intention clearer.
>
Sure! I can definitely call fwnode_irq_get_byname().
>
> > > > + if (of_property_read_u32(pdev->dev.of_node, "ngpios", &ngpios)) {
> > > > + dev_err(&pdev->dev, "Missing ngpios OF property\n");
> > > > + return -ENODEV;
> > > > + }
> > >
> > > This is not needed, it is already done in GPIOLIB core.
> >
> > I believe this is still needed:
> > - For gpos, we need the gpio count to correctly set the partition
> > between gpo and keypad columns in max7360_set_gpos_count().
>
> Shouldn't be that done somewhere in the GPIO valid mask initialisation?
>
> > - For gpios, we need the gpio count to setup the IRQs.
>
> Doesn't GPIOLIB parse the property before initializing the IRQ valid mask
> and other init callbacks?
No, I believe I have to register the IRQ before registering the GPIO, so
I can get the IRQ domain.
Right now I have something like:
irq_chip->num_irqs = ngpios;
devm_regmap_add_irq_chip_fwnode(dev, dev_fwnode(dev), max7360_gpio->regmap, irq, flags, 0, irq_chip, &irq_chip_data);
gpio_config.irq_domain = regmap_irq_get_domain(irq_chip_data);
devm_gpio_regmap_register(dev, &gpio_config);
Also, gpiolib will store ngpios in the gpio_chip structure, but while
using gpio-regmap, this structure is masked behind the opaque
gpio_regmap structure. So I believe there is no easy way to retrieve its
value.
This part of the code changed a lot, maybe it would be easier if I push
a new version of the series and we continue the discussion there?
--
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2025-02-12 16:08 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-13 12:42 [PATCH v3 0/7] Add support for MAX7360 Mathieu Dubois-Briand
2025-01-13 12:42 ` [PATCH v3 1/7] dt-bindings: mfd: gpio: Add MAX7360 Mathieu Dubois-Briand
2025-01-14 8:11 ` Krzysztof Kozlowski
2025-01-14 13:02 ` Mathieu Dubois-Briand
2025-01-13 12:42 ` [PATCH v3 2/7] mfd: Add max7360 support mathieu.dubois-briand
2025-01-15 15:42 ` Lee Jones
2025-01-17 10:38 ` Mathieu Dubois-Briand
2025-01-13 12:42 ` [PATCH v3 3/7] pwm: max7360: Add MAX7360 PWM support mathieu.dubois-briand
2025-01-17 9:33 ` Uwe Kleine-König
2025-01-17 14:11 ` Mathieu Dubois-Briand
2025-01-17 14:40 ` Uwe Kleine-König
2025-01-17 15:47 ` Mathieu Dubois-Briand
2025-01-20 14:13 ` Uwe Kleine-König
2025-01-22 12:37 ` Mathieu Dubois-Briand
2025-01-13 12:42 ` [PATCH v3 4/7] gpio: max7360: Add MAX7360 gpio support Mathieu Dubois-Briand
2025-01-14 14:33 ` Linus Walleij
2025-01-14 17:57 ` Mathieu Dubois-Briand
2025-01-17 15:22 ` Mathieu Dubois-Briand
2025-01-22 13:18 ` Linus Walleij
2025-01-27 12:52 ` Andy Shevchenko
2025-01-27 13:07 ` Andy Shevchenko
2025-02-12 12:57 ` Mathieu Dubois-Briand
2025-02-12 15:14 ` Andy Shevchenko
2025-02-12 16:08 ` Mathieu Dubois-Briand [this message]
2025-02-12 16:17 ` Andy Shevchenko
2025-02-13 10:59 ` Mathieu Dubois-Briand
2025-02-13 13:45 ` Mathieu Dubois-Briand
2025-02-13 19:47 ` Andy Shevchenko
2025-02-14 8:42 ` Mathieu Dubois-Briand
2025-01-13 12:42 ` [PATCH v3 5/7] input: keyboard: Add support for MAX7360 keypad Mathieu Dubois-Briand
2025-01-13 12:42 ` [PATCH v3 6/7] input: misc: Add support for MAX7360 rotary Mathieu Dubois-Briand
2025-01-14 13:16 ` Mathieu Dubois-Briand
2025-01-13 12:42 ` [PATCH v3 7/7] MAINTAINERS: Add entry on MAX7360 driver Mathieu Dubois-Briand
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=D7QLITNTXRUJ.3NA44E6PQMAUX@bootlin.com \
--to=mathieu.dubois-briand@bootlin.com \
--cc=andriy.shevchenko@intel.com \
--cc=brgl@bgdev.pl \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=gregory.clement@bootlin.com \
--cc=kamel.bouhara@bootlin.com \
--cc=krzk+dt@kernel.org \
--cc=lee@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=robh@kernel.org \
--cc=thomas.petazzoni@bootlin.com \
--cc=ukleinek@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).