RE: iwlwifi-driver card doesn't work with 3.19-rc2+
Grumbach, Emmanuel wrote: > I don't see this as another datapoint. All it means is that there are ancient > drivers that won't work at all with newer tools and that are taken into > consideration while trying to deprecate an API. Not just drivers, tools and applications too. I don't think we can ever lose the WEXT baggage since there will probably be tools that will never migrate to nl80211. But, we can direct to /dev/null all kernel bugs that are related to WEXT. :-) Sujith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: iwlwifi-driver card doesn't work with 3.19-rc2+
Grumbach, Emmanuel wrote: I don't see this as another datapoint. All it means is that there are ancient drivers that won't work at all with newer tools and that are taken into consideration while trying to deprecate an API. Not just drivers, tools and applications too. I don't think we can ever lose the WEXT baggage since there will probably be tools that will never migrate to nl80211. But, we can direct to /dev/null all kernel bugs that are related to WEXT. :-) Sujith -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ath: phy1: DMA failed to stop in 10 ms
Andrej Gelenberg wrote: > i got some problems with my Qualcomm Atheros AR9485 wlan pcie card. I > use my card as access point (with hotspotd) on amd64 machine. I use > self compiled vanilla kernel 3.17.4 and a get a lot of > "DMA failed to stop" messages in my kernel log. I found some reports on > similar errors for *wrt, ubuntu and other distros in various > operation modes (ap and client). Increasing the timeout in mac.c to 100 > ms do not help. iommu=soft do not help either and GART iommu is not an > option (usb don't work for me with amd_iommu=off). I found this patch: > https://dev.openwrt.org/browser/trunk/package/mac80211/patches/552-ath9k_rx_dma_stop_check.patch?rev=34910 > , > which seems to apply to my problem, but i am not sure if it is a proper > solution. Can you please open a bug on bugzilla.kernel.org ? Sujith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ath: phy1: DMA failed to stop in 10 ms
Andrej Gelenberg wrote: i got some problems with my Qualcomm Atheros AR9485 wlan pcie card. I use my card as access point (with hotspotd) on amd64 machine. I use self compiled vanilla kernel 3.17.4 and a get a lot of DMA failed to stop messages in my kernel log. I found some reports on similar errors for *wrt, ubuntu and other distros in various operation modes (ap and client). Increasing the timeout in mac.c to 100 ms do not help. iommu=soft do not help either and GART iommu is not an option (usb don't work for me with amd_iommu=off). I found this patch: https://dev.openwrt.org/browser/trunk/package/mac80211/patches/552-ath9k_rx_dma_stop_check.patch?rev=34910 , which seems to apply to my problem, but i am not sure if it is a proper solution. Can you please open a bug on bugzilla.kernel.org ? Sujith -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ath9k ARM build error with v3.13-8330-g4ba9920
Josh Boyer wrote: > adds a udelay(1) call to the ath9k driver. This will cause a > build error on various ARM configs because the value passed to udelay > is too large: > > ERROR: "__bad_udelay" [drivers/net/wireless/ath/ath9k/ath9k_hw.ko] undefined! > make[1]: *** [__modpost] Error 1 > make: *** [modules] Error 2 > > Is the 1 microsecond udelay really required? I believe the limit > on ARM is 2000. Perhaps something else could be done in this case? The delay is a workaround for a HW issue. Does this patch fix the problem ? diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c index fbf43c0..11eab9f 100644 --- a/drivers/net/wireless/ath/ath9k/hw.c +++ b/drivers/net/wireless/ath/ath9k/hw.c @@ -1316,7 +1316,7 @@ static bool ath9k_hw_set_reset(struct ath_hw *ah, int type) if (AR_SREV_9300_20_OR_LATER(ah)) udelay(50); else if (AR_SREV_9100(ah)) - udelay(1); + mdelay(10); else udelay(100); @@ -2051,9 +2051,8 @@ static bool ath9k_hw_set_power_awake(struct ath_hw *ah) REG_SET_BIT(ah, AR_RTC_FORCE_WAKE, AR_RTC_FORCE_WAKE_EN); - if (AR_SREV_9100(ah)) - udelay(1); + mdelay(10); else udelay(50); Sujith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ath9k ARM build error with v3.13-8330-g4ba9920
Josh Boyer wrote: adds a udelay(1) call to the ath9k driver. This will cause a build error on various ARM configs because the value passed to udelay is too large: ERROR: __bad_udelay [drivers/net/wireless/ath/ath9k/ath9k_hw.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 Is the 1 microsecond udelay really required? I believe the limit on ARM is 2000. Perhaps something else could be done in this case? The delay is a workaround for a HW issue. Does this patch fix the problem ? diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c index fbf43c0..11eab9f 100644 --- a/drivers/net/wireless/ath/ath9k/hw.c +++ b/drivers/net/wireless/ath/ath9k/hw.c @@ -1316,7 +1316,7 @@ static bool ath9k_hw_set_reset(struct ath_hw *ah, int type) if (AR_SREV_9300_20_OR_LATER(ah)) udelay(50); else if (AR_SREV_9100(ah)) - udelay(1); + mdelay(10); else udelay(100); @@ -2051,9 +2051,8 @@ static bool ath9k_hw_set_power_awake(struct ath_hw *ah) REG_SET_BIT(ah, AR_RTC_FORCE_WAKE, AR_RTC_FORCE_WAKE_EN); - if (AR_SREV_9100(ah)) - udelay(1); + mdelay(10); else udelay(50); Sujith -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pull request: wireless 2013-06-06
David Miller wrote: > John, I also don't like the ATK9K Kconfig option name change added in > this pull request, this is exactly the kind of thing that drives > Linus insane. > > Change the default, fine, but changing the name is unnecssary churn > and adds a new config prompt that people are going to respond to > incorrectly when they type "make oldconfig" This was Linus' suggestion: https://patchwork.kernel.org/patch/2676971/ The RH bugzilla appears to be down at the moment, but more background for the bug is here: https://bugzilla.redhat.com/show_bug.cgi?id=927191 Sujith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pull request: wireless 2013-06-06
David Miller wrote: John, I also don't like the ATK9K Kconfig option name change added in this pull request, this is exactly the kind of thing that drives Linus insane. Change the default, fine, but changing the name is unnecssary churn and adds a new config prompt that people are going to respond to incorrectly when they type make oldconfig This was Linus' suggestion: https://patchwork.kernel.org/patch/2676971/ The RH bugzilla appears to be down at the moment, but more background for the bug is here: https://bugzilla.redhat.com/show_bug.cgi?id=927191 Sujith -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the wireless-next tree with the wireless tree
Stephen Rothwell wrote:
> Today's linux-next merge of the wireless-next tree got a conflict in
> drivers/net/wireless/ath/ath9k/Kconfig between commit 8bb7f167a12a
> ("ath9k: Use minstrel rate control by default") from the wireless tree
> and commit cf657a2bc50d ("ath9k: Remove MAC_DEBUG") from the
> wireless-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Thanks !
Sujith
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the wireless-next tree with the wireless tree
Stephen Rothwell wrote: Today's linux-next merge of the wireless-next tree got a conflict in drivers/net/wireless/ath/ath9k/Kconfig between commit 8bb7f167a12a (ath9k: Use minstrel rate control by default) from the wireless tree and commit cf657a2bc50d (ath9k: Remove MAC_DEBUG) from the wireless-next tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). Thanks ! Sujith -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: kernel panic on Dell Vostro 3560 when plugging in AC adapter
Adrian Byszuk wrote: > Aaaand failure again! > I haven't finished bisecting yet, but as of now I have ~20 commits left: > all related to 'mtd' - propably not a source of troubles too. > Any other way to diagnose this bug? I think this has been fixed by: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=3935e89505a1c3ab3f3b0c7ef0eae54124f48905 For Arch Linux, it was tracked here: https://bugs.archlinux.org/task/33095 Sujith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: kernel panic on Dell Vostro 3560 when plugging in AC adapter
Adrian Byszuk wrote: Aaaand failure again! I haven't finished bisecting yet, but as of now I have ~20 commits left: all related to 'mtd' - propably not a source of troubles too. Any other way to diagnose this bug? I think this has been fixed by: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=3935e89505a1c3ab3f3b0c7ef0eae54124f48905 For Arch Linux, it was tracked here: https://bugs.archlinux.org/task/33095 Sujith -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ath9k_htc: Fix skb leaks
Larry Finger wrote: > > I'll come up with a patch and see if kmemleak still complains. > > Did I miss your posting on this issue? Nope, I haven't got to this yet, sorry. I'll try to send a patch by today. Sujith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ath9k_htc: Fix skb leaks
Larry Finger wrote: I'll come up with a patch and see if kmemleak still complains. Did I miss your posting on this issue? Nope, I haven't got to this yet, sorry. I'll try to send a patch by today. Sujith -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ath9k_htc: Fix skb leaks
Larry Finger wrote: > My only counter argument is that none of the other paths that get to > ath9k_htc_txcompletion_cb() leak the skb. It only happens for the path that > goes > through htc_connect_service(). Sure, but the TX completion handler would be invoked for every skb that is passed to the USB layer, including the ones that are allocated in htc_hst.c. When this skb goes down to hif_usb.c, a URB is allocated and I am not sure how freeing the skb before the USB layer invokes the completion handler for the URB is correct. I'll come up with a patch and see if kmemleak still complains. Sujith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ath9k_htc: Fix skb leaks
Larry Finger wrote:
> diff --git a/drivers/net/wireless/ath/ath9k/htc_hst.c
> b/drivers/net/wireless/ath/ath9k/htc_hst.c
> index 4a9570d..a304748 100644
> --- a/drivers/net/wireless/ath/ath9k/htc_hst.c
> +++ b/drivers/net/wireless/ath/ath9k/htc_hst.c
> @@ -278,10 +278,12 @@ int htc_connect_service(struct htc_target *target,
> if (!time_left) {
> dev_err(target->dev, "Service connection timeout for: %d\n",
> service_connreq->service_id);
> - return -ETIMEDOUT;
> + ret = -ETIMEDOUT;
> + goto err;
> }
>
> *conn_rsp_epid = target->conn_rsp_epid;
> + kfree_skb(skb);
> return 0;
> err:
> kfree_skb(skb);
The allocated skb should be freed in the TX completion hander,
ath9k_htc_txcompletion_cb() - doing it in htc_connect_service() is wrong, I
think.
Sujith
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ath9k_htc: Fix skb leaks
Larry Finger wrote:
diff --git a/drivers/net/wireless/ath/ath9k/htc_hst.c
b/drivers/net/wireless/ath/ath9k/htc_hst.c
index 4a9570d..a304748 100644
--- a/drivers/net/wireless/ath/ath9k/htc_hst.c
+++ b/drivers/net/wireless/ath/ath9k/htc_hst.c
@@ -278,10 +278,12 @@ int htc_connect_service(struct htc_target *target,
if (!time_left) {
dev_err(target-dev, Service connection timeout for: %d\n,
service_connreq-service_id);
- return -ETIMEDOUT;
+ ret = -ETIMEDOUT;
+ goto err;
}
*conn_rsp_epid = target-conn_rsp_epid;
+ kfree_skb(skb);
return 0;
err:
kfree_skb(skb);
The allocated skb should be freed in the TX completion hander,
ath9k_htc_txcompletion_cb() - doing it in htc_connect_service() is wrong, I
think.
Sujith
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ath9k_htc: Fix skb leaks
Larry Finger wrote: My only counter argument is that none of the other paths that get to ath9k_htc_txcompletion_cb() leak the skb. It only happens for the path that goes through htc_connect_service(). Sure, but the TX completion handler would be invoked for every skb that is passed to the USB layer, including the ones that are allocated in htc_hst.c. When this skb goes down to hif_usb.c, a URB is allocated and I am not sure how freeing the skb before the USB layer invokes the completion handler for the URB is correct. I'll come up with a patch and see if kmemleak still complains. Sujith -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the wireless-next tree with the pci tree
Stephen Rothwell wrote:
> Hi John,
>
> Today's linux-next merge of the wireless-next tree got a conflict in
> drivers/net/wireless/ath/ath9k/pci.c between commit 08bd108096b6 ("ath9k:
> Use PCI Express Capability accessors") from the pci tree and commit
> 046b6802c8d3 ("ath9k: Disable ASPM only for AR9285") from the
> wireless-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
The fix looks good, thanks.
Sujith
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the wireless-next tree with the pci tree
Stephen Rothwell wrote: Hi John, Today's linux-next merge of the wireless-next tree got a conflict in drivers/net/wireless/ath/ath9k/pci.c between commit 08bd108096b6 (ath9k: Use PCI Express Capability accessors) from the pci tree and commit 046b6802c8d3 (ath9k: Disable ASPM only for AR9285) from the wireless-next tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). The fix looks good, thanks. Sujith -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
