* Re: [PATCH 01/13] staging: vt6656: cleanup MACvWriteMultiAddr
From: Greg KH @ 2013-06-05 22:43 UTC (permalink / raw)
To: Malcolm Priestley; +Cc: linux-wireless
In-Reply-To: <1370463202.6213.16.camel@canaries64>
On Wed, Jun 05, 2013 at 09:13:22PM +0100, Malcolm Priestley wrote:
> Remove internal white space and camel case.
>
> Camel case changes;
> pDevice -> priv
> uByteidx -> byte_idx
> byData -> data
>
> Functional change secondary buffer byData1 removed.
>
> Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
> ---
> drivers/staging/vt6656/mac.c | 24 +++++++++---------------
> drivers/staging/vt6656/mac.h | 2 +-
> 2 files changed, 10 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/staging/vt6656/mac.c b/drivers/staging/vt6656/mac.c
> index 343db19..89d700f 100644
> --- a/drivers/staging/vt6656/mac.c
> +++ b/drivers/staging/vt6656/mac.c
> @@ -46,26 +46,20 @@ static int msglevel =MSG_LEVEL_INFO;
> * Write MAC Multicast Address Mask
> *
> * Parameters:
> - * In:
> - * uByteidx - Index of Mask
> - * byData - Mask Value to write
> - * Out:
> - * none
> + * In:
> + * byte_idx - Index of Mask
> + * data- Mask Value to write
> + * Out:
> + * none
> *
> * Return Value: none
> *
> */
> -void MACvWriteMultiAddr(struct vnt_private *pDevice, u32 uByteIdx, u8 byData)
> +void MACvWriteMultiAddr(struct vnt_private *priv, u16 byte_idx, u8 data)
Why did you change the variable type of byte_idx? You don't document
that in your changelog above.
Yes, it's being cast, but don't mix formatting / variable name changes
with logical changes please. Remember, one patch per "thing" you
change.
please redo this.
thanks,
greg k-h
^ permalink raw reply
* Re: carl9170:5/10 MHz Channel Support on carl9170
From: Christian Lamparter @ 2013-06-05 21:35 UTC (permalink / raw)
To: C.B. Wang; +Cc: Adrian Chadd, linux-wireless
In-Reply-To: <CAJ-Vmok5yLZvstvYHi35ALWG3q8sVYLx_1PuhL31unOjxrg-4g@mail.gmail.com>
Hello Adrian
On Wednesday, June 05, 2013 08:08:14 PM Adrian Chadd wrote:
> I think that the zydas mac doesn't officially support 5/10mhz operation.
Just checked, it looks like the bandwidth control is very similar to ath9k.
The settings is controlled by Bit 3 and 2 in AR9170_PWR_REG_CLOCK_SEL (0x1d4008)
00 <-- default
01 <-- half
There's a new firmware branch for this new feature:
<https://github.com/chunkeey/carl9170fw/tree/halfandquarter>
The patch for the carl9170 driver will come later... Once mac/nl/cfg80211
and userspace have support for the 5/10 MHz channel bandwidth.
So, if you [(Mr.?) Wang] is interested, please help us testing
and integrating the stack patchset into the kernel - NOW -:
"Add support for 5 and 10 MHz channels"
<http://www.spinics.net/lists/linux-wireless/msg107116.html>
> > I've read the "otus" vendor driver and found that in the source file
> > /HalPlus/OTUS_FB50/hpreg.h on
> > line 1915,the comment says "Temporary discard channel that BW < 20MHz
> > (5 or 10MHz) */
> > /* Our architecture does not implemnt it"
> > I think either the driver does not implement the 5/10 channels or
> > worse,the ar9170 chip does not support 5/10 mhz channel at all.
I think "architecture" could be just the software. At least an
ath9k spectral analyzer confirmed that at least the PHY can operate
on 10 MHz channels in the 5GHz band.
> > But 802.11j has 10mhz channel support.To comply with the 802.11j
> > standard,the chip should support 10mhz channel width.
Oh, I don't have a 802.11j copy handy, is it a mandatory or optional
feature?
> > Also the ar9170 MAC was indeed designed by ZyDaS berfore
> > the company was taken over by Atheros.
Do you know any 5 GHz solution from ZyDaS that sold as 802.11j
compliant?
> > It has some problems with long distance links.
True, but again look at the vendor driver. I think it should
be very easy to implement "set coverage class". The slot time
can be set by "AR9170_MAC_REG_SLOT_TIME" register and the ack
timeout should be in "AR9170_MAC_REG_ACK_EXTENSION". That's
all the information I have. So what are you waiting for ;)
Regards,
Chr
^ permalink raw reply
* Re: stop_machine lockup issue in 3.9.y.
From: Ben Greear @ 2013-06-05 21:33 UTC (permalink / raw)
To: Tejun Heo
Cc: Rusty Russell, Joe Lawrence, Linux Kernel Mailing List, stable,
Luis R. Rodriguez, Jouni Malinen, Vasanthakumar Thiagarajan,
Senthil Balasubramanian, linux-wireless, ath9k-devel,
Thomas Gleixner, Ingo Molnar
In-Reply-To: <20130605211157.GK10693@mtj.dyndns.org>
On 06/05/2013 02:11 PM, Tejun Heo wrote:
> (cc'ing wireless crowd, tglx and Ingo. The original thread is at
> http://thread.gmane.org/gmane.linux.kernel/1500158/focus=55005 )
>
> Hello, Ben.
>
> On Wed, Jun 05, 2013 at 01:58:31PM -0700, Ben Greear wrote:
>> Hmm, wonder if I found it. I previously saw times where it appears
>> jiffies does not increment. __do_softirq has a break-out based on
>> jiffies timeout. Maybe that is failing to get us out of __do_softirq
>> in my lockup case because for whatever reason the system cannot update
>> jiffies in this case?
>>
>> I added this (probably whitespace damaged) hack and now I have not been
>> able to reproduce the problem.
>
> Ah, nice catch. :)
>
>> diff --git a/kernel/softirq.c b/kernel/softirq.c
>> index 14d7758..621ea3b 100644
>> --- a/kernel/softirq.c
>> +++ b/kernel/softirq.c
>> @@ -212,6 +212,7 @@ asmlinkage void __do_softirq(void)
>> unsigned long end = jiffies + MAX_SOFTIRQ_TIME;
>> int cpu;
>> unsigned long old_flags = current->flags;
>> + unsigned long loops = 0;
>>
>> /*
>> * Mask out PF_MEMALLOC s current task context is borrowed for the
>> @@ -241,6 +242,7 @@ restart:
>> unsigned int vec_nr = h - softirq_vec;
>> int prev_count = preempt_count();
>>
>> + loops++;
>> kstat_incr_softirqs_this_cpu(vec_nr);
>>
>> trace_softirq_entry(vec_nr);
>> @@ -265,7 +267,7 @@ restart:
>>
>> pending = local_softirq_pending();
>> if (pending) {
>> - if (time_before(jiffies, end) && !need_resched())
>> + if (time_before(jiffies, end) && !need_resched() && (loops < 500))
>> goto restart;
>
> So, softirq most likely kicked off from ath9k is rescheduling itself
> to the extent where it ends up locking out the CPU completely. The
> problem is usually okay because the processing would break out in 2ms
> but as jiffies is stopped in this case with all other CPUs trapped in
> stop_machine, the loop never breaks and the machine hangs. While
> adding the counter limit probably isn't a bad idea, softirq requeueing
> itself indefinitely sounds pretty buggy.
Just to be clear on the ath9k part for the wifi folks:
This is basically un-patched 3.9.4, but I have 200 virtual stations
configured on each of two ath9k radios. I cannot reproduce the problem
without ath9k, but I do not know for certain ath9k is the real
culprit.
In the case where I can most easily reproduce the lockup, ath9k virtual
stations would be trying to associate, so I'd expect a fair amount
of packet processing to be happening...
> ath9k people, do you guys have any idea what's going on? Why would
> softirq repeat itself indefinitely?
>
> Ingo, Thomas, we're seeing a stop_machine hanging because
>
> * All other CPUs entered IRQ disabled stage. Jiffies is not being
> updated.
>
> * The last CPU get caught up executing softirq indefinitely. As
> jiffies doesn't get updated, it never breaks out of softirq
> handling. This is a deadlock. This CPU won't break out of softirq
> handling unless jiffies is updated and other CPUs can't do anything
> until this CPU enters the same stop_machine stage.
>
> Ben found out that breaking out of softirq handling after certain
> number of repetitions makes the issue go away, which isn't a proper
> fix but we might want anyway. What do you guys think?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: stop_machine lockup issue in 3.9.y.
From: Tejun Heo @ 2013-06-05 21:11 UTC (permalink / raw)
To: Ben Greear
Cc: Rusty Russell, Joe Lawrence, Linux Kernel Mailing List, stable,
Luis R. Rodriguez, Jouni Malinen, Vasanthakumar Thiagarajan,
Senthil Balasubramanian, linux-wireless, ath9k-devel,
Thomas Gleixner, Ingo Molnar
In-Reply-To: <51AFA677.9010605@candelatech.com>
(cc'ing wireless crowd, tglx and Ingo. The original thread is at
http://thread.gmane.org/gmane.linux.kernel/1500158/focus=55005 )
Hello, Ben.
On Wed, Jun 05, 2013 at 01:58:31PM -0700, Ben Greear wrote:
> Hmm, wonder if I found it. I previously saw times where it appears
> jiffies does not increment. __do_softirq has a break-out based on
> jiffies timeout. Maybe that is failing to get us out of __do_softirq
> in my lockup case because for whatever reason the system cannot update
> jiffies in this case?
>
> I added this (probably whitespace damaged) hack and now I have not been
> able to reproduce the problem.
Ah, nice catch. :)
> diff --git a/kernel/softirq.c b/kernel/softirq.c
> index 14d7758..621ea3b 100644
> --- a/kernel/softirq.c
> +++ b/kernel/softirq.c
> @@ -212,6 +212,7 @@ asmlinkage void __do_softirq(void)
> unsigned long end = jiffies + MAX_SOFTIRQ_TIME;
> int cpu;
> unsigned long old_flags = current->flags;
> + unsigned long loops = 0;
>
> /*
> * Mask out PF_MEMALLOC s current task context is borrowed for the
> @@ -241,6 +242,7 @@ restart:
> unsigned int vec_nr = h - softirq_vec;
> int prev_count = preempt_count();
>
> + loops++;
> kstat_incr_softirqs_this_cpu(vec_nr);
>
> trace_softirq_entry(vec_nr);
> @@ -265,7 +267,7 @@ restart:
>
> pending = local_softirq_pending();
> if (pending) {
> - if (time_before(jiffies, end) && !need_resched())
> + if (time_before(jiffies, end) && !need_resched() && (loops < 500))
> goto restart;
So, softirq most likely kicked off from ath9k is rescheduling itself
to the extent where it ends up locking out the CPU completely. The
problem is usually okay because the processing would break out in 2ms
but as jiffies is stopped in this case with all other CPUs trapped in
stop_machine, the loop never breaks and the machine hangs. While
adding the counter limit probably isn't a bad idea, softirq requeueing
itself indefinitely sounds pretty buggy.
ath9k people, do you guys have any idea what's going on? Why would
softirq repeat itself indefinitely?
Ingo, Thomas, we're seeing a stop_machine hanging because
* All other CPUs entered IRQ disabled stage. Jiffies is not being
updated.
* The last CPU get caught up executing softirq indefinitely. As
jiffies doesn't get updated, it never breaks out of softirq
handling. This is a deadlock. This CPU won't break out of softirq
handling unless jiffies is updated and other CPUs can't do anything
until this CPU enters the same stop_machine stage.
Ben found out that breaking out of softirq handling after certain
number of repetitions makes the issue go away, which isn't a proper
fix but we might want anyway. What do you guys think?
Thanks.
--
tejun
^ permalink raw reply
* [PATCH 13/13] staging: vt6656: clean up MACvWriteBeaconInterval
From: Malcolm Priestley @ 2013-06-05 20:51 UTC (permalink / raw)
To: gregkh; +Cc: linux-wireless
Remove internal white space and camel case.
Camel case changes;
pDevice -> priv
pbyData -> data
wInterval -> interval
Functional change
CONTROLnsRequestOut Length = ARRAY_SIZE(data)
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
---
drivers/staging/vt6656/mac.c | 21 ++++++++-------------
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/vt6656/mac.c b/drivers/staging/vt6656/mac.c
index e255405..1d25722 100644
--- a/drivers/staging/vt6656/mac.c
+++ b/drivers/staging/vt6656/mac.c
@@ -279,18 +279,13 @@ void MACvDisableBarkerPreambleMd(struct vnt_private *priv)
MESSAGE_REQUEST_MACREG, ARRAY_SIZE(data), data);
}
-void MACvWriteBeaconInterval(struct vnt_private *pDevice, u16 wInterval)
+void MACvWriteBeaconInterval(struct vnt_private *priv, u16 interval)
{
- u8 pbyData[2];
-
- pbyData[0] = (u8)(wInterval & 0xff);
- pbyData[1] = (u8)(wInterval >> 8);
-
- CONTROLnsRequestOut(pDevice,
- MESSAGE_TYPE_WRITE,
- MAC_REG_BI,
- MESSAGE_REQUEST_MACREG,
- 2,
- pbyData
- );
+ u8 data[2];
+
+ data[0] = (u8)(interval & 0xff);
+ data[1] = (u8)(interval >> 8);
+
+ CONTROLnsRequestOut(priv, MESSAGE_TYPE_WRITE, MAC_REG_BI,
+ MESSAGE_REQUEST_MACREG, ARRAY_SIZE(data), data);
}
--
1.8.1.2
^ permalink raw reply related
* [PATCH 12/13] staging: vt6656: clean up MACvDisableBarkerPreambleMd
From: Malcolm Priestley @ 2013-06-05 20:49 UTC (permalink / raw)
To: gregkh; +Cc: linux-wireless
Remove internal white space and camel case.
Camel case changes;
pDevice -> priv
pbyData -> data
Functional change
CONTROLnsRequestOut Length = ARRAY_SIZE(data)
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
---
drivers/staging/vt6656/mac.c | 17 ++++++-----------
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/vt6656/mac.c b/drivers/staging/vt6656/mac.c
index 89bba7d..e255405 100644
--- a/drivers/staging/vt6656/mac.c
+++ b/drivers/staging/vt6656/mac.c
@@ -268,20 +268,15 @@ void MACvEnableBarkerPreambleMd(struct vnt_private *priv)
MESSAGE_REQUEST_MACREG, ARRAY_SIZE(data), data);
}
-void MACvDisableBarkerPreambleMd(struct vnt_private *pDevice)
+void MACvDisableBarkerPreambleMd(struct vnt_private *priv)
{
- u8 pbyData[2];
+ u8 data[2];
- pbyData[0] = 0;
- pbyData[1] = EnCFG_BarkerPream;
+ data[0] = 0;
+ data[1] = EnCFG_BarkerPream;
- CONTROLnsRequestOut(pDevice,
- MESSAGE_TYPE_WRITE_MASK,
- MAC_REG_ENCFG2,
- MESSAGE_REQUEST_MACREG,
- 2,
- pbyData
- );
+ CONTROLnsRequestOut(priv, MESSAGE_TYPE_WRITE_MASK, MAC_REG_ENCFG2,
+ MESSAGE_REQUEST_MACREG, ARRAY_SIZE(data), data);
}
void MACvWriteBeaconInterval(struct vnt_private *pDevice, u16 wInterval)
--
1.8.1.2
^ permalink raw reply related
* [PATCH 11/13] staging: vt6656: clean up MACvEnableBarkerPreambleMd
From: Malcolm Priestley @ 2013-06-05 20:47 UTC (permalink / raw)
To: gregkh; +Cc: linux-wireless
Remove internal white space and camel case.
Camel case changes;
pDevice -> priv
pbyData -> data
Functional change
CONTROLnsRequestOut Length = ARRAY_SIZE(data)
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
---
drivers/staging/vt6656/mac.c | 17 ++++++-----------
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/vt6656/mac.c b/drivers/staging/vt6656/mac.c
index 4038ad8..89bba7d 100644
--- a/drivers/staging/vt6656/mac.c
+++ b/drivers/staging/vt6656/mac.c
@@ -257,20 +257,15 @@ void MACvDisableProtectMD(struct vnt_private *priv)
MESSAGE_REQUEST_MACREG, ARRAY_SIZE(data), data);
}
-void MACvEnableBarkerPreambleMd(struct vnt_private *pDevice)
+void MACvEnableBarkerPreambleMd(struct vnt_private *priv)
{
- u8 pbyData[2];
+ u8 data[2];
- pbyData[0] = EnCFG_BarkerPream;
- pbyData[1] = EnCFG_BarkerPream;
+ data[0] = EnCFG_BarkerPream;
+ data[1] = EnCFG_BarkerPream;
- CONTROLnsRequestOut(pDevice,
- MESSAGE_TYPE_WRITE_MASK,
- MAC_REG_ENCFG2,
- MESSAGE_REQUEST_MACREG,
- 2,
- pbyData
- );
+ CONTROLnsRequestOut(priv, MESSAGE_TYPE_WRITE_MASK, MAC_REG_ENCFG2,
+ MESSAGE_REQUEST_MACREG, ARRAY_SIZE(data), data);
}
void MACvDisableBarkerPreambleMd(struct vnt_private *pDevice)
--
1.8.1.2
^ permalink raw reply related
* [PATCH 10/13] staging: vt6656: clean up MACvDisableProtectMD
From: Malcolm Priestley @ 2013-06-05 20:46 UTC (permalink / raw)
To: gregkh; +Cc: linux-wireless
Remove internal white space and camel case.
Camel case changes;
pDevice -> priv
pbyData -> data
Functional change
CONTROLnsRequestOut Length = ARRAY_SIZE(data)
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
---
drivers/staging/vt6656/mac.c | 17 ++++++-----------
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/vt6656/mac.c b/drivers/staging/vt6656/mac.c
index 3e5c816..4038ad8 100644
--- a/drivers/staging/vt6656/mac.c
+++ b/drivers/staging/vt6656/mac.c
@@ -246,20 +246,15 @@ void MACvEnableProtectMD(struct vnt_private *priv)
MESSAGE_REQUEST_MACREG, ARRAY_SIZE(data), data);
}
-void MACvDisableProtectMD(struct vnt_private *pDevice)
+void MACvDisableProtectMD(struct vnt_private *priv)
{
- u8 pbyData[2];
+ u8 data[2];
- pbyData[0] = 0;
- pbyData[1] = EnCFG_ProtectMd;
+ data[0] = 0;
+ data[1] = EnCFG_ProtectMd;
- CONTROLnsRequestOut(pDevice,
- MESSAGE_TYPE_WRITE_MASK,
- MAC_REG_ENCFG0,
- MESSAGE_REQUEST_MACREG,
- 2,
- pbyData
- );
+ CONTROLnsRequestOut(priv, MESSAGE_TYPE_WRITE_MASK, MAC_REG_ENCFG0,
+ MESSAGE_REQUEST_MACREG, ARRAY_SIZE(data), data);
}
void MACvEnableBarkerPreambleMd(struct vnt_private *pDevice)
--
1.8.1.2
^ permalink raw reply related
* [PATCH 09/13] staging: vt6656: clean up MACvEnableProtectMD
From: Malcolm Priestley @ 2013-06-05 20:44 UTC (permalink / raw)
To: gregkh; +Cc: linux-wireless
Remove internal white space and camel case.
Camel case changes;
pDevice -> priv
pbyData -> data
Functional change
CONTROLnsRequestOut Length = ARRAY_SIZE(data)
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
---
drivers/staging/vt6656/mac.c | 17 ++++++-----------
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/vt6656/mac.c b/drivers/staging/vt6656/mac.c
index d274cae..3e5c816 100644
--- a/drivers/staging/vt6656/mac.c
+++ b/drivers/staging/vt6656/mac.c
@@ -235,20 +235,15 @@ void MACvWriteBSSIDAddress(struct vnt_private *priv, u8 *addr)
MESSAGE_REQUEST_MACREG, ETH_ALEN, addr);
}
-void MACvEnableProtectMD(struct vnt_private *pDevice)
+void MACvEnableProtectMD(struct vnt_private *priv)
{
- u8 pbyData[2];
+ u8 data[2];
- pbyData[0] = EnCFG_ProtectMd;
- pbyData[1] = EnCFG_ProtectMd;
+ data[0] = EnCFG_ProtectMd;
+ data[1] = EnCFG_ProtectMd;
- CONTROLnsRequestOut(pDevice,
- MESSAGE_TYPE_WRITE_MASK,
- MAC_REG_ENCFG0,
- MESSAGE_REQUEST_MACREG,
- 2,
- pbyData
- );
+ CONTROLnsRequestOut(priv, MESSAGE_TYPE_WRITE_MASK, MAC_REG_ENCFG0,
+ MESSAGE_REQUEST_MACREG, ARRAY_SIZE(data), data);
}
void MACvDisableProtectMD(struct vnt_private *pDevice)
--
1.8.1.2
^ permalink raw reply related
* [PATCH 08/13] staging: vt6656: cleanup MACvWriteBSSIDAddress
From: Malcolm Priestley @ 2013-06-05 20:40 UTC (permalink / raw)
To: gregkh; +Cc: linux-wireless
Remove secondary buffer
Camel case changes;
pDevice -> priv
pbyEtherAddr -> addr
Functional change
point buffer to callers addr
addr is always ETH_ALEN length and check for NULL
CONTROLnsRequestOut Length = ETH_ALEN
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
---
drivers/staging/vt6656/mac.c | 22 +++++++---------------
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/vt6656/mac.c b/drivers/staging/vt6656/mac.c
index 673ed5d..d274cae 100644
--- a/drivers/staging/vt6656/mac.c
+++ b/drivers/staging/vt6656/mac.c
@@ -223,24 +223,16 @@ void MACvWriteWord(struct vnt_private *priv, u16 offset, u16 word)
offset, MESSAGE_REQUEST_MACREG, ARRAY_SIZE(data), data);
}
-void MACvWriteBSSIDAddress(struct vnt_private *pDevice, u8 *pbyEtherAddr)
+void MACvWriteBSSIDAddress(struct vnt_private *priv, u8 *addr)
{
- u8 pbyData[6];
- pbyData[0] = *((u8 *)pbyEtherAddr);
- pbyData[1] = *((u8 *)pbyEtherAddr+1);
- pbyData[2] = *((u8 *)pbyEtherAddr+2);
- pbyData[3] = *((u8 *)pbyEtherAddr+3);
- pbyData[4] = *((u8 *)pbyEtherAddr+4);
- pbyData[5] = *((u8 *)pbyEtherAddr+5);
+ if (!addr) {
+ pr_warn("%s addr is NULL\n", __func__);
+ return;
+ }
- CONTROLnsRequestOut(pDevice,
- MESSAGE_TYPE_WRITE,
- MAC_REG_BSSID0,
- MESSAGE_REQUEST_MACREG,
- 6,
- pbyData
- );
+ CONTROLnsRequestOut(priv, MESSAGE_TYPE_WRITE, MAC_REG_BSSID0,
+ MESSAGE_REQUEST_MACREG, ETH_ALEN, addr);
}
void MACvEnableProtectMD(struct vnt_private *pDevice)
--
1.8.1.2
^ permalink raw reply related
* [PATCH 07/13] staging: vt6656: clean up MACvWriteWord
From: Malcolm Priestley @ 2013-06-05 20:38 UTC (permalink / raw)
To: gregkh; +Cc: linux-wireless
Remove internal white space and camel case.
Camel case changes;
pDevice -> priv
byRegOfs -> offset
wData -> word
pbyData -> data
Functional change
CONTROLnsRequestOut Length = ARRAY_SIZE(data)
offset changed to u16 to match CONTROLnsRequestOut
Value size.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
---
drivers/staging/vt6656/mac.c | 18 ++++++------------
drivers/staging/vt6656/mac.h | 2 +-
2 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/vt6656/mac.c b/drivers/staging/vt6656/mac.c
index d690ef1..673ed5d 100644
--- a/drivers/staging/vt6656/mac.c
+++ b/drivers/staging/vt6656/mac.c
@@ -212,21 +212,15 @@ void MACvRegBitsOn(struct vnt_private *priv, u16 offset, u8 bits)
offset, MESSAGE_REQUEST_MACREG, ARRAY_SIZE(data), data);
}
-void MACvWriteWord(struct vnt_private *pDevice, u8 byRegOfs, u16 wData)
+void MACvWriteWord(struct vnt_private *priv, u16 offset, u16 word)
{
- u8 pbyData[2];
+ u8 data[2];
- pbyData[0] = (u8)(wData & 0xff);
- pbyData[1] = (u8)(wData >> 8);
-
- CONTROLnsRequestOut(pDevice,
- MESSAGE_TYPE_WRITE,
- byRegOfs,
- MESSAGE_REQUEST_MACREG,
- 2,
- pbyData
- );
+ data[0] = (u8)(word & 0xff);
+ data[1] = (u8)(word >> 8);
+ CONTROLnsRequestOut(priv, MESSAGE_TYPE_WRITE,
+ offset, MESSAGE_REQUEST_MACREG, ARRAY_SIZE(data), data);
}
void MACvWriteBSSIDAddress(struct vnt_private *pDevice, u8 *pbyEtherAddr)
diff --git a/drivers/staging/vt6656/mac.h b/drivers/staging/vt6656/mac.h
index 91964e8..b575d61 100644
--- a/drivers/staging/vt6656/mac.h
+++ b/drivers/staging/vt6656/mac.h
@@ -410,7 +410,7 @@ void MACvDisableKeyEntry(struct vnt_private *, u32);
void MACvSetKeyEntry(struct vnt_private *, u16, u32, u16, u8 *, u32 *);
void MACvRegBitsOff(struct vnt_private *, u16, u8);
void MACvRegBitsOn(struct vnt_private *, u16, u8);
-void MACvWriteWord(struct vnt_private *, u8, u16);
+void MACvWriteWord(struct vnt_private *, u16, u16);
void MACvWriteBSSIDAddress(struct vnt_private *, u8 *);
void MACvEnableProtectMD(struct vnt_private *);
void MACvDisableProtectMD(struct vnt_private *);
--
1.8.1.2
^ permalink raw reply related
* [PATCH 06/13] staging: vt6656: clean up MACvRegBitsOn
From: Malcolm Priestley @ 2013-06-05 20:33 UTC (permalink / raw)
To: gregkh; +Cc: linux-wireless
Remove internal white space and camel case.
Camel case changes;
pDevice -> priv
byRegOfs -> offset
byBits -> bits
pbyData -> data
Functional change
CONTROLnsRequestOut Length = ARRAY_SIZE(data)
offset changed to u16
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
---
drivers/staging/vt6656/mac.c | 17 ++++++-----------
drivers/staging/vt6656/mac.h | 2 +-
2 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/vt6656/mac.c b/drivers/staging/vt6656/mac.c
index 77ec057..d690ef1 100644
--- a/drivers/staging/vt6656/mac.c
+++ b/drivers/staging/vt6656/mac.c
@@ -201,20 +201,15 @@ void MACvRegBitsOff(struct vnt_private *priv, u16 offset, u8 bits)
offset, MESSAGE_REQUEST_MACREG, ARRAY_SIZE(data), data);
}
-void MACvRegBitsOn(struct vnt_private *pDevice, u8 byRegOfs, u8 byBits)
+void MACvRegBitsOn(struct vnt_private *priv, u16 offset, u8 bits)
{
- u8 pbyData[2];
+ u8 data[2];
- pbyData[0] = byBits;
- pbyData[1] = byBits;
+ data[0] = bits;
+ data[1] = bits;
- CONTROLnsRequestOut(pDevice,
- MESSAGE_TYPE_WRITE_MASK,
- byRegOfs,
- MESSAGE_REQUEST_MACREG,
- 2,
- pbyData
- );
+ CONTROLnsRequestOut(priv, MESSAGE_TYPE_WRITE_MASK,
+ offset, MESSAGE_REQUEST_MACREG, ARRAY_SIZE(data), data);
}
void MACvWriteWord(struct vnt_private *pDevice, u8 byRegOfs, u16 wData)
diff --git a/drivers/staging/vt6656/mac.h b/drivers/staging/vt6656/mac.h
index 4aa0f8d..91964e8 100644
--- a/drivers/staging/vt6656/mac.h
+++ b/drivers/staging/vt6656/mac.h
@@ -409,7 +409,7 @@ void MACvSetBBType(struct vnt_private *, u8);
void MACvDisableKeyEntry(struct vnt_private *, u32);
void MACvSetKeyEntry(struct vnt_private *, u16, u32, u16, u8 *, u32 *);
void MACvRegBitsOff(struct vnt_private *, u16, u8);
-void MACvRegBitsOn(struct vnt_private *, u8, u8);
+void MACvRegBitsOn(struct vnt_private *, u16, u8);
void MACvWriteWord(struct vnt_private *, u8, u16);
void MACvWriteBSSIDAddress(struct vnt_private *, u8 *);
void MACvEnableProtectMD(struct vnt_private *);
--
1.8.1.2
^ permalink raw reply related
* [PATCH 05/13] staging: vt6656: cleanup MACvRegBitsOff
From: Malcolm Priestley @ 2013-06-05 20:28 UTC (permalink / raw)
To: gregkh; +Cc: linux-wireless
Remove internal white space and camel case.
Camel case changes;
pDevice -> priv
byRegOfs -> offset
byBits -> bits
pbyData -> data
Functional change
CONTROLnsRequestOut Length = ARRAY_SIZE(data)
offset changed to u16
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
---
drivers/staging/vt6656/mac.c | 17 ++++++-----------
drivers/staging/vt6656/mac.h | 2 +-
2 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/vt6656/mac.c b/drivers/staging/vt6656/mac.c
index 56da5ef..77ec057 100644
--- a/drivers/staging/vt6656/mac.c
+++ b/drivers/staging/vt6656/mac.c
@@ -190,20 +190,15 @@ void MACvSetKeyEntry(struct vnt_private *priv, u16 key_ctl, u32 entry_idx,
}
-void MACvRegBitsOff(struct vnt_private *pDevice, u8 byRegOfs, u8 byBits)
+void MACvRegBitsOff(struct vnt_private *priv, u16 offset, u8 bits)
{
- u8 pbyData[2];
+ u8 data[2];
- pbyData[0] = 0;
- pbyData[1] = byBits;
+ data[0] = 0;
+ data[1] = bits;
- CONTROLnsRequestOut(pDevice,
- MESSAGE_TYPE_WRITE_MASK,
- byRegOfs,
- MESSAGE_REQUEST_MACREG,
- 2,
- pbyData
- );
+ CONTROLnsRequestOut(priv, MESSAGE_TYPE_WRITE_MASK,
+ offset, MESSAGE_REQUEST_MACREG, ARRAY_SIZE(data), data);
}
void MACvRegBitsOn(struct vnt_private *pDevice, u8 byRegOfs, u8 byBits)
diff --git a/drivers/staging/vt6656/mac.h b/drivers/staging/vt6656/mac.h
index 548ab3c..4aa0f8d 100644
--- a/drivers/staging/vt6656/mac.h
+++ b/drivers/staging/vt6656/mac.h
@@ -408,7 +408,7 @@ void MACbShutdown(struct vnt_private *);
void MACvSetBBType(struct vnt_private *, u8);
void MACvDisableKeyEntry(struct vnt_private *, u32);
void MACvSetKeyEntry(struct vnt_private *, u16, u32, u16, u8 *, u32 *);
-void MACvRegBitsOff(struct vnt_private *, u8, u8);
+void MACvRegBitsOff(struct vnt_private *, u16, u8);
void MACvRegBitsOn(struct vnt_private *, u8, u8);
void MACvWriteWord(struct vnt_private *, u8, u16);
void MACvWriteBSSIDAddress(struct vnt_private *, u8 *);
--
1.8.1.2
^ permalink raw reply related
* [PATCH 04/13] staging: vt6656: clean up MACvSetKeyEntry
From: Malcolm Priestley @ 2013-06-05 20:23 UTC (permalink / raw)
To: gregkh; +Cc: linux-wireless
Remove internal white space and camel case.
Camel case changes;
pDevice -> priv
uKeyIdx -> key_idx
pbyAddr -> addr
pdwKey -> key
uEntryIdx -> entry_idx
pbyKey -> ptr_key
wOffset -> offset
dwData1 -> data1
dwData2 -> data2
pbyData -> data
ii -> i
Functional change
Removed MAKEWORD macro
key_idx changed to u16
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
---
drivers/staging/vt6656/mac.c | 132 ++++++++++++++++++-------------------------
drivers/staging/vt6656/mac.h | 2 +-
2 files changed, 55 insertions(+), 79 deletions(-)
diff --git a/drivers/staging/vt6656/mac.c b/drivers/staging/vt6656/mac.c
index 13c15fa..56da5ef 100644
--- a/drivers/staging/vt6656/mac.c
+++ b/drivers/staging/vt6656/mac.c
@@ -125,92 +125,68 @@ void MACvDisableKeyEntry(struct vnt_private *priv, u32 entry_idx)
* Set the Key by MISCFIFO
*
* Parameters:
- * In:
- * dwIoBase - Base Address for MAC
+ * In:
+ * dwIoBase - Base Address for MAC
*
- * Out:
- * none
+ * Out:
+ * none
*
* Return Value: none
*
*/
-void MACvSetKeyEntry(struct vnt_private *pDevice, u16 wKeyCtl, u32 uEntryIdx,
- u32 uKeyIdx, u8 *pbyAddr, u32 *pdwKey)
+void MACvSetKeyEntry(struct vnt_private *priv, u16 key_ctl, u32 entry_idx,
+ u16 key_idx, u8 *addr, u32 *key)
{
- u8 *pbyKey;
- u16 wOffset;
- u32 dwData1, dwData2;
- int ii;
- u8 pbyData[24];
-
- if (pDevice->byLocalID <= MAC_REVISION_A1)
- if (pDevice->vnt_mgmt.byCSSPK == KEY_CTL_CCMP)
+ u8 data[24];
+ u8 *ptr_key;
+ u16 offset;
+ u32 data1, data2;
+ int i;
+
+ if (priv->byLocalID <= MAC_REVISION_A1)
+ if (priv->vnt_mgmt.byCSSPK == KEY_CTL_CCMP)
return;
- wOffset = MISCFIFO_KEYETRY0;
- wOffset += (uEntryIdx * MISCFIFO_KEYENTRYSIZE);
-
- dwData1 = 0;
- dwData1 |= wKeyCtl;
- dwData1 <<= 16;
- dwData1 |= MAKEWORD(*(pbyAddr+4), *(pbyAddr+5));
-
- DBG_PRT(MSG_LEVEL_DEBUG, KERN_INFO"1. wOffset: %d, Data: %X,"\
- " KeyCtl:%X\n", wOffset, dwData1, wKeyCtl);
-
- //VNSvOutPortW(dwIoBase + MAC_REG_MISCFFNDEX, wOffset);
- //VNSvOutPortD(dwIoBase + MAC_REG_MISCFFDATA, dwData);
- //VNSvOutPortW(dwIoBase + MAC_REG_MISCFFCTL, MISCFFCTL_WRITE);
-
- //wOffset++;
-
- dwData2 = 0;
- dwData2 |= *(pbyAddr+3);
- dwData2 <<= 8;
- dwData2 |= *(pbyAddr+2);
- dwData2 <<= 8;
- dwData2 |= *(pbyAddr+1);
- dwData2 <<= 8;
- dwData2 |= *(pbyAddr+0);
-
- DBG_PRT(MSG_LEVEL_DEBUG, KERN_INFO"2. wOffset: %d, Data: %X\n",
- wOffset, dwData2);
-
- //VNSvOutPortW(dwIoBase + MAC_REG_MISCFFNDEX, wOffset);
- //VNSvOutPortD(dwIoBase + MAC_REG_MISCFFDATA, dwData);
- //VNSvOutPortW(dwIoBase + MAC_REG_MISCFFCTL, MISCFFCTL_WRITE);
-
- //wOffset++;
-
- //wOffset += (uKeyIdx * 4);
-/* for (ii=0;ii<4;ii++) {
- // alway push 128 bits
- DBG_PRT(MSG_LEVEL_DEBUG, KERN_INFO"3.(%d) wOffset: %d, Data: %lX\n", ii, wOffset+ii, *pdwKey);
- VNSvOutPortW(dwIoBase + MAC_REG_MISCFFNDEX, wOffset+ii);
- VNSvOutPortD(dwIoBase + MAC_REG_MISCFFDATA, *pdwKey++);
- VNSvOutPortW(dwIoBase + MAC_REG_MISCFFCTL, MISCFFCTL_WRITE);
- }
-*/
- pbyKey = (u8 *)pdwKey;
-
- pbyData[0] = (u8)dwData1;
- pbyData[1] = (u8)(dwData1>>8);
- pbyData[2] = (u8)(dwData1>>16);
- pbyData[3] = (u8)(dwData1>>24);
- pbyData[4] = (u8)dwData2;
- pbyData[5] = (u8)(dwData2>>8);
- pbyData[6] = (u8)(dwData2>>16);
- pbyData[7] = (u8)(dwData2>>24);
- for (ii = 8; ii < 24; ii++)
- pbyData[ii] = *pbyKey++;
-
- CONTROLnsRequestOut(pDevice,
- MESSAGE_TYPE_SETKEY,
- wOffset,
- (u16)uKeyIdx,
- 24,
- pbyData
- );
+ offset = MISCFIFO_KEYETRY0;
+ offset += (entry_idx * MISCFIFO_KEYENTRYSIZE);
+
+ data1 = (u32)key_ctl;
+ data1 <<= 16;
+ data1 |= (u32)(*(addr + 5) << 8);
+ data1 |= (u32)*(addr + 4);
+
+ DBG_PRT(MSG_LEVEL_DEBUG, KERN_INFO
+ "1. offset: %d, data1: %X, key_ctl:%X\n",
+ offset, data1, key_ctl);
+
+ data2 = 0;
+ data2 |= *(addr + 3);
+ data2 <<= 8;
+ data2 |= *(addr + 2);
+ data2 <<= 8;
+ data2 |= *(addr + 1);
+ data2 <<= 8;
+ data2 |= *(addr);
+
+ DBG_PRT(MSG_LEVEL_DEBUG, KERN_INFO
+ "2. offset: %d, data2: %X\n", offset, data2);
+
+ ptr_key = (u8 *)key;
+
+ data[0] = (u8)data1;
+ data[1] = (u8)(data1 >> 8);
+ data[2] = (u8)(data1 >> 16);
+ data[3] = (u8)(data1 >> 24);
+ data[4] = (u8)data2;
+ data[5] = (u8)(data2 >> 8);
+ data[6] = (u8)(data2 >> 16);
+ data[7] = (u8)(data2 >> 24);
+
+ for (i = 8; i < 24; i++)
+ data[i] = *ptr_key++;
+
+ CONTROLnsRequestOut(priv, MESSAGE_TYPE_SETKEY,
+ offset, key_idx, ARRAY_SIZE(data), data);
}
diff --git a/drivers/staging/vt6656/mac.h b/drivers/staging/vt6656/mac.h
index f0cecc9..548ab3c 100644
--- a/drivers/staging/vt6656/mac.h
+++ b/drivers/staging/vt6656/mac.h
@@ -407,7 +407,7 @@ void MACvWriteMultiAddr(struct vnt_private *, u16, u8);
void MACbShutdown(struct vnt_private *);
void MACvSetBBType(struct vnt_private *, u8);
void MACvDisableKeyEntry(struct vnt_private *, u32);
-void MACvSetKeyEntry(struct vnt_private *, u16, u32, u32, u8 *, u32 *);
+void MACvSetKeyEntry(struct vnt_private *, u16, u32, u16, u8 *, u32 *);
void MACvRegBitsOff(struct vnt_private *, u8, u8);
void MACvRegBitsOn(struct vnt_private *, u8, u8);
void MACvWriteWord(struct vnt_private *, u8, u16);
--
1.8.1.2
^ permalink raw reply related
* Re: [bcmdhd] Retransmission packet
From: Matteo @ 2013-06-05 20:21 UTC (permalink / raw)
To: Arend van Spriel; +Cc: brcm80211-dev-list, linux-wireless
In-Reply-To: <51AF3CEA.1000409@broadcom.com>
Yes, on Android. From my point of view is hard to find a tablet/smartphone with a driver supports ad-hoc mode.
With the driver b43 driver and ath5k I could find the retx count.
Do you know any website where I can find the chipset on board smartphones and tablets?
Thanks
Matteo
On Jun 5, 2013, at 3:28 PM, "Arend van Spriel" <arend@broadcom.com> wrote:
> + linux-wireless
>
> On 06/05/2013 02:04 PM, Matteo wrote:
>> Hi Arend,
>> thank a lot.
>>
>> yea, I wanted to find the retransmissions of the frame over the air.
>> I don't know, if other devices (broadcom or atheros) could give that information.
>
> On Android? I guess any mac80211 based driver could give you that information. The information is provided by the driver to mac80211 upon txstatus using struct ieee80211_tx_info::status. The rates field should contain the rates at which the transmits were attempted and how often (see explanation of struct ).
>
> Regards,
> Arend
>
>> Thanks again
>> Matteo
>>
>> On Jun 5, 2013, at 10:50 AM, "Arend van Spriel" <arend@broadcom.com> wrote:
>>
>>> - linux-wireless@vger.kernel.org
>>>
>>> bcmdhd is not an upstream linux driver so removing that mailing list address.
>>>
>>> On 06/04/2013 11:20 PM, Matteo Danieletto wrote:
>>>> Hi all,
>>>>
>>>> I am trying to extract the number of retransmissions frame occur during
>>>> data transfer between two nodes.
>>>
>>> I suppose you want the know the retransmissions of the frame over the air. The retries in the code below are over the bus between host and device. So that is not the information you want (right?).
>>>
>>> The bad news is that the information is not available in the driver.
>>>
>>> Regards,
>>> Arend
>>>
>>>> I found in did_sdio.c this function:
>>>>
>>>> 1. /* Writes a HW/SW header into the packet and sends it. */
>>>> 2. /* Assumes: (a) header space already there, (b) caller holds lock */
>>>> 3. staticint
>>>> 4. dhdsdio_txpkt(dhd_bus_t *bus,void*pkt,uint chan,boolfree_pkt)
>>>>
>>>>
>>>> .
>>>> .
>>>> .
>>>> there is this part:
>>>>
>>>> 1. do{
>>>> 2. ret
>>>> =dhd_bcmsdh_send_buf(bus,bcmsdh_cur_sbwad(sdh),SDIO_FUNC_2,F2SYNC,
>>>> 3. frame,len,pkt,NULL,NULL);
>>>> 4. bus->f2txdata++;
>>>> 5. ASSERT(ret !=BCME_PENDING);
>>>> 6.
>>>>
>>>> 7. if(ret <0){
>>>> 8. /* On failure, abort the command and terminate the frame */
>>>> 9. DHD_INFO(("%s: sdio error %d, abort command
>>>> and terminate frame.\n",
>>>> 10. __FUNCTION__,ret));
>>>> 11. bus->tx_sderrs++;
>>>> 12.
>>>>
>>>> 13. bcmsdh_abort(sdh,SDIO_FUNC_2);
>>>> 14.
>>>> bcmsdh_cfg_write(sdh,SDIO_FUNC_1,SBSDIO_FUNC1_FRAMECTRL,
>>>> 15. SFC_WF_TERM,NULL);
>>>> 16. bus->f1regdata++;
>>>> 17.
>>>>
>>>> 18. for(i =0;i <3;i++){
>>>> 19. uint8 hi,lo;
>>>> 20. hi =bcmsdh_cfg_read(sdh,SDIO_FUNC_1,
>>>> 21.
>>>> SBSDIO_FUNC1_WFRAMEBCHI,NULL);
>>>> 22. lo =bcmsdh_cfg_read(sdh,SDIO_FUNC_1,
>>>> 23.
>>>> SBSDIO_FUNC1_WFRAMEBCLO,NULL);
>>>> 24. bus->f1regdata +=2;
>>>> 25. if((hi ==0)&&(lo ==0))
>>>> 26. break;
>>>> 27. }
>>>> 28.
>>>>
>>>> 29. }
>>>> 30. if(ret ==0){
>>>> 31. bus->tx_seq =(bus->tx_seq
>>>> +1)%SDPCM_SEQUENCE_WRAP;
>>>> 32. }
>>>> 33. }while((ret <0)&&retrydata &&retries++<TXRETRIES);
>>>>
>>>>
>>>>
>>>> I exploited iperf to create a data stream between two nodes, but it
>>>> never occurred an incrementation of retries variable, then everytime
>>>> did_bcmsdh_send_buf returned 0.
>>>>
>>>> So, I don't know if it is the right point to extract this information
>>>> and it never occurred a retransmission, or more it is not possible
>>>> extract what I want.
>>>>
>>>> Thanks a lot
>>>>
>>>> Matteo
>>>>
>>>>
>>>
>>>
>>
>>
>
>
^ permalink raw reply
* [PATCH 03/13] staging: vt6656: clean up MACvDisableKeyEntry
From: Malcolm Priestley @ 2013-06-05 20:16 UTC (permalink / raw)
To: gregkh; +Cc: linux-wireless
Remove internal white space and camel case.
Camel case changes;
pDevice -> priv
uEntryIdx -> entry_idx
byData -> data
Removed wOffset and dead code
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
---
drivers/staging/vt6656/mac.c | 34 ++++++++++------------------------
1 file changed, 10 insertions(+), 24 deletions(-)
diff --git a/drivers/staging/vt6656/mac.c b/drivers/staging/vt6656/mac.c
index 0f8132b8..13c15fa 100644
--- a/drivers/staging/vt6656/mac.c
+++ b/drivers/staging/vt6656/mac.c
@@ -98,40 +98,26 @@ void MACvSetBBType(struct vnt_private *priv, u8 type)
/*
* Description:
- * Disable the Key Entry by MISCFIFO
+ * Disable the Key Entry
*
* Parameters:
- * In:
- * dwIoBase - Base Address for MAC
+ * In:
+ * entry_idx - Base Address for MAC
*
- * Out:
- * none
+ * Out:
+ * none
*
* Return Value: none
*
*/
-void MACvDisableKeyEntry(struct vnt_private *pDevice, u32 uEntryIdx)
+void MACvDisableKeyEntry(struct vnt_private *priv, u32 entry_idx)
{
- u16 wOffset;
- u8 byData;
-
- byData = (u8) uEntryIdx;
+ u8 data;
- wOffset = MISCFIFO_KEYETRY0;
- wOffset += (uEntryIdx * MISCFIFO_KEYENTRYSIZE);
-
- //VNSvOutPortW(dwIoBase + MAC_REG_MISCFFNDEX, wOffset);
- //VNSvOutPortD(dwIoBase + MAC_REG_MISCFFDATA, 0);
- //VNSvOutPortW(dwIoBase + MAC_REG_MISCFFCTL, MISCFFCTL_WRITE);
+ data = (u8)entry_idx;
- //issue write misc fifo command to device
- CONTROLnsRequestOut(pDevice,
- MESSAGE_TYPE_CLRKEYENTRY,
- 0,
- 0,
- 1,
- &byData
- );
+ CONTROLnsRequestOut(priv, MESSAGE_TYPE_CLRKEYENTRY,
+ 0, 0, sizeof(u8), &data);
}
/*
--
1.8.1.2
^ permalink raw reply related
* [PATCH 02/13] staging: vt6656: clean up MACvSetBBType
From: Malcolm Priestley @ 2013-06-05 20:15 UTC (permalink / raw)
To: gregkh; +Cc: linux-wireless
Remove internal white space and camel case.
Camel case changes;
pDevice -> priv
pbyData -> data
byType -> type
Functional change
CONTROLnsRequestOut Length = ARRAY_SIZE(data)
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
---
drivers/staging/vt6656/mac.c | 18 +++++++-----------
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/vt6656/mac.c b/drivers/staging/vt6656/mac.c
index 89d700f..0f8132b8 100644
--- a/drivers/staging/vt6656/mac.c
+++ b/drivers/staging/vt6656/mac.c
@@ -84,20 +84,16 @@ void MACbShutdown(struct vnt_private *pDevice)
);
}
-void MACvSetBBType(struct vnt_private *pDevice, u8 byType)
+void MACvSetBBType(struct vnt_private *priv, u8 type)
{
- u8 pbyData[2];
+ u8 data[2];
- pbyData[0] = byType;
- pbyData[1] = EnCFG_BBType_MASK;
+ data[0] = type;
+ data[1] = EnCFG_BBType_MASK;
- CONTROLnsRequestOut(pDevice,
- MESSAGE_TYPE_WRITE_MASK,
- MAC_REG_ENCFG0,
- MESSAGE_REQUEST_MACREG,
- 2,
- pbyData
- );
+ CONTROLnsRequestOut(priv, MESSAGE_TYPE_WRITE_MASK,
+ MAC_REG_ENCFG0, MESSAGE_REQUEST_MACREG,
+ ARRAY_SIZE(data), data);
}
/*
--
1.8.1.2
^ permalink raw reply related
* [PATCH 01/13] staging: vt6656: cleanup MACvWriteMultiAddr
From: Malcolm Priestley @ 2013-06-05 20:13 UTC (permalink / raw)
To: gregkh; +Cc: linux-wireless
Remove internal white space and camel case.
Camel case changes;
pDevice -> priv
uByteidx -> byte_idx
byData -> data
Functional change secondary buffer byData1 removed.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
---
drivers/staging/vt6656/mac.c | 24 +++++++++---------------
drivers/staging/vt6656/mac.h | 2 +-
2 files changed, 10 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/vt6656/mac.c b/drivers/staging/vt6656/mac.c
index 343db19..89d700f 100644
--- a/drivers/staging/vt6656/mac.c
+++ b/drivers/staging/vt6656/mac.c
@@ -46,26 +46,20 @@ static int msglevel =MSG_LEVEL_INFO;
* Write MAC Multicast Address Mask
*
* Parameters:
- * In:
- * uByteidx - Index of Mask
- * byData - Mask Value to write
- * Out:
- * none
+ * In:
+ * byte_idx - Index of Mask
+ * data- Mask Value to write
+ * Out:
+ * none
*
* Return Value: none
*
*/
-void MACvWriteMultiAddr(struct vnt_private *pDevice, u32 uByteIdx, u8 byData)
+void MACvWriteMultiAddr(struct vnt_private *priv, u16 byte_idx, u8 data)
{
- u8 byData1;
-
- byData1 = byData;
- CONTROLnsRequestOut(pDevice,
- MESSAGE_TYPE_WRITE,
- (u16) (MAC_REG_MAR0 + uByteIdx),
- MESSAGE_REQUEST_MACREG,
- 1,
- &byData1);
+ CONTROLnsRequestOut(priv, MESSAGE_TYPE_WRITE,
+ (u16)(MAC_REG_MAR0 + byte_idx), MESSAGE_REQUEST_MACREG,
+ sizeof(data), &data);
}
/*
diff --git a/drivers/staging/vt6656/mac.h b/drivers/staging/vt6656/mac.h
index 0db1be5..f0cecc9 100644
--- a/drivers/staging/vt6656/mac.h
+++ b/drivers/staging/vt6656/mac.h
@@ -403,7 +403,7 @@
#define MAC_REVISION_A0 0x00
#define MAC_REVISION_A1 0x01
-void MACvWriteMultiAddr(struct vnt_private *, u32, u8);
+void MACvWriteMultiAddr(struct vnt_private *, u16, u8);
void MACbShutdown(struct vnt_private *);
void MACvSetBBType(struct vnt_private *, u8);
void MACvDisableKeyEntry(struct vnt_private *, u32);
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH 1/2] rt2x00: convert rt2x00_ops.extra_tx_headroom to be a fuction
From: Gabor Juhos @ 2013-06-05 19:58 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: John Linville, linux-wireless, users
In-Reply-To: <20130605125130.GA3367@redhat.com>
2013.06.05. 14:51 keltezéssel, Stanislaw Gruszka írta:
> On Wed, Jun 05, 2013 at 12:53:59PM +0200, Gabor Juhos wrote:
>> The rt2x00_ops structure has a static field to indicate
>> the extra TX headroom size required for a given device.
>> The drawback of this is that we have to use a separate
>> rt2x00_ops structure for each chipset which requires
>> different size.
>>
>> Convert the static field into a callback function.
>> This allows the drivers to dynamically determine the
>> extra TX headroom size based on the actual chipset.
>> Also implement the the callback in the drivers which
>> needs an extra TX headroom, and remove the field
>> initialization from the others.
>>
>> Additionally, introduce a new extra_tx_headroom field
>> in struct rt2x00_dev, initialize its value in the probe
>> routine and use the cached value in the rest of the code.
>
> Could we rather get rid of that extra_tx_headroom variable and use queue
> parameters: winfo_size and desc_size ?
Yes, it seems that we can compute the value of extra_tx_headrom from those
fields. The driver uses the following values now:
driver/device desc_size winfo_size extra_tx_headroom
rt2400pci TXD_DESC_SIZE 0 0
rt2500pci TXD_DESC_SIZE 0 0
rt2800pci TXD_DESC_SIZE TXWI_DESC_SIZE TXWI_DESC_SIZE
rt61pci TXD_DESC_SIZE 0 0
rt2500usb TXD_DESC_SIZE 0 TXD_DESC_SIZE
rt2800usb TXINFO_DESC_SIZE TXWI_DESC_SIZE TXINFO_DESC_SIZE +
TXWI_DESC_SIZE
rt2800usb/RT5592 TXINFO_DESC_SIZE TXWI_DESC_SIZE_5592 TXINFO_DESC_SIZE +
TXWI_DESC_SIZE_5592
rt73usb TXD_DESC_SIZE 0 TXD_DESC_SIZE
On USB devices we can get it from desc_size + winfo_size and on PCI/PCIe/SoC
devices it equals with winfo_size. So the callbacks and the extra_tx_headroom
field in rt2x00_ops can be removed.
However I would keep the new extra_tx_headroom field in rt2x00_dev. It would
ensure that we don't have to compute its value every time it is used.
-Gabor
^ permalink raw reply
* Re: cw1200: add driver for the ST-E CW1100 & CW1200 WLAN chipsets
From: Solomon Peachy @ 2013-06-05 19:11 UTC (permalink / raw)
To: Kalle Valo; +Cc: Dan Carpenter, linux-wireless
In-Reply-To: <87vc5s3i24.fsf@purkki.adurom.net>
[-- Attachment #1: Type: text/plain, Size: 1707 bytes --]
On Wed, Jun 05, 2013 at 02:36:51PM +0300, Kalle Valo wrote:
> What do you mean with bring up netdev? I don't understand.
>
> Even now you call ieee80211_register_hw() before cw1200_debug_init(). At
> least from a quick look I don't see any technical reason why you can't
> use testmode (unless I'm missing something).
A dozen-ish lines above the call to ieee80211_register_hw() you'll see:
#ifdef CONFIG_CW1200_ETF
if (etf_mode)
goto done;
#endif
In other words, when in that debugging-only mode, the device never
gets registered.
> We have been working hard to get rid of all sort ugly driver specific
> interfaces. If you don't want to use the proper interface then I guess
> it's better to remove the custom debugfs interface from cw1200.
It's not a matter of not wanting to use the proper interface so much as
having to pick my battles. (I no longer have access to the vendor
tools, nor am I inclined to spend my free time hacking on something
end-users aren't going to need)
I'm fine with the ETF support getting stripped out of the mainline. In
the shorter term it can live as an out-of-tree patch; in the longer term
it can be implemented properly using the nl80211_testmode hooks.
Meanwhile, there's a second debugfs interface ("itp") in the cw1200
driver that basically implements a continuous tx/rx function on top of
regular production firmware. This should probably just go as well.
I'll prepare a couple of patches to do this.
- Solommon
--
Solomon Peachy pizza at shaftnet dot org
Delray Beach, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum viditur.
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: carl9170:5/10 MHz Channel Support on carl9170
From: Adrian Chadd @ 2013-06-05 18:08 UTC (permalink / raw)
To: C.B. Wang; +Cc: Christian Lamparter, linux-wireless
In-Reply-To: <CAB-Tk73mTDsvf+MCEq5xfUBUtE4c6KfL2nkAcZe2LCY5pF=7RQ@mail.gmail.com>
I think that the zydas mac doesn't officially support 5/10mhz operation.
I don't know how it's supposed to.
As for the alternate frequencies - it all depends what it's calibrated
for. The PHY and radio support whatever the AR5416/AR9160 do (as
they're the same PHY/radio), but it does depend if the board design
and calibration has been done with those frequencies in mind.
So by default, please, leave them off. :-)
adrian
On 5 June 2013 05:59, C.B. Wang <wtwangcb@gmail.com> wrote:
> Hi
>
> I've read the "otus" vendor driver and found that in the source file
> /HalPlus/OTUS_FB50/hpreg.h on
> line 1915,the comment says "Temporary discard channel that BW < 20MHz
> (5 or 10MHz) */
> /* Our architecture does not implemnt it"
> I think either the driver does not implement the 5/10 channels or
> worse,the ar9170 chip does
> not support 5/10 mhz channel at all.
> But 802.11j has 10mhz channel support.To comply with the 802.11j
> standard,the chip should
> support 10mhz channel width.
>
> I know ar9170 support 4.9ghz channels.But does it also support
> non-standard bands like 2.3ghz and 6.0ghz?
>
> Also the ar9170 MAC was indeed designed by ZyDaS berfore the company
> was taken over by
> Atheros.It has some problems with long distance links.
>
> On 6/5/13, Christian Lamparter <chunkeey@googlemail.com> wrote:
>> On Tuesday, June 04, 2013 03:20:26 PM C.B. Wang wrote:
>>> I want to know if the ar9170 chip support 5/10 mhz channels.
>> Maybe. if you care about it, you'll have to look for clues in
>> the original vendor driver (otus - was part of the kernel's staging/
>> directory for < 2.6.39?) and the original vendor firmware
>> (ar9170fw - you can find a git-tree @ git.sipsolutions.com).
>>
>> Anyway, if you need a definitive "yes" or "no", you should
>> ask Qualcomm Atheros directly. As I can only tell something
>> about the MAC [which does have a 802.11j Mode. It can be
>> enabled by setting bit 3 in AR9170_MAC_REG_POWER_STATE_CTRL.]
>> However, I don't have any information about the PHY/FEM/RF
>> and BB.
>>
>>> The datasheet says it supports 802.11j, but the carl9170
>>> driver does not provide support.
>> Again, talk to Qualcomm Atheros to find out what needs to be
>> done in order to support it.
>>
>>> Also the radio chip ar9104 has tuning range from 2.3-2.5ghz and
>>> 4.9-6.1ghz,but the driver does not provide any support for these
>>> super channels.
>> Some AR9170 devices do indeed support the 4.9 GHz channels
>> (out of the box). e.g.:
>> Frequencies:
>> * 4920 MHz [-16] (18.0 dBm)
>> * 4940 MHz [-12] (18.0 dBm)
>> * 4960 MHz [-8] (18.0 dBm)
>> * 4980 MHz [-4] (18.0 dBm)
>> * 5040 MHz [8] (18.0 dBm)
>> * 5060 MHz [12] (18.0 dBm)
>> * 5080 MHz [16] (18.0 dBm)
>>
>> However, the device needs to be calibrated for the frequencies
>> to use them legally (the Japanese Market). Look in your kernel
>> logs when the driver is loaded; There should be something like
>> this:
>>
>>> ath: EEPROM regdomain: 0x8xyz
>>> ath: EEPROM indicates we should expect a country code
>>> ath: doing EEPROM country->regdmn map search
>>> ath: Country alpha2 being used: JP <--- JaPan
>>
>> If your country code is not "JP", then you'll have to talk to
>> the manufacturer.
>>
>> Regards,
>> Chr
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ath9k_htc: fix skb_under_panic error
From: Oleksij Rempel @ 2013-06-05 17:03 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: Helmut Schaa, linux-wireless, ath9k-devel
In-Reply-To: <51AF4F35.50503@rempel-privat.de>
Am 05.06.2013 16:46, schrieb Oleksij Rempel:
> Am 05.06.2013 16:26, schrieb Marc Kleine-Budde:
>> On 06/05/2013 04:24 PM, Helmut Schaa wrote:
>>> On Tue, Jun 4, 2013 at 8:37 PM, Oleksij Rempel
>>> <linux@rempel-privat.de> wrote:
>>>> This error seems to be really rare, and we do not know real couse of
>>>> it.
>>>> But, in any case, we should check size of head before reducing it.
>>>
>>> Mind to try the (completely untested) patch against wireless-testing
>>> instead?
>>> Helmut
>>
>> I will do, however I'm not in range of that USB wireless adapter for
>> about 1,5 weeks.
>
> Helmut, thank you for patch!
>
> i'll do regression test, but not week long test. So i probably won't
> reproduce this issue.
I was running two stream netperf test for 2 hours without visible
regressions.
--
Regards,
Oleksij
^ permalink raw reply
* Re: [PATCHv4 2/4] brcm80211: make mgmt_tx in brcmfmac accept a NULL channel
From: Antonio Quartulli @ 2013-06-05 16:58 UTC (permalink / raw)
To: Johannes Berg
Cc: Arend van Spriel, Antonio Quartulli,
linux-wireless@vger.kernel.org, brcm80211-dev-list@broadcom.com
In-Reply-To: <1370446810.25710.6.camel@jlt4.sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]
iOn Wed, Jun 05, 2013 at 08:40:10AM -0700, Johannes Berg wrote:
> On Wed, 2013-06-05 at 17:35 +0200, Arend van Spriel wrote:
> > On 06/05/2013 05:34 PM, Arend van Spriel wrote:
> > > On 06/05/2013 05:09 PM, Antonio Quartulli wrote:
> > >> From: Antonio Quartulli <antonio@open-mesh.com>
> > >>
> > >> cfg80211 passes a NULL channel to mgmt_tx if the frame has
> > >> to be sent on the one currently in use by the device.
> > >> Make the implementation of mgmt_tx correctly handle this
> > >> case
> > >>
> > >> Cc: Arend van Spriel <arend@broadcom.com>
> > >> Cc: brcm80211-dev-list@broadcom.com
> > >> Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
> > >> ---
> > >
> > > For my name above you (or Johannes) can change 'Cc:' to 'Acked-by:'
> >
> > Or John?
>
> I think I'll take the whole series if that's ok with everyone, otherwise
> we get synchronisation issues between John and myself :)
>
Yeah, I think that's the best option.
Thanks everybody!
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: wireless tree rebased (from 5/28), Broadcom bits dropped
From: Arend van Spriel @ 2013-06-05 16:57 UTC (permalink / raw)
To: John W. Linville
Cc: Johannes Berg, linux-wireless, Samuel Ortiz, Gustavo Padovan,
Luciano Coelho
In-Reply-To: <20130605143700.GA2271@tuxdriver.com>
On 06/05/2013 04:37 PM, John W. Linville wrote:
> On Wed, Jun 05, 2013 at 08:59:46AM +0200, Johannes Berg wrote:
>> On Tue, 2013-06-04 at 17:53 -0400, John W. Linville wrote:
>>> I messed this up too -- bad day...
>>>
>>> If you pulled in between the earlier message and this one, please
>>> do so again. If you saw this message before taking any action to
>>> clean-up my mess, then you are OK.
>>
>> This was confusing, I think you rebased around some merges instead of
>> redoing the merges? My patches are in, but suddenly got new commit IDs,
>> e.g. fa331699d05ce1d0d4896eb4a137cfae50d7afde (new) vs.
>> c2c15e215e860c99b86ddfc4be4bb25cf180fed0 for "mac80211: work around
>> broken APs not including HT info".
>>
>> This will cause git to pull them in again when I send a new pull
>> request, so it would have been nicer to redo the merges, but anyway ...
>> just a heads-up for everyone that here it's a bit confusing now.
>>
>> johannes
>
> You are right, I could have done it better with regard to your tree.
> I probably should redo that part.
>
> The Bluetooth tree had pulled the wireless tree and applied their
> patches on top of the brcmfmac/brcmsmac series that I removed. So,
> their pull couldn't be redone.
>
> I think I can fix the wireless tree and preserve the original mac80211
> tree commits. Everyone please hold off on doing anything else here, as
> I'm a bit busy and won't be able to get to this before this afternoon
> (Eastern USA time).
>
> Anyone object to one more wireless tree rebase today?
Sorry, John
I feel your pain and I guess I should. Another lesson learned.
Gr. AvS
^ permalink raw reply
* Re: wireless tree rebased (from 5/28), Broadcom bits dropped
From: Gustavo Padovan @ 2013-06-05 16:49 UTC (permalink / raw)
To: John W. Linville
Cc: Johannes Berg, linux-wireless, Samuel Ortiz, Luciano Coelho
In-Reply-To: <20130605143700.GA2271@tuxdriver.com>
* John W. Linville <linville@tuxdriver.com> [2013-06-05 10:37:01 -0400]:
> On Wed, Jun 05, 2013 at 08:59:46AM +0200, Johannes Berg wrote:
> > On Tue, 2013-06-04 at 17:53 -0400, John W. Linville wrote:
> > > I messed this up too -- bad day...
> > >
> > > If you pulled in between the earlier message and this one, please
> > > do so again. If you saw this message before taking any action to
> > > clean-up my mess, then you are OK.
> >
> > This was confusing, I think you rebased around some merges instead of
> > redoing the merges? My patches are in, but suddenly got new commit IDs,
> > e.g. fa331699d05ce1d0d4896eb4a137cfae50d7afde (new) vs.
> > c2c15e215e860c99b86ddfc4be4bb25cf180fed0 for "mac80211: work around
> > broken APs not including HT info".
> >
> > This will cause git to pull them in again when I send a new pull
> > request, so it would have been nicer to redo the merges, but anyway ...
> > just a heads-up for everyone that here it's a bit confusing now.
> >
> > johannes
>
> You are right, I could have done it better with regard to your tree.
> I probably should redo that part.
>
> The Bluetooth tree had pulled the wireless tree and applied their
> patches on top of the brcmfmac/brcmsmac series that I removed. So,
> their pull couldn't be redone.
The Bluetooth commit IDs have changed too, but I just did a rebase on top
your tree and it is all set here now. I'll wait for your rebase today and see
how things goes.
Gustavo
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox