[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/2] code style: Format ns16550 driver


  • To: Oleksandr Andrushchenko <andr2000@xxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 17 Feb 2025 11:20:35 +0100
  • Autocrypt: addr=jbeulich@xxxxxxxx; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL
  • Cc: sstabellini@xxxxxxxxxx, Artem_Mygaiev@xxxxxxxx, Luca.Fancellu@xxxxxxx, roger.pau@xxxxxxxxxx, marmarek@xxxxxxxxxxxxxxxxxxxxxx, andrew.cooper3@xxxxxxxxxx, anthony.perard@xxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 17 Feb 2025 10:20:41 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.