blob: 5c8c7f7b4831651c5ae8a432227d1b22be6fa891 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
|
id = 1458
title = "ns16550a reg-shift incorrect for qemu-system-riscv64"
state = "closed"
created_at = "2023-01-23T21:29:38.060Z"
closed_at = "2023-01-24T02:38:25.538Z"
labels = []
url = "https://gitlab.com/qemu-project/qemu/-/issues/1458"
host-os = "n/a"
host-arch = "n/a"
qemu-version = "n/a"
guest-os = "n/a"
guest-arch = "n/a"
description = """Missing reg-shift 0 on the ns16550n in qemu-system-riscv64 creates an impossible assumption case."""
reproduce = """1. qemu-system-riscv64 -M virt,dumpdtb=dtb
2. dtc dtb | less
serial@10000000 {
interrupts = <0x0a>;
interrupt-parent = <0x03>;
clock-frequency = "\\08@";
reg = <0x00 0x10000000 0x00 0x100>;
compatible = "ns16550a";
};
Generally, ns16550a has a default reg-shift of 0 on x86,x86_64 for compatibility reasons. All other architectures have an assumed reg-shift of 2 (or having the reg-shift assumption overridden by fdt providing a reg-shift property)
Beyond the above, anything non-standard is assumed to be specified by the "reg-shift" property fdt.
qemu-system-riscv64 seems to "assume" a reg-shift of 0. Other riscv64 devices don't supply "reg-shift" (SiFive Unmatched) and "assume" 2.
The above means driver writers don't actually know what to "assume" on riscv64 ns16550a when no reg-shift is present.
Essentially, qemu-system-riscv64 needs to do one of the following:
* If serial ns16550a with a uart reg-shift of 0 is intentional, qemu needs to advertise the deviance via "reg-shift 0"
* If serial ns16550a with a uart reg-shift of 0 is unintentional, it needs updated to 2 so drivers can assume 2 on riscv64."""
additional = "n/a"
|