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:
> > From: Hugo Villeneuve <hvilleneuve@xxxxxxxxxxxx>
> >
> > 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
>
>
>
