Re: [PATCH 1/2] ath10k: Define an enum to enable cycle counter wraparound logic
>> --- a/drivers/net/wireless/ath/ath10k/core.c >> +++ b/drivers/net/wireless/ath/ath10k/core.c >> @@ -55,7 +55,7 @@ static const struct ath10k_hw_params >> ath10k_hw_params_list[] = { >> .name = "qca988x hw2.0", >> .patch_load_addr = QCA988X_HW_2_0_PATCH_LOAD_ADDR, >> .uart_pin = 7, >> -.has_shifted_cc_wraparound = true, >> +.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL, >> .otp_exe_param = 0, >> .channel_counters_freq_hz = 88000, >> .max_probe_resp_desc_thres = 0, >> @@ -224,7 +224,7 @@ static const struct ath10k_hw_params >> ath10k_hw_params_list[] = { >> .name = "qca4019 hw1.0", >> .patch_load_addr = QCA4019_HW_1_0_PATCH_LOAD_ADDR, >> .uart_pin = 7, >> -.has_shifted_cc_wraparound = true, >> +.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL, >> .otp_exe_param = 0x001, >> .continuous_frag_desc = true, >> .channel_counters_freq_hz = 125000, > > As the pending branch has the QCA9887 patch I added > ATH10K_HW_CC_WRAP_SHIFTED_ALL also for QCA9887. Please review my changes > in the pending branch: > > https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending=2fa32dbd9f26e8b2f323ca30ad116ea486840aba > Looks good, thanks. Vasanth -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pull-request: wireless-drivers 2016-06-04
From: Kalle ValoDate: Sat, 04 Jun 2016 18:45:21 +0300 > few fixes for 4.7. Please let me know if you have any issues. Pulled, thanks kalle. -- 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 v3 1/2] b43: Remove unused phy_a code
On 06/04/2016 09:54 AM, Guenter Roeck wrote: gcc-6 reports the following error with -Werror=unused-const-variable. drivers/net/wireless/broadcom/b43/phy_a.c:576:40: error: 'b43_phyops_a' defined but not used Per Michael Büsch: "All a-phy code is usused", so remove it all, and move the remaining Type-G initialization code into phy_g.c. Reported-by: Fengguang Wu[0-day test robot] Cc: Michael Büsch Signed-off-by: Guenter Roeck --- v3: Do not rename b43_phy_inita() v2: Remove phy_a.c; move left-over code into phy_g.c Remove now unused data structure These two patches have been tested on a BCM4318. Larry -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ath9k_htc firmware
Am 04.06.2016 um 21:44 schrieb bruce m beach: >>> I'm looking for some kind of simple request in the ath9k_htc driver, through >>> the usb ep0, like a memory read on the card, where a urb is sent with >>> the resulting chain of events. The simpler the better. The simplest. > >> For EP0 on drivers site: >> static int ath9k_hif_usb_download_fw(struct hif_device_usb *hif_dev) >> { >> int transfer, err; >> const void *data = hif_dev->fw_data; >> size_t len = hif_dev->fw_size; >> u32 addr = AR9271_FIRMWARE; >> u8 *buf = kzalloc(4096, GFP_KERNEL); >> u32 firm_offset; >> ... > > What about the code for setting and resetting leds ??? > > Bruce It is EP3/EP4 and it is not working without firmware. Here is one example how you can add new command to firmware: https://github.com/olerem/open-ath9k-htc-firmware/commit/c73c159303e30a28e2d3dc05ba0d2d15504e5fad And for kernel driver: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8badb50cfab6d433622dbfd5a90b6adf27333107 PS: Grr... today i send message from wrong email. Sorry for the spam -- Regards, Oleksij signature.asc Description: OpenPGP digital signature
ath9k_htc firmware
>> I'm looking for some kind of simple request in the ath9k_htc driver, through >> the usb ep0, like a memory read on the card, where a urb is sent with >> the resulting chain of events. The simpler the better. The simplest. > For EP0 on drivers site: > static int ath9k_hif_usb_download_fw(struct hif_device_usb *hif_dev) > { > int transfer, err; > const void *data = hif_dev->fw_data; > size_t len = hif_dev->fw_size; > u32 addr = AR9271_FIRMWARE; > u8 *buf = kzalloc(4096, GFP_KERNEL); > u32 firm_offset; > ... What about the code for setting and resetting leds ??? Bruce -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch "ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards." has been added to the 4.6-stable tree
This is a note to let you know that I've just added the patch titled ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards. to the 4.6-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: ath9k-fix-led-polarity-for-some-mini-pci-ar9220-mb92-cards.patch and it can be found in the queue-4.6 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please letknow about it. >From 0f9edcdd88a993914fa1d1dc369b35dc503979db Mon Sep 17 00:00:00 2001 From: "Vittorio Gambaletta (VittGam)" Date: Mon, 11 Apr 2016 04:48:55 +0200 Subject: ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards. From: Vittorio Gambaletta (VittGam) commit 0f9edcdd88a993914fa1d1dc369b35dc503979db upstream. The Wistron DNMA-92 and Compex WLM200NX have inverted LED polarity (active high instead of active low). The same PCI Subsystem ID is used by both cards, which are based on the same Atheros MB92 design. Cc: Cc: Cc: Signed-off-by: Vittorio Gambaletta Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman --- drivers/net/wireless/ath/ath9k/pci.c | 10 ++ 1 file changed, 10 insertions(+) --- a/drivers/net/wireless/ath/ath9k/pci.c +++ b/drivers/net/wireless/ath/ath9k/pci.c @@ -28,6 +28,16 @@ static const struct pci_device_id ath_pc { PCI_VDEVICE(ATHEROS, 0x0024) }, /* PCI-E */ { PCI_VDEVICE(ATHEROS, 0x0027) }, /* PCI */ { PCI_VDEVICE(ATHEROS, 0x0029) }, /* PCI */ + +#ifdef CONFIG_ATH9K_PCOEM + /* Mini PCI AR9220 MB92 cards: Compex WLM200NX, Wistron DNMA-92 */ + { PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS, +0x0029, +PCI_VENDOR_ID_ATHEROS, +0x2096), + .driver_data = ATH9K_PCI_LED_ACT_HI }, +#endif + { PCI_VDEVICE(ATHEROS, 0x002A) }, /* PCI-E */ #ifdef CONFIG_ATH9K_PCOEM Patches currently in stable-queue which might be from linux-wirel...@vittgam.net are queue-4.6/ath9k-add-a-module-parameter-to-invert-led-polarity.patch queue-4.6/ath9k-fix-led-polarity-for-some-mini-pci-ar9220-mb92-cards.patch -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch "ath9k: Add a module parameter to invert LED polarity." has been added to the 4.6-stable tree
This is a note to let you know that I've just added the patch titled ath9k: Add a module parameter to invert LED polarity. to the 4.6-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: ath9k-add-a-module-parameter-to-invert-led-polarity.patch and it can be found in the queue-4.6 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please letknow about it. >From cd84042ce9040ad038e958bc67a46fcfc015c736 Mon Sep 17 00:00:00 2001 From: "Vittorio Gambaletta (VittGam)" Date: Mon, 11 Apr 2016 04:48:54 +0200 Subject: ath9k: Add a module parameter to invert LED polarity. From: Vittorio Gambaletta (VittGam) commit cd84042ce9040ad038e958bc67a46fcfc015c736 upstream. The LED can be active high instead of active low on some hardware. Add the led_active_high module parameter. It defaults to -1 to obey platform data as before. Setting the parameter to 1 or 0 will force the LED respectively active high or active low. Cc: Cc: Cc: Signed-off-by: Vittorio Gambaletta Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman --- drivers/net/wireless/ath/ath9k/init.c |7 +++ 1 file changed, 7 insertions(+) --- a/drivers/net/wireless/ath/ath9k/init.c +++ b/drivers/net/wireless/ath/ath9k/init.c @@ -49,6 +49,10 @@ int ath9k_led_blink; module_param_named(blink, ath9k_led_blink, int, 0444); MODULE_PARM_DESC(blink, "Enable LED blink on activity"); +static int ath9k_led_active_high = -1; +module_param_named(led_active_high, ath9k_led_active_high, int, 0444); +MODULE_PARM_DESC(led_active_high, "Invert LED polarity"); + static int ath9k_btcoex_enable; module_param_named(btcoex_enable, ath9k_btcoex_enable, int, 0444); MODULE_PARM_DESC(btcoex_enable, "Enable wifi-BT coexistence"); @@ -600,6 +604,9 @@ static int ath9k_init_softc(u16 devid, s if (ret) return ret; + if (ath9k_led_active_high != -1) + ah->config.led_active_high = ath9k_led_active_high == 1; + /* * Enable WLAN/BT RX Antenna diversity only when: * Patches currently in stable-queue which might be from linux-wirel...@vittgam.net are queue-4.6/ath9k-add-a-module-parameter-to-invert-led-polarity.patch queue-4.6/ath9k-fix-led-polarity-for-some-mini-pci-ar9220-mb92-cards.patch -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch "ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards." has been added to the 4.4-stable tree
This is a note to let you know that I've just added the patch titled ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards. to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: ath9k-fix-led-polarity-for-some-mini-pci-ar9220-mb92-cards.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please letknow about it. >From 0f9edcdd88a993914fa1d1dc369b35dc503979db Mon Sep 17 00:00:00 2001 From: "Vittorio Gambaletta (VittGam)" Date: Mon, 11 Apr 2016 04:48:55 +0200 Subject: ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards. From: Vittorio Gambaletta (VittGam) commit 0f9edcdd88a993914fa1d1dc369b35dc503979db upstream. The Wistron DNMA-92 and Compex WLM200NX have inverted LED polarity (active high instead of active low). The same PCI Subsystem ID is used by both cards, which are based on the same Atheros MB92 design. Cc: Cc: Cc: Signed-off-by: Vittorio Gambaletta Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman --- drivers/net/wireless/ath/ath9k/pci.c | 10 ++ 1 file changed, 10 insertions(+) --- a/drivers/net/wireless/ath/ath9k/pci.c +++ b/drivers/net/wireless/ath/ath9k/pci.c @@ -28,6 +28,16 @@ static const struct pci_device_id ath_pc { PCI_VDEVICE(ATHEROS, 0x0024) }, /* PCI-E */ { PCI_VDEVICE(ATHEROS, 0x0027) }, /* PCI */ { PCI_VDEVICE(ATHEROS, 0x0029) }, /* PCI */ + +#ifdef CONFIG_ATH9K_PCOEM + /* Mini PCI AR9220 MB92 cards: Compex WLM200NX, Wistron DNMA-92 */ + { PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS, +0x0029, +PCI_VENDOR_ID_ATHEROS, +0x2096), + .driver_data = ATH9K_PCI_LED_ACT_HI }, +#endif + { PCI_VDEVICE(ATHEROS, 0x002A) }, /* PCI-E */ #ifdef CONFIG_ATH9K_PCOEM Patches currently in stable-queue which might be from linux-wirel...@vittgam.net are queue-4.4/ath9k-add-a-module-parameter-to-invert-led-polarity.patch queue-4.4/ath9k-fix-led-polarity-for-some-mini-pci-ar9220-mb92-cards.patch -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch "ath9k: Add a module parameter to invert LED polarity." has been added to the 4.4-stable tree
This is a note to let you know that I've just added the patch titled ath9k: Add a module parameter to invert LED polarity. to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: ath9k-add-a-module-parameter-to-invert-led-polarity.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please letknow about it. >From cd84042ce9040ad038e958bc67a46fcfc015c736 Mon Sep 17 00:00:00 2001 From: "Vittorio Gambaletta (VittGam)" Date: Mon, 11 Apr 2016 04:48:54 +0200 Subject: ath9k: Add a module parameter to invert LED polarity. From: Vittorio Gambaletta (VittGam) commit cd84042ce9040ad038e958bc67a46fcfc015c736 upstream. The LED can be active high instead of active low on some hardware. Add the led_active_high module parameter. It defaults to -1 to obey platform data as before. Setting the parameter to 1 or 0 will force the LED respectively active high or active low. Cc: Cc: Cc: Signed-off-by: Vittorio Gambaletta Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman --- drivers/net/wireless/ath/ath9k/init.c |7 +++ 1 file changed, 7 insertions(+) --- a/drivers/net/wireless/ath/ath9k/init.c +++ b/drivers/net/wireless/ath/ath9k/init.c @@ -49,6 +49,10 @@ int ath9k_led_blink; module_param_named(blink, ath9k_led_blink, int, 0444); MODULE_PARM_DESC(blink, "Enable LED blink on activity"); +static int ath9k_led_active_high = -1; +module_param_named(led_active_high, ath9k_led_active_high, int, 0444); +MODULE_PARM_DESC(led_active_high, "Invert LED polarity"); + static int ath9k_btcoex_enable; module_param_named(btcoex_enable, ath9k_btcoex_enable, int, 0444); MODULE_PARM_DESC(btcoex_enable, "Enable wifi-BT coexistence"); @@ -600,6 +604,9 @@ static int ath9k_init_softc(u16 devid, s if (ret) return ret; + if (ath9k_led_active_high != -1) + ah->config.led_active_high = ath9k_led_active_high == 1; + /* * Enable WLAN/BT RX Antenna diversity only when: * Patches currently in stable-queue which might be from linux-wirel...@vittgam.net are queue-4.4/ath9k-add-a-module-parameter-to-invert-led-polarity.patch queue-4.4/ath9k-fix-led-polarity-for-some-mini-pci-ar9220-mb92-cards.patch -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch "ath9k: Add a module parameter to invert LED polarity." has been added to the 4.5-stable tree
This is a note to let you know that I've just added the patch titled ath9k: Add a module parameter to invert LED polarity. to the 4.5-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: ath9k-add-a-module-parameter-to-invert-led-polarity.patch and it can be found in the queue-4.5 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please letknow about it. >From cd84042ce9040ad038e958bc67a46fcfc015c736 Mon Sep 17 00:00:00 2001 From: "Vittorio Gambaletta (VittGam)" Date: Mon, 11 Apr 2016 04:48:54 +0200 Subject: ath9k: Add a module parameter to invert LED polarity. From: Vittorio Gambaletta (VittGam) commit cd84042ce9040ad038e958bc67a46fcfc015c736 upstream. The LED can be active high instead of active low on some hardware. Add the led_active_high module parameter. It defaults to -1 to obey platform data as before. Setting the parameter to 1 or 0 will force the LED respectively active high or active low. Cc: Cc: Cc: Signed-off-by: Vittorio Gambaletta Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman --- drivers/net/wireless/ath/ath9k/init.c |7 +++ 1 file changed, 7 insertions(+) --- a/drivers/net/wireless/ath/ath9k/init.c +++ b/drivers/net/wireless/ath/ath9k/init.c @@ -49,6 +49,10 @@ int ath9k_led_blink; module_param_named(blink, ath9k_led_blink, int, 0444); MODULE_PARM_DESC(blink, "Enable LED blink on activity"); +static int ath9k_led_active_high = -1; +module_param_named(led_active_high, ath9k_led_active_high, int, 0444); +MODULE_PARM_DESC(led_active_high, "Invert LED polarity"); + static int ath9k_btcoex_enable; module_param_named(btcoex_enable, ath9k_btcoex_enable, int, 0444); MODULE_PARM_DESC(btcoex_enable, "Enable wifi-BT coexistence"); @@ -600,6 +604,9 @@ static int ath9k_init_softc(u16 devid, s if (ret) return ret; + if (ath9k_led_active_high != -1) + ah->config.led_active_high = ath9k_led_active_high == 1; + /* * Enable WLAN/BT RX Antenna diversity only when: * Patches currently in stable-queue which might be from linux-wirel...@vittgam.net are queue-4.5/ath9k-add-a-module-parameter-to-invert-led-polarity.patch queue-4.5/ath9k-fix-led-polarity-for-some-mini-pci-ar9220-mb92-cards.patch -- 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: rt2800usb firmware rt2870.bin 0.36 not scanning
Craig McQueen wrote: > I have a D-Link DWA-140 USB Wi-Fi device which is rt2800 based (5392 > chipset). I'm trying to use it on a BeagleBone Black based system with > 3.14.x kernel built with Yocto. We're using ConnMan 1.30 at the moment. Try it with a _desktop x86_64 distribution_ , with a *recent kernel* as Fedora: (WORK is gnome) https://alt.fedoraproject.org/pub/alt/live-respins/ > We've been finding some instabilities with it periodically disconnecting > from some networks. So we tried upgrading the firmware file rt2870.bin > from version 0.29 to 0.36. That seems to be more stable with the > network. However, we're finding that it initially doesn't connect, until > the Wi-Fi has been disabled and then re-enabled. ' scan wifi' > and 'iwlist scan' don't return anything until Wi-Fi has been disabled > and then re-enabled. Don't use any wrapper(NM, ConnMan, wicd, ...), usually are buggy. You should use raw commands "iw" and "wpa_supplicant". Hints: https://wireless.wiki.kernel.org/en/users/documentation/iw and wpa_supplicant always running with "-Dnl80211" > Have there been any Linux driver changes needed to support this 0.36 > firmware? Does anyone have any pointers on where to look to understand > this behaviour between 0.29 and 0.36 firmware? closed source, but old changelogs are available at: http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2013-September/006391.html Related to latest firmware releases, ralink/mediatek guys say: "According to the engineers comment, the firmware didn't change much these years, just some bbp register update and led stuff." -- 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] rtlwifi: Change long delays to sleeps
Jan Kiszkawrites: > On 2016-02-15 23:12, Larry Finger wrote: >> Routine rtl_addr_delay() uses delay statements in code that can >> sleep. To improve system responsiveness, the various delay statements >> are changed. >> >> In addition, routines rtl_rfreg_delay() and rtl_bb_delay() are >> rewritten to use the code in rtl_addr_delay() for most of their >> input values. >> >> Suggested-by: Byeoungwook Kim >> Signed-off-by: Larry Finger [...] > This breaks spectacularly when turning on a little bit of correctness > checking: > > BUG: scheduling while atomic: wpa_supplicant/1116/0x0002 This should fix it: https://git.kernel.org/cgit/linux/kernel/git/kvalo/wireless-drivers.git/commit/?id=de26859dcf363d520cc44e59f6dcaf20ebe0aadf -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rtlwifi: Change long delays to sleeps
On 2016-02-15 23:12, Larry Finger wrote: > Routine rtl_addr_delay() uses delay statements in code that can > sleep. To improve system responsiveness, the various delay statements > are changed. > > In addition, routines rtl_rfreg_delay() and rtl_bb_delay() are > rewritten to use the code in rtl_addr_delay() for most of their > input values. > > Suggested-by: Byeoungwook Kim> Signed-off-by: Larry Finger > --- > > Kalle, > > This patch will interfere with a set of 3 patches submitted by Byeoungwook Kim > on Feb. 3, 2016 that are currently in the deferred list > at patchwork. > > Larry > > drivers/net/wireless/realtek/rtlwifi/core.c | 44 > - > 1 file changed, 12 insertions(+), 32 deletions(-) > > diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c > b/drivers/net/wireless/realtek/rtlwifi/core.c > index 02eba0e..16ad0d6 100644 > --- a/drivers/net/wireless/realtek/rtlwifi/core.c > +++ b/drivers/net/wireless/realtek/rtlwifi/core.c > @@ -54,59 +54,39 @@ EXPORT_SYMBOL(channel5g_80m); > void rtl_addr_delay(u32 addr) > { > if (addr == 0xfe) > - mdelay(50); > + msleep(50); > else if (addr == 0xfd) > - mdelay(5); > + msleep(5); > else if (addr == 0xfc) > - mdelay(1); > + msleep(1); > else if (addr == 0xfb) > - udelay(50); > + usleep_range(50, 100); > else if (addr == 0xfa) > - udelay(5); > + usleep_range(5, 10); > else if (addr == 0xf9) > - udelay(1); > + usleep_range(1, 2); > } > EXPORT_SYMBOL(rtl_addr_delay); > > void rtl_rfreg_delay(struct ieee80211_hw *hw, enum radio_path rfpath, u32 > addr, >u32 mask, u32 data) > { > - if (addr == 0xfe) { > - mdelay(50); > - } else if (addr == 0xfd) { > - mdelay(5); > - } else if (addr == 0xfc) { > - mdelay(1); > - } else if (addr == 0xfb) { > - udelay(50); > - } else if (addr == 0xfa) { > - udelay(5); > - } else if (addr == 0xf9) { > - udelay(1); > + if (addr >= 0xf9 && addr <= 0xfe) { > + rtl_addr_delay(addr); > } else { > rtl_set_rfreg(hw, rfpath, addr, mask, data); > - udelay(1); > + usleep_range(1, 2); > } > } > EXPORT_SYMBOL(rtl_rfreg_delay); > > void rtl_bb_delay(struct ieee80211_hw *hw, u32 addr, u32 data) > { > - if (addr == 0xfe) { > - mdelay(50); > - } else if (addr == 0xfd) { > - mdelay(5); > - } else if (addr == 0xfc) { > - mdelay(1); > - } else if (addr == 0xfb) { > - udelay(50); > - } else if (addr == 0xfa) { > - udelay(5); > - } else if (addr == 0xf9) { > - udelay(1); > + if (addr >= 0xf9 && addr <= 0xfe) { > + rtl_addr_delay(addr); > } else { > rtl_set_bbreg(hw, addr, MASKDWORD, data); > - udelay(1); > + usleep_range(1, 2); > } > } > EXPORT_SYMBOL(rtl_bb_delay); > This breaks spectacularly when turning on a little bit of correctness checking: BUG: scheduling while atomic: wpa_supplicant/1116/0x0002 [...] Call Trace: [] dump_trace+0x59/0x340 [] show_stack_log_lvl+0xfc/0x190 [] show_stack+0x21/0x40 [] dump_stack+0x5c/0x7e [] __schedule_bug+0x4b/0x59 [] thread_return+0x562/0x6b0 [] schedule+0x3c/0x90 [] schedule_hrtimeout_range_clock+0xab/0x130 [] usleep_range+0x3b/0x40 [] rtl92c_phy_config_rf_with_headerfile+0x104/0x2f0 [rtl8192ce] [] rtl92ce_phy_rf6052_config+0x1b0/0x310 [rtl8192ce] [] rtl92ce_hw_init+0xa8b/0x17e0 [rtl8192ce] [] rtl_ps_enable_nic+0x3b/0xc0 [rtlwifi] [] rtl92c_phy_set_rf_power_state+0x509/0x760 [rtl8192ce] [] rtl_ps_set_rf_state+0xd4/0x200 [rtlwifi] [] _rtl_ps_inactive_ps+0x38/0xb0 [rtlwifi] [] rtl_ips_nic_on+0x78/0xb0 [rtlwifi] [] rtl_op_config+0x278/0x440 [rtlwifi] [] ieee80211_hw_config+0x56/0x3a0 [mac80211] [] ieee80211_add_chanctx+0x17a/0x1c0 [mac80211] [] ieee80211_new_chanctx+0x2d/0x80 [mac80211] [] ieee80211_vif_use_channel+0x1fb/0x250 [mac80211] [] ieee80211_prep_connection+0x188/0x8e0 [mac80211] [] ieee80211_mgd_auth+0x22a/0x330 [mac80211] [] cfg80211_mlme_auth+0x117/0x230 [cfg80211] [] nl80211_authenticate+0x2a7/0x300 [cfg80211] [] genl_family_rcv_msg+0x1b6/0x380 [] genl_rcv_msg+0x79/0xb0 [] netlink_rcv_skb+0x92/0xa0 [] genl_rcv+0x24/0x40 [] netlink_unicast+0x146/0x1f0 [] netlink_sendmsg+0x323/0x3a0 [] sock_sendmsg+0x30/0x40 [] ___sys_sendmsg+0x279/0x290 [] __sys_sendmsg+0x41/0x70 [] do_syscall_64+0x59/0xb0 [] entry_SYSCALL64_slow_path+0x25/0x25 So please revert this commit. I agree with the general goal, but this approach does not work. I had to in order to make my wifi work again. Then, when looking deeper, those local_irq_enable constructs in
pull-request: wireless-drivers 2016-06-04
Hi Dave, few fixes for 4.7. Please let me know if you have any issues. Kalle The following changes since commit b7e7ad611e24b95b0db2998428ce78370415c086: Merge branch 'qed-fixes' (2016-05-26 12:27:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-for-davem-2016-06-04 for you to fetch changes up to 182fd9eecb287e696c82b30d06c6150d80a49c5b: MAINTAINERS: Add file patterns for wireless device tree bindings (2016-06-04 17:24:02 +0300) wireless-drivers fixes for 4.7 brcmfmac * add fallback RSSI report for devices that do not report per-chain values * fix a null pointer derefence regression on PCIe full dongle devices rtlwifi * fix scheduling while atomic regression from commit 49f86ec21c01 MAINTAINERS * add file patterns for wireless device tree bindings Franky Lin (1): brcmfmac: add eth_type_trans back for PCIe full dongle Geert Uytterhoeven (1): MAINTAINERS: Add file patterns for wireless device tree bindings Jaap Jan Meijer (1): brcmfmac: add fallback for devices that do not report per-chain values Larry Finger (1): rtlwifi: Fix scheduling while atomic error from commit 49f86ec21c01 MAINTAINERS|1 + .../broadcom/brcm80211/brcmfmac/cfg80211.c | 16 .../wireless/broadcom/brcm80211/brcmfmac/msgbuf.c |2 ++ drivers/net/wireless/realtek/rtlwifi/core.c|6 +++--- 4 files changed, 22 insertions(+), 3 deletions(-) -- 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] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets
Jonas Gorskiwrites: > On 26 May 2016 at 20:52, Avinash Patil wrote: > >> This email, including its contents and any attachment(s), may contain >> confidential information of Quantenna Communications, Inc. and is >> solely for the intended recipient(s). If you may have received this >> in error, please contact the sender and permanently delete this >> email, its contents and any attachment(s). > > You will need to remove this footer to be taken seriously, as > confidential information would be not GPL compatible, and "may > contain" means it is too risky to accept that. Yeah, I'm not going to take (or even look) patches with such disclaimers. So please resend so that we can start the review. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [7/7] mwifiex: fix typo
Julia Lawallwrote: > firmare -> firmware > > Signed-off-by: Julia Lawall Thanks, 1 patch applied to wireless-drivers-next.git: 47ce90f9f08a mwifiex: fix typo -- Sent by pwcli https://patchwork.kernel.org/patch/9113281/ -- 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: b43: don't unconditionally fall back to CCK if the rate is 6MB OFDM.
Adrian Chaddwrote: > Check the current PHY operating mode (gmode) to see if we should > fall back from 6MB OFDM to 11MB CCK. For 5GHz operation this isn't > allowed. > > Note, the fallback lookup is only done for RTS rates; normal fallback > rates are done via mac80211 and aren't affected by this change. > > Signed-off-by: Adrian Chadd Thanks, 1 patch applied to wireless-drivers-next.git: d0b03439f784 b43: don't unconditionally fall back to CCK if the rate is 6MB OFDM. -- Sent by pwcli https://patchwork.kernel.org/patch/9108351/ -- 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: [v2,1/2] brcmfmac: Fix kernel oops in failed chip_attach
Christian Daudtwrote: > When chip attach fails, brcmf_sdiod_intr_unregister is being called > but that is too early as sdiodev->settings has not been set yet > nor has brcmf_sdiod_intr_register been called. > Change to use oob_irq_requested + newly created sd_irq_requested > to decide on what to unregister at intr_unregister time. > > Steps to reproduce problem: > - modprobe brcmfmac using buggy FW > - rmmod brcmfmac > - modprobe brcmfmac again. > > If done with a buggy firmware, brcm_chip_attach will fail on the > 2nd modprobe triggering the call to intr_unregister and the > kernel oops when attempting to de-reference sdiodev->settings->bus.sdio > which has not yet been set. > > Signed-off-by: Christian Daudt Thanks, 2 patches applied to wireless-drivers-next.git: b88a2e80396b brcmfmac: Fix kernel oops in failed chip_attach b746740147dc brcmfmac: Fix 'did not remove int handler' warning -- Sent by pwcli https://patchwork.kernel.org/patch/9075231/ -- 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: [v2] carl9170: Clarify kconfig text
Lauri Kasanenwrote: > The previous text was confusing, leading readers to think this > driver was a duplicate, and so didn't need to be enabled. > > After the removal of the older staging driver, this is the only > driver in mainline for these devices. > > Signed-off-by: Lauri Kasanen > Acked-by: Christian Lamparter Thanks, 1 patch applied to wireless-drivers-next.git: 83e41e77819b carl9170: Clarify kconfig text -- Sent by pwcli https://patchwork.kernel.org/patch/8861621/ -- 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
wireless-drivers-next open for 4.8
Bob Copelandwrites: > Since Linus released 4.7-rc1 today, I've resumed wireless-testing > updates since its merge window hiatus, with tag wt-2016-05-29. > > Please test and let me know of any issues. I also opened wireless-drivers-next tree for patches going to 4.8. And wireless-drivers continues to be open for important fixes and regressions to 4.7. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] b43: Remove unused phy_a code
gcc-6 reports the following error with -Werror=unused-const-variable. drivers/net/wireless/broadcom/b43/phy_a.c:576:40: error: 'b43_phyops_a' defined but not used Per Michael Büsch: "All a-phy code is usused", so remove it all, and move the remaining Type-G initialization code into phy_g.c. Reported-by: Fengguang Wu[0-day test robot] Cc: Michael Büsch Signed-off-by: Guenter Roeck --- v3: Do not rename b43_phy_inita() v2: Remove phy_a.c; move left-over code into phy_g.c Remove now unused data structure drivers/net/wireless/broadcom/b43/Makefile | 2 +- drivers/net/wireless/broadcom/b43/phy_a.c | 595 - drivers/net/wireless/broadcom/b43/phy_a.h | 22 - drivers/net/wireless/broadcom/b43/phy_common.h | 3 - drivers/net/wireless/broadcom/b43/phy_g.c | 25 +- 5 files changed, 21 insertions(+), 626 deletions(-) delete mode 100644 drivers/net/wireless/broadcom/b43/phy_a.c diff --git a/drivers/net/wireless/broadcom/b43/Makefile b/drivers/net/wireless/broadcom/b43/Makefile index ddc4df46656f..27fab958e3d5 100644 --- a/drivers/net/wireless/broadcom/b43/Makefile +++ b/drivers/net/wireless/broadcom/b43/Makefile @@ -1,6 +1,6 @@ b43-y += main.o b43-y += bus.o -b43-$(CONFIG_B43_PHY_G)+= phy_a.o phy_g.o tables.o lo.o wa.o +b43-$(CONFIG_B43_PHY_G)+= phy_g.o tables.o lo.o wa.o b43-$(CONFIG_B43_PHY_N)+= tables_nphy.o b43-$(CONFIG_B43_PHY_N)+= radio_2055.o b43-$(CONFIG_B43_PHY_N)+= radio_2056.o diff --git a/drivers/net/wireless/broadcom/b43/phy_a.c b/drivers/net/wireless/broadcom/b43/phy_a.c deleted file mode 100644 index 99c036f5ecb7.. --- a/drivers/net/wireless/broadcom/b43/phy_a.c +++ /dev/null @@ -1,595 +0,0 @@ -/* - - Broadcom B43 wireless driver - IEEE 802.11a PHY driver - - Copyright (c) 2005 Martin Langer , - Copyright (c) 2005-2007 Stefano Brivio - Copyright (c) 2005-2008 Michael Buesch - Copyright (c) 2005, 2006 Danny van Dyk - Copyright (c) 2005, 2006 Andreas Jaggi - - This program is free software; you can redistribute it and/or modify - it under the terms of the GNU General Public License as published by - the Free Software Foundation; either version 2 of the License, or - (at your option) any later version. - - This program is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. - - You should have received a copy of the GNU General Public License - along with this program; see the file COPYING. If not, write to - the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, - Boston, MA 02110-1301, USA. - -*/ - -#include - -#include "b43.h" -#include "phy_a.h" -#include "phy_common.h" -#include "wa.h" -#include "tables.h" -#include "main.h" - - -/* Get the freq, as it has to be written to the device. */ -static inline u16 channel2freq_a(u8 channel) -{ - B43_WARN_ON(channel > 200); - - return (5000 + 5 * channel); -} - -static inline u16 freq_r3A_value(u16 frequency) -{ - u16 value; - - if (frequency < 5091) - value = 0x0040; - else if (frequency < 5321) - value = 0x; - else if (frequency < 5806) - value = 0x0080; - else - value = 0x0040; - - return value; -} - -#if 0 -/* This function converts a TSSI value to dBm in Q5.2 */ -static s8 b43_aphy_estimate_power_out(struct b43_wldev *dev, s8 tssi) -{ - struct b43_phy *phy = >phy; - struct b43_phy_a *aphy = phy->a; - s8 dbm = 0; - s32 tmp; - - tmp = (aphy->tgt_idle_tssi - aphy->cur_idle_tssi + tssi); - tmp += 0x80; - tmp = clamp_val(tmp, 0x00, 0xFF); - dbm = aphy->tssi2dbm[tmp]; - //TODO: There's a FIXME on the specs - - return dbm; -} -#endif - -static void b43_radio_set_tx_iq(struct b43_wldev *dev) -{ - static const u8 data_high[5] = { 0x00, 0x40, 0x80, 0x90, 0xD0 }; - static const u8 data_low[5] = { 0x00, 0x01, 0x05, 0x06, 0x0A }; - u16 tmp = b43_radio_read16(dev, 0x001E); - int i, j; - - for (i = 0; i < 5; i++) { - for (j = 0; j < 5; j++) { - if (tmp == (data_high[i] << 4 | data_low[j])) { - b43_phy_write(dev, 0x0069, - (i - j) << 8 | 0x00C0); - return; - } - } - } -} - -static void aphy_channel_switch(struct b43_wldev *dev, unsigned int channel) -{ - u16 freq, r8, tmp; - - freq =
[PATCH v3 2/2] b43: Completely remove support for phy_a
Per Michael Büsch: "All a-phy code is usused", so remove it all. Cc: Michael BüschSigned-off-by: Guenter Roeck --- v3: no change v2: added patch drivers/net/wireless/broadcom/b43/main.c | 31 +--- drivers/net/wireless/broadcom/b43/wa.c | 283 +++ drivers/net/wireless/broadcom/b43/xmit.c | 17 +- 3 files changed, 24 insertions(+), 307 deletions(-) diff --git a/drivers/net/wireless/broadcom/b43/main.c b/drivers/net/wireless/broadcom/b43/main.c index 4ee5c5853f9f..6e5d9095b195 100644 --- a/drivers/net/wireless/broadcom/b43/main.c +++ b/drivers/net/wireless/broadcom/b43/main.c @@ -3180,7 +3180,6 @@ static void b43_rate_memory_write(struct b43_wldev *dev, u16 rate, int is_ofdm) static void b43_rate_memory_init(struct b43_wldev *dev) { switch (dev->phy.type) { - case B43_PHYTYPE_A: case B43_PHYTYPE_G: case B43_PHYTYPE_N: case B43_PHYTYPE_LP: @@ -3194,8 +3193,6 @@ static void b43_rate_memory_init(struct b43_wldev *dev) b43_rate_memory_write(dev, B43_OFDM_RATE_36MB, 1); b43_rate_memory_write(dev, B43_OFDM_RATE_48MB, 1); b43_rate_memory_write(dev, B43_OFDM_RATE_54MB, 1); - if (dev->phy.type == B43_PHYTYPE_A) - break; /* fallthrough */ case B43_PHYTYPE_B: b43_rate_memory_write(dev, B43_CCK_RATE_1MB, 0); @@ -4604,14 +4601,6 @@ static int b43_phy_versioning(struct b43_wldev *dev) if (radio_manuf != 0x17F /* Broadcom */) unsupported = 1; switch (phy_type) { - case B43_PHYTYPE_A: - if (radio_id != 0x2060) - unsupported = 1; - if (radio_rev != 1) - unsupported = 1; - if (radio_manuf != 0x17F) - unsupported = 1; - break; case B43_PHYTYPE_B: if ((radio_id & 0xFFF0) != 0x2050) unsupported = 1; @@ -4766,10 +4755,7 @@ static void b43_set_synth_pu_delay(struct b43_wldev *dev, bool idle) u16 pu_delay; /* The time value is in microseconds. */ - if (dev->phy.type == B43_PHYTYPE_A) - pu_delay = 3700; - else - pu_delay = 1050; + pu_delay = 1050; if (b43_is_mode(dev->wl, NL80211_IFTYPE_ADHOC) || idle) pu_delay = 500; if ((dev->phy.radio_ver == 0x2050) && (dev->phy.radio_rev == 8)) @@ -4784,14 +4770,10 @@ static void b43_set_pretbtt(struct b43_wldev *dev) u16 pretbtt; /* The time value is in microseconds. */ - if (b43_is_mode(dev->wl, NL80211_IFTYPE_ADHOC)) { + if (b43_is_mode(dev->wl, NL80211_IFTYPE_ADHOC)) pretbtt = 2; - } else { - if (dev->phy.type == B43_PHYTYPE_A) - pretbtt = 120; - else - pretbtt = 250; - } + else + pretbtt = 250; b43_shm_write16(dev, B43_SHM_SHARED, B43_SHM_SH_PRETBTT, pretbtt); b43_write16(dev, B43_MMIO_TSF_CFP_PRETBTT, pretbtt); } @@ -5380,10 +5362,6 @@ static void b43_supported_bands(struct b43_wldev *dev, bool *have_2ghz_phy, /* As a fallback, try to guess using PHY type */ switch (dev->phy.type) { - case B43_PHYTYPE_A: - *have_2ghz_phy = false; - *have_5ghz_phy = true; - return; case B43_PHYTYPE_G: case B43_PHYTYPE_N: case B43_PHYTYPE_LP: @@ -5455,7 +5433,6 @@ static int b43_wireless_core_attach(struct b43_wldev *dev) /* We don't support 5 GHz on some PHYs yet */ if (have_5ghz_phy) { switch (dev->phy.type) { - case B43_PHYTYPE_A: case B43_PHYTYPE_G: case B43_PHYTYPE_LP: case B43_PHYTYPE_HT: diff --git a/drivers/net/wireless/broadcom/b43/wa.c b/drivers/net/wireless/broadcom/b43/wa.c index c218c08fb2f5..0e96c08d1e17 100644 --- a/drivers/net/wireless/broadcom/b43/wa.c +++ b/drivers/net/wireless/broadcom/b43/wa.c @@ -30,33 +30,6 @@ #include "phy_common.h" #include "wa.h" -static void b43_wa_papd(struct b43_wldev *dev) -{ - u16 backup; - - backup = b43_ofdmtab_read16(dev, B43_OFDMTAB_PWRDYN2, 0); - b43_ofdmtab_write16(dev, B43_OFDMTAB_PWRDYN2, 0, 7); - b43_ofdmtab_write16(dev, B43_OFDMTAB_UNKNOWN_APHY, 0, 0); - b43_dummy_transmission(dev, true, true); - b43_ofdmtab_write16(dev, B43_OFDMTAB_PWRDYN2, 0, backup); -} - -static void b43_wa_auxclipthr(struct b43_wldev *dev) -{ - b43_phy_write(dev, B43_PHY_OFDM(0x8E), 0x3800); -} - -static void b43_wa_afcdac(struct b43_wldev *dev) -{ - b43_phy_write(dev, 0x0035, 0x03FF); - b43_phy_write(dev, 0x0036, 0x0400); -} - -static void b43_wa_txdc_offset(struct b43_wldev *dev) -{ - b43_ofdmtab_write16(dev, B43_OFDMTAB_DC, 0, 0x0051);
Re: [PATCH 1/2] ath10k: Define an enum to enable cycle counter wraparound logic
Vasanthakumar Thiagarajanwrites: > QCA988X hw implements a different cycle counter wraparound > behaviour when compared to QCA4019. To properly handle different > wraparound logic for these chipsets replace already available > bool hw_params member, has_shifted_cc_wraparound, with an > enum which could be extended to handle different wraparound > behaviour. This patch keeps the existing logic functionally > same and a prepares cycle counter wraparound handling to > extend for other chips. > > Signed-off-by: Vasanthakumar Thiagarajan [...] > --- a/drivers/net/wireless/ath/ath10k/core.c > +++ b/drivers/net/wireless/ath/ath10k/core.c > @@ -55,7 +55,7 @@ static const struct ath10k_hw_params > ath10k_hw_params_list[] = { > .name = "qca988x hw2.0", > .patch_load_addr = QCA988X_HW_2_0_PATCH_LOAD_ADDR, > .uart_pin = 7, > - .has_shifted_cc_wraparound = true, > + .cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL, > .otp_exe_param = 0, > .channel_counters_freq_hz = 88000, > .max_probe_resp_desc_thres = 0, > @@ -224,7 +224,7 @@ static const struct ath10k_hw_params > ath10k_hw_params_list[] = { > .name = "qca4019 hw1.0", > .patch_load_addr = QCA4019_HW_1_0_PATCH_LOAD_ADDR, > .uart_pin = 7, > - .has_shifted_cc_wraparound = true, > + .cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL, > .otp_exe_param = 0x001, > .continuous_frag_desc = true, > .channel_counters_freq_hz = 125000, As the pending branch has the QCA9887 patch I added ATH10K_HW_CC_WRAP_SHIFTED_ALL also for QCA9887. Please review my changes in the pending branch: https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending=2fa32dbd9f26e8b2f323ca30ad116ea486840aba -- Kalle Valo-- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ath9k gpio request
(Fixing top posting) "Pan, Miaoqing"writes: >>> --- a/drivers/net/wireless/ath/ath9k/reg.h >>> +++ b/drivers/net/wireless/ath/ath9k/reg.h >>> @@ -1122,8 +1122,8 @@ enum { >>> #define AR9300_NUM_GPIO 16 >>> #define AR9330_NUM_GPIO 16 >>> #define AR9340_NUM_GPIO 23 >>> -#define AR9462_NUM_GPIO 10 >>> -#define AR9485_NUM_GPIO 12 >>> +#define AR9462_NUM_GPIO 14 >>> +#define AR9485_NUM_GPIO 11 >>> #define AR9531_NUM_GPIO 18 >>> #define AR9550_NUM_GPIO 24 >>> #define AR9561_NUM_GPIO 23 >>> @@ -1139,8 +1139,8 @@ enum { >>> #define AR9300_GPIO_MASK0xF4FF >>> #define AR9330_GPIO_MASK0xF4FF >>> #define AR9340_GPIO_MASK0x000F >>> -#define AR9462_GPIO_MASK0x03FF >>> -#define AR9485_GPIO_MASK0x0FFF >>> +#define AR9462_GPIO_MASK0x3FFF >>> +#define AR9485_GPIO_MASK0x07FF >>> #define AR9531_GPIO_MASK0x000F >>> #define AR9550_GPIO_MASK0x000F >>> #define AR9561_GPIO_MASK0x000F >> >> solves the problem. >> >> Tested-by: Sudip Mukherjee > > Done, https://patchwork.kernel.org/patch/9151847/ But the patch 9151847 is different from what Sudip tested above? Why? And if you modify something _after_ the reporter has tested the patch clearly document what you changed and why. I do not want find hidden changes like this, even more so when the patch is going to a 4.7-rc release. Sudip, could you also test patch 9151847, please? You can download the patch from the patchwork link above. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net: wireless: marvell: libertas: Remove create_workqueue
On Sat, Jun 4, 2016 at 7:59 PM, Kalle Valowrote: > > $ git log --oneline --no-merges -10 Sure. Will keep that in mind. Thanks, Bhaktipriya -- 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: [RFC/RFT 2/5] ath9k: use mac80211 intermediate software queues
Tim Shepardwrites: >> Reworked to not require the global variable renaming in ath9k. >> >> Signed-off-by: Toke Høiland-Jørgensen > > Huh. I wonder why you did that? Is it really better to call the > ieee80211_txq a swq and call the ath9k hardware queue a txq? I > thought doing the renaming made for more readable and much more > maintainable code (where searching for text strings produced much > cleaner results when trying to track down all references). Well, the immediate reason was that at the time I just spent two weeks figuring out how ath9k worked and what the different concepts were, and suddenly they start to mean something different. The txq->hwq renaming would probably make sense in itself, but suddenly the same variable (txq) meant something different, which was quite confusing. So I found it was easier to change your patch to not require the renaming. A secondary reason was to keep the patch delta as small as possible. I'm definitely not the right person to make that call, but I found the global renaming somewhat intrusive. As for the first point, I think it would be easier if you did not call the mac80211 queues 'txq' but something else ('swq' like I did, perhaps; I also considered 'imq' for intermediate queue). This will at least make it clear at a glance that it is something different than 'txq' was previously. > I am grateful to learn that someone has read my patched version of > ath9k at least enough to do this rework. Any comments on the actual > work? Well, it seems to work well enough (haven't noticed the pending_frames issue, but on the other hand I haven't been looking very hard). However, it does fell like somewhat of a temporary solution. Having another intermediate queue in the driver (tid->i_q) and having a side-effect in ath_tid_has_buffered() seems a bit iffy to me. Wouldn't the 'right' way to do it be to have ath_tid_has_buffered() ask the mac layer if it has any frames queued, and then have ath_tx_get_tid_subframe() basically translate straight to a call to ieee80211_tx_dequeue() (taking into account the retry queue)? Not sure if that covers all code paths, but the current approach seems like it has one too many layers of queues? Haven't given the above a lot of thought, but since you asked... :) -Toke -- 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] net: wireless: marvell: libertas: Remove create_workqueue
Bhaktipriya Shridharwrites: > alloc_workqueue replaces deprecated create_workqueue(). > > In if_sdio.c, the workqueue card->workqueue has workitem > >packet_worker, which is mapped to if_sdio_host_to_card_worker. > The workitem is involved in sending packets to firmware. > Forward progress under memory pressure is a requirement here. > > In if_spi.c, the workqueue card->workqueue has workitem > >packet_worker, which is mapped to if_spi_host_to_card_worker. > The workitem is involved in sending command packets from the host. > Forward progress under memory pressure is a requirement here. > > Dedicated workqueues have been used in both cases since the workitems > on the workqueues are involved in normal device operation with > WQ_MEM_RECLAIM set to gurantee forward progress under memory pressure. > Since there are only a fixed number of work items, explicit concurrency > limit is unnecessary. > > flush_workqueue is unnecessary since destroy_workqueue() itself calls > drain_workqueue() which flushes repeatedly till the workqueue > becomes empty. Hence the calls to flush_workqueue() before > destroy_workqueue() have been dropped. > > Signed-off-by: Bhaktipriya Shridhar "libertas:" as a prefix is enough, no need to put the full path to the title. I can fix that this time. You can actually check yourself what prefix is commonly used in a particular file or directory: $ git log --oneline --no-merges -10 drivers/net/wireless/marvell/libertas/ 57fbcce37be7 cfg80211: remove enum ieee80211_band 3691ac4a9c95 libertas: fix an error code in probe 143e49458424 libertas: add an cfg80211 interface for powersaving 0b8802dc5f59 libertas: fix ps-mode related removal problems fada24a54770 libertas: go back to ps mode without commands pending 57954b94cad7 libertas: do not confirm sleep if commands are pending fae4f9f78ab1 libertas: check whether bus can do more than polling 0a7701b4defc libertas: fix pointer bugs for PS_MODE commands 6d91ff7acc90 libertas: cleanup a variable name 0a38c8e1b592 libertas: check for NULL before use $ -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [33/54] MAINTAINERS: Add file patterns for wireless device tree bindings
Geert Uytterhoevenwrote: > Submitters of device tree binding documentation may forget to CC > the subsystem maintainer if this is missing. > > Signed-off-by: Geert Uytterhoeven > Cc: Kalle Valo > Cc: linux-wireless@vger.kernel.org Thanks, 1 patch applied to wireless-drivers.git: 182fd9eecb28 MAINTAINERS: Add file patterns for wireless device tree bindings -- Sent by pwcli https://patchwork.kernel.org/patch/9130849/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] net: wireless: marvell: libertas: Remove create_workqueue
alloc_workqueue replaces deprecated create_workqueue(). In if_sdio.c, the workqueue card->workqueue has workitem >packet_worker, which is mapped to if_sdio_host_to_card_worker. The workitem is involved in sending packets to firmware. Forward progress under memory pressure is a requirement here. In if_spi.c, the workqueue card->workqueue has workitem >packet_worker, which is mapped to if_spi_host_to_card_worker. The workitem is involved in sending command packets from the host. Forward progress under memory pressure is a requirement here. Dedicated workqueues have been used in both cases since the workitems on the workqueues are involved in normal device operation with WQ_MEM_RECLAIM set to gurantee forward progress under memory pressure. Since there are only a fixed number of work items, explicit concurrency limit is unnecessary. flush_workqueue is unnecessary since destroy_workqueue() itself calls drain_workqueue() which flushes repeatedly till the workqueue becomes empty. Hence the calls to flush_workqueue() before destroy_workqueue() have been dropped. Signed-off-by: Bhaktipriya Shridhar--- drivers/net/wireless/marvell/libertas/if_sdio.c | 3 +-- drivers/net/wireless/marvell/libertas/if_spi.c | 4 +--- 2 files changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/net/wireless/marvell/libertas/if_sdio.c b/drivers/net/wireless/marvell/libertas/if_sdio.c index 13eae9f..47f4a14 100644 --- a/drivers/net/wireless/marvell/libertas/if_sdio.c +++ b/drivers/net/wireless/marvell/libertas/if_sdio.c @@ -1228,7 +1228,7 @@ static int if_sdio_probe(struct sdio_func *func, } spin_lock_init(>lock); - card->workqueue = create_workqueue("libertas_sdio"); + card->workqueue = alloc_workqueue("libertas_sdio", WQ_MEM_RECLAIM, 0); INIT_WORK(>packet_worker, if_sdio_host_to_card_worker); init_waitqueue_head(>pwron_waitq); @@ -1326,7 +1326,6 @@ static void if_sdio_remove(struct sdio_func *func) lbs_stop_card(card->priv); lbs_remove_card(card->priv); - flush_workqueue(card->workqueue); destroy_workqueue(card->workqueue); while (card->packets) { diff --git a/drivers/net/wireless/marvell/libertas/if_spi.c b/drivers/net/wireless/marvell/libertas/if_spi.c index 82c0796..c3a53cd 100644 --- a/drivers/net/wireless/marvell/libertas/if_spi.c +++ b/drivers/net/wireless/marvell/libertas/if_spi.c @@ -1180,7 +1180,7 @@ static int if_spi_probe(struct spi_device *spi) priv->fw_ready = 1; /* Initialize interrupt handling stuff. */ - card->workqueue = create_workqueue("libertas_spi"); + card->workqueue = alloc_workqueue("libertas_spi", WQ_MEM_RECLAIM, 0); INIT_WORK(>packet_work, if_spi_host_to_card_worker); INIT_WORK(>resume_work, if_spi_resume_worker); @@ -1208,7 +1208,6 @@ static int if_spi_probe(struct spi_device *spi) release_irq: free_irq(spi->irq, card); terminate_workqueue: - flush_workqueue(card->workqueue); destroy_workqueue(card->workqueue); lbs_remove_card(priv); /* will call free_netdev */ free_card: @@ -1235,7 +1234,6 @@ static int libertas_spi_remove(struct spi_device *spi) lbs_remove_card(priv); /* will call free_netdev */ free_irq(spi->irq, card); - flush_workqueue(card->workqueue); destroy_workqueue(card->workqueue); if (card->pdata->teardown) card->pdata->teardown(spi); -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ath10k: Add board data download from target
Sven Eckelmannwrites: > The QCA9887 stores its calibration data (board.bin) inside the EEPROM of > the target. This has to be downloaded manually to allow the device to > initialize correctly. > > Signed-off-by: Sven Eckelmann [...] > --- a/drivers/net/wireless/ath/ath10k/core.c > +++ b/drivers/net/wireless/ath/ath10k/core.c > @@ -18,6 +18,7 @@ > #include > #include > #include > +#include > > #include "core.h" > #include "mac.h" > @@ -550,6 +551,34 @@ out: > return ret; > } > > +static int ath10k_download_cal_eeprom(struct ath10k *ar) > +{ > + size_t data_len; > + void *data = NULL; > + int ret; > + > + ret = ath10k_hif_fetch_target_board_data(ar, , _len); > + if (ret) { > + ath10k_warn(ar, "failed to read calibration data from EEPROM: > %d\n", > + ret); > + goto out_free; > + } Looking at this again I noticed that we issue this warning even if EEPROM is not supported, which I think is wrong. I fixed this in the pending branch, the diff is below. I also renamed target_board_data to cal_eeprom because, at least to my understanding, the eeprom actually contains the real calibration data, not the board data file. Please review so that I didn't break anything. https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending=4f79bdf2db7bcfa9c7c093fd423af801b9797c63 diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c index 10a1b620a68b..1e88251ca6d0 100644 --- a/drivers/net/wireless/ath/ath10k/core.c +++ b/drivers/net/wireless/ath/ath10k/core.c @@ -580,10 +580,11 @@ static int ath10k_download_cal_eeprom(struct ath10k *ar) void *data = NULL; int ret; - ret = ath10k_hif_fetch_target_board_data(ar, , _len); + ret = ath10k_hif_fetch_cal_eeprom(ar, , _len); if (ret) { - ath10k_warn(ar, "failed to read calibration data from EEPROM: %d\n", - ret); + if (ret != -EOPNOTSUPP) + ath10k_warn(ar, "failed to read calibration data from EEPROM: %d\n", + ret); goto out_free; } diff --git a/drivers/net/wireless/ath/ath10k/hif.h b/drivers/net/wireless/ath/ath10k/hif.h index c18b8c81bde4..b2566b06e1e1 100644 --- a/drivers/net/wireless/ath/ath10k/hif.h +++ b/drivers/net/wireless/ath/ath10k/hif.h @@ -88,9 +88,9 @@ struct ath10k_hif_ops { int (*suspend)(struct ath10k *ar); int (*resume)(struct ath10k *ar); - /* fetch board data from target eeprom */ - int (*fetch_target_board_data)(struct ath10k *ar, void **data, - size_t *data_len); + /* fetch calibration data from target eeprom */ + int (*fetch_cal_eeprom)(struct ath10k *ar, void **data, + size_t *data_len); }; static inline int ath10k_hif_tx_sg(struct ath10k *ar, u8 pipe_id, @@ -206,14 +206,14 @@ static inline void ath10k_hif_write32(struct ath10k *ar, ar->hif.ops->write32(ar, address, data); } -static inline int ath10k_hif_fetch_target_board_data(struct ath10k *ar, -void **data, -size_t *data_len) +static inline int ath10k_hif_fetch_cal_eeprom(struct ath10k *ar, + void **data, + size_t *data_len) { - if (!ar->hif.ops->fetch_target_board_data) + if (!ar->hif.ops->fetch_cal_eeprom) return -EOPNOTSUPP; - return ar->hif.ops->fetch_target_board_data(ar, data, data_len); + return ar->hif.ops->fetch_cal_eeprom(ar, data, data_len); } #endif /* _HIF_H_ */ diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c index fb53f8846efd..f06dd3941bac 100644 --- a/drivers/net/wireless/ath/ath10k/pci.c +++ b/drivers/net/wireless/ath/ath10k/pci.c @@ -2678,8 +2678,8 @@ static int ath10k_pci_read_eeprom(struct ath10k *ar, u16 addr, u8 *out) return 0; } -static int ath10k_pci_fetch_target_board_data(struct ath10k *ar, void **data, - size_t *data_len) +static int ath10k_pci_hif_fetch_cal_eeprom(struct ath10k *ar, void **data, + size_t *data_len) { u8 *caldata = NULL; size_t calsize, i; @@ -2734,7 +2734,7 @@ static const struct ath10k_hif_ops ath10k_pci_hif_ops = { .suspend= ath10k_pci_hif_suspend, .resume = ath10k_pci_hif_resume, #endif - .fetch_target_board_data = ath10k_pci_fetch_target_board_data, + .fetch_cal_eeprom = ath10k_pci_hif_fetch_cal_eeprom, }; /* -- Kalle Valo-- To unsubscribe from this list: send the line "unsubscribe
Re: [PATCH 1/2] ath10k: add QCA9887 chipset support
Sven Eckelmannwrites: > Add the hardware name, revision, firmware names and update the pci_id > table. > > QA9887 HW1.0 is supposed to be similar to QCA988X HW2.0 . Details about > he firmware interface are currently unknown. > > Signed-off-by: Sven Eckelmann I added the warning we talked about, diff below. Full patch in the pending branch: https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending=ed730faad11df99f2aba3b8d78ac5587c3403e69 diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c index d34c32a075ac..3e8e7ed6faa1 100644 --- a/drivers/net/wireless/ath/ath10k/pci.c +++ b/drivers/net/wireless/ath/ath10k/pci.c @@ -3005,6 +3005,7 @@ static int ath10k_pci_probe(struct pci_dev *pdev, pci_hard_reset = ath10k_pci_qca988x_chip_reset; break; case QCA9887_1_0_DEVICE_ID: + dev_warn(>dev, "QCA9887 support is still experimental, there are likely bugs. You have been warned.\n"); hw_rev = ATH10K_HW_QCA9887; pci_ps = false; pci_soft_reset = ath10k_pci_warm_reset; -- Kalle Valo-- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers: ssb: Change bare unsigned to unsigned int to suit coding style
On Sat, 4 Jun 2016 12:50:05 +0100 Hugh Sipièrewrote: > These lines just have unsigned gpio rather than unsigned int gpio. > I changed it to suit the coding style. > > Signed-off-by: Hugh Sipière Acked-by: Michael Buesch Please send this to the MIPS tree, because this basically is MIPS-only code: MIPS M: Ralf Baechle L: linux-m...@linux-mips.org -- Michael pgprMkyfNGSBd.pgp Description: OpenPGP digital signature
[PATCH] drivers: ssb: Change bare unsigned to unsigned int to suit coding style
These lines just have unsigned gpio rather than unsigned int gpio. I changed it to suit the coding style. Signed-off-by: Hugh Sipière--- drivers/ssb/driver_gpio.c | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/drivers/ssb/driver_gpio.c b/drivers/ssb/driver_gpio.c index 180e027..796e220 100644 --- a/drivers/ssb/driver_gpio.c +++ b/drivers/ssb/driver_gpio.c @@ -23,7 +23,7 @@ **/ #if IS_ENABLED(CONFIG_SSB_EMBEDDED) -static int ssb_gpio_to_irq(struct gpio_chip *chip, unsigned gpio) +static int ssb_gpio_to_irq(struct gpio_chip *chip, unsigned int gpio) { struct ssb_bus *bus = gpiochip_get_data(chip); @@ -38,14 +38,14 @@ static int ssb_gpio_to_irq(struct gpio_chip *chip, unsigned gpio) * ChipCommon **/ -static int ssb_gpio_chipco_get_value(struct gpio_chip *chip, unsigned gpio) +static int ssb_gpio_chipco_get_value(struct gpio_chip *chip, unsigned int gpio) { struct ssb_bus *bus = gpiochip_get_data(chip); return !!ssb_chipco_gpio_in(>chipco, 1 << gpio); } -static void ssb_gpio_chipco_set_value(struct gpio_chip *chip, unsigned gpio, +static void ssb_gpio_chipco_set_value(struct gpio_chip *chip, unsigned int gpio, int value) { struct ssb_bus *bus = gpiochip_get_data(chip); @@ -54,7 +54,7 @@ static void ssb_gpio_chipco_set_value(struct gpio_chip *chip, unsigned gpio, } static int ssb_gpio_chipco_direction_input(struct gpio_chip *chip, - unsigned gpio) + unsigned int gpio) { struct ssb_bus *bus = gpiochip_get_data(chip); @@ -63,7 +63,7 @@ static int ssb_gpio_chipco_direction_input(struct gpio_chip *chip, } static int ssb_gpio_chipco_direction_output(struct gpio_chip *chip, - unsigned gpio, int value) + unsigned int gpio, int value) { struct ssb_bus *bus = gpiochip_get_data(chip); @@ -72,7 +72,7 @@ static int ssb_gpio_chipco_direction_output(struct gpio_chip *chip, return 0; } -static int ssb_gpio_chipco_request(struct gpio_chip *chip, unsigned gpio) +static int ssb_gpio_chipco_request(struct gpio_chip *chip, unsigned int gpio) { struct ssb_bus *bus = gpiochip_get_data(chip); @@ -85,7 +85,7 @@ static int ssb_gpio_chipco_request(struct gpio_chip *chip, unsigned gpio) return 0; } -static void ssb_gpio_chipco_free(struct gpio_chip *chip, unsigned gpio) +static void ssb_gpio_chipco_free(struct gpio_chip *chip, unsigned int gpio) { struct ssb_bus *bus = gpiochip_get_data(chip); @@ -256,14 +256,14 @@ static int ssb_gpio_chipco_init(struct ssb_bus *bus) #ifdef CONFIG_SSB_DRIVER_EXTIF -static int ssb_gpio_extif_get_value(struct gpio_chip *chip, unsigned gpio) +static int ssb_gpio_extif_get_value(struct gpio_chip *chip, unsigned int gpio) { struct ssb_bus *bus = gpiochip_get_data(chip); return !!ssb_extif_gpio_in(>extif, 1 << gpio); } -static void ssb_gpio_extif_set_value(struct gpio_chip *chip, unsigned gpio, +static void ssb_gpio_extif_set_value(struct gpio_chip *chip, unsigned int gpio, int value) { struct ssb_bus *bus = gpiochip_get_data(chip); @@ -272,7 +272,7 @@ static void ssb_gpio_extif_set_value(struct gpio_chip *chip, unsigned gpio, } static int ssb_gpio_extif_direction_input(struct gpio_chip *chip, - unsigned gpio) + unsigned int gpio) { struct ssb_bus *bus = gpiochip_get_data(chip); @@ -281,7 +281,7 @@ static int ssb_gpio_extif_direction_input(struct gpio_chip *chip, } static int ssb_gpio_extif_direction_output(struct gpio_chip *chip, - unsigned gpio, int value) + unsigned int gpio, int value) { struct ssb_bus *bus = gpiochip_get_data(chip); -- 2.5.5 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers: ssb: Fix comments to suit coding style
On Sat, 4 Jun 2016 12:32:13 +0100 Hugh Sipièrewrote: > I changed it so that these two comments do not end on a line with text. > > Signed-off-by: Hugh Sipière > --- > drivers/ssb/driver_gpio.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/ssb/driver_gpio.c b/drivers/ssb/driver_gpio.c > index 180e027..f2435f3 100644 > --- a/drivers/ssb/driver_gpio.c > +++ b/drivers/ssb/driver_gpio.c > @@ -231,7 +231,8 @@ static int ssb_gpio_chipco_init(struct ssb_bus *bus) > chip->ngpio = 16; > /* There is just one SoC in one device and its GPIO addresses should be >* deterministic to address them more easily. The other buses could get > - * a random base number. */ > + * a random base number. > + */ > if (bus->bustype == SSB_BUSTYPE_SSB) > chip->base = 0; > else > @@ -424,7 +425,8 @@ static int ssb_gpio_extif_init(struct ssb_bus *bus) > chip->ngpio = 5; > /* There is just one SoC in one device and its GPIO addresses should be >* deterministic to address them more easily. The other buses could get > - * a random base number. */ > + * a random base number. > + */ > if (bus->bustype == SSB_BUSTYPE_SSB) > chip->base = 0; > else What's the benefit from this change? Will the next person submit a patch to remove wasted lines that just contain a */? -- Michael pgpt0LkZKe3iZ.pgp Description: OpenPGP digital signature
[PATCH] drivers: ssb: Fix comments to suit coding style
I changed it so that these two comments do not end on a line with text. Signed-off-by: Hugh Sipière--- drivers/ssb/driver_gpio.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/ssb/driver_gpio.c b/drivers/ssb/driver_gpio.c index 180e027..f2435f3 100644 --- a/drivers/ssb/driver_gpio.c +++ b/drivers/ssb/driver_gpio.c @@ -231,7 +231,8 @@ static int ssb_gpio_chipco_init(struct ssb_bus *bus) chip->ngpio = 16; /* There is just one SoC in one device and its GPIO addresses should be * deterministic to address them more easily. The other buses could get -* a random base number. */ +* a random base number. +*/ if (bus->bustype == SSB_BUSTYPE_SSB) chip->base = 0; else @@ -424,7 +425,8 @@ static int ssb_gpio_extif_init(struct ssb_bus *bus) chip->ngpio = 5; /* There is just one SoC in one device and its GPIO addresses should be * deterministic to address them more easily. The other buses could get -* a random base number. */ +* a random base number. +*/ if (bus->bustype == SSB_BUSTYPE_SSB) chip->base = 0; else -- 2.5.5 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Drivers: ssb: Fix bare unsigned and changed to trailing comments
Hi Hugh, On Sat, Jun 4, 2016 at 10:39 AM, Hugh Sipierewrote: > I changed drivers/ssb/driver_gpio.c to better fit the coding style. > I changed unsigned to unsigned int > Two comments were changed to not end on a line with the text. > > Signed-off-by: Hugh Sipiere You should separate the changes into two patches, one to change "unsigned" to "unsigned int" and one to fix the comments. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ -- 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 v2 1/2] b43: Remove unused phy_a code
On Fri, 3 Jun 2016 21:11:51 -0700 Guenter Roeckwrote: > +static void __b43_phy_initg(struct b43_wldev *dev) > +{ > + struct b43_phy *phy = >phy; > + > + might_sleep(); > + > + if (phy->rev >= 6) { > + if (b43_phy_read(dev, B43_PHY_ENCORE) & B43_PHY_ENCORE_EN) > + b43_phy_set(dev, B43_PHY_ENCORE, 0x0010); > + else > + b43_phy_mask(dev, B43_PHY_ENCORE, ~0x1010); > + } > + > + b43_wa_all(dev); > + > + if (dev->dev->bus_sprom->boardflags_lo & B43_BFL_PACTRL) > + b43_phy_maskset(dev, B43_PHY_OFDM(0x6E), 0xE000, 0x3CF); > +} > + > static void b43_phy_initg(struct b43_wldev *dev) > { > struct b43_phy *phy = >phy; > @@ -1999,7 +2019,7 @@ static void b43_phy_initg(struct b43_wldev *dev) > b43_phy_initb6(dev); > > if (phy->rev >= 2 || phy->gmode) > - b43_phy_inita(dev); > + __b43_phy_initg(dev); This actually is correctly called inita(), because there are A-phy parts in the G-phy. So I wasn't 100% correct saying that _all_ a-phy code is unused. I'm Ok with moving that into the g-phy file though. But don't rename it. -- Michael pgp1mgBgFViAO.pgp Description: OpenPGP digital signature