Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 31 May 2023 09:57:14 -0400
From:   Hugo Villeneuve <hugo@hugovil.com>
To:     Andy Shevchenko <andy.shevchenko@gmail.com>
Cc:     gregkh@linuxfoundation.org, robh+dt@kernel.org,
        krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
        jirislaby@kernel.org, jringle@gridpoint.com,
        l.perczak@camlintechnologies.com, tomasz.mon@camlingroup.com,
        linux-serial@vger.kernel.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
        Hugo Villeneuve <hvilleneuve@dimonoff.com>
Message-Id: <20230531095714.2428a41369cd7509bc321bf7@hugovil.com>
In-Reply-To: <CAHp75Vf35rN93sXFBU0nRZQLpUgQHR2caGC8BmHkEgPZqF=dQg@mail.gmail.com>
References: <20230529140711.896830-1-hugo@hugovil.com>
        <20230529140711.896830-8-hugo@hugovil.com>
        <ZHUpWQafRPHW1RJQ@surfacebook>
        <20230530113649.73f28b9f6ba91f17ace1e12f@hugovil.com>
        <CAHp75Vf35rN93sXFBU0nRZQLpUgQHR2caGC8BmHkEgPZqF=dQg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PATCH v4 7/9] serial: sc16is7xx: fix regression with GPIO
 configuration
Precedence: bulk

On Wed, 31 May 2023 00:56:57 +0300
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> On Tue, May 30, 2023 at 6:36 PM Hugo Villeneuve <hugo@hugovil.com> wrote:
> > On Tue, 30 May 2023 01:38:17 +0300
> > andy.shevchenko@gmail.com wrote:
> > > Mon, May 29, 2023 at 10:07:09AM -0400, Hugo Villeneuve kirjoitti:
> 
> ...
> 
> > > GENMASK()
> >
> > Ok done, altough even if in general I like the bit manipulation macros because they make the code easier to read/understand, I find it less obvious by using GENMASK in this case IMMO.
> 
> GENMASK() was introduced to increase code robustness:
> 1) to make sure the bits mentioned are correct
> 2) to check the bit boundary.
> 
> ...
> 
> > > > +           of_property_for_each_u32(dev->of_node, "nxp,modem-control-line-ports",
> > > > +                                    prop, p, u) {
> > > > +                   if (u >= devtype->nr_uart)
> > > > +                           continue;
> > > > +
> > > > +                   /* Use GPIO lines as modem control lines */
> > > > +                   if (u == 0)
> > > > +                           mctrl_mask |= SC16IS7XX_IOCONTROL_MODEM_A_BIT;
> > > > +                   else if (u == 1)
> > > > +                           mctrl_mask |= SC16IS7XX_IOCONTROL_MODEM_B_BIT;
> > > > +           }
> > >
> > > Can we use device properties, please?
> >
> > I have converted this section to use device_property_count_u32() and device_property_read_u32_array(). Is that Ok?
> 
> Yes, thank you!
> 
> > > If you think about backporting to the earlier kernels (w/o properties in use in
> > > this driver), perhaps an additional followup for that?
> >
> > I am not sure what you mean by this?
> 
> If the device property API was not yet available for this fix being
> backported to the old enough kernel we have to use old OF stuff. In
> that case the device property conversion needs to be done in a
> separate change.

Hi,.
ok, now I see.

Thank you,
Hugo.