Re: MediaTek WiFi hardware support in upstream kernel
This is sorely needed given the miserable state of wifi drivers in the Linux kernel. Kernel maintainers, can this be pushed to mainline? It's not a vendor driver after all, and it uses nl80211 instead of WEXT. Regards, Etna On 26/02/15 22:40, Jakub Kiciński wrote: On Thu, 26 Feb 2015 14:56:46 +0100, poma wrote: On 06.02.2015 18:29, Jakub Kiciński wrote: Hello everyone! I put together a mac80211 driver for Mediatek MT7601U. It's partially based on Felix's mt76, but I'm not sure if it will make sense to merge the two together. MT7601U is a pretty old 1x1 bgn chip for USB dongles and mt76 now only supports the latest and greatest ac APs. I'm testing STA functionality right now and it seems to be working ok. The code is very much a work in progress but if anyone is interested you can get it here: https://github.com/kuba-moo/mt7601uCheers, kuba -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.orgMore majordomo info at http://vger.kernel.org/majordomo-info.html How many mt7601u module editions exists there? :) - vendor's - vendor's patched (how many forms of the same) - your reinvented - the one on which pán Gruszka allegedly works? - any more? I assume you mean to ask how many different drivers are there. There is the vendor 3.0.0.4 STA driver which only has client functionality. Many patched versions of this driver exist on GitHub. There is also an older version of vendor driver which can work as an AP. My mac80211-based driver is the only non-vendor version I'm aware of. -- 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 16/16] NFC: pn533: fix error return code
Return a negative error code on failure.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret = 0
)
... when != ret = e1
when != &ret
*if(...)
{
... when != ret = e2
when forall
return ret;
}
//
Signed-off-by: Julia Lawall
---
drivers/nfc/pn533.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/nfc/pn533.c b/drivers/nfc/pn533.c
index d46a700..732e607 100644
--- a/drivers/nfc/pn533.c
+++ b/drivers/nfc/pn533.c
@@ -2554,8 +2554,10 @@ static int pn533_data_exchange_complete(struct pn533
*dev, void *_arg,
}
skb = pn533_build_response(dev);
- if (!skb)
+ if (!skb) {
+ rc = -ENOMEM;
goto error;
+ }
arg->cb(arg->cb_context, skb, 0);
kfree(arg);
--
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 0/16] fix error return code
The complate semantic patch that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
//
@ok exists@
identifier f,ret,i;
expression e;
constant c;
@@
// identify a function that returns a negative return value at least once.
f(...) {
... when any
(
return -c@i;
|
ret = -c@i;
... when != ret = e
return ret;
|
if (ret < 0) { ... return ret; }
)
... when any
}
@r exists@
identifier ret,ok.f,fn;
expression e1,e2,e3,e4,e5,e6,x;
statement S,S1;
position p1,p2,p3;
@@
// identify a case where the return variable is set to a non-negative value
// and then returned in error-handling code
f(...) {
... when any
(
if@p1 (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret@p1 = 0
)
... when != \(ret = e1\|ret++\|ret--\|ret+=e1\|ret-=e1\)
when != &ret
when any
(
if (<+... ret = e5 ...+>) S1
|
if (<+... &ret ...+>) S1
|
if@p2(<+...x = fn(...)...+>)
{
... when != ret = e6
when forall
return@p3 ret;
}
|
break;
|
x = fn(...)
... when != \(ret = e4\|ret++\|ret--\|ret+=e4\|ret-=e4\)
when != &ret
(
if (<+... ret = e3 ...+>) S
|
if (<+... &ret ...+>) S
|
if@p2(<+...\(x != 0\|x < 0\|x == NULL\|IS_ERR(x)\)...+>)
{
... when != ret = e2
when forall
return@p3 ret;
}
)
)
... when any
}
@printer depends on r@
position p;
identifier ok.f,pr;
constant char [] c;
@@
f(...) { <...pr@p(...,c,...)...> }
@bad0 exists@
identifier r.ret,ok.f,g != {ERR_PTR,IS_ERR};
position p != printer.p;
@@
f(...) { ... when any
g@p(...,ret,...)
... when any
}
@bad depends on !bad0 exists@
position r.p1,r.p2;
statement S1,S2;
identifier r.ret;
expression e1;
@@
// ignore the above if there is some path where the variable is set to
// something else
(
if@p1 (\(ret < 0\|ret != 0\)) S1
|
ret@p1 = 0
)
... when any
\(ret = e1\|ret++\|ret--\|ret+=e1\|ret-=e1\|&ret\)
... when any
if@p2(...) S2
@bad1 depends on !bad0 && !bad exists@
position r.p2;
statement S2;
identifier r.ret;
expression e1;
constant c;
@@
ret = -c
... when != \(ret = e1\|ret++\|ret--\|ret+=e1\|ret-=e1\)
when != &ret
when any
if@p2(...) S2
@bad2 depends on !bad0 && !bad && !bad1 exists@
position r.p1,r.p2;
identifier r.ret;
expression e1;
statement S2;
constant c;
@@
// likewise ignore it if there has been an intervening return
ret@p1 = 0
... when != if (...) { ... ret = e1 ... return ret; }
when != if (...) { ... return -c; }
when any
if@p2(...) S2
@script:python depends on !bad0 && !bad && !bad1 && !bad2@
p1 << r.p1;
p2 << r.p2;
p3 << r.p3;
@@
cocci.print_main("",p1)
cocci.print_secs("",p2)
cocci.print_secs("",p3)
//
--
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] ssb: add delay after PCI reset to fix SoC reboots
Signed-off-by: Rafał Miłecki --- Kalle: this bug is there since ever, I guess this patch can be queued for next. --- drivers/ssb/driver_pcicore.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/ssb/driver_pcicore.c b/drivers/ssb/driver_pcicore.c index d75b72b..15a7ee3 100644 --- a/drivers/ssb/driver_pcicore.c +++ b/drivers/ssb/driver_pcicore.c @@ -357,6 +357,15 @@ static void ssb_pcicore_init_hostmode(struct ssb_pcicore *pc) pcicore_write32(pc, SSB_PCICORE_SBTOPCI2, SSB_PCICORE_SBTOPCI_MEM | SSB_PCI_DMA); + /* +* Accessing PCI config without a proper delay after devices reset (not +* GPIO reset) was causing reboots on WRT300N v1.0. +* Tested delay 850 us lowered reboot chance to 50-80%, 1000 us fixed it +* completely. Flushing all writes was also tested but with no luck. +*/ + if (pc->dev->bus->chip_id == 0x4704) + usleep_range(1000, 2000); + /* Enable PCI bridge BAR0 prefetch and burst */ val = PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY; ssb_extpci_write_config(pc, 0, 0, 0, PCI_COMMAND, &val, 2); -- 1.8.4.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
Re: [PATCH 16/16] NFC: pn533: fix error return code
Hi Julia,
On Sun, Apr 05, 2015 at 02:06:36PM +0200, Julia Lawall wrote:
> Return a negative error code on failure.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> //
> @@
> identifier ret; expression e1,e2;
> @@
> (
> if (\(ret < 0\|ret != 0\))
> { ... return ret; }
> |
> ret = 0
> )
> ... when != ret = e1
> when != &ret
> *if(...)
> {
> ... when != ret = e2
> when forall
> return ret;
> }
> //
>
> Signed-off-by: Julia Lawall
>
> ---
> drivers/nfc/pn533.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Applied, thanks.
Cheers,
Samuel.
--
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
stp broadcast packet not receving with the bridge and wpa_supplicant
Hi, We are using IXDP465 intel board which is running kernel 3.12.2 with a wireless Atheros card (driver ath9k) for wireless driver. We had configured the wireless client on this board and try to connect Target board Access point. Wireless client able to connect this Access point (With open and secure mode).ping also working between Access point to wireless client bridge. But we are not observing any stp & arp broadcast packet passing through the wireless client(capture the data using the tcpdump). >From the Target board this packet are trasmited confirm by tcpdump. I had also kept some debug prints in our kernel (3.12.3) and this packet also passing through the ath9k driver but not receiving on the application layer. Our Board configuration: We have two wireless card and two ethernet interface,which are added to the bridge. wpa_supplicant(0.7.3) running on the wireless interface with the drive nl80211 and set 4addr flag on using iw command. Target board configuration: Running with the kernel 2.6.15 and for access point they had used the hostapd (0.5.8). Driver used for Access point is madwifi(0.9.3) and Access point also added to the Bridge with the wds support. (We don't have access to target source code so we can't modify code on target platform) So it looks like madwifi + stp interoperability issue. Has someone observed this issue. Any inputs on this is much appreciated. Please forgive me if I have posted to a wrong list, and please guide me where should I post this? Thanks & regards, Deepak Kumar Pradhan -- 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] ath9k_htc: check seq number instead of cmd id for timeout
Hi all,
May I have an update on the patch status please?
Thanks and regards,
Fred
On 13/3/2015 4:32 PM, Fred Chou wrote:
> From: Fred Chou
>
> As the driver may send multiple wmi commands with identical cmd id,
> it is more robust to check seq number for timeout instead.
>
> Signed-off-by: Fred Chou
> ---
> drivers/net/wireless/ath/ath9k/wmi.c | 12 ++--
> drivers/net/wireless/ath/ath9k/wmi.h | 2 +-
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/wmi.c
> b/drivers/net/wireless/ath/ath9k/wmi.c
> index 65c8894..aba909f 100644
> --- a/drivers/net/wireless/ath/ath9k/wmi.c
> +++ b/drivers/net/wireless/ath/ath9k/wmi.c
> @@ -224,7 +224,7 @@ static void ath9k_wmi_ctrl_rx(void *priv, struct sk_buff
> *skb,
>
> /* Check if there has been a timeout. */
> spin_lock(&wmi->wmi_lock);
> - if (cmd_id != wmi->last_cmd_id) {
> + if (be16_to_cpu(hdr->seq_no) != wmi->last_seq_id) {
> spin_unlock(&wmi->wmi_lock);
> goto free_skb;
> }
> @@ -272,11 +272,16 @@ static int ath9k_wmi_cmd_issue(struct wmi *wmi,
> enum wmi_cmd_id cmd, u16 len)
> {
> struct wmi_cmd_hdr *hdr;
> + unsigned long flags;
>
> hdr = (struct wmi_cmd_hdr *) skb_push(skb, sizeof(struct wmi_cmd_hdr));
> hdr->command_id = cpu_to_be16(cmd);
> hdr->seq_no = cpu_to_be16(++wmi->tx_seq_id);
>
> + spin_lock_irqsave(&wmi->wmi_lock, flags);
> + wmi->last_seq_id = wmi->tx_seq_id;
> + spin_unlock_irqrestore(&wmi->wmi_lock, flags);
> +
> return htc_send_epid(wmi->htc, skb, wmi->ctrl_epid);
> }
>
> @@ -292,7 +297,6 @@ int ath9k_wmi_cmd(struct wmi *wmi, enum wmi_cmd_id cmd_id,
> struct sk_buff *skb;
> u8 *data;
> int time_left, ret = 0;
> - unsigned long flags;
>
> if (ah->ah_flags & AH_UNPLUGGED)
> return 0;
> @@ -320,10 +324,6 @@ int ath9k_wmi_cmd(struct wmi *wmi, enum wmi_cmd_id
> cmd_id,
> wmi->cmd_rsp_buf = rsp_buf;
> wmi->cmd_rsp_len = rsp_len;
>
> - spin_lock_irqsave(&wmi->wmi_lock, flags);
> - wmi->last_cmd_id = cmd_id;
> - spin_unlock_irqrestore(&wmi->wmi_lock, flags);
> -
> ret = ath9k_wmi_cmd_issue(wmi, skb, cmd_id, cmd_len);
> if (ret)
> goto out;
> diff --git a/drivers/net/wireless/ath/ath9k/wmi.h
> b/drivers/net/wireless/ath/ath9k/wmi.h
> index 0db37f2..2aad6dc 100644
> --- a/drivers/net/wireless/ath/ath9k/wmi.h
> +++ b/drivers/net/wireless/ath/ath9k/wmi.h
> @@ -143,7 +143,7 @@ struct wmi {
> enum htc_endpoint_id ctrl_epid;
> struct mutex op_mutex;
> struct completion cmd_wait;
> - enum wmi_cmd_id last_cmd_id;
> + u16 last_seq_id;
> struct sk_buff_head wmi_event_queue;
> struct tasklet_struct wmi_event_tasklet;
> u16 tx_seq_id;
>
--
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
