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
