Hi Andre, I have a couple questions and a bug report regarding the SBSA UART. When AArch64 Linux is boot with QEMU and UEFI (AAVMF) we can enable the use of ACPI. When we do that the PL011 model QEMU provides is exposed via the _HID ARMH0011. The Linux driver (amba-pl011.c) only associates this _HID with the SBSA UART. Is that _HID supposed to be specifically the SBSA UART? The '11' in the ID makes me think a full PL011 would be more appropriate. My second question is about the SBSA UART specification. The spec doesn't provide any registers to reset the FIFOs. Section 6.4 says the FIFOs should be enabled by hardware-specific software. However, even if that's done, then, if Linux does a driver-level shutdown of the UART, and then starts it back up again, it seems a FIFO reset is in order. Is there any way to reset the SBSA UART FIFOs that I don't see? The bug report is just my second question formulated differently; While Linux is booting the UART is started and stopped a few times. If the user sends characters to the UART during boot (just types on the terminal), then when the boot completes, and a login is presented, the user cannot input any characters and log in (Note, this is with QEMU's PL011 model. I don't know the status of boots with hardware, and it doesn't appear kvmtool emulates the PL011.) This is only seen when booting with ACPI (or a modified QEMU mach-virt DT that claims the UART is compatible with "arm,sbsa-uart"), as the problem is only with the SBSA UART implementation, which doesn't toggle the enable bit of the FIFO (UARTLCR_H.FEN) on startup/shutdown. When that bit is toggled by the PL011 driver the QEMU PL011 model resets its read FIFO and has no problem. Patching the model to reset the read FIFO when UARTIMSC=0 and UARTICR is being written as 0xffff, appears to resolve this issue, but it's a hack. Please let me know your thoughts on this. Thanks, drew -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
