2020-08-12 12:36:49

by Mateusz Holenko

[permalink] [raw]
Subject: [PATCH v10 0/5] LiteX SoC controller and LiteUART serial driver

This patchset introduces support for LiteX SoC Controller
and LiteUART - serial device from LiteX SoC builder
(https://github.com/enjoy-digital/litex).

In the following patchset I will add
a new mor1kx-based (OpenRISC) platform that
uses this device.

Later I plan to extend this platform by
adding support for more devices from LiteX suite.

Changes in v10:
- added casting to avoid sparse warnings in the SoC Controller's driver

Changes in v9:
- fixed the `reg` node notation in the DT example
- added exporting of the `litex_set_reg`/`litex_get_reg` symbols

Changes in v8:
- fixed help messages in LiteUART's KConfig
- removed dependency between LiteUART and LiteX SoC drivers
- removed `litex_check_accessors()` helper function
- added crashing (BUG) on the failed LiteX CSR access test

Changes in v7:
- added missing include directive in UART's driver

Changes in v6:
- changed accessors in SoC Controller's driver
- reworked UART driver

Changes in v5:
- added Reviewed-by tag
- removed custom accessors from SoC Controller's driver
- fixed error checking in SoC Controller's driver

Changes in v4:
- fixed copyright headers
- fixed SoC Controller's yaml
- simplified SoC Controller's driver

Changes in v3:
- added Acked-by and Reviewed-by tags
- introduced LiteX SoC Controller driver
- removed endianness detection (handled now by LiteX SoC Controller driver)
- modified litex.h header
- DTS aliases for LiteUART made optional
- renamed SERIAL_LITEUART_NR_PORTS to SERIAL_LITEUART_MAX_PORTS
- changed PORT_LITEUART from 122 to 123

Changes in v2:
- binding description rewritten to a yaml schema file
- added litex.h header with common register access functions

Filip Kokosinski (3):
dt-bindings: vendor: add vendor prefix for LiteX
dt-bindings: serial: document LiteUART bindings
drivers/tty/serial: add LiteUART driver

Pawel Czarnecki (2):
dt-bindings: soc: document LiteX SoC Controller bindings
drivers/soc/litex: add LiteX SoC Controller driver

.../bindings/serial/litex,liteuart.yaml | 38 ++
.../soc/litex/litex,soc-controller.yaml | 39 ++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
MAINTAINERS | 9 +
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/litex/Kconfig | 15 +
drivers/soc/litex/Makefile | 3 +
drivers/soc/litex/litex_soc_ctrl.c | 194 +++++++++
drivers/tty/serial/Kconfig | 32 ++
drivers/tty/serial/Makefile | 1 +
drivers/tty/serial/liteuart.c | 402 ++++++++++++++++++
include/linux/litex.h | 24 ++
13 files changed, 761 insertions(+)
create mode 100644 Documentation/devicetree/bindings/serial/litex,liteuart.yaml
create mode 100644 Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml
create mode 100644 drivers/soc/litex/Kconfig
create mode 100644 drivers/soc/litex/Makefile
create mode 100644 drivers/soc/litex/litex_soc_ctrl.c
create mode 100644 drivers/tty/serial/liteuart.c
create mode 100644 include/linux/litex.h

--
2.25.1


2020-08-12 12:37:18

by Mateusz Holenko

[permalink] [raw]
Subject: [PATCH v10 1/5] dt-bindings: vendor: add vendor prefix for LiteX

From: Filip Kokosinski <[email protected]>

Add vendor prefix for LiteX SoC builder.

Signed-off-by: Filip Kokosinski <[email protected]>
Signed-off-by: Mateusz Holenko <[email protected]>
Acked-by: Rob Herring <[email protected]>
---

Notes:
No changes in v10.

No changes in v9.

No changes in v8.

No changes in v7.

No changes in v6.

No changes in v5.

No changes in v4.

Changes in v3:
- added Acked-by tag

No changes in v2.

Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index d3891386d671..9aae6c56d7a3 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -571,6 +571,8 @@ patternProperties:
description: Linux-specific binding
"^linx,.*":
description: Linx Technologies
+ "^litex,.*":
+ description: LiteX SoC builder
"^lltc,.*":
description: Linear Technology Corporation
"^logicpd,.*":
--
2.25.1

2020-08-12 12:37:43

by Mateusz Holenko

[permalink] [raw]
Subject: [PATCH v10 3/5] drivers/soc/litex: add LiteX SoC Controller driver

From: Pawel Czarnecki <[email protected]>

This commit adds driver for the FPGA-based LiteX SoC
Controller from LiteX SoC builder.

Co-developed-by: Mateusz Holenko <[email protected]>
Signed-off-by: Mateusz Holenko <[email protected]>
Signed-off-by: Pawel Czarnecki <[email protected]>
---

Notes:
Changes in v10:
- added casting to avoid sparse warnings in the SoC Controller's driver

Changes in v9:
- added exporting of the `litex_set_reg`/`litex_get_reg` symbols

Changes in v8:
- removed `litex_check_accessors()` helper function
- added crashing (BUG) on the failed LiteX CSR access test

No changes in v7.

Changes in v6:
- added dependency on OF || COMPILE_TEST
- used le32_to_cpu(readl(addr)) instead of __raw_readl
and writel(cpu_to_le32(value), addr) instead of __raw_writel
to take advantage of memory barriers provided by readl/writel

Changes in v5:
- removed helper accessors and used __raw_readl/__raw_writel instead
- fixed checking for errors in litex_soc_ctrl_probe

Changes in v4:
- fixed indent in Kconfig's help section
- fixed copyright header
- changed compatible to "litex,soc-controller"
- simplified litex_soc_ctrl_probe
- removed unnecessary litex_soc_ctrl_remove

This commit has been introduced in v3 of the patchset.

It includes a simplified version of common 'litex.h'
header introduced in v2 of the patchset.

MAINTAINERS | 2 +
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/litex/Kconfig | 15 +++
drivers/soc/litex/Makefile | 3 +
drivers/soc/litex/litex_soc_ctrl.c | 194 +++++++++++++++++++++++++++++
include/linux/litex.h | 24 ++++
7 files changed, 240 insertions(+)
create mode 100644 drivers/soc/litex/Kconfig
create mode 100644 drivers/soc/litex/Makefile
create mode 100644 drivers/soc/litex/litex_soc_ctrl.c
create mode 100644 include/linux/litex.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 39be98db7418..4d70a1b22a87 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9840,6 +9840,8 @@ M: Karol Gugala <[email protected]>
M: Mateusz Holenko <[email protected]>
S: Maintained
F: Documentation/devicetree/bindings/*/litex,*.yaml
+F: drivers/soc/litex/litex_soc_ctrl.c
+F: include/linux/litex.h

LIVE PATCHING
M: Josh Poimboeuf <[email protected]>
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index 425ab6f7e375..d097d070f579 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -9,6 +9,7 @@ source "drivers/soc/bcm/Kconfig"
source "drivers/soc/fsl/Kconfig"
source "drivers/soc/imx/Kconfig"
source "drivers/soc/ixp4xx/Kconfig"
+source "drivers/soc/litex/Kconfig"
source "drivers/soc/mediatek/Kconfig"
source "drivers/soc/qcom/Kconfig"
source "drivers/soc/renesas/Kconfig"
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 36452bed86ef..0b16108823ef 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_ARCH_GEMINI) += gemini/
obj-y += imx/
obj-$(CONFIG_ARCH_IXP4XX) += ixp4xx/
obj-$(CONFIG_SOC_XWAY) += lantiq/
+obj-$(CONFIG_LITEX_SOC_CONTROLLER) += litex/
obj-y += mediatek/
obj-y += amlogic/
obj-y += qcom/
diff --git a/drivers/soc/litex/Kconfig b/drivers/soc/litex/Kconfig
new file mode 100644
index 000000000000..c974ec3846bc
--- /dev/null
+++ b/drivers/soc/litex/Kconfig
@@ -0,0 +1,15 @@
+# SPDX-License_Identifier: GPL-2.0
+
+menu "Enable LiteX SoC Builder specific drivers"
+
+config LITEX_SOC_CONTROLLER
+ tristate "Enable LiteX SoC Controller driver"
+ depends on OF || COMPILE_TEST
+ help
+ This option enables the SoC Controller Driver which verifies
+ LiteX CSR access and provides common litex_get_reg/litex_set_reg
+ accessors.
+ All drivers that use functions from litex.h must depend on
+ LITEX_SOC_CONTROLLER.
+
+endmenu
diff --git a/drivers/soc/litex/Makefile b/drivers/soc/litex/Makefile
new file mode 100644
index 000000000000..98ff7325b1c0
--- /dev/null
+++ b/drivers/soc/litex/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License_Identifier: GPL-2.0
+
+obj-$(CONFIG_LITEX_SOC_CONTROLLER) += litex_soc_ctrl.o
diff --git a/drivers/soc/litex/litex_soc_ctrl.c b/drivers/soc/litex/litex_soc_ctrl.c
new file mode 100644
index 000000000000..08330c9872b0
--- /dev/null
+++ b/drivers/soc/litex/litex_soc_ctrl.c
@@ -0,0 +1,194 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * LiteX SoC Controller Driver
+ *
+ * Copyright (C) 2020 Antmicro <http://www.antmicro.com>
+ *
+ */
+
+#include <linux/litex.h>
+#include <linux/device.h>
+#include <linux/errno.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/printk.h>
+#include <linux/module.h>
+#include <linux/errno.h>
+#include <linux/io.h>
+
+/*
+ * The parameters below are true for LiteX SoC
+ * configured for 8-bit CSR Bus, 32-bit aligned.
+ *
+ * Supporting other configurations will require
+ * extending the logic in this header.
+ */
+#define LITEX_REG_SIZE 0x4
+#define LITEX_SUBREG_SIZE 0x1
+#define LITEX_SUBREG_SIZE_BIT (LITEX_SUBREG_SIZE * 8)
+
+static DEFINE_SPINLOCK(csr_lock);
+
+/*
+ * LiteX SoC Generator, depending on the configuration,
+ * can split a single logical CSR (Control & Status Register)
+ * into a series of consecutive physical registers.
+ *
+ * For example, in the configuration with 8-bit CSR Bus,
+ * 32-bit aligned (the default one for 32-bit CPUs) a 32-bit
+ * logical CSR will be generated as four 32-bit physical registers,
+ * each one containing one byte of meaningful data.
+ *
+ * For details see: https://github.com/enjoy-digital/litex/wiki/CSR-Bus
+ *
+ * The purpose of `litex_set_reg`/`litex_get_reg` is to implement
+ * the logic of writing to/reading from the LiteX CSR in a single
+ * place that can be then reused by all LiteX drivers.
+ */
+void litex_set_reg(void __iomem *reg, unsigned long reg_size,
+ unsigned long val)
+{
+ unsigned long shifted_data, shift, i;
+ unsigned long flags;
+
+ spin_lock_irqsave(&csr_lock, flags);
+
+ for (i = 0; i < reg_size; ++i) {
+ shift = ((reg_size - i - 1) * LITEX_SUBREG_SIZE_BIT);
+ shifted_data = val >> shift;
+
+ writel((u32 __force)cpu_to_le32(shifted_data), reg + (LITEX_REG_SIZE * i));
+ }
+
+ spin_unlock_irqrestore(&csr_lock, flags);
+}
+EXPORT_SYMBOL_GPL(litex_set_reg);
+
+unsigned long litex_get_reg(void __iomem *reg, unsigned long reg_size)
+{
+ unsigned long shifted_data, shift, i;
+ unsigned long result = 0;
+ unsigned long flags;
+
+ spin_lock_irqsave(&csr_lock, flags);
+
+ for (i = 0; i < reg_size; ++i) {
+ shifted_data = le32_to_cpu((__le32 __force)readl(reg + (LITEX_REG_SIZE * i)));
+
+ shift = ((reg_size - i - 1) * LITEX_SUBREG_SIZE_BIT);
+ result |= (shifted_data << shift);
+ }
+
+ spin_unlock_irqrestore(&csr_lock, flags);
+
+ return result;
+}
+EXPORT_SYMBOL_GPL(litex_get_reg);
+
+#define SCRATCH_REG_OFF 0x04
+#define SCRATCH_REG_SIZE 4
+#define SCRATCH_REG_VALUE 0x12345678
+#define SCRATCH_TEST_VALUE 0xdeadbeef
+
+/*
+ * Check LiteX CSR read/write access
+ *
+ * This function reads and writes a scratch register in order
+ * to verify if CSR access works.
+ *
+ * In case any problems are detected, the driver should panic.
+ *
+ * Access to the LiteX CSR is, by design, done in CPU native
+ * endianness. The driver should not dynamically configure
+ * access functions when the endianness mismatch is detected.
+ * Such situation indicates problems in the soft SoC design
+ * and should be solved at the LiteX generator level,
+ * not in the software.
+ */
+static int litex_check_csr_access(void __iomem *reg_addr)
+{
+ unsigned long reg;
+
+ reg = litex_get_reg(reg_addr + SCRATCH_REG_OFF, SCRATCH_REG_SIZE);
+
+ if (reg != SCRATCH_REG_VALUE) {
+ panic("Scratch register read error! Expected: 0x%x but got: 0x%lx",
+ SCRATCH_REG_VALUE, reg);
+ return -EINVAL;
+ }
+
+ litex_set_reg(reg_addr + SCRATCH_REG_OFF,
+ SCRATCH_REG_SIZE, SCRATCH_TEST_VALUE);
+ reg = litex_get_reg(reg_addr + SCRATCH_REG_OFF, SCRATCH_REG_SIZE);
+
+ if (reg != SCRATCH_TEST_VALUE) {
+ panic("Scratch register write error! Expected: 0x%x but got: 0x%lx",
+ SCRATCH_TEST_VALUE, reg);
+ return -EINVAL;
+ }
+
+ /* restore original value of the SCRATCH register */
+ litex_set_reg(reg_addr + SCRATCH_REG_OFF,
+ SCRATCH_REG_SIZE, SCRATCH_REG_VALUE);
+
+ /* Set flag for other drivers */
+ pr_info("LiteX SoC Controller driver initialized");
+
+ return 0;
+}
+
+struct litex_soc_ctrl_device {
+ void __iomem *base;
+};
+
+static const struct of_device_id litex_soc_ctrl_of_match[] = {
+ {.compatible = "litex,soc-controller"},
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, litex_soc_ctrl_of_match);
+
+static int litex_soc_ctrl_probe(struct platform_device *pdev)
+{
+ int result;
+ struct device *dev;
+ struct device_node *node;
+ struct litex_soc_ctrl_device *soc_ctrl_dev;
+
+ dev = &pdev->dev;
+ node = dev->of_node;
+ if (!node)
+ return -ENODEV;
+
+ soc_ctrl_dev = devm_kzalloc(dev, sizeof(*soc_ctrl_dev), GFP_KERNEL);
+ if (!soc_ctrl_dev)
+ return -ENOMEM;
+
+ soc_ctrl_dev->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(soc_ctrl_dev->base))
+ return PTR_ERR(soc_ctrl_dev->base);
+
+ result = litex_check_csr_access(soc_ctrl_dev->base);
+ if (result) {
+ // LiteX CSRs access is broken which means that
+ // none of LiteX drivers will most probably
+ // operate correctly
+ BUG();
+ }
+
+ return 0;
+}
+
+static struct platform_driver litex_soc_ctrl_driver = {
+ .driver = {
+ .name = "litex-soc-controller",
+ .of_match_table = of_match_ptr(litex_soc_ctrl_of_match)
+ },
+ .probe = litex_soc_ctrl_probe,
+};
+
+module_platform_driver(litex_soc_ctrl_driver);
+MODULE_DESCRIPTION("LiteX SoC Controller driver");
+MODULE_AUTHOR("Antmicro <http://www.antmicro.com>");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/litex.h b/include/linux/litex.h
new file mode 100644
index 000000000000..72061018c172
--- /dev/null
+++ b/include/linux/litex.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Common LiteX header providing
+ * helper functions for accessing CSRs.
+ *
+ * Implementation of the functions is provided by
+ * the LiteX SoC Controller driver.
+ *
+ * Copyright (C) 2019-2020 Antmicro <http://www.antmicro.com>
+ */
+
+#ifndef _LINUX_LITEX_H
+#define _LINUX_LITEX_H
+
+#include <linux/io.h>
+#include <linux/types.h>
+#include <linux/compiler_types.h>
+
+void litex_set_reg(void __iomem *reg, unsigned long reg_sz, unsigned long val);
+
+unsigned long litex_get_reg(void __iomem *reg, unsigned long reg_sz);
+
+
+#endif /* _LINUX_LITEX_H */
--
2.25.1

