Message ID | 20211118132317.15898-1-brgl@bgdev.pl |
---|---|
State | Superseded |
Headers | show |
Series | [v2,1/2] gpiolib: improve coding style for local variables | expand |
On Fri, Nov 19, 2021 at 08:35:33PM +0100, Bartosz Golaszewski wrote: > On Thu, Nov 18, 2021 at 10:16 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > On Thu, Nov 18, 2021 at 09:12:59PM +0100, Bartosz Golaszewski wrote: > > > On Thu, Nov 18, 2021 at 6:06 PM Andy Shevchenko > > > <andriy.shevchenko@linux.intel.com> wrote: > > > > On Thu, Nov 18, 2021 at 02:23:17PM +0100, Bartosz Golaszewski wrote: ... > > > > > if (gc->ngpio == 0) { > > > > > - chip_err(gc, "tried to insert a GPIO chip with zero lines\n"); > > > > > - ret = -EINVAL; > > > > > - goto err_free_descs; > > > > > + ret = device_property_read_u32(&gdev->dev, "ngpios", &ngpios); > > > > > + if (ret) { > > > > > + chip_err(gc, "tried to insert a GPIO chip with zero lines\n"); > > > > > + ret = -EINVAL; > > > > > + goto err_free_descs; > > > > > + } > > > > > + > > > > > + gc->ngpio = ngpios; > > > > > } > > > > > > > > This should be > > > > > > > > if (gc->ngpio == 0) { > > > > ret = device_property_read_u32(&gdev->dev, "ngpios", &ngpios); > > > > if (ret) > > > > return ret; > > > > > > But device_property_read_u32() returning -ENODATA means there's no > > > such property, which should actually be converted to -EINVAL as the > > > caller wanting to create the chip provided invalid configuration - in > > > this case: a chip with 0 lines. In case of the non-array variant of > > > read_u32 that's also the only error that can be returned so this bit > > > looks right to me. > > > > So, what is so special about -EINVAL? Why -ENODATA is not good enough which > > will exactly explain to the caller what's going on, no? > > > > Let's imagine the user sets gc->ngpio = 0 incorrectly thinking it'll > make gpiolib set it to some sane default. Then gpiochip_add_data() > returns -ENODATA (No data available). This is confusing IMO. But if we > convert it to -EINVAL, it now says "Invalid value" which points to the > wrong configuration. > > ENODATA means "device tree property is not present" in this case but > the problem is that user supplies the gpiolib with invalid > configuration. EINVAL is the right error here. Then be explicit, don't shadow other error codes from fwnode API. if (ret && ret != -ENODATA) > > > > gc->ngpio = ngpios; > > > > } > > > > > > > > if (gc->ngpio == 0) { > > > > chip_err(gc, "tried to insert a GPIO chip with zero lines\n"); > > > > ret = -EINVAL; > > > > goto err_free_descs; > > > > When the caller intended to create a chip with 0 GPIOs they will get an error > > as you wish with an error message. > > Yes, as it was before.
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index abfbf546d159..20d63028b85c 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -594,11 +594,10 @@ int gpiochip_add_data_with_key(struct gpio_chip *gc, void *data, struct lock_class_key *request_key) { struct fwnode_handle *fwnode = gc->parent ? dev_fwnode(gc->parent) : NULL; - unsigned long flags; - int ret = 0; - unsigned i; - int base = gc->base; + int ret = 0, base = gc->base; struct gpio_device *gdev; + unsigned long flags; + unsigned int i; /* * First: allocate and populate the internal stat container, and