[PATCH 1/9] cmd: aes: fix DM operation handling

[Simon Glass]

Hi James,

On 2026-07-02T01:46:51, James Hilliard <james.hilliard1 at gmail.com> wrote:
> cmd: aes: fix DM operation handling
>
> The DM AES command path takes operation-specific arguments after the
> common arguments. Parse the requested operation before reading those
> arguments so encrypt and decrypt use the correct positions.
>
> Also handle in-place operations by reusing the source mapping when the
> source and destination addresses match. Mapping and unmapping the same
> range twice can break UCLASS_AES providers that perform DMA-backed
> operations.
>
> Signed-off-by: James Hilliard <james.hilliard1 at gmail.com>
>
> cmd/aes.c | 24 ++++++++++++++++--------
>  1 file changed, 16 insertions(+), 8 deletions(-)

> Also handle in-place operations by reusing the source mapping when the
> source and destination addresses match. Mapping and unmapping the same
> range twice can break UCLASS_AES providers that perform DMA-backed
> operations.

Just to check, what actually breaks here? map_sysmem() is stateless: on
real hardware it is a plain cast (see include/mapmem.h) and on sandbox
it returns an offset into the RAM buffer, so when the addresses match
both calls already return the same pointer and unmap_sysmem() is a
no-op. It is not a DMA mapping, so I don't see how the double
map/unmap can affect a driver. If there is a real failure please
can you describe it; otherwise please drop these hunks. Either way this is a
separate logical change from the argv fix and should be its own patch.

> diff --git a/cmd/aes.c b/cmd/aes.c
> @@ -175,9 +175,9 @@ int cmd_aes_ecb(int argc, char *const argv[], u32 key_len)
> -     if (!strncmp(argv[1], 'enc', 3))
> +     if (!strncmp(argv[2], 'enc', 3))
>               enc = 1;
> -     else if (!strncmp(argv[1], 'dec', 3))
> +     else if (!strncmp(argv[2], 'dec', 3))

The fix is right, but the commit message undersells it: argv[1] holds
the subcommand (ecb or cbc), so the strncmp() always fails and these
commands unconditionally return CMD_RET_USAGE - they have never
worked. Please can you state that plainly and add a Fixes: tag, like:

    Fixes: b01444aa14cf ("cmd: aes: Add support for DM AES drivers")

BTW a sandbox test using the aes command with a DM_AES provider would
have caught this and would be a welcome addition to the series.

Regards,
Simon