Return-path: Received: from mail-qy0-f174.google.com ([209.85.216.174]:37396 "EHLO mail-qy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758854Ab1JGW3u (ORCPT ); Fri, 7 Oct 2011 18:29:50 -0400 Received: by qyk30 with SMTP id 30so1058093qyk.19 for ; Fri, 07 Oct 2011 15:29:50 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1317772067-6998-1-git-send-email-mcgrof@qca.qualcomm.com> From: "Luis R. Rodriguez" Date: Fri, 7 Oct 2011 15:29:30 -0700 Message-ID: (sfid-20111008_002954_099051_C90C5638) Subject: Re: [PATCH 0/8] wireless: add DFS master support To: linux-wireless@vger.kernel.org, linville@tuxdriver.com, Johannes Berg Cc: "Luis R. Rodriguez" Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Fri, Oct 7, 2011 at 2:11 PM, Luis R. Rodriguez wrote: > On Tue, Oct 4, 2011 at 5:14 PM, Luis R. Rodriguez > wrote: >> On Tue, Oct 4, 2011 at 4:47 PM, Luis R. Rodriguez >> wrote: >>> This set of 8 patches adds DFS master support to the Linux wireless subsystem. >>> I've reviewed future possible changes to DFS master regions and it seems that >>> we are not going to be having multiple DFS regions for one country, instead >>> we'll always have one DFS region for one country. >>> >>> The changes here are spread out throughout wireless-regdb, crda the kernel and >>> lastly iw. The changes made allow for older verions of CRDA to work with new >>> wireless-regdb files with DFS region support. If you want DFS master region >>> support you'll need to upgrade your CRDA, your kernel and then hope someone >>> implements DFS master support for your respective driver. >>> >>> This patch series does not have specific driver changes, although some seem to >>> be backing in the oven right now. >> >> Here's a puzzle though... If we change this series to use the other >> pad byte that was available, the first pad byte, instead of the last >> one, we loose backward compatibility support and I cannot figure out >> why. What I ended up seeing was that crda sends the message, and for >> some reason (return code is 222 from nl_wait_for_ack(), whatever that >> is) the kernel rejects it. I suspect it may have to do with some sort >> of offset to the *other* data that makes some of the rules output >> invalid data for the attribute policy, but at least when I hexdump the >> wireless-regdb the only changes I see are in the signature and the pad >> shift. >> >> I got tired of trying though and after seeing flipping the pad bytes >> things worked decided to stay with it. In my original RFC in December >> I had used u16 instead, but since the data was in the last pad byte >> things still worked. So something is fishy about only using the first >> pad byte. The change below, as far as I can tell, should not have any >> issues but it does with the older version of CRDA and even a new one. > > Johannes spotted the issue, I'll send the fix, thanks to Johannes. > John, Johannes the patches still apply my fix goes on top of these > changes, the fix is not addressing a regression introduced by this > patchset, instead it fixes a long standing issue which would prevent > us from using the next available pad byte. I'm going to respin this to make use of 2 bits: 00 unset 01 FCC 10 ETSI 11 JP We may need some more DFS values later but Luis