On Wed, Nov 24, 2021 at 12:47:57PM +0100, Ruediger Willenberg wrote:
> Am 24.11.2021 um 11:08 schrieb Greg KH:
> > On Tue, Nov 23, 2021 at 12:14:46AM +0100, Ruediger Willenberg wrote:
> > > Find free uart_port struct in range 0 <= id < ULITE_NR_UARTS when
> > > the device tree port-number property is outside that range. This
> > > happens when there are other UART types in the system because the
> > > Xilinx device tree generator numbers all UARTs consecutively;
> > > as a result, not as many Uartlites as specified by the
> > > SERIAL_UARTLITE_NR_UARTS parameter could be successfully added.
> >
> > Ick. Please just remove that build option entirely, this should just
> > dynamically allocate new devices based on what is in the system.
> >
> > The driver should not care at build time about this.
> >
>
> Fully agree removing SERIAL_UARTLITE_NR_UARTS and making allocation dynamic
> is best.
> Please briefly advise on how to best handle the following resulting issue:
>
> In serial_core.c the following check occurs:
>
> int uart_add_one_port(struct uart_driver *drv, struct uart_port *uport)
> {
> ...
> if (uport->line >= drv->nr)
> return -EINVAL;
>
>
> To not let this fail on registering a legit uartlite port, should we
>
> * Set ulite_uart_driver.nr = INT_MAX before registering the driver
Or just 256, be kind :)
> * Adjust ulite_uart_driver.nr when adding or removing a port (surely with
> lock, but still smells)
Why do you need to change this when adding/removing a port?
> * do something blindingly obvious I'm missing?
I do not know, sorry, try it and see!
greg k-h
