On 11/13/2023 7:15 AM, Kalle Valo wrote:
Jeffrey Hugo <quic_jhugo@xxxxxxxxxxx> writes:
On 11/11/2023 9:24 PM, Baochen Qiang wrote:
On 11/11/2023 12:54 AM, Jeffrey Hugo wrote:
On 11/10/2023 3:21 AM, Kalle Valo wrote:
From: Baochen Qiang <quic_bqiang@xxxxxxxxxxx>
There is no driver to match these two channels, so
remove them. This fixes warnings from MHI subsystem during suspend:
mhi mhi0_LOOPBACK: 1: Failed to reset channel, still resetting
mhi mhi0_LOOPBACK: 0: Failed to reset channel, still resetting
This feels like just masking a real issue.
If LOOPBACK is not being consumed, then the channel should never go
into the start state. Why would we be trying to transition to the
reset state then?
-Jeff
That is because, with patch 'bus: mhi: host: add new interfaces to
handle MHI channels directly' in this patch set, ath11k is able to
call mhi_unprepare_all_from_transfer(), which will reset all
channels.
that implementation is flawed if it is causing this. Looks like you
never check to see if the channel was prepared in the first place.
If you go fix that, then it looks like this change is not needed.
BTW what do these loopback channels do? I didn't notice any difference
in the functionality so I'm wondering the reason for these.
The loopback channel is defined as a service where any data the host
sends to the device is immediately sent back to the host, unmodified.
The typical usecase is smoke test and performance profiling.
I do not object to the removal of the channel from the atheros devices,
assuming suitable justification. Not having a use for the channel seems
like good justification. Working around a bug seem more like a hack
than proper justification.
