Re: [PATCH] wireless-regdb: Update regulatory rules for Taiwan (TW)

[Chen-Yu Tsai]

On Thu, Jul 9, 2015 at 11:15 PM, Seth Forshee
 wrote:
> On Wed, Jul 08, 2015 at 11:07:20AM +0800, Chen-Yu Tsai wrote:
>> > Thanks. I think there should be a written document about what the
>> > rules should be like, or what is expected:
>> >
>> >   1. WiFi channel boundaries or band boundaries
>> >   2. peak output power or peak power spectral density
>> >
>> > In 
>> > http://lists.infradead.org/pipermail/wireless-regdb/2015-July/000856.html
>> > you mentioned the software is smart enough to work out how to combine
>> > different bands and what channels to use, so I see no reason to explicitly
>> > chop up contiguous spectrum, unless there are explicit rules forbidding
>> > combined use of bands with different regulatory rules. AFAIK the FCC
>> > only requires one to satisfy all rules when usage crosses band boundaries.
>> >
>> > http://lists.infradead.org/pipermail/wireless-regdb/2015-July/000857.html
>> > also raises a similar question.
>
> I was really commenting about the transmit power updates in your patch.
> I just compared the frequency changes to the documentation you linked to
> and those do look okay to me.

I see.

>> >> I would however consider an update for 5.15-5.25 GHz and 5.6-5.65 GHz
>> >> provided that there's official documentation to substantiate the change.
>> >> I unfortunately cannot read Chinese, so I would need some assistance to
>> >> confirm the documentation.
>> >
>> > I could possibly ask around, though I'm not optimistic. The "official"
>> > documents are just transcripts from NCC hosted Q&A sessions regarding
>> > the latest regulations. Proposals/questions are submitted by vendors,
>> > and the NCC responds and puts together an aggregated transcript.
>>
>> Just got off the phone with the NCC. Their position is, spectrum allocation
>> is not within their purview, but the Ministry of Transportation and
>> Communications. As noted in the patch, they have already opened up the
>> spectrum to U-NII and low power radio usage. What remains is that the
>> NCC revise its testing standards. Until then, their position is that,
>> since their testing standards are modeled after FCC standards, vendors
>> can just test under FCC standards, then convert the reports into LP0002
>> format, and cite the FCC test report.
>>
>> There is no formal English version of the Q&A transcript, at least not
>> until some foreign testing body requests it. The person in charge just
>> asked me to translate it myself...
>
> If you send a patch which updates only the frequencies I would likely
> apply that after allowing a week or so for others to either ack or nack
> it (and running the stuff you linked to through google translate and
> seeing if I could make any sense of the output).

Got it.

> I think the power updates are probably based on a misunderstanding, and
> may not even be completely correct. For the most part after they've been
> converted to EIRP (eirp = 10 * log10(mW)) they don't turn out to be
> substantially different than what we have now. I think the value in
> 5250-5350 MHz is probably incorrect however. Based on my quick skim of
> the document you linked to it should be 50 mW rather than 250. 50 mW
> also roughly matches to the 17 dBm which is in the database today,
> whereas 250 mW is closer to 24 dBm.

Yes. About the first part, it seems dbparse.py converts values in mW
into EIRP anyway. However I don't think EIRT equals "peak power spectral
density".

About the second part, yes the current values match the ones in LP0002.
However as I stated, the regulatory body has explicitly allowed certifying
under the latest FCC rules, which effectively raises the limits from
50 mW to 250 mW.

> My suggestion would be update the frequencies but not the existing
> transmit power limits, unless you discover that any of the power limits
> are definitely incorrect.

I'll split up the patch into 3:

  1. Add the new 5150 - 5250 frequency band, using current LP0002
 limits if any, otherwise FCC limits.

  2. Tweak frequency boundaries for the remaining bands to make
 them contiguous and properly reflect the regulations rather
 than the WiFi channel frequencies.

  3. Update power limits and DFS requirements to latest FCC standards.

Each patch will then explain why and how the regulations changed
along with references, in English if available.

You can then decide on whether to merge all three or just the first
two.


Regards
ChenYu
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] wireless-regdb: Update regulatory rules for Taiwan (TW)

[Chen-Yu Tsai]

On Wed, Jul 22, 2015 at 3:40 PM, Chen-Yu Tsai  wrote:
> On Thu, Jul 9, 2015 at 11:15 PM, Seth Forshee
>  wrote:
>> On Wed, Jul 08, 2015 at 11:07:20AM +0800, Chen-Yu Tsai wrote:
>>> > Thanks. I think there should be a written document about what the
>>> > rules should be like, or what is expected:
>>> >
>>> >   1. WiFi channel boundaries or band boundaries
>>> >   2. peak output power or peak power spectral density
>>> >
>>> > In 
>>> > http://lists.infradead.org/pipermail/wireless-regdb/2015-July/000856.html
>>> > you mentioned the software is smart enough to work out how to combine
>>> > different bands and what channels to use, so I see no reason to explicitly
>>> > chop up contiguous spectrum, unless there are explicit rules forbidding
>>> > combined use of bands with different regulatory rules. AFAIK the FCC
>>> > only requires one to satisfy all rules when usage crosses band boundaries.
>>> >
>>> > http://lists.infradead.org/pipermail/wireless-regdb/2015-July/000857.html
>>> > also raises a similar question.
>>
>> I was really commenting about the transmit power updates in your patch.
>> I just compared the frequency changes to the documentation you linked to
>> and those do look okay to me.
>
> I see.
>
>>> >> I would however consider an update for 5.15-5.25 GHz and 5.6-5.65 GHz
>>> >> provided that there's official documentation to substantiate the change.
>>> >> I unfortunately cannot read Chinese, so I would need some assistance to
>>> >> confirm the documentation.
>>> >
>>> > I could possibly ask around, though I'm not optimistic. The "official"
>>> > documents are just transcripts from NCC hosted Q&A sessions regarding
>>> > the latest regulations. Proposals/questions are submitted by vendors,
>>> > and the NCC responds and puts together an aggregated transcript.
>>>
>>> Just got off the phone with the NCC. Their position is, spectrum allocation
>>> is not within their purview, but the Ministry of Transportation and
>>> Communications. As noted in the patch, they have already opened up the
>>> spectrum to U-NII and low power radio usage. What remains is that the
>>> NCC revise its testing standards. Until then, their position is that,
>>> since their testing standards are modeled after FCC standards, vendors
>>> can just test under FCC standards, then convert the reports into LP0002
>>> format, and cite the FCC test report.
>>>
>>> There is no formal English version of the Q&A transcript, at least not
>>> until some foreign testing body requests it. The person in charge just
>>> asked me to translate it myself...
>>
>> If you send a patch which updates only the frequencies I would likely
>> apply that after allowing a week or so for others to either ack or nack
>> it (and running the stuff you linked to through google translate and
>> seeing if I could make any sense of the output).
>
> Got it.
>
>> I think the power updates are probably based on a misunderstanding, and
>> may not even be completely correct. For the most part after they've been
>> converted to EIRP (eirp = 10 * log10(mW)) they don't turn out to be
>> substantially different than what we have now. I think the value in
>> 5250-5350 MHz is probably incorrect however. Based on my quick skim of
>> the document you linked to it should be 50 mW rather than 250. 50 mW
>> also roughly matches to the 17 dBm which is in the database today,
>> whereas 250 mW is closer to 24 dBm.
>
> Yes. About the first part, it seems dbparse.py converts values in mW
> into EIRP anyway. However I don't think EIRT equals "peak power spectral
> density".

Sorry, this part applies to the US rules, not part of this patch.

> About the second part, yes the current values match the ones in LP0002.
> However as I stated, the regulatory body has explicitly allowed certifying
> under the latest FCC rules, which effectively raises the limits from
> 50 mW to 250 mW.
>
>> My suggestion would be update the frequencies but not the existing
>> transmit power limits, unless you discover that any of the power limits
>> are definitely incorrect.
>
> I'll split up the patch into 3:
>
>   1. Add the new 5150 - 5250 frequency band, using current LP0002
>  limits if any, otherwise FCC limits.
>
>   2. Tweak frequency boundaries for the remaining bands to make
>  them contiguous and properly reflect the regulations rather
>  than the WiFi channel frequencies.
>
>   3. Update power limits and DFS requirements to latest FCC standards.
>
> Each patch will then explain why and how the regulations changed
> along with references, in English if available.
>
> You can then decide on whether to merge all three or just the first
> two.
>
>
> Regards
> ChenYu
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RESEND] ath9k: Fix NF CCA limits for AR9287 and AR9227

[Martin Blumenstingl]

The FreeBSD driver [0] uses the same 2G values as for the AR9280 chips.
Using the same values in ath9k results in much better throughput for me.

Before this patch I had a huge amount of packet loss (sometimes up to
40%) and the max transfer speed was somewhere around 5Mbit/s. With this
patch applied I have zero packet loss and ten times the throughput.
My device uses a AR9227 which is the PCI variant of the AR9287.

[0] http://bxr.su/FreeBSD/sys/dev/ath/ath_hal/ar9002/ar9287.h

Signed-off-by: Martin Blumenstingl 
---
Patch has not changed, I am just CC'ing @linux-wireless (instead of
@ath9k-devel only).

 drivers/net/wireless/ath/ath9k/ar9002_phy.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ar9002_phy.h 
b/drivers/net/wireless/ath/ath9k/ar9002_phy.h
index 6314ae2..9d17a53 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_phy.h
+++ b/drivers/net/wireless/ath/ath9k/ar9002_phy.h
@@ -610,8 +610,8 @@
 #define AR_PHY_CCA_MIN_GOOD_VAL_9271_2GHZ  -127
 #define AR_PHY_CCA_MAX_GOOD_VAL_9271_2GHZ  -116
 
-#define AR_PHY_CCA_NOM_VAL_9287_2GHZ   -120
+#define AR_PHY_CCA_NOM_VAL_9287_2GHZ   -112
 #define AR_PHY_CCA_MIN_GOOD_VAL_9287_2GHZ-127
-#define AR_PHY_CCA_MAX_GOOD_VAL_9287_2GHZ-110
+#define AR_PHY_CCA_MAX_GOOD_VAL_9287_2GHZ-97
 
 #endif
-- 
2.4.6

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] ath9k: remove the sched field in struct ath_atx_tid

[Felix Fietkau]

Use list_empty(&tid->list) instead

Signed-off-by: Felix Fietkau 
---
 drivers/net/wireless/ath/ath9k/ath9k.h |  1 -
 drivers/net/wireless/ath/ath9k/xmit.c  | 23 ---
 2 files changed, 8 insertions(+), 16 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h 
b/drivers/net/wireless/ath/ath9k/ath9k.h
index 14e0ecc..7ef1be6 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -245,7 +245,6 @@ struct ath_atx_tid {
int baw_tail;   /* next unused tx buffer slot */
 
s8 bar_index;
-   bool sched;
bool active;
bool clear_ps_filter;
 };
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c 
b/drivers/net/wireless/ath/ath9k/xmit.c
index f7d6a85..3e3dac3 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -113,12 +113,9 @@ static void ath_tx_queue_tid(struct ath_softc *sc, struct 
ath_txq *txq,
if (!ctx)
return;
 
-   if (tid->sched)
-   return;
-
-   tid->sched = true;
list = &ctx->acq[TID_TO_WME_AC(tid->tidno)];
-   list_add_tail(&tid->list, list);
+   if (list_empty(&tid->list))
+   list_add_tail(&tid->list, list);
 }
 
 static struct ath_frame_info *get_frame_info(struct sk_buff *skb)
