linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Bartosz Golaszewski <brgl@bgdev.pl>,
	linux-acpi@vger.kernel.org, linux-gpio@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 6/6] gpiolib: add support for software nodes
Date: Wed, 9 Nov 2022 11:08:07 -0800	[thread overview]
Message-ID: <Y2v6lxoCQvlRdr8q@google.com> (raw)
In-Reply-To: <Y2uNDmRefzPvUu3P@smile.fi.intel.com>

On Wed, Nov 09, 2022 at 01:20:46PM +0200, Andy Shevchenko wrote:
> On Tue, Nov 08, 2022 at 04:26:51PM -0800, Dmitry Torokhov wrote:
> > Now that static device properties understand notion of child nodes and
> > references, let's teach gpiolib to handle them:
> > 
> > - GPIOs are represented as a references to software nodes representing
> >   gpiochip
> > - references must have 2 arguments - GPIO number within the chip and
> >   GPIO flags (GPIO_ACTIVE_LOW/GPIO_ACTIVE_HIGH, etc)
> > - a new PROPERTY_ENTRY_GPIO() macro is supplied to ensure the above
> > - name of the software node representing gpiochip must match label of
> >   the gpiochip, as we use it to locate gpiochip structure at runtime
> > 
> > The following illustrates use of software nodes to describe a "System"
> > button that is currently specified via use of gpio_keys_platform_data
> > in arch/mips/alchemy/board-mtx1.c. It follows bindings specified in
> > Documentation/devicetree/bindings/input/gpio-keys.yaml.
> > 
> > static const struct software_node mxt1_gpiochip2_node = {
> > 	.name = "alchemy-gpio2",
> > };
> > 
> > static const struct property_entry mtx1_gpio_button_props[] = {
> > 	PROPERTY_ENTRY_U32("linux,code", BTN_0),
> > 	PROPERTY_ENTRY_STRING("label", "System button"),
> > 	PROPERTY_ENTRY_GPIO("gpios", &mxt1_gpiochip2_node, 7, GPIO_ACTIVE_LOW),
> > 	{ }
> > };
> > 
> > Similarly, arch/arm/mach-tegra/board-paz00.c can be converted to:
> > 
> > static const struct software_node tegra_gpiochip_node = {
> > 	.name = "tegra-gpio",
> > };
> > 
> > static struct property_entry wifi_rfkill_prop[] __initdata = {
> > 	PROPERTY_ENTRY_STRING("name", "wifi_rfkill"),
> > 	PROPERTY_ENTRY_STRING("type", "wlan"),
> > 	PROPERTY_ENTRY_GPIO("reset-gpios",
> > 			    &tegra_gpiochip_node, 25, GPIO_ACTIVE_HIGH);
> > 	PROPERTY_ENTRY_GPIO("shutdown-gpios",
> > 			    &tegra_gpiochip_node, 85, GPIO_ACTIVE_HIGH);
> > 	{ },
> > };
> > 
> > static struct platform_device wifi_rfkill_device = {
> > 	.name	= "rfkill_gpio",
> > 	.id	= -1,
> > };
> > 
> > ...
> > 
> > 	software_node_register(&tegra_gpiochip_node);
> > 	device_create_managed_software_node(&wifi_rfkill_device.dev,
> > 					    wifi_rfkill_prop, NULL);
> 
> ...
> 
> > +static struct gpio_chip *swnode_get_chip(struct fwnode_handle *fwnode)
> > +{
> > +	const struct software_node *chip_node;
> > +	struct gpio_chip *chip;
> > +
> > +	chip_node = to_software_node(fwnode);
> > +	if (!chip_node || !chip_node->name)
> > +		return ERR_PTR(-EINVAL);
> 
> > +	chip = gpiochip_find((void *)chip_node->name,
> > +			     swnode_gpiochip_match_name);
> 
> One line?

OK.

> 
> > +	if (!chip)
> > +		return ERR_PTR(-EPROBE_DEFER);
> > +
> > +	return chip;
> 
> As below you can use Elvis here as well, up to you.
> 
> 	return chip ?: ERR_PTR(...);

OK.

> 
> > +}
> 
> ...
> 
> > +	desc = gpiochip_get_desc(chip, args.args[0]);
> > +	*flags = args.args[1]; /* We expect native GPIO flags */
> > +
> > +	pr_debug("%s: parsed '%s' property of node '%pfwP[%d]' - status (%d)\n",
> > +		 __func__, propname, fwnode, idx, PTR_ERR_OR_ZERO(desc));
> 
> %pe ?

