Closed michaeljclark closed 6 years ago
The changes have ended up being less trivial, albeit safe, as I've been fixing several spec conformance issues. I'm considering spinning a v9 patch series although we are quickly approaching soft-freeze. These could be added to v8 patch series as "bug fixes". i.e. they don't introduce new features.
Some very trivial fixes after going through the code several more times.
I'm pushing these changes to
riscv-wip
which is based on the last upstream rebase. We'll have to revise our branch strategy once we get accepted upstream. After we are upstream (assuming we make it) we should be able to create a stableriscv-qemu-2.12
branch based on upstreammaster
.riscv-next
is actually trailing at the moment given it is the default branch and our proxy for a stable branch. We can revise our branch strategy once we're upstream. i.e. when we haveriscv-qemu-2.12
, eitherriscv-qemu-2.12
ormaster
can become the default branch, and we useriscv-wip
orriscv-next
for integrating new features. At the moment we are targetting changes at the last rebase which presently isqemu-upstream-v8
; the pattern we have been using during the upstream review process.These changes make naming and function interfaces more consistent and lift hardcoded constants (timebase-frequency and clock-frequency) from the device-tree code into header defined constants.