expo: Set up menu fully in bootflow_menu_start()

Apply the theme, calculate dimensions, highlight the menu and arrange
the scene correctly, so that everything is ready to go when the expo
is rendered.

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

expo: Split setting up the menu from adding items

Some callers may wish to add items later as they are discovered. Split
the setup code into its own function, to permit this.

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

expo: Update bootflow_menu_poll() to return a sequence ID

Rather than returning a bootflow, return the index of the bootflow. This
will allow callers to do their own translation to bootflows or some
other data structure.

Also return a special code when the user tries to move the pointer, so
that the caller can cancel the boot-menu timeout, if this is in use.

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

expo: Improve the visual appearance of the menu

The menu is currently quite basic. Make use of some recently added
features in expo, to:

- Show proper prompts
- Highlight the current item
- Centre text
- Use multi-line text instead of two independent lines
- Put a box around the items

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

expo: Provide a way to position things relative to display

It is often necessary to centre objects within the display area. Add a
special position value to indicate this.

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

expo: Drop the render from expo_poll()

Within tests it is useful to be able to control rendering of the expo.
Drop the automatic call to expo_render() within expo_poll() and adjust
its callers to handle this instead.

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

expo: Adjust expo_poll() to avoid looping forever

If the user does not quickly provide some input, exit so that other
things can be done, such as searching for the next OS.

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

expo: Support highlighting menu items

Expo normally uses a pointer to show the current item. Add support for
highlighting as well, since this makes it easier for the user to see the
current item.

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

expo: Add forward declarations to scene_internal.h

Provide some forward declarations for types used in this file, to keep
the LSP happy and avoid errors if the caller happens not to include the
required header.

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

expo: Drop the gap between groups of menu items

The gap is intended to separate options which are on different bootdevs,
but most of the time there is only one. So drop this gap.

Keep the code around in case it becomes useful to have it in the style,
or based on some other mechanism.

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

expo: Use a simpler name for USB media

For USB devices we use the string 'usb_mass_storage' which is a bit
verbose. Use 'USB' instead.

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

expo: Begin implementation of a text editor

It is useful to be able to edit text, e.g. to allow the user to edit the
environment or the command-line arguments for the OS.

Add the beginnings of an implementation. Future work is needed to finish
this: keypress handling and scrolling. For now it just displays the
text.

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

expo: Support object alignment

Add support for left, right and centred alignment for text, in the
horizontal dimension.

Also support top, bottom and centred in the vertical dimension, for the
text object as a whole.

Alignment is not yet implemented for images. It has no meaning for
menus. A textline object uses a text object internally, so alignment
is supported there.

Provide some documentation to explain how objects are positioned.

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

expo: Implement a box

It is useful to be able to draw a box around elements in the menu. Add
support for an unfilled box with a selectable thickness.

Note that there is no support for selecting the colour for any expo
objects yet.

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

expo: Support white-on-black in the theme

Allow this setting to be controlled from the theme.

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

expo: Support rendering multiple lines of text

Use the measurement info to write each line of text separately, thus
respecting word-wrapping and newlines.

Fix up the comment for scene_obj_render() while we are here.

Since a lineedit does not support alignment, add a special case to just
display the text if there is no measurement. This happens assuming the
lineedit is initially empty.

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

expo: Check the screen contents after rendering

Make sure that the screen contents are as expected when a scene has been
rendered.

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

expo: Allow strings to be editable

In some cases dynamic text is needed, e.g. for a menu countdown. Add a
function which handles this, allowing the caller to take control of the
text that is shown on each render.

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

expo: Tidy up scene_txt_render()

Add an early return if there is no string. Move all declarations to the
top of the function.

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

expo: Move text-rendering into its own function

The code to render text is quite long, so put it in its own function.

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

expo: Create a struct for generic text attributes

In preparation for adding more text types, refactor the common fields
into a new structure. This will allow common code to be used.

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

expo: Line up all menu objects

At present labels are lined up vertically. Do the same with keys and
descriptions, since it looks nicer.

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

expo: Support setting the size and bounds of an object

Add a function to allow the size of an object to be set independently
of its position.

Also add a function to permit the object's bounding box to be set
independently of its dimensions.

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

expo: Make bounding-box calculation more flexible

In some cases it is useful to obtain more than just two bounding boxes
from a menu, e.g. to line up all descriptions vertically.

