[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aFcDOx1bdB34I5hS@surfacebook.localdomain>
Date: Sat, 21 Jun 2025 22:08:43 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: "Maciej S. Szmigiero" <mail@...iej.szmigiero.name>
Cc: Andy Shevchenko <andriy.shevchenko@...el.com>,
"Jiri Slaby (SUSE)" <jirislaby@...nel.org>,
Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
gregkh@...uxfoundation.org, linux-serial@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 30/33] serial: 8250: invert
serial8250_register_8250_port() CIR condition
Fri, Jun 20, 2025 at 11:48:09PM +0200, Maciej S. Szmigiero kirjoitti:
> On 18.06.2025 07:48, Andy Shevchenko wrote:
> > On Wed, Jun 11, 2025 at 12:03:16PM +0200, Jiri Slaby (SUSE) wrote:
...
> > > + if (uart->port.type == PORT_8250_CIR) {
> > > + ret = -ENODEV;
> > > + goto unlock;
> > > + }
> >
> > > + if (up->port.flags & UPF_FIXED_TYPE)
> > > + uart->port.type = up->port.type;
> >
> > > + if (uart->port.type != PORT_8250_CIR) {
> >
> > I admit that there tons of mysterious ways of UART initialisation, but can you
> > elaborate how this is not a always-true conditional?
>
> Careful here, someone had an idea in the past that this is indeed
> a dead code/branch and ended causing a regression [1].
> It would definitely make sense to add a comment describing the code
> flow there though as it proven to bewilder people.
Yes, this is my point between the lines. I left the code that may affect the
type change and the second check needs a comment explaining these cases, if any.
"If any" defines "always-true" or not conditional. W//o a comment this code
tends to be updated again and lead to a regression.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists