From: Javier Arteaga <javier@emutex.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Dan O'Donovan <dan@emutex.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Lee Jones <lee.jones@linaro.org>,
Jacek Anaszewski <jacek.anaszewski@gmail.com>,
Pavel Machek <pavel@ucw.cz>,
linux-gpio@vger.kernel.org, linux-leds@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH RESEND 3/3] pinctrl: upboard: Add UP2 pinctrl and gpio driver
Date: Thu, 26 Apr 2018 03:38:36 +0100 [thread overview]
Message-ID: <20180426023836.udbeoocp76tsv7vu@localhost> (raw)
In-Reply-To: <1524674952.21176.610.camel@linux.intel.com>
On Wed, Apr 25, 2018 at 07:49:12PM +0300, Andy Shevchenko wrote:
> > For reference, here's the relevant ASL from the UP2 platform
> > controller.
>
> It should be in Documentation file or in commit message.
Perfect, I just wasn't sure whether dumping ASL this way would be
acceptable in commit history. In that case, I think I prefer the commit
body over keeping a Documentation/ file elsewhere that's easy to miss.
> > static const struct mfd_cell upboard_up2_mfd_cells[] = {
> > + { .name = "upboard-pinctrl" },
>
> I guess it should be 3 lines.
>
> > UPBOARD_LED_CELL(upboard_up2_led_data, 0),
> > UPBOARD_LED_CELL(upboard_up2_led_data, 1),
> > UPBOARD_LED_CELL(upboard_up2_led_data, 2),
>
> ...and honestly I would not use this macro and put 4 cells explicitly
> here.
The idea was to avoid repeating .platform_data + .pdata_size over and
over as there's a few LEDs per board, but explicit is good too.
May just go with your suggestion as that seems to be more popular than
macros in other mfd drivers.
> > +static int upboard_gpio_request_enable(struct pinctrl_dev *pctldev,
> > + struct pinctrl_gpio_range
> > *range,
> > + unsigned int pin)
> > +{
> > + const struct pin_desc * const pd = pin_desc_get(pctldev,
> > pin);
> > + const struct upboard_pin *p;
> > + int ret;
> > +
>
> > + if (!pd)
> > + return -EINVAL;
>
> When it's possible?
Just reread pin_request() from pinctrl core. You're right, it isn't.
I'll take out the check.
> > + if (!pd)
> > + return -EINVAL;
>
> Ditto.
As above.
>
> > + struct upboard_pinctrl *pctrl =
> > + container_of(gc, struct upboard_pinctrl, chip);
>
> Do define and use to_upboard_pinctrl().
Will do.
> > + if (offset + 1 > pctrl->nsoc_gpios || !pctrl-
> > >soc_gpios[offset])
> > + return ERR_PTR(-ENODEV);
>
> When this is a case?
Another unnecessary check if gpiolib already guarantees valid inputs.
> > +static int upboard_gpio_get_direction(struct gpio_chip *gc, unsigned
> > int offset)
> > +{
> > + struct gpio_desc *desc = upboard_offset_to_soc_gpio(gc,
> > offset);
> > +
>
> Split above to definition and assignment pieces. Put assignment
> immediately before condition.
>
> > + if (IS_ERR(desc))
> > + return PTR_ERR(desc);
I'll do that.
> > +static struct regmap_field * __init upboard_field_alloc(struct device
> > *dev,
> > + struct regmap
> > *regmap,
> > + unsigned int
> > base,
> > + unsigned int
> > number)
>
> You should really understand what __init means and when it's appropriate
> to use it.
As in the other email: the intention was to drop probe() and funcs only
used on module init, but I appear to have misunderstood something here.
> > +static int __init upboard_pinctrl_probe(struct platform_device *pdev)
> > +{
> > + struct acpi_device * const adev = ACPI_COMPANION(&pdev->dev);
>
> Huh, const in that place? Why?
You're right, it isn't a usual pattern. Dropped.
> > + if (!pdev->dev.parent)
> > + return -EINVAL;
> > +
> > + upboard = dev_get_drvdata(pdev->dev.parent);
> > + if (!upboard)
> > + return -EINVAL;
>
> Same comment as per LED driver.
I'll address that too.
> > + if (strcmp(acpi_device_hid(adev), "AANT0F01"))
> > + return -ENODEV;
>
> Huh?
Ugh, this is left over from a bit of code that selected the right
pinctrl_desc* for each UP HID. Of course, it doesn't make sense now.
I'll take that out.
> > + ((struct pinctrl_pin_desc *)pd)->drv_data = pin;
>
> What is that?! I mean ugly casting.
I agree, it's an eyesore. The intention was to drop const from
pinctrl_desc->pins as we're replacing the pins' drv_data on init.
It does look like I'm going at this the wrong way though. I'll take
another stab at it (pointers welcome of course).
> > +MODULE_LICENSE("GPL");
>
> License mismatch.
Will fix.
Thanks again for your time Andy! I really appreciate your help :)
next prev parent reply other threads:[~2018-04-26 2:38 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-21 8:50 [RFC PATCH RESEND 0/3] UP Squared board drivers Javier Arteaga
2018-04-21 8:50 ` [RFC PATCH RESEND 1/3] mfd: upboard: Add UP2 platform controller driver Javier Arteaga
2018-04-25 9:51 ` Mika Westerberg
2018-04-25 12:05 ` Javier Arteaga
2018-04-25 15:57 ` Andy Shevchenko
2018-04-26 2:33 ` Javier Arteaga
2018-04-21 8:50 ` [RFC PATCH RESEND 2/3] leds: upboard: Add LED support Javier Arteaga
2018-04-25 6:41 ` Pavel Machek
2018-04-25 7:02 ` Javier Arteaga
2018-04-25 7:04 ` Pavel Machek
2018-04-25 16:15 ` Andy Shevchenko
2018-04-26 2:34 ` Javier Arteaga
2018-04-26 7:55 ` Andy Shevchenko
2018-04-26 12:49 ` Javier Arteaga
2018-05-02 13:55 ` Andy Shevchenko
2018-04-26 7:34 ` Lee Jones
2018-04-26 13:03 ` Javier Arteaga
2018-04-27 7:38 ` Lee Jones
2018-04-21 8:50 ` [RFC PATCH RESEND 3/3] pinctrl: upboard: Add UP2 pinctrl and gpio driver Javier Arteaga
2018-04-25 16:49 ` Andy Shevchenko
2018-04-26 2:38 ` Javier Arteaga [this message]
2018-04-26 6:50 ` Lee Jones
2018-04-26 13:36 ` Javier Arteaga
2018-04-25 9:53 ` [RFC PATCH RESEND 0/3] UP Squared board drivers Mika Westerberg
2018-10-19 17:15 ` [PATCH v2 " Dan O'Donovan
2018-10-19 17:15 ` [PATCH v2 1/3] mfd: upboard: Add UP2 platform controller driver Dan O'Donovan
2018-10-20 11:49 ` Andy Shevchenko
2018-10-25 11:05 ` Lee Jones
2018-10-25 13:15 ` Andy Shevchenko
2018-10-31 20:40 ` Dan O'Donovan
2018-10-19 17:15 ` [PATCH v2 2/3] leds: upboard: Add LED support Dan O'Donovan
2018-10-20 11:17 ` Andy Shevchenko
2018-10-21 8:31 ` Pavel Machek
2018-10-23 18:50 ` Jacek Anaszewski
2018-10-23 18:54 ` Pavel Machek
2018-10-23 19:09 ` Jacek Anaszewski
2018-10-23 19:30 ` Pavel Machek
2018-10-24 20:07 ` Jacek Anaszewski
2018-10-25 9:22 ` Andy Shevchenko
2018-10-25 17:44 ` Jacek Anaszewski
2018-10-23 19:23 ` Joe Perches
2018-10-23 20:31 ` Jacek Anaszewski
2018-10-24 10:13 ` Andy Shevchenko
2018-10-24 10:24 ` Joe Perches
2018-10-19 17:15 ` [PATCH v2 3/3] pinctrl: upboard: Add UP2 pinctrl and gpio driver Dan O'Donovan
2018-10-20 11:40 ` Andy Shevchenko
2018-10-31 19:55 ` Dan O'Donovan
2018-10-22 9:07 ` Linus Walleij
2018-10-24 13:05 ` [PATCH v2 0/3] UP Squared board drivers Andy Shevchenko
2018-10-31 20:44 ` [PATCH v3 " Dan O'Donovan
2018-10-31 20:44 ` [PATCH v3 1/3] mfd: upboard: Add UP2 platform controller driver Dan O'Donovan
2018-11-01 8:07 ` Lee Jones
2018-11-01 9:58 ` Dan O'Donovan
2018-11-11 11:29 ` Pavel Machek
2018-11-15 14:56 ` Linus Walleij
2018-10-31 20:44 ` [PATCH v3 2/3] leds: upboard: Add LED support Dan O'Donovan
2018-10-31 20:44 ` [PATCH v3 3/3] pinctrl: upboard: Add UP2 pinctrl and gpio driver Dan O'Donovan
2018-10-31 21:30 ` Linus Walleij
2018-10-31 21:39 ` Dan O'Donovan
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=20180426023836.udbeoocp76tsv7vu@localhost \
--to=javier@emutex.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=dan@emutex.com \
--cc=heikki.krogerus@linux.intel.com \
--cc=jacek.anaszewski@gmail.com \
--cc=lee.jones@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=pavel@ucw.cz \
/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).