* [PATCH 07/10] serial: max310x: use FIELD_PREP macro to set PLL bitfields
From: Hugo Villeneuve @ 2026-04-17 14:53 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: hugo, linux-kernel, linux-serial, Hugo Villeneuve
In-Reply-To: <20260417-max310x-2-v1-0-b424e105ecac@dimonoff.com>
From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Use FIELD_PREP macros to improve code readability.
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
---
drivers/tty/serial/max310x.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
index 7ab5e4bd87ee6c87dd211bc52a3a4eb169a2b202..b4449b68cfeee07d1d6d3206cf58f72fac00044e 100644
--- a/drivers/tty/serial/max310x.c
+++ b/drivers/tty/serial/max310x.c
@@ -9,6 +9,7 @@
* Based on max3107.c, by Aavamobile
*/
+#include <linux/bitfield.h>
#include <linux/bitops.h>
#include <linux/clk.h>
#include <linux/delay.h>
@@ -621,7 +622,9 @@ static int max310x_set_ref_clk(struct device *dev, struct max310x_port *s,
u8 pll_id = max310x_pll_mult_to_id(cfg.pll_mult);
clksrc |= MAX310X_CLKSRC_PLL_BIT;
- regmap_write(s->regmap, MAX310X_PLLCFG_REG, (pll_id << 6) | cfg.prediv);
+ val = FIELD_PREP(MAX310X_PLLCFG_PLLFACTOR_MASK, pll_id) |
+ FIELD_PREP(MAX310X_PLLCFG_PREDIV_MASK, cfg.prediv);
+ regmap_write(s->regmap, MAX310X_PLLCFG_REG, val);
} else
clksrc |= MAX310X_CLKSRC_PLLBYP_BIT;
--
2.47.3
^ permalink raw reply related
* [PATCH 05/10] serial: max310x: improve max310x_set_ref_clk() efficiency
From: Hugo Villeneuve @ 2026-04-17 14:53 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: hugo, linux-kernel, linux-serial, Hugo Villeneuve
In-Reply-To: <20260417-max310x-2-v1-0-b424e105ecac@dimonoff.com>
From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
The same basic code is duplicated for each of the four PLL multiplier
values, so simplify and streamline it. Doing so allows us to avoid
some unnecessary (fdiv * factor) multiplications for some fdiv values and
replace the second "if" statement with an "else if" and avoid a useless
comparison.
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
---
drivers/tty/serial/max310x.c | 91 +++++++++++++++++++++++++-------------------
1 file changed, 52 insertions(+), 39 deletions(-)
diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
index f689958736f71b15b7c113214cda60db4aa7c593..1cd7632831a2826ddd42127b1cde2a10dfa412f0 100644
--- a/drivers/tty/serial/max310x.c
+++ b/drivers/tty/serial/max310x.c
@@ -258,6 +258,17 @@
#define MAX14830_BRGCFG_CLKDIS_BIT (1 << 6) /* Clock Disable */
#define MAX14830_REV_ID (0xb0)
+struct max310x_clk_config_t {
+ u8 prediv; /* Predivider */
+ u8 pll_mult; /* PLL multiplier */
+ unsigned int fref; /*
+ * Reference clock for fractional baud rate generator:
+ * PLL enabled: (freq / prediv) x pll_mult
+ * PLL disabled: freq
+ */
+ unsigned int err; /* Computed error for selected parameters */
+};
+
struct max310x_if_cfg {
int (*extended_reg_enable)(struct device *dev, bool enable);
u8 rev_id_offset;
@@ -545,70 +556,72 @@ static int max310x_set_baud(struct uart_port *port, int baud)
return (16*port->uartclk) / (c*(16*div + frac));
}
-static int max310x_update_best_err(unsigned int f, unsigned int *besterr)
+static void max310x_try_cfg(unsigned int fdiv, u8 div, u8 pll_mult,
+ struct max310x_clk_config_t *cfg)
{
+ unsigned int fmul = fdiv * pll_mult;
+ unsigned int err;
+
/* Use high-enough baudrate to calculate error */
- unsigned int err = f % (460800 * 16);
+ err = fmul % (460800 * 16);
- if (*besterr > err) {
- *besterr = err;
- return 0;
+ if (cfg->err > err) {
+ cfg->err = err;
+ cfg->pll_mult = pll_mult;
+ cfg->prediv = div;
+ cfg->fref = fmul;
}
+}
- return 1;
+static u8 max310x_pll_mult_to_id(u8 pll_mult)
+{
+ switch (pll_mult) {
+ case 144: return 3;
+ case 96: return 2;
+ case 48: return 1;
+ case 6:
+ default: return 0;
+ }
}
static int max310x_set_ref_clk(struct device *dev, struct max310x_port *s,
unsigned int freq, unsigned int *fref, bool xtal)
{
- unsigned int div, clksrc, pllcfg = 0;
- unsigned int besterr = UINT_MAX;
- unsigned int fdiv, fmul, bestfreq = freq;
+ unsigned int div, fdiv, clksrc;
+ struct max310x_clk_config_t cfg;
+
+ cfg.err = UINT_MAX;
+ cfg.prediv = 0;
+ cfg.fref = freq;
/* First, update error without PLL */
- max310x_update_best_err(freq, &besterr);
+ max310x_try_cfg(freq, 1, 1, &cfg);
/* Try all possible PLL dividers */
- for (div = 1; (div <= 63) && besterr; div++) {
+ for (div = 1; (div <= 63) && cfg.err; div++) {
fdiv = DIV_ROUND_CLOSEST(freq, div);
- /* Try multiplier 6 */
- fmul = fdiv * 6;
if ((fdiv >= 500000) && (fdiv <= 800000))
- if (!max310x_update_best_err(fmul, &besterr)) {
- pllcfg = (0 << 6) | div;
- bestfreq = fmul;
- }
- /* Try multiplier 48 */
- fmul = fdiv * 48;
- if ((fdiv >= 850000) && (fdiv <= 1200000))
- if (!max310x_update_best_err(fmul, &besterr)) {
- pllcfg = (1 << 6) | div;
- bestfreq = fmul;
- }
- /* Try multiplier 96 */
- fmul = fdiv * 96;
+ max310x_try_cfg(fdiv, div, 6, &cfg); /* PLL x6 */
+ else if ((fdiv >= 850000) && (fdiv <= 1200000))
+ max310x_try_cfg(fdiv, div, 48, &cfg); /* PLL x48 */
+
if ((fdiv >= 425000) && (fdiv <= 1000000))
- if (!max310x_update_best_err(fmul, &besterr)) {
- pllcfg = (2 << 6) | div;
- bestfreq = fmul;
- }
- /* Try multiplier 144 */
- fmul = fdiv * 144;
+ max310x_try_cfg(fdiv, div, 96, &cfg); /* PLL x96 */
+
if ((fdiv >= 390000) && (fdiv <= 667000))
- if (!max310x_update_best_err(fmul, &besterr)) {
- pllcfg = (3 << 6) | div;
- bestfreq = fmul;
- }
+ max310x_try_cfg(fdiv, div, 144, &cfg); /* PLL x144 */
}
/* Configure clock source */
clksrc = MAX310X_CLKSRC_EXTCLK_BIT | (xtal ? MAX310X_CLKSRC_CRYST_BIT : 0);
/* Configure PLL */
- if (pllcfg) {
+ if (cfg.prediv) {
+ u8 pll_id = max310x_pll_mult_to_id(cfg.pll_mult);
+
clksrc |= MAX310X_CLKSRC_PLL_BIT;
- regmap_write(s->regmap, MAX310X_PLLCFG_REG, pllcfg);
+ regmap_write(s->regmap, MAX310X_PLLCFG_REG, (pll_id << 6) | cfg.prediv);
} else
clksrc |= MAX310X_CLKSRC_PLLBYP_BIT;
@@ -632,7 +645,7 @@ static int max310x_set_ref_clk(struct device *dev, struct max310x_port *s,
"clock is not stable\n");
}
- *fref = bestfreq;
+ *fref = cfg.fref;
return 0;
}
--
2.47.3
^ permalink raw reply related
* [PATCH 06/10] serial: max310x: use regmap_read_poll_timeout() for busy wait
From: Hugo Villeneuve @ 2026-04-17 14:53 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: hugo, linux-kernel, linux-serial, Hugo Villeneuve
In-Reply-To: <20260417-max310x-2-v1-0-b424e105ecac@dimonoff.com>
From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Simplify busy wait stages by using regmap_read_poll_timeout().
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
---
Note that the "val" variable is move to the function scope in prevision for
reuse by the next patch.
---
drivers/tty/serial/max310x.c | 44 +++++++++++++++++---------------------------
1 file changed, 17 insertions(+), 27 deletions(-)
diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
index 1cd7632831a2826ddd42127b1cde2a10dfa412f0..7ab5e4bd87ee6c87dd211bc52a3a4eb169a2b202 100644
--- a/drivers/tty/serial/max310x.c
+++ b/drivers/tty/serial/max310x.c
@@ -241,12 +241,12 @@
#define MAX310X_WRITE_BIT 0x80
/* Port startup definitions */
-#define MAX310X_PORT_STARTUP_WAIT_RETRIES 20 /* Number of retries */
-#define MAX310X_PORT_STARTUP_WAIT_DELAY_MS 10 /* Delay between retries */
+#define MAX310X_PORT_STARTUP_SLEEP_US 10000 /* Delay between retries */
+#define MAX310X_PORT_STARTUP_TIMEOUT_US (20 * MAX310X_PORT_STARTUP_SLEEP_US) /* Total timeout */
/* Crystal-related definitions */
-#define MAX310X_XTAL_WAIT_RETRIES 20 /* Number of retries */
-#define MAX310X_XTAL_WAIT_DELAY_MS 10 /* Delay between retries */
+#define MAX310X_XTAL_SLEEP_US 10000 /* Delay between retries */
+#define MAX310X_XTAL_TIMEOUT_US (20 * MAX310X_XTAL_SLEEP_US) /* Total timeout */
/* MAX3107 specific */
#define MAX3107_REV_ID (0xa0)
@@ -587,7 +587,7 @@ static u8 max310x_pll_mult_to_id(u8 pll_mult)
static int max310x_set_ref_clk(struct device *dev, struct max310x_port *s,
unsigned int freq, unsigned int *fref, bool xtal)
{
- unsigned int div, fdiv, clksrc;
+ unsigned int div, fdiv, clksrc, val;
struct max310x_clk_config_t cfg;
cfg.err = UINT_MAX;
@@ -629,18 +629,13 @@ static int max310x_set_ref_clk(struct device *dev, struct max310x_port *s,
/* Wait for crystal */
if (xtal) {
- bool stable = false;
- unsigned int try = 0, val = 0;
+ int ret;
- do {
- msleep(MAX310X_XTAL_WAIT_DELAY_MS);
- regmap_read(s->regmap, MAX310X_STS_IRQSTS_REG, &val);
-
- if (val & MAX310X_STS_CLKREADY_BIT)
- stable = true;
- } while (!stable && (++try < MAX310X_XTAL_WAIT_RETRIES));
-
- if (!stable)
+ ret = regmap_read_poll_timeout(s->regmap, MAX310X_STS_IRQSTS_REG,
+ val, val & MAX310X_STS_CLKREADY_BIT,
+ MAX310X_XTAL_SLEEP_US,
+ MAX310X_XTAL_TIMEOUT_US);
+ if (ret)
return dev_err_probe(dev, -EAGAIN,
"clock is not stable\n");
}
@@ -1346,8 +1341,7 @@ static int max310x_probe(struct device *dev, const struct max310x_devtype *devty
goto out_clk;
for (i = 0; i < devtype->nr; i++) {
- bool started = false;
- unsigned int try = 0, val = 0;
+ unsigned int val;
/* Reset port */
regmap_write(regmaps[i], MAX310X_MODE2_REG,
@@ -1356,15 +1350,11 @@ static int max310x_probe(struct device *dev, const struct max310x_devtype *devty
regmap_write(regmaps[i], MAX310X_MODE2_REG, 0);
/* Wait for port startup */
- do {
- msleep(MAX310X_PORT_STARTUP_WAIT_DELAY_MS);
- regmap_read(regmaps[i], MAX310X_BRGDIVLSB_REG, &val);
-
- if (val == 0x01)
- started = true;
- } while (!started && (++try < MAX310X_PORT_STARTUP_WAIT_RETRIES));
-
- if (!started) {
+ ret = regmap_read_poll_timeout(regmaps[i], MAX310X_BRGDIVLSB_REG,
+ val, val == 0x01,
+ MAX310X_PORT_STARTUP_SLEEP_US,
+ MAX310X_PORT_STARTUP_TIMEOUT_US);
+ if (ret) {
ret = dev_err_probe(dev, -EAGAIN, "port reset failed\n");
goto out_uart;
}
--
2.47.3
^ permalink raw reply related
* [PATCH 08/10] serial: max310x: allow driver to be built with SPI or I2C
From: Hugo Villeneuve @ 2026-04-17 14:53 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: hugo, linux-kernel, linux-serial, Hugo Villeneuve
In-Reply-To: <20260417-max310x-2-v1-0-b424e105ecac@dimonoff.com>
From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
If SPI is disabled, the max310x driver cannot be selected. Allow driver to
be selected if either I2C or SPI is set.
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
---
drivers/tty/serial/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 9aa61c93d7bc6d164b9c493f140477b793ca8afe..296fa20340bd59196f7d1394687edac10fc73adf 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -321,7 +321,7 @@ config SERIAL_MAX3100
config SERIAL_MAX310X
tristate "MAX310X support"
- depends on SPI_MASTER
+ depends on SPI_MASTER || I2C
select SERIAL_CORE
select REGMAP_SPI if SPI_MASTER
select REGMAP_I2C if I2C
--
2.47.3
^ permalink raw reply related
* [PATCH 09/10] serial: max310x: move variables to while() scope
From: Hugo Villeneuve @ 2026-04-17 14:53 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: hugo, linux-kernel, linux-serial, Hugo Villeneuve
In-Reply-To: <20260417-max310x-2-v1-0-b424e105ecac@dimonoff.com>
From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
txlen, to_send and tail variables are only used within the while() loop.
Move them to that scope to keep them closer to their usage and improve
readability.
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
---
drivers/tty/serial/max310x.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
index b4449b68cfeee07d1d6d3206cf58f72fac00044e..748306d1a9329694e90ec4f096dd00e39d457fda 100644
--- a/drivers/tty/serial/max310x.c
+++ b/drivers/tty/serial/max310x.c
@@ -761,8 +761,6 @@ static void max310x_handle_rx(struct uart_port *port, unsigned int rxlen)
static void max310x_handle_tx(struct uart_port *port)
{
struct tty_port *tport = &port->state->port;
- unsigned int txlen, to_send;
- unsigned char *tail;
if (unlikely(port->x_char)) {
max310x_port_write(port, MAX310X_THR_REG, port->x_char);
@@ -779,6 +777,9 @@ static void max310x_handle_tx(struct uart_port *port)
* We could do that in one SPI transaction, but meh.
*/
while (!kfifo_is_empty(&tport->xmit_fifo)) {
+ unsigned int txlen, to_send;
+ unsigned char *tail;
+
/* Limit to space available in TX FIFO */
txlen = max310x_port_read(port, MAX310X_TXFIFOLVL_REG);
txlen = port->fifosize - txlen;
--
2.47.3
^ permalink raw reply related
* [PATCH 10/10] serial: max310x: add comments for PLL limits
From: Hugo Villeneuve @ 2026-04-17 14:53 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: hugo, linux-kernel, linux-serial, Hugo Villeneuve
In-Reply-To: <20260417-max310x-2-v1-0-b424e105ecac@dimonoff.com>
From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Add comments to help clarify the provenance of the various hardcoded values
used in computing the ref clk.
Assisted-by: Gemini:Pro
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
---
drivers/tty/serial/max310x.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
index 748306d1a9329694e90ec4f096dd00e39d457fda..9f423b3b4201d0db07bbd7b15934db36249e7620 100644
--- a/drivers/tty/serial/max310x.c
+++ b/drivers/tty/serial/max310x.c
@@ -585,6 +585,23 @@ static u8 max310x_pll_mult_to_id(u8 pll_mult)
}
}
+/*
+ * From table 7 in datasheet: PLLFactor Selector Guide
+ *
+ * +-----------+----------------+-------------------+-------------------+
+ * | PLLFactor | MULTIPLICATION | fPLLIN | fREF |
+ * | (1 & 0) | FACTOR +---------+---------+---------+---------+
+ * | | | MIN | MAX | MIN | MAX |
+ * +-----------+----------------+---------+---------+---------+---------+
+ * | 0 | 6 | 500kHz | 800kHz | 3MHz | 4.8MHz |
+ * +-----------+----------------+---------+---------+---------+---------+
+ * | 1 | 48 | 850kHz | 1.2MHz | 40.8MHz | 56MHz |
+ * +-----------+----------------+---------+---------+---------+---------+
+ * | 2 | 96 | 425kHz | 1MHz | 40.8MHz | 96MHz |
+ * +-----------+----------------+---------+---------+---------+---------+
+ * | 3 | 144 | 390kHz | 667kHz | 56MHz | 96MHz |
+ * +-----------+----------------+---------+---------+---------+---------+
+ */
static int max310x_set_ref_clk(struct device *dev, struct max310x_port *s,
unsigned int freq, unsigned int *fref, bool xtal)
{
--
2.47.3
^ permalink raw reply related
* [PATCH 03/10] serial: max310x: change return type of max310x_set_ref_clk()
From: Hugo Villeneuve @ 2026-04-17 14:53 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: hugo, linux-kernel, linux-serial, Hugo Villeneuve
In-Reply-To: <20260417-max310x-2-v1-0-b424e105ecac@dimonoff.com>
From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Having max310x_set_ref_clk() return an s32 as both an error code
and a frequency value is ambiguous. Fix by passing a pointer to the
frequency value that will then be updated, and simply return a status.
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
---
drivers/tty/serial/max310x.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
index b68a17ebd10b84fa2ecfc521efa454cb248f90b5..cf27e597ea41541331c8786fe4b4ded39b53d291 100644
--- a/drivers/tty/serial/max310x.c
+++ b/drivers/tty/serial/max310x.c
@@ -558,8 +558,8 @@ static int max310x_update_best_err(unsigned int f, unsigned int *besterr)
return 1;
}
-static s32 max310x_set_ref_clk(struct device *dev, struct max310x_port *s,
- unsigned int freq, bool xtal)
+static int max310x_set_ref_clk(struct device *dev, struct max310x_port *s,
+ unsigned int freq, unsigned int *fref, bool xtal)
{
unsigned int div, clksrc, pllcfg = 0;
unsigned int besterr = UINT_MAX;
@@ -632,7 +632,9 @@ static s32 max310x_set_ref_clk(struct device *dev, struct max310x_port *s,
"clock is not stable\n");
}
- return bestfreq;
+ *fref = bestfreq;
+
+ return 0;
}
static void max310x_batch_write(struct uart_port *port, u8 *txbuf, unsigned int len)
@@ -1271,7 +1273,7 @@ static int max310x_probe(struct device *dev, const struct max310x_devtype *devty
unsigned int fmin, fmax, freq;
int i, ret;
struct max310x_port *s;
- s32 uartclk = 0;
+ unsigned int uartclk = 0;
bool xtal;
for (i = 0; i < devtype->nr; i++)
@@ -1357,11 +1359,9 @@ static int max310x_probe(struct device *dev, const struct max310x_devtype *devty
regmap_write(regmaps[i], MAX310X_MODE1_REG, devtype->mode1);
}
- uartclk = max310x_set_ref_clk(dev, s, freq, xtal);
- if (uartclk < 0) {
- ret = uartclk;
+ ret = max310x_set_ref_clk(dev, s, freq, &uartclk, xtal);
+ if (ret < 0)
goto out_uart;
- }
dev_dbg(dev, "Reference clock set to %i Hz\n", uartclk);
--
2.47.3
^ permalink raw reply related
* [PATCH 04/10] serial: max310x: update baudrate comments for err calculation
From: Hugo Villeneuve @ 2026-04-17 14:53 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: hugo, linux-kernel, linux-serial, Hugo Villeneuve
In-Reply-To: <20260417-max310x-2-v1-0-b424e105ecac@dimonoff.com>
From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
The baudrate used to compute the best error was changed from 115200 to
460800 in commit 35240ba26a93 ("tty: max310x: Fix invalid baudrate
divisors calculator"), but the comment was not updated, so fix it.
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
---
drivers/tty/serial/max310x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
index cf27e597ea41541331c8786fe4b4ded39b53d291..f689958736f71b15b7c113214cda60db4aa7c593 100644
--- a/drivers/tty/serial/max310x.c
+++ b/drivers/tty/serial/max310x.c
@@ -547,7 +547,7 @@ static int max310x_set_baud(struct uart_port *port, int baud)
static int max310x_update_best_err(unsigned int f, unsigned int *besterr)
{
- /* Use baudrate 115200 for calculate error */
+ /* Use high-enough baudrate to calculate error */
unsigned int err = f % (460800 * 16);
if (*besterr > err) {
--
2.47.3
^ permalink raw reply related
* [PATCH 02/10] serial: max310x: simplify max310x_update_best_err()
From: Hugo Villeneuve @ 2026-04-17 14:53 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: hugo, linux-kernel, linux-serial, Hugo Villeneuve
In-Reply-To: <20260417-max310x-2-v1-0-b424e105ecac@dimonoff.com>
From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
besterr was defined as a signed type was to make sure that the first call
to max310x_update_best_err() would always set besterr. Also there is no
need for it to be a long. By changing its type to unsigned int and initial
value to UINT_MAX, max310x_update_best_err() can be simplified and be more
efficient while achieving the same initial result.
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
---
drivers/tty/serial/max310x.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
index 7c1c3696f5684d6dcaf1149e54bfa96c202c7b26..b68a17ebd10b84fa2ecfc521efa454cb248f90b5 100644
--- a/drivers/tty/serial/max310x.c
+++ b/drivers/tty/serial/max310x.c
@@ -545,12 +545,12 @@ static int max310x_set_baud(struct uart_port *port, int baud)
return (16*port->uartclk) / (c*(16*div + frac));
}
-static int max310x_update_best_err(unsigned int f, long *besterr)
+static int max310x_update_best_err(unsigned int f, unsigned int *besterr)
{
/* Use baudrate 115200 for calculate error */
- long err = f % (460800 * 16);
+ unsigned int err = f % (460800 * 16);
- if ((*besterr < 0) || (*besterr > err)) {
+ if (*besterr > err) {
*besterr = err;
return 0;
}
@@ -562,7 +562,7 @@ static s32 max310x_set_ref_clk(struct device *dev, struct max310x_port *s,
unsigned int freq, bool xtal)
{
unsigned int div, clksrc, pllcfg = 0;
- long besterr = -1;
+ unsigned int besterr = UINT_MAX;
unsigned int fdiv, fmul, bestfreq = freq;
/* First, update error without PLL */
--
2.47.3
^ permalink raw reply related
* [PATCH 00/10] serial: max310x: improvements and cleanups
From: Hugo Villeneuve @ 2026-04-17 14:53 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: hugo, linux-kernel, linux-serial, Hugo Villeneuve
Hello,
this patch series brings a few improvements and cleanups to the max310x
driver.
Note that I do not have access to a board with an actual max310x IC on it,
but I have tested it by using i2c-stub to simulate the four ports on a
virtual max14830 device.
Tests for patch "serial: max310x: use regmap_read_poll_timeout() for busy
wait":
Tested by setting the initial register values to 0x00, then loading the
driver with a (temporary) modified delay of 10s and using i2c-stub
to set register values to 0x01 after 5 seconds. Also tested by leaving
register to 0x00 and confirming the timout is properly handled.
Tests for reference clock computations:
Tested all possible frequencies from 5KHz to 35MHz in 1z increment
(osc mode) and comparing the resulting reference clock between the original
code and the new one, again using i2c-stub.
Thank you.
---
Hugo Villeneuve (10):
serial: max310x: uniformize clock/freq types
serial: max310x: simplify max310x_update_best_err()
serial: max310x: change return type of max310x_set_ref_clk()
serial: max310x: update baudrate comments for err calculation
serial: max310x: improve max310x_set_ref_clk() efficiency
serial: max310x: use regmap_read_poll_timeout() for busy wait
serial: max310x: use FIELD_PREP macro to set PLL bitfields
serial: max310x: allow driver to be built with SPI or I2C
serial: max310x: move variables to while() scope
serial: max310x: add comments for PLL limits
drivers/tty/serial/Kconfig | 2 +-
drivers/tty/serial/max310x.c | 179 ++++++++++++++++++++++++-------------------
2 files changed, 103 insertions(+), 78 deletions(-)
---
base-commit: a1a81aef99e853dec84241d701fbf587d713eb5b
change-id: 20260417-max310x-2-965fe921aea6
Best regards,
--
Hugo Villeneuve <hvilleneuve@dimonoff.com>
^ permalink raw reply
* [PATCH 01/10] serial: max310x: uniformize clock/freq types
From: Hugo Villeneuve @ 2026-04-17 14:53 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: hugo, linux-kernel, linux-serial, Hugo Villeneuve
In-Reply-To: <20260417-max310x-2-v1-0-b424e105ecac@dimonoff.com>
From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
max310x_set_ref_clk() returns a 32-bits clock value, so there is no need
to have parameters and intermediate values defined as long. Change
clock and freq types to int.
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
---
drivers/tty/serial/max310x.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
index ac7d3f197c3a5ce3531d5607f48e21a807314021..7c1c3696f5684d6dcaf1149e54bfa96c202c7b26 100644
--- a/drivers/tty/serial/max310x.c
+++ b/drivers/tty/serial/max310x.c
@@ -545,7 +545,7 @@ static int max310x_set_baud(struct uart_port *port, int baud)
return (16*port->uartclk) / (c*(16*div + frac));
}
-static int max310x_update_best_err(unsigned long f, long *besterr)
+static int max310x_update_best_err(unsigned int f, long *besterr)
{
/* Use baudrate 115200 for calculate error */
long err = f % (460800 * 16);
@@ -559,11 +559,11 @@ static int max310x_update_best_err(unsigned long f, long *besterr)
}
static s32 max310x_set_ref_clk(struct device *dev, struct max310x_port *s,
- unsigned long freq, bool xtal)
+ unsigned int freq, bool xtal)
{
unsigned int div, clksrc, pllcfg = 0;
long besterr = -1;
- unsigned long fdiv, fmul, bestfreq = freq;
+ unsigned int fdiv, fmul, bestfreq = freq;
/* First, update error without PLL */
max310x_update_best_err(freq, &besterr);
@@ -1268,7 +1268,8 @@ static int max310x_probe(struct device *dev, const struct max310x_devtype *devty
const struct max310x_if_cfg *if_cfg,
struct regmap *regmaps[], int irq)
{
- int i, ret, fmin, fmax, freq;
+ unsigned int fmin, fmax, freq;
+ int i, ret;
struct max310x_port *s;
s32 uartclk = 0;
bool xtal;
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v4 7/8] ARM: dts: Declare UART1 on zx297520v3 boards
From: Stefan Dösinger @ 2026-04-17 17:24 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Krzysztof Kozlowski,
Alexandre Belloni, Linus Walleij, Drew Fustini,
Greg Kroah-Hartman, Jiri Slaby, linux-doc, linux-kernel,
linux-arm-kernel, devicetree, soc, linux-serial
In-Reply-To: <0d80dcbe-cb46-45e5-821a-de5299d6a663@app.fastmail.com>
[-- Attachment #1: Type: text/plain, Size: 2283 bytes --]
Hi Arnd,
Thanks for your comments.
> Am 17.04.2026 um 11:59 schrieb Arnd Bergmann <arnd@arndb.de>:
>
> On Thu, Apr 16, 2026, at 22:19, Stefan Dösinger wrote:
>>
>> The reason why I add the serial1=uart1 alias is to keep console=ttyAMA1
>> stable regardless of the other enabled UARTs. UART0, as the name
>> implies, has a lower MMIO address, but uart1 is the one that usually has
>> the boot output and console.
>
> I'm not sure I'm following here. You generally want to either make
> sure the alias matches whatever number is printed on the product
> if there are multiple numbered ports, or you just use 'serial0'
> as the only alias if there is only one port.
Not all boards have their uart pins labeled, but those that do have the pins that connect to the UART at 0x01408000 named UART1RX/UART1TX. Most boards have only one though. I have seen a picture of only one that has UART0 and UART1. I could not test that board myself yet.
My original reason is one of developer convenience: If I have
uart0=serial@131000{
reg = <0x00131000 0x1000>;
...
status = "disabled";
};
uart1=serial@1408000{
reg = <0x01408000 0x1000>;
...
status = "okay";
};
cmdline="... console=ttyAMA{0/1} ..."
changing uart0.status between disabled and okay (e.g. to experiment with uart0 and pinctrl) required changing the command line to match. I found that pretty annoying and the aliases seemed like the best way to avoid this.
Either way I am open to do whatever. I can keep the current naming for the reasons stated above, I can name serial@1408000 "uart0" and leave the others without an alias or I can drop the alias altogether.
> Either way, the alias should go into the board specific file, not
> the general SoC file, as a board might be using a different
> set of UARTs.
That works for me, I'll move them. The aliases will most likely be the same for all boards based on this chipset, meaning duplicate code, but matching the alias to the board labels makes sense to me.
> Since you know the addresses of the other uart instances, I would
> suggest you add all of them at the same time.
Will do.
I'll hold off for a bit before I resend the patches to see if some other comments come up.
Cheers,
Stefan
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] serial: sh-sci: optimize max_freq determination
From: Hugo Villeneuve @ 2026-04-17 19:35 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: hugo, Hugo Villeneuve, biju.das.jz, linux-kernel, linux-serial
From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Follow example of rsci driver to avoid code duplication and useless
max_freq search when port->uartclk is set to zero.
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
---
Cc: biju.das.jz@bp.renesas.com
Biju: if you want, feel free to pickup this patch when you resubmit your
serie for "sh-sci/rsci: Fix divide by zero and clean up baud rate logic".
---
drivers/tty/serial/sh-sci.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 6c819b6b24258..dcee8b69adab2 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2711,14 +2711,15 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
* setup the baud rate generator hardware for us already.
*/
if (!port->uartclk) {
- baud = uart_get_baud_rate(port, termios, old, 0, 115200);
- goto done;
+ max_freq = 115200;
+ } else {
+ for (i = 0; i < SCI_NUM_CLKS; i++)
+ max_freq = max(max_freq, s->clk_rates[i]);
+
+ max_freq /= min_sr(s);
}
- for (i = 0; i < SCI_NUM_CLKS; i++)
- max_freq = max(max_freq, s->clk_rates[i]);
-
- baud = uart_get_baud_rate(port, termios, old, 0, max_freq / min_sr(s));
+ baud = uart_get_baud_rate(port, termios, old, 0, max_freq);
if (!baud)
goto done;
base-commit: a1a81aef99e853dec84241d701fbf587d713eb5b
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v4 2/8] dt-bindings: arm: Add zx297520v3 board binding
From: Rob Herring (Arm) @ 2026-04-17 21:08 UTC (permalink / raw)
To: Stefan Dösinger
Cc: linux-kernel, Conor Dooley, Jonathan Corbet, Alexandre Belloni,
Greg Kroah-Hartman, linux-doc, devicetree, Drew Fustini,
Linus Walleij, Jiri Slaby, Russell King, soc, Arnd Bergmann,
Krzysztof Kozlowski, Krzysztof Kozlowski, linux-arm-kernel,
linux-serial, Shuah Khan
In-Reply-To: <20260416-send-v4-2-e19d02b944ec@gmail.com>
On Thu, 16 Apr 2026 23:19:10 +0300, Stefan Dösinger wrote:
> Add a compatible for boards based on the ZTE zx297520v3 SoC.
>
> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
>
> ---
>
> The list of devices is the devices I have access to for testing. There
> are many more devices based on this board and it is not always easy to
> identify them. Often they are sold without any branding ("4G home
> router") or with mobile carrier branding.
> ---
> Documentation/devicetree/bindings/arm/zte.yaml | 25 +++++++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 26 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
./Documentation/devicetree/bindings/arm/zte.yaml:19:13: [warning] wrong indentation: expected 14 but found 12 (indentation)
dtschema/dtc warnings/errors:
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260416-send-v4-2-e19d02b944ec@gmail.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* RE: [PATCH] serial: sh-sci: optimize max_freq determination
From: Biju Das @ 2026-04-18 7:12 UTC (permalink / raw)
To: Hugo Villeneuve, Greg Kroah-Hartman, Jiri Slaby,
Geert Uytterhoeven
Cc: Hugo Villeneuve, linux-kernel@vger.kernel.org,
linux-serial@vger.kernel.org
In-Reply-To: <20260417193603.3906568-1-hugo@hugovil.com>
Hi Hugo,
> -----Original Message-----
> From: Hugo Villeneuve <hugo@hugovil.com>
> Sent: 17 April 2026 20:36
> Subject: [PATCH] serial: sh-sci: optimize max_freq determination
>
> From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
>
> Follow example of rsci driver to avoid code duplication and useless max_freq search when port->uartclk
> is set to zero.
>
> Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> ---
> Cc: biju.das.jz@bp.renesas.com
>
> Biju: if you want, feel free to pickup this patch when you resubmit your serie for "sh-sci/rsci: Fix
> divide by zero and clean up baud rate logic".
> ---
> drivers/tty/serial/sh-sci.c | 13 +++++++------
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c index
> 6c819b6b24258..dcee8b69adab2 100644
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -2711,14 +2711,15 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
> * setup the baud rate generator hardware for us already.
> */
> if (!port->uartclk) {
> - baud = uart_get_baud_rate(port, termios, old, 0, 115200);
> - goto done;
> + max_freq = 115200;
I have thought about this change. but the below comment made me not to do this change.
<snippet from Geert>
IIRC, baud == 0 can (only?) happen when using earlyprintk on a non-DT
system, where the serial console should just keep on using the settings
programmed by the firmware. So any config register writes should
be skipped.
</snippet>
Cheers,
Biju
> + } else {
> + for (i = 0; i < SCI_NUM_CLKS; i++)
> + max_freq = max(max_freq, s->clk_rates[i]);
> +
> + max_freq /= min_sr(s);
> }
>
> - for (i = 0; i < SCI_NUM_CLKS; i++)
> - max_freq = max(max_freq, s->clk_rates[i]);
> -
> - baud = uart_get_baud_rate(port, termios, old, 0, max_freq / min_sr(s));
> + baud = uart_get_baud_rate(port, termios, old, 0, max_freq);
> if (!baud)
> goto done;
>
>
> base-commit: a1a81aef99e853dec84241d701fbf587d713eb5b
> --
> 2.47.3
^ permalink raw reply
* Re: [PATCH] sysrq: add optional logging of caller info on /proc/sysrq-trigger write
From: Greg KH @ 2026-04-18 7:20 UTC (permalink / raw)
To: Xiang Gao; +Cc: jirislaby, akpm, linux-kernel, linux-serial, Xiang Gao
In-Reply-To: <20260416131419.1231012-1-gxxa03070307@gmail.com>
On Thu, Apr 16, 2026 at 09:14:19PM +0800, Xiang Gao wrote:
> From: Xiang Gao <gaoxiang17@xiaomi.com>
>
> When /proc/sysrq-trigger is written to, there is no record of which
> process triggered the sysrq operation. This makes it difficult to audit
> or debug who initiated a sysrq action, especially when the write comes
> from a shell spawned by system()/popen() where the immediate caller is
> "sh" rather than the originating application.
>
> Add CONFIG_MAGIC_SYSRQ_TRIGGER_LOG (default n) and a runtime toggle via
> module parameter sysrq.trigger_log (default off). When both are enabled,
> the kernel logs the triggering process's comm, pid, tgid, uid, and walks
> up to 5 levels of the parent process chain. This allows tracing the
> original initiator even through system()/popen()/fork+exec indirection.
>
> Example output:
> sysrq: proc trigger: comm=sh pid=68 tgid=68 uid=0
> sysrq: parent[0]: comm=my_app pid=67 tgid=67
> sysrq: parent[1]: comm=init pid=1 tgid=1
>
> Usage:
> # Compile-time: enable CONFIG_MAGIC_SYSRQ_TRIGGER_LOG=y
> # Runtime: echo 1 > /sys/module/sysrq/parameters/trigger_log
> # Or boot parameter: sysrq.trigger_log=1
>
> Signed-off-by: Xiang Gao <gaoxiang17@xiaomi.com>
> ---
> drivers/tty/sysrq.c | 29 +++++++++++++++++++++++++++++
> lib/Kconfig.debug | 16 ++++++++++++++++
> 2 files changed, 45 insertions(+)
>
> diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
> index c2e4b31b699a..e9277e7de35b 100644
> --- a/drivers/tty/sysrq.c
> +++ b/drivers/tty/sysrq.c
> @@ -48,6 +48,9 @@
> #include <linux/uaccess.h>
> #include <linux/moduleparam.h>
> #include <linux/jiffies.h>
> +#ifdef CONFIG_MAGIC_SYSRQ_TRIGGER_LOG
> +#include <linux/cred.h>
> +#endif
We really do not want or like #ifdef in .c files, and for stuff like
this, it is not needed at all.
> #include <linux/syscalls.h>
> #include <linux/of.h>
> #include <linux/rcupdate.h>
> @@ -59,6 +62,12 @@
> static int __read_mostly sysrq_enabled = CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE;
> static bool __read_mostly sysrq_always_enabled;
>
> +#ifdef CONFIG_MAGIC_SYSRQ_TRIGGER_LOG
> +static bool sysrq_trigger_log;
> +module_param_named(trigger_log, sysrq_trigger_log, bool, 0644);
> +MODULE_PARM_DESC(trigger_log, "Log caller info on /proc/sysrq-trigger write");
> +#endif
Module parameters are really not the way for stuff like this. And why
would such a "tiny" option need a config option at all? If you don't
use/need it, it's only a single bool being used?
> +
> static bool sysrq_on(void)
> {
> return sysrq_enabled || sysrq_always_enabled;
> @@ -1209,6 +1218,26 @@ static ssize_t write_sysrq_trigger(struct file *file, const char __user *buf,
> bool bulk = false;
> size_t i;
>
> +#ifdef CONFIG_MAGIC_SYSRQ_TRIGGER_LOG
> + if (sysrq_trigger_log) {
> + struct task_struct *task;
> + int depth = 0;
> +
> + pr_info("proc trigger: comm=%s pid=%d tgid=%d uid=%u\n",
> + current->comm, current->pid, current->tgid,
> + from_kuid(&init_user_ns, current_uid()));
The kernel log is not there for doing audits and the like, so is this
just a debug option?
> +
> + rcu_read_lock();
> + task = current;
> + while (task->pid > 1 && depth < 5) {
> + task = rcu_dereference(task->real_parent);
> + pr_info(" parent[%d]: comm=%s pid=%d tgid=%d\n",
> + depth++, task->comm, task->pid, task->tgid);
> + }
> + rcu_read_unlock();
This might cause problems for when the system is hung and sysrq is the
only way to reboot the box. Have you tried it in that situation?
> + }
> +#endif
> +
> for (i = 0; i < count; i++) {
> char c;
>
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index aac60b6cfa4b..46bd361decd0 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -705,6 +705,22 @@ config MAGIC_SYSRQ_SERIAL_SEQUENCE
>
> If unsure, leave an empty string and the option will not be enabled.
>
> +config MAGIC_SYSRQ_TRIGGER_LOG
> + bool "Log caller info on /proc/sysrq-trigger write"
> + depends on MAGIC_SYSRQ
> + default n
n is always the default, no need to add it again.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] serial: sh-sci: optimize max_freq determination
From: Hugo Villeneuve @ 2026-04-18 14:39 UTC (permalink / raw)
To: Biju Das
Cc: Greg Kroah-Hartman, Jiri Slaby, Geert Uytterhoeven,
Hugo Villeneuve, linux-kernel@vger.kernel.org,
linux-serial@vger.kernel.org
In-Reply-To: <TY3PR01MB1134667FC9A3920ADC444C21A86212@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Hi Biju,
On Sat, 18 Apr 2026 07:12:57 +0000
Biju Das <biju.das.jz@bp.renesas.com> wrote:
> Hi Hugo,
>
> > -----Original Message-----
> > From: Hugo Villeneuve <hugo@hugovil.com>
> > Sent: 17 April 2026 20:36
> > Subject: [PATCH] serial: sh-sci: optimize max_freq determination
> >
> > From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> >
> > Follow example of rsci driver to avoid code duplication and useless max_freq search when port->uartclk
> > is set to zero.
> >
> > Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > ---
> > Cc: biju.das.jz@bp.renesas.com
> >
> > Biju: if you want, feel free to pickup this patch when you resubmit your serie for "sh-sci/rsci: Fix
> > divide by zero and clean up baud rate logic".
> > ---
> > drivers/tty/serial/sh-sci.c | 13 +++++++------
> > 1 file changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c index
> > 6c819b6b24258..dcee8b69adab2 100644
> > --- a/drivers/tty/serial/sh-sci.c
> > +++ b/drivers/tty/serial/sh-sci.c
> > @@ -2711,14 +2711,15 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
> > * setup the baud rate generator hardware for us already.
> > */
> > if (!port->uartclk) {
> > - baud = uart_get_baud_rate(port, termios, old, 0, 115200);
> > - goto done;
> > + max_freq = 115200;
>
> I have thought about this change. but the below comment made me not to do this change.
>
> <snippet from Geert>
> IIRC, baud == 0 can (only?) happen when using earlyprintk on a non-DT
> system, where the serial console should just keep on using the settings
> programmed by the firmware. So any config register writes should
> be skipped.
> </snippet>
I think Geert comments referred to the clock (port->uartclk) being zero,
not the baud (the baud rate cannot be zero)...
But I am not sure how it is relevant here because the modification is
not changing the behavior of the existing code, it is an optimization
and a simplification. In fact, it is exactly the change I proposed [1]
when you submitted the rsci driver (and yoyu accepted), unless I am
missing something?
[1]
https://lore.kernel.org/all/20251028112236.c832fb48ad9fafcd2cf34b57@hugovil.com/
The goal of this patch is to have both rsci and sh-sci code to be the
same for this specific section at least. If you modify it to take into
account Geert's comments, then It think you need to do it both for rsci
and sh-sci drivers, no?
>
> Cheers,
> Biju
>
> > + } else {
> > + for (i = 0; i < SCI_NUM_CLKS; i++)
> > + max_freq = max(max_freq, s->clk_rates[i]);
> > +
> > + max_freq /= min_sr(s);
> > }
> >
> > - for (i = 0; i < SCI_NUM_CLKS; i++)
> > - max_freq = max(max_freq, s->clk_rates[i]);
> > -
> > - baud = uart_get_baud_rate(port, termios, old, 0, max_freq / min_sr(s));
> > + baud = uart_get_baud_rate(port, termios, old, 0, max_freq);
> > if (!baud)
> > goto done;
> >
> >
> > base-commit: a1a81aef99e853dec84241d701fbf587d713eb5b
> > --
> > 2.47.3
>
>
--
Hugo Villeneuve
^ permalink raw reply
* Re: [PATCH v4 2/8] dt-bindings: arm: Add zx297520v3 board binding
From: Stefan Dösinger @ 2026-04-19 8:30 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: linux-kernel, Conor Dooley, Jonathan Corbet, Alexandre Belloni,
Greg Kroah-Hartman, linux-doc, devicetree, Drew Fustini,
Linus Walleij, Jiri Slaby, Russell King, soc, Arnd Bergmann,
Krzysztof Kozlowski, Krzysztof Kozlowski, linux-arm-kernel,
linux-serial, Shuah Khan
In-Reply-To: <177646012448.2165534.5760108355183774935.robh@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 710 bytes --]
Hi Rob,
Am Samstag, 18. April 2026, 00:08:44 Ostafrikanische Zeit schrieben Sie:
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
Here is a new PEBKAC issue for your mail template: I ran dt_binding_check, it
wrote the warning you pointed out, but I only checked the return value - which
indicated success. Which I guess makes sense for a warning, since there seem
to be a few preexisting ones. The warning itself was somewhere in the
scrollback because I let dt_binding_check check all the files.
So I learned I have to actually look at the output to see if there are any
warnings.
Cheers,
Stefan
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* [GIT PULL] TTY/Serial driver changes for 7.1-rc1
From: Greg KH @ 2026-04-19 13:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jiri Slaby, Andrew Morton, linux-kernel, linux-serial
The following changes since commit c369299895a591d96745d6492d4888259b004a9e:
Linux 7.0-rc5 (2026-03-22 14:42:17 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tags/tty-7.1-rc1
for you to fetch changes up to a1a81aef99e853dec84241d701fbf587d713eb5b:
tty: serial: ip22zilog: Fix section mispatch warning (2026-04-02 15:59:56 +0200)
----------------------------------------------------------------
TTY/Serial changes for 7.1-rc1
Here is the set of tty and serial driver changes for 7.1-rc1.
Not much here this cycle, biggest thing is the removal of an old driver
that never got any actual hardware support (esp32), and the second try
to moving the tty ports to their own workqueues (first try was in
7.0-rc1 but was reverted due to problems.)
Otherwise it's just a small set of driver updates and some vt modifier
key enhancements.
All have been in linux-next for a while with no reported issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----------------------------------------------------------------
Alyssa Milburn (1):
tty: serial: samsung_tty: avoid dev_dbg deadlock
Andy Shevchenko (2):
serial: 8250_port: Drop duplicate NULL check
serial: xilinx_uartps: Drop unused include
Anup Kulkarni (1):
serial: qcom-geni: Fix RTS behavior with flow control
Biju Das (2):
dt-bindings: serial: renesas,rsci: Document RZ/G3L SoC
serial: sh-sci: Add support for RZ/G3L RSCI
Brian Masney (1):
serial: pic32_uart: allow driver to be compiled on all architectures with COMPILE_TEST
Fabio Estevam (1):
dt-bindings: serial: snps-dw-apb-uart: Add RV1103B compatible
Francesco Lavra (1):
serial: tegra: remove Kconfig dependency on APB DMA controller
Greg Kroah-Hartman (1):
Merge 7.0-rc5 into tty-next
Jason Andryuk (1):
hvc/xen: Check console connection flag
Julian Braha (1):
serial: remove drivers for espressif esp32
Kartik Rajput (4):
serial: amba-pl011: Introduce skip_ibrd_fbrd vendor flag
serial: amba-pl011: Introduce set_uartclk_rate vendor flag
serial: amba-pl011: Add Tegra264 UART support
serial: amba-pl011: Respect DMA controller's copy_align requirement
Kathiravan Thirumoorthy (1):
serial: qcom-geni: drop stray newline format specifier
Kexin Sun (1):
tty: atmel_serial: update outdated reference to atmel_tasklet_func()
Michael Walle (1):
tty: serial: 8250: Add SystemBase Multi I/O cards
Nicolas Pitre (3):
vt: add modifier support to cursor keys
vt: add KT_CSI keysym type for modifier-aware CSI sequences
vt: add fallback to plain map for modifier-aware key types
Peter Maydell (1):
serial: amba-pl011: Enable UART in earlycon setup
Qingfang Deng (1):
tty: constify tty_ldisc_ops
Randy Dunlap (2):
tty: hvc_iucv: fix off-by-one in number of supported devices
serdev: serdev.h: clean up kernel-doc comments
Ravi Rama (1):
serial: 8250_fintek: Add support for F81214E
Robert Marko (1):
dt-bindings: serial: atmel,at91-usart: add microchip,lan9691-usart
Robin Gong (1):
tty: serial: imx: keep dma request disabled before dma transfer setup
Ronan Pigott (1):
vt: support ITU-T T.416 color subparameters
Rong Zhang (2):
dt-bindings: serial: 8250: Add Loongson 3A4000 uart compatible
serial: 8250: loongson: Enable building on MIPS Loongson64
Thomas Bogendoerfer (1):
tty: serial: ip22zilog: Fix section mispatch warning
Xianwei Zhao (1):
dt-bindings: serial: amlogic,meson-uart: Add compatible string for A9
Xin Zhao (1):
tty: tty_port: add workqueue to flip TTY buffer
Zhaoyang Yu (1):
serial: auart: check clk_enable() return in console write
Documentation/devicetree/bindings/serial/8250.yaml | 1 +
.../bindings/serial/amlogic,meson-uart.yaml | 1 +
.../bindings/serial/atmel,at91-usart.yaml | 1 +
.../devicetree/bindings/serial/renesas,rsci.yaml | 26 +
.../bindings/serial/snps-dw-apb-uart.yaml | 1 +
drivers/tty/hvc/hvc_iucv.c | 2 +-
drivers/tty/hvc/hvc_xen.c | 3 +
drivers/tty/pty.c | 12 +-
drivers/tty/serial/8250/8250_core.c | 2 +-
drivers/tty/serial/8250/8250_fintek.c | 10 +-
drivers/tty/serial/8250/8250_pci.c | 51 ++
drivers/tty/serial/8250/8250_port.c | 4 +-
drivers/tty/serial/8250/Kconfig | 9 +-
drivers/tty/serial/Kconfig | 33 +-
drivers/tty/serial/Makefile | 2 -
drivers/tty/serial/amba-pl011.c | 153 +++-
drivers/tty/serial/apbuart.c | 2 +-
drivers/tty/serial/atmel_serial.c | 2 +-
drivers/tty/serial/dz.c | 2 +-
drivers/tty/serial/esp32_acm.c | 459 ------------
drivers/tty/serial/esp32_uart.c | 779 ---------------------
drivers/tty/serial/imx.c | 7 +-
drivers/tty/serial/ip22zilog.c | 4 +-
drivers/tty/serial/mxs-auart.c | 3 +-
drivers/tty/serial/qcom_geni_serial.c | 21 +-
drivers/tty/serial/rsci.c | 13 +
drivers/tty/serial/rsci.h | 1 +
drivers/tty/serial/samsung_tty.c | 10 +-
drivers/tty/serial/sh-sci-common.h | 1 +
drivers/tty/serial/sh-sci.c | 14 +-
drivers/tty/serial/xilinx_uartps.c | 1 -
drivers/tty/serial/zs.c | 2 +-
drivers/tty/tty_buffer.c | 15 +-
drivers/tty/tty_io.c | 25 +-
drivers/tty/tty_ldisc.c | 16 +-
drivers/tty/tty_port.c | 22 +
drivers/tty/vt/keyboard.c | 80 ++-
drivers/tty/vt/vt.c | 48 +-
include/linux/serdev.h | 9 +-
include/linux/tty_buffer.h | 1 +
include/linux/tty_driver.h | 7 +
include/linux/tty_ldisc.h | 6 +-
include/linux/tty_port.h | 13 +
include/uapi/linux/keyboard.h | 29 +
include/xen/interface/io/console.h | 13 +
45 files changed, 550 insertions(+), 1366 deletions(-)
delete mode 100644 drivers/tty/serial/esp32_acm.c
delete mode 100644 drivers/tty/serial/esp32_uart.c
^ permalink raw reply
* Re: [GIT PULL] TTY/Serial driver changes for 7.1-rc1
From: pr-tracker-bot @ 2026-04-19 15:54 UTC (permalink / raw)
To: Greg KH
Cc: Linus Torvalds, Jiri Slaby, Andrew Morton, linux-kernel,
linux-serial
In-Reply-To: <aeTena-xiaqaffDG@kroah.com>
The pull request you sent on Sun, 19 Apr 2026 15:54:37 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tags/tty-7.1-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/73398c2772d04ee656a654c63db85851381cd147
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH v2 2/2] riscv: ultrarisc: 8250_dw: support DP1000 uart
From: Jia Wang @ 2026-04-20 5:27 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jia Wang, Ilpo Järvinen, Greg Kroah-Hartman, Jiri Slaby,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-kernel,
linux-serial, linux-riscv, devicetree, Zhang Xincheng
In-Reply-To: <aeHlaTIKm1wl0J0_@ashevche-desk.local>
On 2026-04-17 10:46 +0300, Andy Shevchenko wrote:
> On Fri, Apr 17, 2026 at 03:32:17PM +0800, Jia Wang wrote:
> > On 2026-03-16 13:35 +0200, Andy Shevchenko wrote:
> > > On Mon, Mar 16, 2026 at 02:33:23PM +0800, Jia Wang via B4 Relay wrote:
>
> ...
>
> > > > +#define DW_UART_QUIRK_FIXED_TYPE BIT(6)
> > >
> > > Seems unrequired.
> > >
> > > But to make sure, can you elaborate what's going on here?
> > > What is the reads from UCV and CPR registers?
> >
> > Apologies for the delayed response.
> >
> > Our DW UART implementation on DP1000 does not provide the CPR/UCV capability
> > registers, and reads from both registers always return 0. As a result, the
> > autodetection logic in 8250_dw cannot obtain meaningful capability
> > information.
> >
> > To handle this, the current approach is to skip autodetection and rely on
> > fixed configuration via a quirk.
> >
> > If there is a preferred or more appropriate way to support DW UART instances
> > without CPR/UCV, I would be happy to adjust the implementation based on your
> > suggestions.
>
> Why can't you provide a CPR value via the existing quirk?
>
Thanks for the feedback.
I will switch to using DW_UART_QUIRK_CPR_VALUE in v3.
> --
> With Best Regards,
> Andy Shevchenko
>
>
>
Best Regards,
Jia Wang
^ permalink raw reply
* [PATCH] dt-bindings: serial: Add compatible for Qualcomm Nord SoC
From: Shawn Guo @ 2026-04-20 6:05 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Praveen Talari,
Konrad Dybcio, Dmitry Baryshkov, Bartosz Golaszewski,
Deepti Jaggi, linux-serial, devicetree, linux-arm-msm,
linux-kernel, Shawn Guo
From: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
Document compatibles for QUP GENI UART controller on Nord SoC with
fallback on SA8255P compatibles.
Signed-off-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
.../bindings/serial/qcom,sa8255p-geni-uart.yaml | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/serial/qcom,sa8255p-geni-uart.yaml b/Documentation/devicetree/bindings/serial/qcom,sa8255p-geni-uart.yaml
index c8f01923cb25..55e73b359f04 100644
--- a/Documentation/devicetree/bindings/serial/qcom,sa8255p-geni-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/qcom,sa8255p-geni-uart.yaml
@@ -14,9 +14,16 @@ allOf:
properties:
compatible:
- enum:
- - qcom,sa8255p-geni-uart
- - qcom,sa8255p-geni-debug-uart
+ oneOf:
+ - enum:
+ - qcom,sa8255p-geni-uart
+ - qcom,sa8255p-geni-debug-uart
+ - items:
+ - const: qcom,nord-auto-geni-uart
+ - const: qcom,sa8255p-geni-uart
+ - items:
+ - const: qcom,nord-auto-geni-debug-uart
+ - const: qcom,sa8255p-geni-debug-uart
reg:
maxItems: 1
--
2.43.0
^ permalink raw reply related
* [PATCH] dt-bindings: qcom: geni-se-qup: Add compatible for Nord SoC
From: Shawn Guo @ 2026-04-20 6:44 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Praveen Talari,
Konrad Dybcio, Dmitry Baryshkov, Bartosz Golaszewski,
Deepti Jaggi, linux-serial, devicetree, linux-arm-msm,
linux-kernel, Shawn Guo
From: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
Add compatibles for GENI Serial Engine QUP Wrapper Controller on Nord SoC
with fallback on SA8255P compatibles.
Signed-off-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
.../soc/qcom/qcom,sa8255p-geni-se-qup.yaml | 20 +++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml
index 352af3426d34..d73f9edcbbdb 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml
@@ -19,7 +19,12 @@ description:
properties:
compatible:
- const: qcom,sa8255p-geni-se-qup
+ oneOf:
+ - enum:
+ - qcom,sa8255p-geni-se-qup
+ - items:
+ - const: qcom,nord-auto-geni-se-qup
+ - const: qcom,sa8255p-geni-se-qup
reg:
description: QUP wrapper common register address and length.
@@ -67,9 +72,16 @@ patternProperties:
properties:
compatible:
- enum:
- - qcom,sa8255p-geni-uart
- - qcom,sa8255p-geni-debug-uart
+ oneOf:
+ - enum:
+ - qcom,sa8255p-geni-uart
+ - qcom,sa8255p-geni-debug-uart
+ - items:
+ - const: qcom,nord-auto-geni-uart
+ - const: qcom,sa8255p-geni-uart
+ - items:
+ - const: qcom,nord-auto-geni-debug-uart
+ - const: qcom,sa8255p-geni-debug-uart
required:
- compatible
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] serial: sh-sci: optimize max_freq determination
From: Geert Uytterhoeven @ 2026-04-20 7:13 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: Biju Das, Greg Kroah-Hartman, Jiri Slaby, Hugo Villeneuve,
linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org
In-Reply-To: <20260418103936.a3651d1606db7178fa7ff854@hugovil.com>
Hi Hugo,
On Sat, 18 Apr 2026 at 16:39, Hugo Villeneuve <hugo@hugovil.com> wrote:
> On Sat, 18 Apr 2026 07:12:57 +0000
> Biju Das <biju.das.jz@bp.renesas.com> wrote:
> > > From: Hugo Villeneuve <hugo@hugovil.com>
> > > Follow example of rsci driver to avoid code duplication and useless max_freq search when port->uartclk
> > > is set to zero.
> > >
> > > Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > > ---
> > > Cc: biju.das.jz@bp.renesas.com
> > >
> > > Biju: if you want, feel free to pickup this patch when you resubmit your serie for "sh-sci/rsci: Fix
> > > divide by zero and clean up baud rate logic".
> > > ---
> > > drivers/tty/serial/sh-sci.c | 13 +++++++------
> > > 1 file changed, 7 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c index
> > > 6c819b6b24258..dcee8b69adab2 100644
> > > --- a/drivers/tty/serial/sh-sci.c
> > > +++ b/drivers/tty/serial/sh-sci.c
> > > @@ -2711,14 +2711,15 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
> > > * setup the baud rate generator hardware for us already.
> > > */
> > > if (!port->uartclk) {
> > > - baud = uart_get_baud_rate(port, termios, old, 0, 115200);
> > > - goto done;
> > > + max_freq = 115200;
> >
> > I have thought about this change. but the below comment made me not to do this change.
> >
> > <snippet from Geert>
> > IIRC, baud == 0 can (only?) happen when using earlyprintk on a non-DT
> > system, where the serial console should just keep on using the settings
> > programmed by the firmware. So any config register writes should
> > be skipped.
> > </snippet>
>
> I think Geert comments referred to the clock (port->uartclk) being zero,
> not the baud (the baud rate cannot be zero)...
I did mean the baud variable being zero.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] serial: sh-sci: optimize max_freq determination
From: Geert Uytterhoeven @ 2026-04-20 7:23 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: Greg Kroah-Hartman, Jiri Slaby, Hugo Villeneuve, biju.das.jz,
linux-kernel, linux-serial
In-Reply-To: <20260417193603.3906568-1-hugo@hugovil.com>
Hi Hugo,
On Sat, 18 Apr 2026 at 07:24, Hugo Villeneuve <hugo@hugovil.com> wrote:
> From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
>
> Follow example of rsci driver to avoid code duplication and useless
> max_freq search when port->uartclk is set to zero.
>
> Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Thanks for your patch!
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -2711,14 +2711,15 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
> * setup the baud rate generator hardware for us already.
> */
> if (!port->uartclk) {
> - baud = uart_get_baud_rate(port, termios, old, 0, 115200);
> - goto done;
There was no "useless max_freq search", due to this goto?
> + max_freq = 115200;
> + } else {
> + for (i = 0; i < SCI_NUM_CLKS; i++)
> + max_freq = max(max_freq, s->clk_rates[i]);
> +
> + max_freq /= min_sr(s);
> }
>
> - for (i = 0; i < SCI_NUM_CLKS; i++)
> - max_freq = max(max_freq, s->clk_rates[i]);
> -
> - baud = uart_get_baud_rate(port, termios, old, 0, max_freq / min_sr(s));
> + baud = uart_get_baud_rate(port, termios, old, 0, max_freq);
> if (!baud)
> goto done;
>
Due to removing the goto above (for the casual reader: this is the
earlyprintk case, when port->uartclk is zero), the code will now
continue here, calculating transmission parameters and setting best_clk,
and overwriting the register configuration done by the bootloader.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox