[PATCH RFC 4/8] wifi: ath11k: remove MHI LOOPBACK channels

[Jeffrey Hugo]

On 11/13/2023 7:15 AM, Kalle Valo wrote:
> Jeffrey Hugo <quic_jhugo at quicinc.com> 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 at quicinc.com>
>>>>>
>>>>> 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.