device reset #102
device reset #102
Conversation
bobwzy
force-pushed
the
device-reset
branch
2 times, most recently
from
7800940 to
aa2b0d6
Compare
tests/helper.py
Outdated
|
|
||
|
|
||
| async def init(host: Host): | ||
| await host.expect_control(uci.CoreDeviceResetRsp(status=uci.Status.OK)) |
There was a problem hiding this comment.
Can you please test with AOSP to make sure that the HAL is behaving as expected ?
Receiving the notification on init seems fine, but receiving a response for a command that was never sent looks dangerous.
There was a problem hiding this comment.
Tested with aosp and uwb cts tests and looks it works well.
There was a problem hiding this comment.
So the response is ignored ?
There was a problem hiding this comment.
I think so. This rsp is sent back before the hal opened, so no callback will be called.
https://cs.android.com/android/platform/superproject/main/+/main:hardware/interfaces/uwb/aidl/default/src/uwb_chip.rs;l=101?q=uwb_chip.rs&ss=android%2Fplatform%2Fsuperproject%2Fmain
There was a problem hiding this comment.
Still can you please check if it is possible to avoid sending that response ?
There was a problem hiding this comment.
Seems set is_reset to true when adding the device resolve the problem?
There was a problem hiding this comment.
Well that is just removing the logic for checking for device reset...
I feel that the more appropriate approach should be the modify the HAL to emit the Device Reset command on startup instead..
There was a problem hiding this comment.
But if we send the Device Reset command on startup on the HAL side, it will receive the response when the hal is open, which is not what we wanted.
There was a problem hiding this comment.
In the HCI HAL implementation I am intercepting the response before it is sent to host:
https://cs.android.com/android/platform/superproject/main/+/main:device/google/cuttlefish/guest/hals/bluetooth/src/hci.rs
2 participants
Uh oh!
There was an error while loading. Please reload this page.