From: Lars Povlsen <lars.povlsen@microchip.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Lars Povlsen <lars.povlsen@microchip.com>,
Linus Walleij <linus.walleij@linaro.org>,
Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>,
devicetree <devicetree@vger.kernel.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
"linux-arm Mailing List" <linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Alexandre Belloni <alexandre.belloni@bootlin.com>
Subject: Re: [PATCH v6 2/3] pinctrl: pinctrl-microchip-sgpio: Add pinctrl driver for Microsemi Serial GPIO
Date: Mon, 26 Oct 2020 15:41:48 +0100 [thread overview]
Message-ID: <87blgp9hhv.fsf@soft-dev15.microsemi.net> (raw)
In-Reply-To: <CAHp75Vdd6ECJaWytYVz+5GYZrwybzZmviUOt3H=t-4LH=_idKg@mail.gmail.com>
Hi Andy!
Andy Shevchenko writes:
> On Wed, Oct 14, 2020 at 6:25 PM Lars Povlsen <lars.povlsen@microchip.com> wrote:
>>
>> This adds a pinctrl driver for the Microsemi/Microchip Serial GPIO
>> (SGPIO) device used in various SoC's.
>
> ...
>
>> +#define PIN_NAM_SZ (sizeof("SGPIO_D_pXXbY")+1)
>
> +1 for what?
>
Reverse fencepost :-). I'll remove it.
> ...
>
>> +#define __shf(x) (__builtin_ffsll(x) - 1)
>> +#define __BF_PREP(bf, x) (bf & ((x) << __shf(bf)))
>> +#define __BF_GET(bf, x) (((x & bf) >> __shf(bf)))
>
> This smells like bitfield.h.
>
Yes, and I would use it if I could, just bitfield.h don't like anything
but constexpr. The driver support 3 SoC variants which (unfortunately)
have different register layouts in some areas.
> ...
>
>> +static int sgpio_input_get(struct sgpio_priv *priv,
>> + struct sgpio_port_addr *addr)
>> +{
>
>> + int ret;
>> +
>> + ret = !!(sgpio_readl(priv, REG_INPUT_DATA, addr->bit) &
>> + BIT(addr->port));
>> +
>> + return ret;
>
> Sounds like one line.
>
Yes, I'll change that.
>> +}
>
>> +static int sgpio_get_functions_count(struct pinctrl_dev *pctldev)
>> +{
>
>> + return 1;
>
> I didn't get why it's not a pure GPIO driver?
> It has only one function (no pinmux).
> I didn't find any pin control features either.
>
> What did I miss?
The hardware has more functions, which are planned to be added
later. This has already been agreed with Linux Walleij.
>
> ...
>
>> +static int microchip_sgpio_get_value(struct gpio_chip *gc, unsigned int gpio)
>> +{
>> + struct sgpio_bank *bank = gpiochip_get_data(gc);
>> + struct sgpio_priv *priv = bank->priv;
>> + struct sgpio_port_addr addr;
>
>> + int ret;
>
> No need.
Ok, I'll trim it.
>
>> +
>> + sgpio_pin_to_addr(priv, gpio, &addr);
>> +
>> + if (bank->is_input)
>> + ret = sgpio_input_get(priv, &addr);
>> + else
>> + ret = sgpio_output_get(priv, &addr);
>> +
>> + return ret;
>> +}
>
>
> ...
>
>
>> + ret = devm_gpiochip_add_data(dev, gc, bank);
>> + if (ret == 0)
>
>> + dev_info(dev, "Registered %d GPIOs\n", ngpios);
>
> No noise.
>
OK, gone.
>> + else
>> + dev_err(dev, "Failed to register: ret %d\n", ret);
>> +
>
> ...
>
>> + /* Get register map */
>> + regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + priv->regs = devm_ioremap_resource(dev, regs);
>
> devm_platform_ioremap_resource();
Yes, I'll replace with that.
>
>> + if (IS_ERR(priv->regs))
>> + return PTR_ERR(priv->regs);
>
>> + priv->properties = of_device_get_match_data(dev);
>
> It's interesting you have a mix between OF APIs and device property
> APIs. Choose one. If you stick with OF, use of_property_ and so,
> otherwise replace of_*() by corresponding device_*() or generic calls.
Sure. I will change the device_property_read_u32() with
of_property_read_u32().
>
> Can you use gpio-regmap APIs?
No, I think the sgpio hardware is a little too odd for that
(of_gpio_n_cells == 3). And then there's alternate pinctrl functions.
Thank you for your comments, they are very much appreciated. Let me know
if I missed anything.
I will refresh the series shortly (on v5.10-rc1).
---Lars
--
Lars Povlsen,
Microchip
next prev parent reply other threads:[~2020-10-26 14:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-14 10:07 [PATCH v6 0/3] Adding support for Microchip/Microsemi serial GPIO controller Lars Povlsen
2020-10-14 10:07 ` [PATCH v6 1/3] dt-bindings: pinctrl: Add bindings for pinctrl-microchip-sgpio driver Lars Povlsen
2020-10-14 10:07 ` [PATCH v6 2/3] pinctrl: pinctrl-microchip-sgpio: Add pinctrl driver for Microsemi Serial GPIO Lars Povlsen
2020-10-16 14:34 ` Andy Shevchenko
2020-10-26 14:41 ` Lars Povlsen [this message]
2020-10-14 10:07 ` [PATCH v6 3/3] arm64: dts: sparx5: Add SGPIO devices Lars Povlsen
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=87blgp9hhv.fsf@soft-dev15.microsemi.net \
--to=lars.povlsen@microchip.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=alexandre.belloni@bootlin.com \
--cc=andy.shevchenko@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.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).