Update Patrick and my email address with the one dedicated to
upstream activities.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>

Since commit 690079767803 ("cros_ec: Support keyboard scanning with
EC_CMD_GET_NEXT_EVENT") the cros-ec-keyb driver has started using this
command, but the sandbox EC emulator does not recognize it and
continuously prints:

    ** Unknown EC command 0x67

This patch makes the sandbox driver send basic responses to the command,
but the response only supports keyboard scans for now.

The EC side of this command stores and returns events from a queue, and
returns -EC_RES_UNAVAILABLE when there are no new events. This should be
possible to implement by hooking into the SDL event queue (perhaps via
sandbox_sdl_poll_events). Implementing that is a bit harder to do since
the existing sandbox code is discarding pending keyboard events, then
reading the current keyboard state.

Since the EC emulator never explicitly fails to work on this command,
the fallback to the older command will not trigger and will not be
tested anymore.

Fixes: 690079767803 ("cros_ec: Support keyboard scanning with EC_CMD_GET_NEXT_EVENT")
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

With commit 690079767803 ("cros_ec: Support keyboard scanning with
EC_CMD_GET_NEXT_EVENT") check_for_keys() tries to read keyboard
strokes using EC_CMD_GET_NEXT_EVENT. But the sandbox driver does
not understand this command. We need to reply with
-EC_RES_INVALID_COMMAND to force check_for_keys() to fall back to
use EC_CMD_MKBP_STATE. Currently the driver prints

    ** Unknown EC command 0x67

in this case. With the patch the message is suppressed.

In a future patch we should upgrade the sandbox driver to provide
EC_CMD_GET_NEXT_EVENT support.

Fixes: 690079767803 ("cros_ec: Support keyboard scanning with EC_CMD_GET_NEXT_EVENT")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

Erasing the flash can take over a second on some devices and the EC is
not responsive during this time. Update the timeout to 5 seconds to cope
with this.

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

The EC now requires that the offset field be set correctly when checking
on hash status. Update the code to handle this. Use the same message
struct in both functions to reduce stack space.

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

patman status subcommand to collect tags from Patchwork
patman showing email replies from Patchwork
sandbox poweroff command
minor fixes in binman, tests

The cros_ec_keyb driver currently uses EC_CMD_MKBP_STATE to scan the
keyboard, but this host command was superseded by EC_CMD_GET_NEXT_EVENT
and unavailable on more recent devices (including gru-kevin), as it was
removed in cros-ec commit 87a071941b89 ("mkbp: Add support for buttons
and switches.") dated 2016-07-06.

The EC_CMD_GET_NEXT_EVENT has been available since cros-ec commit
d1ed75815efe ("MKBP event signalling implementation") dated 2014-10-20,
but it looks like it isn't included in firmware-* branches for at least
link, nyan-big, samus, snow, spring, panther and peach-pit which have
defconfigs in U-Boot. So this patch falls back to the old method if the
EC doesn't recognize the newer command.

The implementation is mostly adapted from Depthcharge commit
f88af26b44fc ("cros_ec: Change keyboard scanning method.").

On a gru-kevin, the current driver before this patch fails to read the
pressed keys with:

    out: cmd=0x60: 03 9d 60 00 00 00 00 00
    in-header: 03 fc 01 00 00 00 00 00
    in-data:
    ec_command_inptr: len=-1, din=0000000000000000
    check_for_keys: keyboard scan failed

However the keyboard works fine with the newer command:

    out: cmd=0x67: 03 96 67 00 00 00 00 00
    in-header: 03 ef 00 00 0e 00 00 00
    in-data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    ec_command_inptr: len=14, din=00000000f412df30
    key_matrix_decode: num_keys = 0
      0 valid keycodes found
    out: cmd=0x67: 03 96 67 00 00 00 00 00
    in-header: 03 df 00 00 0e 00 00 00
    in-data: 00 00 00 00 00 00 00 00 00 00 00 00 10 00
    ec_command_inptr: len=14, din=00000000f412df30
    key_matrix_decode: num_keys = 1
      valid=1, row=4, col=11
        keycode=28
      1 valid keycodes found
     {0d}

Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Fix the dtoc warning in these file by using a driver name that matches the
compatible string.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

of-platdata and dtoc improvements
sandbox SPL tests
binman support for compressed sections

At present we use a 'node' pointer in the of-platadata phandle_n_arg
structs. This is a pointer to the struct driver_info for a particular
device, and we can use it to obtain the struct udevice pointer itself.

Since we don't know the struct udevice pointer until it is allocated in
memory, we have to fix up the phandle_n_arg.node at runtime. This is
annoying since it requires that SPL's data is writable and adds a small
amount of extra (generated) code in the dm_populate_phandle_data()
function.

Now that we can find a driver_info by its index, it is easier to put the
index in the phandle_n_arg structures.

Update dtoc to do this, add a new device_get_by_driver_info_idx() to look
up a device by drive_info index and update the tests to match.

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