"/* %pe with a non-ERR_PTR gets treated as plain %p */".

I do not think users are interested in the address on success.


> 
> > +	return desc;
> 
> ...
> 
> > +	while (fwnode_property_get_reference_args(fwnode, propname, NULL,
> > +						  0, count, &args) == 0) {
> 
> I would move 0 to the previous line.

OK.

> 
> > +		fwnode_handle_put(args.fwnode);
> > +		count++;
> > +	}
> 
> ...
> 
> >  int gpiod_count(struct device *dev, const char *con_id)
> >  {
> > -	const struct fwnode_handle *fwnode = dev ? dev_fwnode(dev) : NULL;
> > -	int count = -ENOENT;
> > +	struct fwnode_handle *fwnode = dev ? dev_fwnode(dev) : NULL;
> 
> Why dropping const?

Restored.

> 
> > +	int count;
> 
> Why this change is needed?

Restored.

> 
> >  	if (is_of_node(fwnode))
> >  		count = of_gpio_get_count(dev, con_id);
> >  	else if (is_acpi_node(fwnode))
> >  		count = acpi_gpio_count(dev, con_id);
> > +	else if (is_software_node(fwnode))
> > +		count = swnode_gpio_count(fwnode, con_id);
> > +	else
> > +		count = -ENOENT;
> 
> ...
> 
> > +#include <dt-bindings/gpio/gpio.h>
> 
> Not sure why we have this here.

For convenience - so that users have access to GPIO_ACTIVE_HIGH/
GPIO_ACTIVE_LOW and other flags.

> 
> > +#include <linux/property.h>
> > +
> > +#define PROPERTY_ENTRY_GPIO(_name_, _chip_node_, _idx_, _flags_) \
> > +	PROPERTY_ENTRY_REF(_name_, _chip_node_, _idx_, _flags_)
> 

Thanks.

-- 
Dmitry

  reply	other threads:[~2022-11-09 19:08 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-09  0:26 [PATCH v2 0/6] Add support for software nodes to gpiolib Dmitry Torokhov
2022-11-09  0:26 ` [PATCH v2 1/6] gpiolib: of: change of_find_gpio() to accept device node Dmitry Torokhov
2022-11-09  0:26 ` [PATCH v2 2/6] gpiolib: acpi: change acpi_find_gpio() to accept firmware node Dmitry Torokhov
2022-11-09  0:26 ` [PATCH v2 3/6] gpiolib: acpi: teach acpi_find_gpio() to handle data-only nodes Dmitry Torokhov
2022-11-09  0:26 ` [PATCH v2 4/6] gpiolib: acpi: avoid leaking ACPI details into upper gpiolib layers Dmitry Torokhov
2022-11-09  0:26 ` [PATCH v2 5/6] gpiolib: consolidate GPIO lookups Dmitry Torokhov
2022-11-09 11:25   ` Andy Shevchenko
2022-11-09 19:00     ` Dmitry Torokhov
2022-11-10 13:42       ` Andy Shevchenko
2022-11-10 17:21         ` Dmitry Torokhov
2022-11-10 20:10           ` Andy Shevchenko
2022-11-09  0:26 ` [PATCH v2 6/6] gpiolib: add support for software nodes Dmitry Torokhov
2022-11-09 11:20   ` Andy Shevchenko
2022-11-09 19:08     ` Dmitry Torokhov [this message]
2022-11-10 13:48       ` Andy Shevchenko
2022-11-10 17:17         ` Dmitry Torokhov
2022-11-09 11:29 ` [PATCH v2 0/6] Add support for software nodes to gpiolib Andy Shevchenko
2022-11-09 19:32   ` Dmitry Torokhov
2022-11-10 14:16     ` 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=Y2v6lxoCQvlRdr8q@google.com \
    --to=dmitry.torokhov@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=brgl@bgdev.pl \
    --cc=linus.walleij@linaro.org \
    --cc=linux-acpi@vger.kernel.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).