On Wed, 5 Apr 2023, Jan Kundrát wrote:
After upgrading from 5.16 to 6.1, our board with a MAX14830 started producing lots of garbage data over UART. Bisection pointed out commit 285e76fc049c as the culprit. That patch tried to replace hand-written code which I added in 2b4bac48c1084 ("serial: max310x: Use batched reads when reasonably safe") with the generic regmap infrastructure for batched operations.
Unfortunately, the `regmap_raw_read` and `regmap_raw_write` which were used are actually functions which perform IO over *multiple* registers. That's not what is needed for accessing these Tx/Rx FIFOs; the appropriate functions are the `_noinc_` versions, not the `_raw_` ones.
Fix this regression by using `regmap_noinc_read()` and `regmap_noinc_write()` along with the necessary `regmap_config` setup; with this patch in place, our board communicates happily again. Since our board uses SPI for talking to this chip, the I2C part is completely untested.
Fixes: 285e76fc049c serial: max310x: use regmap methods for SPI batch operations Signed-off-by: Jan Kundrát jan.kundrat@cesnet.cz Cc: stable@vger.kernel.org
drivers/tty/serial/max310x.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c index c82391c928cb..47520d4a381f 100644 --- a/drivers/tty/serial/max310x.c +++ b/drivers/tty/serial/max310x.c @@ -529,6 +529,11 @@ static bool max310x_reg_precious(struct device *dev, unsigned int reg) return false; } +static bool max310x_reg_noinc(struct device *dev, unsigned int reg) +{
- return reg == MAX310X_RHR_REG;
I'd either add a comment or just do || reg == MAX310X_THR_REG (which probably gets optimized away by the compiler) to make it look less magic for the Tx side.