linux-leds.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 :)

  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).