@@ -1541,15 +1538,14 @@ void ath_tx_aggr_sleep(struct ieee80211_sta *sta, 
struct ath_softc *sc,
 
ath_txq_lock(sc, txq);
 
-   if (!tid->sched) {
+   if (list_empty(&tid->list)) {
ath_txq_unlock(sc, txq);
continue;
}
 
buffered = ath_tid_has_buffered(tid);
 
-   tid->sched = false;
-   list_del(&tid->list);
+   list_del_init(&tid->list);
 
ath_txq_unlock(sc, txq);
 
@@ -1929,8 +1925,7 @@ void ath_txq_schedule(struct ath_softc *sc, struct 
ath_txq *txq)
break;
 
tid = list_first_entry(tid_list, struct ath_atx_tid, list);
-   list_del(&tid->list);
-   tid->sched = false;
+   list_del_init(&tid->list);
 
if (ath_tx_sched_aggr(sc, txq, tid, &stop))
sent = true;
@@ -2848,11 +2843,11 @@ void ath_tx_node_init(struct ath_softc *sc, struct 
ath_node *an)
tid->seq_start = tid->seq_next = 0;
tid->baw_size  = WME_MAX_BA;
tid->baw_head  = tid->baw_tail = 0;
-   tid->sched = false;
tid->active= false;
tid->clear_ps_filter = true;
__skb_queue_head_init(&tid->buf_q);
__skb_queue_head_init(&tid->retry_q);
+   INIT_LIST_HEAD(&tid->list);
acno = TID_TO_WME_AC(tidno);
tid->txq = sc->tx.txq_map[acno];
}
@@ -2871,10 +2866,8 @@ void ath_tx_node_cleanup(struct ath_softc *sc, struct 
ath_node *an)
 
ath_txq_lock(sc, txq);
 
-   if (tid->sched) {
-   list_del(&tid->list);
-   tid->sched = false;
-   }
+   if (!list_empty(&tid->list))
+   list_del_init(&tid->list);
 
ath_tid_drain(sc, txq, tid);
tid->active = false;
-- 
2.2.2

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] ath9k: add fast-xmit support

[Felix Fietkau]

Signed-off-by: Felix Fietkau 
---
 drivers/net/wireless/ath/ath9k/init.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/ath9k/init.c 
b/drivers/net/wireless/ath/ath9k/init.c
index eff0e53..7cf615f 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -826,6 +826,7 @@ static void ath9k_set_hw_capab(struct ath_softc *sc, struct 
ieee80211_hw *hw)
ieee80211_hw_set(hw, SIGNAL_DBM);
ieee80211_hw_set(hw, RX_INCLUDES_FCS);
ieee80211_hw_set(hw, HOST_BROADCAST_PS_BUFFERING);
+   ieee80211_hw_set(hw, SUPPORT_FAST_XMIT);
 
if (ath9k_ps_enable)
ieee80211_hw_set(hw, SUPPORTS_PS);
-- 
2.2.2

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] ath9k: remove struct ath_atx_ac

[Felix Fietkau]

struct ath_atx_ac contains a list of active TIDs belonging to one WMM AC.
This patch changes the code to track active station TIDs in the txq directly.

Signed-off-by: Felix Fietkau 
---
 drivers/net/wireless/ath/ath9k/ath9k.h |  12 +---
 drivers/net/wireless/ath/ath9k/xmit.c  | 128 ++---
 2 files changed, 41 insertions(+), 99 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h 
b/drivers/net/wireless/ath/ath9k/ath9k.h
index 45596e5..14e0ecc 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -173,14 +173,6 @@ struct ath_txq {
struct sk_buff_head complete_q;
 };
 
