diff mbox series

[13/23] gpio: mockup: pass the chip label as device property

Message ID 20200904154547.3836-14-brgl@bgdev.pl (mailing list archive)
State Not Applicable, archived
Headers show
Series gpio: mockup: support dynamically created and removed chips | expand

Commit Message

Bartosz Golaszewski Sept. 4, 2020, 3:45 p.m. UTC 
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>

While we do check the "chip-name" property in probe(), we never actually
use it. Let's pass the chip label to the driver using device properties
as we'll want to allow users to define their own once dynamically
created chips are supported.

The property is renamed to "chip-label" to not cause any confusion with
the actual chip name which is of the form: "gpiochipX".

If the "chip-label" property is missing, let's do what most devices in
drivers/gpio/ do and use dev_name().

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
 drivers/gpio/gpio-mockup.c | 17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

Comments

Andy Shevchenko Sept. 4, 2020, 4:48 p.m. UTC | #1 
On Fri, Sep 04, 2020 at 05:45:37PM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> 
> While we do check the "chip-name" property in probe(), we never actually
> use it. Let's pass the chip label to the driver using device properties
> as we'll want to allow users to define their own once dynamically
> created chips are supported.
> 
> The property is renamed to "chip-label" to not cause any confusion with
> the actual chip name which is of the form: "gpiochipX".
> 
> If the "chip-label" property is missing, let's do what most devices in
> drivers/gpio/ do and use dev_name().

Just wondering if we have a documentation in kernel how this mockup mechanism
works and what kind of properties it uses.

Side note: moving to software nodes would make some advantages in future such
as visibility properties and their values (not yet implemented, but there is an
idea to move forward).

> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
>  drivers/gpio/gpio-mockup.c | 17 ++++++++---------
>  1 file changed, 8 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-mockup.c b/drivers/gpio/gpio-mockup.c
> index e8a19a28ed13..ce83f1df1933 100644
> --- a/drivers/gpio/gpio-mockup.c
> +++ b/drivers/gpio/gpio-mockup.c
> @@ -433,21 +433,14 @@ static int gpio_mockup_probe(struct platform_device *pdev)
>  	if (rv)
>  		return rv;
>  
> -	rv = device_property_read_string(dev, "chip-name", &name);
> +	rv = device_property_read_string(dev, "chip-label", &name);
>  	if (rv)
> -		name = NULL;
> +		name = dev_name(dev);
>  
>  	chip = devm_kzalloc(dev, sizeof(*chip), GFP_KERNEL);
>  	if (!chip)
>  		return -ENOMEM;
>  
> -	if (!name) {
> -		name = devm_kasprintf(dev, GFP_KERNEL,
> -				      "%s-%c", pdev->name, pdev->id + 'A');
> -		if (!name)
> -			return -ENOMEM;
> -	}
> -
>  	mutex_init(&chip->lock);
>  
>  	gc = &chip->gc;
> @@ -534,6 +527,7 @@ static void gpio_mockup_unregister_devices(void)
>  static int __init gpio_mockup_init(void)
>  {
>  	struct property_entry properties[GPIO_MOCKUP_MAX_PROP];
> +	char chip_label[GPIO_MOCKUP_LABEL_SIZE];
>  	struct gpio_mockup_device *mockup_dev;
>  	int i, prop, num_chips, err = 0, base;
>  	struct platform_device_info pdevinfo;
> @@ -570,6 +564,11 @@ static int __init gpio_mockup_init(void)
>  		memset(&pdevinfo, 0, sizeof(pdevinfo));
>  		prop = 0;
>  
> +		snprintf(chip_label, sizeof(chip_label),
> +			 "gpio-mockup-%c", i + 'A');
> +		properties[prop++] = PROPERTY_ENTRY_STRING("chip-label",
> +							   chip_label);
> +
>  		base = gpio_mockup_range_base(i);
>  		if (base >= 0)
>  			properties[prop++] = PROPERTY_ENTRY_U32("gpio-base",
> -- 
> 2.26.1
>
Bartosz Golaszewski Sept. 7, 2020, 11:01 a.m. UTC | #2 
On Fri, Sep 4, 2020 at 6:48 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Fri, Sep 04, 2020 at 05:45:37PM +0200, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> >
> > While we do check the "chip-name" property in probe(), we never actually
> > use it. Let's pass the chip label to the driver using device properties
> > as we'll want to allow users to define their own once dynamically
> > created chips are supported.
> >
> > The property is renamed to "chip-label" to not cause any confusion with
> > the actual chip name which is of the form: "gpiochipX".
> >
> > If the "chip-label" property is missing, let's do what most devices in
> > drivers/gpio/ do and use dev_name().
>
> Just wondering if we have a documentation in kernel how this mockup mechanism
> works and what kind of properties it uses.
>
> Side note: moving to software nodes would make some advantages in future such
> as visibility properties and their values (not yet implemented, but there is an
> idea to move forward).

Seems like we're implicitly using software nodes already:
fwnode_create_software_node() is called when adding device properties.

Bart
Andy Shevchenko Sept. 7, 2020, 11:48 a.m. UTC | #3 
On Mon, Sep 07, 2020 at 01:01:02PM +0200, Bartosz Golaszewski wrote:
> On Fri, Sep 4, 2020 at 6:48 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Fri, Sep 04, 2020 at 05:45:37PM +0200, Bartosz Golaszewski wrote:
> > > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> > >
> > > While we do check the "chip-name" property in probe(), we never actually
> > > use it. Let's pass the chip label to the driver using device properties
> > > as we'll want to allow users to define their own once dynamically
> > > created chips are supported.
> > >
> > > The property is renamed to "chip-label" to not cause any confusion with
> > > the actual chip name which is of the form: "gpiochipX".
> > >
> > > If the "chip-label" property is missing, let's do what most devices in
> > > drivers/gpio/ do and use dev_name().
> >
> > Just wondering if we have a documentation in kernel how this mockup mechanism
> > works and what kind of properties it uses.
> >
> > Side note: moving to software nodes would make some advantages in future such
> > as visibility properties and their values (not yet implemented, but there is an
> > idea to move forward).
> 
> Seems like we're implicitly using software nodes already:
> fwnode_create_software_node() is called when adding device properties.

It's not the same APIs, though the former is called from the latter.
But maybe for now it's okay.
diff mbox series

Patch

diff --git a/drivers/gpio/gpio-mockup.c b/drivers/gpio/gpio-mockup.c
index e8a19a28ed13..ce83f1df1933 100644
--- a/drivers/gpio/gpio-mockup.c
+++ b/drivers/gpio/gpio-mockup.c
@@ -433,21 +433,14 @@  static int gpio_mockup_probe(struct platform_device *pdev)
 	if (rv)
 		return rv;
 
-	rv = device_property_read_string(dev, "chip-name", &name);
+	rv = device_property_read_string(dev, "chip-label", &name);
 	if (rv)
-		name = NULL;
+		name = dev_name(dev);
 
 	chip = devm_kzalloc(dev, sizeof(*chip), GFP_KERNEL);
 	if (!chip)
 		return -ENOMEM;
 
-	if (!name) {
-		name = devm_kasprintf(dev, GFP_KERNEL,
-				      "%s-%c", pdev->name, pdev->id + 'A');
-		if (!name)
-			return -ENOMEM;
-	}
-
 	mutex_init(&chip->lock);
 
 	gc = &chip->gc;
@@ -534,6 +527,7 @@  static void gpio_mockup_unregister_devices(void)
 static int __init gpio_mockup_init(void)
 {
 	struct property_entry properties[GPIO_MOCKUP_MAX_PROP];
+	char chip_label[GPIO_MOCKUP_LABEL_SIZE];
 	struct gpio_mockup_device *mockup_dev;
 	int i, prop, num_chips, err = 0, base;
 	struct platform_device_info pdevinfo;
@@ -570,6 +564,11 @@  static int __init gpio_mockup_init(void)
 		memset(&pdevinfo, 0, sizeof(pdevinfo));
 		prop = 0;
 
+		snprintf(chip_label, sizeof(chip_label),
+			 "gpio-mockup-%c", i + 'A');
+		properties[prop++] = PROPERTY_ENTRY_STRING("chip-label",
+							   chip_label);
+
 		base = gpio_mockup_range_base(i);
 		if (base >= 0)
 			properties[prop++] = PROPERTY_ENTRY_U32("gpio-base",