On Tue, May 9, 2023, at 14:25, Ilpo Järvinen wrote:
On Tue, 9 May 2023, Arnd Bergmann wrote:I'd rename all of them and share nothing. I had the same thought as you
On Tue, May 9, 2023, at 12:17, Ilpo Järvinen wrote:So use the normal name for compatible ones and HW specific names for the
On Mon, 8 May 2023, Jacky Huang wrote:I think this came up in previous reviews, but it turned out that
+These duplicate include/uapi/linux/serial_reg.h ones, use the std ones
+#define UART_NR 17
+
+#define UART_REG_RBR 0x00
+#define UART_REG_THR 0x00
+#define UART_REG_IER 0x04
+#define UART_REG_FCR 0x08
+#define UART_REG_LCR 0x0C
+#define UART_REG_MCR 0x10
directly.
Setup regshift too and use it in serial_in.
only the first six registers are compatible, while the later
ones are all different, and it's not 8250 compatible.
others?
It might not be compatible in everything but surely 8250 influence is
visible here and there.
when I first looked at the driver, and thought of how we merged the omap
uart into 8250 for this reason, but after I found a datasheet for this
one, my impression was that it's a much more distant cousin of 8250
than the others,
There is clearly some family lineage, but there are differences
everywhere, and I don't think it was designed by extending a 8250
compatible hardware block with extra features, but rather built
from scratch (sigh) based only loosely on a register description
but then extending it with no intent of retaining compatibility.
Arnd