-struct ath_atx_ac {
-   struct ath_txq *txq;
-   struct list_head list;
-   struct list_head tid_q;
-   bool clear_ps_filter;
-   bool sched;
-};
-
 struct ath_frame_info {
struct ath_buf *bf;
u16 framelen;
@@ -243,7 +235,7 @@ struct ath_atx_tid {
struct sk_buff_head buf_q;
struct sk_buff_head retry_q;
struct ath_node *an;
-   struct ath_atx_ac *ac;
+   struct ath_txq *txq;
unsigned long tx_buf[BITS_TO_LONGS(ATH_TID_MAX_BUFS)];
u16 seq_start;
u16 seq_next;
@@ -255,6 +247,7 @@ struct ath_atx_tid {
s8 bar_index;
bool sched;
bool active;
+   bool clear_ps_filter;
 };
 
 struct ath_node {
@@ -262,7 +255,6 @@ struct ath_node {
struct ieee80211_sta *sta; /* station struct we're part of */
struct ieee80211_vif *vif; /* interface with which we're associated */
struct ath_atx_tid tid[IEEE80211_NUM_TIDS];
-   struct ath_atx_ac ac[IEEE80211_NUM_ACS];
 
u16 maxampdu;
u8 mpdudensity;
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c 
b/drivers/net/wireless/ath/ath9k/xmit.c
index b766a7f..f7d6a85 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -106,7 +106,6 @@ void ath_txq_unlock_complete(struct ath_softc *sc, struct 
ath_txq *txq)
 static void ath_tx_queue_tid(struct ath_softc *sc, struct ath_txq *txq,
 struct ath_atx_tid *tid)
 {
-   struct ath_atx_ac *ac = tid->ac;
struct list_head *list;
struct ath_vif *avp = (struct ath_vif *) tid->an->vif->drv_priv;
struct ath_chanctx *ctx = avp->chanctx;
@@ -118,15 +117,8 @@ static void ath_tx_queue_tid(struct ath_softc *sc, struct 
ath_txq *txq,
return;
 
tid->sched = true;
-   list_add_tail(&tid->list, &ac->tid_q);
-
-   if (ac->sched)
-   return;
-
-   ac->sched = true;
-
list = &ctx->acq[TID_TO_WME_AC(tid->tidno)];
-   list_add_tail(&ac->list, list);
+   list_add_tail(&tid->list, list);
 }
 
 static struct ath_frame_info *get_frame_info(struct sk_buff *skb)
@@ -208,7 +200,7 @@ static struct sk_buff *ath_tid_dequeue(struct ath_atx_tid 
*tid)
 static void
 ath_tx_tid_change_state(struct ath_softc *sc, struct ath_atx_tid *tid)
 {
-   struct ath_txq *txq = tid->ac->txq;
+   struct ath_txq *txq = tid->txq;
struct ieee80211_tx_info *tx_info;
struct sk_buff *skb, *tskb;
struct ath_buf *bf;
@@ -237,7 +229,7 @@ ath_tx_tid_change_state(struct ath_softc *sc, struct 
ath_atx_tid *tid)
 
 static void ath_tx_flush_tid(struct ath_softc *sc, struct ath_atx_tid *tid)
 {
-   struct ath_txq *txq = tid->ac->txq;
+   struct ath_txq *txq = tid->txq;
struct sk_buff *skb;
struct ath_buf *bf;
struct list_head bf_head;
@@ -644,7 +636,7 @@ static void ath_tx_complete_aggr(struct ath_softc *sc, 
struct ath_txq *txq,
ath_tx_queue_tid(sc, txq, tid);
 
if (ts->ts_status & (ATH9K_TXERR_FILT | 
ATH9K_TXERR_XRETRY))
-   tid->ac->clear_ps_filter = true;
+   tid->clear_ps_filter = true;
}
}
 
@@ -734,7 +726,7 @@ static u32 ath_lookup_rate(struct ath_softc *sc, struct 
ath_buf *bf,
struct ieee80211_tx_rate *rates;
u32 max_4ms_framelen, frmlen;
u16 aggr_limit, bt_aggr_limit, legacy = 0;
-   int q = tid->ac->txq->mac80211_qnum;
+   int q = tid->txq->mac80211_qnum;
int i;
 
skb = bf->bf_mpdu;
@@ -1471,8 +1463,8 @@ static bool ath_tx_sched_aggr(struct ath_softc *sc, 
struct ath_txq *txq,
if (list_empty(&bf_q))
return false;
 
-   if (tid->ac->clear_ps_filter || tid->an->no_ps_filter) {
-   tid->ac->clear_ps_filter = false;
+   if (tid->clear_ps_filter || tid->an->no_ps_filter) {
+   tid->clear_ps_filter = false;
tx_info->flags |= IEEE80211_TX_CTL_CLEAR_PS_FILT;
}
 
@@ -1491,7 +1483,7 @@ int ath_tx_aggr_start(struct ath_softc *sc, struct 
ieee80211_sta *sta,
 
an = (struct ath_node *)sta->drv_priv;
txtid = ATH_AN_2_TID(an, tid);
-   txq = txtid->ac->txq;
+   txq = txtid->txq;
 
ath_txq_

[PATCH 1/4] mwifiex: using right aid value for tdls action frame

[Amitkumar Karwar]

From: Xinming Hu 

Variable pos is u8 here, so memcpy is needed to store u16 aid.
At the same time, aid should be platform independent, upper layer
utility(wpa_supplicant,etc.,) parse it as le16, so keep it le16
here.

Signed-off-by: Xinming Hu 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/mwifiex/tdls.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mwifiex/tdls.c 
b/drivers/net/wireless/mwifiex/tdls.c
index aa3d3c5..b3e163d 100644
--- a/drivers/net/wireless/mwifiex/tdls.c
+++ b/drivers/net/wireless/mwifiex/tdls.c
@@ -164,7 +164,7 @@ static void mwifiex_tdls_add_aid(struct mwifiex_private 
*priv,
pos = (void *)skb_put(skb, 4);
*pos++ = WLAN_EID_AID;
*pos++ = 2;
-   *pos++ = le16_to_cpu(assoc_rsp->a_id);
+   memcpy(pos, &assoc_rsp->a_id, sizeof(assoc_rsp->a_id));
 
return;
 }
-- 
1.8.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/4] mwifiex: fix command timeout for PCIe chipsets

[Amitkumar Karwar]

From: Zhaoyang Liu 

When WLAN interface is up and running, driver unload and
load was causing command timeout error.

We enable Rx data by updating RX ring read pointer in
init_fw_port(). It should be done when FW is completely
intialialised. Command timeout is fixed in this patch by
moving init_fw_port() call to mwifiex_init_fw_complete().

Signed-off-by: Zhaoyang Liu 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/mwifiex/init.c | 5 -
 drivers/net/wireless/mwifiex/util.c | 4 
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/mwifiex/init.c 
b/drivers/net/wireless/mwifiex/init.c
index 8fa363a..7a970c2 100644
--- a/drivers/net/wireless/mwifiex/init.c
+++ b/drivers/net/wireless/mwifiex/init.c
@@ -551,11 +551,6 @@ int mwifiex_init_fw(struct mwifiex_adapter *adapter)
}
}
 
-   if (adapter->if_ops.init_fw_port) {
-   if (adapter->if_ops.init_fw_port(adapter))
-   return -1;
-   }
-
for (i = 0; i < adapter->priv_num; i++) {
if (adapter->priv[i]) {
ret = mwifiex_sta_init_cmd(adapter->priv[i], first_sta,
diff --git a/drivers/net/wireless/mwifiex/util.c 
b/drivers/net/wireless/mwifiex/util.c
index 2504e42..46f12d3 100644
--- a/drivers/net/wireless/mwifiex/util.c
+++ b/drivers/net/wireless/mwifiex/util.c
@@ -126,6 +126,10 @@ static int num_of_items = ARRAY_SIZE(items);
 int mwifiex_init_fw_complete(struct mwifiex_adapter *adapter)
 {
 
+   if (adapter->hw_status == MWIFIEX_HW_STATUS_READY)
+   if (adapter->if_ops.init_fw_port)
+   adapter->if_ops.init_fw_port(adapter);
+
adapter->init_wait_q_woken = true;
wake_up_interruptible(&adapter->init_wait_q);
return 0;
-- 
1.8.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/4] mwifiex: fix system crash observed during initialisation

[Amitkumar Karwar]

From: Zhaoyang Liu 

System crash was observed if one of the driver initialisation
commands is timed out. The reason is our timeout handler triggers
firmware dump, meanwhile driver initialisation error paths have
already freed the adapter structure.

Firmware hasn't yet completely initialized. So collecting firmware
dump is not needed in this case. Command timeout handler is
modified in this patch to fix the crash issue.

Signed-off-by: Zhaoyang Liu 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/mwifiex/cmdevt.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mwifiex/cmdevt.c 
b/drivers/net/wireless/mwifiex/cmdevt.c
index 207da40..dbfbbdf 100644
--- a/drivers/net/wireless/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/mwifiex/cmdevt.c
@@ -993,8 +993,10 @@ mwifiex_cmd_timeout_func(unsigned long function_context)
mwifiex_cancel_pending_ioctl(adapter);
}
}
-   if (adapter->hw_status == MWIFIEX_HW_STATUS_INITIALIZING)
+   if (adapter->hw_status == MWIFIEX_HW_STATUS_INITIALIZING) {
mwifiex_init_fw_complete(adapter);
+   return;
+   }
 
if (adapter->if_ops.device_dump)
adapter->if_ops.device_dump(adapter);
-- 
1.8.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/4] mwifiex: corrections in PCIe event skb handling

[Amitkumar Karwar]

Preallocated event SKBs are getting reused for PCIe chipset.
Their physical addresses are shared with firmware so that
firmware can write data into them.

This patch makes sure that SKB is cleared and length is set to
default while submitting it to firmware.

Signed-off-by: Amitkumar Karwar 
Signed-off-by: Zhaoyang Liu 
---
 drivers/net/wireless/mwifiex/pcie.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/mwifiex/pcie.c 
b/drivers/net/wireless/mwifiex/pcie.c
index 77b9055..33c75d7 100644
--- a/drivers/net/wireless/mwifiex/pcie.c
+++ b/drivers/net/wireless/mwifiex/pcie.c
@@ -1807,6 +1807,8 @@ static int mwifiex_pcie_event_complete(struct 
mwifiex_adapter *adapter,
 
if (!card->evt_buf_list[rdptr]) {
skb_push(skb, INTF_HEADER_LEN);
+   skb_put(skb, MAX_EVENT_SIZE - skb->len);
+   memset(skb->data, 0, MAX_EVENT_SIZE);
if (mwifiex_map_pci_memory(adapter, skb,
   MAX_EVENT_SIZE,
   PCI_DMA_FROMDEVICE))
-- 
1.8.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] wireless-regdb: Update regulatory rules for Taiwan (TW)

[Chen-Yu Tsai]

On Wed, Jul 22, 2015 at 3:56 PM, Chen-Yu Tsai  wrote:
> On Wed, Jul 22, 2015 at 3:40 PM, Chen-Yu Tsai  wrote:
>> On Thu, Jul 9, 2015 at 11:15 PM, Seth Forshee
>>  wrote:
>>> On Wed, Jul 08, 2015 at 11:07:20AM +0800, Chen-Yu Tsai wrote:
 > Thanks. I think there should be a written document about what the
 > rules should be like, or what is expected:
 >
 >   1. WiFi channel boundaries or band boundaries
 >   2. peak output power or peak power spectral density
 >
 > In 
 > http://lists.infradead.org/pipermail/wireless-regdb/2015-July/000856.html
 > you mentioned the software is smart enough to work out how to combine
 > different bands and what channels to use, so I see no reason to 
 > explicitly
 > chop up contiguous spectrum, unless there are explicit rules forbidding
 > combined use of bands with different regulatory rules. AFAIK the FCC
 > only requires one to satisfy all rules when usage crosses band 
 > boundaries.
 >
 > http://lists.infradead.org/pipermail/wireless-regdb/2015-July/000857.html
 > also raises a similar question.
>>>
>>> I was really commenting about the transmit power updates in your patch.
>>> I just compared the frequency changes to the documentation you linked to
>>> and those do look okay to me.
>>
>> I see.
>>
 >> I would however consider an update for 5.15-5.25 GHz and 5.6-5.65 GHz
 >> provided that there's official documentation to substantiate the change.
 >> I unfortunately cannot read Chinese, so I would need some assistance to
 >> confirm the documentation.
 >
 > I could possibly ask around, though I'm not optimistic. The "official"
 > documents are just transcripts from NCC hosted Q&A sessions regarding
 > the latest regulations. Proposals/questions are submitted by vendors,
 > and the NCC responds and puts together an aggregated transcript.

 Just got off the phone with the NCC. Their position is, spectrum allocation
 is not within their purview, but the Ministry of Transportation and
 Communications. As noted in the patch, they have already opened up the
 spectrum to U-NII and low power radio usage. What remains is that the
 NCC revise its testing standards. Until then, their position is that,
 since their testing standards are modeled after FCC standards, vendors
 can just test under FCC standards, then convert the reports into LP0002
 format, and cite the FCC test report.

 There is no formal English version of the Q&A transcript, at least not
 until some foreign testing body requests it. The person in charge just
 asked me to translate it myself...
>>>
>>> If you send a patch which updates only the frequencies I would likely
>>> apply that after allowing a week or so for others to either ack or nack
>>> it (and running the stuff you linked to through google translate and
>>> seeing if I could make any sense of the output).
>>
>> Got it.
>>
>>> I think the power updates are probably based on a misunderstanding, and
>>> may not even be completely correct. For the most part after they've been
>>> converted to EIRP (eirp = 10 * log10(mW)) they don't turn out to be
>>> substantially different than what we have now. I think the value in
>>> 5250-5350 MHz is probably incorrect however. Based on my quick skim of
>>> the document you linked to it should be 50 mW rather than 250. 50 mW
>>> also roughly matches to the 17 dBm which is in the database today,
>>> whereas 250 mW is closer to 24 dBm.
>>
>> Yes. About the first part, it seems dbparse.py converts values in mW
>> into EIRP anyway. However I don't think EIRT equals "peak power spectral
>> density".
>
> Sorry, this part applies to the US rules, not part of this patch.

I just realized that what I misunderstood as PSD was the fact that no one
had updated the power limits of U-NII-1 for the US. I've added such a patch
to my series.

Sorry for the noise.

>> About the second part, yes the current values match the ones in LP0002.
>> However as I stated, the regulatory body has explicitly allowed certifying
>> under the latest FCC rules, which effectively raises the limits from
>> 50 mW to 250 mW.
>>
>>> My suggestion would be update the frequencies but not the existing
>>> transmit power limits, unless you discover that any of the power limits
>>> are definitely incorrect.
>>
>> I'll split up the patch into 3:
>>
>>   1. Add the new 5150 - 5250 frequency band, using current LP0002
>>  limits if any, otherwise FCC limits.
>>
>>   2. Tweak frequency boundaries for the remaining bands to make
>>  them contiguous and properly reflect the regulations rather
>>  than the WiFi channel frequencies.
>>
>>   3. Update power limits and DFS requirements to latest FCC standards.
>>
>> Each patch will then explain why and how the regulations changed
>> along with references, in English if available.
>>
>> You can then decide on whether to merge all three or just the first

Re: ath9k_htc: virtual interfaces, AP connection drop & kernel warning

[Rolf Anderegg]

On 16/07/15 13:54, Oleksij Rempel wrote:
> Am 13.07.2015 um 13:52 schrieb Rolf Anderegg:
>>
>> I suspect that there are bandwidth/speed issues when dealing with USB
>> adapters, but that does not inherently mean that the connection is prone
>> to drop, right? Doesn't that mean that I am leaking packages somewhere
>> along the way? What else could I be looking for?
> 
> The packages can drop if you will do channel scan. STA mode need some
> seconds to complete channel scan. It means AP will be all the time
> unavailable.

Ok, that may be. Then again why am I not experiencing the same
connection drop on my ath5k setup? Because the channel scan is more
likely to be completed in due time?

Regards,
Rolf Anderegg
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath9k_htc: virtual interfaces, AP connection drop & kernel warning

[Oleksij Rempel]

Am 22.07.2015 um 18:37 schrieb Rolf Anderegg:
> 
> On 16/07/15 13:54, Oleksij Rempel wrote:
>> Am 13.07.2015 um 13:52 schrieb Rolf Anderegg:
>>>
>>> I suspect that there are bandwidth/speed issues when dealing with USB
>>> adapters, but that does not inherently mean that the connection is prone
>>> to drop, right? Doesn't that mean that I am leaking packages somewhere
>>> along the way? What else could I be looking for?
>>
>> The packages can drop if you will do channel scan. STA mode need some
>> seconds to complete channel scan. It means AP will be all the time
>> unavailable.
> 
> Ok, that may be. Then again why am I not experiencing the same
> connection drop on my ath5k setup? Because the channel scan is more
> likely to be completed in due time?

Yes, channel scantime on usb device is match longer then on pci.

-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] iwlwifi:Fix error handling in the function iwl_pcie_enqueue_hcmd

[Grumbach, Emmanuel]

On 07/22/2015 07:39 PM, Nicholas Krause wrote:
> This fixes error handling in the function iwl_pcie_enqueue_hcmd
> by checking if all calls to the function wl_pcie_txq_build_tfd
> have failed by returning a error code and if so jump to the goto
> label out from the cleaning up of acquired resources before

What tests did you run on your patch?

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linuxwifi] [PATCH] iwlwifi:Fix error handling in the function iwl_pcie_enqueue_hcmd

[Grumbach, Emmanuel]

On 07/22/2015 08:30 PM, nick wrote:
> 
> 
> On 2015-07-22 01:28 PM, Grumbach, Emmanuel wrote:
>>
>>
>> On 07/22/2015 07:39 PM, Nicholas Krause wrote:
>>> This fixes error handling in the function iwl_pcie_enqueue_hcmd
>>> by checking if all calls to the function wl_pcie_txq_build_tfd
>>> have failed by returning a error code and if so jump to the goto
>>> label out from the cleaning up of acquired resources before
>>
>> What tests did you run on your patch?
>>
> None did I miss something?

I can't really accept a patch if you don't even test it, right?
Your patch doesn't look problematic at first glance, but hitting
these paths isn't easy and I am not very happy to change the behavior
without direct testing.

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] staging: rtl8723au: fix incorrect type in assignment warning

[Steve Pennington]

Repaced calls to htons and memcpy with a single call to put_unaligned_be16
to fix the following sparse warning:
drivers/staging/rtl8723au/core/rtw_recv.c:1557:21: warning: incorrect type in 
assignment (different base types)
drivers/staging/rtl8723au/core/rtw_recv.c:1557:21:expected unsigned short 
[unsigned] [assigned] [usertype] len
drivers/staging/rtl8723au/core/rtw_recv.c:1557:21:got restricted __be16 
[usertype] 

Signed-off-by: Steve Pennington 
---
 drivers/staging/rtl8723au/core/rtw_recv.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_recv.c 
b/drivers/staging/rtl8723au/core/rtw_recv.c
index 274a4b6..ad0549c 100644
--- a/drivers/staging/rtl8723au/core/rtw_recv.c
+++ b/drivers/staging/rtl8723au/core/rtw_recv.c
@@ -1554,8 +1554,7 @@ static int wlanhdr_to_ethhdr (struct recv_frame 
*precvframe)
ether_addr_copy(ptr + ETH_ALEN, pattrib->src);
 
if (!bsnaphdr) {
-   len = htons(len);
-   memcpy(ptr + 12, &len, 2);
+   put_unaligned_be16(len, ptr + 12);
}
 
 
-- 
2.4.6

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] staging: rtl8723au: fix incorrect type in assignment warning

[Jes Sorensen]

Steve Pennington  writes:
> Repaced calls to htons and memcpy with a single call to put_unaligned_be16

You may want an 'l' in replaced, but not a biggie to me.

> to fix the following sparse warning:
> drivers/staging/rtl8723au/core/rtw_recv.c:1557:21: warning: incorrect type in 
> assignment (different base types)
> drivers/staging/rtl8723au/core/rtw_recv.c:1557:21:expected unsigned short 
> [unsigned] [assigned] [usertype] len
> drivers/staging/rtl8723au/core/rtw_recv.c:1557:21:got restricted __be16 
> [usertype] 
>
> Signed-off-by: Steve Pennington 
> ---
>  drivers/staging/rtl8723au/core/rtw_recv.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/staging/rtl8723au/core/rtw_recv.c 
> b/drivers/staging/rtl8723au/core/rtw_recv.c
> index 274a4b6..ad0549c 100644
> --- a/drivers/staging/rtl8723au/core/rtw_recv.c
> +++ b/drivers/staging/rtl8723au/core/rtw_recv.c
> @@ -1554,8 +1554,7 @@ static int wlanhdr_to_ethhdr (struct recv_frame 
> *precvframe)
>   ether_addr_copy(ptr + ETH_ALEN, pattrib->src);
>  
>   if (!bsnaphdr) {
> - len = htons(len);
> - memcpy(ptr + 12, &len, 2);
> + put_unaligned_be16(len, ptr + 12);
>   }

This one looks good to me.

Jes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 01/15] staging: vt6655: Remove ununsed macro ASSERT

[Malcolm Priestley]

VIAWET_DEBUG is not defined so macro is empty.

Remove the macro.

Signed-off-by: Malcolm Priestley 
---
 drivers/staging/vt6655/baseband.c| 4 +---
 drivers/staging/vt6655/card.c| 1 -
 drivers/staging/vt6655/device_cfg.h  | 9 -
 drivers/staging/vt6655/device_main.c | 9 -
 drivers/staging/vt6655/mac.c | 1 -
 drivers/staging/vt6655/rxtx.c| 1 -
 6 files changed, 5 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/vt6655/baseband.c 
b/drivers/staging/vt6655/baseband.c
index b0ea38f..befaa42 100644
--- a/drivers/staging/vt6655/baseband.c
+++ b/drivers/staging/vt6655/baseband.c
@@ -1728,10 +1728,8 @@ BBuGetFrameTime(
unsigned int uRateIdx = (unsigned int) wRate;
unsigned int uRate = 0;
 
-   if (uRateIdx > RATE_54M) {
-   ASSERT(0);
+   if (uRateIdx > RATE_54M)
return 0;
-   }
 
uRate = (unsigned int)awcFrameTime[uRateIdx];
 
diff --git a/drivers/staging/vt6655/card.c b/drivers/staging/vt6655/card.c
index e00c060..df62bdc 100644
--- a/drivers/staging/vt6655/card.c
+++ b/drivers/staging/vt6655/card.c
@@ -847,7 +847,6 @@ void CARDvSetLoopbackMode(struct vnt_private *priv, 
unsigned short wLoopbackMode
case CARD_LB_PHY:
break;
default:
-   ASSERT(false);
break;
}
/* set MAC loopback */
diff --git a/drivers/staging/vt6655/device_cfg.h 
b/drivers/staging/vt6655/device_cfg.h
index a4a8a84..c7f21716 100644
--- a/drivers/staging/vt6655/device_cfg.h
+++ b/drivers/staging/vt6655/device_cfg.h
@@ -70,17 +70,8 @@ typedef enum  _chip_type {
 } CHIP_TYPE, *PCHIP_TYPE;
 
 #ifdef VIAWET_DEBUG
-#define ASSERT(x)  \
-do {   \
-   if (!(x)) { \
-   pr_err("assertion %s failed: file %s line %d\n", \
-  #x, __func__, __LINE__); \
-   *(int *)0 = 0;  \
-   }   \
-} while (0)
 #define DBG_PORT80(value)   outb(value, 0x80)
 #else
-#define ASSERT(x)
 #define DBG_PORT80(value)
 #endif
 
diff --git a/drivers/staging/vt6655/device_main.c 
b/drivers/staging/vt6655/device_main.c
index 23ad16e..053291a 100644
--- a/drivers/staging/vt6655/device_main.c
+++ b/drivers/staging/vt6655/device_main.c
@@ -623,7 +623,7 @@ static void device_init_rd0_ring(struct vnt_private 
*pDevice)
for (i = 0; i < pDevice->sOpts.nRxDescs0; i ++, curr += 
sizeof(SRxDesc)) {
pDesc = &(pDevice->aRD0Ring[i]);
pDesc->pRDInfo = alloc_rd_info();
-   ASSERT(pDesc->pRDInfo);
+
if (!device_alloc_rx_buf(pDevice, pDesc))
dev_err(&pDevice->pcid->dev, "can not alloc rx bufs\n");
 
@@ -647,7 +647,7 @@ static void device_init_rd1_ring(struct vnt_private 
*pDevice)
for (i = 0; i < pDevice->sOpts.nRxDescs1; i ++, curr += 
sizeof(SRxDesc)) {
pDesc = &(pDevice->aRD1Ring[i]);
pDesc->pRDInfo = alloc_rd_info();
-   ASSERT(pDesc->pRDInfo);
+
if (!device_alloc_rx_buf(pDevice, pDesc))
dev_err(&pDevice->pcid->dev, "can not alloc rx bufs\n");
 
@@ -705,7 +705,7 @@ static void device_init_td0_ring(struct vnt_private 
*pDevice)
for (i = 0; i < pDevice->sOpts.nTxDescs[0]; i++, curr += 
sizeof(STxDesc)) {
pDesc = &(pDevice->apTD0Rings[i]);
pDesc->pTDInfo = alloc_td_info();
-   ASSERT(pDesc->pTDInfo);
+
if (pDevice->flags & DEVICE_FLAGS_TX_ALIGN) {
pDesc->pTDInfo->buf = pDevice->tx0_bufs + 
(i)*PKT_BUF_SZ;
pDesc->pTDInfo->buf_dma = pDevice->tx_bufs_dma0 + 
(i)*PKT_BUF_SZ;
@@ -731,7 +731,7 @@ static void device_init_td1_ring(struct vnt_private 
*pDevice)
for (i = 0; i < pDevice->sOpts.nTxDescs[1]; i++, curr += 
sizeof(STxDesc)) {
pDesc = &(pDevice->apTD1Rings[i]);
pDesc->pTDInfo = alloc_td_info();
-   ASSERT(pDesc->pTDInfo);
+
if (pDevice->flags & DEVICE_FLAGS_TX_ALIGN) {
pDesc->pTDInfo->buf = pDevice->tx1_bufs + (i) * 
PKT_BUF_SZ;
pDesc->pTDInfo->buf_dma = pDevice->tx_bufs_dma1 + (i) * 
PKT_BUF_SZ;
@@ -818,7 +818,6 @@ static bool device_alloc_rx_buf(struct vnt_private 
*pDevice, PSRxDesc pRD)
pRDInfo->skb = dev_alloc_skb((int)pDevice->rx_buf_sz);
if (pRDInfo->skb == NULL)
return false;
-   ASSERT(pRDInfo->skb);
 
pRDInfo->skb_dma =
dma_map_single(&pDevice->pcid->dev,
diff --git a/drivers/staging/vt6655/mac.c b/drivers/staging/vt6655/mac.c
index aed530f..65dd49c 100644
--- a/drivers/stagin

[PATCH 02/15] staging: vt6655: remove unused DBG_PORT80 and VIAWET_DEBUG

[Malcolm Priestley]

VIAWET_DEBUG is never defined so DBG_PORT80 is empty and never used.

Remove both macros.

Signed-off-by: Malcolm Priestley 
---
 drivers/staging/vt6655/baseband.c   |  2 --
 drivers/staging/vt6655/device_cfg.h |  6 --
 drivers/staging/vt6655/mac.c| 17 -
 3 files changed, 25 deletions(-)

diff --git a/drivers/staging/vt6655/baseband.c 
b/drivers/staging/vt6655/baseband.c
index befaa42..9e61f2d 100644
--- a/drivers/staging/vt6655/baseband.c
+++ b/drivers/staging/vt6655/baseband.c
@@ -1943,7 +1943,6 @@ bool BBbReadEmbedded(struct vnt_private *priv,
VNSvInPortB(dwIoBase + MAC_REG_BBREGDATA, pbyData);
 
if (ww == W_MAX_TIMEOUT) {
-   DBG_PORT80(0x30);
pr_debug(" DBG_PORT80(0x30)\n");
return false;
}
@@ -1986,7 +1985,6 @@ bool BBbWriteEmbedded(struct vnt_private *priv,
}
 
if (ww == W_MAX_TIMEOUT) {
-   DBG_PORT80(0x31);
pr_debug(" DBG_PORT80(0x31)\n");
return false;
}
diff --git a/drivers/staging/vt6655/device_cfg.h 
b/drivers/staging/vt6655/device_cfg.h
index c7f21716..b4c9547 100644
--- a/drivers/staging/vt6655/device_cfg.h
+++ b/drivers/staging/vt6655/device_cfg.h
@@ -69,10 +69,4 @@ typedef enum  _chip_type {
VT3253 = 1
 } CHIP_TYPE, *PCHIP_TYPE;
 
-#ifdef VIAWET_DEBUG
-#define DBG_PORT80(value)   outb(value, 0x80)
-#else
-#define DBG_PORT80(value)
-#endif
-
 #endif
diff --git a/drivers/staging/vt6655/mac.c b/drivers/staging/vt6655/mac.c
index 65dd49c..3dfd333 100644
--- a/drivers/staging/vt6655/mac.c
+++ b/drivers/staging/vt6655/mac.c
@@ -373,7 +373,6 @@ bool MACbSafeRxOff(void __iomem *dwIoBase)
break;
}
if (ww == W_MAX_TIMEOUT) {
-   DBG_PORT80(0x10);
pr_debug(" DBG_PORT80(0x10)\n");
return false;
}
@@ -383,7 +382,6 @@ bool MACbSafeRxOff(void __iomem *dwIoBase)
break;
}
if (ww == W_MAX_TIMEOUT) {
-   DBG_PORT80(0x11);
pr_debug(" DBG_PORT80(0x11)\n");
return false;
}
@@ -397,7 +395,6 @@ bool MACbSafeRxOff(void __iomem *dwIoBase)
break;
}
if (ww == W_MAX_TIMEOUT) {
-   DBG_PORT80(0x12);
pr_debug(" DBG_PORT80(0x12)\n");
return false;
}
@@ -435,7 +432,6 @@ bool MACbSafeTxOff(void __iomem *dwIoBase)
break;
}
if (ww == W_MAX_TIMEOUT) {
-   DBG_PORT80(0x20);
pr_debug(" DBG_PORT80(0x20)\n");
return false;
}
@@ -445,7 +441,6 @@ bool MACbSafeTxOff(void __iomem *dwIoBase)
break;
}
if (ww == W_MAX_TIMEOUT) {
-   DBG_PORT80(0x21);
pr_debug(" DBG_PORT80(0x21)\n");
return false;
}
@@ -460,7 +455,6 @@ bool MACbSafeTxOff(void __iomem *dwIoBase)
break;
}
if (ww == W_MAX_TIMEOUT) {
-   DBG_PORT80(0x24);
pr_debug(" DBG_PORT80(0x24)\n");
return false;
}
@@ -485,13 +479,11 @@ bool MACbSafeStop(void __iomem *dwIoBase)
MACvRegBitsOff(dwIoBase, MAC_REG_TCR, TCR_AUTOBCNTX);
 
if (!MACbSafeRxOff(dwIoBase)) {
-   DBG_PORT80(0xA1);
pr_debug(" MACbSafeRxOff == false)\n");
MACbSafeSoftwareReset(dwIoBase);
return false;
}
if (!MACbSafeTxOff(dwIoBase)) {
-   DBG_PORT80(0xA2);
pr_debug(" MACbSafeTxOff == false)\n");
MACbSafeSoftwareReset(dwIoBase);
return false;
@@ -589,9 +581,6 @@ void MACvSetCurrRx0DescAddr(void __iomem *dwIoBase, 
unsigned long dwCurrDescAddr
break;
}
 
-   if (ww == W_MAX_TIMEOUT)
-   DBG_PORT80(0x13);
-
VNSvOutPortD(dwIoBase + MAC_REG_RXDMAPTR0, dwCurrDescAddr);
if (byOrgDMACtl & DMACTL_RUN)
VNSvOutPortB(dwIoBase + MAC_REG_RXDMACTL0, DMACTL_RUN);
@@ -626,8 +615,6 @@ void MACvSetCurrRx1DescAddr(void __iomem *dwIoBase, 
unsigned long dwCurrDescAddr
if (!(byData & DMACTL_RUN))
break;
}
-   if (ww == W_MAX_TIMEOUT)
-   DBG_PORT80(0x14);
 
VNSvOutPortD(dwIoBase + MAC_REG_RXDMAPTR1, dwCurrDescAddr);
if (byOrgDMACtl & DMACTL_RUN)
@@ -665,8 +652,6 @@ void MACvSetCurrTx0DescAddrEx(void __iomem *dwIoBase,
if (!(byData & DMACTL_RUN))
break;
}
-   if (ww == W_MAX_TIMEOUT)
-   DBG_PORT80(0x25);
 
VNSvOutPortD(dwIoBase + MAC_REG_TXDMAPTR0, dwCurrDescAddr);
if (byOrgDMACtl & DMACTL_RUN)
@@ -705,7 +690,6 @@ void MACvSetCurrAC0DescAddrEx(void __iomem *dwIoBase,
break;
}
if (ww == W_M

[PATCH 05/15] staging: vt6655: Remove unused tagDEVICE_TD_INFO curr_desc

[Malcolm Priestley]

The variable is assigned a value that is never used.

Signed-off-by: Malcolm Priestley 
---
 drivers/staging/vt6655/desc.h| 1 -
 drivers/staging/vt6655/device_main.c | 2 --
 2 files changed, 3 deletions(-)

diff --git a/drivers/staging/vt6655/desc.h b/drivers/staging/vt6655/desc.h
index d568101..485c6fd 100644
--- a/drivers/staging/vt6655/desc.h
+++ b/drivers/staging/vt6655/desc.h
@@ -257,7 +257,6 @@ typedef struct tagDEVICE_TD_INFO {
struct sk_buff *skb;
unsigned char *buf;
dma_addr_t  buf_dma;
-   dma_addr_t  curr_desc;
unsigned long dwReqCount;
unsigned long dwHeaderLength;
unsigned char byFlags;
diff --git a/drivers/staging/vt6655/device_main.c 
b/drivers/staging/vt6655/device_main.c
index 89611a7..7409ed2 100644
--- a/drivers/staging/vt6655/device_main.c
+++ b/drivers/staging/vt6655/device_main.c
@@ -711,7 +711,6 @@ static void device_init_td0_ring(struct vnt_private 
*pDevice)
pDesc->pTDInfo->buf_dma = pDevice->tx_bufs_dma0 + 
(i)*PKT_BUF_SZ;
}
pDesc->next = &(pDevice->apTD0Rings[(i+1) % 
pDevice->sOpts.nTxDescs[0]]);
-   pDesc->pTDInfo->curr_desc = cpu_to_le32(curr);
pDesc->next_desc = cpu_to_le32(curr+sizeof(STxDesc));
}
 
@@ -737,7 +736,6 @@ static void device_init_td1_ring(struct vnt_private 
*pDevice)
pDesc->pTDInfo->buf_dma = pDevice->tx_bufs_dma1 + (i) * 
PKT_BUF_SZ;
}
pDesc->next = &(pDevice->apTD1Rings[(i + 1) % 
pDevice->sOpts.nTxDescs[1]]);
-   pDesc->pTDInfo->curr_desc = cpu_to_le32(curr);
pDesc->next_desc = cpu_to_le32(curr+sizeof(STxDesc));
}
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 13/15] staging: vt6655: always set 32 bit dma mask

[Malcolm Priestley]

The device is limited to 32 bit address space.

Signed-off-by: Malcolm Priestley 
---
 drivers/staging/vt6655/device_main.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/staging/vt6655/device_main.c 
b/drivers/staging/vt6655/device_main.c
index c82bf48..c97353b 100644
--- a/drivers/staging/vt6655/device_main.c
+++ b/drivers/staging/vt6655/device_main.c
@@ -1747,6 +1747,12 @@ vt6655_probe(struct pci_dev *pcid, const struct 
pci_device_id *ent)
return -ENODEV;
}
 
+   if (dma_set_mask(&pcid->dev, DMA_BIT_MASK(32))) {
+   dev_err(&pcid->dev, ": Failed to set dma 32 bit mask\n");
+   device_free_info(priv);
+   return -ENODEV;
+   }
+
INIT_WORK(&priv->interrupt_work, vnt_interrupt_work);
 
/* do reset */
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 08/15] staging: vt6655: remove unused tagDEVICE_RD_INFO -> curr_desc

[Malcolm Priestley]

variable is assigned a value that is never used.

Signed-off-by: Malcolm Priestley 
---
 drivers/staging/vt6655/desc.h| 1 -
 drivers/staging/vt6655/device_main.c | 2 --
 2 files changed, 3 deletions(-)

diff --git a/drivers/staging/vt6655/desc.h b/drivers/staging/vt6655/desc.h
index 26cd3e1..3302d0182 100644
--- a/drivers/staging/vt6655/desc.h
+++ b/drivers/staging/vt6655/desc.h
@@ -170,7 +170,6 @@
 typedef struct tagDEVICE_RD_INFO {
struct sk_buff *skb;
dma_addr_t  skb_dma;
-   dma_addr_t  curr_desc;
 } DEVICE_RD_INFO,   *PDEVICE_RD_INFO;
 
 #ifdef __BIG_ENDIAN
diff --git a/drivers/staging/vt6655/device_main.c 
b/drivers/staging/vt6655/device_main.c
index 7409ed2..c82bf48 100644
--- a/drivers/staging/vt6655/device_main.c
+++ b/drivers/staging/vt6655/device_main.c
@@ -628,7 +628,6 @@ static void device_init_rd0_ring(struct vnt_private 
*pDevice)
dev_err(&pDevice->pcid->dev, "can not alloc rx bufs\n");
 
pDesc->next = &(pDevice->aRD0Ring[(i+1) % 
pDevice->sOpts.nRxDescs0]);
-   pDesc->pRDInfo->curr_desc = cpu_to_le32(curr);
pDesc->next_desc = cpu_to_le32(curr + sizeof(SRxDesc));
}
 
@@ -652,7 +651,6 @@ static void device_init_rd1_ring(struct vnt_private 
*pDevice)
dev_err(&pDevice->pcid->dev, "can not alloc rx bufs\n");
 
pDesc->next = &(pDevice->aRD1Ring[(i+1) % 
pDevice->sOpts.nRxDescs1]);
-   pDesc->pRDInfo->curr_desc = cpu_to_le32(curr);
pDesc->next_desc = cpu_to_le32(curr + sizeof(SRxDesc));
}
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 14/15] staging: vt6655: s_cbFillTxBufHead replace STxBufHead

