[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75VeWFPBmsD8zsSAaQGNNXtfgLtQuM9AMGfLPk-6p0VW=Pg@mail.gmail.com>
Date: Sun, 4 Jun 2023 22:31:04 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Hugo Villeneuve <hugo@...ovil.com>
Cc: Greg KH <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>,
stable@...r.kernel.org
Subject: Re: [PATCH v7 5/9] serial: sc16is7xx: fix regression with GPIO configuration
On Sun, Jun 4, 2023 at 8:45 PM Hugo Villeneuve <hugo@...ovil.com> wrote:
>
> On Sun, 4 Jun 2023 14:57:31 +0300
> Andy Shevchenko <andy.shevchenko@...il.com> wrote:
>
> > On Sun, Jun 4, 2023 at 10:47 AM Greg KH <gregkh@...uxfoundation.org> wrote:
> > > On Fri, Jun 02, 2023 at 11:26:21AM -0400, Hugo Villeneuve wrote:
> >
> > ...
> >
> > > > +static u8 sc16is7xx_setup_mctrl_ports(struct device *dev)
> > >
> > > This returns what, mctrl? If so, please document that, it doesn't look
> > > obvious.
> >
> > Good suggestion. Because I also stumbled over the returned type.
> >
> > > And as the kernel test robot reported, you do nothing with the
> > > return value so why compute it?
> >
> > It seems that the entire function and respective call has to be moved
> > under #ifdef CONFIG_GPIOLIB.
>
> Hi,
> it cannot. See my explanations in response to Greg's comments.
Then as Greg suggested, store in the structure and make this function
to return an error code (with int), with this amendment you don't need
to add a comment about the returned variable anymore.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists