Johannes Berg <johannes@xxxxxxxxxxxxxxxx> writes: > On Fri, 2017-03-10 at 10:11 +0100, Rostyslav Khudolii wrote: >> On 10 March 2017 at 09:56, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> >> wrote: >> > On Fri, 2017-03-10 at 09:49 +0100, Rostyslav Khudolii wrote: >> > > Channels 34/38/42/46 can only be used for compatibility with >> > > old devices sold in Japan. Modern products, such as AR6003/AR6004 >> > > don't support these channels. >> > > Keeping them in the upstream is error prone and requires full >> > > network stack support. >> > >> > Seems pointless. Nothing in the network stack really cares much >> > about >> > the channel numbers, so what exactly does this improve? >> > >> >> Without this one, a user is able to start an AP using wpa_supplicant, >> for example, on one of these channels (34/38/42/46), without getting >> any warning/error from the cfg80211 or ath6kl - which is correct >> (since these channels match regdom rules). However, the AR6003 and >> its >> firmware (we're using v3.4.0.225) will fail and return >> "WMI_CMDERROR_EVENTID" with "INVALID_PARAM" error code. >> In my opinion, ath6kl shouldn't support anything the firmware >> doesn't. >> We should also handle WMI_CMDERROR_EVENTID properly (not just >> printing >> a message), but this is another problem, I believe. > > Ah. I didn't make the connection that AR6003 was actually a product > that used this driver and thought you were using it as another peer and > then the two couldn't make a connection... > > My bad. I'll copy Rostyslav's description above to the commit log, I think it's useful information to document. -- Kalle Valo
