Re: [PATCH 1/4] gpiolib: cdev: relocate debounce_period_us from struct gpio_desc

From: Andy Shevchenko
Date: Wed Dec 13 2023 - 08:59:01 EST


On Tue, Dec 12, 2023 at 01:42:50PM +0800, Kent Gibson wrote:
> Store the debounce period for a requested line locally, rather than in
> the debounce_period_us field in the gpiolib struct gpio_desc.
>
> Add a global tree of lines containing supplemental line information
> to make the debounce period available to be reported by the
> GPIO_V2_GET_LINEINFO_IOCTL and the line change notifier.

...

> struct line {
> struct gpio_desc *desc;
> + struct rb_node node;

If you swap them, would it benefit in a code generation (bloat-o-meter)?

> };

...

> +struct supinfo {
> + spinlock_t lock;
> + struct rb_root tree;
> +};

Same Q.

...

> +static struct supinfo supinfo;

Why supinfo should be a struct to begin with? Seems to me as an unneeded
complication.

...

> + pr_warn("%s: duplicate line inserted\n", __func__);

I hope at bare minimum we have pr_fmt(), but even though this is poor message
that might require some information about exact duplication (GPIO chip label /
name, line number, etc). Generally speaking the __func__ in non-debug messages
_usually_ is a symptom of poorly written message.

...

> +out_unlock:
> + spin_unlock(&supinfo.lock);

No use of cleanup.h?

...

> +static inline bool line_is_supplemental(struct line *line)
> +{
> + return READ_ONCE(line->debounce_period_us) != 0;

" != 0" is redundant.

> +}

...

> for (i = 0; i < lr->num_lines; i++) {
> - if (lr->lines[i].desc) {
> - edge_detector_stop(&lr->lines[i]);
> - gpiod_free(lr->lines[i].desc);
> + line = &lr->lines[i];
> + if (line->desc) {

Perhaps

if (!line->desc)
continue;

?

> + edge_detector_stop(line);
> + if (line_is_supplemental(line))
> + supinfo_erase(line);
> + gpiod_free(line->desc);
> }
> }

...

> +static int __init gpiolib_cdev_init(void)
> +{
> + supinfo_init();
> + return 0;
> +}

It's a good practice to explain initcalls (different to the default ones),
can you add a comment on top to explain the choice of this initcall, please?

> +postcore_initcall(gpiolib_cdev_init);

--
With Best Regards,
Andy Shevchenko