Use an array to obtain bounding-box information and calculate it
separately for each item.

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

expo: Separate dimensions from the bounding box

At present each object has a width and height and the bounding box is
implicit in that.

This is not flexible enough to handle objects which are larger than
their contents might need. For example, when centring a text object we
might want to have it stretch across the whole width of the display even
if the text itself does not need that much space.

Create a new 'dimensions' field and convert the existing width/height
into x1/y1 coordinates.

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

expo: Use an abuf to hold strings

It is more convenient to put strings in an abuf so they can easily be
resized. Adjust the struct accordingly.

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

expo: Rename x and y in struct scene_obj_bbox

These coordinates are the top left values, so rename them to x0 and y0
in preparation for changing the width and height to x1 and y1

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

expo: Rename scene_dim to scene_obj_bbox

At present we assume that each object is a simple box and that it fills
the whole box.

This is quite limiting for text objects, which we may want to centre
within the box. We need a position within the box where drawing starts.

Rename the scene_dim struct to indicate that it is a bounding box.

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

expo: Allow adding a single bootflow to a menu

Refactor bootflow_menu_add_all() to call a new bootflow_menu_add() to
add each of its bootflows.

Move the last_bootdev value into struct menu_priv to make this work.

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

expo: Split bootflow_menu_new() into two pieces

Split the iteration piece of this function into bootflow_menu_add_all()
so that it is possible for the caller to be in control of adding items
to the menu.

Move the expo_destroy() call into the caller.

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

expo: Split bootflow_menu_run() into two pieces

Split the starting piece of this function into bootflow_menu_start()
and the polling part into bootflow_menu_poll() so that it is possible
for the caller to be in control of the event loop.

Move the expo_destroy() call into the caller.

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

expo: Test editing a lineedit

Open the lineedit and add a few characters, to check that things look
right.

At present when the user moves to a new menu item, the menu code
handles this immediately. This means it is not possible to use an expo
action to effect the same change.

Update this so that EXPOACT_POINT_ITEM is handled in cedit_do_action().

Expand the test to cover this.

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

expo: Adjust how menu items are highlighted

At present when the user moves to a new menu item, the menu code
handles this immediately. This means it is not possible to use an expo
action to effect the same change.

Update this so that EXPOACT_POINT_ITEM is handled in cedit_do_action().

Expand the test to cover this.

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

expo: Provide access to the current menu item

Add functions to allow a caller to find out the current menu item and to
select a different one.

Update the event handling so that an attempt to change the current item
(e.g. by pressing the up-arrow key) is reported to the caller, since
this may be used to cancel an autoboot timeout.

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

expo: Test rendering a lineedit

Check the rendering output when adding characters to a line-edit object.

Add a separate test to check behaviour when starting with existing text
in the lineedit. The cursor should start at the end.

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

expo: Pass in the video device for cedit_prepare()

At present this function locates it own video device. Pass it in to
provide more flexibility.

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

expo: Test some cedit actions

Refactor the action-processing code into a new cedit_do_action()
function so we can call it from a test. Check moving to a new field and
opening the menu, to ensure that rendering is correct.

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

expo: Move cedit-state fields into expo

Move the boolean flags into struct expo so that the state can be
maintained over function calls.

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

expo: Create a rendering test for cedit

Add a test to check that the cedit renders as expected.

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

expo: Destroy the cedit expo when done

Once 'cedit run' is completed, destroy the expo so that a fresh one is
used for any future editing.

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

expo: Add a function to poll for input

Both bootflow_menu and cedit use similar logic to poll an expo. Move
this into the expo library so the code can be shared.

Update bootflow_menu_run() to return -EPIPE when the user quits without
choosing anything, since -EAGAIN is ambiguous and elsewhere means that
there is no input yet.

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

expo: Add CLI context to the expo

An expo generally needs to keep track of the keyboard state while it is
running, so move the context into struct expo

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

abuf: Add a way to printf() into a buffer

It is useful to format a string into a buffer, with the sizing handled
automatically. Add a function for this.

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

abuf: Add a function to copy a buffer

It is useful to be able to copy an abuf, to allow changes while
preserving the original. Add a function for this.

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

abuf: Add a helper for initing and allocating a buffer

This construct appears in various places. Reduce code size by adding a
function for it.

It inits the abuf, then allocates it to the requested size.

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

Merge patch series "Enable env in SCSI"

