[PATCH] arm64: defconfig: increase SERIAL_8250_NR_UARTS
Nishanth Menon
nm at ti.com
Fri Dec 1 08:31:26 PST 2023
On 16:31-20231201, Arnd Bergmann wrote:
> On Fri, Dec 1, 2023, at 07:49, Nishanth Menon wrote:
> > On 08:03-20231201, Tony Lindgren wrote:
> >> * Francesco Dolcini <francesco at dolcini.it> [231130 23:17]:
> >> > Increase CONFIG_SERIAL_8250_NR_UARTS from 4 to 8, the current legacy value
> >> > is not adequate for embedded systems that use SoCs where it's common to
> >> > have a large number of serial ports.
> >> >
> >> > No need to change CONFIG_SERIAL_8250_RUNTIME_UARTS, see commit 9d86719f8769
> >> > ("serial: 8250: Allow using ports higher than SERIAL_8250_RUNTIME_UARTS").
> >> >
> >> > This enables using the UART connected Bluetooth device on Verdin AM62
> >> > board.
> >>
> >> OK makes sense for distro use.
> >>
> >> Disabling unused ports leads into port names shifting, which we still can't
> >> easily tolerate until we have the DEVNAME:0.0 style addressing available for
> >> ports. So for now we still depend CONFIG_SERIAL_8250_NR_UARTS, eventually
> >> that too should become just a legacy ISA port array.. Meanwhile:
> >>
> >> Reviewed-by: Tony Lindgren <tony at atomide.com>
> >
> > I'd prefer to get Arnd's view on the topic as well (I kind of
> > recollect some historic discussion which I am not failing to trace
> > that there usage model doesn't exceed 4 and aliases could be used to
> > map these as required for the platform). The 8250 debate has been
> > popping on and off over the years.. Sigh.. memories of [1] still haunt
> > me.
>
> I don't recall any reason to have the limit set to the default
> of 4, other than possibly using excessive amounts of .data in
> vmlinux, but we have other serial port drivers that just hardcode
> a much larger value.
Thanks Arnd, we will queue this up.
Francesco: Could you respin with a more clear commit message to indicate
actual board usage instance.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
More information about the linux-arm-kernel
mailing list