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. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
