Re: [PATCH] staging: rtl8723au: rtl8723a_hal_init: Improve code readability
Johannes Postma jgmpos...@gmail.com writes: This patch improves code readability in the function rtl8723a_cal_txdesc_chksum. It improves the readability of the argument of the function le16_to_cpu. Signed-off-by: Johannes Postma jgmpos...@gmail.com --- drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Jes Sorensen jes.soren...@redhat.com -- 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 1/5] device property: helper macros for property entry creation
On Thursday, August 06, 2015 10:48:48 AM Heikki Krogerus wrote:
On Wed, Aug 05, 2015 at 05:02:18PM +0300, Andy Shevchenko wrote:
On Wed, 2015-08-05 at 16:39 +0300, Heikki Krogerus wrote:
Marcos for easier creation of build-in property entries.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
include/linux/property.h | 35 +++
1 file changed, 35 insertions(+)
diff --git a/include/linux/property.h b/include/linux/property.h
index 76ebde9..204d899 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -152,6 +152,41 @@ struct property_entry {
} value;
};
+#define PROP_ENTRY_U8(_name_, _val_) { \
PROP_ prefix is too generic.
Maybe DEVPROP_ ? At least for the latter no records in the current
sources.
I disagree with that. IMO this kind of macros should ideally resemble
the structure name they are used to fill (struct property_entry in
this case). And there are already definitions for DEV_PROP_* to
describe the types, so using something like DEVPROP_* here is just
confusing.
If PROP_ENTRY_* is really not good enough, we can change them
PROPERTY_ENTRY_*. But is PROP_ENTRY_* really so bad?
Rafael, what is your opinion?
I would prefer PROPERTY_ENTRY_ to be honest. It's not like we need to save
characters here.
Thanks,
Rafael
--
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 sparse warning: cast to restricted __le16
On 06/08/15 at 08:21am, Jes Sorensen wrote: Looks OK to me. Probably worth changing the *(usPtr + index) to be usPtr[index] as well to make the code easier to read. Jes Thank you for reviewing. I will make a seperate patch for that. I will send it after this one is accepted. Or should I combine them into a patch serie? Johannes -- 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] mac80211_hwsim: unregister genetlink family properly
During hwsim_init_netlink(), we should call genl_unregister_family()
if failed on netlink_register_notifier() since the genetlink is
already registered.
Signed-off-by: Su Kang Yin cant...@cantona.net
---
drivers/net/wireless/mac80211_hwsim.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c
b/drivers/net/wireless/mac80211_hwsim.c
index 99e873d..16d953e 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -3120,8 +3120,10 @@ static int hwsim_init_netlink(void)
goto failure;
rc = netlink_register_notifier(hwsim_netlink_notifier);
- if (rc)
+ if (rc) {
+ genl_unregister_family(hwsim_genl_family);
goto failure;
+ }
return 0;
--
1.9.1
--
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: pull-request: wireless-drivers 2015-08-04
From: Kalle Valo kv...@codeaurora.org Date: Tue, 04 Aug 2015 19:54:09 +0300 here are few small fixes I would like to get to 4.2. Please let me know if there are any problems. Pulled, thanks. -- 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] ath10k: wake up queue upon vif creation
Vif's vdev_id is used as queue number. However due to the tx pausing design in ath10k it was possible for a new interface to be created with its tx queue stopped (via ieee80211_stop_queues). This could in turn leave the interface inoperable until ath10k_mac_tx_unlock() was called. This problem only affected multi-vif scenarios when new interfaces were created some time later after other interfaces have been running for some time and had Tx queue full at some point prior. Possible manifestation of the bug was authentication timeout for a client vif. Fixes: 96d828d45e16 (ath10k: rework tx queue locking) Signed-off-by: Michal Kazior michal.kaz...@tieto.com --- drivers/net/wireless/ath/ath10k/mac.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index acd222f3b899..03e498cb64b4 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -4299,6 +4299,11 @@ static int ath10k_add_interface(struct ieee80211_hw *hw, } } + spin_lock_bh(ar-htt.tx_lock); + if (!ar-tx_paused) + ieee80211_wake_queue(ar-hw, arvif-vdev_id); + spin_unlock_bh(ar-htt.tx_lock); + mutex_unlock(ar-conf_mutex); return 0; -- 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: ath9k: fix build with CONFIG_ATH9K_STATION_STATISTICS=y
kbuild bot reported that commit 592fa228f213 (ath9k: remove struct ath_atx_ac) broke the build when CONFIG_ATH9K_STATION_STATISTICS is y. Reported-by: kbuild test robot fengguang...@intel.com Fixes: 592fa228f213 (ath9k: remove struct ath_atx_ac) Signed-off-by: Felix Fietkau n...@openwrt.org Thanks, applied to wireless-drivers-next.git. 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
RE: [PATCH 4.2 1/3] mwifiex: usb: Fix double add error when submitting rx urb
Hi Kalle, From: Kalle Valo [mailto:kv...@codeaurora.org] Sent: Friday, August 07, 2015 1:56 PM To: Amitkumar Karwar Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam; sta...@vger.kernel.org; Reyad Attiyat Subject: Re: [PATCH 4.2 1/3] mwifiex: usb: Fix double add error when submitting rx urb Amitkumar Karwar akar...@marvell.com writes: From: Reyad Attiyat reyad.atti...@gmail.com There is an error that can occur where the driver adds the same URB to USB submission list twice. This happens since mwifiex_usb_submit_rem_rx can submit packets at same time as an rx urb complete callback. This causes list corruption and is fixed by not setting the skb to NULL when submitting an rx packet. [ 84.461242] WARNING: CPU: 1 PID: 748 at lib/list_debug.c:36 __list_add+0xcb/0xd0() [ 84.461245] list_add double add: new=8800c92b0c50, prev=8800c92b0c50, next=8800ced6c430. [ 84.461247] Modules linked in: rfcomm fuse cmac nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack bnep iptable_mangle iptable_security iptable_raw btusb btintel bluetooth mwifiex_usb mwifiex x86_pkg_temp_thermal cfg80211 coretemp r8712u(C) kvm_intel kvm hid_sensor_als hid_sensor_incl_3d hid_sensor_rotation hid_sensor_magn_3d hid_sensor_accel_3d hid_sensor_gyro_3d hid_sensor_trigger hid_sensor_iio_common industrialio_triggered_buffer kfifo_buf rfkill iTCO_wdt industrialio iTCO_vendor_support [ 84.461316] crc32_pclmul crc32c_intel ghash_clmulni_intel microcode snd_hda_codec_realtek vfat snd_hda_codec_generic fat snd_hda_codec_hdmi snd_hda_intel snd_hda_controller uvcvideo snd_hda_codec videobuf2_vmalloc videobuf2_memops snd_hwdep videobuf2_core snd_hda_core joydev v4l2_common videodev hid_sensor_hub snd_seq hid_multitouch media snd_seq_device snd_pcm snd_timer mei_me snd i2c_i801 lpc_ich mei soundcore tpm_infineon tpm_tis tpm i2c_hid i2c_designware_platform i2c_designware_core nfsd auth_rpcgss nfs_acl lockd grace sunrpc sch_fq_codel i915 i2c_algo_bit drm_kms_helper drm xhci_pci xhci_hcd ehci_pci sd_mod ehci_hcd video [ 84.461383] CPU: 1 PID: 748 Comm: kworker/u9:0 Tainted: G C 4.1.0-rc5+ #163 [ 84.461386] Hardware name: Microsoft Corporation Surface Pro 2/Surface Pro 2, BIOS 2.05.0250 04/10/2015 [ 84.461396] Workqueue: MWIFIEX_RX_WORK_QUEUE mwifiex_rx_work_queue [mwifiex] [ 84.461399] 81a8150e 8801174cf8e8 817df830 [ 84.461405] 8801174cf938 8801174cf928 810a54ba 8800c86bd750 [ 84.461410] 8800c92b0c50 8800c92b0c50 8800ced6c430 88010c057178 [ 84.461416] Call Trace: [ 84.461421] [817df830] dump_stack+0x4f/0x7b [ 84.461428] [810a54ba] warn_slowpath_common+0x8a/0xc0 [ 84.461432] [810a5536] warn_slowpath_fmt+0x46/0x50 [ 84.461436] [814109fb] __list_add+0xcb/0xd0 [ 84.461442] [815c551a] ? usb_hcd_link_urb_to_ep+0x2a/0xa0 [ 84.461446] [815c5570] usb_hcd_link_urb_to_ep+0x80/0xa0 [ 84.461459] [a004318a] prepare_transfer+0xaa/0x130 [xhci_hcd] [ 84.461470] [a0044cf7] xhci_queue_bulk_tx+0xb7/0x7a0 [xhci_hcd] [ 84.461480] [a003b67f] ? xhci_urb_enqueue+0x50f/0x660 [xhci_hcd] [ 84.461489] [a003b67f] ? xhci_urb_enqueue+0x50f/0x660 [xhci_hcd] [ 84.461498] [a003b735] xhci_urb_enqueue+0x5c5/0x660 [xhci_hcd] [ 84.461503] [815c7ad3] usb_hcd_submit_urb+0x93/0xa70 [ 84.461507] [8168dde8] ? __alloc_skb+0x78/0x1f0 [ 84.461511] [8168d301] ? __kmalloc_reserve.isra.26+0x31/0x90 [ 84.461515] [8168ddbc] ? __alloc_skb+0x4c/0x1f0 [ 84.461519] [8168ddfc] ? __alloc_skb+0x8c/0x1f0 [ 84.461523] [8168badd] ? skb_dequeue+0x5d/0x80 [ 84.461527] [815c987e] usb_submit_urb+0x42e/0x5f0 [ 84.461531] [816931d9] ? __alloc_rx_skb+0x39/0x100 [ 84.461536] [a05aa372] mwifiex_usb_submit_rx_urb+0xb2/0x170 [mwifiex_usb] [ 84.461542] [a05aa5f5] mwifiex_usb_submit_rem_rx_urbs+0x45/0x50 [mwifiex_usb] [ 84.461550] [a07094be] mwifiex_rx_work_queue+0x10e/0x140 [mwifiex] [ 84.461556] [810c4429] process_one_work+0x229/0x890 [ 84.461559] [810c438c] ? process_one_work+0x18c/0x890 [ 84.461565] [810c4ae3] worker_thread+0x53/0x470 [ 84.461569] [810c4a90] ? process_one_work+0x890/0x890 [ 84.461572] [810cb162] kthread+0xf2/0x110 [ 84.461577] [811031ad] ? trace_hardirqs_on+0xd/0x10 [ 84.461581] [810cb070] ?
Re: [PATCH 4.2 1/3] mwifiex: usb: Fix double add error when submitting rx urb
Amitkumar Karwar akar...@marvell.com writes: From: Reyad Attiyat reyad.atti...@gmail.com There is an error that can occur where the driver adds the same URB to USB submission list twice. This happens since mwifiex_usb_submit_rem_rx can submit packets at same time as an rx urb complete callback. This causes list corruption and is fixed by not setting the skb to NULL when submitting an rx packet. [ 84.461242] WARNING: CPU: 1 PID: 748 at lib/list_debug.c:36 __list_add+0xcb/0xd0() [ 84.461245] list_add double add: new=8800c92b0c50, prev=8800c92b0c50, next=8800ced6c430. [ 84.461247] Modules linked in: rfcomm fuse cmac nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack bnep iptable_mangle iptable_security iptable_raw btusb btintel bluetooth mwifiex_usb mwifiex x86_pkg_temp_thermal cfg80211 coretemp r8712u(C) kvm_intel kvm hid_sensor_als hid_sensor_incl_3d hid_sensor_rotation hid_sensor_magn_3d hid_sensor_accel_3d hid_sensor_gyro_3d hid_sensor_trigger hid_sensor_iio_common industrialio_triggered_buffer kfifo_buf rfkill iTCO_wdt industrialio iTCO_vendor_support [ 84.461316] crc32_pclmul crc32c_intel ghash_clmulni_intel microcode snd_hda_codec_realtek vfat snd_hda_codec_generic fat snd_hda_codec_hdmi snd_hda_intel snd_hda_controller uvcvideo snd_hda_codec videobuf2_vmalloc videobuf2_memops snd_hwdep videobuf2_core snd_hda_core joydev v4l2_common videodev hid_sensor_hub snd_seq hid_multitouch media snd_seq_device snd_pcm snd_timer mei_me snd i2c_i801 lpc_ich mei soundcore tpm_infineon tpm_tis tpm i2c_hid i2c_designware_platform i2c_designware_core nfsd auth_rpcgss nfs_acl lockd grace sunrpc sch_fq_codel i915 i2c_algo_bit drm_kms_helper drm xhci_pci xhci_hcd ehci_pci sd_mod ehci_hcd video [ 84.461383] CPU: 1 PID: 748 Comm: kworker/u9:0 Tainted: G C 4.1.0-rc5+ #163 [ 84.461386] Hardware name: Microsoft Corporation Surface Pro 2/Surface Pro 2, BIOS 2.05.0250 04/10/2015 [ 84.461396] Workqueue: MWIFIEX_RX_WORK_QUEUE mwifiex_rx_work_queue [mwifiex] [ 84.461399] 81a8150e 8801174cf8e8 817df830 [ 84.461405] 8801174cf938 8801174cf928 810a54ba 8800c86bd750 [ 84.461410] 8800c92b0c50 8800c92b0c50 8800ced6c430 88010c057178 [ 84.461416] Call Trace: [ 84.461421] [817df830] dump_stack+0x4f/0x7b [ 84.461428] [810a54ba] warn_slowpath_common+0x8a/0xc0 [ 84.461432] [810a5536] warn_slowpath_fmt+0x46/0x50 [ 84.461436] [814109fb] __list_add+0xcb/0xd0 [ 84.461442] [815c551a] ? usb_hcd_link_urb_to_ep+0x2a/0xa0 [ 84.461446] [815c5570] usb_hcd_link_urb_to_ep+0x80/0xa0 [ 84.461459] [a004318a] prepare_transfer+0xaa/0x130 [xhci_hcd] [ 84.461470] [a0044cf7] xhci_queue_bulk_tx+0xb7/0x7a0 [xhci_hcd] [ 84.461480] [a003b67f] ? xhci_urb_enqueue+0x50f/0x660 [xhci_hcd] [ 84.461489] [a003b67f] ? xhci_urb_enqueue+0x50f/0x660 [xhci_hcd] [ 84.461498] [a003b735] xhci_urb_enqueue+0x5c5/0x660 [xhci_hcd] [ 84.461503] [815c7ad3] usb_hcd_submit_urb+0x93/0xa70 [ 84.461507] [8168dde8] ? __alloc_skb+0x78/0x1f0 [ 84.461511] [8168d301] ? __kmalloc_reserve.isra.26+0x31/0x90 [ 84.461515] [8168ddbc] ? __alloc_skb+0x4c/0x1f0 [ 84.461519] [8168ddfc] ? __alloc_skb+0x8c/0x1f0 [ 84.461523] [8168badd] ? skb_dequeue+0x5d/0x80 [ 84.461527] [815c987e] usb_submit_urb+0x42e/0x5f0 [ 84.461531] [816931d9] ? __alloc_rx_skb+0x39/0x100 [ 84.461536] [a05aa372] mwifiex_usb_submit_rx_urb+0xb2/0x170 [mwifiex_usb] [ 84.461542] [a05aa5f5] mwifiex_usb_submit_rem_rx_urbs+0x45/0x50 [mwifiex_usb] [ 84.461550] [a07094be] mwifiex_rx_work_queue+0x10e/0x140 [mwifiex] [ 84.461556] [810c4429] process_one_work+0x229/0x890 [ 84.461559] [810c438c] ? process_one_work+0x18c/0x890 [ 84.461565] [810c4ae3] worker_thread+0x53/0x470 [ 84.461569] [810c4a90] ? process_one_work+0x890/0x890 [ 84.461572] [810cb162] kthread+0xf2/0x110 [ 84.461577] [811031ad] ? trace_hardirqs_on+0xd/0x10 [ 84.461581] [810cb070] ? kthread_create_on_node+0x230/0x230 [ 84.461586] [817e9662] ret_from_fork+0x42/0x70 [ 84.461590] [810cb070] ? kthread_create_on_node+0x230/0x230 [ 84.461593] ---[ end trace 65103af5e6fb3444 ]--- Cc: sta...@vger.kernel.org # 3.19+ Signed-off-by: Reyad Attiyat reyad.atti...@gmail.com Acked-by: Amitkumar Karwar
RE: firmware in a bad state (module mwifiex)
Hi Julien,
Thanks for reporting this. We will take a look at this right away.
We don't have significant changes after 4.2.0-rc3.
Well there were the two patches you pointed at that fixed a very serious
problem for me. Actually are these included in some branch of the main
kernel git tree ? I couldn't find the commit for
http://www.spinics.net/lists/netdev/msg334367.html at
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/
You can try to find older working commit.
I'm afraid that will be difficult since this driver has been broken for
me since the 3.19 series.
Thanks again for your very precious help.
We ran overnight data path stress test, but could not hit any issue. Do you see
command timeout message every time when the problem is hit?
Could you provide some more logs? We had following fixes for timeout issue.
Listing here just in case if you missed them(less likely).
http://www.spinics.net/lists/linux-wireless/msg123959.html
http://www.spinics.net/lists/linux-wireless/msg124366.html
Setup info:
Kernel - 4.2.0-rc4
Chip - USB8797
Firmware - 14.68.29.p38
Regards,
Amitkumar
N�r��yb�X��ǧv�^�){.n�+{��*ޕ�,�{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
Re: [PATCH] rtlwifi: rtl8723be: disable FW control power save
On 08/06/2015 10:11 PM, AceLan Kao wrote:
There are many rtl8723be wifi unstable issues that wifi lost connection
after working for a while. The wifi signal and status it's show connected
also ifconfig have IP but can not connect to internet and filed to ping 8.8.8.8
The problem should result from the power saving controlled by firmware.
I'd suggest to disable it by default and re-enable it after firmware fixes
this issue.
BTW. the firmware I tested from linux-firmware git tree is
rtlwifi/rtl8723befw.bin
be225d6 Update firmware for rtl8723be
Signed-off-by: AceLan Kao acelan@canonical.com
NACK for this patch. If you were to make this change, you should also change the
text in the MODULE_PARM_DESC() for this parameter. It shows a hard-coded default.
I am not sure this is a firmware problem as some users report that they need to
run with the ips=0 option, not with fwlps=0 as your patch would force.
Conversely, the driver works fine as is with other AP/environment combinations.
The Realtek engineer has told me that he is aware of problems with the dynamic
management for all the drivers, and that they are working on major replacements;
however, there is no timetable for the new code.
If we make a change in the default power settings, I would prefer changing
inactiveps and its MODULE_PARM_DESC() text; however, that would have a negative
impact on power usage on the host.
I have BCc'd the Realtek engineer and I hope to get his comments on this change.
Larry
---
drivers/net/wireless/rtlwifi/rtl8723be/sw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8723be/sw.c
b/drivers/net/wireless/rtlwifi/rtl8723be/sw.c
index 1017f02..02fe2cc 100644
--- a/drivers/net/wireless/rtlwifi/rtl8723be/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8723be/sw.c
@@ -266,7 +266,7 @@ static struct rtl_mod_params rtl8723be_mod_params = {
.sw_crypto = false,
.inactiveps = true,
.swctrl_lps = false,
- .fwctrl_lps = true,
+ .fwctrl_lps = false,
};
static struct rtl_hal_cfg rtl8723be_hal_cfg = {
--
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 sparse warning: cast to restricted __le16
Johannes Postma jgmpos...@gmail.com writes: On 06/08/15 at 08:21am, Jes Sorensen wrote: Looks OK to me. Probably worth changing the *(usPtr + index) to be usPtr[index] as well to make the code easier to read. Jes Thank you for reviewing. I will make a seperate patch for that. I will send it after this one is accepted. Or should I combine them into a patch serie? Either is fine with 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] staging: rtl8723au: rtl8723a_hal_init: Improve code readability
This patch improves code readability in the function rtl8723a_cal_txdesc_chksum. It improves the readability of the argument of the function le16_to_cpu. Signed-off-by: Johannes Postma jgmpos...@gmail.com --- drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c b/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c index eb76ac4..cf2388f 100644 --- a/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c +++ b/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c @@ -1847,7 +1847,7 @@ static void rtl8723a_cal_txdesc_chksum(struct tx_desc *ptxdesc) ptxdesc-txdw7 = cpu_to_le32(0x); for (index = 0; index count; index++) - checksum ^= le16_to_cpu(*(usPtr + index)); + checksum ^= le16_to_cpu(usPtr[index]); ptxdesc-txdw7 |= cpu_to_le32(checksum 0x); } -- 2.5.0 -- 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 sparse warning: cast to restricted __le16
On 07/08/15 at 08:26am, Jes Sorensen wrote: Johannes Postma jgmpos...@gmail.com writes: On 06/08/15 at 08:21am, Jes Sorensen wrote: Looks OK to me. Probably worth changing the *(usPtr + index) to be usPtr[index] as well to make the code easier to read. Jes Thank you for reviewing. I will make a seperate patch for that. I will send it after this one is accepted. Or should I combine them into a patch serie? Either is fine with me. Jes Ok, I have sent it as a separate patch. Since it doesn't depend on this patch and should apply cleanly I have already sent it in. Johannes -- 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