[Malcolm Priestley]

vnt_tx_fifo_head has now replaced STxBufHead

Signed-off-by: Malcolm Priestley 
---
 drivers/staging/vt6655/rxtx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vt6655/rxtx.c b/drivers/staging/vt6655/rxtx.c
index 82380f3..380b879 100644
--- a/drivers/staging/vt6655/rxtx.c
+++ b/drivers/staging/vt6655/rxtx.c
@@ -1088,7 +1088,7 @@ s_cbFillTxBufHead(struct vnt_private *pDevice, unsigned 
char byPktType,
 
 
/* Set RrvTime/RTS/CTS Buffer */
-   wTxBufSize = sizeof(STxBufHead);
+   wTxBufSize = sizeof(struct vnt_tx_fifo_head);
if (byPktType == PK_TYPE_11GB || byPktType == PK_TYPE_11GA) {/* 802.11g 
packet */
 
if (byFBOption == AUTO_FB_NONE) {
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 06/15] staging: vt6655: fix tagDEVICE_TD_INFO -> buff_addr type

[Malcolm Priestley]

Should always be __le32 type

Signed-off-by: Malcolm Priestley 
---
 drivers/staging/vt6655/desc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vt6655/desc.h b/drivers/staging/vt6655/desc.h
index 485c6fd..8dc53bd 100644
--- a/drivers/staging/vt6655/desc.h
+++ b/drivers/staging/vt6655/desc.h
@@ -266,7 +266,7 @@ typedef struct tagDEVICE_TD_INFO {
 typedef struct tagSTxDesc {
volatileSTDES0  m_td0TD0;
volatileSTDES1  m_td1TD1;
-   volatileu32buff_addr;
+   volatile__le32  buff_addr;
volatileu32next_desc;
struct tagSTxDesc *next __aligned(8);
volatilePDEVICE_TD_INFO pTDInfo __aligned(8);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 10/15] staging: vt6655: fix tagSRxDesc -> next_desc type

[Malcolm Priestley]

Should always be __le32

Signed-off-by: Malcolm Priestley 
---
 drivers/staging/vt6655/desc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vt6655/desc.h b/drivers/staging/vt6655/desc.h
index 42e005a..251f7bc 100644
--- a/drivers/staging/vt6655/desc.h
+++ b/drivers/staging/vt6655/desc.h
@@ -209,7 +209,7 @@ typedef struct tagSRxDesc {
volatile SRDES0 m_rd0RD0;
volatile SRDES1 m_rd1RD1;
volatile __le32 buff_addr;
-   volatile u32next_desc;
+   volatile __le32 next_desc;
struct tagSRxDesc *next __aligned(8);
volatile PDEVICE_RD_INFO pRDInfo __aligned(8);
 } __attribute__ ((__packed__))
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 12/15] staging: vt6655: fix tagTDES1 -> wReqCount type

[Malcolm Priestley]

should be __le16

Signed-off-by: Malcolm Priestley 
---
 drivers/staging/vt6655/desc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vt6655/desc.h b/drivers/staging/vt6655/desc.h
index f6563d3..2374fa5 100644
--- a/drivers/staging/vt6655/desc.h
+++ b/drivers/staging/vt6655/desc.h
@@ -245,7 +245,7 @@ STDES0;
 #endif
 
 typedef struct tagTDES1 {
-   volatileunsigned short wReqCount;
+   volatile__le16wReqCount;
volatileunsigned char byTCR;
volatileunsigned char byReserved;
 } __attribute__ ((__packed__))
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 11/15] staging: vt6655: Fix wReqCount to __le16

[Malcolm Priestley]

Should be __le16 and do and correct endian conversion.

Signed-off-by: Malcolm Priestley 
---
 drivers/staging/vt6655/card.c | 8 
 drivers/staging/vt6655/desc.h | 6 +++---
 drivers/staging/vt6655/dpc.c  | 2 +-
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/vt6655/card.c b/drivers/staging/vt6655/card.c
index df62bdc..ae8fd7f 100644
--- a/drivers/staging/vt6655/card.c
+++ b/drivers/staging/vt6655/card.c
@@ -573,17 +573,17 @@ CARDvSafeResetRx(
/* init state, all RD is chip's */
for (uu = 0; uu < pDevice->sOpts.nRxDescs0; uu++) {
pDesc = &(pDevice->aRD0Ring[uu]);
-   pDesc->m_rd0RD0.wResCount = (unsigned 
short)(pDevice->rx_buf_sz);
+   pDesc->m_rd0RD0.wResCount = cpu_to_le16(pDevice->rx_buf_sz);
pDesc->m_rd0RD0.f1Owner = OWNED_BY_NIC;
-   pDesc->m_rd1RD1.wReqCount = (unsigned 
short)(pDevice->rx_buf_sz);
+   pDesc->m_rd1RD1.wReqCount = cpu_to_le16(pDevice->rx_buf_sz);
}
 
/* init state, all RD is chip's */
for (uu = 0; uu < pDevice->sOpts.nRxDescs1; uu++) {
pDesc = &(pDevice->aRD1Ring[uu]);
-   pDesc->m_rd0RD0.wResCount = (unsigned 
short)(pDevice->rx_buf_sz);
+   pDesc->m_rd0RD0.wResCount = cpu_to_le16(pDevice->rx_buf_sz);
pDesc->m_rd0RD0.f1Owner = OWNED_BY_NIC;
-   pDesc->m_rd1RD1.wReqCount = (unsigned 
short)(pDevice->rx_buf_sz);
+   pDesc->m_rd1RD1.wReqCount = cpu_to_le16(pDevice->rx_buf_sz);
}
 
/* set perPkt mode */
diff --git a/drivers/staging/vt6655/desc.h b/drivers/staging/vt6655/desc.h
index 251f7bc..f6563d3 100644
--- a/drivers/staging/vt6655/desc.h
+++ b/drivers/staging/vt6655/desc.h
@@ -175,7 +175,7 @@ typedef struct tagDEVICE_RD_INFO {
 #ifdef __BIG_ENDIAN
 
 typedef struct tagRDES0 {
-   volatile unsigned short wResCount;
+   volatile __le16 wResCount;
union {
volatile u16f15Reserved;
struct {
@@ -190,7 +190,7 @@ SRDES0, *PSRDES0;
 #else
 
 typedef struct tagRDES0 {
-   unsigned short wResCount;
+   __le16 wResCount;
unsigned short f15Reserved:15;
unsigned short f1Owner:1;
 } __attribute__ ((__packed__))
@@ -199,7 +199,7 @@ SRDES0;
 #endif
 
 typedef struct tagRDES1 {
-   unsigned short wReqCount;
+   __le16 wReqCount;
unsigned short wReserved;
 } __attribute__ ((__packed__))
 SRDES1;
diff --git a/drivers/staging/vt6655/dpc.c b/drivers/staging/vt6655/dpc.c
index b25ee96..e14eed1 100644
--- a/drivers/staging/vt6655/dpc.c
+++ b/drivers/staging/vt6655/dpc.c
@@ -144,7 +144,7 @@ bool vnt_receive_frame(struct vnt_private *priv, PSRxDesc 
curr_rd)
 priv->rx_buf_sz, DMA_FROM_DEVICE);
 
frame_size = le16_to_cpu(curr_rd->m_rd1RD1.wReqCount)
-   - cpu_to_le16(curr_rd->m_rd0RD0.wResCount);
+   - le16_to_cpu(curr_rd->m_rd0RD0.wResCount);
 
if ((frame_size > 2364) || (frame_size < 33)) {
/* Frame Size error drop this packet.*/
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 09/15] staging: vt6655: Fix tagSRxDesc -> buff_addr type

[Malcolm Priestley]

Should always be __le32.

Signed-off-by: Malcolm Priestley 
---
 drivers/staging/vt6655/desc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vt6655/desc.h b/drivers/staging/vt6655/desc.h
index 3302d0182..42e005a 100644
--- a/drivers/staging/vt6655/desc.h
+++ b/drivers/staging/vt6655/desc.h
@@ -208,7 +208,7 @@ SRDES1;
 typedef struct tagSRxDesc {
volatile SRDES0 m_rd0RD0;
volatile SRDES1 m_rd1RD1;
-   volatile u32buff_addr;
+   volatile __le32 buff_addr;
volatile u32next_desc;
struct tagSRxDesc *next __aligned(8);
volatile PDEVICE_RD_INFO pRDInfo __aligned(8);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 15/15] staging: vt6655: desc.h remove dead strctures

[Malcolm Priestley]

Remove these unsed structures.
typedef struct tagSTxSyncDesc
typedef struct tagSRrvTime_atim
typedef struct tagSTxBufHead
typedef struct tagSBEACONCtl
typedef struct tagSSecretKey
typedef struct tagSKeyEntry

Signed-off-by: Malcolm Priestley 
---
 drivers/staging/vt6655/desc.h | 59 ---
 1 file changed, 59 deletions(-)

diff --git a/drivers/staging/vt6655/desc.h b/drivers/staging/vt6655/desc.h
index 2374fa5..c916214 100644
--- a/drivers/staging/vt6655/desc.h
+++ b/drivers/staging/vt6655/desc.h
@@ -273,27 +273,6 @@ typedef struct tagSTxDesc {
 STxDesc, *PSTxDesc;
 typedef const STxDesc *PCSTxDesc;
 
-typedef struct tagSTxSyncDesc {
-   volatileSTDES0  m_td0TD0;
-   volatileSTDES1  m_td1TD1;
-   volatileu32 buff_addr; /* pointer to logical buffer */
-   volatileu32 next_desc; /* pointer to next logical descriptor */
-   volatileunsigned short m_wFIFOCtl;
-   volatileunsigned short m_wTimeStamp;
-   struct tagSTxSyncDesc *next __aligned(8);
-   volatilePDEVICE_TD_INFO pTDInfo __aligned(8);
-} __attribute__ ((__packed__))
-STxSyncDesc, *PSTxSyncDesc;
-typedef const STxSyncDesc *PCSTxSyncDesc;
-
-/* RsvTime buffer header */
-typedef struct tagSRrvTime_atim {
-   unsigned short wCTSTxRrvTime_ba;
-   unsigned short wTxRrvTime_a;
-} __attribute__ ((__packed__))
-SRrvTime_atim, *PSRrvTime_atim;
-typedef const SRrvTime_atim *PCSRrvTime_atim;
-
 /* Length, Service, and Signal fields of Phy for Tx */
 struct vnt_phy_field {
u8 signal;
@@ -307,42 +286,4 @@ union vnt_phy_field_swap {
u32 field_write;
 };
 
-/* Tx FIFO header */
-typedef struct tagSTxBufHead {
-   u32 adwTxKey[4];
-   unsigned short wFIFOCtl;
-   unsigned short wTimeStamp;
-   unsigned short wFragCtl;
-   unsigned char byTxPower;
-   unsigned char wReserved;
-} __attribute__ ((__packed__))
-STxBufHead, *PSTxBufHead;
-typedef const STxBufHead *PCSTxBufHead;
-
-typedef struct tagSBEACONCtl {
-   u32 BufReady:1;
-   u32 TSF:15;
-   u32 BufLen:11;
-   u32 Reserved:5;
-} __attribute__ ((__packed__))
-SBEACONCtl;
-
-typedef struct tagSSecretKey {
-   u32 dwLowDword;
-   unsigned char byHighByte;
-} __attribute__ ((__packed__))
-SSecretKey;
-
-typedef struct tagSKeyEntry {
-   unsigned char abyAddrHi[2];
-   unsigned short wKCTL;
-   unsigned char abyAddrLo[4];
-   u32 dwKey0[4];
-   u32 dwKey1[4];
-   u32 dwKey2[4];
-   u32 dwKey3[4];
-   u32 dwKey4[4];
-} __attribute__ ((__packed__))
-SKeyEntry;
-
 #endif /* __DESC_H__ */
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 04/15] staging: vt6655: remove unnecessary variable skb_dma

[Malcolm Priestley]

skb_dma flips from 0 to the contents buf_dma.

This is nolonger necessary so use buf_dma directly
and remove skb_dma altogether.

Signed-off-by: Malcolm Priestley 
---
 drivers/staging/vt6655/desc.h| 1 -
 drivers/staging/vt6655/device_main.c | 3 +--
 drivers/staging/vt6655/rxtx.c| 1 -
 3 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/staging/vt6655/desc.h b/drivers/staging/vt6655/desc.h
index 758eeb2..d568101 100644
--- a/drivers/staging/vt6655/desc.h
+++ b/drivers/staging/vt6655/desc.h
@@ -256,7 +256,6 @@ typedef struct tagDEVICE_TD_INFO {
void *mic_hdr;
struct sk_buff *skb;
unsigned char *buf;
-   dma_addr_t  skb_dma;
dma_addr_t  buf_dma;
dma_addr_t  curr_desc;
unsigned long dwReqCount;
diff --git a/drivers/staging/vt6655/device_main.c 
b/drivers/staging/vt6655/device_main.c
index 695aa25..89611a7 100644
--- a/drivers/staging/vt6655/device_main.c
+++ b/drivers/staging/vt6655/device_main.c
@@ -970,7 +970,6 @@ static void device_free_tx_buf(struct vnt_private *pDevice, 
PSTxDesc pDesc)
if (skb)
ieee80211_tx_status_irqsafe(pDevice->hw, skb);
 
-   pTDInfo->skb_dma = 0;
pTDInfo->skb = NULL;
pTDInfo->byFlags = 0;
 }
@@ -1201,7 +1200,7 @@ static int vnt_tx_packet(struct vnt_private *priv, struct 
sk_buff *skb)
head_td->m_td1TD1.wReqCount =
cpu_to_le16((u16)head_td->pTDInfo->dwReqCount);
 
-   head_td->buff_addr = cpu_to_le32(head_td->pTDInfo->skb_dma);
+   head_td->buff_addr = cpu_to_le32(head_td->pTDInfo->buf_dma);
 
/* Poll Transmit the adapter */
wmb();
diff --git a/drivers/staging/vt6655/rxtx.c b/drivers/staging/vt6655/rxtx.c
index 0ffa9bf..82380f3 100644
--- a/drivers/staging/vt6655/rxtx.c
+++ b/drivers/staging/vt6655/rxtx.c
@@ -1202,7 +1202,6 @@ s_cbFillTxBufHead(struct vnt_private *pDevice, unsigned 
char byPktType,
 
ptdCurr->pTDInfo->dwReqCount = cbReqCount;
ptdCurr->pTDInfo->dwHeaderLength = cbHeaderLength;
-   ptdCurr->pTDInfo->skb_dma = ptdCurr->pTDInfo->buf_dma;
 
return cbHeaderLength;
 }
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 03/15] staging: vt6655: dead code tx path remove dma_unmap_single

[Malcolm Priestley]

When pTDInfo->skb_dma not equal to pTDInfo->buf_dma, pTDInfo->skb_dma
equals zero.

as mentioned in comment pre-allocated buf_dma can't be unmapped
so remove dead code.

Signed-off-by: Malcolm Priestley 
---
 drivers/staging/vt6655/device_main.c | 14 --
 1 file changed, 14 deletions(-)

diff --git a/drivers/staging/vt6655/device_main.c 
b/drivers/staging/vt6655/device_main.c
index 053291a..695aa25 100644
--- a/drivers/staging/vt6655/device_main.c
+++ b/drivers/staging/vt6655/device_main.c
@@ -754,10 +754,6 @@ static void device_free_td0_ring(struct vnt_private 
*pDevice)
PSTxDescpDesc = &(pDevice->apTD0Rings[i]);
PDEVICE_TD_INFO  pTDInfo = pDesc->pTDInfo;
 
-   if (pTDInfo->skb_dma && (pTDInfo->skb_dma != pTDInfo->buf_dma))
-   dma_unmap_single(&pDevice->pcid->dev, pTDInfo->skb_dma,
-pTDInfo->skb->len, DMA_TO_DEVICE);
-
dev_kfree_skb(pTDInfo->skb);
kfree(pDesc->pTDInfo);
}
@@ -771,10 +767,6 @@ static void device_free_td1_ring(struct vnt_private 
*pDevice)
PSTxDescpDesc = &(pDevice->apTD1Rings[i]);
PDEVICE_TD_INFO  pTDInfo = pDesc->pTDInfo;
 
-   if (pTDInfo->skb_dma && (pTDInfo->skb_dma != pTDInfo->buf_dma))
-   dma_unmap_single(&pDevice->pcid->dev, pTDInfo->skb_dma,
-pTDInfo->skb->len, DMA_TO_DEVICE);
-
dev_kfree_skb(pTDInfo->skb);
kfree(pDesc->pTDInfo);
}
@@ -975,12 +967,6 @@ static void device_free_tx_buf(struct vnt_private 
*pDevice, PSTxDesc pDesc)
PDEVICE_TD_INFO  pTDInfo = pDesc->pTDInfo;
struct sk_buff *skb = pTDInfo->skb;
 
-   /* pre-allocated buf_dma can't be unmapped. */
-   if (pTDInfo->skb_dma && (pTDInfo->skb_dma != pTDInfo->buf_dma)) {
-   dma_unmap_single(&pDevice->pcid->dev, pTDInfo->skb_dma,
-skb->len, DMA_TO_DEVICE);
-   }
-
if (skb)
ieee80211_tx_status_irqsafe(pDevice->hw, skb);
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 07/15] staging: vt6655: fix tagSTxDesc -> next_desc type

[Malcolm Priestley]

Should always be __le32 type

Signed-off-by: Malcolm Priestley 
---
 drivers/staging/vt6655/desc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vt6655/desc.h b/drivers/staging/vt6655/desc.h
index 8dc53bd..26cd3e1 100644
--- a/drivers/staging/vt6655/desc.h
+++ b/drivers/staging/vt6655/desc.h
@@ -267,7 +267,7 @@ typedef struct tagSTxDesc {
volatileSTDES0  m_td0TD0;
volatileSTDES1  m_td1TD1;
volatile__le32  buff_addr;
-   volatileu32next_desc;
+   volatile__le32  next_desc;
struct tagSTxDesc *next __aligned(8);
volatilePDEVICE_TD_INFO pTDInfo __aligned(8);
 } __attribute__ ((__packed__))
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] ath10k: Improve performance by reducing tx_lock contention.

[Marty Faltesek]

From: Qi Zhou 

During tx completion, tx_lock is held for longer than required, preventing
efficient refill of htt->pending_tx. Refactor the code so that only MSDU
related operations are protected by the lock.

Improves downstream performance on a dual-core ARM Freescale LS1024A
(f.k.a. Mindspeed Comcerto 2000) AP with a 3x3 client from 495 to 580 Mbps.
Other CPU bound multicore systems may also benefit.

Signed-off-by: Denton Gentry 
Signed-off-by: Avery Pennarun 
[mfalte...@google.com: removed conflicting code for tracking msdu_ids.]
Signed-off-by: Marty Faltesek 

---
 drivers/net/wireless/ath/ath10k/htt_rx.c | 12 ++--
 drivers/net/wireless/ath/ath10k/htt_tx.c |  8 ++--
 drivers/net/wireless/ath/ath10k/txrx.c   | 17 -
 3 files changed, 12 insertions(+), 25 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c 
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 89eb16b..79e68fa 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1633,8 +1633,6 @@ static void ath10k_htt_rx_frm_tx_compl(struct ath10k *ar,
__le16 msdu_id;
int i;
 
-   lockdep_assert_held(&htt->tx_lock);
-
switch (status) {
case HTT_DATA_TX_STATUS_NO_ACK:
tx_done.no_ack = true;
@@ -2000,15 +1998,11 @@ void ath10k_htt_t2h_msg_handler(struct ath10k *ar, 
struct sk_buff *skb)
break;
}
 
-   spin_lock_bh(&htt->tx_lock);
ath10k_txrx_tx_unref(htt, &tx_done);
-   spin_unlock_bh(&htt->tx_lock);
break;
}
case HTT_T2H_MSG_TYPE_TX_COMPL_IND:
-   spin_lock_bh(&htt->tx_lock);
-   __skb_queue_tail(&htt->tx_compl_q, skb);
-   spin_unlock_bh(&htt->tx_lock);
+   skb_queue_tail(&htt->tx_compl_q, skb);
tasklet_schedule(&htt->txrx_compl_task);
return;
case HTT_T2H_MSG_TYPE_SEC_IND: {
@@ -2093,12 +2087,10 @@ static void ath10k_htt_txrx_compl_task(unsigned long 
ptr)
struct htt_resp *resp;
struct sk_buff *skb;
 
-   spin_lock_bh(&htt->tx_lock);
-   while ((skb = __skb_dequeue(&htt->tx_compl_q))) {
+   while ((skb = skb_dequeue(&htt->tx_compl_q))) {
ath10k_htt_rx_frm_tx_compl(htt->ar, skb);
dev_kfree_skb_any(skb);
}
-   spin_unlock_bh(&htt->tx_lock);
 
spin_lock_bh(&htt->rx_ring.lock);
while ((skb = __skb_dequeue(&htt->rx_compl_q))) {
diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c 
b/drivers/net/wireless/ath/ath10k/htt_tx.c
index a60ef7d..262d657 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -112,9 +112,7 @@ static int ath10k_htt_tx_clean_up_pending(int msdu_id, void 
*skb, void *ctx)
tx_done.discard = 1;
tx_done.msdu_id = msdu_id;
 
-   spin_lock_bh(&htt->tx_lock);
ath10k_txrx_tx_unref(htt, &tx_done);
-   spin_unlock_bh(&htt->tx_lock);
 
return 0;
 }
@@ -355,12 +353,11 @@ int ath10k_htt_mgmt_tx(struct ath10k_htt *htt, struct 
sk_buff *msdu)
 
spin_lock_bh(&htt->tx_lock);
res = ath10k_htt_tx_alloc_msdu_id(htt, msdu);
+   spin_unlock_bh(&htt->tx_lock);
if (res < 0) {
-   spin_unlock_bh(&htt->tx_lock);
goto err_tx_dec;
}
msdu_id = res;
-   spin_unlock_bh(&htt->tx_lock);
 
txdesc = ath10k_htc_alloc_skb(ar, len);
if (!txdesc) {
@@ -429,12 +426,11 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff 
*msdu)
 
spin_lock_bh(&htt->tx_lock);
res = ath10k_htt_tx_alloc_msdu_id(htt, msdu);
+   spin_unlock_bh(&htt->tx_lock);
if (res < 0) {
-   spin_unlock_bh(&htt->tx_lock);
goto err_tx_dec;
}
msdu_id = res;
-   spin_unlock_bh(&htt->tx_lock);
 
prefetch_len = min(htt->prefetch_len, msdu->len);
prefetch_len = roundup(prefetch_len, 4);
diff --git a/drivers/net/wireless/ath/ath10k/txrx.c 
b/drivers/net/wireless/ath/ath10k/txrx.c
index 826500b..40a8083 100644
--- a/drivers/net/wireless/ath/ath10k/txrx.c
+++ b/drivers/net/wireless/ath/ath10k/txrx.c
@@ -53,8 +53,6 @@ void ath10k_txrx_tx_unref(struct ath10k_htt *htt,
struct ath10k_skb_cb *skb_cb;
struct sk_buff *msdu;
 
-   lockdep_assert_held(&htt->tx_lock);
-
ath10k_dbg(ar, ATH10K_DBG_HTT,
   "htt tx completion msdu_id %u discard %d no_ack %d success 
%d\n",
   tx_done->msdu_id, !!tx_done->discard,
@@ -66,12 +64,19 @@ void ath10k_txrx_tx_unref(struct ath10k_htt *htt,
return;
}
 
+   spin_lock_bh(&htt->tx_lock);
msdu = idr_find(&htt->pending_tx, tx_done->msdu_id);
if (!msdu) {
ath10k_warn(ar, "received tx completion for invalid msdu_id: 
%d\n",
tx_done->msdu_id);
+ 

Re: Patch for backtrace dump WARNING: CPU: 0 PID: 668 at net/wireless/sme.c:655

[Rafał Miłecki]

On 20 July 2015 at 22:14, Marc Murphy  wrote:
> I have been looking at an issue with WPA/WPA2 and joining a specific Access 
> Point SSID that also has a hidden SSID available.  This was with 3.14.47 
> kernel but it is also present in all 3.x kernels.
> When the AP's are being scanned it there is a warning generated stating that 
> the bssid is empty yet when you inspect what is actually happening in the 
> code it is because there is an SSID string but its length is 0 so it fails to 
> return when it should.
>
> in net/wireless/scan.c there is a function is_bss that should return the 
> cfg80211_bss struct when it finds the matching details.  When the bssid is 
> found but the SSID is empty (valid string "" but with length of 0) it passes 
> through when it should return as the bssid matches.
>
> Patch is as follows:

Please follow
Documentation/SubmittingPatches
Documentation/CodingStyle
(and resend your patch)

You need a clear commit messages, description and use kernel's coding style.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] bcma: switch GPIO portions to use GPIOLIB_IRQCHIP

[Rafał Miłecki]

On 21 July 2015 at 23:04, Linus Walleij  wrote:
> This switches the BCMA GPIO driver to use GPIOLIB_IRQCHIP to
> handle its interrupts instead of rolling its own copy of the
> irqdomain handling etc.
>
> Signed-off-by: Linus Walleij 
> ---
> Hi BCMA people,
>
> if we can figure this out it would be great if you can test this
> and merge it through whatever GIT tree handles BCMA patches.
> Alternatively I can merge it into the GPIO tree with your ACK.
>
> This is not even compiled, I don't have the right cross compilers
> but the conversion is done like all other GPIOLIB_IRQCHIP conversions
> I've done, so it shouldn't be very far off. Maybe you can get it
> in shape in accordance with my idea if I screwed up? Thanks.

I'm away one my holidays, won't be able to check it anytime soon.
Unless someone else willing to test it appears, I guess we should hold
it for now, sorry :( I'll for sure handle this after my holidays (late
august).
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] bcma: populate bus DT subnodes as platform_device-s

[Rafał Miłecki]

On 28 June 2015 at 17:17, Rafał Miłecki  wrote:
> Our bus should allow defining children nodes as we may want to specify
> devices attached to the bus. This is required e.g. to specify NAND or
> ChipCommon cores and use bus's address and IRQ mappings.
>
> Signed-off-by: Rafał Miłecki 
> ---
>  drivers/bcma/main.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
> index 9635f10..5912847 100644
> --- a/drivers/bcma/main.c
> +++ b/drivers/bcma/main.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  MODULE_DESCRIPTION("Broadcom's specific AMBA driver");
>  MODULE_LICENSE("GPL");
> @@ -409,6 +410,13 @@ int bcma_bus_register(struct bcma_bus *bus)
> bcma_core_pci_early_init(&bus->drv_pci[0]);
> }
>
> +   if (bus->host_pdev) {
> +   struct device *dev = &bus->host_pdev->dev;
> +
> +   of_platform_populate(dev->of_node, of_default_bus_match_table,
> +NULL, dev);
> +   }
> +

This caused a compile error when using bcma as module:
ERROR: "of_default_bus_match_table" [drivers/bcma/bcma.ko] undefined!

There are two options I guess:
1) Export of_default_bus_match_table
2) Use some better condition like
if (IS_BUILTIN(CONFIG_BCMA) && bus->host_pdev)

Unfortunately I'm on my long holidays right now.

Hauke: do you think you can find a moment to handle this?

Sorry for the problem :|

-- 
Rafał
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 5/5] wireless-regdb: Update 5 GHz rules for Taiwan (TW) to follow US

[Chen-Yu Tsai]

Following the amendment of FCC part 15E and U-NII regulations effective
2014/06/02, and the opening up of 5150 ~ 5250 MHz and 5600 ~ 5650 MHz
spectrum in Taiwan, vendors have asked whether Taiwan's regulations
would be updated to match the new FCC rules, when this would happen,
and what to do in the interim.

The NCC, Taiwan's regulatory body has officially replied that new
amendments are under way, and the goal is to match the FCC rules.
Until the amendments come through, vendors are free to test and
submit applications using the new FCC rules for transmission power
limits and DFS requirements, though unintended / unwanted emissions
must still conform to the current standard, LP0002. [1][2]

This has been confirmed via a phone call to the NCC.

[1] 
http://www.rheintech.com/our-blog/item/585-taiwan-ncc-opens-5150-5250-mhz-for-wireless-devices
[2] Proposal #10312260 (p.6, Chinese),

http://www.etc.org.tw/_library/K00/%E9%9B%BB%E4%BF%A1%E7%B5%82%E7%AB%AF%E8%A8%AD%E5%82%99%E5%AF%A9%E9%A9%97/1031223_nccqa56.pdf

Signed-off-by: Chen-Yu Tsai 
---
 db.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/db.txt b/db.txt
index 29ba4b6..56fbba3 100644
--- a/db.txt
+++ b/db.txt
@@ -1125,10 +1125,10 @@ country TT: DFS-FCC
 # LP0002 Low-power Radio-frequency Devices Technical Regulations / 28 Jun 2011:
 #   http://www.ncc.gov.tw/english/show_file.aspx?table_name=news&file_sn=681
 #   (section 3.10.1, 4.7)
-country TW: DFS-JP
+country TW: DFS-FCC
(2400 - 2483.5 @ 40), (30)
(5150 - 5250 @ 80), (30), AUTO-BW
-   (5250 - 5350 @ 80), (17), DFS, AUTO-BW
+   (5250 - 5350 @ 80), (23), DFS, AUTO-BW
(5470 - 5725 @ 160), (23), DFS
(5725 - 5850 @ 80), (30)
  
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/5] wireless-regdb: Update U-NII-2c (5470 ~ 5725 MHz) rules for Taiwan (TW)

