devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jacky Huang <ychuang570808@gmail.com>
To: Jiri Slaby <jirislaby@kernel.org>,
	robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
	lee@kernel.org, mturquette@baylibre.com, sboyd@kernel.org,
	p.zabel@pengutronix.de, gregkh@linuxfoundation.org
Cc: devicetree@vger.kernel.org, linux-clk@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
	arnd@arndb.de, schung@nuvoton.com, mjchen@nuvoton.com,
	Jacky Huang <ychuang3@nuvoton.com>
Subject: Re: [PATCH v6 11/12] tty: serial: Add Nuvoton ma35d1 serial driver support
Date: Wed, 29 Mar 2023 16:06:31 +0800	[thread overview]
Message-ID: <89268a72-468f-415d-0f52-e1e2b8f1ad1e@gmail.com> (raw)
In-Reply-To: <f44fffcf-c592-0c73-6e6c-f5914de82503@kernel.org>

Dear Jiri,


Thanks for your advice.

On 2023/3/28 下午 05:23, Jiri Slaby wrote:
> On 28. 03. 23, 4:19, Jacky Huang wrote:
>> +static void transmit_chars(struct uart_ma35d1_port *up)
>> +{
>> +    struct circ_buf *xmit = &up->port.state->xmit;
>> +    int count;
>> +    u8 ch;
>> +
>> +    if (uart_tx_stopped(&up->port)) {
>> +        ma35d1serial_stop_tx(&up->port);
>> +        return;
>> +    }
>> +    if (uart_circ_empty(xmit)) {
>> +        __stop_tx(up);
>> +        return;
>> +    }
>
> Why is this necessary?
>

I will remove this reduntant uart_circ_empty() check.

>> +    count = UART_FIFO_DEPTH - ((serial_in(up, UART_REG_FSR) & 
>> FSR_TXPTR_MSK) >> 16);
>> +
>> +    uart_port_tx_limited(&up->port, ch, count,
>> +                 !(serial_in(up, UART_REG_FSR) & FSR_TX_FULL),
>> +                 serial_out(up, UART_REG_THR, ch),
>> +                 ({}));
>> +
>> +    if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
>> +        uart_write_wakeup(&up->port);
>> +
>> +    if (uart_circ_empty(xmit))
>> +        __stop_tx(up);
>
> uart_port_tx_limited() should take care about the above and this too, 
> right?

Yes, you are right. These two are also redundant. I will remove them.
Thank you.

>
>> +}
> ...
>> +static void receive_chars(struct uart_ma35d1_port *up)
>> +{
>> +    u8 flag;
>> +    u32 fsr;
>> +    unsigned int ch;
>
> Shouldn't ch be u8 too?

OK, I will fix it as u8.

>
>> +    int max_count = 256;
>> +
>> +    fsr = serial_in(up, UART_REG_FSR);
>> +    do {
>> +        flag = TTY_NORMAL;
>> +        up->port.icount.rx++;
>> +
>> +        if (unlikely(fsr & (FSR_BIF | FSR_FEF | FSR_PEF | 
>> FSR_RX_OVER_IF))) {
>> +            if (fsr & FSR_BIF) {
>> +                up->port.icount.brk++;
>> +                if (uart_handle_break(&up->port))
>> +                    continue;
>> +            }
>> +            if (fsr & FSR_FEF)
>> +                up->port.icount.frame++;
>> +            if (fsr & FSR_PEF)
>> +                up->port.icount.parity++;
>> +            if (fsr & FSR_RX_OVER_IF)
>> +                up->port.icount.overrun++;
>> +
>> +            serial_out(up, UART_REG_FSR, fsr &
>> +                   (FSR_BIF | FSR_FEF | FSR_PEF | FSR_RX_OVER_IF));
>> +
>> +            if (fsr & FSR_BIF)
>> +                flag = TTY_BREAK;
>> +            else if (fsr & FSR_PEF)
>> +                flag = TTY_PARITY;
>> +            else if (fsr & FSR_FEF)
>> +                flag = TTY_FRAME;
>> +        }
>> +
>> +        ch = serial_in(up, UART_REG_RBR);
>> +        if (uart_handle_sysrq_char(&up->port, ch))
>> +            continue;
>> +
>> +        spin_lock(&up->port.lock);
>> +        uart_insert_char(&up->port, fsr, FSR_RX_OVER_IF, ch, flag);
>> +        spin_unlock(&up->port.lock);
>> +
>> +        fsr = serial_in(up, UART_REG_FSR);
>> +    } while (!(fsr & FSR_RX_EMPTY) && (max_count-- > 0));
>> +
>> +    spin_lock(&up->port.lock);
>> +    tty_flip_buffer_push(&up->port.state->port);
>> +    spin_unlock(&up->port.lock);
>> +}
> ...
>> +static int ma35d1serial_remove(struct platform_device *dev)
>> +{
>> +    struct uart_port *port = platform_get_drvdata(dev);
>> +
>> +    if (port) {
>
> Can this ever be NULL?

OK, I will remove this NULL check.

>
>> + uart_remove_one_port(&ma35d1serial_reg, port);
>> +        free_irq(port->irq, port);
>> +    }
>> +    return 0;
>> +}
>> +
>> +static int ma35d1serial_suspend(struct platform_device *dev, 
>> pm_message_t state)
>> +{
>> +    int i;
>> +    struct uart_ma35d1_port *up;
>> +
>> +    if (dev->dev.of_node)
>> +        i = of_alias_get_id(dev->dev.of_node, "serial");
>> +    if (i < 0) {
>> +        dev_err(&dev->dev, "failed to get alias/pdev id, errno 
>> %d\n", i);
>> +        return i;
>> +    }
>> +    up = &ma35d1serial_ports[i];
>
> platform_get_drvdata(dev) ?

We will fix it.

>
>> +    if (i == 0) {
>> +        up->console_baud_rate = serial_in(up, UART_REG_BAUD);
>> +        up->console_line = serial_in(up, UART_REG_LCR);
>> +        up->console_int = serial_in(up, UART_REG_IER);
>> +    }
>> +    return 0;
>> +}
>> +
>> +static int ma35d1serial_resume(struct platform_device *dev)
>> +{
>> +    int i;
>> +    struct uart_ma35d1_port *up;
>> +
>> +    if (dev->dev.of_node)
>> +        i = of_alias_get_id(dev->dev.of_node, "serial");
>> +    if (i < 0) {
>> +        dev_err(&dev->dev, "failed to get alias/pdev id, errno 
>> %d\n", i);
>> +        return i;
>> +    }
>> +    up = &ma35d1serial_ports[i];
>> +    if (i == 0) {
>> +        serial_out(up, UART_REG_BAUD, up->console_baud_rate);
>> +        serial_out(up, UART_REG_LCR, up->console_line);
>> +        serial_out(up, UART_REG_IER, up->console_int);
>> +    }
>> +    return 0;
>> +}
>
> No uart_suspend_port()/uart_resume_port()? You don't wait for 
> transmitter to be empty in suspend. You don't stop tx etc.
>

We will fix it in the next version.

>> +static struct platform_driver ma35d1serial_driver = {
>> +    .probe      = ma35d1serial_probe,
>> +    .remove     = ma35d1serial_remove,
>> +    .suspend    = ma35d1serial_suspend,
>> +    .resume     = ma35d1serial_resume,
>> +    .driver     = {
>> +        .name   = "ma35d1-uart",
>> +        .owner  = THIS_MODULE,
>> +        .of_match_table = of_match_ptr(ma35d1_serial_of_match),
>> +    },
>> +};
>> +
>> +static int __init ma35d1serial_init(void)
>> +{
>> +    int ret;
>> +
>> +    ret = uart_register_driver(&ma35d1serial_reg);
>> +    if (ret)
>> +        return ret;
>> +    ret = platform_driver_register(&ma35d1serial_driver);
>> +    if (ret)
>> +        uart_unregister_driver(&ma35d1serial_reg);
>> +    return ret;
>> +}
>> +
>> +static void __exit ma35d1serial_exit(void)
>> +{
>> +    platform_driver_unregister(&ma35d1serial_driver);
>> +    uart_unregister_driver(&ma35d1serial_reg);
>> +}
>> +
>> +module_init(ma35d1serial_init);
>> +module_exit(ma35d1serial_exit);
>> +
>> +MODULE_LICENSE("GPL");
>> +MODULE_DESCRIPTION("MA35D1 serial driver");
>
>
>> +MODULE_ALIAS_CHARDEV_MAJOR(TTY_MAJOR);
>
> Why is this needed? How are other platform drivers autoloaded?
>
> thanks,

Yes, it's not needed. I will remove it.


Best regards,
Jacky Huang




  reply	other threads:[~2023-03-29  8:06 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-28  2:19 [PATCH v6 00/12] Introduce Nuvoton ma35d1 SoC Jacky Huang
2023-03-28  2:19 ` [PATCH v6 01/12] arm64: Kconfig.platforms: Add config for Nuvoton MA35 platform Jacky Huang
2023-03-28  2:19 ` [PATCH v6 02/12] arm64: defconfig: Add support for Nuvoton MA35 family SoCs Jacky Huang
2023-03-28  2:19 ` [PATCH v6 03/12] dt-bindings: clock: nuvoton: add binding for ma35d1 clock controller Jacky Huang
2023-03-29  8:14   ` Krzysztof Kozlowski
2023-03-28  2:19 ` [PATCH v6 04/12] dt-bindings: reset: nuvoton: add binding for ma35d1 IP reset control Jacky Huang
2023-03-28 17:48   ` Stephen Boyd
2023-03-29  8:53     ` Jacky Huang
2023-03-29  8:17   ` Krzysztof Kozlowski
2023-03-29  9:12     ` Jacky Huang
2023-03-29  9:27       ` Krzysztof Kozlowski
2023-03-29  9:33         ` Jacky Huang
2023-03-28  2:19 ` [PATCH v6 05/12] dt-bindings: mfd: syscon: Add nuvoton,ma35d1-sys compatible Jacky Huang
2023-04-05 15:27   ` Lee Jones
2023-03-28  2:19 ` [PATCH v6 06/12] dt-bindings: arm: Add initial bindings for Nuvoton platform Jacky Huang
2023-03-28 15:41   ` kernel test robot
2023-03-29  8:19   ` Krzysztof Kozlowski
2023-03-29  8:32     ` Jacky Huang
2023-03-29 13:07   ` Rob Herring
2023-03-30 10:41     ` Jacky Huang
2023-03-30 13:25       ` Krzysztof Kozlowski
2023-03-31  2:15         ` Jacky Huang
2023-04-03 20:33           ` Rob Herring
2023-04-06  2:09             ` Jacky Huang
2023-03-28  2:19 ` [PATCH v6 07/12] dt-bindings: serial: Document ma35d1 uart controller Jacky Huang
2023-03-29  8:20   ` Krzysztof Kozlowski
2023-03-29  8:44     ` Jacky Huang
2023-03-30  7:33       ` Krzysztof Kozlowski
2023-03-30 10:52         ` Jacky Huang
2023-03-30 13:12           ` Rob Herring
2023-03-31  2:03             ` Jacky Huang
2023-03-28  2:19 ` [PATCH v6 08/12] arm64: dts: nuvoton: Add initial ma35d1 device tree Jacky Huang
2023-03-28 17:57   ` Stephen Boyd
2023-03-29  2:03     ` Jacky Huang
2023-03-29  2:19       ` Stephen Boyd
2023-03-29  2:39         ` Jacky Huang
2023-03-29  2:46           ` Stephen Boyd
2023-03-29  3:13             ` Jacky Huang
2023-03-29  3:25               ` Stephen Boyd
2023-03-29  3:43                 ` Jacky Huang
2023-03-29  3:54                   ` Stephen Boyd
2023-03-29  6:02                     ` Jacky Huang
2023-03-29 17:52                       ` Stephen Boyd
2023-03-29  8:21   ` Krzysztof Kozlowski
2023-03-29  8:36     ` Jacky Huang
2023-03-28  2:19 ` [PATCH v6 09/12] clk: nuvoton: Add clock driver for ma35d1 clock controller Jacky Huang
2023-03-28 18:18   ` Stephen Boyd
2023-03-30 10:36     ` Jacky Huang
2023-03-28  2:19 ` [PATCH v6 10/12] reset: Add Nuvoton ma35d1 reset driver support Jacky Huang
2023-04-24 20:02   ` Philipp Zabel
2023-04-25  1:22     ` Jacky Huang
2023-03-28  2:19 ` [PATCH v6 11/12] tty: serial: Add Nuvoton ma35d1 serial " Jacky Huang
2023-03-28  9:23   ` Jiri Slaby
2023-03-29  8:06     ` Jacky Huang [this message]
2023-03-31  0:29   ` kernel test robot
2023-03-28  2:19 ` [PATCH v6 12/12] MAINTAINERS: Add entry for NUVOTON MA35 Jacky Huang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=89268a72-468f-415d-0f52-e1e2b8f1ad1e@gmail.com \
    --to=ychuang570808@gmail.com \
    --cc=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jirislaby@kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=lee@kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=mjchen@nuvoton.com \
    --cc=mturquette@baylibre.com \
    --cc=p.zabel@pengutronix.de \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=schung@nuvoton.com \
    --cc=ychuang3@nuvoton.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).