> Tony Chuang <yhchuang@xxxxxxxxxxx> writes: > > > Kalle Valo <kvalo@xxxxxxxxxxxxxx> : > > > >> <yhchuang@xxxxxxxxxxx> writes: > >> > >> > From: Yan-Hsuan Chuang <yhchuang@xxxxxxxxxxx> > >> > > >> > Sometimes we need to stop the coex mechanism to debug, so that we > >> > can manually control the device through various outer commands. > >> > Hence, add a new debugfs coex_enable to allow us to enable/disable > >> > the coex mechanism when driver is running. > >> > > >> > To disable coex > >> > echo 0 > /sys/kernel/debug/ieee80211/phyX/rtw88/coex_enable > >> > > >> > To enable coex > >> > echo 1 > /sys/kernel/debug/ieee80211/phyX/rtw88/coex_enable > >> > > >> > To check coex dm is enabled or not > >> > cat /sys/kernel/debug/ieee80211/phyX/rtw88/coex_enable > >> > >> I forgot, did we add a command to nl80211 for managing btcoex? At least > >> we have talking about that for years. Please check that first before > >> adding a debugfs interface for this. > >> > > > > Yes, I found there was a thread [1] talking about adding a callback to > > enable/disable btcoex, but it seems not get applied eventually. > > Too bad, I really think we should have at least enable/disable > functionality in nl80211. But if it's not there, I guess it's ok to have > yet another driver custom debugfs file :/ > > > And there's another thread [2] talking about add a btcoex subsystem. > > But seems like nobody can implement it cleanly in the host. > > > > I think adding btcoex subsystem could have a lot of pain since each > > vendor is using different mechanism controlling the btcoex, and it > > usually comes with RF related design which is difficult to write a common > > function to deal with all kinds of them. > > Yeah, btcoex subsystem is a big challenge. > So I think we can take this patch set. It is really useful to debug on coex's issues. Yen-Hsuan