[Chen-Yu Tsai]

Taiwan's Ministry of Transportation and Communications revised its
frequency allocation rules [1] on 2014/11/17, allowing usage of 5600 ~
5650 MHz, previously allocated to weather radars, to U-NII applications
with DFS support.

Also, the technical regulations [2] show that for 5470 ~ 5725 MHz U-NII
applications, the peak transmit power shall not exceed the lesser of
250 mW (slightly less than 24 dBm) or 11 dBm + 10log B, where B is the
26dB emission bandwidth in MHz. This is slightly more than 23 dBm for
20 MHz channels.

This patch updates both. Also add links to the two documents into the
database.

[1] 
http://www.motc.gov.tw/websitedowndoc?file=post/201411171137330.doc&filedisplay=Table+of+radio+frequency+allocation.doc
[2] http://www.ncc.gov.tw/english/show_file.aspx?table_name=news&file_sn=681

Signed-off-by: Chen-Yu Tsai 
---
 db.txt | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/db.txt b/db.txt
index 982db34..5114557 100644
--- a/db.txt
+++ b/db.txt
@@ -1118,11 +1118,17 @@ country TT: DFS-FCC
(5490 - 5730 @ 160), (24), DFS
(5735 - 5835 @ 80), (30)
 
+# Source:
+# Table of Frequency Allocations of Republic of China (Taiwan) / Nov 2014:
+#   http://www.motc.gov.tw/websitedowndoc?file=post/201411171137330.doc&; \
+#  filedisplay=Table+of+radio+frequency+allocation.doc
+# LP0002 Low-power Radio-frequency Devices Technical Regulations / 28 Jun 2011:
+#   http://www.ncc.gov.tw/english/show_file.aspx?table_name=news&file_sn=681
+#   (section 3.10.1, 4.7)
 country TW: DFS-JP
