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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID:
 <DB9PR04MB8429E68D7A21BD8196CEF1E192112@DB9PR04MB8429.eurprd04.prod.outlook.com>
Date: Tue, 7 Jan 2025 09:54:44 +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: 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.)
> >
> > BTW, it seems that usb-serial devices also have the max ports limit,
> > you can check the MAX_NUM_PORTS macro in include/linux/usb/serial.h, it
> was extended from 8 to 16 now.
> >
> > /* The maximum number of ports one device can grab at once */
> > #define MAX_NUM_PORTS       16
> 
> That's different, that is "max devices a single device can use".  We don't know
> of any single-usb-device that has more than 16 ports on it, do you?  I've seen
> big ones, but internally they are all split up into smaller USB devices in order
> to handle the bandwidth properly.  And I think even the 16 port devices are
> almost always really just 2 8-port devices, or 4 4-port ones.
> 
> Now you can have a lot of 16-port devices in the system at the same time, but
> I think we max out at 256.
> 
> Oops, nope, we now support 512 usb-serial ports in the system at one
> time:
> 	#define USB_SERIAL_TTY_MINORS   512     /* should be enough for a
> while */
> 
> Well "now" is relative, that change was made in 2013 :)
> 
> The commit that bumped the number also gives a hint on how to make this
> more dynamic, if you want to read the changelog text for commit
> 455b4f7e18e7 ("USB: serial: increase the number of devices we support") for
> more details.
> 

Hi Greg,
Thanks for the detailed explanation, yes it is clear to me now, anyway the next
step may needs to remove the limitation of both normal uart and usb serial,
dynamic configuration is our goal.

Best Regards
Sherry