Thread (5 messages) flat view 5 messages, 3 authors, 2021-11-24

Re: [PATCH v3] serial: uartlite: Move out-of-range port-numbers into ULITE_NR_UARTS range

From: Greg KH <gregkh@linuxfoundation.org>
Date: 2021-11-24 14:07:12

On Wed, Nov 24, 2021 at 12:47:57PM +0100, Ruediger Willenberg wrote:
Am 24.11.2021 um 11:08 schrieb Greg KH:
quoted
On Tue, Nov 23, 2021 at 12:14:46AM +0100, Ruediger Willenberg wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help