(2402 - 2472 @ 40), (30)
(5270 - 5330 @ 40), (17), DFS
-   (5490 - 5590 @ 80), (30), DFS
-   (5650 - 5710 @ 40), (30), DFS
+   (5470 - 5725 @ 160), (23), DFS
(5735 - 5835 @ 80), (30)
  
 country TZ:
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/5] wireless-regdb: Update TW and US rules to latest regulations

[Chen-Yu Tsai]

Hi Seth,

I've split up my original patch into 4, each addressing a small part of
the original. I've also added a patch to update the US 5150 ~ 5250 MHz
rule.

Patch 1 updates the 5470 ~ 5725 MHz rules for Taiwan, specifically
the opening up of 5600 ~ 5650 MHz spectrum previously allocated to
weather radars. The transmission power limit is also corrected to
match the regulations.

Patch 2 changes the boundary frequencies for each rule for Taiwan to
match the frequency allocation table. The "regulation" database shouldn't
care about artificial channel boundaries.

Patch 3 adds the previously unusable 5150 ~ 5250 MHz band for Taiwan.

Patch 4 updates the transmission power limits for 5150 ~ 5250 MHz for
the US.

Patch 5 updates the transmission power limits for Taiwan, per the NCC's
official reply. This patch may be slightly controversial, as there is
no official English document. Either someone will have to independently
verify this, or translate the Chinese document.


