|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 1/2] code style: Format ns16550 driver
On 16.02.2025 11:21, Oleksandr Andrushchenko wrote:
> --- a/xen/drivers/char/ns16550.c
> +++ b/xen/drivers/char/ns16550.c
> @@ -14,7 +14,7 @@
> * abstracted.
> */
> #if defined(CONFIG_HAS_PCI) && defined(CONFIG_X86)
> -# define NS16550_PCI
> +#define NS16550_PCI
> #endif
Hmm. Either form ought to be okay, so the line would want leaving untouched.
> @@ -43,12 +43,12 @@
>
> static struct ns16550 {
> int baud, clock_hz, data_bits, parity, stop_bits, fifo_size, irq;
> - u64 io_base; /* I/O port or memory-mapped I/O address. */
> + u64 io_base; /* I/O port or memory-mapped I/O address. */
> u64 io_size;
> int reg_shift; /* Bits to shift register offset by */
Breaking alignment between comments (also in the immediately following hunk),
while at the same time ...
> int reg_width; /* Size of access to use, the registers
> * themselves are still bytes */
... not taking care of the comment style violation here?
> @@ -63,8 +63,8 @@ static struct ns16550 {
> bool dw_usr_bsy;
> #ifdef NS16550_PCI
> /* PCI card parameters. */
> - bool pb_bdf_enable; /* if =1, pb-bdf effective, port behind bridge */
> - bool ps_bdf_enable; /* if =1, ps_bdf effective, port on pci card */
> + bool pb_bdf_enable; /* if =1, pb-bdf effective, port behind bridge */
> + bool ps_bdf_enable; /* if =1, ps_bdf effective, port on pci card */
(Just leaving this here for context of the earlier comment.)
> @@ -248,8 +249,9 @@ static int cf_check ns16550_tx_ready(struct serial_port
> *port)
> if ( ns16550_ioport_invalid(uart) )
> return -EIO;
>
> - return ( (ns_read_reg(uart, UART_LSR) &
> - uart->lsr_mask ) == uart->lsr_mask ) ? uart->fifo_size : 0;
> + return ((ns_read_reg(uart, UART_LSR) & uart->lsr_mask) == uart->lsr_mask)
> + ? uart->fifo_size
> + : 0;
Indentation of the ? and : lines is clearly wrong here? What is the tool
doing?
> @@ -275,9 +277,10 @@ static void pci_serial_early_init(struct ns16550 *uart)
> #ifdef NS16550_PCI
> if ( uart->bar && uart->io_base >= 0x10000 )
> {
> - pci_conf_write16(PCI_SBDF(0, uart->ps_bdf[0], uart->ps_bdf[1],
> - uart->ps_bdf[2]),
> - PCI_COMMAND, PCI_COMMAND_MEMORY);
> + pci_conf_write16(
> + PCI_SBDF(0, uart->ps_bdf[0], uart->ps_bdf[1], uart->ps_bdf[2]),
> + PCI_COMMAND,
> + PCI_COMMAND_MEMORY);
> return;
> }
Hmm, transforming a well-formed block into another well-formed one. No
gain? (Same again further down.)
> @@ -335,14 +338,14 @@ static void ns16550_setup_preirq(struct ns16550 *uart)
> else
> {
> /* Baud rate already set: read it out from the divisor latch. */
> - divisor = ns_read_reg(uart, UART_DLL);
> + divisor = ns_read_reg(uart, UART_DLL);
> divisor |= ns_read_reg(uart, UART_DLM) << 8;
An example where tabulation is being broken. There are quite a bit worse
ones further down.
> @@ -350,8 +353,10 @@ static void ns16550_setup_preirq(struct ns16550 *uart)
> ns_write_reg(uart, UART_MCR, UART_MCR_DTR | UART_MCR_RTS);
>
> /* Enable and clear the FIFOs. Set a large trigger threshold. */
> - ns_write_reg(uart, UART_FCR,
> - UART_FCR_ENABLE | UART_FCR_CLRX | UART_FCR_CLTX |
> UART_FCR_TRG14);
> + ns_write_reg(uart,
> + UART_FCR,
> + UART_FCR_ENABLE | UART_FCR_CLRX | UART_FCR_CLTX |
> + UART_FCR_TRG14);
What's the underlying indentation rule here? The way it's re-formatted
certainly looks odd to me. What we occasionally do in such cases is add
parentheses:
ns_write_reg(uart,
UART_FCR,
(UART_FCR_ENABLE | UART_FCR_CLRX | UART_FCR_CLTX |
UART_FCR_TRG14));
Also - does the format they apply demand one argument per line? Else
why not
ns_write_reg(uart, UART_FCR,
(UART_FCR_ENABLE | UART_FCR_CLRX | UART_FCR_CLTX |
UART_FCR_TRG14));
Plus what's their criteria to choose between this style of function calls
and the one in context higher up for calls to pci_conf_write16()?
> @@ -424,31 +430,37 @@ static void __init cf_check ns16550_init_postirq(struct
> serial_port *port)
>
> /* Calculate time to fill RX FIFO and/or empty TX FIFO for polling. */
> bits = uart->data_bits + uart->stop_bits + !!uart->parity;
> - uart->timeout_ms = max_t(
> - unsigned int, 1, (bits * uart->fifo_size * 1000) / uart->baud);
> + uart->timeout_ms =
> + max_t(unsigned int, 1, (bits * uart->fifo_size * 1000) / uart->baud);
Again both forms look conforming to me. I think there's a general issue
with the tool making transformations when none are needed. I won't
further point out any such.
> @@ -1197,7 +1174,9 @@ pci_uart_config(struct ns16550 *uart, bool skip_amt,
> unsigned int idx)
>
> nextf = (f || (pci_conf_read16(PCI_SBDF(0, b, d, f),
> PCI_HEADER_TYPE) &
> - 0x80)) ? f + 1 : 8;
> + 0x80))
> + ? f + 1
> + : 8;
Again the odd indentation of ? and :.
> @@ -1422,19 +1409,19 @@ struct serial_param_var {
> * com_console_options for serial port com1 and com2.
> */
> static const struct serial_param_var __initconst sp_vars[] = {
> - {"baud", baud_rate},
> - {"clock-hz", clock_hz},
> - {"data-bits", data_bits},
> - {"io-base", io_base},
> - {"irq", irq},
> - {"parity", parity},
> - {"reg-shift", reg_shift},
> - {"reg-width", reg_width},
> - {"stop-bits", stop_bits},
> + { "baud", baud_rate },
> + { "clock-hz", clock_hz },
> + { "data-bits", data_bits },
> + { "io-base", io_base },
> + { "irq", irq },
> + { "parity", parity },
> + { "reg-shift", reg_shift },
> + { "reg-width", reg_width },
> + { "stop-bits", stop_bits },
> #ifdef CONFIG_HAS_PCI
> - {"bridge", bridge_bdf},
> - {"dev", device},
> - {"port", port_bdf},
> + { "bridge", bridge_bdf },
> + { "dev", device },
> + { "port", port_bdf },
> #endif
> };
Interesting - here tabulation is being introduced.
> @@ -1706,7 +1704,7 @@ static void __init ns16550_parse_port_config(
> if ( !parse_namevalue_pairs(str, uart) )
> return;
>
> - config_parsed:
> +config_parsed:
This is a no-go - ./CODING_STYLE specifically says why this isn't appropriate.
All of the remarks aside, there are also a lot of good changes that are being
made.
Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |