servod: fix image_usbkey_dev situation
In the original logic to probe the block device file for a usb-stick the
code switches the usb-mux to the servo-visible, gets the dev-file, and
switches it back to the dut (if it originally pointed to the DUT).
This isn't stable i.e. if that value is cached and someone plugs in
another block device, that name might be taken in the meantime.
Other code (downloading images, and making them noninteractive) took
this value directly to write to the usb-device, potentially failing.
However, in the lab, probing the host dev file is used to determine if a
usb stick is attached or not. This is causing failures by reporting that
the usb stick is not attached, simply because it is not facing the
servo/host. This might have been 'hidden' by the fact that all 3 servo devices
deal with the usb-mux differently on initializatoin:
- v2 does not initialize it (probably defaults to servo)
- v3 initializes it towards the servo, powers it on
- v4 initializes it towards the dut, powers it on
Another change explores unifying that behavior.
This change aims to solve this by assuming that whenever the user
- wants to see the device file
- wants to download an image (using device file interface)
- wants to make that image non-interactive (using device file interface)
they want the usb-mux to
- face the servo
- be powered on
BUG=chromium:895705
TEST=manual testing on servo-v4
dut-control image_usbkey_mux
> dut_sees_usbkey
dut-control image_usbkey_dev
> /dev/sdb
dut-control image_usbkey_mux
> servo_sees_usbkey
Change-Id: I70d1277412c55964e38effd695c623ff2516531a
Signed-off-by: Ruben Rodriguez Buchillon <coconutruben@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1282548
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Matthew Blecker <matthewb@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
4 files changed