Regards
ChenYu

Chen-Yu Tsai (5):
  wireless-regdb: Update U-NII-2c (5470 ~ 5725 MHz) rules for Taiwan
(TW)
  wireless-regdb: Update regulatory rule boundary frequencies for Taiwan
(TW)
  wireless-regdb: Add U-NII-1 (5150 ~ 5250 MHz) band for Taiwan (TW)
  wireless-regdb: Update 5GHz rules for US
  wireless-regdb: Update 5 GHz rules for Taiwan (TW) to follow US

 db.txt | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/5] wireless-regdb: Update regulatory rule boundary frequencies for Taiwan (TW)

[Chen-Yu Tsai]

Taiwan's frequency allocation rules [1] list the following frequency
ranges available for low power RF devices:

  - 2400 ~ 2483.5 MHz
  - 5150 ~ 5250 MHz
  - 5250 ~ 5350 MHz
  - 5470 ~ 5725 MHz
  - 5725 ~ 5850 MHz

Update the rules to match. Since 5250 ~ 5350 MHz is wide enough for
VHT80, and there are no regulations against it, enable it as well.

[1] 
http://www.motc.gov.tw/websitedowndoc?file=post/201411171137330.doc&filedisplay=Table+of+radio+frequency+allocation.doc
[2] http://www.ncc.gov.tw/english/show_file.aspx?table_name=news&file_sn=681

Signed-off-by: Chen-Yu Tsai 
---
 db.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/db.txt b/db.txt
index 5114557..8a05c57 100644
--- a/db.txt
+++ b/db.txt
@@ -1126,10 +1126,10 @@ country TT: DFS-FCC
 #   http://www.ncc.gov.tw/english/show_file.aspx?table_name=news&file_sn=681
 #   (section 3.10.1, 4.7)
 country TW: DFS-JP
-   (2402 - 2472 @ 40), (30)
-   (5270 - 5330 @ 40), (17), DFS
+   (2400 - 2483.5 @ 40), (30)
+   (5250 - 5350 @ 80), (17), DFS
(5470 - 5725 @ 160), (23), DFS
-   (5735 - 5835 @ 80), (30)
+   (5725 - 5850 @ 80), (30)
  
 country TZ:
(2402 - 2482 @ 40), (20)
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 4/5] wireless-regdb: Update 5GHz rules for US

[Chen-Yu Tsai]

The FCC increased the maximum conducted transmission power for the
U-NII-1 (5150 ~ 5250 MHz) band to 30 dBm or 1 W for master devices
and 24 dBm or 250 mW for mobile/portable devices.

Effective 6/2/2014.

See FCC KDB 905462 D06.

Signed-off-by: Chen-Yu Tsai 
---
 db.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/db.txt b/db.txt
index cadd52c..29ba4b6 100644
--- a/db.txt
+++ b/db.txt
@@ -1160,7 +1160,7 @@ country UG: DFS-FCC
 
 country US: DFS-FCC
(2402 - 2472 @ 40), (30)
-   (5170 - 5250 @ 80), (17), AUTO-BW
+   (5170 - 5250 @ 80), (30), AUTO-BW
(5250 - 5330 @ 80), (23), DFS, AUTO-BW
(5490 - 5730 @ 160), (23), DFS
(5735 - 5835 @ 80), (30)
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/5] wireless-regdb: Add U-NII-1 (5150 ~ 5250 MHz) band for Taiwan (TW)

[Chen-Yu Tsai]

Taiwan's Ministry of Transportation and Communications revised its
frequency allocation rules [1] on 2014/11/17, opening up 5150 ~ 5250
MHz to U-NII applications.

Taiwan's regulatory body, NCC, officially stated [3][4] that until
the technical regulatory standard [2] are updated to cover this part
of the spectrum, FCC rules (part 15E, 15.407, effective 2014/06/02)
shall serve in its place.

Also add AUTO-BW to this and the next (5250 ~ 5350 MHz) rule, so the
system can actually use VHT160 channels spanning these two rules.

[1] 
http://www.motc.gov.tw/websitedowndoc?file=post/201411171137330.doc&filedisplay=Table+of+radio+frequency+allocation.doc
[2] http://www.ncc.gov.tw/english/show_file.aspx?table_name=news&file_sn=681
[3] 
http://www.rheintech.com/our-blog/item/585-taiwan-ncc-opens-5150-5250-mhz-for-wireless-devices
[4] Proposal #10312260 (p.6, Chinese),

http://www.etc.org.tw/_library/K00/%E9%9B%BB%E4%BF%A1%E7%B5%82%E7%AB%AF%E8%A8%AD%E5%82%99%E5%AF%A9%E9%A9%97/1031223_nccqa56.pdf

Signed-off-by: Chen-Yu Tsai 
---
 db.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/db.txt b/db.txt
index 8a05c57..cadd52c 100644
--- a/db.txt
+++ b/db.txt
@@ -1127,7 +1127,8 @@ country TT: DFS-FCC
 #   (section 3.10.1, 4.7)
 country TW: DFS-JP
(2400 - 2483.5 @ 40), (30)
-   (5250 - 5350 @ 80), (17), DFS
+   (5150 - 5250 @ 80), (30), AUTO-BW
+   (5250 - 5350 @ 80), (17), DFS, AUTO-BW
(5470 - 5725 @ 160), (23), DFS
(5725 - 5850 @ 80), (30)
  
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] bcma: populate bus DT subnodes as platform_device-s

[Kalle Valo]

Rafał Miłecki  writes:

>> +   if (bus->host_pdev) {
>> +   struct device *dev = &bus->host_pdev->dev;
>> +
>> +   of_platform_populate(dev->of_node, 
>> of_default_bus_match_table,
>> +NULL, dev);
>> +   }
>> +
>
> This caused a compile error when using bcma as module:
> ERROR: "of_default_bus_match_table" [drivers/bcma/bcma.ko] undefined!
>
> There are two options I guess:
> 1) Export of_default_bus_match_table
> 2) Use some better condition like
> if (IS_BUILTIN(CONFIG_BCMA) && bus->host_pdev)
>
> Unfortunately I'm on my long holidays right now.
>
> Hauke: do you think you can find a moment to handle this?

I can cook up a patch which uses IS_BUILTIN() so that we get the build
working again. You can fix this better once you come back.

> Sorry for the problem :|

No worries, enjoy your vacation :)

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] bcma: fix linking problem with of_default_bus_match_table

[Kalle Valo]

Stephen reported a build problem caused by commit cae761b5a6bd ("bcma: populate
bus DT subnodes as platform_device-s"):

ERROR: "of_default_bus_match_table" [drivers/bcma/bcma.ko] undefined!

Rafał Miłecki suggested as a quick fix to use IS_BUILTIN() to workaround the
issue. The downside is that this won't work when BCMA is compiled as a module,
but we can live with that for now just to unblock the breakage.

Reported-by: Stephen Rothwell 
Fixes: cae761b5a6bd ("bcma: populate bus DT subnodes as platform_device-s")
Signed-off-by: Kalle Valo 
---
 drivers/bcma/main.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index 59128478a90f..6b7d54622058 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -410,7 +410,7 @@ int bcma_bus_register(struct bcma_bus *bus)
bcma_core_pci_early_init(&bus->drv_pci[0]);
}
 
-   if (bus->host_pdev) {
+   if (IS_BUILTIN(CONFIG_BCMA) && bus->host_pdev) {
struct device *dev = &bus->host_pdev->dev;
 
of_platform_populate(dev->of_node, of_default_bus_match_table,
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html