From: andy.shevchenko@gmail.com
To: Nikita Shubin <nikita.shubin@maquefel.me>
Cc: Alexander Sverdlin <alexander.sverdlin@gmail.com>,
Arnd Bergmann <arnd@arndb.de>,
Linus Walleij <linus.walleij@linaro.org>,
Hartley Sweeten <hsweeten@visionengravers.com>,
Russell King <linux@armlinux.org.uk>,
Lukasz Majewski <lukma@denx.de>,
Bartosz Golaszewski <brgl@bgdev.pl>,
Michael Peters <mpeters@embeddedts.com>,
Kris Bahnsen <kris@embeddedts.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org
Subject: Re: [PATCH v1 01/43] gpio: ep93xx: split device in multiple
Date: Fri, 2 Jun 2023 04:50:44 +0300 [thread overview]
Message-ID: <ZHlK9EkHlLD7DDG7@surfacebook> (raw)
In-Reply-To: <20230601053546.9574-2-nikita.shubin@maquefel.me>
Thu, Jun 01, 2023 at 08:33:52AM +0300, Nikita Shubin kirjoitti:
> This prepares ep93xx SOC gpio to convert into device tree driver:
> - dropped banks and legacy defines
> - split AB IRQ and make it shared
>
> We are relying on IRQ number information A, B ports have single shared
> IRQ, while F port have dedicated IRQ for each line.
>
> Also we had to split single ep93xx platform_device into multiple, one
> for each port, without this we can't do a full working transition from
> legacy platform code into device tree capable. All GPIO_LOOKUP were
> change to match new chip namings.
First of all, check if you added In-Reply-to email header to the previous
thread, at least `b4` downloaded 188 messages in this one so far. Second,
the previous was kinda v0, while we usually assume that non-versioned series
is v1. This is a bit ambiguous.
...
> + GPIO_LOOKUP_IDX("gpio-ep93xx.4", 1, NULL, 1, GPIO_ACTIVE_HIGH),
TAB used instead of space.
...
> struct device __init *ep93xx_init_devices(void)
> {
> struct device *parent;
> + int i;
It's unsigned, right?
> + for (i = 0; i < ARRAY_SIZE(ep93xx_gpio_device); i++)
> + platform_device_register(ep93xx_gpio_device[i]);
...
> writeb(eic->int_debounce,
> - epg->base + eic->irq_offset + EP93XX_INT_DEBOUNCE_OFFSET);
> + eic->base + EP93XX_INT_DEBOUNCE_OFFSET);
Now this can be a single line. Also some other cases may be optimized.
...
> + void __iomem *intr = devm_platform_ioremap_resource_byname(pdev, "intr");
It's less error prone if the assignment is split from definition and moved
closer to its (first) user...
> +
...here.
> + if (IS_ERR(intr))
> + return PTR_ERR(intr);
...
> + egc->eic = devm_kcalloc(dev, 1,
> + sizeof(*egc->eic),
> + GFP_KERNEL);
Why kcalloc(1), is this a part that will be (slightly) modified in the next
patches in the series?
> + if (!egc->eic)
> + return -ENOMEM;
>
...
> + irq = platform_get_irq(pdev, 0);
No return value check?
> + ret = devm_request_irq(dev, irq,
> + ep93xx_ab_irq_handler,
> + IRQF_SHARED, gc->label, gc);
> + if (ret) {
> + dev_err(dev, "error requesting IRQ : %d\n", irq);
> + return ret;
If it's soslely part of the ->probe() flow, you may use dev_err_probe().
> + }
>
> + girq->parents[0] = irq;
...
> for (i = 0; i < girq->num_parents; i++) {
> + irq = platform_get_irq(pdev, i);
> + if (irq <= 0)
== 0 is never happen case. Why?
> + continue;
> +
> + girq->parents[i] = irq;
> }
> + ret = bgpio_init(gc, &pdev->dev, 1, data, NULL, NULL, dir, NULL, 0);
> + if (ret) {
> + dev_err(&pdev->dev, "unable to init generic GPIO\n");
> + return ret;
return dev_err_probe(...);
> }
...
> + if (platform_irq_count(pdev) > 0) {
Do you need this check?
> + dev_dbg(&pdev->dev, "setting up irqs for %s\n", dev_name(&pdev->dev));
> + ret = ep93xx_setup_irqs(pdev, egc);
> + if (ret)
> + dev_err(&pdev->dev, "setup irqs failed for %s\n", dev_name(&pdev->dev));
If it's an error, why continuing?
> + }
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2023-06-02 1:50 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-24 12:34 [PATCH 00/43] ep93xx device tree conversion Nikita Shubin
2023-04-24 11:31 ` Arnd Bergmann
[not found] ` <20230424152933.48b2ede1@kernel.org>
2023-04-25 9:20 ` Krzysztof Kozlowski
2023-04-25 13:27 ` Arnd Bergmann
2023-04-24 12:34 ` [PATCH 01/43] gpio: ep93xx: split device in multiple Nikita Shubin
2023-04-24 12:34 ` [PATCH 03/43] dt-bindings: pinctrl: Add DT bindings ep93xx pinctrl Nikita Shubin
2023-04-24 13:28 ` Rob Herring
2023-04-25 9:24 ` Krzysztof Kozlowski
2023-04-24 12:34 ` [PATCH 04/43] pinctrl: add a Cirrus ep93xx SoC pin controller Nikita Shubin
2023-04-24 12:34 ` [PATCH 32/43] dt-bindings: gpio: Add DT bindings ep93xx gpio Nikita Shubin
2023-04-24 16:32 ` Rob Herring
2023-04-26 20:48 ` Linus Walleij
2023-04-28 14:44 ` Nikita Shubin
2023-04-24 12:34 ` [PATCH 33/43] gpio: ep93xx: add DT support for gpio-ep93xx Nikita Shubin
2023-06-16 9:18 ` Bartosz Golaszewski
2023-06-16 12:37 ` Nikita Shubin
2023-04-26 20:56 ` [PATCH 00/43] ep93xx device tree conversion Linus Walleij
[not found] ` <b5396ef5-3fed-4e98-8f37-a9cd4473bddc@sirena.org.uk>
2023-04-26 21:06 ` Linus Walleij
2023-05-16 3:47 ` Florian Fainelli
2023-05-16 10:37 ` Nikita Shubin
2023-06-01 5:33 ` [PATCH v1 01/43] gpio: ep93xx: split device in multiple Nikita Shubin
2023-06-02 1:50 ` andy.shevchenko [this message]
2023-06-15 16:56 ` Nikita Shubin
2023-06-01 5:33 ` [PATCH v1 06/43] dt-bindings: pinctrl: Add Cirrus EP93xx Nikita Shubin
2023-06-01 6:42 ` Krzysztof Kozlowski
2023-06-01 5:33 ` [PATCH v1 07/43] pinctrl: add a Cirrus ep93xx SoC pin controller Nikita Shubin
2023-06-03 19:58 ` andy.shevchenko
2023-06-01 5:45 ` [PATCH v1 33/43] dt-bindings: gpio: Add Cirrus EP93xx Nikita Shubin
2023-06-01 8:20 ` Krzysztof Kozlowski
2023-06-02 7:40 ` Linus Walleij
2023-06-13 14:55 ` Bartosz Golaszewski
2023-06-13 18:09 ` Linus Walleij
2023-06-16 9:15 ` Bartosz Golaszewski
2023-06-01 5:45 ` [PATCH v1 34/43] gpio: ep93xx: add DT support for gpio-ep93xx Nikita Shubin
2023-06-02 7:30 ` Linus Walleij
2023-06-03 20:07 ` andy.shevchenko
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=ZHlK9EkHlLD7DDG7@surfacebook \
--to=andy.shevchenko@gmail.com \
--cc=alexander.sverdlin@gmail.com \
--cc=arnd@arndb.de \
--cc=brgl@bgdev.pl \
--cc=hsweeten@visionengravers.com \
--cc=kris@embeddedts.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=lukma@denx.de \
--cc=mpeters@embeddedts.com \
--cc=nikita.shubin@maquefel.me \
/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).