The commit ce78ffa3ef16 ("net: really fix the build...") introduced two
issues into the mhi.c driver:
- use of initialized completion
- calling mhi_prepare_for_transfer twice
While the first one is pretty obvious, the second one makes all devices
using mhi.c to return -EINVAL during probe. Fist
mhi_prepare_for_transfer() would change both channels state to ENABLED.
Then when second mhi_prepare_for_transfer() would be called it would
also try switching them to ENABLED again, which is forbidden by the
state machine in the mhi_update_channel_state() function (see
drivers/bus/mhi/core/main.c).
These two issues make all drivers using qcom_mhi_qrtr (e.g. ath11k) to
fail with -EINVAL.
Fix them by removing first mhi_prepare_for_transfer() call and by adding
the init_completion() call.
Fixes: ce78ffa3ef16 ("net: really fix the build...")
Signed-off-by: Dmitry Baryshkov <redacted>
---
net/qrtr/mhi.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
Hi Dmitry,
On Sun, Aug 29, 2021 at 03:45:28PM +0300, Dmitry Baryshkov wrote:
The commit ce78ffa3ef16 ("net: really fix the build...") introduced two
issues into the mhi.c driver:
- use of initialized completion
- calling mhi_prepare_for_transfer twice
While the first one is pretty obvious, the second one makes all devices
using mhi.c to return -EINVAL during probe. Fist
mhi_prepare_for_transfer() would change both channels state to ENABLED.
Then when second mhi_prepare_for_transfer() would be called it would
also try switching them to ENABLED again, which is forbidden by the
state machine in the mhi_update_channel_state() function (see
drivers/bus/mhi/core/main.c).
These two issues make all drivers using qcom_mhi_qrtr (e.g. ath11k) to
fail with -EINVAL.
Fix them by removing first mhi_prepare_for_transfer() call and by adding
the init_completion() call.
Fixes: ce78ffa3ef16 ("net: really fix the build...")
Signed-off-by: Dmitry Baryshkov <redacted>
---
net/qrtr/mhi.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)