Varadarajan Narayanan <quic_varada@quicinc.com> says:

The qcs9100 based Ride platforms have UFS as their primary storage.
Hence add support to U-Boot env framework to be able to save and
retrieve the environment from UFS. The environment will be
saved/retrieved from the partition specified in the config option
CONFIG_SCSI_ENV_PART.

Also add an API to convert partition UUID string to block device
descriptor for UFS. This API will be used to get the block device
descriptor for the partition specified in CONFIG_SCSI_ENV_PART.

Link: https://lore.kernel.org/r/20250513091710.3719292-1-quic_varada@quicinc.com

configs: qcs9100: Enable env in SCSI

Enable CONFIG_ENV_IS_IN_SCSI to store environment variables in SCSI.
Set env variables partition UUID as seen in qcs9100 based boards.

Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
Reviewed-by: Casey Connolly <casey.connolly@linaro.org>

env: Add support for storing env variables in SCSI devices

Allow SCSI to be able to store environment variables.

Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
Acked-by: Casey Connolly <casey.connolly@linaro.org>

scsi: Implement get_blk() function

Add a function to obtain the block device for SCSI.

Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
Acked-by: Casey Connolly <casey.connolly@linaro.org>

disk: part: implement generic function part_get_info_by_uuid()

Add function to search for a partition by UUID as partition
names may not be unique.

Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
Acked-by: Casey Connolly <casey.connolly@linaro.org>

Merge patch series "Remove clocks from R5 dtsi for missed boards."

Manorit Chawdhry <m-chawdhry@ti.com> says:

Fix some of the boards that could be affected by the change done in [0].

[0]: https://lore.kernel.org/u-boot/20241121-b4-upstream-pll-fix-v1-0-904f618897a7@ti.com/T/#mecb70b415a364fdf322a94241438db7b5607e92b
Link: https://lore.kernel.org/r/20250515-b4-upstream-k3-pll-miss-v1-0-e38b89f027b8@ti.com

arm: dts: k3-am62a7-phycore-r5*: Remove clocks from main_timer0

