serial_find_console_or_panic() may left cur_serial_dev unassigned if
REQUIRE_SERIAL_CONSOLE is not set. Setting GD_FLG_SERIAL_READY in
this situation confuses serial console code. It tries to use
unassigned driver instead of debug port and stops printing.
So check cur_serial_dev before setting GD_FLG_SERIAL_READY to allow
console to keep printing via debug port.

Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru>

Rasmus Villemoes <ravi@prevas.dk> says:

Some small improvements to the serial rx buffer feature.

CI seems happy: https://github.com/u-boot/u-boot/pull/674

Link: https://lore.kernel.org/r/20241003141029.920035-1-ravi@prevas.dk

The initialization of upriv->buf doesn't check for a NULL return. But
there's actually no point in doing a separate, unconditional malloc()
in post_probe; we can just make serial_dev_priv contain the rx buffer
itself, and let the (larger) allocation be handled by the driver core
when it allocates the ->per_device_auto. The total run-time memory
used is mostly the same, we reduce the code size a little, and as a
bonus, struct serial_dev_priv does not contain the unused members when
!SERIAL_RX_BUFFER.

Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>

The help text says it must be a power of 2, and the implementation
does rely on that. Enforce it.

A violation gives a wall of text, but the last few lines should be
reasonably obvious:

drivers/serial/serial-uclass.c:334:9: note: in expansion of macro ‘BUILD_BUG_ON_NOT_POWER_OF_2’
  334 |         BUILD_BUG_ON_NOT_POWER_OF_2(CONFIG_SERIAL_RX_BUFFER_SIZE);

Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>

Before the previous patch, pasting a string of length x >
CONFIG_SERIAL_RX_BUFFER_SIZE results in getting the
last (x%CONFIG_SERIAL_RX_BUFFER_SIZE) characters from that string.

With the previous patch, one instead gets the last
CONFIG_SERIAL_RX_BUFFER_SIZE characters repeatedly until the ->rd_ptr
catches up.

Both behaviours are counter-intuitive, and happen because the code
that checks for a character available from the hardware does not
account for whether there is actually room in the software buffer to
receive it. Fix that by adding such accounting. This also brings the
software buffering more in line with how most hardware FIFOs
behave (first received characters are kept, overflowing characters are
dropped).

Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>

The current implementation of the circular rx buffer falls into a
common trap with circular buffers: It keeps the head/tail indices
reduced modulo the buffer size. The problem with that is that it makes
it impossible to distinguish "buffer full" from "buffer empty",
because in both situations one has head==tail.

This can easily be demonstrated: Build sandbox with RX_BUFFER enabled,
set the RX_BUFFER_SIZE to 32, and try pasting the string

  01234567890123456789012345678901

Nothing seems to happen, but in reality, all characters have been read
and put into the buffer, but then tstc ends up believing nothing is in
the buffer anyway because upriv->rd_ptr == upriv->wr_ptr.

A better approach is to let the indices be free-running, and only
reduce them modulo the buffer size when accessing the array. Then
"empty" is head-tail==0 and "full" is head-tail==size. This does rely
on the buffer size being a power-of-two and the free-running
indices simply wrapping around to 0 when incremented beyond the
maximal positive value.

Incidentally, that change from signed to unsigned int also improves
code generation quite a bit: In C, (signed int)%(signed int) is
defined to have the sign of the dividend (so (-35) % 32 is -3, not
29), and hence despite the modulus being a power-of-two, x % 32 does
not actually compile to the same as a simple x & 31 - on x86 with -Os,
it seems that gcc ends up emitting an idiv instruction, which is quite
expensive.

Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>

Use the new symbol to refer to any 'SPL' build, including TPL and VPL

Signed-off-by: Simon Glass <sjg@chromium.org>

As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>

When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.

This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>

Remove <common.h> from this driver directory and when needed
add missing include files directly.

Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>