| Message ID | CAPXt_dabk8KNL0HTHZJfoHT+93ZS+3R31tVEPb4zpKJWE65cMw@mail.gmail.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | b51040fc375c194e20164be489668d4d28001f53 |
| Delegated to: | Kalle Valo |
| Headers | show |
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? johannes
On 10 March 2017 at 09:56, Johannes Berg <johannes@sipsolutions.net> 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.
On Fri, 2017-03-10 at 10:11 +0100, Rostyslav Khudolii wrote: > On 10 March 2017 at 09:56, Johannes Berg <johannes@sipsolutions.net> > 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. johannes
Johannes Berg <johannes@sipsolutions.net> writes: > On Fri, 2017-03-10 at 10:11 +0100, Rostyslav Khudolii wrote: >> On 10 March 2017 at 09:56, Johannes Berg <johannes@sipsolutions.net> >> 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.
Rostyslav Khudolii <rkhudolii@airtame.com> 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. > A custom patch should be used in case such compatibility is required. > > Signed-off-by: Rostyslav Khudolii <rkhudolii@airtame.com> > Cc: Attila Sukosd <attila@airtame.com> For some reason the patch didn't apply to ath.git, I had manually recreate it. Please review carefully that the patch is correct now: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=cd63adf640e39c2ba013cba91b29700f3f593b9c Also I added your description of the bug to the commit log.
On 16 March 2017 at 10:36, Kalle Valo <kvalo@qca.qualcomm.com> wrote: > Rostyslav Khudolii <rkhudolii@airtame.com> 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. >> A custom patch should be used in case such compatibility is required. >> >> Signed-off-by: Rostyslav Khudolii <rkhudolii@airtame.com> >> Cc: Attila Sukosd <attila@airtame.com> > > For some reason the patch didn't apply to ath.git, I had manually recreate it. > Please review carefully that the patch is correct now: > > https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=cd63adf640e39c2ba013cba91b29700f3f593b9c > > Also I added your description of the bug to the commit log. > > -- > https://patchwork.kernel.org/patch/9615199/ > > Documentation about submitting wireless patches and checking status > from patchwork: > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches > It's correct.
Rostyslav Khudolii <rkhudolii@airtame.com> 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. A custom patch should be used in case such compatibility is required. > > 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. > > Signed-off-by: Rostyslav Khudolii <rkhudolii@airtame.com> > Cc: Attila Sukosd <attila@airtame.com> Patch applied to ath-next branch of ath.git, thanks. b51040fc375c ath6kl: Remove old 802.11a-only channels
diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c b/drivers/net/wireless/ath/ath6kl/cfg80211.c index 363b30a..aae65ce 100644 --- a/drivers/net/wireless/ath/ath6kl/cfg80211.c +++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c @@ -102,10 +102,8 @@ static struct ieee80211_channel ath6kl_2ghz_channels[] = { }; static struct ieee80211_channel ath6kl_5ghz_a_channels[] = { - CHAN5G(34, 0), CHAN5G(36, 0), - CHAN5G(38, 0), CHAN5G(40, 0), - CHAN5G(42, 0), CHAN5G(44, 0), - CHAN5G(46, 0), CHAN5G(48, 0), + CHAN5G(36, 0), CHAN5G(40, 0), + CHAN5G(44, 0), CHAN5G(48, 0), CHAN5G(52, 0), CHAN5G(56, 0), CHAN5G(60, 0), CHAN5G(64, 0), CHAN5G(100, 0), CHAN5G(104, 0),
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. A custom patch should be used in case such compatibility is required. Signed-off-by: Rostyslav Khudolii <rkhudolii@airtame.com> Cc: Attila Sukosd <attila@airtame.com> --- drivers/net/wireless/ath/ath6kl/cfg80211.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)