2020-08-12 12:38:33

by Mateusz Holenko

[permalink] [raw]
Subject: [PATCH v10 5/5] drivers/tty/serial: add LiteUART driver

From: Filip Kokosinski <[email protected]>

This commit adds driver for the FPGA-based LiteUART serial controller
from LiteX SoC builder.

The current implementation supports LiteUART configured
for 32 bit data width and 8 bit CSR bus width.

It does not support IRQ.

Signed-off-by: Filip Kokosinski <[email protected]>
Signed-off-by: Mateusz Holenko <[email protected]>
---

Notes:
No changes in v10.

No changes in v9.

Changes in v8:
- fixed help messages in LiteUART's KConfig
- removed dependency between LiteUART and LiteX SoC drivers

Changed in v7:
- added missing include directive

Changes in v6:
- LiteUART ports now stored in xArray
- removed PORT_LITEUART
- fixed formatting
- removed some unnecessary defines

No changes in v5.

Changes in v4:
- fixed copyright header
- removed a wrong dependency on UARTLITE from Kconfig
- added a dependency on LITEX_SOC_CONTROLLER to LITEUART in Kconfig

Changes in v3:
- aliases made optional
- used litex_get_reg/litex_set_reg functions instead of macros
- SERIAL_LITEUART_NR_PORTS renamed to SERIAL_LITEUART_MAX_PORTS
- PORT_LITEUART changed from 122 to 123
- added dependency on LITEX_SOC_CONTROLLER
- patch number changed from 4 to 5

