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

[andy.shevchenko@xxxxxxxxx]

Thu, May 25, 2023 at 11:02:55AM -0400, Hugo Villeneuve kirjoitti:
> On Thu, 25 May 2023 14:19:52 +0300
> andy.shevchenko@xxxxxxxxx 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