Closed gsomlo closed 3 years ago
But I'm assuming there must be some implementations that still report litex,uart0
, right? Assuming the same driver works for both, should we not accept both strings?
On Thu, Mar 25, 2021 at 03:34:48PM -0700, Andrew Waterman wrote:
But I'm assuming there must be some implementations that still report litex,uart0, right? Assuming the same driver works for both, should we not accept both strings?
I'm not aware of any pre-existing use cases where the .dts file wasn't
embedded into BBL at build time (i.e., via --with-dts=foo.dts
), but
we can definitely exercise an abundance of caution and accept both.
I'll send an update shortly.
Replaced by PR #237
Not sure where all the merge conflicts came from, so I re-applied my commit on top of the new upstream master.
The upstream LiteX project defaults to "litex,liteuart" as the value for the "compatible" property of the UART DT node.
Signed-off-by: Gabriel Somlo gsomlo@gmail.com