No changes in v2.

MAINTAINERS | 1 +
drivers/tty/serial/Kconfig | 32 +++
drivers/tty/serial/Makefile | 1 +
drivers/tty/serial/liteuart.c | 402 ++++++++++++++++++++++++++++++++++
4 files changed, 436 insertions(+)
create mode 100644 drivers/tty/serial/liteuart.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 4d70a1b22a87..1387cefc63ce 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9841,6 +9841,7 @@ M: Mateusz Holenko <[email protected]>
S: Maintained
F: Documentation/devicetree/bindings/*/litex,*.yaml
F: drivers/soc/litex/litex_soc_ctrl.c
+F: drivers/tty/serial/liteuart.c
F: include/linux/litex.h

LIVE PATCHING
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index adf9e80e7dc9..17aaf0afb27a 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1562,6 +1562,38 @@ config SERIAL_MILBEAUT_USIO_CONSOLE
receives all kernel messages and warnings and which allows logins in
single user mode).

+config SERIAL_LITEUART
+ tristate "LiteUART serial port support"
+ depends on HAS_IOMEM
+ depends on OF || COMPILE_TEST
+ depends on LITEX_SOC_CONTROLLER
+ select SERIAL_CORE
+ help
+ This driver is for the FPGA-based LiteUART serial controller from LiteX
+ SoC builder.
+
+ Say 'Y' or 'M' here if you wish to use the LiteUART serial controller.
+ Otherwise, say 'N'.
+
+config SERIAL_LITEUART_MAX_PORTS
+ int "Maximum number of LiteUART ports"
+ depends on SERIAL_LITEUART
+ default "1"
+ help
+ Set this to the maximum number of serial ports you want the driver
+ to support.
+
+config SERIAL_LITEUART_CONSOLE
+ bool "LiteUART serial port console support"
+ depends on SERIAL_LITEUART=y
+ select SERIAL_CORE_CONSOLE
+ help
+ Say 'Y' or 'M' here if you wish to use the FPGA-based LiteUART serial
+ controller from LiteX SoC builder as the system console
+ (the system console is the device which receives all kernel messages
+ and warnings and which allows logins in single user mode).
+ Otherwise, say 'N'.
+
endmenu

config SERIAL_MCTRL_GPIO
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index d056ee6cca33..9f8ba419ff3b 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -89,6 +89,7 @@ obj-$(CONFIG_SERIAL_OWL) += owl-uart.o
obj-$(CONFIG_SERIAL_RDA) += rda-uart.o
obj-$(CONFIG_SERIAL_MILBEAUT_USIO) += milbeaut_usio.o
obj-$(CONFIG_SERIAL_SIFIVE) += sifive.o
+obj-$(CONFIG_SERIAL_LITEUART) += liteuart.o

# GPIOLIB helpers for modem control lines
obj-$(CONFIG_SERIAL_MCTRL_GPIO) += serial_mctrl_gpio.o
diff --git a/drivers/tty/serial/liteuart.c b/drivers/tty/serial/liteuart.c
new file mode 100644
index 000000000000..b087e6a32106
--- /dev/null
+++ b/drivers/tty/serial/liteuart.c
@@ -0,0 +1,402 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * LiteUART serial controller (LiteX) Driver
+ *
+ * Copyright (C) 2019-2020 Antmicro <http://www.antmicro.com>
+ */
+
+#include <linux/console.h>
+#include <linux/litex.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/serial.h>
+#include <linux/serial_core.h>
+#include <linux/slab.h>
+#include <linux/timer.h>
+#include <linux/tty_flip.h>
+#include <linux/xarray.h>
+
+/*
+ * CSRs definitions (base address offsets + width)
+ *
+ * The definitions below are true for LiteX SoC configured for 8-bit CSR Bus,
+ * 32-bit aligned.
+ *
+ * Supporting other configurations might require new definitions or a more
+ * generic way of indexing the LiteX CSRs.
+ *
+ * For more details on how CSRs are defined and handled in LiteX, see comments
+ * in the LiteX SoC Driver: drivers/soc/litex/litex_soc_ctrl.c
+ */
+#define OFF_RXTX 0x00
+#define OFF_TXFULL 0x04
+#define OFF_RXEMPTY 0x08
+#define OFF_EV_STATUS 0x0c
+#define OFF_EV_PENDING 0x10
+#define OFF_EV_ENABLE 0x14
+
+/* events */
+#define EV_TX 0x1
+#define EV_RX 0x2
+
+struct liteuart_port {
+ struct uart_port port;
+ struct timer_list timer;
+};
+
+#define to_liteuart_port(port) container_of(port, struct liteuart_port, port)
+
+static DEFINE_XARRAY_FLAGS(liteuart_array, XA_FLAGS_ALLOC);
+
+#ifdef CONFIG_SERIAL_LITEUART_CONSOLE
+static struct console liteuart_console;
+#endif
+
+static struct uart_driver liteuart_driver = {
+ .owner = THIS_MODULE,
+ .driver_name = "liteuart",
+ .dev_name = "ttyLXU",
+ .major = 0,
+ .minor = 0,
+ .nr = CONFIG_SERIAL_LITEUART_MAX_PORTS,
+#ifdef CONFIG_SERIAL_LITEUART_CONSOLE
+ .cons = &liteuart_console,
+#endif
+};
+
+static void liteuart_timer(struct timer_list *t)
+{
+ struct liteuart_port *uart = from_timer(uart, t, timer);
+ struct uart_port *port = &uart->port;
+ unsigned char __iomem *membase = port->membase;
+ unsigned int flg = TTY_NORMAL;
+ int ch;
+ unsigned long status;
+
+ while ((status = !litex_get_reg(membase + OFF_RXEMPTY, 1)) == 1) {
+ ch = litex_get_reg(membase + OFF_RXTX, 1);
+ port->icount.rx++;
+
+ /* necessary for RXEMPTY to refresh its value */
+ litex_set_reg(membase + OFF_EV_PENDING, 1, EV_TX | EV_RX);
+
+ /* no overflow bits in status */
+ if (!(uart_handle_sysrq_char(port, ch)))
+ uart_insert_char(port, status, 0, ch, flg);
+
+ tty_flip_buffer_push(&port->state->port);
+ }
+
+ mod_timer(&uart->timer, jiffies + uart_poll_timeout(port));
+}
+
+static void liteuart_putchar(struct uart_port *port, int ch)
+{
+ while (litex_get_reg(port->membase + OFF_TXFULL, 1))
+ cpu_relax();
+
+ litex_set_reg(port->membase + OFF_RXTX, 1, ch);
+}
+
+static unsigned int liteuart_tx_empty(struct uart_port *port)
+{
+ /* not really tx empty, just checking if tx is not full */
+ if (!litex_get_reg(port->membase + OFF_TXFULL, 1))
+ return TIOCSER_TEMT;
+
+ return 0;
+}
+
+static void liteuart_set_mctrl(struct uart_port *port, unsigned int mctrl)
+{
+ /* modem control register is not present in LiteUART */
+}
+
+static unsigned int liteuart_get_mctrl(struct uart_port *port)
+{
+ return TIOCM_CTS | TIOCM_DSR | TIOCM_CAR;
+}
+
+static void liteuart_stop_tx(struct uart_port *port)
+{
+}
+
+static void liteuart_start_tx(struct uart_port *port)
+{
+ struct circ_buf *xmit = &port->state->xmit;
+ unsigned char ch;
+
+ if (unlikely(port->x_char)) {
+ litex_set_reg(port->membase + OFF_RXTX, 1, port->x_char);
+ port->icount.tx++;
+ port->x_char = 0;
+ } else if (!uart_circ_empty(xmit)) {
+ while (xmit->head != xmit->tail) {
+ ch = xmit->buf[xmit->tail];
+ xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
+ port->icount.tx++;
+ liteuart_putchar(port, ch);
+ }
+ }
+
+ if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+ uart_write_wakeup(port);
+}
+
+static void liteuart_stop_rx(struct uart_port *port)
+{
+ struct liteuart_port *uart = to_liteuart_port(port);
+
+ /* just delete timer */
+ del_timer(&uart->timer);
+}
+
+static void liteuart_break_ctl(struct uart_port *port, int break_state)
+{
+ /* LiteUART doesn't support sending break signal */
+}
+
+static int liteuart_startup(struct uart_port *port)
+{
+ struct liteuart_port *uart = to_liteuart_port(port);
+
+ /* disable events */
+ litex_set_reg(port->membase + OFF_EV_ENABLE, 1, 0);
+
+ /* prepare timer for polling */
+ timer_setup(&uart->timer, liteuart_timer, 0);
+ mod_timer(&uart->timer, jiffies + uart_poll_timeout(port));
+
+ return 0;
+}
+
+static void liteuart_shutdown(struct uart_port *port)
+{
+}
+
+static void liteuart_set_termios(struct uart_port *port, struct ktermios *new,
+ struct ktermios *old)
+{
+ unsigned int baud;
+ unsigned long flags;
+
+ spin_lock_irqsave(&port->lock, flags);
+
+ /* update baudrate */
+ baud = uart_get_baud_rate(port, new, old, 0, 460800);
+ uart_update_timeout(port, new->c_cflag, baud);
+
+ spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static const char *liteuart_type(struct uart_port *port)
+{
+ return "liteuart";
+}
+
+static void liteuart_release_port(struct uart_port *port)
+{
+}
+
+static int liteuart_request_port(struct uart_port *port)
+{
+ return 0;
+}
+
+static void liteuart_config_port(struct uart_port *port, int flags)
+{
+ /*
+ * Driver core for serial ports forces a non-zero value for port type.
+ * Write an arbitrary value here to accommodate the serial core driver,
+ * as ID part of UAPI is redundant.
+ */
+ port->type = 1;
+}
+
+static int liteuart_verify_port(struct uart_port *port,
+ struct serial_struct *ser)
+{
+ if (port->type != PORT_UNKNOWN && ser->type != 1)
+ return -EINVAL;
+
+ return 0;
+}
+
+static const struct uart_ops liteuart_ops = {
+ .tx_empty = liteuart_tx_empty,
+ .set_mctrl = liteuart_set_mctrl,
+ .get_mctrl = liteuart_get_mctrl,
+ .stop_tx = liteuart_stop_tx,
+ .start_tx = liteuart_start_tx,
+ .stop_rx = liteuart_stop_rx,
+ .break_ctl = liteuart_break_ctl,
+ .startup = liteuart_startup,
+ .shutdown = liteuart_shutdown,
+ .set_termios = liteuart_set_termios,
+ .type = liteuart_type,
+ .release_port = liteuart_release_port,
+ .request_port = liteuart_request_port,
+ .config_port = liteuart_config_port,
+ .verify_port = liteuart_verify_port,
+};
+
+static int liteuart_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct liteuart_port *uart;
+ struct uart_port *port;
+ struct xa_limit limit;
+ int dev_id, ret;
+
+ /* no device tree */
+ if (!np)
+ return -ENODEV;
+
+ /* look for aliases; auto-enumerate for free index if not found */
+ dev_id = of_alias_get_id(np, "serial");
+ if (dev_id < 0)
+ limit = XA_LIMIT(0, CONFIG_SERIAL_LITEUART_MAX_PORTS);
+ else
+ limit = XA_LIMIT(dev_id, dev_id);
+
+ uart = kzalloc(sizeof(struct liteuart_port), GFP_KERNEL);
+ if (!uart)
+ return -ENOMEM;
+
+ ret = xa_alloc(&liteuart_array, &dev_id, uart, limit, GFP_KERNEL);
+ if (ret)
+ return ret;
+
+ port = &uart->port;
+
+ /* get membase */
+ port->membase = devm_platform_get_and_ioremap_resource(pdev, 0, NULL);
+ if (!port->membase)
+ return -ENXIO;
+
+ /* values not from device tree */
+ port->dev = &pdev->dev;
+ port->iotype = UPIO_MEM;
+ port->flags = UPF_BOOT_AUTOCONF;
+ port->ops = &liteuart_ops;
+ port->regshift = 2;
+ port->fifosize = 16;
+ port->iobase = 1;
+ port->type = PORT_UNKNOWN;
+ port->line = dev_id;
+ spin_lock_init(&port->lock);
+
+ return uart_add_one_port(&liteuart_driver, &uart->port);
+}
+
+static int liteuart_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static const struct of_device_id liteuart_of_match[] = {
+ { .compatible = "litex,liteuart" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, liteuart_of_match);
+
+static struct platform_driver liteuart_platform_driver = {
+ .probe = liteuart_probe,
+ .remove = liteuart_remove,
+ .driver = {
+ .name = "liteuart",
+ .of_match_table = liteuart_of_match,
+ },
+};
+
+#ifdef CONFIG_SERIAL_LITEUART_CONSOLE
+
+static void liteuart_console_write(struct console *co, const char *s,
+ unsigned int count)
+{
+ struct liteuart_port *uart;
+ struct uart_port *port;
+ unsigned long flags;
+
+ uart = (struct liteuart_port *)xa_load(&liteuart_array, co->index);
+ port = &uart->port;
+
+ spin_lock_irqsave(&port->lock, flags);
+ uart_console_write(port, s, count, liteuart_putchar);
+ spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static int liteuart_console_setup(struct console *co, char *options)
+{
+ struct liteuart_port *uart;
+ struct uart_port *port;
+ int baud = 115200;
+ int bits = 8;
+ int parity = 'n';
+ int flow = 'n';
+
+ uart = (struct liteuart_port *)xa_load(&liteuart_array, co->index);
+ if (!uart)
+ return -ENODEV;
+
+ port = &uart->port;
+ if (!port->membase)
+ return -ENODEV;
+
+ if (options)
+ uart_parse_options(options, &baud, &parity, &bits, &flow);
+
+ return uart_set_options(port, co, baud, parity, bits, flow);
+}
+
+static struct console liteuart_console = {
+ .name = "liteuart",
+ .write = liteuart_console_write,
+ .device = uart_console_device,
+ .setup = liteuart_console_setup,
+ .flags = CON_PRINTBUFFER,
+ .index = -1,
+ .data = &liteuart_driver,
+};
+
+static int __init liteuart_console_init(void)
+{
+ register_console(&liteuart_console);
+
+ return 0;
+}
+console_initcall(liteuart_console_init);
+#endif /* CONFIG_SERIAL_LITEUART_CONSOLE */
+
+static int __init liteuart_init(void)
+{
+ int res;
+
+ res = uart_register_driver(&liteuart_driver);
+ if (res)
+ return res;
+
+ res = platform_driver_register(&liteuart_platform_driver);
+ if (res) {
+ uart_unregister_driver(&liteuart_driver);
+ return res;
+ }
+
+ return 0;
+}
+
+static void __exit liteuart_exit(void)
+{
+ platform_driver_unregister(&liteuart_platform_driver);
+ uart_unregister_driver(&liteuart_driver);
+}
+
+module_init(liteuart_init);
+module_exit(liteuart_exit);
+
+MODULE_AUTHOR("Antmicro <http://www.antmicro.com>");
+MODULE_DESCRIPTION("LiteUART serial driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform: liteuart");
--
2.25.1

2020-08-28 08:18:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH v10 5/5] drivers/tty/serial: add LiteUART driver

On Wed, Aug 12, 2020 at 02:35:00PM +0200, Mateusz Holenko wrote:
> From: Filip Kokosinski <[email protected]>
>
> This commit adds driver for the FPGA-based LiteUART serial controller
> from LiteX SoC builder.
>
> The current implementation supports LiteUART configured
> for 32 bit data width and 8 bit CSR bus width.
>
> It does not support IRQ.
>
> Signed-off-by: Filip Kokosinski <[email protected]>
> Signed-off-by: Mateusz Holenko <[email protected]>

Reviewed-by: Greg Kroah-Hartman <[email protected]>

2020-09-11 00:59:13

by Stafford Horne

[permalink] [raw]
Subject: Re: [PATCH v10 3/5] drivers/soc/litex: add LiteX SoC Controller driver

On Wed, Aug 12, 2020 at 02:34:34PM +0200, Mateusz Holenko wrote:
> From: Pawel Czarnecki <[email protected]>
>
> This commit adds driver for the FPGA-based LiteX SoC
> Controller from LiteX SoC builder.
>
> Co-developed-by: Mateusz Holenko <[email protected]>
> Signed-off-by: Mateusz Holenko <[email protected]>
> Signed-off-by: Pawel Czarnecki <[email protected]>
> ---
...
> +static int litex_check_csr_access(void __iomem *reg_addr)
> +{
> + unsigned long reg;
> +
> + reg = litex_get_reg(reg_addr + SCRATCH_REG_OFF, SCRATCH_REG_SIZE);
> +
> + if (reg != SCRATCH_REG_VALUE) {
> + panic("Scratch register read error! Expected: 0x%x but got: 0x%lx",
> + SCRATCH_REG_VALUE, reg);
> + return -EINVAL;
> + }
> +
> + litex_set_reg(reg_addr + SCRATCH_REG_OFF,
> + SCRATCH_REG_SIZE, SCRATCH_TEST_VALUE);
> + reg = litex_get_reg(reg_addr + SCRATCH_REG_OFF, SCRATCH_REG_SIZE);
> +
> + if (reg != SCRATCH_TEST_VALUE) {
> + panic("Scratch register write error! Expected: 0x%x but got: 0x%lx",
> + SCRATCH_TEST_VALUE, reg);
> + return -EINVAL;
> + }
> +
> + /* restore original value of the SCRATCH register */
> + litex_set_reg(reg_addr + SCRATCH_REG_OFF,
> + SCRATCH_REG_SIZE, SCRATCH_REG_VALUE);
> +
> + /* Set flag for other drivers */
What does this comment mean?

> + pr_info("LiteX SoC Controller driver initialized");
> +
> + return 0;
> +}
> +
> +struct litex_soc_ctrl_device {
> + void __iomem *base;
> +};
> +
> +static const struct of_device_id litex_soc_ctrl_of_match[] = {
> + {.compatible = "litex,soc-controller"},
> + {},
> +};
> +
> +MODULE_DEVICE_TABLE(of, litex_soc_ctrl_of_match);
> +
> +static int litex_soc_ctrl_probe(struct platform_device *pdev)
> +{
> + int result;
> + struct device *dev;
> + struct device_node *node;
> + struct litex_soc_ctrl_device *soc_ctrl_dev;
> +
> + dev = &pdev->dev;
> + node = dev->of_node;
> + if (!node)
> + return -ENODEV;
> +
> + soc_ctrl_dev = devm_kzalloc(dev, sizeof(*soc_ctrl_dev), GFP_KERNEL);
> + if (!soc_ctrl_dev)
> + return -ENOMEM;
> +
> + soc_ctrl_dev->base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(soc_ctrl_dev->base))
> + return PTR_ERR(soc_ctrl_dev->base);
> +
> + result = litex_check_csr_access(soc_ctrl_dev->base);
> + if (result) {
> + // LiteX CSRs access is broken which means that
> + // none of LiteX drivers will most probably
> + // operate correctly
The comment format here with // is not usually used in the kernel, but its not
forbidded. Could you use the /* */ multiline style?

> + BUG();
Instead of stopping the system with BUG, could we just do:

return litex_check_csr_access(soc_ctrl_dev->base);

We already have failure for NODEV/NOMEM so might as well not call BUG() here
too.

> + }
> +
> + return 0;
> +}
> +

