Amitkumar Karwar <akarwar@xxxxxxxxxxx> writes: >> Sorry for the delay. I have been thinking about vendor commands quite a >> lot and I don't think they belong to upstream drivers. For regular use >> cases (used by normal users) we have nl80211, for developer and testing >> purposes we have debugfs and for manufacturing type of tests we have >> nl80211 testmode interface. The focus of development should be adding >> new functionality to nl80211 (and other generic interfaces), not to >> driver specific vendor commands. >> >> I know brcm80211 and ti's wlcore have few vendor commands but I'm hoping >> to remove them sometime soon. >> >> Thoughts? >> > > Thanks for your reply. > > There is something called energy detect mode. Chip can detect non-WiFi > radio signal also and monitor it for specified time before > transmitting frames. As per ETSI specification, enabling this mode is > mandatory for some countries for certain frequencies. To me this looks this is something which can be generic, not a driver specific interface. And why can't regulatory code enable this automatically, without any user involvement? It already knows what country we are in. > The purpose of this patch is to configure the chip for working in this > mode. I can see cfg80211 has a framework to handle vendor specific > commands and events. I think having vendor commands would be helpful > to support vendor specific functionalities which can't be generalized. First of all, I don't see how the interface is mwifiex specific. If I could trust that using vendor commands will not slow down the development of nl80211, and other generic interfaces, I might think otherwise. But at the moment I am nowhere near that. > I suppose debugfs interface is only for collecting stats and info > which can be used for debugging purpose. Correct. I consider debugfs as a development and debugging interface for developers and advanced users. -- Kalle Valo