The commit 79d91e77f4c2 ("clk: ti: clk-k3-pll: Add additional robustness
steps to the PLL sequence") introduced a change which requires the
main_timer0 to not rely on it's own clocks which anyways was wrong.

Fix it by removing the clock dependency for it, also while at it, move
it from u-boot.dtsi to R5 as that is the only entity that should require
it as DM isn't up.

Fixes: 5d1aac358f3c ("arm: dts: k3-*-r5: Remove clocks from mcu_timer0")
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
Acked-by: Wadim Egorov <w.egorov@phytec.de>

arm: dts: k3-am625-verdin-r5*: Remove clocks from main_timer0

The commit 79d91e77f4c2 ("clk: ti: clk-k3-pll: Add additional robustness
steps to the PLL sequence") introduced a change which requires the
main_timer0 to not rely on it's own clocks which anyways was wrong.

Fix it by removing the clock dependency for it, also while at it, move
it from u-boot.dtsi to R5 as that is the only entity that should require
it as DM isn't up.

Fixes: 5d1aac358f3c ("arm: dts: k3-*-r5: Remove clocks from mcu_timer0")
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com>

arm: dts: k3-am625-phycore-r5*: Remove clocks from main_timer0

The commit 79d91e77f4c2 ("clk: ti: clk-k3-pll: Add additional robustness
steps to the PLL sequence") introduced a change which requires the
main_timer0 to not rely on it's own clocks which anyways was wrong.

Fix it by removing the clock dependency for it, also while at it, move
it from u-boot.dtsi to R5 as that is the only entity that should require
it as DM isn't up.

Fixes: 5d1aac358f3c ("arm: dts: k3-*-r5: Remove clocks from mcu_timer0")
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>

arm: dts: k3-am625-beagleplay-r5*: Remove clocks from main_timer0

The commit 79d91e77f4c2 ("clk: ti: clk-k3-pll: Add additional robustness
steps to the PLL sequence") introduced a change which requires the
main_timer0 to not rely on it's own clocks which anyways was wrong.

Fix it by removing the clock dependency for it, also while at it, move
it from u-boot.dtsi to R5 as that is the only entity that should require
it as DM isn't up.

Fixes: 5d1aac358f3c ("arm: dts: k3-*-r5: Remove clocks from mcu_timer0")
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>

Merge patch series "Print Reset Reason for K3 based devices"

Wadim Egorov <w.egorov@phytec.de> says:

Although AM62x, AM62Ax, AM64x, and AM62Px share the same register for
reset reason, not all TRMs document this consistently. To avoid relying
on undocumented behavior, introduce SoC-specific implementations for
now. If TI confirms all SoCs share the same register, this can be moved to
common.c for reuse.

It will be mostly copy&paste for the mentioned devices.

Also, I am not sure how this Register operates exactly. I noticed that
two bits can be set at once, so I started to check for set bits instead
of having a switch/case logic.

Link: https://lore.kernel.org/r/20250515111554.2916254-1-w.egorov@phytec.de

arm: mach-k3: am62x: Implement get_reset_reason()

Implement get_reset_reason() for AM62x to enable reporting of
the reset cause in the cpuinfo output.

Signed-off-by: Wadim Egorov <w.egorov@phytec.de>

arm: mach-k3: Detect and print reset reason

Call get_reset_reason() during CPU info output and display the result
if the SoC provides the implementation. This helps in debugging by
providing context on the last system reset reason.

Signed-off-by: Wadim Egorov <w.egorov@phytec.de>

Merge patch series "Remove <env.h> from <net.h>"

Tom Rini <trini@konsulko.com> says:

Hey all,

This is a v3 of Simon's series[1] and depends on the series[2] I posted
the other day that removes <env.h> from <command.h>. With this series
done, I believe we've tackled all of the current cases of headers which
include <env.h> without directly needing it. Much of this series is in
fact Simon's v2 with the main differneces being:
- Removing <env.h> from <net.h> at the end
- Removing env_to_ip() given how little it's used rather than shuffling
  around where it's declared and un-inline'ing it. For a rarely used
  helper, this ends up being cleaner I think. Especially looking at some
  of the users (which called env_get repeatedly). If there's strong
  opinion here about using the other method[3] we can do that instead.
- Setting aside for now how to handle CMD_ELF=y and NO_NET=y because
  today it's actually fine as we unconditionally build lib/net_utils.c
  where string_to_ip() is defined. I'm unsure if a further series is
  warranted here or not. We rely on link-time optimization to keep code
  readable too.

[1]: https://lore.kernel.org/all/20250501010456.3930701-1-sjg@chromium.org
[2]: https://lore.kernel.org/all/20250514225002.15361-1-trini@konsulko.com
[3]: https://lore.kernel.org/all/20250501010456.3930701-23-sjg@chromium.org
Link: https://lore.kernel.org/r/20250515234154.1859366-1-trini@konsulko.com

include/net.h: Drop <env.h>

Now that all of the cases of code that relied on <net.h> to provide
<env.h> (or one of the headers that it includes, and so forth) have been
fixed, we can drop the include from here.

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

global: Avoid indirect inclusion of <env.h> from <net.h>

Now that env_get_ip() has been removed, the include file <net.h> does
not need anything from <env.h>. Furthermore, include/env.h itself
includes other headers which can lead to longer indirect inclusion
paths. To prepare to remove <env.h> from <net.h> fix all of the
remaining places which had relied on this indirect inclusion to instead
include <env.h> directly.

Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org> # net/lwip
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: Martyn Welch <martyn.welch@collabora.com>
Signed-off-by: Tom Rini <trini@konsulko.com>

net: dc2114x: Include env.h to permit reading the environment

This file uses the environment but does not include the header file.
Update it.

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

net: Include env.h in pcap.c

This file uses the environment but does not include the header file.
Update it.

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

net: Include byteorder in net6.h

This file uses byteorder but does not include the header file. Update
it.

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

technexion: Include env.h to permit reading the environment

This file reads from the environment but does not include the correct
header. Update it.

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

liebherr: Include env.h to permit reading the environment

This file reads from the environment but does not include the correct
header. Update it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>

google: Include env.h to permit reading the environment

This file reads from the environment but does not include the correct
header. Update it.

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

freescale: Include env.h to permit reading the environment

This file reads from the environment but does not include the correct
header. Update it.

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

amlogic: Include env.h to permit reading the environment

This file reads from the environment but does not include the correct
header. Update it.

Reviewed-by: Viacheslav Bocharov <adeep@lexina.in>
Signed-off-by: Simon Glass <sjg@chromium.org>

synology: Include env.h to permit reading the environment

This file reads from the environment but does not include the correct
header. Update it.

Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Tony Dinh <mibodhi@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>

tegra: Include env.h to permit reading the environment

This file reads from the environment but does not include the correct
header. Update it.

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

advantech: Include env.h in imx8qm_dmsse20_a1

This file uses the environment but does not include the header file.
Update it.

Acked-by: Oliver Graute <oliver.graute@kococonnector.com>
Signed-off-by: Simon Glass <sjg@chromium.org>

toradex: Include env.h to permit reading the environment

Two files read from the environment but don't not include the correct
header. Update them.

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

ronetix: Include env.h to permit reading the environment

This file reads from the environment but does not include the correct
header. Update it.

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

phytec: Include env.h to permit reading the environment

This file reads from the environment but does not include the correct
header. Update it.

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

venice: Include env.h to permit reading the environment

This file reads from the environment but does not include the correct
header. Update it.

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

net: Include string.h in net-legacy.h

This file uses memcpy() but does not include the header file. Update it.

Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Signed-off-by: Simon Glass <sjg@chromium.org>

imx8ulp_evk: Include env.h to permit reading the environment

This file reads from the environment but does not include the correct
header. Update it.

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

dhelectronics: Include env.h to permit reading the environment

This file reads from the environment but does not include the correct
header. Update it.

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

congatec: Include env.h to permit reading the environment

This file reads from the environment but does not include the correct
header. Update it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

net: Remove env_get_ip helper() function

Currently, we have the function env_get_ip which takes an IP address
in string form and returns a struct in_addr representation of that
address. It is however little used and means that a number of places
indirectly (and unclearly) get <env.h> via <net.h>. To clean this up
start by replacing env_get_ip() calls with string_to_ip() calls. This is
generally a no-op as env_get_ip(str) is an inline of
string_to_ip(env_get(str)) but in a few cases we can or already have
stored the result of env_get(str) and can save the additional call.

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

Merge patch series "Start removing <env.h> from headers when not required"

Tom Rini <trini@konsulko.com> says:

Given Simon's series at [1] I started looking in to what brings in
<env.h> when not strictly required and in turn has some unintended
implicit includes. This series takes care of the places where, commonly,
<linux/string.h> or <env.h> itself were required along with a few other
less common cases. This sets aside for the moment what to do about
net-common.h and env_get_ip() as I'm not entirely sure what's best
there.

[1]: https://patchwork.ozlabs.org/project/uboot/list/?series=454939&state=*
Link: https://lore.kernel.org/r/20250514225002.15361-1-trini@konsulko.com

include/command.h: Drop <env.h>

Now that all of the cases of code that relied on <command.h> to provide
<env.h> (or one of the headers that it includes, and so forth) have been
fixed, we can drop the include from here.

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

global: Avoid indirect inclusion of <env.h> from <command.h>

The include file <command.h> does not need anything from <env.h>.
Furthermore, include/env.h itself includes other headers which can lead
to longer indirect inclusion paths. To prepare to remove <env.h> from
<command.h> fix all of the places which had relied on this indirect
inclusion to instead include <env.h> directly.

Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org> # android, bcb
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org> # spawn
Signed-off-by: Tom Rini <trini@konsulko.com>

gpio: pca953x: Add missing <asm/byteorder.h>

This driver takes a long implicit include path to get this header which
it directly uses. Add it.

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

cmd/mem.c, test/cmd/mem_copy.c: Add <compiler.h>

These files require <compiler.h> in order to have MEM_SUPPORT_64BIT_DATA
be defined but currently rely on a long indirect include path to get it.
Add this directly.

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

global: Add <linux/string.h> instead of long indirect include path

In a number of cases we have C files which rely on a chain of indirect
include paths to get <linux/string.h> to be included via <command.h>. To
facilitate cleaning up <command.h> make this code directly include
<linux/string.h>.

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

Merge patch series "regex patches"

Rasmus Villemoes <ravi@prevas.dk> says:

This started as a rather simple patch, 1/12, adding the ability to
more conveniently do regex matching in shell.

But with that, it became very easy to see what the slre library can
and especially what it cannot do, and that way I found both outright
bugs and a "wow, doesn't it support that syntax" gotcha. I couldn't
find any tests ('git grep slre -- test/' was empty), so I added a
small test suite and tweaked slre.c.

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

doc: document test command

Add documentation for the test command, including the newly added =~
operator and some gotchas wrt. the numeric comparisons.

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

test: slre: add tests for character ranges

The first of these, { "U-Boot", "^[B-Uo-t]*$", 0 }, would match
previously when the - and the letters were all interpreted literally.

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

slre: implement support for ranges in character classes

When trying to use U-Boot's regex facility, it is a rather large
gotcha that [a-z] range syntax is not supported. It doesn't require a
lot of extra code to implement that; we just let the regular parsing
emit the start and end literal symbols as usual, and add a new
"escape" code RANGE.

At match time, this means the code will first just see an 'a' and try
to match that, and only then recognize that it's actually part of a
range and then do the 'a' <= ch <= 'z' test.

Of course, this means that a - in the middle of a [] pair no longer
matches a literal dash, but I highly doubt anybody relies on
that. Putting it first or last, or escaping it with \, as in most
other RE engines, continues to work.

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

test: slre: add test cases for escape char in character class

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

slre: fix matching of escape sequence used inside character class

At the compile stage, the anyof() function clearly intends to handle escape
sequences like \d (for digits) inside square brackets, since the logic
emits a 0 byte followed by the code representing the character
class (NONSPACE, SPACE or DIGIT).

However, this is not handled in the corresponding match helper
is_any_of(); it just naively loops over all the bytes in the ->data
array emitted by anyof() and compares those directly to the current
character. For example, this means that the string "\x11" (containing
the single character with value 17) is matched by the regex "[#%\d]",
because DIGIT happens to be 17.

Fix that by recognizing a zero byte as indicating something special
and act accordingly. In order not to repeat the "increment *ofs and
return 1" in all places, put those two lines after a new match: label.

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

slre: refactor is_any_but()

As preparation for fixing the handling of backslash-escapes used
inside a character class, refactor is_any_but() to be defined in terms
of is_any_of() so we don't have to repeat the same logic in two places.

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

test: slre: add some (negative) character class tests

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

test: slre: add more test cases

Add some tests for the "drop wrong anchored optimization". Without
the previous commit, the first, fifth and seventh of these would fail,
i.e. those:

{ "xby", "^a|b", 1},
{ "", "x*$", 1},
{ "yy", "x*$", 1},

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

slre: drop wrong "anchored" optimization

The regex '^a|b' means "does the string start with a, or does it have
a b anywhere", not "does the string start with a or b" (the latter
should be spelled '^[ab]' or '^(a|b)'). It should match exactly the
same strings as 'b|^a'. But the current implementation hard-codes an
assumption that when the regex starts with a ^, the whole regex must
match from the beginning, i.e. it only attempts at offset 0.

It really should be completely symmetrical to 'b|c$' ("does it have a
b anywhere or end with c?"), which is treated correctly.

Another quirk is that currently the regex 'x*$', which should match
all strings (because it just means "does the string end
with 0 or more x'es"), does not, because in the unanchored case we
never attempt to match at ofs==len. In the anchored case, '^x*$', this
works correctly and matches exactly strings (including the empty
string) consisting entirely of x'es.

Fix both of these issues by dropping all use of the slre->anchored
member and always test at all possible offsets. If the regex does have
a ^ somewhere (including after a | branch character), that is
correctly handled by the match engine by only matching when *ofs is 0.

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

test: slre: add tests for regex library

Inspecting the slre.c code reveals a few bugs; those are easy to
demonstrate with the new '=~' test operator. Before fixing them, let's
add a place to add test cases.

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

slre: add myself as maintainer

I guess that touching these files means "tag, you're it". That's fine
with me.

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

cmd: test: add support for =~ operator

Currently, the only way to make use of regex matching in the shell is
by using "setexpr [g]sub" command. That's rather awkward for asking
whether a string matches a regex. At the very least, it requires
providing setexpr with a dummy target variable, but also, the return
value of setexpr doesn't say whether any substitutions were done, so
one would have to do some roundabout thing like

  env set dummy "${string_to_test}"
  setexpr sub dummy '<some regex>' ''
  if test "${dummy}" != "${string_to_test}" ; then ...

When CONFIG_REGEX is set, teach the test command a new operator, =~,
which will allow one to more naturally write

  if test "${string_to_test}" =~ '<some regex>' ; then ...

The =~ operator with similar functionality is also supported in bash
when using its "extended" test operator [[ ]].

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