From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: matthew.gerlach@linux.intel.com
Cc: hao.wu@intel.com, yilun.xu@intel.com, russell.h.weight@intel.com,
basheer.ahmed.muddebihal@intel.com, trix@redhat.com,
mdf@kernel.org, linux-fpga@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
tianfei.zhang@intel.com, corbet@lwn.net,
gregkh@linuxfoundation.org, linux-serial@vger.kernel.org,
jirislaby@kernel.org, geert+renesas@glider.be,
niklas.soderlund+renesas@ragnatech.se, phil.edworthy@renesas.com,
macro@orcam.me.uk, johan@kernel.org, lukas@wunner.de
Subject: Re: [PATCH v1 5/5] tty: serial: 8250: add DFL bus driver for Altera 16550.
Date: Tue, 6 Sep 2022 23:24:45 +0300 [thread overview]
Message-ID: <YxesjfoBagiC3gGE@smile.fi.intel.com> (raw)
In-Reply-To: <20220906190426.3139760-6-matthew.gerlach@linux.intel.com>
On Tue, Sep 06, 2022 at 12:04:26PM -0700, matthew.gerlach@linux.intel.com wrote:
> From: Matthew Gerlach <matthew.gerlach@linux.intel.com>
>
> Add a Device Feature List (DFL) bus driver for the Altera
> 16550 implementation of UART.
...
> +#include <linux/dfl.h>
> +#include <linux/version.h>
Hmm... Do we need this?
> +#include <linux/serial.h>
> +#include <linux/serial_8250.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/bitfield.h>
> +#include <linux/io-64-nonatomic-lo-hi.h>
Can this block be sorted alphabetically?
...
> +int feature_uart_walk(struct dfl_uart *dfluart, resource_size_t max)
> +{
> + void __iomem *param_base;
> + int off;
> + u64 v;
> +
> + v = readq(dfluart->csr_base + DFHv1_CSR_ADDR);
> + dfluart->csr_addr = FIELD_GET(DFHv1_CSR_ADDR_MASK, v);
> +
> + v = readq(dfluart->csr_base + DFHv1_CSR_SIZE_GRP);
> + dfluart->csr_size = FIELD_GET(DFHv1_CSR_SIZE_GRP_SIZE, v);
> +
> + if (dfluart->csr_addr == 0 || dfluart->csr_size == 0) {
> + dev_err(dfluart->dev, "FIXME bad dfh address and size\n");
DFH ?
> + return -EINVAL;
> + }
> +
> + if (!FIELD_GET(DFHv1_CSR_SIZE_GRP_HAS_PARAMS, v)) {
> + dev_err(dfluart->dev, "missing required parameters\n");
Not sure I understood what parameters are here. FPGA VHDL? Configuration? RTL?
> + return -EINVAL;
> + }
> +
> + param_base = dfluart->csr_base + DFHv1_PARAM_HDR;
> +
> + off = dfl_find_param(param_base, max, DFHv1_PARAM_ID_CLK_FRQ);
> + if (off < 0) {
> + dev_err(dfluart->dev, "missing CLK_FRQ param\n");
> + return -EINVAL;
> + }
> +
> + dfluart->uart_clk = readq(param_base + off + DFHv1_PARAM_DATA);
> + dev_dbg(dfluart->dev, "UART_CLK_ID %llu Hz\n", dfluart->uart_clk);
Isn't this available via normal interfaces to user?
> + off = dfl_find_param(param_base, max, DFHv1_PARAM_ID_FIFO_LEN);
> + if (off < 0) {
> + dev_err(dfluart->dev, "missing FIFO_LEN param\n");
> + return -EINVAL;
> + }
> +
> + dfluart->fifo_len = readq(param_base + off + DFHv1_PARAM_DATA);
> + dev_dbg(dfluart->dev, "UART_FIFO_ID fifo_len %llu\n", dfluart->fifo_len);
> +
> + off = dfl_find_param(param_base, max, DFHv1_PARAM_ID_REG_LAYOUT);
> + if (off < 0) {
> + dev_err(dfluart->dev, "missing REG_LAYOUT param\n");
> + return -EINVAL;
> + }
> +
> + v = readq(param_base + off + DFHv1_PARAM_DATA);
> + dfluart->fifo_size = FIELD_GET(DFHv1_PARAM_ID_REG_WIDTH, v);
> + dfluart->reg_shift = FIELD_GET(DFHv1_PARAM_ID_REG_SHIFT, v);
> + dev_dbg(dfluart->dev, "UART_LAYOUT_ID width %d shift %d\n",
> + dfluart->fifo_size, dfluart->reg_shift);
> +
> + return 0;
> +}
> +
> +static int dfl_uart_probe(struct dfl_device *dfl_dev)
> +{
> + struct device *dev = &dfl_dev->dev;
> + struct uart_8250_port uart;
> + struct dfl_uart *dfluart;
> + int ret;
> +
> + memset(&uart, 0, sizeof(uart));
> +
> + dfluart = devm_kzalloc(dev, sizeof(*dfluart), GFP_KERNEL);
> + if (!dfluart)
> + return -ENOMEM;
> +
> + dfluart->csr_base = devm_ioremap_resource(dev, &dfl_dev->mmio_res);
> + if (IS_ERR(dfluart->csr_base)) {
> + dev_err(dev, "failed to get mem resource!\n");
The above call have a few different messages depending on error code.
No need to repeat this.
> + return PTR_ERR(dfluart->csr_base);
> + }
> +
> + dfluart->dev = dev;
> +
> + ret = feature_uart_walk(dfluart, resource_size(&dfl_dev->mmio_res));
> + if (ret < 0) {
> + dev_err(dev, "failed to uart feature walk %d\n", ret);
> + return -EINVAL;
Why shadowing error code?
What about
return dev_err_probe(dev, ret, ...);
?
> + }
> +
> + dev_dbg(dev, "nr_irqs %d %p\n", dfl_dev->num_irqs, dfl_dev->irqs);
> +
> + if (dfl_dev->num_irqs == 1)
> + uart.port.irq = dfl_dev->irqs[0];
> +
> + switch (dfluart->fifo_len) {
> + case 32:
> + uart.port.type = PORT_ALTR_16550_F32;
> + break;
> +
> + case 64:
> + uart.port.type = PORT_ALTR_16550_F64;
> + break;
> +
> + case 128:
> + uart.port.type = PORT_ALTR_16550_F128;
> + break;
> +
> + default:
> + dev_err(dev, "bad fifo_len %llu\n", dfluart->fifo_len);
> + return -EINVAL;
> + }
> +
> + uart.port.iotype = UPIO_MEM32;
> + uart.port.membase = dfluart->csr_base + dfluart->csr_addr;
> + uart.port.mapsize = dfluart->csr_size;
> + uart.port.regshift = dfluart->reg_shift;
> + uart.port.uartclk = dfluart->uart_clk;
> +
> + /* register the port */
> + ret = serial8250_register_8250_port(&uart);
> + if (ret < 0) {
> + dev_err(dev, "unable to register 8250 port %d.\n", ret);
> + return -EINVAL;
> + }
> + dev_info(dev, "serial8250_register_8250_port %d\n", ret);
> + dfluart->line = ret;
> + dev_set_drvdata(dev, dfluart);
> +
> + return 0;
> +}
> +
> +static void dfl_uart_remove(struct dfl_device *dfl_dev)
> +{
> + struct dfl_uart *dfluart = dev_get_drvdata(&dfl_dev->dev);
> +
> + if (dfluart->line > 0)
> + serial8250_unregister_port(dfluart->line);
> +}
...
> +#define FME_FEATURE_ID_UART 0x24
Purpose of this definition? For me with or without is still an ID.
> +static const struct dfl_device_id dfl_uart_ids[] = {
> + { FME_ID, FME_FEATURE_ID_UART },
> + { }
> +};
...
> +static struct dfl_driver dfl_uart_driver = {
> + .drv = {
> + .name = "dfl-uart",
> + },
> + .id_table = dfl_uart_ids,
> + .probe = dfl_uart_probe,
> + .remove = dfl_uart_remove,
> +};
> +
No need to have this blank line.
> +module_dfl_driver(dfl_uart_driver);
...
> +MODULE_DEVICE_TABLE(dfl, dfl_uart_ids);
Move this closer to the definition. That's how other drivers do in the kernel.
...
> --- a/drivers/tty/serial/8250/Kconfig
> +++ b/drivers/tty/serial/8250/Kconfig
> --- a/drivers/tty/serial/8250/Makefile
> +++ b/drivers/tty/serial/8250/Makefile
I know that the records in those files are not sorted, but can you try hard
to find the best place for them in those files from sorting point of view?
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2022-09-06 20:24 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-06 19:04 [PATCH v1 0/5] Enhance definition of DFH and use enhancements for uart driver matthew.gerlach
2022-09-06 19:04 ` [PATCH v1 1/5] Documentation: fpga: dfl: Add documentation for DFHv1 matthew.gerlach
2022-09-06 20:08 ` Andy Shevchenko
2022-09-07 19:15 ` matthew.gerlach
2022-09-11 9:57 ` Xu Yilun
2022-09-11 16:06 ` matthew.gerlach
2022-09-06 19:04 ` [PATCH v1 2/5] fpga: dfl: Move the DFH definitions matthew.gerlach
2022-09-06 20:07 ` Andy Shevchenko
2022-09-07 21:01 ` matthew.gerlach
2022-09-07 5:08 ` Greg KH
2022-09-11 15:40 ` matthew.gerlach
2022-09-11 17:54 ` Geert Uytterhoeven
2022-09-11 8:04 ` Xu Yilun
2022-09-11 16:13 ` matthew.gerlach
2022-09-06 19:04 ` [PATCH v1 3/5] fpga: dfl: Add DFHv1 Register Definitions matthew.gerlach
2022-09-11 8:27 ` Xu Yilun
2022-09-11 16:21 ` matthew.gerlach
2022-09-06 19:04 ` [PATCH v1 4/5] fpga: dfl: add generic support for MSIX interrupts matthew.gerlach
2022-09-06 20:15 ` Andy Shevchenko
2022-09-07 21:37 ` matthew.gerlach
2022-09-08 11:04 ` Andy Shevchenko
2022-09-08 17:34 ` matthew.gerlach
2022-09-08 17:51 ` Andy Shevchenko
2022-09-08 19:28 ` Geert Uytterhoeven
2022-09-08 20:21 ` matthew.gerlach
2022-09-11 9:06 ` Xu Yilun
2022-09-06 19:04 ` [PATCH v1 5/5] tty: serial: 8250: add DFL bus driver for Altera 16550 matthew.gerlach
2022-09-06 20:24 ` Andy Shevchenko [this message]
2022-09-08 18:27 ` matthew.gerlach
2022-09-08 21:16 ` Andy Shevchenko
2022-09-11 15:56 ` matthew.gerlach
2022-09-12 10:54 ` Andy Shevchenko
2022-09-06 21:43 ` kernel test robot
2022-09-11 9:41 ` Xu Yilun
2022-09-12 15:29 ` matthew.gerlach
2022-09-13 2:48 ` Xu Yilun
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=YxesjfoBagiC3gGE@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=basheer.ahmed.muddebihal@intel.com \
--cc=corbet@lwn.net \
--cc=geert+renesas@glider.be \
--cc=gregkh@linuxfoundation.org \
--cc=hao.wu@intel.com \
--cc=jirislaby@kernel.org \
--cc=johan@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fpga@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=macro@orcam.me.uk \
--cc=matthew.gerlach@linux.intel.com \
--cc=mdf@kernel.org \
--cc=niklas.soderlund+renesas@ragnatech.se \
--cc=phil.edworthy@renesas.com \
--cc=russell.h.weight@intel.com \
--cc=tianfei.zhang@intel.com \
--cc=trix@redhat.com \
--cc=yilun.xu@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.