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@xxxxxxxxxxxxxxx> wrote: > > On Thu, Nov 18, 2021 at 02:23:17PM +0100, Bartosz Golaszewski wrote: > > > Several drivers read the 'ngpios' device property on their own, but > > > since it's defined as a standard GPIO property in the device tree bindings > > > anyway, it's a good candidate for generalization. If the driver didn't > > > set its gc->ngpio, try to read the 'ngpios' property from the GPIO > > > device's firmware node before bailing out. > > > > ... > > > > > 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? > > 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. > > } -- With Best Regards, Andy Shevchenko