[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75Ve6W-hcB4YAeKukgv-uOEzBY7Tx5Sdf3doTRYKzNPcVGw@mail.gmail.com>
Date: Sun, 4 Jun 2023 14:57:31 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Hugo Villeneuve <hugo@...ovil.com>, 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 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.
> And you have a real port here, no need to pass in a "raw" struct device,
> right?
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists