> -----Original Message----- > From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> > Sent: Monday, January 6, 2025 9:45 PM > To: Sherry Sun <sherry.sun@xxxxxxx> > Cc: jirislaby@xxxxxxxxxx; linux-serial@xxxxxxxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx; imx@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxx> > > > Sent: Friday, January 3, 2025 5:08 PM > > > To: Sherry Sun <sherry.sun@xxxxxxx> > > > Cc: jirislaby@xxxxxxxxxx; linux-serial@xxxxxxxxxxxxxxx; linux- > > > kernel@xxxxxxxxxxxxxxx; imx@xxxxxxxxxxxxxxx > > > 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@xxxxxxx> > > > > --- > > > > 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
