uart: provide and use default rclk for JH7110 UART

[mhorne]

Summary

A regression in the u-boot-provided JH7110 device tree leaves the uart
incorrectly configured.

The issue arises when a baud rate is specified ('current-speed'
property), but the rclk value is not ('clock-frequency'). Previous
releases, e.g. v2025.04, provided both.

In this instance, we end up defaulting to DEFAULT_RCLK in ns8250_init(),
which is the wrong value. The relevant uart class (uart_snps) should
provide a default rclk in its definition, but it does not. Add a new
variant class with the correct default rclk of 24000000.

Finally, uart_cpu_fdt_probe() needs to be updated to actually query this
default value when it does not find a 'clock-frequency' property. This
was simply missing; the ACPI uart bus behaves identically, see
uart_acpi_probe().

PR: 289978
Reported by: [e-mail]
MFC after: 1 week?
Sponsored by: The FreeBSD Foundation

[jrtc27]

The logic for removing this in the FDT is that, on Linux, the clock framework comes up early enough (or at least some early part of it) in order to be able to query the UART clock's frequency from the clock driver, whereas we don't do anything like that with clocks prior to newbus passes, so way too late for cninit.

[mhorne]

In D53119#1213368, @jrtc27 wrote:

The logic for removing this in the FDT is that, on Linux, the clock framework comes up early enough (or at least some early part of it) in order to be able to query the UART clock's frequency from the clock driver, whereas we don't do anything like that with clocks prior to newbus passes, so way too late for cninit.

Yes. I can note this in the commit message.

What do you think of the patch?

[jrtc27]

In D53119#1213395, @mhorne wrote:

In D53119#1213368, @jrtc27 wrote:

The logic for removing this in the FDT is that, on Linux, the clock framework comes up early enough (or at least some early part of it) in order to be able to query the UART clock's frequency from the clock driver, whereas we don't do anything like that with clocks prior to newbus passes, so way too late for cninit.

Yes. I can note this in the commit message.

What do you think of the patch?

Seems reasonable at a glance, but not giving a proper approval as I'm busy listening to conference talks.