linux-kernel - Re: [PATCH v9 04/10] serial: sc16is7xx: refactor GPIO controller registration

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: <2023073118-mousiness-sandlot-6258@gregkh>
Date:   Mon, 31 Jul 2023 17:55:42 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Hugo Villeneuve <hugo@...ovil.com>
Cc:     robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
        conor+dt@...nel.org, jirislaby@...nel.org, jringle@...dpoint.com,
        isaac.true@...onical.com, jesse.sung@...onical.com,
        l.perczak@...lintechnologies.com, tomasz.mon@...lingroup.com,
        linux-serial@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-gpio@...r.kernel.org,
        Hugo Villeneuve <hvilleneuve@...onoff.com>,
        stable@...r.kernel.org, Lech Perczak <lech.perczak@...lingroup.com>
Subject: Re: [PATCH v9 04/10] serial: sc16is7xx: refactor GPIO controller
 registration

On Tue, Jul 25, 2023 at 10:23:36AM -0400, Hugo Villeneuve wrote:
> From: Hugo Villeneuve <hvilleneuve@...onoff.com>
> 
> In preparation for upcoming patch "fix regression with GPIO
> configuration". To facilitate review and make code more modular.

I would much rather the issue be fixed _before_ the code is refactored,
unless it is impossible to fix it without the refactor?

> 
> Cc: <stable@...r.kernel.org> # 6.1.x

What commit id does this fix?

> Signed-off-by: Hugo Villeneuve <hvilleneuve@...onoff.com>
> Reviewed-by: Lech Perczak <lech.perczak@...lingroup.com>
> Tested-by: Lech Perczak <lech.perczak@...lingroup.com>
> ---
>  drivers/tty/serial/sc16is7xx.c | 40 ++++++++++++++++++++--------------
>  1 file changed, 24 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c
> index 32d43d00a583..5b0aeef9d534 100644
> --- a/drivers/tty/serial/sc16is7xx.c
> +++ b/drivers/tty/serial/sc16is7xx.c
> @@ -332,6 +332,7 @@ struct sc16is7xx_one {
>  
>  struct sc16is7xx_port {
>  	const struct sc16is7xx_devtype	*devtype;
> +	struct device			*dev;

Why is this pointer needed?

Why is it grabbed and yet the reference count is never incremented?  Who
owns the reference count and when will it go away?

And what device is this?  The parent?  Current device?  What type of
device is it?  And why is it needed?

Using "raw" devices is almost never something a driver should do, they
are only passed into functions by the driver core, but then the driver
should instantly turn them into the "real" structure.


thanks,

greg k-h