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]

Date:   Fri, 26 May 2023 21:34:29 +0300
From:   andy.shevchenko@...il.com
To:     Hugo Villeneuve <hugo@...ovil.com>
Cc:     andy.shevchenko@...il.com, 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

Thu, May 25, 2023 at 11:02:55AM -0400, Hugo Villeneuve kirjoitti:
> 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:

...

> > 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?

I was wondering and have nothing to suggest here. It seems a burden we have to
cope with for now.

> > > +	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?

Maybe, but first try the approach with valid mask being involved. It may be
that we won't need this variable at all.

...

> > > +		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.

This is unfortunate. I missed that one, but i don't care about IrDA so much.

> 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?

device_property_read_u32_array().

Independently on the IrDA case, this one is more important and would have
consequences if we avoid agnostic APIs.

...

> > > +			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?

But you have below checks for u value. Wouldn't be enough?

> > > +				/* 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;
> > > +

-- 
With Best Regards,
Andy Shevchenko