* Re: pull-request: mac80211 2016-08-05
From: David Miller @ 2016-08-07 7:24 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <1470400329-23256-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Fri, 5 Aug 2016 14:32:08 +0200
> Here's a first set of fixes for the current cycle. See the tag message
> for more information.
>
> I'll probably have a follow-up fix for the real problem in mac80211
> that caused the crash later, but for now we have this patch and it
> makes sense and fixes the crash, even if the behaviour isn't quite
> right (afaict.)
>
> Let me know if there's any problem.
Pulled, thanks.
^ permalink raw reply
* iwlwifi errors (regression?) on 4.7.0
From: Andy Lutomirski @ 2016-08-07 8:54 UTC (permalink / raw)
To: Linux Wireless List, Intel Linux Wireless, Luca Coelho,
Emmanuel Grumbach, Johannes Berg
My Intel 7265 used to work flawlessly, but for the past week or two it
has seemed to be very unreliable. It's also throwing errors. I see
problems on firmware versions 16 and 21, although I haven't gotten the
warning and backtrace on firmware 16 yet.
I have:
iwlwifi 0000:3a:00.0: enabling device (0000 -> 0002)
iwlwifi 0000:3a:00.0: Unsupported splx structure
iwlwifi 0000:3a:00.0: loaded firmware version 21.302800.0 op_mode iwlmvm
iwlwifi 0000:3a:00.0: Detected Intel(R) Dual Band Wireless AC 7265, REV=0x210
iwlwifi 0000:3a:00.0: L1 Enabled - LTR Disabled
iwlwifi 0000:3a:00.0: L1 Enabled - LTR Disabled
I just got this error on 4.7.0:
[324188.495734] wlp58s0: associated
[324281.259579] iwlwifi 0000:3a:00.0: Queue 16 stuck for 10000 ms.
[324281.259600] iwlwifi 0000:3a:00.0: Current SW read_ptr 255 write_ptr 13
[324281.259648] iwl data: 00000000: 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 ................
[324281.259676] iwlwifi 0000:3a:00.0: FH TRBs(0) = 0x00000000
[324281.259703] iwlwifi 0000:3a:00.0: FH TRBs(1) = 0xc011000c
[324281.259728] iwlwifi 0000:3a:00.0: FH TRBs(2) = 0x00000000
[324281.259753] iwlwifi 0000:3a:00.0: FH TRBs(3) = 0x80300024
[324281.259779] iwlwifi 0000:3a:00.0: FH TRBs(4) = 0x00000000
[324281.259804] iwlwifi 0000:3a:00.0: FH TRBs(5) = 0x00000000
[324281.259830] iwlwifi 0000:3a:00.0: FH TRBs(6) = 0x00000000
[324281.259855] iwlwifi 0000:3a:00.0: FH TRBs(7) = 0x007090e6
[324281.259925] iwlwifi 0000:3a:00.0: Q 0 is active and mapped to fifo
3 ra_tid 0x0000 [37,37]
[324281.259999] iwlwifi 0000:3a:00.0: Q 1 is active and mapped to fifo
2 ra_tid 0x0000 [0,0]
[324281.260065] iwlwifi 0000:3a:00.0: Q 2 is active and mapped to fifo
1 ra_tid 0x0000 [7,7]
[324281.260131] iwlwifi 0000:3a:00.0: Q 3 is active and mapped to fifo
0 ra_tid 0x0000 [0,0]
[324281.260197] iwlwifi 0000:3a:00.0: Q 4 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.260264] iwlwifi 0000:3a:00.0: Q 5 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.260330] iwlwifi 0000:3a:00.0: Q 6 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.260396] iwlwifi 0000:3a:00.0: Q 7 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.260462] iwlwifi 0000:3a:00.0: Q 8 is active and mapped to fifo
3 ra_tid 0x0000 [0,0]
[324281.260528] iwlwifi 0000:3a:00.0: Q 9 is active and mapped to fifo
7 ra_tid 0x0000 [231,231]
[324281.260595] iwlwifi 0000:3a:00.0: Q 10 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.260662] iwlwifi 0000:3a:00.0: Q 11 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.260731] iwlwifi 0000:3a:00.0: Q 12 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.260806] iwlwifi 0000:3a:00.0: Q 13 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.260873] iwlwifi 0000:3a:00.0: Q 14 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.260939] iwlwifi 0000:3a:00.0: Q 15 is active and mapped to
fifo 5 ra_tid 0x0000 [0,0]
[324281.261006] iwlwifi 0000:3a:00.0: Q 16 is active and mapped to
fifo 1 ra_tid 0x1fff [255,13]
[324281.261085] iwlwifi 0000:3a:00.0: Q 17 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.261214] iwlwifi 0000:3a:00.0: Q 18 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.261356] iwlwifi 0000:3a:00.0: Q 19 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.261499] iwlwifi 0000:3a:00.0: Q 20 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.261636] iwlwifi 0000:3a:00.0: Q 21 is inactive and mapped to
fifo 0 ra_tid 0x8000 [0,0]
[324281.261775] iwlwifi 0000:3a:00.0: Q 22 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.261903] iwlwifi 0000:3a:00.0: Q 23 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.262032] iwlwifi 0000:3a:00.0: Q 24 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.262173] iwlwifi 0000:3a:00.0: Q 25 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.262285] iwlwifi 0000:3a:00.0: Q 26 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.262426] iwlwifi 0000:3a:00.0: Q 27 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.262555] iwlwifi 0000:3a:00.0: Q 28 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.262684] iwlwifi 0000:3a:00.0: Q 29 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.262812] iwlwifi 0000:3a:00.0: Q 30 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.262909] iwlwifi 0000:3a:00.0: Microcode SW error detected.
Restarting 0x2000000.
[324281.262918] iwlwifi 0000:3a:00.0: CSR values:
[324281.262925] iwlwifi 0000:3a:00.0: (2nd byte of CSR_INT_COALESCING
is CSR_INT_PERIODIC_REG)
[324281.262945] iwlwifi 0000:3a:00.0: CSR_HW_IF_CONFIG_REG: 0X00489200
[324281.262960] iwlwifi 0000:3a:00.0: CSR_INT_COALESCING: 0X00000040
[324281.262976] iwlwifi 0000:3a:00.0: CSR_INT: 0X00000000
[324281.262992] iwlwifi 0000:3a:00.0: CSR_INT_MASK: 0X00000000
[324281.263007] iwlwifi 0000:3a:00.0: CSR_FH_INT_STATUS: 0X00000000
[324281.263022] iwlwifi 0000:3a:00.0: CSR_GPIO_IN: 0X00000000
[324281.263037] iwlwifi 0000:3a:00.0: CSR_RESET: 0X00000000
[324281.263053] iwlwifi 0000:3a:00.0: CSR_GP_CNTRL: 0X080403c5
[324281.263069] iwlwifi 0000:3a:00.0: CSR_HW_REV: 0X00000210
[324281.263084] iwlwifi 0000:3a:00.0: CSR_EEPROM_REG: 0Xd55555d5
[324281.263099] iwlwifi 0000:3a:00.0: CSR_EEPROM_GP: 0X00000000
[324281.263115] iwlwifi 0000:3a:00.0: CSR_OTP_GP_REG: 0Xd55555d5
[324281.263131] iwlwifi 0000:3a:00.0: CSR_GIO_REG: 0X001f0042
[324281.263146] iwlwifi 0000:3a:00.0: CSR_GP_UCODE_REG: 0X00000000
[324281.263162] iwlwifi 0000:3a:00.0: CSR_GP_DRIVER_REG: 0X00000000
[324281.263177] iwlwifi 0000:3a:00.0: CSR_UCODE_DRV_GP1: 0X00000000
[324281.263192] iwlwifi 0000:3a:00.0: CSR_UCODE_DRV_GP2: 0X00000000
[324281.263208] iwlwifi 0000:3a:00.0: CSR_LED_REG: 0X00000060
[324281.263223] iwlwifi 0000:3a:00.0: CSR_DRAM_INT_TBL_REG: 0X88272f5f
[324281.263238] iwlwifi 0000:3a:00.0: CSR_GIO_CHICKEN_BITS: 0X27800200
[324281.263253] iwlwifi 0000:3a:00.0: CSR_ANA_PLL_CFG: 0Xd55555d5
[324281.263272] iwlwifi 0000:3a:00.0: CSR_MONITOR_STATUS_REG: 0Xc3b7ff57
[324281.263293] iwlwifi 0000:3a:00.0: CSR_HW_REV_WA_REG: 0X0001001a
[324281.263311] iwlwifi 0000:3a:00.0: CSR_DBG_HPET_MEM_REG: 0Xffff0010
[324281.263317] iwlwifi 0000:3a:00.0: FH register values:
[324281.263347] iwlwifi 0000:3a:00.0:
FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X274eac00
[324281.263374] iwlwifi 0000:3a:00.0:
FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X0274eaf0
[324281.263401] iwlwifi 0000:3a:00.0:
FH_RSCSR_CHNL0_WPTR: 0X00000000
[324281.263427] iwlwifi 0000:3a:00.0:
FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X00801114
[324281.263454] iwlwifi 0000:3a:00.0:
FH_MEM_RSSR_SHARED_CTRL_REG: 0X000000fc
[324281.263482] iwlwifi 0000:3a:00.0:
FH_MEM_RSSR_RX_STATUS_REG: 0X03030000
[324281.263509] iwlwifi 0000:3a:00.0:
FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X00000000
[324281.263535] iwlwifi 0000:3a:00.0:
FH_TSSR_TX_STATUS_REG: 0X07ff0001
[324281.263598] iwlwifi 0000:3a:00.0:
FH_TSSR_TX_ERROR_REG: 0X00000000
[324281.263732] iwlwifi 0000:3a:00.0: Start IWL Error Log Dump:
[324281.263739] iwlwifi 0000:3a:00.0: Status: 0x00000000, count: 6
[324281.263745] iwlwifi 0000:3a:00.0: Loaded firmware version: 21.302800.0
[324281.263751] iwlwifi 0000:3a:00.0: 0x00000084 | NMI_INTERRUPT_UNKNOWN
[324281.263756] iwlwifi 0000:3a:00.0: 0x000002F3 | trm_hw_status0
[324281.263762] iwlwifi 0000:3a:00.0: 0x00000000 | trm_hw_status1
[324281.263767] iwlwifi 0000:3a:00.0: 0x000401D4 | branchlink2
[324281.263772] iwlwifi 0000:3a:00.0: 0x00049A60 | interruptlink1
[324281.263777] iwlwifi 0000:3a:00.0: 0x000069F6 | interruptlink2
[324281.263782] iwlwifi 0000:3a:00.0: 0x00000000 | data1
[324281.263787] iwlwifi 0000:3a:00.0: 0x00000080 | data2
[324281.263793] iwlwifi 0000:3a:00.0: 0x03030000 | data3
[324281.263798] iwlwifi 0000:3a:00.0: 0xE280296F | beacon time
[324281.263804] iwlwifi 0000:3a:00.0: 0x0188C690 | tsf low
[324281.263809] iwlwifi 0000:3a:00.0: 0x00000233 | tsf hi
[324281.263814] iwlwifi 0000:3a:00.0: 0x00000000 | time gp1
[324281.263819] iwlwifi 0000:3a:00.0: 0x2E22C83F | time gp2
[324281.263825] iwlwifi 0000:3a:00.0: 0x00000000 | uCode revision type
[324281.263832] iwlwifi 0000:3a:00.0: 0x00000015 | uCode version major
[324281.263838] iwlwifi 0000:3a:00.0: 0x00049ED0 | uCode version minor
[324281.263844] iwlwifi 0000:3a:00.0: 0x00000210 | hw version
[324281.263850] iwlwifi 0000:3a:00.0: 0x00489200 | board version
[324281.263857] iwlwifi 0000:3a:00.0: 0x10FF001C | hcmd
[324281.263862] iwlwifi 0000:3a:00.0: 0x26E22002 | isr0
[324281.263868] iwlwifi 0000:3a:00.0: 0x01804000 | isr1
[324281.263873] iwlwifi 0000:3a:00.0: 0x00000002 | isr2
[324281.263879] iwlwifi 0000:3a:00.0: 0x40400080 | isr3
[324281.263883] iwlwifi 0000:3a:00.0: 0x00000000 | isr4
[324281.263888] iwlwifi 0000:3a:00.0: 0x10800112 | last cmd Id
[324281.263894] iwlwifi 0000:3a:00.0: 0x00000000 | wait_event
[324281.263899] iwlwifi 0000:3a:00.0: 0x00000288 | l2p_control
[324281.263904] iwlwifi 0000:3a:00.0: 0x00001C22 | l2p_duration
[324281.263909] iwlwifi 0000:3a:00.0: 0x000000BF | l2p_mhvalid
[324281.263914] iwlwifi 0000:3a:00.0: 0x00000020 | l2p_addr_match
[324281.263919] iwlwifi 0000:3a:00.0: 0x00000007 | lmpm_pmg_sel
[324281.263925] iwlwifi 0000:3a:00.0: 0x09031909 | timestamp
[324281.263931] iwlwifi 0000:3a:00.0: 0x00340010 | flow_handler
[324281.263940] ieee80211 phy0: Hardware restart was requested
[324281.668963] iwlwifi 0000:3a:00.0: L1 Enabled - LTR Disabled
[324281.669167] iwlwifi 0000:3a:00.0: L1 Enabled - LTR Disabled
[324281.734332] iwlwifi 0000:3a:00.0: L1 Enabled - LTR Disabled
[324281.734597] iwlwifi 0000:3a:00.0: L1 Enabled - LTR Disabled
Earlier on the same boot I got:
[266562.042662] ------------[ cut here ]------------
[266562.042693] WARNING: CPU: 2 PID: 994 at
drivers/net/wireless/intel/iwlwifi/mvm/tx.c:1377
iwl_mvm_rx_tx_cmd+0x665/0x870 [iwlmvm]
[266562.042697] Modules linked in: rfcomm fuse ccm xt_CHECKSUM
ipt_MASQUERADE nf_nat_masquerade_ipv4 tun nf_conntrack_netbios_ns
nf_conntrack_broadcast ip6t_REJECT nf_reject_ipv6 xt_conntrack
ip6t_rpfilter ebtable_broute bridge stp llc ebtable_nat
ip6table_mangle ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6
nf_nat_ipv6 ip6table_raw ip6table_security iptable_mangle iptable_nat
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack
iptable_raw iptable_security ebtable_filter ebtables ip6table_filter
ip6_tables cmac bnep arc4 iwlmvm vfat fat mac80211 snd_hda_codec_hdmi
snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel
snd_hda_codec iwlwifi intel_rapl snd_hwdep x86_pkg_temp_thermal
hid_multitouch coretemp snd_hda_core kvm_intel kvm snd_seq btusb btrtl
cfg80211 btbcm snd_seq_device btintel
[266562.042780] snd_pcm bluetooth uvcvideo i2c_designware_platform
iTCO_wdt iTCO_vendor_support i2c_designware_core snd_timer
videobuf2_vmalloc dell_wmi videobuf2_memops snd videobuf2_v4l2
videobuf2_core videodev mei_me dell_laptop dell_smbios mei dcdbas
irqbypass efi_pstore joydev rtsx_pci_ms memstick efivars media pcspkr
soundcore i2c_i801 shpchp rfkill idma64 processor_thermal_device
intel_soc_dts_iosf intel_lpss_pci wmi nfsd acpi_als kfifo_buf tpm_tis
industrialio auth_rpcgss pinctrl_sunrisepoint int3400_thermal
intel_lpss_acpi pinctrl_intel tpm intel_lpss nfs_acl intel_hid
acpi_thermal_rel lockd int3403_thermal int340x_thermal_zone
sparse_keymap acpi_pad grace sunrpc binfmt_misc dm_crypt i915
i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt
fb_sys_fops rtsx_pci_sdmmc mmc_core drm crct10dif_pclmul
[266562.042923] crc32_pclmul crc32c_intel ghash_clmulni_intel
serio_raw rtsx_pci i2c_hid video i2c_dev
[266562.042944] CPU: 2 PID: 994 Comm: irq/283-iwlwifi Tainted: G
W 4.7.0-xps13+ #113
[266562.042950] Hardware name: Dell Inc. XPS 13 9350/07TYC2, BIOS
1.4.4 06/14/2016
[266562.042956] 0000000000000286 000000009bd58e95 ffff880273217bb0
ffffffff81462534
[266562.042967] 0000000000000000 0000000000000000 ffff880273217bf0
ffffffff81097a4b
[266562.042976] 0000056175c08720 0000000000000000 0000000000000d14
0000000000000d14
[266562.042986] Call Trace:
[266562.043000] [<ffffffff81462534>] dump_stack+0x65/0x91
[266562.043008] [<ffffffff81097a4b>] __warn+0xcb/0xf0
[266562.043016] [<ffffffff81097b7d>] warn_slowpath_null+0x1d/0x20
[266562.043043] [<ffffffffa085e2e5>] iwl_mvm_rx_tx_cmd+0x665/0x870 [iwlmvm]
[266562.043065] [<ffffffffa0854605>] iwl_mvm_rx_common+0x165/0x260 [iwlmvm]
[266562.043082] [<ffffffffa085475b>] iwl_mvm_rx+0x5b/0x70 [iwlmvm]
[266562.043102] [<ffffffffa0734979>] iwl_pcie_rx_handle+0x319/0x950 [iwlwifi]
[266562.043127] [<ffffffffa07363cb>] iwl_pcie_irq_handler+0x4db/0xb10 [iwlwifi]
[266562.043137] [<ffffffff810f51c0>] ? irq_forced_thread_fn+0x70/0x70
[266562.043144] [<ffffffff810f51e0>] irq_thread_fn+0x20/0x50
[266562.043152] [<ffffffff810f54ad>] irq_thread+0x12d/0x1c0
[266562.043162] [<ffffffff81887773>] ? __schedule+0x2f3/0x7b0
[266562.043169] [<ffffffff810f52d0>] ? wake_threads_waitq+0x30/0x30
[266562.043177] [<ffffffff810f5380>] ? irq_thread_dtor+0xb0/0xb0
[266562.043186] [<ffffffff810b7808>] kthread+0xd8/0xf0
[266562.043197] [<ffffffff8188c7bf>] ret_from_fork+0x1f/0x40
[266562.043207] [<ffffffff810b7730>] ? kthread_worker_fn+0x160/0x160
[266562.043215] ---[ end trace fc942b7f981b5787 ]---
[266563.131187] ------------[ cut here ]------------
^ permalink raw reply
* [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
From: Stephan Mueller @ 2016-08-07 9:36 UTC (permalink / raw)
To: Ted Tso
Cc: herbert, linux-kernel, linux-crypto, ath9k-devel, linux-wireless,
ath9k-devel, Kalle Valo, Jason Cooper
In-Reply-To: <34197429.2CvoIfft9B@positron.chronox.de>
The ATH9K driver implements an RNG which is completely bypassing the
standard Linux HW generator logic.
The RNG may or may not deliver entropy. Considering the conservative
approach in treating entropy with respect to non-auditable sources, this
patch changes the delivered entropy value to zero. The RNG still feeds
data into the input_pool but it is assumed to have no entropy.
When the ATH9K RNG changes to use the HW RNG framework, it may re-enable
the entropy estimation considering that a user can change that value at
boot and runtime.
Reviewed-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
drivers/net/wireless/ath/ath9k/rng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/rng.c b/drivers/net/wireless/ath/ath9k/rng.c
index d38e50f..1ed8338 100644
--- a/drivers/net/wireless/ath/ath9k/rng.c
+++ b/drivers/net/wireless/ath/ath9k/rng.c
@@ -22,7 +22,6 @@
#include "ar9003_phy.h"
#define ATH9K_RNG_BUF_SIZE 320
-#define ATH9K_RNG_ENTROPY(x) (((x) * 8 * 320) >> 10) /* quality: 320/1024 */
static int ath9k_rng_data_read(struct ath_softc *sc, u32 *buf, u32 buf_size)
{
@@ -92,8 +91,7 @@ static int ath9k_rng_kthread(void *data)
fail_stats = 0;
/* sleep until entropy bits under write_wakeup_threshold */
- add_hwgenerator_randomness((void *)rng_buf, bytes_read,
- ATH9K_RNG_ENTROPY(bytes_read));
+ add_hwgenerator_randomness((void *)rng_buf, bytes_read, 0);
}
kfree(rng_buf);
--
2.7.4
^ permalink raw reply related
* Re: TCP data throughput for BCM43362
From: Arend van Spriel @ 2016-08-07 11:41 UTC (permalink / raw)
To: Jörg Krause, Franky Lin
Cc: Brett Rudley, brcm80211-dev-list, Hante Meuleman, Franky Lin,
linux-wireless, Arend van Spriel
In-Reply-To: <1470492734.2120.0.camel@embedded.rocks>
On 06-08-16 16:12, Jörg Krause wrote:
> Hi all,
A bit weird email format making it a bit hard to determine where your
last reply starts...
> On Fr, 2016-08-05 at 17:56 -0700, Franky Lin wrote:
>
> On Fri, Aug 5, 2016 at 2:29 PM, Jörg Krause <joerg.krause@embedded.ro
> cks>
> wrote:
>
>
>
>
>
> Am 5. August 2016 23:01:10 MESZ, schrieb Arend Van Spriel <
> arend.vanspriel@broadcom.com>:
>
>
> Op 5 aug. 2016 22:46 schreef "Jörg Krause"
> <joerg.krause@embedded.rocks>:
>
>
>
> Hi,
>
> I'm using a custom ARM board with an BCM43362 wifi chip from
>
> Broadcom.
>
>
> The wifi chip is attached via SDIO to the controller with a
> clock of
> 48MHz. Linux kernel version is 4.7.
>
> When measuring the network bandwidth with iperf3 I get a
> bandwith of
> only around 5 Mbps. I found a similar thread at the Broadcom
>
> community
>
>
> [1] where the test was done with a M4 CPU + BCM43362 and an
> average
> result of 3.3 Mbps.
>
> Interestingly, a BCM43362 Wi-Fi Dev Kit [2] notes a TCP data
>
> throughput
>
>
> greater than 20 Mbps.
>
> Why is the throughput I measured much lower? Note that I
> measured
> several times with almost no neighbor devices or networks.
>
> This is a test sample measured with iperf3:
>
> $ iperf3 -c 192.168.2.1 -i 1 -t 10
> Connecting to host 192.168.2.1, port 5201
> [ 4] local 192.168.2.155 port 36442 connected to
> 192.168.2.1
>
> port
>
>
> 5201
> [ ID]
> Interval Transfer Bandwidth Retr Cwnd
> [ 4] 0.00-1.00 sec 615 KBytes 5.04
> Mbits/sec 0 56.6
> KBytes
> [ 4] 1.00-2.00 sec 622 KBytes 5.10
> Mbits/sec 0 84.8
> KBytes
> [ 4] 2.00-3.00 sec 625 KBytes 5.12
> Mbits/sec 0 113
> KBytes
> [ 4] 3.00-4.00 sec 571 KBytes 4.68
> Mbits/sec 0 140
> KBytes
> [ 4] 4.00-5.00 sec 594 KBytes 4.87
> Mbits/sec 0 167
> KBytes
> [ 4] 5.00-6.00 sec 628 KBytes 5.14
> Mbits/sec 0 195
> KBytes
> [ 4] 6.00-7.00 sec 619 KBytes 5.07
> Mbits/sec 0 202
> KBytes
> [ 4] 7.00-8.00 sec 608 KBytes 4.98
> Mbits/sec 0 202
> KBytes
> [ 4] 8.00-9.00 sec 602 KBytes 4.93
> Mbits/sec 0 202
> KBytes
> [ 4] 9.00-10.00 sec 537 KBytes 4.40
> Mbits/sec 0 202
> KBytes
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval Transfer Bandwidth Retr
> [ 4] 0.00-10.00 sec 5.88 MBytes 4.93
> Mbits/sec 0 sender
> [ 4] 0.00-10.00 sec 5.68 MBytes 4.76
> Mbits/sec receiver
>
>
> Not overly familiar with iperf3. Do these lines mean you are
> doing
> bidirectional test, ie. upstream and downstream at the same time.
> Another
> thing affecting tput could be power-save.
>
>
> No, iperf3 does not support bidrectional test. Power-save is turned
> off.
>
> What does iw link say?
>
but I guess it starts here!
> I compared the results with a Cubietruck I have:
>
> # iperf3 -s
> -----------------------------------------------------------
> Server listening on 5201
> -----------------------------------------------------------
> Accepted connection from 192.168.178.46, port 42906
> [ 5] local 192.168.178.38 port 5201 connected to 192.168.178.46 port
> 42908
> [ ID] Interval Transfer Bandwidth
> [ 5] 0.00-1.00 sec 2.29 MBytes 19.2 Mbits/sec
> [ 5] 1.00-2.00 sec 2.21 MBytes 18.5 Mbits/sec
> [ 5] 2.00-3.00 sec 2.17 MBytes 18.2 Mbits/sec
> [ 5] 3.00-4.00 sec 2.09 MBytes 17.6 Mbits/sec
> [ 5] 4.00-5.00 sec 2.20 MBytes 18.5 Mbits/sec
> [ 5] 5.00-6.00 sec 2.64 MBytes 22.1 Mbits/sec
> [ 5] 6.00-7.00 sec 2.67 MBytes 22.4 Mbits/sec
> [ 5] 7.00-8.00 sec 2.62 MBytes 22.0 Mbits/sec
> [ 5] 8.00-9.00 sec 2.35 MBytes 19.8 Mbits/sec
> [ 5] 9.00-10.00 sec 2.30 MBytes 19.3 Mbits/sec
> [ 5] 10.00-10.03 sec 83.4 KBytes 23.5 Mbits/sec
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval Transfer Bandwidth Retr
> [ 5] 0.00-10.03 sec 23.9 MBytes 20.0
> Mbits/sec 0 sender
> [ 5] 0.00-10.03 sec 23.6 MBytes 19.8
> Mbits/sec receiver
>
> # iw dev wlan0 link
> Connected to xx:xx:xx:xx:xx (on wlan0)
> SSID: xxx
> freq: 2437
> tx bitrate: 65.0 MBit/s
>
> bss flags: short-preamble short-slot-time
> dtim period: 1
> beacon int: 100
Too bad RSSI is not in the output above. That may be due to a regression
in our driver which has been fixed by commit 94abd778a7bb ("brcmfmac:
add fallback for devices that do not report per-chain values"). However,
the tx bitrate seems within the same range as the other platform.
> The Cubietruck works also with the brcmfmac driver.
>
> May it depend on the NVRAM file?
Not sure. Can you tell me a bit more about the custom ARM board. Does it
use the same wifi module as Cubietruck, ie. the AMPAK AP6210? If you can
make a wireshark sniff we can check the actual bitrate and medium
density in terms of packets. Another thing to look at is the SDIO host
controller. In brcmf_sdiod_sgtable_alloc() some key values are used from
the host controller. It only logs the number of entries of the
scatter-gather table, but could you add the other values in this
function that are used to determine the number of entries.
Regards,
Arend
^ permalink raw reply
* Re: wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel
From: Ben Hutchings @ 2016-08-07 16:49 UTC (permalink / raw)
To: Johannes Berg
Cc: rasun Maiti, Ujjal Roy, Dibyajyoti Ghosh, linux-wireless, stable
[-- Attachment #1: Type: text/plain, Size: 499 bytes --]
I'm looking at commit 3d5fdff46c4b as part of the stable process.
The path it touches is only used for drivers that don't describe their
private wext handlers, right? So how can we know that the private
ioctl is using the iw_point structure and not one of the other types in
union iwreq_data? Doesn't this result in a regression when another
type is being used?
Ben.
--
Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* RE: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
From: Pan, Miaoqing @ 2016-08-08 2:03 UTC (permalink / raw)
To: Stephan Mueller, Ted Tso, Sepehrdad, Pouyan
Cc: herbert@gondor.apana.org.au, linux-kernel@vger.kernel.org,
linux-crypto@vger.kernel.org, ath9k-devel,
linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org,
Kalle Valo, Jason Cooper
In-Reply-To: <1654172.XfclnXhRmn@positron.chronox.de>
The entropy was evaluated by crypto expert, the analysis report show the ADC with at least 10bits and up to 22 bits of min-entropy for a 32 bits value, we conservatively assume the min-entropy is 10 bits out of 32 bits, so that's why set entropy quality to 320/1024 = 10/32. Also we have explained in the commit message why can't use the HW RNG framework.
Otherwise, your patch will cause high CPU load, as continuously read ADC data if entropy bits under write_wakeup_threshold.
--
Miaoqing
-----Original Message-----
From: Stephan Mueller [mailto:smueller@chronox.de]
Sent: Sunday, August 07, 2016 5:36 PM
To: Ted Tso <tytso@mit.edu>
Cc: herbert@gondor.apana.org.au; linux-kernel@vger.kernel.org; linux-crypto@vger.kernel.org; ath9k-devel <ath9k-devel@qca.qualcomm.com>; linux-wireless@vger.kernel.org; ath9k-devel@lists.ath9k.org; Kalle Valo <kvalo@codeaurora.org>; Jason Cooper <jason@lakedaemon.net>
Subject: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
The ATH9K driver implements an RNG which is completely bypassing the standard Linux HW generator logic.
The RNG may or may not deliver entropy. Considering the conservative approach in treating entropy with respect to non-auditable sources, this patch changes the delivered entropy value to zero. The RNG still feeds data into the input_pool but it is assumed to have no entropy.
When the ATH9K RNG changes to use the HW RNG framework, it may re-enable the entropy estimation considering that a user can change that value at boot and runtime.
Reviewed-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
drivers/net/wireless/ath/ath9k/rng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/rng.c b/drivers/net/wireless/ath/ath9k/rng.c
index d38e50f..1ed8338 100644
--- a/drivers/net/wireless/ath/ath9k/rng.c
+++ b/drivers/net/wireless/ath/ath9k/rng.c
@@ -22,7 +22,6 @@
#include "ar9003_phy.h"
#define ATH9K_RNG_BUF_SIZE 320
-#define ATH9K_RNG_ENTROPY(x) (((x) * 8 * 320) >> 10) /* quality: 320/1024 */
static int ath9k_rng_data_read(struct ath_softc *sc, u32 *buf, u32 buf_size) { @@ -92,8 +91,7 @@ static int ath9k_rng_kthread(void *data)
fail_stats = 0;
/* sleep until entropy bits under write_wakeup_threshold */
- add_hwgenerator_randomness((void *)rng_buf, bytes_read,
- ATH9K_RNG_ENTROPY(bytes_read));
+ add_hwgenerator_randomness((void *)rng_buf, bytes_read, 0);
}
kfree(rng_buf);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
From: Stephan Mueller @ 2016-08-08 6:41 UTC (permalink / raw)
To: Pan, Miaoqing
Cc: Ted Tso, Sepehrdad, Pouyan, herbert@gondor.apana.org.au,
linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
ath9k-devel, linux-wireless@vger.kernel.org,
ath9k-devel@lists.ath9k.org, Kalle Valo, Jason Cooper
In-Reply-To: <657897b90b8344eeab10d7a0f604988d@aptaiexm02f.ap.qualcomm.com>
Am Montag, 8. August 2016, 02:03:36 CEST schrieb Pan, Miaoqing:
Hi Miaoqing,
> The entropy was evaluated by crypto expert, the analysis report show the
> ADC with at least 10bits and up to 22 bits of min-entropy for a 32 bits
> value, we conservatively assume the min-entropy is 10 bits out of 32 bits,
> so that's why set entropy quality to 320/1024 = 10/32. Also we have
> explained in the commit message why can't use the HW RNG framework.
Where is the description of the RNG, where is the test implementation?
>
> Otherwise, your patch will cause high CPU load, as continuously read ADC
> data if entropy bits under write_wakeup_threshold.
The issue is that although you may have analyzed it, others are unable to
measure the quality of the RNG and assess the design as well as the
implementation of the RNG. This RNG is the only implementation of a hardware
RNG that per default and without being able to change it at runtime injects
data into the input_pool where the noise source cannot be audited. Note, even
other respected RNG noise sources like the Intel RDRAND will not feed into /
dev/random per default in a way that dominates all other noise sources.
I would like to be able to deactivate that noise source to the extent that it
does not cause /dev/random to unblock. The reason is that your noise source
starts to dominate all other noise sources.
If you think that this patch is a challenge because your driver starts to
spin, please help and offer another solution.
>
> --
> Miaoqing
>
> -----Original Message-----
> From: Stephan Mueller [mailto:smueller@chronox.de]
> Sent: Sunday, August 07, 2016 5:36 PM
> To: Ted Tso <tytso@mit.edu>
> Cc: herbert@gondor.apana.org.au; linux-kernel@vger.kernel.org;
> linux-crypto@vger.kernel.org; ath9k-devel <ath9k-devel@qca.qualcomm.com>;
> linux-wireless@vger.kernel.org; ath9k-devel@lists.ath9k.org; Kalle Valo
> <kvalo@codeaurora.org>; Jason Cooper <jason@lakedaemon.net> Subject: [PATCH
> v2] RANDOM: ATH9K RNG delivers zero bits of entropy
>
> The ATH9K driver implements an RNG which is completely bypassing the
> standard Linux HW generator logic.
>
> The RNG may or may not deliver entropy. Considering the conservative
> approach in treating entropy with respect to non-auditable sources, this
> patch changes the delivered entropy value to zero. The RNG still feeds data
> into the input_pool but it is assumed to have no entropy.
>
> When the ATH9K RNG changes to use the HW RNG framework, it may re-enable
the
> entropy estimation considering that a user can change that value at boot
> and runtime.
>
> Reviewed-by: Jason Cooper <jason@lakedaemon.net>
> Signed-off-by: Stephan Mueller <smueller@chronox.de>
> ---
> drivers/net/wireless/ath/ath9k/rng.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/rng.c
> b/drivers/net/wireless/ath/ath9k/rng.c index d38e50f..1ed8338 100644
> --- a/drivers/net/wireless/ath/ath9k/rng.c
> +++ b/drivers/net/wireless/ath/ath9k/rng.c
> @@ -22,7 +22,6 @@
> #include "ar9003_phy.h"
>
> #define ATH9K_RNG_BUF_SIZE 320
> -#define ATH9K_RNG_ENTROPY(x) (((x) * 8 * 320) >> 10) /* quality: 320/1024
> */
>
> static int ath9k_rng_data_read(struct ath_softc *sc, u32 *buf, u32
> buf_size) { @@ -92,8 +91,7 @@ static int ath9k_rng_kthread(void *data)
> fail_stats = 0;
>
> /* sleep until entropy bits under write_wakeup_threshold */
> - add_hwgenerator_randomness((void *)rng_buf, bytes_read,
> - ATH9K_RNG_ENTROPY(bytes_read));
> + add_hwgenerator_randomness((void *)rng_buf, bytes_read, 0);
> }
>
> kfree(rng_buf);
> --
> 2.7.4
Ciao
Stephan
^ permalink raw reply
* Re: wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel
From: Johannes Berg @ 2016-08-08 6:45 UTC (permalink / raw)
To: Ben Hutchings
Cc: rasun Maiti, Ujjal Roy, Dibyajyoti Ghosh, linux-wireless, stable
In-Reply-To: <1470588577.4325.4.camel@decadent.org.uk>
On Sun, 2016-08-07 at 17:49 +0100, Ben Hutchings wrote:
> I'm looking at commit 3d5fdff46c4b as part of the stable process.
>
> The path it touches is only used for drivers that don't describe
> their private wext handlers, right? So how can we know that the
> private ioctl is using the iw_point structure and not one of the
> other types in union iwreq_data? Doesn't this result in a regression
> when another type is being used?
>
Crap, that's good point. I'll revert the patch.
Fortunately this code path is never actually used. The only "mainline"
driver that appears to use it is staging/wilc1000.
I wonder if we should just remove it entirely. Yes, it'd break that
staging driver to some extent, but it's clearly an unsafe code path.
Prasun, did you need this for the mwifiex wext ioctl support that was
shot down anyway?
johannes
^ permalink raw reply
* [PATCH] Revert "wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel"
From: Johannes Berg @ 2016-08-08 6:50 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Hutchings, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
This reverts commit 3d5fdff46c4b2b9534fa2f9fc78e90a48e0ff724.
Ben Hutchings pointed out that the commit isn't safe since it assumes
that the structure used by the driver is iw_point, when in fact there's
no way to know about that.
Fortunately, the only driver in the tree that ever runs this code path
is the wilc1000 staging driver, so it doesn't really matter.
Clearly I should have investigated this better before applying, sorry.
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Cc: stable@vger.kernel.org [though I guess it doesn't matter much]
Fixes: 3d5fdff46c4b ("wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/wext-core.c | 25 ++-----------------------
1 file changed, 2 insertions(+), 23 deletions(-)
diff --git a/net/wireless/wext-core.c b/net/wireless/wext-core.c
index dbb2738e356a..6250b1cfcde5 100644
--- a/net/wireless/wext-core.c
+++ b/net/wireless/wext-core.c
@@ -958,29 +958,8 @@ static int wireless_process_ioctl(struct net *net, struct ifreq *ifr,
return private(dev, iwr, cmd, info, handler);
}
/* Old driver API : call driver ioctl handler */
- if (dev->netdev_ops->ndo_do_ioctl) {
-#ifdef CONFIG_COMPAT
- if (info->flags & IW_REQUEST_FLAG_COMPAT) {
- int ret = 0;
- struct iwreq iwr_lcl;
- struct compat_iw_point *iwp_compat = (void *) &iwr->u.data;
-
- memcpy(&iwr_lcl, iwr, sizeof(struct iwreq));
- iwr_lcl.u.data.pointer = compat_ptr(iwp_compat->pointer);
- iwr_lcl.u.data.length = iwp_compat->length;
- iwr_lcl.u.data.flags = iwp_compat->flags;
-
- ret = dev->netdev_ops->ndo_do_ioctl(dev, (void *) &iwr_lcl, cmd);
-
- iwp_compat->pointer = ptr_to_compat(iwr_lcl.u.data.pointer);
- iwp_compat->length = iwr_lcl.u.data.length;
- iwp_compat->flags = iwr_lcl.u.data.flags;
-
- return ret;
- } else
-#endif
- return dev->netdev_ops->ndo_do_ioctl(dev, ifr, cmd);
- }
+ if (dev->netdev_ops->ndo_do_ioctl)
+ return dev->netdev_ops->ndo_do_ioctl(dev, ifr, cmd);
return -EOPNOTSUPP;
}
--
2.8.1
^ permalink raw reply related
* [PATCH v3] mac80211: mesh: set tx_info->hw_queue to the correct queue upon packet forwarding
From: Yaniv Machani @ 2016-08-08 7:06 UTC (permalink / raw)
To: linux-kernel
Cc: Meirav Kama, Yaniv Machani, Johannes Berg, David S. Miller,
linux-wireless, netdev
From: Meirav Kama <meiravk@ti.com>
MP received data frames from another MP. Frames are forwarded
from Rx to Tx to be transmitted to a third MP.
Upon cloning the skb, the tx_info was zeroed, and the
hw_queue wasn't set correctly, causing frames to be
inserted to queue 0 (VOICE). If re-queue occurred for some
reason, frame will be inserted to correct queue 2 (BE).
In this case frames are now dequeued from 2 different queues and
sent out of order.
Signed-off-by: Meirav Kama <meiravk@ti.com>
Signed-off-by: Yaniv Machani <yanivma@ti.com>
---
v3 - update the headline
net/mac80211/rx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 9a1eb70..88dc744 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2392,6 +2392,7 @@ ieee80211_rx_h_mesh_fwding(struct ieee80211_rx_data *rx)
info->flags |= IEEE80211_TX_INTFL_NEED_TXPROCESSING;
info->control.vif = &rx->sdata->vif;
info->control.jiffies = jiffies;
+ info->hw_queue = q;
if (is_multicast_ether_addr(fwd_hdr->addr1)) {
IEEE80211_IFSTA_MESH_CTR_INC(ifmsh, fwded_mcast);
memcpy(fwd_hdr->addr2, sdata->vif.addr, ETH_ALEN);
--
2.9.0
^ permalink raw reply related
* [PATCH 1/2] mwifiex: fix the length parameter of a memset
From: Christophe JAILLET @ 2016-08-08 7:38 UTC (permalink / raw)
To: akarwar, nishants, linux-wireless
Cc: netdev, linux-kernel, kernel-janitors, Christophe JAILLET
In 'mwifiex_get_ver_ext', we have:
struct mwifiex_ver_ext ver_ext;
memset(&ver_ext, 0, sizeof(struct host_cmd_ds_version_ext));
This is likely that memset'ing sizeof(struct mwifiex_ver_ext) was expected.
Remove the ambiguity by using the variable name directly instead of its
type.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/net/wireless/marvell/mwifiex/sta_ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c b/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
index e06647a..78819e8 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
@@ -1180,7 +1180,7 @@ mwifiex_get_ver_ext(struct mwifiex_private *priv, u32 version_str_sel)
{
struct mwifiex_ver_ext ver_ext;
- memset(&ver_ext, 0, sizeof(struct host_cmd_ds_version_ext));
+ memset(&ver_ext, 0, sizeof(ver_ext));
ver_ext.version_str_sel = version_str_sel;
if (mwifiex_send_cmd(priv, HostCmd_CMD_VERSION_EXT,
HostCmd_ACT_GEN_GET, 0, &ver_ext, true))
--
2.7.4
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
^ permalink raw reply related
* [PATCH 2/2] mwifiex: simplify length computation for some memset
From: Christophe JAILLET @ 2016-08-08 7:39 UTC (permalink / raw)
To: akarwar, nishants, linux-wireless
Cc: netdev, linux-kernel, kernel-janitors, Christophe JAILLET
This patch should be a no-op. It just simplifies code by using the name of
a variable instead of its type when calling 'sizeof'.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/net/wireless/marvell/mwifiex/sta_ioctl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c b/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
index 78819e8..644f3a2 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
@@ -574,7 +574,7 @@ int mwifiex_enable_hs(struct mwifiex_adapter *adapter)
adapter->hs_activate_wait_q_woken = false;
- memset(&hscfg, 0, sizeof(struct mwifiex_ds_hs_cfg));
+ memset(&hscfg, 0, sizeof(hscfg));
hscfg.is_invoke_hostcmd = true;
adapter->hs_enabling = true;
@@ -1138,7 +1138,7 @@ int mwifiex_set_encode(struct mwifiex_private *priv, struct key_params *kp,
{
struct mwifiex_ds_encrypt_key encrypt_key;
- memset(&encrypt_key, 0, sizeof(struct mwifiex_ds_encrypt_key));
+ memset(&encrypt_key, 0, sizeof(encrypt_key));
encrypt_key.key_len = key_len;
encrypt_key.key_index = key_index;
--
2.7.4
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
^ permalink raw reply related
* [PATCH] wlcore: mesh: add zone time sync support
From: Guy Mishol @ 2016-08-08 8:57 UTC (permalink / raw)
To: linux-wireless; +Cc: Guy Mishol
Add zone time sync support for mesh role.
This allows to configure the mesh peer
master of each zone for time synchronization.
Signed-off-by: Guy Mishol <guym@ti.com>
---
drivers/net/wireless/ti/wl18xx/acx.c | 29 ++++++++++++++++
drivers/net/wireless/ti/wl18xx/acx.h | 13 +++++++
drivers/net/wireless/ti/wl18xx/debugfs.c | 59 ++++++++++++++++++++++++++++++++
drivers/net/wireless/ti/wl18xx/event.c | 1 +
drivers/net/wireless/ti/wlcore/wlcore.h | 3 ++
5 files changed, 105 insertions(+)
diff --git a/drivers/net/wireless/ti/wl18xx/acx.c b/drivers/net/wireless/ti/wl18xx/acx.c
index 4be0409..b5525a3 100644
--- a/drivers/net/wireless/ti/wl18xx/acx.c
+++ b/drivers/net/wireless/ti/wl18xx/acx.c
@@ -309,3 +309,32 @@ out:
kfree(acx);
return ret;
}
+
+int wl18xx_acx_time_sync_cfg(struct wl1271 *wl)
+{
+ struct acx_time_sync_cfg *acx;
+ int ret;
+
+ wl1271_debug(DEBUG_ACX, "acx time sync cfg: mode %d, addr: %pM",
+ wl->conf.sg.params[WL18XX_CONF_SG_TIME_SYNC],
+ wl->zone_master_mac_addr);
+
+ acx = kzalloc(sizeof(*acx), GFP_KERNEL);
+ if (!acx) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ acx->sync_mode = wl->conf.sg.params[WL18XX_CONF_SG_TIME_SYNC];
+ memcpy(acx->zone_mac_addr, wl->zone_master_mac_addr, ETH_ALEN);
+
+ ret = wl1271_cmd_configure(wl, ACX_TIME_SYNC_CFG,
+ acx, sizeof(*acx));
+ if (ret < 0) {
+ wl1271_warning("acx time sync cfg failed: %d", ret);
+ goto out;
+ }
+out:
+ kfree(acx);
+ return ret;
+}
diff --git a/drivers/net/wireless/ti/wl18xx/acx.h b/drivers/net/wireless/ti/wl18xx/acx.h
index 342a299..2edbbbf 100644
--- a/drivers/net/wireless/ti/wl18xx/acx.h
+++ b/drivers/net/wireless/ti/wl18xx/acx.h
@@ -37,6 +37,7 @@ enum {
ACX_RX_BA_FILTER = 0x0058,
ACX_AP_SLEEP_CFG = 0x0059,
ACX_DYNAMIC_TRACES_CFG = 0x005A,
+ ACX_TIME_SYNC_CFG = 0x005B,
};
/* numbers of bits the length field takes (add 1 for the actual number) */
@@ -388,6 +389,17 @@ struct acx_dynamic_fw_traces_cfg {
__le32 dynamic_fw_traces;
} __packed;
+/*
+ * ACX_TIME_SYNC_CFG
+ * configure the time sync parameters
+ */
+struct acx_time_sync_cfg {
+ struct acx_header header;
+ u8 sync_mode;
+ u8 zone_mac_addr[ETH_ALEN];
+ u8 padding[1];
+} __packed;
+
int wl18xx_acx_host_if_cfg_bitmap(struct wl1271 *wl, u32 host_cfg_bitmap,
u32 sdio_blk_size, u32 extra_mem_blks,
u32 len_field_size);
@@ -402,5 +414,6 @@ int wl18xx_acx_interrupt_notify_config(struct wl1271 *wl, bool action);
int wl18xx_acx_rx_ba_filter(struct wl1271 *wl, bool action);
int wl18xx_acx_ap_sleep(struct wl1271 *wl);
int wl18xx_acx_dynamic_fw_traces(struct wl1271 *wl);
+int wl18xx_acx_time_sync_cfg(struct wl1271 *wl);
#endif /* __WL18XX_ACX_H__ */
diff --git a/drivers/net/wireless/ti/wl18xx/debugfs.c b/drivers/net/wireless/ti/wl18xx/debugfs.c
index 86ccf84..9e28748 100644
--- a/drivers/net/wireless/ti/wl18xx/debugfs.c
+++ b/drivers/net/wireless/ti/wl18xx/debugfs.c
@@ -408,6 +408,64 @@ static const struct file_operations radar_debug_mode_ops = {
};
#endif /* CFG80211_CERTIFICATION_ONUS */
+static ssize_t time_sync_zone_addr_write(struct file *file,
+ const char __user *user_buf,
+ size_t count, loff_t *ppos) {
+ struct wl1271 *wl = file->private_data;
+ char buf[(ETH_ALEN * 2)];
+ int ret;
+
+ if (count < (ETH_ALEN * 2 + 1)) {
+ wl1271_warning("Illegal MAC address: wrong size");
+ return -EINVAL;
+ }
+
+ ret = copy_from_user(buf, user_buf, (ETH_ALEN * 2));
+ if (ret < 0)
+ return ret;
+
+ ret = hex2bin(wl->zone_master_mac_addr, buf, ETH_ALEN);
+ if (ret < 0) {
+ wl1271_warning("Illegal MAC address: invalid characters");
+ return ret;
+ }
+
+ mutex_lock(&wl->mutex);
+
+ if (unlikely(wl->state != WLCORE_STATE_ON))
+ goto out;
+
+ ret = wl1271_ps_elp_wakeup(wl);
+ if (ret < 0)
+ goto out;
+
+ ret = wl18xx_acx_time_sync_cfg(wl);
+ if (ret < 0)
+ count = ret;
+
+ wl1271_ps_elp_sleep(wl);
+out:
+ mutex_unlock(&wl->mutex);
+ return count;
+}
+
+static ssize_t time_sync_zone_addr_read(struct file *file,
+ char __user *userbuf,
+ size_t count, loff_t *ppos)
+{
+ struct wl1271 *wl = file->private_data;
+
+ return wl1271_format_buffer(userbuf, count, ppos,
+ "%pM\n", wl->zone_master_mac_addr);
+}
+
+static const struct file_operations time_sync_zone_addr_ops = {
+ .write = time_sync_zone_addr_write,
+ .read = time_sync_zone_addr_read,
+ .open = simple_open,
+ .llseek = default_llseek,
+};
+
int wl18xx_debugfs_add_files(struct wl1271 *wl,
struct dentry *rootdir)
{
@@ -576,6 +634,7 @@ int wl18xx_debugfs_add_files(struct wl1271 *wl,
#ifdef CONFIG_CFG80211_CERTIFICATION_ONUS
DEBUGFS_ADD(radar_debug_mode, moddir);
#endif
+ DEBUGFS_ADD(time_sync_zone_addr, moddir);
DEBUGFS_ADD(dynamic_fw_traces, moddir);
return 0;
diff --git a/drivers/net/wireless/ti/wl18xx/event.c b/drivers/net/wireless/ti/wl18xx/event.c
index 2c5df43..b36ce18 100644
--- a/drivers/net/wireless/ti/wl18xx/event.c
+++ b/drivers/net/wireless/ti/wl18xx/event.c
@@ -22,6 +22,7 @@
#include <net/genetlink.h>
#include "event.h"
#include "scan.h"
+#include "conf.h"
#include "../wlcore/cmd.h"
#include "../wlcore/debug.h"
#include "../wlcore/vendor_cmd.h"
diff --git a/drivers/net/wireless/ti/wlcore/wlcore.h b/drivers/net/wireless/ti/wlcore/wlcore.h
index 8f28aa0..1827546 100644
--- a/drivers/net/wireless/ti/wlcore/wlcore.h
+++ b/drivers/net/wireless/ti/wlcore/wlcore.h
@@ -501,6 +501,9 @@ struct wl1271 {
/* dynamic fw traces */
u32 dynamic_fw_traces;
+
+ /* time sync zone master */
+ u8 zone_master_mac_addr[ETH_ALEN];
};
int wlcore_probe(struct wl1271 *wl, struct platform_device *pdev);
--
2.6.4
^ permalink raw reply related
* wireless-testing on 4.8-rc1
From: Bob Copeland @ 2016-08-08 13:04 UTC (permalink / raw)
To: linux-wireless
Hi all,
Now that Linus closed the merge window for 4.8, I'm resuming near-daily
wireless-testing builds at:
http://git.kernel.org/cgit/linux/kernel/git/wireless/wireless-testing.git
The first tag in this series is wt-2016-08-08. Let us know of any issues.
--
Bob Copeland %% http://bobcopeland.com/
^ permalink raw reply
* [5.3] ucc_geth: Fix to avoid IS_ERR_VALUE abuses and dead code on 64bit systems.
From: Arvind Yadav @ 2016-08-05 8:40 UTC (permalink / raw)
To: zajec5, leoli
Cc: qiang.zhao, scottwood, viresh.kumar, akpm, linux-wireless, netdev,
linuxppc-dev, linux, arnd, Arvind Yadav
IS_ERR_VALUE() assumes that parameter is an unsigned long.
It can not be used to check if 'unsigned int' is passed insted.
Which tends to reflect an error.
In 64bit architectures sizeof (int) == 4 && sizeof (long) == 8.
IS_ERR_VALUE(x) is ((x) >= (unsigned long)-4095).
IS_ERR_VALUE() of 'unsigned int' is always false because the 32bit
value is zero extended to 64 bits.
Now problem in Freescale QEGigabit Ethernet-:
drivers/net/ethernet/freescale/ucc_geth.c
init_enet_offset =
qe_muram_alloc(thread_size, thread_alignment);
if (IS_ERR_VALUE(init_enet_offset)) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory\n");
qe_put_snum((u8) snum);
return -ENOMEM;
}
ugeth->tx_bd_ring_offset[j] =
qe_muram_alloc(length,
UCC_GETH_TX_BD_RING_ALIGNMENT);
if (!IS_ERR_VALUE(ugeth->tx_bd_ring_offset[j]))
ugeth->p_tx_bd_ring[j] = (u8 __iomem *) qe_muram_addr(ugeth->
tx_bd_ring_offset[j]);
ugeth->rx_bd_ring_offset[j] =
qe_muram_alloc(length,
UCC_GETH_RX_BD_RING_ALIGNMENT);
if (!IS_ERR_VALUE(ugeth->rx_bd_ring_offset[j]))
ugeth->p_rx_bd_ring[j] =
(u8 __iomem *) qe_muram_addr(ugeth->
rx_bd_ring_offset[j]);
/* Allocate global tx parameter RAM page */
ugeth->tx_glbl_pram_offset =
qe_muram_alloc(sizeof(struct ucc_geth_tx_global_pram),
UCC_GETH_TX_GLOBAL_PRAM_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->tx_glbl_pram_offset)) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for p_tx_glbl_pram\n");
return -ENOMEM;
}
/* Size varies with number of Tx threads */
ugeth->thread_dat_tx_offset =
qe_muram_alloc(numThreadsTxNumerical *
sizeof(struct ucc_geth_thread_data_tx) +
32 * (numThreadsTxNumerical == 1),
UCC_GETH_THREAD_DATA_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->thread_dat_tx_offset)) {
if (netif_msg_ifup(ugeth))
pr_err
("Can not allocate DPRAM memory for p_thread_data_tx\n");
return -ENOMEM;
}
/* Size varies with number of Tx queues */
ugeth->send_q_mem_reg_offset =
qe_muram_alloc(ug_info->numQueuesTx *
sizeof(struct ucc_geth_send_queue_qd),
UCC_GETH_SEND_QUEUE_QUEUE_DESCRIPTOR_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->send_q_mem_reg_offset)) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for p_send_q_mem_reg\n");
return -ENOMEM;
}
ugeth->scheduler_offset =
qe_muram_alloc(sizeof(struct ucc_geth_scheduler),
UCC_GETH_SCHEDULER_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->scheduler_offset)) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for p_scheduler\n");
return -ENOMEM;
}
ugeth->tx_fw_statistics_pram_offset =
qe_muram_alloc(sizeof
(struct ucc_geth_tx_firmware_statistics_pram),
UCC_GETH_TX_STATISTICS_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->tx_fw_statistics_pram_offset)) {
if (netif_msg_ifup(ugeth))
pr_err(
"Can not allocate DPRAM memory for p_tx_fw_statistics_pram\n");
return -ENOMEM;
}
/* Allocate global rx parameter RAM page */
ugeth->rx_glbl_pram_offset =
qe_muram_alloc(sizeof(struct ucc_geth_rx_global_pram),
UCC_GETH_RX_GLOBAL_PRAM_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->rx_glbl_pram_offset)) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for p_rx_glbl_pram\n");
return -ENOMEM;
}
/* Size varies with number of Rx threads */
ugeth->thread_dat_rx_offset =
qe_muram_alloc(numThreadsRxNumerical *
sizeof(struct ucc_geth_thread_data_rx),
UCC_GETH_THREAD_DATA_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->thread_dat_rx_offset)) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for p_thread_data_rx\n");
return -ENOMEM;
}
ugeth->rx_fw_statistics_pram_offset =
qe_muram_alloc(sizeof
(struct ucc_geth_rx_firmware_statistics_pram),
UCC_GETH_RX_STATISTICS_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->rx_fw_statistics_pram_offset)) {
if (netif_msg_ifup(ugeth))
pr_err(
"Can not allocate DPRAM memory for p_rx_fw_statistics_pram\n");
return -ENOMEM;
}
/* Size varies with number of Rx queues */
ugeth->rx_irq_coalescing_tbl_offset =
qe_muram_alloc(ug_info->numQueuesRx *
sizeof(struct ucc_geth_rx_interrupt_coalescing_entry)
+ 4, UCC_GETH_RX_INTERRUPT_COALESCING_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->rx_irq_coalescing_tbl_offset)) {
if (netif_msg_ifup(ugeth))
pr_err(
"Can not allocate DPRAM memory for p_rx_irq_coalescing_tbl\n");
return -ENOMEM;
}
/* Size varies with number of Rx queues */
ugeth->rx_bd_qs_tbl_offset =
qe_muram_alloc(ug_info->numQueuesRx *
(sizeof(struct ucc_geth_rx_bd_queues_entry) +
sizeof(struct ucc_geth_rx_prefetched_bds)),
UCC_GETH_RX_BD_QUEUES_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->rx_bd_qs_tbl_offset)) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for p_rx_bd_qs_tbl\n");
return -ENOMEM;
}
ugeth->exf_glbl_param_offset =
qe_muram_alloc(sizeof(struct ucc_geth_exf_global_pram),
UCC_GETH_RX_EXTENDED_FILTERING_GLOBAL_PARAMETERS_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->exf_glbl_param_offset)) {
if (netif_msg_ifup(ugeth))
pr_err(
"Can not allocate DPRAM memory for p_exf_glbl_param\n");
return -ENOMEM;
}
/* Allocate InitEnet command parameter structure */
init_enet_pram_offset =
qe_muram_alloc(sizeof(struct ucc_geth_init_pram), 4);
if (IS_ERR_VALUE(init_enet_pram_offset)) {
if (netif_msg_ifup(ugeth))
pr_err(
"Can not allocate DPRAM memory for p_init_enet_pram\n");
return -ENOMEM;
}
p_init_enet_pram =
(struct ucc_geth_init_pram __iomem *)
qe_muram_addr(init_enet_pram_offset);
qe_muram_alloc (a.k.a. cpm_muram_alloc) returns unsigned long.
Return value store in a u32 (init_enet_offset, exf_glbl_param_offset,
rx_glbl_pram_offset, tx_glbl_pram_offset, send_q_mem_reg_offset,
thread_dat_tx_offset, thread_dat_rx_offset, scheduler_offset,
tx_fw_statistics_pram_offset, rx_fw_statistics_pram_offset,
rx_irq_coalescing_tbl_offset, rx_bd_qs_tbl_offset, tx_bd_ring_offset,
init_enet_pram_offset and rx_bd_ring_offset).
If qe_muram_alloc will return any error, Then IS_ERR_VALUE will always
return 0. it'll not call ucc_fast_free for any failure. Inside 'if code'
will be a dead code on 64bit. Even qe_muram_addr will return wrong
virtual address. Which can cause an error.
kfree((void *)ugeth->tx_bd_ring_offset[i]);
which is not 64-bit safe when tx_bd_ring_offset is a 32-bit value
that also holds the return value of qe_muram_alloc.
This patch is to avoid these problem on 64bit machine.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
drivers/net/ethernet/freescale/ucc_geth.c | 7 ++++---
drivers/net/ethernet/freescale/ucc_geth.h | 26 +++++++++++++-------------
2 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c
index 5bf1ade..eb1f4e2 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -273,7 +273,7 @@ static int fill_init_enet_entries(struct ucc_geth_private *ugeth,
unsigned int risc,
int skip_page_for_first_entry)
{
- u32 init_enet_offset;
+ unsigned long init_enet_offset;
u8 i;
int snum;
@@ -1871,7 +1871,7 @@ static void ucc_geth_free_rx(struct ucc_geth_private *ugeth)
if (ugeth->ug_info->uf_info.bd_mem_part ==
MEM_PART_SYSTEM)
- kfree((void *)ugeth->rx_bd_ring_offset[i]);
+ kfree(ugeth->rx_bd_ring_offset[i]);
else if (ugeth->ug_info->uf_info.bd_mem_part ==
MEM_PART_MURAM)
qe_muram_free(ugeth->rx_bd_ring_offset[i]);
@@ -2367,7 +2367,8 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
struct ucc_geth __iomem *ug_regs;
int ret_val = -EINVAL;
u32 remoder = UCC_GETH_REMODER_INIT;
- u32 init_enet_pram_offset, cecr_subblock, command;
+ unsigned long init_enet_pram_offset;
+ u32 cecr_subblock, command;
u32 ifstat, i, j, size, l2qt, l3qt;
u16 temoder = UCC_GETH_TEMODER_INIT;
u16 test;
diff --git a/drivers/net/ethernet/freescale/ucc_geth.h b/drivers/net/ethernet/freescale/ucc_geth.h
index 5da19b4..1639ffd 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.h
+++ b/drivers/net/ethernet/freescale/ucc_geth.h
@@ -1162,31 +1162,31 @@ struct ucc_geth_private {
struct ucc_geth __iomem *ug_regs;
struct ucc_geth_init_pram *p_init_enet_param_shadow;
struct ucc_geth_exf_global_pram __iomem *p_exf_glbl_param;
- u32 exf_glbl_param_offset;
+ unsigned long exf_glbl_param_offset;
struct ucc_geth_rx_global_pram __iomem *p_rx_glbl_pram;
- u32 rx_glbl_pram_offset;
+ unsigned long rx_glbl_pram_offset;
struct ucc_geth_tx_global_pram __iomem *p_tx_glbl_pram;
- u32 tx_glbl_pram_offset;
+ unsigned long tx_glbl_pram_offset;
struct ucc_geth_send_queue_mem_region __iomem *p_send_q_mem_reg;
- u32 send_q_mem_reg_offset;
+ unsigned long send_q_mem_reg_offset;
struct ucc_geth_thread_data_tx __iomem *p_thread_data_tx;
- u32 thread_dat_tx_offset;
+ unsigned long thread_dat_tx_offset;
struct ucc_geth_thread_data_rx __iomem *p_thread_data_rx;
- u32 thread_dat_rx_offset;
+ unsigned long thread_dat_rx_offset;
struct ucc_geth_scheduler __iomem *p_scheduler;
- u32 scheduler_offset;
+ unsigned long scheduler_offset;
struct ucc_geth_tx_firmware_statistics_pram __iomem *p_tx_fw_statistics_pram;
- u32 tx_fw_statistics_pram_offset;
+ unsigned long tx_fw_statistics_pram_offset;
struct ucc_geth_rx_firmware_statistics_pram __iomem *p_rx_fw_statistics_pram;
- u32 rx_fw_statistics_pram_offset;
+ unsigned long rx_fw_statistics_pram_offset;
struct ucc_geth_rx_interrupt_coalescing_table __iomem *p_rx_irq_coalescing_tbl;
- u32 rx_irq_coalescing_tbl_offset;
+ unsigned long rx_irq_coalescing_tbl_offset;
struct ucc_geth_rx_bd_queues_entry __iomem *p_rx_bd_qs_tbl;
- u32 rx_bd_qs_tbl_offset;
+ unsigned long rx_bd_qs_tbl_offset;
u8 __iomem *p_tx_bd_ring[NUM_TX_QUEUES];
- u32 tx_bd_ring_offset[NUM_TX_QUEUES];
+ unsigned long tx_bd_ring_offset[NUM_TX_QUEUES];
u8 __iomem *p_rx_bd_ring[NUM_RX_QUEUES];
- u32 rx_bd_ring_offset[NUM_RX_QUEUES];
+ unsigned long rx_bd_ring_offset[NUM_RX_QUEUES];
u8 __iomem *confBd[NUM_TX_QUEUES];
u8 __iomem *txBd[NUM_TX_QUEUES];
u8 __iomem *rxBd[NUM_RX_QUEUES];
--
1.9.1
^ permalink raw reply related
* RE: [5.3] ucc_geth: Fix to avoid IS_ERR_VALUE abuses and dead code on 64bit systems.
From: David Laight @ 2016-08-08 14:49 UTC (permalink / raw)
To: 'Arvind Yadav', zajec5@gmail.com, leoli@freescale.com
Cc: qiang.zhao@freescale.com, scottwood@freescale.com,
viresh.kumar@linaro.org, akpm@linux-foundation.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux@roeck-us.net, arnd@arndb.de
In-Reply-To: <1470386442-7208-1-git-send-email-arvind.yadav.cs@gmail.com>
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On Behalf Of Arvind Yadav
> IS_ERR_VALUE() assumes that parameter is an unsigned long.
> It can not be used to check if 'unsigned int' is passed insted.
> Which tends to reflect an error.
> In 64bit architectures sizeof (int) == 4 && sizeof (long) == 8.
> IS_ERR_VALUE(x) is ((x) >= (unsigned long)-4095).
> IS_ERR_VALUE() of 'unsigned int' is always false because the 32bit
> value is zero extended to 64 bits.
You are being far too wordy above, and definitely below.
>
> Now problem in Freescale QEGigabit Ethernet-:
> drivers/net/ethernet/freescale/ucc_geth.c
>
...
> qe_muram_addr(init_enet_pram_offset);
>
> qe_muram_alloc (a.k.a. cpm_muram_alloc) returns unsigned long.
> Return value store in a u32 (init_enet_offset, exf_glbl_param_offset,
> rx_glbl_pram_offset, tx_glbl_pram_offset, send_q_mem_reg_offset,
> thread_dat_tx_offset, thread_dat_rx_offset, scheduler_offset,
> tx_fw_statistics_pram_offset, rx_fw_statistics_pram_offset,
> rx_irq_coalescing_tbl_offset, rx_bd_qs_tbl_offset, tx_bd_ring_offset,
> init_enet_pram_offset and rx_bd_ring_offset).
Inpenetrable...
> If qe_muram_alloc will return any error, Then IS_ERR_VALUE will always
> return 0. it'll not call ucc_fast_free for any failure. Inside 'if code'
> will be a dead code on 64bit. Even qe_muram_addr will return wrong
> virtual address. Which can cause an error.
>
> kfree((void *)ugeth->tx_bd_ring_offset[i]);
Erm, kfree() isn't the right function for things allocated by qe_muram_alloc().
I still thing you need to stop this code using IS_ERR_VALUE() at all.
David
^ permalink raw reply
* Re: [5.3] ucc_geth: Fix to avoid IS_ERR_VALUE abuses and dead code on 64bit systems.
From: Arnd Bergmann @ 2016-08-08 15:13 UTC (permalink / raw)
To: linuxppc-dev
Cc: David Laight, 'Arvind Yadav', zajec5@gmail.com,
leoli@freescale.com, qiang.zhao@freescale.com,
viresh.kumar@linaro.org, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, scottwood@freescale.com,
akpm@linux-foundation.org, linux@roeck-us.net
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D5F50C493@AcuExch.aculab.com>
On Monday, August 8, 2016 2:49:11 PM CEST David Laight wrote:
>
> > If qe_muram_alloc will return any error, Then IS_ERR_VALUE will always
> > return 0. it'll not call ucc_fast_free for any failure. Inside 'if code'
> > will be a dead code on 64bit. Even qe_muram_addr will return wrong
> > virtual address. Which can cause an error.
> >
> > kfree((void *)ugeth->tx_bd_ring_offset[i]);
>
> Erm, kfree() isn't the right function for things allocated by qe_muram_alloc().
>
> I still thing you need to stop this code using IS_ERR_VALUE() at all.
Those are two separate issues:
a) The ucc_geth driver mixing kmalloc() memory with muram, and assigning
the result to "u32" and "void __iomem *" variables, both of which
are wrong at least half of the time.
b) calling conventions of qe_muram_alloc() being defined in a way that
requires the use of IS_ERR_VALUE(), because '0' is a valid address
here.
The first one can be solved by updating the network driver, ideally
by getting rid of the casts and using proper types and accessors,
while the second would require updating all users of that interface.
Arnd
^ permalink raw reply
* Re: Buggy rhashtable walking
From: Herbert Xu @ 2016-08-08 15:26 UTC (permalink / raw)
To: Ben Greear
Cc: Johannes Berg, David S. Miller, netdev, linux-wireless,
Thomas Graf, tom
In-Reply-To: <57A47CA3.4010101@candelatech.com>
On Fri, Aug 05, 2016 at 04:46:43AM -0700, Ben Greear wrote:
>
> It would not be fun to have to revert to the old way of hashing
> stations in mac80211...
>
> I'll be happy to test the patches when you have them ready.
Thanks for the offer. Unfortunately it'll be a few days before
I'm ready because I need to work through some crypto patches first.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [v5.1] ucc_fast: Fix to avoid IS_ERR_VALUE abuses and dead code on 64bit systems.
From: Arvind Yadav @ 2016-08-04 16:52 UTC (permalink / raw)
To: zajec5, leoli
Cc: qiang.zhao, scottwood, viresh.kumar, akpm, linux-wireless, netdev,
linuxppc-dev, linux, arnd, Arvind Yadav
IS_ERR_VALUE() assumes that parameter is an unsigned long.
It can not be used to check if 'unsigned int' is passed insted.
Which tends to reflect an error.
In 64bit architectures sizeof (int) == 4 && sizeof (long) == 8.
IS_ERR_VALUE(x) is ((x) >= (unsigned long)-4095).
IS_ERR_VALUE() of 'unsigned int' is always false because the 32bit
value is zero extended to 64 bits.
Now Problem In UCC fast protocols -: drivers/soc/fsl/qe/ucc_fast.c
/* Allocate memory for Tx Virtual Fifo */
uccf->ucc_fast_tx_virtual_fifo_base_offset =
qe_muram_alloc(uf_info->utfs, UCC_FAST_VIRT_FIFO_REGS_ALIGNMENT);
if (IS_ERR_VALUE(uccf->ucc_fast_tx_virtual_fifo_base_offset)) {
printk(KERN_ERR "%s: cannot allocate MURAM for TX FIFO\n",
__func__);
uccf->ucc_fast_tx_virtual_fifo_base_offset = 0;
ucc_fast_free(uccf);
return -ENOMEM;
}
/* Allocate memory for Rx Virtual Fifo */
uccf->ucc_fast_rx_virtual_fifo_base_offset =
qe_muram_alloc(uf_info->urfs +
UCC_FAST_RECEIVE_VIRTUAL_FIFO_SIZE_FUDGE_FACTOR,
UCC_FAST_VIRT_FIFO_REGS_ALIGNMENT);
if (IS_ERR_VALUE(uccf->ucc_fast_rx_virtual_fifo_base_offset)) {
printk(KERN_ERR "%s: cannot allocate MURAM for RX FIFO\n",
__func__);
uccf->ucc_fast_rx_virtual_fifo_base_offset = 0;
ucc_fast_free(uccf);
return -ENOMEM;
}
qe_muram_alloc (a.k.a. cpm_muram_alloc) returns unsigned long.
Return value store in a u32 (ucc_fast_tx_virtual_fifo_base_offset
and ucc_fast_rx_virtual_fifo_base_offset).If qe_muram_alloc will
return any error, Then IS_ERR_VALUE will always return 0. it'll not
call ucc_fast_free for any failure. Inside 'if code' will be a dead
code on 64bit.
This patch is to avoid this problem on 64bit machine.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
include/soc/fsl/qe/ucc_fast.h | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/include/soc/fsl/qe/ucc_fast.h b/include/soc/fsl/qe/ucc_fast.h
index df8ea79..ada9070 100644
--- a/include/soc/fsl/qe/ucc_fast.h
+++ b/include/soc/fsl/qe/ucc_fast.h
@@ -165,10 +165,12 @@ struct ucc_fast_private {
int stopped_tx; /* Whether channel has been stopped for Tx
(STOP_TX, etc.) */
int stopped_rx; /* Whether channel has been stopped for Rx */
- u32 ucc_fast_tx_virtual_fifo_base_offset;/* pointer to base of Tx
- virtual fifo */
- u32 ucc_fast_rx_virtual_fifo_base_offset;/* pointer to base of Rx
- virtual fifo */
+ unsigned long ucc_fast_tx_virtual_fifo_base_offset;/* pointer to base of
+ * Tx virtual fifo
+ */
+ unsigned long ucc_fast_rx_virtual_fifo_base_offset;/* pointer to base of
+ * Rx virtual fifo
+ */
#ifdef STATISTICS
u32 tx_frames; /* Transmitted frames counter. */
u32 rx_frames; /* Received frames counter (only frames
--
1.9.1
^ permalink raw reply related
* RE: [5.3] ucc_geth: Fix to avoid IS_ERR_VALUE abuses and dead code on 64bit systems.
From: David Laight @ 2016-08-08 15:49 UTC (permalink / raw)
To: 'Arnd Bergmann', linuxppc-dev@lists.ozlabs.org
Cc: 'Arvind Yadav', zajec5@gmail.com, leoli@freescale.com,
qiang.zhao@freescale.com, viresh.kumar@linaro.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
scottwood@freescale.com, akpm@linux-foundation.org,
linux@roeck-us.net
In-Reply-To: <2862487.guU7g5Qkfj@wuerfel>
From: Arnd Bergmann
> Sent: 08 August 2016 16:13
>
> On Monday, August 8, 2016 2:49:11 PM CEST David Laight wrote:
> >
> > > If qe_muram_alloc will return any error, Then IS_ERR_VALUE will always
> > > return 0. it'll not call ucc_fast_free for any failure. Inside 'if code'
> > > will be a dead code on 64bit. Even qe_muram_addr will return wrong
> > > virtual address. Which can cause an error.
> > >
> > > kfree((void *)ugeth->tx_bd_ring_offset[i]);
> >
> > Erm, kfree() isn't the right function for things allocated by qe_muram_alloc().
> >
> > I still thing you need to stop this code using IS_ERR_VALUE() at all.
>
> Those are two separate issues:
>
> a) The ucc_geth driver mixing kmalloc() memory with muram, and assigning
> the result to "u32" and "void __iomem *" variables, both of which
> are wrong at least half of the time.
>
> b) calling conventions of qe_muram_alloc() being defined in a way that
> requires the use of IS_ERR_VALUE(), because '0' is a valid address
> here.
Yep, it is all a big bag of worms...
'0' being valid is going to make tidying up after failure 'problematic'.
> The first one can be solved by updating the network driver, ideally
> by getting rid of the casts and using proper types and accessors,
> while the second would require updating all users of that interface.
It might be worth (at least as a compilation option) of embedding the
'muram offset' in a structure (passed and returned by value).
The compiler can then check that the driver code is never be looking
directly at the value.
For 'b' zero can be made invalid by changing the places where the
offset is added/subtracted.
It could even be used to offset the saved physical and virtual
addresses of the area - so not needing any extra code when the values
are converted to physical/virtual addresses.
David
^ permalink raw reply
* mac80211: AP changed bandwidth in a way we can't support - disconnect
From: Kevin O'Connor @ 2016-08-08 16:58 UTC (permalink / raw)
To: linux-wireless
Hi,
I am getting periodic wifi disconnects. The logs show the following
messages when I receive the disconnect:
Sun Aug 7 16:12:59 2016 kern.info kernel: [321982.209148] wlan0: AP ... changed bandwidth, new config is 5500 MHz, width 1 (5500/0 MHz)
Sun Aug 7 16:12:59 2016 kern.info kernel: [321982.218868] wlan0: AP ... changed bandwidth in a way we can't support - disconnect
After the above messages, the connection immediately reconnects. It
will typically stay up for a few hours and then go through the cycle
again.
The client (which I control) is a tp-link archer c7 router running
openwrt (ath10k, QCA9880-BR4A, linux v4.1.23, mac80211.ko from
compat-wireless-2016-01-10). The AP (which I do not have admin access
to) appears to be a "Ruckus Wireless ZoneFlex 802.11ac wave 2 4x4
access point"
To try and debug this, I altered the mac80211 code to display some
additional debugging data and to not force a disconnect (see debugging
patch below). With the altered code the client now stays connected.
I occasionally see periodic debugging messages like the following:
Sun Aug 7 17:52:54 2016 kern.info kernel: [327977.219622] wlan0: AP ... changed bandwidth, orig new config is 5500 MHz, width 3 (5530/0 MHz) 0
Sun Aug 7 17:53:02 2016 kern.info kernel: [327985.206823] wlan0: AP ... changed bandwidth, orig new config is 5500 MHz, width 3 (5530/0 MHz) 0
And then every few hours I'll get:
Sun Aug 7 18:13:04 2016 kern.info kernel: [329187.076091] wlan0: AP ... changed bandwidth, orig new config is 5500 MHz, width 1 (5500/0 MHz) 1024
Sun Aug 7 18:13:04 2016 kern.info kernel: [329187.086633] wlan0: AP ... changed bandwidth, new config is 5500 MHz, width 1 (5500/0 MHz)
Sun Aug 7 18:13:04 2016 kern.info kernel: [329187.096362] wlan0: AP ... changed bandwidth in a way we can't support 1024 132 1 - ignore
Sun Aug 7 18:13:04 2016 kern.info kernel: [329187.383324] wlan0: AP ... changed bandwidth, orig new config is 5500 MHz, width 3 (5530/0 MHz) 0
The above message sequence would have forced a disconnect in the past.
The "width 3" message always immediately follows the "width 1"
messages.
If I'm interpreting the sequence correctly, the AP and client
initially negotiate an 80mhz connection and then at some point the AP
requests a 20mhz connection that is immediately followed by an 80mhz
request.
What is the best way to proceed with this error? I no longer have the
disconnect issue with the debugging patch (which ignores the
unsupported request instead of disconnecting), but it would be good to
get a real fix upstream.
Thanks. I'm not subscribed to the linux-wireless mailing list, so
please CC me on replies.
-Kevin
Debugging patch:
--- mlme.c~ 2016-06-30 14:51:00.999254180 -0400
+++ mlme.c 2016-08-03 18:31:08.938869667 -0400
@@ -345,6 +345,10 @@
ht_cap, ht_oper, vht_oper,
&chandef, true);
+ sdata_info(sdata,
+ "AP %pM changed bandwidth, orig new config is %d MHz, width %d (%d/%d MHz) %d\n",
+ ifmgd->bssid, chandef.chan->center_freq, chandef.width,
+ chandef.center_freq1, chandef.center_freq2, flags);
/*
* Downgrade the new channel if we associated with restricted
* capabilities. For example, if we associated as a 20 MHz STA
@@ -377,9 +381,9 @@
IEEE80211_STA_DISABLE_160MHZ)) ||
!cfg80211_chandef_valid(&chandef)) {
sdata_info(sdata,
- "AP %pM changed bandwidth in a way we can't support - disconnect\n",
- ifmgd->bssid);
- return -EINVAL;
+ "AP %pM changed bandwidth in a way we can't support %d %d %d - ignore\n",
+ ifmgd->bssid, flags, ifmgd->flags, cfg80211_chandef_valid(&chandef));
+ return 0;
}
switch (chandef.width) {
^ permalink raw reply
* Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
From: Jason Cooper @ 2016-08-08 17:29 UTC (permalink / raw)
To: Stephan Mueller
Cc: Pan, Miaoqing, Ted Tso, Sepehrdad, Pouyan,
herbert@gondor.apana.org.au, linux-kernel@vger.kernel.org,
linux-crypto@vger.kernel.org, ath9k-devel,
linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org,
Kalle Valo
In-Reply-To: <1830987.VF9l4XmGxv@tauon.atsec.com>
Hi Stephan, Miaoqing Pan,
On Mon, Aug 08, 2016 at 08:41:36AM +0200, Stephan Mueller wrote:
> Am Montag, 8. August 2016, 02:03:36 CEST schrieb Pan, Miaoqing:
> > The entropy was evaluated by crypto expert, the analysis report show the
> > ADC with at least 10bits and up to 22 bits of min-entropy for a 32 bits
> > value, we conservatively assume the min-entropy is 10 bits out of 32 bits,
> > so that's why set entropy quality to 320/1024 = 10/32.
Ok, so the relevant commit is:
ed14dc0af7cce ath9k: feeding entropy in kernel from ADC capture
Which refers to a previous commit:
6301566e0b2d ath9k: export HW random number generator
> > Also we have explained in the commit message why can't use the HW
> > RNG framework.
>From ed14dc0af7cce:
"""
Since ADC was not designed to be a dedicated HW RNG, we do not want to
bind it to /dev/hwrng framework directly.
"""
> Where is the description of the RNG, where is the test implementation?
> >
> > Otherwise, your patch will cause high CPU load, as continuously read ADC
> > data if entropy bits under write_wakeup_threshold.
>
> The issue is that although you may have analyzed it, others are unable to
> measure the quality of the RNG and assess the design as well as the
> implementation of the RNG. This RNG is the only implementation of a hardware
> RNG that per default and without being able to change it at runtime injects
> data into the input_pool where the noise source cannot be audited. Note, even
> other respected RNG noise sources like the Intel RDRAND will not feed into /
> dev/random per default in a way that dominates all other noise sources.
>
> I would like to be able to deactivate that noise source to the extent that it
> does not cause /dev/random to unblock. The reason is that your noise source
> starts to dominate all other noise sources.
I think the short-term problem here is the config logic:
config ATH9K_HWRNG
bool "Random number generator support"
depends on ATH9K && (HW_RANDOM = y || HW_RANDOM = ATH9K)
default y
If you have *any* hwrngs you want to use and you have an ath9k card
(HW_RANDOM = y and ATH9K != n), you get the behavior Stephan is pointing
out.
Short term, we should just default no here.
> If you think that this patch is a challenge because your driver starts to
> spin, please help and offer another solution.
Well, I don't buy the reasoning listed above for not using the hwrng
framework. Interrupt timings were never designed to be a source of entropy
either. We need to grab it where ever we can find it, especially on
embedded systems. Documentation/hw_random.txt even says:
"""
This data is NOT CHECKED by any fitness tests, and could potentially be
bogus (if the hardware is faulty or has been tampered with).
"""
I really don't think there's a problem with adding these sorts of
sources under char/hw_random/. I think the only thing we would be
concerned about, other than the already addressed entropy estimation,
would be constraining the data rate.
Is ath9k the only wireless card that exposes ADC registers? What about
sound cards?
thx,
Jason.
^ permalink raw reply
* RE: [PATCH v4] cfg80211: Provision to allow the support for different beacon intervals
From: Undekari, Sunil Dutt @ 2016-08-08 17:58 UTC (permalink / raw)
To: Johannes Berg, Kushwaha, Purushottam
Cc: linux-wireless@vger.kernel.org, Malinen, Jouni,
Kondabattini, Ganesh, Kalikot Veetil, Mahesh Kumar,
Hullur Subramanyam, Amarnath, Kumar, Deepak (QCA)
In-Reply-To: <1470386912.2977.28.camel@sipsolutions.net>
PldoYXQgaWYgeW91IGhhdmUgQVAsR08sbWVzaCBpbiB0aGUgc2FtZSBpbnRlcmZhY2UgY29tYmlu
YXRpb24/IEVpdGhlciB5b3VyIGRvY3VtZW50YXRpb24gbmVlZHMgdG8gdmVyeSB2ZXJ5IGNsZWFy
bHkgc3RhdGUgdGhhdCB0aGUgbWVzaCBtdXN0IG1hdGNoIChlaXRoZXIgb25lIG9mIHRoZW0/KSBh
bmQgSSdkIGdvIGFzIGZhciBhcyA+cmVuYW1pbmcgdGhlIEFQSXMsIG9yIHlvdSBzaG91bGRuJ3Qg
cmVxdWlyZSBtdWx0aXBsZSBBUHMgYW5kIG1ha2UgdGhpcyBhcHBseSBvbiBtZXNoIGFuZCBJQlNT
IGFzIHdlbGwuDQpJIGd1ZXNzICwgd2UgY2FuIGV4dGVuZCB0aGlzIHRvIG1lc2ggYW5kIElCU1Mg
YXMgd2VsbC4gDQoNCj5JdCBzZWVtcyB0byBtZSB0aGF0IGlmIEkgd2VyZSB0byBzcGVjaWZ5IGJl
YWNvbiBpbnRlcnZhbHMgd2hpY2ggaGF2ZSBhIHZlcnkgc21hbGwgR0NELCB5b3UnbGwgcnVuIGlu
dG8gdHJvdWJsZSB3aGVuIGFjdHVhbGx5IHNlbmRpbmcgYmVhY29ucy4NCj5QZXJoYXBzIHRoZXJl
IHNob3VsZCBiZSBhIHJlcXVpcmVtZW50IG9uIHRoZSBHQ0Q/DQpDYW4gd2UgaGF2ZSB0aGlzIHB1
Ymxpc2hlZCBieSB0aGUgaG9zdCBkcml2ZXJzIHRocm91Z2ggYSBuZXcgd2lwaHkgcGFyYW1ldGVy
ICwgc2F5ICJtaW5fZGlmZl9iZWFjb25faW50ZXJ2YWxfbXVsdGlwbGllciIuIFRoaXMgc2V0J3Mg
dGhlIGV4cGVjdGF0aW9uIHRoYXQgYW55IGRpZmZlcmVudCBiZWFjb24gaW50ZXJ2YWxzIG9uIHRo
ZSB3aXBoeSAgc2hhbGwgYmUgYSBtdWx0aXBsZSBvZiB0aGlzIHBhcmFtZXRlciB3aGljaCBpcyBh
ZHZlcnRpc2VkIGJ5IHRoZSBob3N0IGRyaXZlciAsIGlzbid0ID8NCg0KUmVnYXJkcywNClN1bmls
DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEpvaGFubmVzIEJlcmcgW21h
aWx0bzpqb2hhbm5lc0BzaXBzb2x1dGlvbnMubmV0XSANClNlbnQ6IEZyaWRheSwgQXVndXN0IDUs
IDIwMTYgMjoxOSBQTQ0KVG86IEt1c2h3YWhhLCBQdXJ1c2hvdHRhbSA8cGt1c2h3YWhAcXRpLnF1
YWxjb21tLmNvbT4NCkNjOiBsaW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IE1hbGluZW4s
IEpvdW5pIDxqb3VuaUBxY2EucXVhbGNvbW0uY29tPjsgVW5kZWthcmksIFN1bmlsIER1dHQgPHVz
ZHV0dEBxdGkucXVhbGNvbW0uY29tPjsgS29uZGFiYXR0aW5pLCBHYW5lc2ggPGdhbmVzaGtAcXRp
LnF1YWxjb21tLmNvbT47IEthbGlrb3QgVmVldGlsLCBNYWhlc2ggS3VtYXIgPG1rYWxpa290QHFj
YS5xdWFsY29tbS5jb20+OyBIdWxsdXIgU3VicmFtYW55YW0sIEFtYXJuYXRoIDxhbWFybmF0aEBx
Y2EucXVhbGNvbW0uY29tPg0KU3ViamVjdDogUmU6IFtQQVRDSCB2NF0gY2ZnODAyMTE6IFByb3Zp
c2lvbiB0byBhbGxvdyB0aGUgc3VwcG9ydCBmb3IgZGlmZmVyZW50IGJlYWNvbiBpbnRlcnZhbHMN
Cg0KT24gRnJpLCAyMDE2LTA4LTA1IGF0IDEwOjU2ICswNTMwLCBQdXJ1c2hvdHRhbSBLdXNod2Fo
YSB3cm90ZToNCj4gVGhpcyBjb21taXQgcHJvdmlkZXMgdGhlIG9wdGlvbiBmb3IgdGhlIGhvc3Qg
ZHJpdmVycyB0byBhZHZlcnRpc2UgdGhlIA0KPiBzdXBwb3J0IGZvciBkaWZmZXJlbnQgYmVhY29u
IGludGVydmFscyBhbW9uZyB0aGUgcmVzcGVjdGl2ZSBpbnRlcmZhY2UgDQo+IGNvbWJpbmF0aW9u
cywgdGhyb3VnaCBzdXBwX2RpZmZfYmVhY29uX2ludCAoYm9vbCkuDQoNCk5laXRoZXIgeW91ciBj
b21taXQgbWVzc2FnZSBub3IgdGhlIGRvY3VtZW50YXRpb24gbWFrZXMgYSBkaXJlY3QgcmVmZXJl
bmNlIHRvIHRoaXMgYWZmZWN0aW5nIG9ubHkgQVAvR08gaW50ZXJmYWNlLiBIb3dldmVyLCB5b3Ug
dGhlbiBnbyBhbmQgcmVxdWlyZSB0aGF0IGF0IGxlYXN0IDIgaW50ZXJmYWNlcyB3aXRoIEFQL0dP
IGFyZSBwcmVzZW50Lg0KDQpXaGF0IGlmIHlvdSBoYXZlIEFQLEdPLG1lc2ggaW4gdGhlIHNhbWUg
aW50ZXJmYWNlIGNvbWJpbmF0aW9uPyBFaXRoZXIgeW91ciBkb2N1bWVudGF0aW9uIG5lZWRzIHRv
IHZlcnkgdmVyeSBjbGVhcmx5IHN0YXRlIHRoYXQgdGhlIG1lc2ggbXVzdCBtYXRjaCAoZWl0aGVy
IG9uZSBvZiB0aGVtPykgYW5kIEknZCBnbyBhcyBmYXIgYXMgcmVuYW1pbmcgdGhlIEFQSXMsIG9y
IHlvdSBzaG91bGRuJ3QgcmVxdWlyZSBtdWx0aXBsZSBBUHMgYW5kIG1ha2UgdGhpcyBhcHBseSBv
biBtZXNoIGFuZCBJQlNTIGFzIHdlbGwuDQoNCkFyZSB0aGVyZSByZWFsbHkgbm8gcmVzdHJpY3Rp
b25zIHdoYXRzb2V2ZXIsIGJ0dz8NCg0KSXQgc2VlbXMgdG8gbWUgdGhhdCBpZiBJIHdlcmUgdG8g
c3BlY2lmeSBiZWFjb24gaW50ZXJ2YWxzIHdoaWNoIGhhdmUgYSB2ZXJ5IHNtYWxsIEdDRCwgeW91
J2xsIHJ1biBpbnRvIHRyb3VibGUgd2hlbiBhY3R1YWxseSBzZW5kaW5nIGJlYWNvbnMuDQpQZXJo
YXBzIHRoZXJlIHNob3VsZCBiZSBhIHJlcXVpcmVtZW50IG9uIHRoZSBHQ0Q/DQoNCmpvaGFubmVz
DQo=
^ permalink raw reply
* Re: [5.3] ucc_geth: Fix to avoid IS_ERR_VALUE abuses and dead code on 64bit systems.
From: Arnd Bergmann @ 2016-08-08 20:49 UTC (permalink / raw)
To: David Laight
Cc: linuxppc-dev@lists.ozlabs.org, 'Arvind Yadav',
zajec5@gmail.com, leoli@freescale.com, qiang.zhao@freescale.com,
viresh.kumar@linaro.org, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, scottwood@freescale.com,
akpm@linux-foundation.org, linux@roeck-us.net
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D5F50C532@AcuExch.aculab.com>
On Monday, August 8, 2016 3:49:22 PM CEST David Laight wrote:
> From: Arnd Bergmann
> > Sent: 08 August 2016 16:13
> >
> > On Monday, August 8, 2016 2:49:11 PM CEST David Laight wrote:
> > >
> > > > If qe_muram_alloc will return any error, Then IS_ERR_VALUE will always
> > > > return 0. it'll not call ucc_fast_free for any failure. Inside 'if code'
> > > > will be a dead code on 64bit. Even qe_muram_addr will return wrong
> > > > virtual address. Which can cause an error.
> > > >
> > > > kfree((void *)ugeth->tx_bd_ring_offset[i]);
> > >
> > > Erm, kfree() isn't the right function for things allocated by qe_muram_alloc().
> > >
> > > I still thing you need to stop this code using IS_ERR_VALUE() at all.
> >
> > Those are two separate issues:
> >
> > a) The ucc_geth driver mixing kmalloc() memory with muram, and assigning
> > the result to "u32" and "void __iomem *" variables, both of which
> > are wrong at least half of the time.
> >
> > b) calling conventions of qe_muram_alloc() being defined in a way that
> > requires the use of IS_ERR_VALUE(), because '0' is a valid address
> > here.
>
> Yep, it is all a big bag of worms...
> '0' being valid is going to make tidying up after failure 'problematic'.
>
> > The first one can be solved by updating the network driver, ideally
> > by getting rid of the casts and using proper types and accessors,
> > while the second would require updating all users of that interface.
>
> It might be worth (at least as a compilation option) of embedding the
> 'muram offset' in a structure (passed and returned by value).
>
> The compiler can then check that the driver code is never be looking
> directly at the value.
>
> For 'b' zero can be made invalid by changing the places where the
> offset is added/subtracted.
> It could even be used to offset the saved physical and virtual
> addresses of the area - so not needing any extra code when the values
> are converted to physical/virtual addresses.
Agreed.
For this driver, we don't actually seem to use the value returned from
the allocation function, only the virtual __iomem address we get after
calling qe_muram_addr(), so it would be a big improvement to just
store the virtual address as a pointer, and wrap the calls
to qe_muram_alloc/qe_muram_addr/qe_muram_free with an appropriate
helper that doesn't even show the offset.
However, I'd also separate the normal kmalloc pointer from the
muram_alloc() pointer because only the latter is __iomem, and
we shouldn't really call MMIO accessor functions on RAM in
portable code.
Arnd
^ permalink raw reply
* [BUG] 4.8-rc1: wlcore: NULL pointer dereference in wlcore_op_get_expected_throughput
From: H. Nikolaus Schaller @ 2016-08-08 21:26 UTC (permalink / raw)
To: linux-wireless; +Cc: LKML, Discussions about the Letux Kernel
Here is what I see in 4.8-rc1 on Pyra device after typing "poweroff".
I hope someone knows what it means.
BR and thanks,
Nikolaus
root@letux:~# poweroff
Broadcast message from root@letux (pts/0) (Mon Aug 8 21:19:21 2016):
The system is going down for system halt NOW!
xinit: unexpected signal 15
[info] Using makefile-style concurrent boot in runlevel 0.
[....] Stopping ISC DHCP server: dhcpd failed!
[....] Stopping bluetooth: /usr/sbin/bluetoothd. ok
[....] Stopping automount.... ok
[....] Not running dhcpcd because /etc/network/interfaces ... failed!
[....] defines some interfaces that will use a DHCP client ... failed!
[....] Shutting down ALSA...done.
[....] Asking all remaining processes to terminate...done.
[....] All processes ended within 1 seconds...done.
[....] Stopping enhanced syslogd: rsyslogd. ok
[....] Deconfiguring network interfaces...SIOCDELRT: No such process
Device "usb0" does not exist.
Cannot find device "usb0"
done.
[info] Saving the system clock.
[info] Hardware Clock updated to Mon Aug 8 21:19:30 UTC 2016.
[....] Unmounting temporary filesystems...done.
[....] Deactivating swap...done.
[....] Unmounting local filesystems...done.
[ 613.196751] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
[info] Will now halt.
[ 615.348870] wlan0: deauthenticating from 00:12:bf:7d:ce:e6 by local choice (Reason: 3=DEAUTH_LEAVING)
[ 615.589721] Unable to handle kernel NULL pointer dereference at virtual address 00000a2a
[ 615.598249] pgd = ec3a4000
[ 615.601220] [00000a2a] *pgd=ab60f835, *pte=00000000, *ppte=00000000
[ 615.607868] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
[ 615.613551] Modules linked in: hci_uart bnep bluetooth autofs4 usb_f_ecm usb_f_rndis u_ether libcomposite configfs ipv6 cdc_ether usbnet cdc_acm arc4 wl18xx wlcore mac80211 omapdrm cfg80211 drm_kms_helper cfbfillrect syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea snd_soc_omap_hdmi_audio panel_mipi_debug drm dwc3 connector_hdmi encoder_tpd12s015 w2cbw003_bluetooth snd_soc_omap_abe_twl6040 snd_soc_twl6040 wwan_on_off leds_gpio omapdss pwm_omap_dmtimer pwm_bl ehci_omap wlcore_sdio dwc3_omap leds_is31fl319x snd_soc_ts3a225e gpio_twl6040 bq27xxx_battery_i2c tsc2007 bq27xxx_battery leds_tca6507 crtouch_mt bq2429x_charger twl6040_vibra ina2xx palmas_pwrbutton palmas_gpadc as5013 tca8418_keypad usb3503 bma150 bmg160_i2c bno055 bmg160_core input_polldev snd_soc_omap_mcpdm snd_soc_omap_mcbsp snd_soc_omap snd_pcm_dmaengine [last unloaded: g_ether]
[ 615.694303] CPU: 0 PID: 3788 Comm: halt Tainted: G B W 4.8.0-rc1-letux+ #655
[ 615.702727] Hardware name: Generic OMAP5 (Flattened Device Tree)
[ 615.709052] task: eb2564c0 task.stack: ec456000
[ 615.713913] PC is at wlcore_op_get_expected_throughput+0x14/0x20 [wlcore]
[ 615.721357] LR is at sta_set_sinfo+0xc18/0x1110 [mac80211]
[ 615.727145] pc : [<bf4de050>] lr : [<bf40cf20>] psr: a00f0013
[ 615.727145] sp : ec457c48 ip : 00000000 fp : 400f0013
[ 615.739237] r10: ec414620 r9 : eb604b30 r8 : eb604c90
[ 615.744735] r7 : c0b02554 r6 : bf4815c4 r5 : bf4de03c r4 : ec823400
[ 615.751613] r3 : 00000000 r2 : 00000000 r1 : 000000c8 r0 : 000003e8
[ 615.758492] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 615.766008] Control: 10c5387d Table: ac3a406a DAC: 00000051
[ 615.772062] Process halt (pid: 3788, stack limit = 0xec456218)
[ 615.778208] Stack: (0xec457c48 to 0xec458000)
[ 615.782806] 7c40: 00000001 00000000 bf40d540 c0a76630 eb604f3c bf40d540
[ 615.791434] 7c60: ec414620 00000000 00000000 eb604a8c eb604c90 00000000 00000001 eb604800
[ 615.800049] 7c80: ec823400 ec45a600 ec45a600 ec414b2c 00000001 ec414b94 00000000 bf40d540
[ 615.808682] 7ca0: 00000000 00000003 ec457cb0 ec414b94 ec457cb8 bf40d75c eb604808 eb604808
[ 615.817308] 7cc0: 00000000 ec45a600 00000000 ec414620 ec45ac50 ec457d1e 000000c0 00000003
[ 615.825940] 7ce0: ffffffff bf4629e8 00000001 ec457d1e ec45a600 ec457d60 ec457d1e 00000001
[ 615.834563] 7d00: bf38707c bf386c94 00000003 bf4680cc ec457d1e 00000000 ec45a67c 00c00000
[ 615.843178] 7d20: 12000000 e6ce7dbf efbeadde 12000000 e6ce7dbf 00030000 00000001 ec892bd4
[ 615.851801] 7d40: ec45a000 c0b02554 ec4142a0 bf38707c bf386c94 00000003 ffffffff bf352b58
[ 615.860428] 7d60: ec892bd4 00000000 00000000 00000003 ec45a648 ec45a608 ec414000 ec414000
[ 615.869051] 7d80: ec414000 ec45a000 00000003 bf3590c0 00000000 00000003 00000000 ec45a000
[ 615.877674] 7da0: ec414000 ec45a648 ec45a608 ec414000 ec414000 00000009 ec96cc0c 00000000
[ 615.886300] 7dc0: ffffffff bf31cba8 ec45a608 ec4142a0 ec45a000 bf31cd70 00000000 00000000
[ 615.894918] 7de0: c06d0594 c06da874 c0b98444 fffffff7 00000000 00000009 ec457e3c bf47bb38
[ 615.903540] 7e00: ec96cc0c 00000000 ffffffff c0152df8 ec45a000 ec457e58 00001042 00001003
[ 615.912162] 7e20: 00000000 c0152e40 00000000 00000009 ec457e3c c0620eb4 00000009 ec45a000
[ 615.920786] 7e40: c062b690 c0620fd0 ec45a04c ec45a000 00000001 c0621134 ec45a04c ec45a04c
[ 615.929410] 7e60: c062b690 c062b97c ec45a000 00001003 ec45a150 ec45a000 00000000 c062ba38
[ 615.938027] 7e80: ec8f7600 00000000 ec96cc00 ec45a000 00000000 c0697f8c 00000000 beabc47c
[ 615.946652] 7ea0: 00000020 00000000 6e616c77 00000030 00000000 00000000 00001042 8202a8c0
[ 615.955275] 7ec0: 00000000 00000000 00000000 00008914 ed5014a0 beabc47c c0b90c80 ed501480
[ 615.963900] 7ee0: 00000003 00000000 00000001 c0609a30 beabc47c ed5014a0 eb34b140 c026560c
[ 615.972524] 7f00: 00000003 c0264ac4 0000c000 c02654a4 600f0013 c135c654 c08a43f4 eb2dccb4
[ 615.981145] 7f20: ec456000 00000000 00000003 eb34b140 ec456000 00000000 00000001 c0271cd8
[ 615.989769] 7f40: 00000000 00000000 c0271a44 c0255308 c0b03bc0 00000000 ed501480 c0609684
[ 615.998389] 7f60: ed813710 00000000 eb34b140 eb34b140 beabc47c 00008914 00000003 00000000
[ 616.007012] 7f80: 00000001 c026560c 00001042 beabc47c 00000000 beabc49c 00000036 c0107204
[ 616.015636] 7fa0: ec456000 c0107060 beabc47c 00000000 00000003 00008914 beabc47c 00001042
[ 616.024253] 7fc0: beabc47c 00000000 beabc49c 00000036 000230f0 00023100 00000003 00000001
[ 616.032875] 7fe0: 00023054 beabc44c 0001135b b6e83206 a00f0030 00000003 00000000 00000000
[ 616.041894] [<bf4de050>] (wlcore_op_get_expected_throughput [wlcore]) from [<bf40cf20>] (sta_set_sinfo+0xc18/0x1110 [mac80211])
[ 616.054542] [<bf40cf20>] (sta_set_sinfo [mac80211]) from [<bf40d540>] (__sta_info_destroy_part2+0x128/0x194 [mac80211])
[ 616.066426] [<bf40d540>] (__sta_info_destroy_part2 [mac80211]) from [<bf40d75c>] (__sta_info_flush+0xf8/0x13c [mac80211])
[ 616.078513] [<bf40d75c>] (__sta_info_flush [mac80211]) from [<bf4629e8>] (ieee80211_set_disassoc+0x168/0x2f8 [mac80211])
[ 616.090512] [<bf4629e8>] (ieee80211_set_disassoc [mac80211]) from [<bf4680cc>] (ieee80211_mgd_deauth+0x3dc/0x9fc [mac80211])
[ 616.102861] [<bf4680cc>] (ieee80211_mgd_deauth [mac80211]) from [<bf352b58>] (cfg80211_mlme_deauth+0x1f4/0x458 [cfg80211])
[ 616.114978] [<bf352b58>] (cfg80211_mlme_deauth [cfg80211]) from [<bf3590c0>] (cfg80211_disconnect+0xa0/0x4a4 [cfg80211])
[ 616.126880] [<bf3590c0>] (cfg80211_disconnect [cfg80211]) from [<bf31cba8>] (cfg80211_leave+0x28/0x34 [cfg80211])
[ 616.138137] [<bf31cba8>] (cfg80211_leave [cfg80211]) from [<bf31cd70>] (cfg80211_netdev_notifier_call+0x1bc/0x84c [cfg80211])
[ 616.150287] [<bf31cd70>] (cfg80211_netdev_notifier_call [cfg80211]) from [<c0152df8>] (notifier_call_chain+0x40/0x68)
[ 616.161479] [<c0152df8>] (notifier_call_chain) from [<c0152e40>] (raw_notifier_call_chain+0x14/0x1c)
[ 616.171111] [<c0152e40>] (raw_notifier_call_chain) from [<c0620eb4>] (call_netdevice_notifiers+0xc/0x14)
[ 616.181108] [<c0620eb4>] (call_netdevice_notifiers) from [<c0620fd0>] (__dev_close_many+0x48/0xb8)
[ 616.190551] [<c0620fd0>] (__dev_close_many) from [<c0621134>] (__dev_close+0x20/0x34)
[ 616.198806] [<c0621134>] (__dev_close) from [<c062b97c>] (__dev_change_flags+0x8c/0x130)
[ 616.207347] [<c062b97c>] (__dev_change_flags) from [<c062ba38>] (dev_change_flags+0x18/0x48)
[ 616.216255] [<c062ba38>] (dev_change_flags) from [<c0697f8c>] (devinet_ioctl+0x338/0x704)
[ 616.224883] [<c0697f8c>] (devinet_ioctl) from [<c0609a30>] (sock_ioctl+0x288/0x2d8)
[ 616.232959] [<c0609a30>] (sock_ioctl) from [<c0264ac4>] (vfs_ioctl+0x20/0x34)
[ 616.240482] [<c0264ac4>] (vfs_ioctl) from [<c02654a4>] (do_vfs_ioctl+0x854/0x970)
[ 616.248369] [<c02654a4>] (do_vfs_ioctl) from [<c026560c>] (SyS_ioctl+0x4c/0x74)
[ 616.256078] [<c026560c>] (SyS_ioctl) from [<c0107060>] (ret_fast_syscall+0x0/0x1c)
[ 616.264075] Code: e3a010c8 e5d02098 e3a00ffa e0233291 (e5d33a2a)
[ 616.272268] ---[ end trace 00ab29170ed628ed ]---
Segmentation fault
[....] startpar: service(s) skipped, program is not configured: dhcpcd ... (warning).
INIT: no more processes left in this runlevel
^ 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