Other than that it looks ok to me.

-Stafford

2020-09-11 01:01:53

by Stafford Horne

[permalink] [raw]
Subject: Re: [PATCH v10 0/5] LiteX SoC controller and LiteUART serial driver

On Wed, Aug 12, 2020 at 02:33:46PM +0200, Mateusz Holenko wrote:
> This patchset introduces support for LiteX SoC Controller
> and LiteUART - serial device from LiteX SoC builder
> (https://github.com/enjoy-digital/litex).
>
> In the following patchset I will add
> a new mor1kx-based (OpenRISC) platform that
> uses this device.
>
> Later I plan to extend this platform by
> adding support for more devices from LiteX suite.

Hello, as discussed offline I am planning to merge these via the OpenRISC tree
during 5.10. If anyone has an issues let me know.

The patches all have their reviews and look fine to me other than a few nit's on
the soc controller patch.

-Stafford

2020-09-14 10:35:06

by Mateusz Holenko

[permalink] [raw]
Subject: Re: [PATCH v10 3/5] drivers/soc/litex: add LiteX SoC Controller driver

On Fri, Sep 11, 2020 at 2:57 AM Stafford Horne <[email protected]> wrote:
>
> On Wed, Aug 12, 2020 at 02:34:34PM +0200, Mateusz Holenko wrote:
> > From: Pawel Czarnecki <[email protected]>
> >
> > This commit adds driver for the FPGA-based LiteX SoC
> > Controller from LiteX SoC builder.
> >
> > Co-developed-by: Mateusz Holenko <[email protected]>
> > Signed-off-by: Mateusz Holenko <[email protected]>
> > Signed-off-by: Pawel Czarnecki <[email protected]>
> > ---
> ...
> > +static int litex_check_csr_access(void __iomem *reg_addr)
> > +{
> > + unsigned long reg;
> > +
> > + reg = litex_get_reg(reg_addr + SCRATCH_REG_OFF, SCRATCH_REG_SIZE);
> > +
> > + if (reg != SCRATCH_REG_VALUE) {
> > + panic("Scratch register read error! Expected: 0x%x but got: 0x%lx",
> > + SCRATCH_REG_VALUE, reg);
> > + return -EINVAL;
> > + }
> > +
> > + litex_set_reg(reg_addr + SCRATCH_REG_OFF,
> > + SCRATCH_REG_SIZE, SCRATCH_TEST_VALUE);
> > + reg = litex_get_reg(reg_addr + SCRATCH_REG_OFF, SCRATCH_REG_SIZE);
> > +
> > + if (reg != SCRATCH_TEST_VALUE) {
> > + panic("Scratch register write error! Expected: 0x%x but got: 0x%lx",
> > + SCRATCH_TEST_VALUE, reg);
> > + return -EINVAL;
> > + }
> > +
> > + /* restore original value of the SCRATCH register */
> > + litex_set_reg(reg_addr + SCRATCH_REG_OFF,
> > + SCRATCH_REG_SIZE, SCRATCH_REG_VALUE);
> > +
> > + /* Set flag for other drivers */
> What does this comment mean?

This is a leftover from the previous version of the patch
and shouldn't be there - sorry for that.
I'll remove it.

> > + pr_info("LiteX SoC Controller driver initialized");
> > +
> > + return 0;
> > +}
> > +
> > +struct litex_soc_ctrl_device {
> > + void __iomem *base;
> > +};
> > +
> > +static const struct of_device_id litex_soc_ctrl_of_match[] = {
> > + {.compatible = "litex,soc-controller"},
> > + {},
> > +};
> > +
> > +MODULE_DEVICE_TABLE(of, litex_soc_ctrl_of_match);
> > +
> > +static int litex_soc_ctrl_probe(struct platform_device *pdev)
> > +{
> > + int result;
> > + struct device *dev;
> > + struct device_node *node;
> > + struct litex_soc_ctrl_device *soc_ctrl_dev;
> > +
> > + dev = &pdev->dev;
> > + node = dev->of_node;
> > + if (!node)
> > + return -ENODEV;
> > +
> > + soc_ctrl_dev = devm_kzalloc(dev, sizeof(*soc_ctrl_dev), GFP_KERNEL);
> > + if (!soc_ctrl_dev)
> > + return -ENOMEM;
> > +
> > + soc_ctrl_dev->base = devm_platform_ioremap_resource(pdev, 0);
> > + if (IS_ERR(soc_ctrl_dev->base))
> > + return PTR_ERR(soc_ctrl_dev->base);
> > +
> > + result = litex_check_csr_access(soc_ctrl_dev->base);
> > + if (result) {
> > + // LiteX CSRs access is broken which means that
> > + // none of LiteX drivers will most probably
> > + // operate correctly
> The comment format here with // is not usually used in the kernel, but its not
> forbidded. Could you use the /* */ multiline style?

Sure, I'll change the commenting style here.

>
> > + BUG();
> Instead of stopping the system with BUG, could we just do:
>
> return litex_check_csr_access(soc_ctrl_dev->base);
>
> We already have failure for NODEV/NOMEM so might as well not call BUG() here
> too.

It's true that litex_check_csr_accessors() already generates error
codes that could be
returned directly.
The point of using BUG() macro here, however, is to stop booting the
system so that it's visible
(and impossible to miss for the user) that an unresolvable HW issue
was encountered.

CSR-accessors - the litex_{g,s}et_reg() functions - are intended to be
used by other LiteX drivers
and it's very unlikely that those drivers would work properly after
the fail of litex_check_csr_accessors().
Since in such case the UART driver will be affected too (no boot logs
and error messages visible to the user),
I thought it'll be easier to spot and debug the problem if the system
stopped in the BUG loop.
Perhaps there are other, more linux-friendly, ways of achieving a
similar goal - I'm open for suggestions.

> > + }
> > +
> > + return 0;
> > +}
> > +
>
> Other than that it looks ok to me.
>
> -Stafford

Thanks for the review!

Best,
Mateusz


--
Mateusz Holenko
Antmicro Ltd | http://www.antmicro.com
Roosevelta 22, 60-829 Poznan, Poland

2020-09-14 13:37:54

by Stafford Horne

[permalink] [raw]
Subject: Re: [PATCH v10 3/5] drivers/soc/litex: add LiteX SoC Controller driver

On Mon, Sep 14, 2020 at 12:33:11PM +0200, Mateusz Holenko wrote:
> On Fri, Sep 11, 2020 at 2:57 AM Stafford Horne <[email protected]> wrote:
> >
> > On Wed, Aug 12, 2020 at 02:34:34PM +0200, Mateusz Holenko wrote:
> > > From: Pawel Czarnecki <[email protected]>
> > >
> > > This commit adds driver for the FPGA-based LiteX SoC
> > > Controller from LiteX SoC builder.
> > >
> > > Co-developed-by: Mateusz Holenko <[email protected]>
> > > Signed-off-by: Mateusz Holenko <[email protected]>
> > > Signed-off-by: Pawel Czarnecki <[email protected]>
> > > ---
> > > + node = dev->of_node;
> > > + if (!node)
> > > + return -ENODEV;

We return here without BUG() if the setup fails.

> > > +
> > > + soc_ctrl_dev = devm_kzalloc(dev, sizeof(*soc_ctrl_dev), GFP_KERNEL);
> > > + if (!soc_ctrl_dev)
> > > + return -ENOMEM;

We return here without BUG() if we are out of memory.

> > > +
> > > + soc_ctrl_dev->base = devm_platform_ioremap_resource(pdev, 0);
> > > + if (IS_ERR(soc_ctrl_dev->base))
> > > + return PTR_ERR(soc_ctrl_dev->base);

Etc.

> > > +
> > > + result = litex_check_csr_access(soc_ctrl_dev->base);
> > > + if (result) {
> > > + // LiteX CSRs access is broken which means that
> > > + // none of LiteX drivers will most probably
> > > + // operate correctly
> > The comment format here with // is not usually used in the kernel, but its not
> > forbidded. Could you use the /* */ multiline style?
>
> Sure, I'll change the commenting style here.
>
> >
> > > + BUG();
> > Instead of stopping the system with BUG, could we just do:
> >
> > return litex_check_csr_access(soc_ctrl_dev->base);
> >
> > We already have failure for NODEV/NOMEM so might as well not call BUG() here
> > too.
>
> It's true that litex_check_csr_accessors() already generates error
> codes that could be
> returned directly.
> The point of using BUG() macro here, however, is to stop booting the
> system so that it's visible
> (and impossible to miss for the user) that an unresolvable HW issue
> was encountered.
>
> CSR-accessors - the litex_{g,s}et_reg() functions - are intended to be
> used by other LiteX drivers
> and it's very unlikely that those drivers would work properly after
> the fail of litex_check_csr_accessors().
> Since in such case the UART driver will be affected too (no boot logs
> and error messages visible to the user),
> I thought it'll be easier to spot and debug the problem if the system
> stopped in the BUG loop.
> Perhaps there are other, more linux-friendly, ways of achieving a
> similar goal - I'm open for suggestions.

I see your point, but I thought if failed with an exit status above, we could do
the same here. But I guess failing here means that something is really wrong as
validation failed.

Some points:
- If we return here, the system will still boot but there will be no UART
- If we bail with BUG(), here the system stops, and there is no UART
- Both cases the user can connect with a debugger and read "dmesg", to see what
is wrong, but BUG() does not print an error message on all architectures.

We could also use:

- WARN(1, "Failed to validate CSR registers, the system is probably broken.");

If you want to keep BUG() it may be fine.

I am not an expert on handling these type of bailout's so other input is
appreciated.

-Stafford

2020-09-16 00:49:13

by Mateusz Holenko

[permalink] [raw]
Subject: Re: [PATCH v10 3/5] drivers/soc/litex: add LiteX SoC Controller driver

On Mon, Sep 14, 2020 at 3:24 PM Stafford Horne <[email protected]> wrote:
>
> On Mon, Sep 14, 2020 at 12:33:11PM +0200, Mateusz Holenko wrote:
> > On Fri, Sep 11, 2020 at 2:57 AM Stafford Horne <[email protected]> wrote:
> > >
> > > On Wed, Aug 12, 2020 at 02:34:34PM +0200, Mateusz Holenko wrote:
> > > > From: Pawel Czarnecki <[email protected]>
> > > >
> > > > This commit adds driver for the FPGA-based LiteX SoC
> > > > Controller from LiteX SoC builder.
> > > >
> > > > Co-developed-by: Mateusz Holenko <[email protected]>
> > > > Signed-off-by: Mateusz Holenko <[email protected]>
> > > > Signed-off-by: Pawel Czarnecki <[email protected]>
> > > > ---
> > > > + node = dev->of_node;
> > > > + if (!node)
> > > > + return -ENODEV;
>
> We return here without BUG() if the setup fails.
>
> > > > +
> > > > + soc_ctrl_dev = devm_kzalloc(dev, sizeof(*soc_ctrl_dev), GFP_KERNEL);
> > > > + if (!soc_ctrl_dev)
> > > > + return -ENOMEM;
>
> We return here without BUG() if we are out of memory.
>
> > > > +
> > > > + soc_ctrl_dev->base = devm_platform_ioremap_resource(pdev, 0);
> > > > + if (IS_ERR(soc_ctrl_dev->base))
> > > > + return PTR_ERR(soc_ctrl_dev->base);
>
> Etc.

You are totally right - this is not consistent.
We should probably either trigger BUG() in each case or don't bother at all.

>
> > > > +
> > > > + result = litex_check_csr_access(soc_ctrl_dev->base);
> > > > + if (result) {
> > > > + // LiteX CSRs access is broken which means that
> > > > + // none of LiteX drivers will most probably
> > > > + // operate correctly
> > > The comment format here with // is not usually used in the kernel, but its not
> > > forbidded. Could you use the /* */ multiline style?
> >
> > Sure, I'll change the commenting style here.
> >
> > >
> > > > + BUG();
> > > Instead of stopping the system with BUG, could we just do:
> > >
> > > return litex_check_csr_access(soc_ctrl_dev->base);
> > >
> > > We already have failure for NODEV/NOMEM so might as well not call BUG() here
> > > too.
> >
> > It's true that litex_check_csr_accessors() already generates error
> > codes that could be
> > returned directly.
> > The point of using BUG() macro here, however, is to stop booting the
> > system so that it's visible
> > (and impossible to miss for the user) that an unresolvable HW issue
> > was encountered.
> >
> > CSR-accessors - the litex_{g,s}et_reg() functions - are intended to be
> > used by other LiteX drivers
> > and it's very unlikely that those drivers would work properly after
> > the fail of litex_check_csr_accessors().
> > Since in such case the UART driver will be affected too (no boot logs
> > and error messages visible to the user),
> > I thought it'll be easier to spot and debug the problem if the system
> > stopped in the BUG loop.
> > Perhaps there are other, more linux-friendly, ways of achieving a
> > similar goal - I'm open for suggestions.
>
> I see your point, but I thought if failed with an exit status above, we could do
> the same here. But I guess failing here means that something is really wrong as
> validation failed.
>
> Some points:
> - If we return here, the system will still boot but there will be no UART
> - If we bail with BUG(), here the system stops, and there is no UART
> - Both cases the user can connect with a debugger and read "dmesg", to see what
> is wrong, but BUG() does not print an error message on all architectures.
>
> We could also use:
>
> - WARN(1, "Failed to validate CSR registers, the system is probably broken.");
>
> If you want to keep BUG() it may be fine.
>
> I am not an expert on handling these type of bailout's so other input is
> appreciated.

I don't have a strong opinion about using BUG() here - I just thought
it would be easier for the user.
If this is, however, not how linux typically works, I'm ok with
reworking this part.

> -Stafford

Best,
Mateusz

--
Mateusz Holenko
Antmicro Ltd | http://www.antmicro.com
Roosevelta 22, 60-829 Poznan, Poland