linux-kernel - Re: [PATCH 1/4] gpiolib: cdev: relocate debounce_period_us from struct gpio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZXm3rayrcvfO1t1Z@smile.fi.intel.com>
Date:   Wed, 13 Dec 2023 15:54:53 +0200
From:   Andy Shevchenko <andy@...nel.org>
To:     Kent Gibson <warthog618@...il.com>
Cc:     linux-kernel@...r.kernel.org, linux-gpio@...r.kernel.org,
        brgl@...ev.pl, linus.walleij@...aro.org
Subject: Re: [PATCH 1/4] gpiolib: cdev: relocate debounce_period_us from
 struct gpio_desc

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