devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Bianconi <lorenzo@kernel.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Sean Wang" <sean.wang@kernel.org>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"AngeloGioacchino Del Regno"
	<angelogioacchino.delregno@collabora.com>,
	"Lee Jones" <lee@kernel.org>,
	"Uwe Kleine-König" <ukleinek@kernel.org>,
	linux-mediatek@lists.infradead.org, linux-gpio@vger.kernel.org,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	upstream@airoha.com, benjamin.larsson@genexis.eu,
	ansuelsmth@gmail.com, linux-pwm@vger.kernel.org
Subject: Re: [PATCH v4 4/5] pinctrl: airoha: Add support for EN7581 SoC
Date: Wed, 2 Oct 2024 17:36:38 +0200	[thread overview]
Message-ID: <Zv1ohibsTelBBMc9@lore-desk> (raw)
In-Reply-To: <CACRpkdbXWMU+wq6DvviCQPQ0EzKUm9oOnyFh34Bm=Y8K-HmT0Q@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3332 bytes --]

> Hi Lorenzo,
> 
> so these comments:
> 
> On Tue, Sep 24, 2024 at 12:12 PM Lorenzo Bianconi <lorenzo@kernel.org> wrote:
> 
> > > > +#include <linux/pinctrl/consumer.h>
> > >
> > > Why do you need the consumer header?
> >
> > we need it for pinctrl_gpio_direction_output() and
> > pinctrl_gpio_direction_input() for direction_input and direction_output
> > callbacks.
> 
> I looked it over again and it looks good, I was just confused.

ack, no worries.

> 
> > > > +               arg = airoha_pinctrl_gpio_get_direction(pinctrl, gpio);
> > >
> > > I don't see why a pin would have to exist in a GPIO range in order to
> > > be set as output or input?
> > >
> > > Can't you just set up the pin as requested and not care whether
> > > it has a corresponding GPIO range?
> > >
> > > Is it over-reuse of the GPIO code? I'd say just set up the pin instead.
> >
> > Do you mean to get rid of PIN_CONFIG_OUTPUT_ENABLE, PIN_CONFIG_INPUT_ENABLE
> > (and even PIN_CONFIG_OUTPUT in airoha_pinconf_set()) here?
> > E.g. we need PIN_CONFIG_OUTPUT_ENABLE to enable pwm for pwm-leds:
> 
> I was mainly thinking that the
> airoha_pinctrl_gpio_get_direction() is limited to pins that are
> used for GPIO.
> 
> The callback should be usable on any pins, no matter if they
> can be muxed to GPIO or not?
> 
> > &mfd {
> >         ...
> >         pio: pinctrl {
> >                 ...
> >                 pwm_gpio18_idx10_pins: pwm-gpio18-idx10-pins {
> >                         function = "pwm";
> >                         pins = "gpio18";
> >                         output-enable;
> >                 };
> >         };
> > };
> 
> Like this one.
> 
> Which I think works.
> 
> It's the name of the function which confuses me:
> airoha_pinctrl_gpio_get_direction() and anything else that
> is used directly from the airoha_pinconf_set() function
> doesn't really care if the pin is used as GPIO or not does
> it?
> 
> Can you rename the functions just e.g. airoha_pinctrl_get_direction()
> because it has nothing to do with GPIO. It's jus pin control.

ack, I will do in v6

> 
> Also some defines are confusing this way:
> 
> +       /* set output enable */
> +       mask = BIT(gpio % AIROHA_GPIO_BANK_SIZE);
> +       index = gpio / AIROHA_GPIO_BANK_SIZE;
> +       airoha_pinctrl_rmw(pinctrl, pinctrl->gpiochip.out[index],
> +                          mask, !input ? mask : 0);
> 
> Variables named "gpio" and AIROHA_GPIO_BANK_SIZE despite
> it is used for pins that are not (in the Linux sense) GPIO all the time.
> This is a big confusion for the mind.
> 
> Can you rename the variable from "gpio" to "pin" or so
> and the AIROHA_GPIO_BANK_SIZE to AIROHA_PIN_BANK_SIZE
> etc so it is clear what is going on?

ack, I will do in v6

> 
> I understand that the datasheet might be talking about
> "GPIO this and GPIO that" but what hardware engineers mean
> with GPIO is something else than what Linux mean: for them
> it means "it can be muxed so it is kinda-general-purpose-kinda"
> but in Linux this has a strict meaning: it can be used by the
> gpiolib to control individual lines.
> 
> I think this would make it easier for me (and possibly others)
> ton understand the driver.

ack.

Regards,
Lorenzo

> 
> Yours,
> Linus Walleij

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2024-10-02 15:36 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-11 19:50 [PATCH v4 0/5] Add mfd, pinctrl and pwm support to EN7581 SoC Lorenzo Bianconi
2024-09-11 19:50 ` [PATCH v4 1/5] dt-bindings: arm: airoha: Add the chip-scu node for " Lorenzo Bianconi
2024-09-11 21:12   ` Rob Herring (Arm)
2024-09-11 21:46     ` Lorenzo Bianconi
2024-09-12 16:43       ` Rob Herring
2024-09-11 19:50 ` [PATCH v4 2/5] dt-bindings: mfd: Add support for Airoha EN7581 GPIO System Controller Lorenzo Bianconi
2024-09-11 21:12   ` Rob Herring (Arm)
2024-09-11 21:48     ` Lorenzo Bianconi
2024-09-12 16:44   ` Rob Herring (Arm)
2024-09-11 19:50 ` [PATCH v4 3/5] mfd: airoha: Add support for Airoha EN7581 MFD Lorenzo Bianconi
2024-09-11 19:50 ` [PATCH v4 4/5] pinctrl: airoha: Add support for EN7581 SoC Lorenzo Bianconi
2024-09-24  7:34   ` Linus Walleij
2024-09-24 10:12     ` Lorenzo Bianconi
2024-09-24 21:22       ` Lorenzo Bianconi
2024-10-02 12:58       ` Linus Walleij
2024-10-02 15:36         ` Lorenzo Bianconi [this message]
2024-09-11 19:50 ` [PATCH v4 5/5] pwm: " Lorenzo Bianconi
2024-09-23  9:53 ` [PATCH v4 0/5] Add mfd, pinctrl and pwm support to " Christian Marangi
2024-09-25  9:47   ` Lee Jones
2024-09-25  9:51     ` Christian Marangi

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=Zv1ohibsTelBBMc9@lore-desk \
    --to=lorenzo@kernel.org \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=ansuelsmth@gmail.com \
    --cc=benjamin.larsson@genexis.eu \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=lee@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=matthias.bgg@gmail.com \
    --cc=robh@kernel.org \
    --cc=sean.wang@kernel.org \
    --cc=ukleinek@kernel.org \
    --cc=upstream@airoha.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).