Re: [PATCH v2 2/2] gpiolib: check the 'ngpios' property in core gpiolib code
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: 2021-11-18 21:16:39
Also in:
lkml
On Thu, Nov 18, 2021 at 09:12:59PM +0100, Bartosz Golaszewski wrote:
On Thu, Nov 18, 2021 at 6:06 PM Andy Shevchenko [off-list ref] wrote:quoted
On Thu, Nov 18, 2021 at 02:23:17PM +0100, Bartosz Golaszewski wrote:quoted
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....quoted
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?
quoted
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.
quoted
}
-- With Best Regards, Andy Shevchenko