linux-kernel - RE: [PATCH] tty: serial: fsl_lpuart: increase maximum uart

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <DB9PR04MB842919A4D63AC7CAC1C3FA5392112@DB9PR04MB8429.eurprd04.prod.outlook.com>
Date: Tue, 7 Jan 2025 08:16:40 +0000
From: Sherry Sun <sherry.sun@....com>
To: Greg KH <gregkh@...uxfoundation.org>
CC: "jirislaby@...nel.org" <jirislaby@...nel.org>,
	"linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"imx@...ts.linux.dev" <imx@...ts.linux.dev>
Subject: RE: [PATCH] tty: serial: fsl_lpuart: increase maximum uart_nr to 12



> -----Original Message-----
> From: Greg KH <gregkh@...uxfoundation.org>
> Sent: Monday, January 6, 2025 9:45 PM
> To: Sherry Sun <sherry.sun@....com>
> Cc: jirislaby@...nel.org; linux-serial@...r.kernel.org; linux-
> kernel@...r.kernel.org; imx@...ts.linux.dev
> Subject: Re: [PATCH] tty: serial: fsl_lpuart: increase maximum uart_nr to 12
>
> On Mon, Jan 06, 2025 at 10:24:52AM +0000, Sherry Sun wrote:
> >
> >
> > > -----Original Message-----
> > > From: Greg KH <gregkh@...uxfoundation.org>
> > > Sent: Friday, January 3, 2025 5:08 PM
> > > To: Sherry Sun <sherry.sun@....com>
> > > Cc: jirislaby@...nel.org; linux-serial@...r.kernel.org; linux-
> > > kernel@...r.kernel.org; imx@...ts.linux.dev
> > > Subject: Re: [PATCH] tty: serial: fsl_lpuart: increase maximum
> > > uart_nr to 12
> > >
> > > On Fri, Jan 03, 2025 at 03:11:54PM +0800, Sherry Sun wrote:
> > > > Some SoCs like the i.MX943 have aliases for up to 12 UARTs, need
> > > > to increase UART_NR from 8 to 12 to support lpuart9-12 to avoid
> > > > initialization failures.
> > > >
> > > > Signed-off-by: Sherry Sun <sherry.sun@....com>
> > > > ---
> > > >  drivers/tty/serial/fsl_lpuart.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/tty/serial/fsl_lpuart.c
> > > > b/drivers/tty/serial/fsl_lpuart.c index 57b0632a3db6..7cb1e36fdaab
> > > > 100644
> > > > --- a/drivers/tty/serial/fsl_lpuart.c
> > > > +++ b/drivers/tty/serial/fsl_lpuart.c
> > > > @@ -245,7 +245,7 @@
> > > >
> > > >  #define DRIVER_NAME    "fsl-lpuart"
> > > >  #define DEV_NAME       "ttyLP"
> > > > -#define UART_NR                8
> > > > +#define UART_NR                12
> > >
> > > Why not fix this properly and make this dynamic and get rid of the
> > > static array causing all of this problem?  That way when you get a
> > > system with 13 uarts, you will be ok :)
> > >
> >
> > Hi Greg,
> >
> > Thanks for your comment.
> > But I checked all the uart drivers under drivers/tty/serial/, UART_NR
> > is widely used, currently almost every uart driver that supports
> > multiple uart ports defines this macro, this value is needed for the
> > nr parameter of struct uart_driver, also for console index checking
> > and setup.
>
> Yeah, it's messy, but it can be done (for example see all of the usb-serial
> devices, we don't limit the number of those ports in the system except to 256
> I think.)
>
> > This patch just refers to many other uart driver patches to extend
> > maximum uart number, such as
> >
> https://lore.ke/
> rnel.org%2Fall%2F20240112095300.2004878-3-
> valentin.caron%40foss.st.com%2F&data=05%7C02%7Csherry.sun%40nxp.co
> m%7C4c12dccfce2c44e0a21408dd2e584fba%7C686ea1d3bc2b4c6fa92cd99c5
> c301635%7C0%7C0%7C638717679009907376%7CUnknown%7CTWFpbGZsb3
> d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF
> OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=uq3dYJI3va5uRu
> LcPkF8DxP0mMPcYBiflG%2Bc18TiC3U%3D&reserved=0.
> > Agree that it will be nice to dynamically allocate everything, but for
> > now I prefer to simply change this value as there doesn't seem to be a
> > good uart implementation at the moment, not sure what you prefer?  :)
>
> I'd prefer not hard-coding stuff like this but if it's going to be too much of a
> pain I guess I'll take this for now...
>

Yes, agree, at least for now change the old hard-coding stuff which are widely
used in uart seems painful, maybe we can try to improve this after further
research and discussion later.

Best Regards
Sherry