<div dir="ltr"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 24, 2022 at 11:35 AM Zev Weiss <<a href="mailto:zev@bewilderbeest.net">zev@bewilderbeest.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, May 24, 2022 at 02:30:02AM PDT, Patrick Rudolph wrote:<br>
> On Tue, May 24, 2022 at 1:07 AM Zev Weiss <<a href="mailto:zweiss@equinix.com" target="_blank">zweiss@equinix.com</a>> wrote:<br>
> <br>
> > On Mon, May 23, 2022 at 06:40:04AM PDT, Patrick Rudolph wrote:<br>
> > >Introduce CONFIG_ASPEED_DEBUG_UART_TO_UART1 and reuse existing<br>
> > >platform code to route the debug uart to RDX1/TDX1.<br>
> > >This is required on IBM/Genesis3 as it uses RDX1/TDX1 as debug uart.<br>
> > ><br>
> > >Signed-off-by: Patrick Rudolph <<a href="mailto:patrick.rudolph@9elements.com" target="_blank">patrick.rudolph@9elements.com</a>><br>
> > >Reviewed-by: Joel Stanley <<a href="mailto:joel@jms.id.au" target="_blank">joel@jms.id.au</a>><br>
> > >---<br>
> > > arch/arm/mach-aspeed/Kconfig | 5 +++++<br>
> > > arch/arm/mach-aspeed/ast2500/platform.S | 2 +-<br>
> > > 2 files changed, 6 insertions(+), 1 deletion(-)<br>
> > ><br>
> > >diff --git a/arch/arm/mach-aspeed/Kconfig b/arch/arm/mach-aspeed/Kconfig<br>
> > >index edb5520aec..a38f070381 100644<br>
> > >--- a/arch/arm/mach-aspeed/Kconfig<br>
> > >+++ b/arch/arm/mach-aspeed/Kconfig<br>
> > >@@ -82,6 +82,11 @@ config ASPEED_ENABLE_DEBUG_UART<br>
> > > systems, but may be useful to enable for debugging during<br>
> > > development.<br>
> > ><br>
> > >+config ASPEED_DEBUG_UART_TO_UART1<br>
> > >+ bool "Route debug UART to UART1"<br>
> > >+ depends on ASPEED_AST2500<br>
> > >+ help<br>
> > >+ Route debug UART to TXD1/RXD1 pins.<br>
> ><br>
> > Any reason not to put this in 'if ASPEED_ENABLE_DEBUG_UART' as suggested<br>
> > in the previous review? And since that one already has the<br>
> > ASPEED_AST2500 dependency, I think it'd obviate the need to have that<br>
> > specified on ASPEED_DEBUG_UART_TO_UART1.<br>
> ><br>
> > While we're at it, slightly more detail in the help text would good I<br>
> > think, perhaps just "... instead of the default TXD5/RXD5."<br>
> ><br>
> > Though actually, looking at the datasheet I'm now not certain if this<br>
> > does exactly what I had been thinking previously -- if I'm understanding<br>
> > it right, it's not so much switching the debug-UART functionality from<br>
> > UART5 to UART1, it's re-routing UART5 itself to the I/Os typically used<br>
> > for UART1? Which seems somewhat different, and I guess would ultimately<br>
> > be independent of the debug-UART itself being enabled or disabled, in<br>
> > which case maybe what I said earlier wasn't entirely appropriate...maybe<br>
> > someone with more expertise on the ast2500 UARTs (e.g. Andrew?) can<br>
> > weigh in?<br>
> ><br>
> > As I understand it only re-routes the UART5 to UART1 I/Os. However it<br>
> doesn't make any<br>
> sense to re-route the UART5 if it's disabled.<br>
> I'll push a new patch.<br>
> <br>
<br>
Bear in mind that there's a difference between UART5 and the debug-UART <br>
feature that can be enabled -- UART5 is a UART pretty much like all the <br>
others, but it happens to be the one on which the debug feature operates <br>
by default (listening for a secret password and providing access to <br>
various special operations via a simple command-line interface). Even <br>
with CONFIG_ASPEED_ENABLE_DEBUG_UART=n, UART5 is still available for use <br>
as a normal UART, it just doesn't have that magic debug capability <br>
turned on.<br>
<br></blockquote><div>Oh, I didn't know that. With that knowledge there should be no need to depend on the</div><div>CONFIG_ASPEED_ENABLE_DEBUG_UART when re-routing uart5.</div><div>I'll try another aproach.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Zev<br>
<br>
</blockquote></div></div>