[PATCH] cfg80211: fix missing break in NL8211_CHAN_WIDTH_80P80 case
From: Colin Ian King The switch on chandef->width is missing a break on the NL8211_CHAN_WIDTH_80P80 case; currently we get a WARN_ON when center_freq2 is non-zero because of the missing break. Signed-off-by: Colin Ian King --- net/wireless/chan.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/wireless/chan.c b/net/wireless/chan.c index b0e11b6..0f50622 100644 --- a/net/wireless/chan.c +++ b/net/wireless/chan.c @@ -513,6 +513,7 @@ static bool cfg80211_chandef_dfs_available(struct wiphy *wiphy, r = cfg80211_get_chans_dfs_available(wiphy, chandef->center_freq2, width); + break; default: WARN_ON(chandef->center_freq2); break; -- 2.8.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: [PATCH] ath9k: fix GPIO mask for AR9462 and AR9565
Hi On 2016-06-03, miaoq...@codeaurora.org wrote: > From: Miaoqing Pan > > The incorrect GPIO mask cause kernel warning, when AR9462 access GPIO11. > Also fix the mask for AR9565. [...] I think I'm seeing a very similar issue on AR5008/ AR5416+AR2133 and 4.7-rc7 (mainline v4.7-rc7-92-g47ef4ad, to be exact). [4.958874] ath9k :02:02.0: enabling device ( -> 0002) [...] [5.401086] [ cut here ] [5.401093] WARNING: CPU: 1 PID: 1159 at /build/linux-aptosid-4.7~rc7/drivers/net/wireless/ath/ath9k/hw.c:2776 ath9k_hw_gpio_get+0x148/0x1a0 [ath9k_hw] [5.401116] Modules linked in: iTCO_wdt gpio_ich iTCO_vendor_support evdev intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp ir_lirc_codec lirc_dev kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul rtl2832_sdr videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core videodev ghash_clmulni_intel fc0013 rtl2832 i2c_mux regmap_i2c sha256_ssse3 sha256_generic drbg ansi_cprng rc_medion_x10_digitainer dvb_usb_rtl28xxu dvb_usb_v2 dvb_usb_dw2102(+) dvb_usb aesni_intel dvb_core aes_x86_64 lrw ati_remote media gf128mul glue_helper ablk_helper cryptd intel_cstate intel_rapl_perf snd_hda_codec_hdmi(+) i915 snd_hda_codec_realtek snd_hda_codec_generic pcspkr serio_raw i2c_i801 ath9k(+) ath9k_common video ath9k_hw i2c_algo_bit drm_kms_helper ath snd_hda_intel drm snd_hda_codec mac80211 snd_hda_core [5.401135] snd_hwdep snd_pcm cfg80211 i2c_core intel_gtt rfkill snd_timer syscopyarea lpc_ich sysfillrect snd sg sysimgblt mfd_core mei_me soundcore fb_sys_fops mei nuvoton_cir floppy(+) rc_core button w83627ehf hwmon_vid parport_pc ppdev lp parport autofs4 ext4 crc16 jbd2 mbcache hid_generic usbhid hid dm_mod sd_mod sr_mod cdrom ohci_pci crc32c_intel psmouse r8169 ahci libahci libata scsi_mod xhci_pci xhci_hcd ohci_hcd e100 mii ehci_pci ehci_hcd usbcore usb_common e1000e ptp pps_core fjes [5.401137] CPU: 1 PID: 1159 Comm: systemd-udevd Not tainted 4.7.0-rc7-aptosid-amd64 #1 aptosid 4.7~rc7-1~git92.slh.3 [5.401138] Hardware name: /DH67CL, BIOS BLH6710H.86A.0160.2012.1204.1156 12/04/2012 [5.401140] 0286 f912d633 81290fd3 [5.401141] 81063fd4 88040c6dc018 [5.401143] 0002 0100 88040c6dc018 [5.401143] Call Trace: [5.401148] [] ? dump_stack+0x5c/0x79 [5.401150] [] ? __warn+0xb4/0xd0 [5.401153] [] ? ath9k_hw_gpio_get+0x148/0x1a0 [ath9k_hw] [5.401156] [] ? ath9k_hw_fill_cap_info+0x163/0x830 [ath9k_hw] [5.401159] [] ? ath9k_hw_init+0x664/0xb10 [ath9k_hw] [5.401167] [] ? ath9k_init_device+0x4df/0xe00 [ath9k] [5.401170] [] ? request_threaded_irq+0xf1/0x1a0 [5.401176] [] ? ath_pci_probe+0x1c9/0x370 [ath9k] [5.401178] [] ? local_pci_probe+0x3a/0x90 [5.401179] [] ? pci_match_device+0xcf/0xf0 [5.401180] [] ? pci_device_probe+0xfb/0x140 [5.401183] [] ? driver_probe_device+0x1ed/0x2b0 [5.401184] [] ? __driver_attach+0x8f/0xa0 [5.401185] [] ? driver_probe_device+0x2b0/0x2b0 [5.401186] [] ? bus_for_each_dev+0x62/0xb0 [5.401188] [] ? bus_add_driver+0x19a/0x210 [5.401189] [] ? 0xa0718000 [5.401190] [] ? driver_register+0x52/0xc0 [5.401195] [] ? ath9k_init+0x5/0x34 [ath9k] [5.401197] [] ? do_one_initcall+0x47/0x180 [5.401199] [] ? do_init_module+0x51/0x1b9 [5.401201] [] ? load_module+0x1f77/0x23a0 [5.401202] [] ? __symbol_put+0x80/0x80 [5.401205] [] ? security_capable+0x3c/0x50 [5.401207] [] ? SYSC_finit_module+0xc2/0xd0 [5.401210] [] ? entry_SYSCALL_64_fastpath+0x1a/0xa4 [5.401211] ---[ end trace ac762697fb0d9f1d ]--- [5.401211] [ cut here ] [5.401214] WARNING: CPU: 1 PID: 1159 at /build/linux-aptosid-4.7~rc7/drivers/net/wireless/ath/ath9k/hw.c:2796 ath9k_hw_gpio_get+0xb4/0x1a0 [ath9k_hw] [5.401234] Modules linked in: iTCO_wdt gpio_ich iTCO_vendor_support evdev intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp ir_lirc_codec lirc_dev kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul rtl2832_sdr videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core videodev ghash_clmulni_intel fc0013 rtl2832 i2c_mux regmap_i2c sha256_ssse3 sha256_generic drbg ansi_cprng rc_medion_x10_digitainer dvb_usb_rtl28xxu dvb_usb_v2 dvb_usb_dw2102(+) dvb_usb aesni_intel dvb_core aes_x86_64 lrw ati_remote media gf128mul glue_helper ablk_helper cryptd intel_cstate intel_rapl_perf snd_hda_codec_hdmi(+) i915 snd_hda_codec_realtek snd_hda_codec_generic pcspkr serio_raw i2c_i801 ath9k(+) ath9k_common video ath9k_hw i2c_algo_bit drm_kms_helper ath snd_hda_intel drm snd_hda_codec mac80211 snd_hda_core [5.401254] snd_hwdep snd_pcm cfg80211 i2c_core intel_gtt rfkill snd_timer syscopyarea lpc_ich sysfillrect snd sg sysimgblt mfd_core mei_me soundcore fb_sys_fop
Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property
On Thu, Jul 07, 2016 at 10:46:28AM +0200, Arnd Bergmann wrote: > On Wednesday, July 6, 2016 9:19:41 PM CEST Arend Van Spriel wrote: > > On 6-7-2016 15:42, Arnd Bergmann wrote: > > > On Wednesday, July 6, 2016 10:08:55 AM CEST Arend Van Spriel wrote: > > >> On Tue, Jul 5, 2016 at 3:43 PM, Arnd Bergmann wrote: > > > All existing uses of the model property in arch/arm/boot/dts and most of > > > the ones in arch/powerpc/boot/dts are against the intended usage in > > > one way or another, but adding different kind of incorrect usage won't > > > improve that. > > > > > > The only way I can see the model property being used correctly would > > > be to have it match the first entry in the compatible property, but > > > that is completely redundant, so we tend to omit it, except for the > > > root node in which it is required. For the root node however, the > > > historic practice that has crept in on ARM is to put something completely > > > different in there, which is a human-readable description of the > > > machine rather than something we can use as a unique indentifier. > > > > > > I'd just consider the "model" property burned, and not use it for anything > > > that doesn't already use it, just like we handle "device_type": a few > > > things require it, nothing else should use it. > > > > If that is the agreed approach in devicetree arena I am fine with it. I > > have been unaware of this and just looked at the suggestion from Jonas > > seeing a solution to the problem at hand. > > I don't think it has been discussed or decided before as the question > has not come up, so for now this is my personal view. Maybe one of > the devicetree maintainers can comment on this. Back from vacation and getting caught up. I agree with Arnd here. In my view model is the OEM branding on the device, compatible is the h/w. If you have different firmware related files, that goes beyond OEM branding. Rob -- 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
Further question about MAC80211
Hello there! I'd like to thank you for your time and all the information you gave me last monday; I'm still reading and studying it! The main goal of our project is to dinamically control the troughtput of each virtual interface (ViF) depending on how good the connection is between 2 stations and depending on the others ViF throughtputs our station (STA structure or local) may have instantiated. To do that we estimate the airtime of the packet that's about to be send and depending on the channel usage we decide if we let the packet flow or if we should enqueue or even drop it! The problems begin when we enqueue a packet that has the txpending flag set (it's been in the AC queue once) and our algorithm decides to enqueue it again or drop the packet. The tx_pending tasklet begins to loop the same packet on tx_frags (stopping the tasklet for some time is not a slution either...). The results of enqueueing is connection lost or a huge delay on some packets. If we drop any packet in tx_frags() mac80211 goes crazy and may instantly drop connection and destroy the vif. Is there any more projects I should check out that drops or enqueue packets on mac80211 when it's not supposed to be enqueuing? Thanks again for your precious time! Joan Josep Aleixendri -- 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
