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 all "commmon/" files and when needed add
missing include files directly.

Signed-off-by: Tom Rini <trini@konsulko.com>

Unexpected 'Esc' key presses are accumulated internally, even if it is
already clear that the current escape sequence is invalid. This results
in weird behaviour. For example, the next character after 'Esc' key
simply disappears from input and 'Unknown command' is printed
after 'Enter'.

This commit fixes some issues with extra 'Esc' keys entered by user:

1. Sequence <Esc><Esc><Enter> right after autoboot stop gives:
=>
nknown command 'ry 'help'
=>
2. Sequence <Esc><p><r><i><Enter> gives:
=> ri
Unknown command 'ri' - try 'help'
=>
3. Extra 'Esc' key presses break backspace functionality.

Signed-off-by: Yurii Monakov <monakov.y@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

This function does not behave as expected when unknown escape sequences
are sent to it:

- it fails to store (and thus echo) the last character of the invalid
  sequence
- it fails to set esc_len to 0 when it finishes emitting the invalid
  sequence, meaning that the following character will appear to be part
  of a new escape sequence
- it processes the first character of the rejected sequence as a valid
  character, just starting the sequence all over again

The last two bugs conspire to produce an "impossible condition #876"
message which is the main symptom of this behaviour.

Fix these bugs and add a test to verify the behaviour.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

Avoid duplicating some of the escape-sequence processing here and use the
CLI function instead.

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

The current cread_line() function is very long. It handles the escape
processing inline. The menu command does similar processing but at the
character level, so there is some duplication.

Split the character processing into a new function cli_ch_process() which
processes individual characters and returns the resulting input character,
taking account of escape sequences. It requires the caller to set up and
maintain its state.

Update cread_line() to use this new function.

The only intended functional change is that an invalid escape sequence
does not add invalid/control characters into the input buffer, but instead
discards these.

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