linux-kernel - Re: [PATCH v3 08/11] serial: sc16is7xx: fix regression with GPIO configuration

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: <20230525110255.6ffe0a0c3f88ae03c3fc5f25@hugovil.com>
Date:   Thu, 25 May 2023 11:02:55 -0400
From:   Hugo Villeneuve <hugo@...ovil.com>
To:     andy.shevchenko@...il.com
Cc:     gregkh@...uxfoundation.org, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
        jirislaby@...nel.org, jringle@...dpoint.com,
        tomasz.mon@...lingroup.com, l.perczak@...lintechnologies.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>
Subject: Re: [PATCH v3 08/11] serial: sc16is7xx: fix regression with GPIO
 configuration

On Thu, 25 May 2023 14:19:52 +0300
andy.shevchenko@...il.com wrote:

> Thu, May 25, 2023 at 12:03:22AM -0400, Hugo Villeneuve kirjoitti:
> > From: Hugo Villeneuve <hvilleneuve@...onoff.com>
> > 
> > Commit 679875d1d880 ("sc16is7xx: Separate GPIOs from modem control lines")
> > and commit 21144bab4f11 ("sc16is7xx: Handle modem status lines")
> > changed the function of the GPIOs pins to act as modem control
> > lines without any possibility of selecting GPIO function.
> > 
> > As a consequence, applications that depends on GPIO lines configured
> > by default as GPIO pins no longer work as expected.
> > 
> > Also, the change to select modem control lines function was done only
> > for channel A of dual UART variants (752/762). This was not documented
> > in the log message.
> 
> > This new patch allows to specify GPIO or modem control line function
> > in the device tree, and for each of the ports (A or B).
> 
> Imperative mood as stated in documentation, please.
> Like "Allow to specify...".
> 
> > This is done by using the new device-tree property named
> > "modem-control-line-ports" (property added in separate patch).
> > 
> > We also now reduce the number of exported GPIOs according to the
> > modem-status-line-port DT property.

Just noticed a mistake:
s/modem-status-line-port/modem-control-line-ports

> > 
> > Boards that need to have GPIOS configured as modem control lines
> > should add that property to their device tree. Here is a list of
> > boards using the sc16is7xx driver in their device tree and that may
> > need to be modified:
> >     arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts
> >     mips/boot/dts/ingenic/cu1830-neo.dts
> >     mips/boot/dts/ingenic/cu1000-neo.dts
> 
> ...
> 
> > +#ifdef CONFIG_GPIOLIB
> 
> I'm wondering if we can avoid adding new ifdefferies...

I am simply following waht was already done in the existing driver.

Are you suggesting that we need to remove all these #defines? If not, what exactly do you suggest?


> > +	s->gpio_configured = devtype->nr_gpio;
> 
> The name of the variable is a bit vague WRT its content.
> Shouldn't be as simple as the rvalue, i.e. s->nr_gpio?

Maybe the name could be improved (and/or comments).

devtype->nr_gpio is the maximum "theoretical" number of GPIOs supported by the chip.

s->gpio_configured is the number of GPIOs that are configured or requested according to the presence (or not) of the modem-control-line-ports property.

I wanted to avoid using the same name to avoid potential confusion.

Maybe devtype->nr_gpio could be renamed to devtype->nr_gpio_max and s->gpio_configured to s->nr_gpio_requested or s->nr_gpio_configured?


> > +#endif /* CONFIG_GPIOLIB */
> 
> ...
> 
> > +		of_property_for_each_u32(dev->of_node, "nxp,modem-control-line-ports",
> > +					 prop, p, u)
> 
> The driver so far is agnostic to property provider. Please keep it that way,
> i.e. no of_ APIs.

The driver, before my patches, was already using the exact same function of_property_for_each_u32() to process the irda-mode-ports property, so I don't understand your comment.

But what do you suggest instead of of_property_for_each_u32()? And do we need to change it also for processing the irda-mode-ports property?


> > +			if (u < devtype->nr_uart) {
> 
> Hmm... What other can it be?

Again, this is similar to the handling of the irda-mode-ports property.

But I am not sure I understand your question/concern?

I think this check is important, because if someone puts the following property in a DT:

    nxp,modem-control-line-ports = <0 1>;

but the variant only supports 1 port, then the check is usefull, no?


> 
> > +				/* Use GPIO lines as modem control lines */
> > +				if (u == 0)
> > +					val |= SC16IS7XX_IOCONTROL_MODEM_A_BIT;
> > +				else if (u == 1)
> > +					val |= SC16IS7XX_IOCONTROL_MODEM_B_BIT;
> > +
> > +#ifdef CONFIG_GPIOLIB
> > +				if (s->gpio_configured >=
> > +				    SC16IS7XX_GPIOS_PER_BANK)
> 
> On one line it will be better to read. Esp. taking into account the above remark.

Fixed.

 
> > +					s->gpio_configured -=
> > +						SC16IS7XX_GPIOS_PER_BANK;
> 
> Ditto.

Fixed.

> 
> > +#endif /* CONFIG_GPIOLIB */
> > +			}
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
> 
>