Re: PROBLEM: Boot failure with bad RIP value
On Fri, Oct 31, 2014 at 10:07:59AM -0500, Larry Finger wrote: > On 10/31/2014 08:56 AM, S. Gilles wrote: > >> 03:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. > >> RTL8188CE 802.11b/g/n WiFi Adapter [10ec:8176] (rev 01) > > > > Any progress on this, or duplication? If this isn't replicable with > > the information in Bugzilla, I can provide anything requested. > > Thanks for posting the PCI ID. I am currently on a family vacation, and I > have > had little time for driver problems, and none for chasing missing information. My apologies, I didn't realize you were still away. > The attached patches should fix the kernel crashes; however, I doubt that the > driver will work. There seems to be a problem with DMA buffers that I have > not > had time to find. For the sake of followp, I can confirm on my machine: the boot is fine but no /dev/wlan0. Thanks for the patches, I'll remain available to test any more if needed. -- S. Gilles -- 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
BCM43228 wireless card broken in kernel update [b43]
After the kernel update to 3.17.1-1-ARCH, I can view a list of wireless networks but not connect to any. Both GNOME network manager and wicd-gtk say "Connecting..." then without an error message change to "Not Connected". Here is the dmesg output that occurs when trying to connect to a wireless network, with my router hardware address redacted: [ 1363.980448] wlp4s0: authenticate with [redacted] [ 1364.066378] wlp4s0: send auth to [redacted] (try 1/3) [ 1364.068641] wlp4s0: authenticated [ 1364.069358] wlp4s0: associate with [redacted] (try 1/3) [ 1364.073798] wlp4s0: RX AssocResp from [redacted] (capab=0x411 status=0 aid=2) [ 1364.073869] wlp4s0: associated [ 1364.073927] IPv6: ADDRCONF(NETDEV_CHANGE): wlp4s0: link becomes ready [ 1364.074029] cfg80211: Calling CRDA to update world regulatory domain [ 1369.624786] wlp4s0: deauthenticating from [redacted] by local choice (Reason: 3=DEAUTH_LEAVING) Here is the exact model of the card, and other information from lspci if it is helpful: 04:00.0 Network controller [0280]: Broadcom Corporation BCM43228 802.11a/b/g/n [14e4:4359] Subsystem: Broadcom Corporation Device [14e4:0607] Flags: bus master, fast devsel, latency 0, IRQ 17 Memory at f250 (64-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [58] Vendor Specific Information: Len=78 Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [d0] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [13c] Virtual Channel Capabilities: [160] Device Serial Number [redacted] Capabilities: [16c] Power Budgeting Kernel driver in use: bcma-pci-bridge Kernel modules: bcma, wl I do not know why "wl" is listed as an available module because I uninstalled broadcom-wl already. I am using the b43 driver, along with b43-firmware from Arch Linux AUR, but broadcom-wl does not work either (same issue where I can view networks but not connect). Everything worked before I updated my kernel. It also may be interesting that on startup, I get this dmesg output: Broadcom BCM4359 802.11 Hybrid Wireless Controller 6.30.223.248 (r487574) however my card is BCM43228 not BCM4359. Here is the output of `lsmod | grep b43`: b43 410153 0 mac80211 604456 1 b43 ssb65506 1 b43 rng_core 12808 1 b43 pcmcia 53108 2 b43,ssb cfg80211 445286 2 b43,mac80211 led_class 12859 2 b43,thinkpad_acpi bcma 45915 1 b43 mmc_core 110434 3 b43,ssb,rtsx_pci_sdmmc I am connected by Ethernet right now but would prefer to use wireless. My distribution is Arch Linux. Thank you for any help. -- Duncan de Wet -- 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 2014-10-31
From: "John W. Linville" Date: Fri, 31 Oct 2014 15:58:17 -0400 > Please pull this small batch of spooky fixes intended for the 3.18 > stream...boo! Scary... but pulled. Thanks a lot! -- 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: bluetooth-next 2014-10-31
On Fri, Oct 31, 2014 at 08:28:03PM +0200, Johan Hedberg wrote: > Hi John, > > Here's the first bluetooth-next pull request for 3.19. The vast majority > of patches are for ieee802154 from Alexander Aring with various fixes > and cleanups. There are also several LE/SMP fixes as well as improved > support for handling LE devices that have lost their pairing information > (the patches from Alfonso). Jukka provides a couple of stability fixes > for 6lowpan and Szymon conformance fixes for RFCOMM. For the HCI drivers > we have one new USB ID for an Acer controller as well as a reset > handling fix for H5. > > Please let me know if there are any issues pulling. Thanks. > > Johan > > --- > The following changes since commit 61ed53deb1c6a4386d8710dbbfcee8779c381931: > > Merge tag 'ntb-3.18' of git://github.com/jonmason/ntb (2014-10-19 12:58:22 > -0700) > > are available in the git repository at: > > > git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git > for-upstream > > for you to fetch changes up to b509c02d0f31639dda90f9b7269668b86c9b25ef: > > Bluetooth: HCI H5 peer reset detection (2014-10-31 19:54:34 +0200) Pulling now... -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- 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 3/3] ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries
On Tue, Oct 28, 2014 at 01:19:12PM +0100, Arend van Spriel wrote: > Use the helper to get rid of the file operations per debugfs file. The > struct ath9k_softc pointer is set as device driver data to be obtained > in the seq_file read operation. > > Signed-off-by: Arend van Spriel Acked-by: John W. Linville -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- 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/3] ath: use seq_file api for ath9k debugfs files
On Tue, Oct 28, 2014 at 01:19:11PM +0100, Arend van Spriel wrote: > The debugfs files that are defined in debug.c which are read-only > and using a simple_open as .open file operation have been modified > to use the single_open seq_file API. This simplifies the read > functions defining the file contents. > > Signed-off-by: Arend van Spriel Acked-by: John W. Linville -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- 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
pull request: wireless 2014-10-31
Dave,
Please pull this small batch of spooky fixes intended for the 3.18
stream...boo!
Cyril Brulebois adds an rt2x00 device ID.
Dan Carpenter provides a one-line masking fix for an ath9k debugfs
entry.
Larry Finger gives us a package of small rtlwifi fixes which add some
bits that were left out of some feature updates that were included
in the merge window. Hopefully this isn't a sign that the rtlwifi
base is getting too big...
Marc Yang brings a fix for a temporary mwifiex stall when doing 11n
RX reordering.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 99c814066e75d09e6a38574c6c395f022a04b730:
Merge tag 'mac80211-for-john-2014-10-23' of
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 (2014-10-27
13:38:15 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git
tags/master-2014-10-30
for you to fetch changes up to 75a916e1944fea8347d2245c62567187e4eff9dd:
rtlwifi: rtl8192se: Fix firmware loading (2014-10-30 15:00:23 -0400)
Cyril Brulebois (1):
wireless: rt2x00: add new rt2800usb device
Dan Carpenter (1):
ath9k: fix some debugfs output
Larry Finger (5):
rtlwifi: rtl8192ce: rtl8192de: rtl8192se: Fix handling for missing
get_btc_status
rtlwifi: rtl8192se: Fix duplicate calls to ieee80211_register_hw()
rtlwifi: rtl8192se: Add missing section to read descriptor setting
rtlwifi: rtl8192ce: Add missing section to read descriptor setting
rtlwifi: rtl8192se: Fix firmware loading
Marc Yang (1):
mwifiex: restart rxreorder timer correctly
drivers/net/wireless/ath/ath9k/debug.c | 2 +-
drivers/net/wireless/mwifiex/11n_rxreorder.c | 52 +---
drivers/net/wireless/mwifiex/11n_rxreorder.h | 2 ++
drivers/net/wireless/mwifiex/main.h | 1 +
drivers/net/wireless/rt2x00/rt2800usb.c | 1 +
drivers/net/wireless/rtlwifi/core.c | 6
drivers/net/wireless/rtlwifi/core.h | 1 +
drivers/net/wireless/rtlwifi/rtl8192ce/def.h | 2 ++
drivers/net/wireless/rtlwifi/rtl8192ce/sw.c | 1 +
drivers/net/wireless/rtlwifi/rtl8192ce/trx.c | 3 ++
drivers/net/wireless/rtlwifi/rtl8192de/sw.c | 1 +
drivers/net/wireless/rtlwifi/rtl8192se/def.h | 2 ++
drivers/net/wireless/rtlwifi/rtl8192se/sw.c | 22 ++--
drivers/net/wireless/rtlwifi/rtl8192se/trx.c | 3 ++
14 files changed, 67 insertions(+), 32 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/debug.c
b/drivers/net/wireless/ath/ath9k/debug.c
index 46f20a309b5f..5c45e787814e 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -455,7 +455,7 @@ static ssize_t read_file_dma(struct file *file, char __user
*user_buf,
"%2d %2x %1x %2x %2x\n",
i, (*qcuBase & (0x7 << qcuOffset)) >> qcuOffset,
(*qcuBase & (0x8 << qcuOffset)) >> (qcuOffset + 3),
-val[2] & (0x7 << (i * 3)) >> (i * 3),
+(val[2] & (0x7 << (i * 3))) >> (i * 3),
(*dcuBase & (0x1f << dcuOffset)) >> dcuOffset);
}
diff --git a/drivers/net/wireless/mwifiex/11n_rxreorder.c
b/drivers/net/wireless/mwifiex/11n_rxreorder.c
index 40057079ffb9..5ef5a0eeba50 100644
--- a/drivers/net/wireless/mwifiex/11n_rxreorder.c
+++ b/drivers/net/wireless/mwifiex/11n_rxreorder.c
@@ -196,6 +196,7 @@ mwifiex_del_rx_reorder_entry(struct mwifiex_private *priv,
mwifiex_11n_dispatch_pkt_until_start_win(priv, tbl, start_win);
del_timer_sync(&tbl->timer_context.timer);
+ tbl->timer_context.timer_is_set = false;
spin_lock_irqsave(&priv->rx_reorder_tbl_lock, flags);
list_del(&tbl->list);
@@ -297,6 +298,7 @@ mwifiex_flush_data(unsigned long context)
(struct reorder_tmr_cnxt *) context;
int start_win, seq_num;
+ ctx->timer_is_set = false;
seq_num = mwifiex_11n_find_last_seq_num(ctx);
if (seq_num < 0)
@@ -385,6 +387,7 @@ mwifiex_11n_create_rx_reorder_tbl(struct mwifiex_private
*priv, u8 *ta,
new_node->timer_context.ptr = new_node;
new_node->timer_context.priv = priv;
+ new_node->timer_context.timer_is_set = false;
init_timer(&new_node->timer_context.timer);
new_node->timer_context.timer.function = mwifiex_flush_data;
@@ -399,6 +402,22 @@ mwifiex_11n_create_rx_reorder_tbl(struct mwifiex_private
*priv, u8 *ta,
spin_unlock_irqrestore(&priv->rx_reorder_tbl_lock, flags);
}
+static void
+mwifiex_11n_rxreorder_timer_restart(struct mwifiex_rx_reorder_tbl *tbl)
+{
+ u32 min_flush_time;
+
+ if (tbl->win_size >= MWIFIEX_BA_WIN_SIZE_32)
+ min_flush_time = MIN_FLUSH_TIMER_15_MS;
+ else
+ min_flush_time = MIN_FLUSH_TIMER_
pull request: bluetooth-next 2014-10-31
Hi John, Here's the first bluetooth-next pull request for 3.19. The vast majority of patches are for ieee802154 from Alexander Aring with various fixes and cleanups. There are also several LE/SMP fixes as well as improved support for handling LE devices that have lost their pairing information (the patches from Alfonso). Jukka provides a couple of stability fixes for 6lowpan and Szymon conformance fixes for RFCOMM. For the HCI drivers we have one new USB ID for an Acer controller as well as a reset handling fix for H5. Please let me know if there are any issues pulling. Thanks. Johan --- The following changes since commit 61ed53deb1c6a4386d8710dbbfcee8779c381931: Merge tag 'ntb-3.18' of git://github.com/jonmason/ntb (2014-10-19 12:58:22 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git for-upstream for you to fetch changes up to b509c02d0f31639dda90f9b7269668b86c9b25ef: Bluetooth: HCI H5 peer reset detection (2014-10-31 19:54:34 +0200) Alexander Aring (103): ieee802154: 6lowpan: fix byteorder for frag tag ieee802154: reassembly: fix tag byteorder ieee802154: 6lowpan: fix sign of errno return val at86rf230: fix errno on tx timeout handling at86rf230: add missing error handling at86rf230: correct aret lifs and sifs handling at86rf230: correct at86rf2xx lifs timings at86rf230: squash unnecessary dereferencing at86rf230: add missing enable_irq at86rf230: fix race condition at86rf230: fix enable_irq handling on async spi at86rf230: remove unnecessary print of async error ieee802154: 6lowpan: improve packet registration ieee802154: 6lowpan: add RTNL assertion ieee802154: mac802154: remove FSF address ieee802154: ieee802154_dev: fix align typo mac802154: fix typo IEEE802515 to IEEE802154 ieee802154: wpan-phy: change to __aligned(size) ieee802154: wpan-phy: use blank line after function ieee802154: wpan-class: fix trailing semicolon mac802154: move ieee802154_dev.c to main.c mac802154: move mac802154.h to ieee802154_i.h mac802154: move wpan.c to iface.c ieee802154: move wpan-phy.h to cfg802154.h ieee802154: move wpan-class.c to core.c ieee802154: move ieee802154 header MAINTAINERS: add missing headers in 802.15.4 ieee802154: remove fakehard driver ieee802154: rename ieee802154_dev to ieee802154_hw mac802154: rename mac802154_priv to ieee802154_local mac802154: rename mac802154_sub_if_data mac802154: rename hw subif_data variable to local mac802154: rename sdata slaves and slaves_mtx mac802154: introduce hw_to_local function mac802154: introduce IEEE802154_DEV_TO_SUB_IF mac802154: rename dev_workqueue to workqueue mac802154: remove ieee802154_addr from driver_ops mac802154: tx: move xmit callback to tx file mac802154: tx: remove kmalloc in xmit hotpath mac802154: tx: squash multiple dereferencing mac802154: tx: remove xmit channel context switch mac802154: add netdev qeue helpers mac802154: tx: use queue helpers in xmit worker mac802154: tx: fix error handling while xmit mac802154: tx: add support for xmit_async callback mac802154: tx: don't allow if down while sync tx mac802154: tx: use netdev print helpers mac802154: tx: cleanup crc calculation mac802154: tx: move stats tx increment mac802154: tx: change naming convention mac802154: tx: add comment at sync xmit callback at86rf230: asynchronous xmit handling mac802154: tx: make worker information static mac802154: tx: use put_unaligned_le16 for copy crc ieee802154: drivers: use dev_alloc_skb mac802154: rx: use tasklet instead workqueue mac802154: rx: document ieee802154_rx() context requirement mac802154: rx: move receive handling into rx.c mac802154: tx: remove monitor receive while xmit mac802154: rx: rename remove mac802154_subif_rx mac802154: rx: move skb->protocol setting mac802154: rx: add CHECKSUM_UNNECESSARY mac802154: rx: add monitor pkt_type information mac802154: rx: move skb_reset_mac_header mac802154: rx: move rcu locking ieee802154: add valid psdu length helper at86rf230: use ieee802154_is_valid_psdu_len helper at86rf230: improve receive handling mac802154: rx: change naming convention mac802154: monitor: merge into iface implementation mac802154: main: move open and close into iface mac802154: declare struct ieee802154_ops as const mac802154: ops: declare channel and page as u8 mac802154: introduce driver-ops header mac802154: use driver-ops function wrappers mac802154: remove might_sleep from driver layer mac802154: remove driver ops in wpan-
Re: [PATCH] mac80211-hwsim: add frequency attribute to netlink pkts
On 10/31/2014 01:02 AM, Jukka Rissanen wrote: > Hi Ben & Johannes, > > while rebasing my hwsim patches on top of Ben's patches, I noticed that > the freq attribute is not mentioned in hwsim_genl_policy struct. The > same applies also to radio name and vif attributes. Just wondered should > they be mentioned in the policy struct like the other attributes? Thanks for fixing that! Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] cfg80211: 802.11p OCB mode handling
On Fri, 2014-10-31 at 16:12 +0100, Rostislav Lisovy wrote:
> On Fri, 2014-10-31 at 14:13 +0100, Johannes Berg wrote:
> > On Thu, 2014-10-30 at 11:42 +0100, Rostislav Lisovy wrote:
> > > @@ -2093,6 +2102,7 @@ enum nl80211_iftype {
> > > NL80211_IFTYPE_P2P_CLIENT,
> > > NL80211_IFTYPE_P2P_GO,
> > > NL80211_IFTYPE_P2P_DEVICE,
> > > + NL80211_IFTYPE_OCB,
> >
> > This is causing a bunch of compiler warnings (warning: enumeration value
> > ‘NL80211_IFTYPE_OCB’ not handled in switch, e.g. in mac80211/iface.c)
> > which I think you should address in this patch. That'll mean that you
> > modify even mac80211 and potentially some drivers, but I think that's
> > the right thing to do in this patch since it's the one changing the API
> > to introduce the new value.
>
> I was aware of the warnings but thought this is the chicken-egg problem
> which can't be solved properly.
> Fortunately there is no driver affected.
Yeah I checked the drivers after sending the mail :)
I think you can add dummy "case OCB" statements to mac80211 in this
patch, and then overwrite them with proper code in the next one. I'd
like to have the build warning-free for every commit, if at all
possible.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] cfg80211: 802.11p OCB mode handling
On Fri, 2014-10-31 at 14:13 +0100, Johannes Berg wrote:
> On Thu, 2014-10-30 at 11:42 +0100, Rostislav Lisovy wrote:
> > @@ -2093,6 +2102,7 @@ enum nl80211_iftype {
> > NL80211_IFTYPE_P2P_CLIENT,
> > NL80211_IFTYPE_P2P_GO,
> > NL80211_IFTYPE_P2P_DEVICE,
> > + NL80211_IFTYPE_OCB,
>
> This is causing a bunch of compiler warnings (warning: enumeration value
> ‘NL80211_IFTYPE_OCB’ not handled in switch, e.g. in mac80211/iface.c)
> which I think you should address in this patch. That'll mean that you
> modify even mac80211 and potentially some drivers, but I think that's
> the right thing to do in this patch since it's the one changing the API
> to introduce the new value.
I was aware of the warnings but thought this is the chicken-egg problem
which can't be solved properly.
Fortunately there is no driver affected.
> I think there's one thing you forgot in this patch, namely
> __cfg80211_leave() which you also need to make the __ version of the
> leave function non-static for due to locking.
Correct. Adding to the next version of the patchset.
Thank you;
Rostislav
--
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: PROBLEM: Boot failure with bad RIP value
On 10/31/2014 08:56 AM, S. Gilles wrote:
03:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8188CE
802.11b/g/n WiFi Adapter [10ec:8176] (rev 01)
Any progress on this, or duplication? If this isn't replicable with
the information in Bugzilla, I can provide anything requested.
Thanks for posting the PCI ID. I am currently on a family vacation, and I have
had little time for driver problems, and none for chasing missing information.
The attached patches should fix the kernel crashes; however, I doubt that the
driver will work. There seems to be a problem with DMA buffers that I have not
had time to find.
Larry
>From bbaf5c9fc3bf1cf30576b546988e4e33cbd9c4a5 Mon Sep 17 00:00:00 2001
From: Larry Finger
Date: Sat, 25 Oct 2014 23:39:08 -0500
Subject: [PATCH 2/7] rtlwifi: rtl8192ce: rtl8192de: rtl8192se: Fix handling
for missing get_btc_status
To: linvi...@tuxdriver.com
Cc: net...@vger.kernel.org,
troy_...@realsil.com.cn
The recent changes in checking for Bluetooth status added some callbacks to code
in rtlwifi. To make certain that all callbacks are defined, a dummy routine has been
added to rtlwifi, and the drivers that need to use it are modified.
Signed-off-by: Larry Finger
---
drivers/net/wireless/rtlwifi/core.c | 6 ++
drivers/net/wireless/rtlwifi/core.h | 1 +
drivers/net/wireless/rtlwifi/rtl8192ce/sw.c | 1 +
drivers/net/wireless/rtlwifi/rtl8192de/sw.c | 1 +
drivers/net/wireless/rtlwifi/rtl8192se/sw.c | 1 +
5 files changed, 10 insertions(+)
diff --git a/drivers/net/wireless/rtlwifi/core.c b/drivers/net/wireless/rtlwifi/core.c
index f6179bc..07dae0d 100644
--- a/drivers/net/wireless/rtlwifi/core.c
+++ b/drivers/net/wireless/rtlwifi/core.c
@@ -1828,3 +1828,9 @@ const struct ieee80211_ops rtl_ops = {
.flush = rtl_op_flush,
};
EXPORT_SYMBOL_GPL(rtl_ops);
+
+bool rtl_btc_status_false(void)
+{
+ return false;
+}
+EXPORT_SYMBOL_GPL(rtl_btc_status_false);
diff --git a/drivers/net/wireless/rtlwifi/core.h b/drivers/net/wireless/rtlwifi/core.h
index 59cd3b9..624e1dc 100644
--- a/drivers/net/wireless/rtlwifi/core.h
+++ b/drivers/net/wireless/rtlwifi/core.h
@@ -42,5 +42,6 @@ void rtl_rfreg_delay(struct ieee80211_hw *hw, enum radio_path rfpath, u32 addr,
u32 mask, u32 data);
void rtl_bb_delay(struct ieee80211_hw *hw, u32 addr, u32 data);
bool rtl_cmd_send_packet(struct ieee80211_hw *hw, struct sk_buff *skb);
+bool rtl_btc_status_false(void);
#endif
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c b/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c
index d86b5b5..46ea076 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c
@@ -244,6 +244,7 @@ static struct rtl_hal_ops rtl8192ce_hal_ops = {
.phy_lc_calibrate = _rtl92ce_phy_lc_calibrate,
.phy_set_bw_mode_callback = rtl92ce_phy_set_bw_mode_callback,
.dm_dynamic_txpower = rtl92ce_dm_dynamic_txpower,
+ .get_btc_status = rtl_btc_status_false,
};
static struct rtl_mod_params rtl92ce_mod_params = {
diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/sw.c b/drivers/net/wireless/rtlwifi/rtl8192de/sw.c
index edab5a5..a0aba08 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192de/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192de/sw.c
@@ -251,6 +251,7 @@ static struct rtl_hal_ops rtl8192de_hal_ops = {
.get_rfreg = rtl92d_phy_query_rf_reg,
.set_rfreg = rtl92d_phy_set_rf_reg,
.linked_set_reg = rtl92d_linked_set_reg,
+ .get_btc_status = rtl_btc_status_false,
};
static struct rtl_mod_params rtl92de_mod_params = {
diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/sw.c b/drivers/net/wireless/rtlwifi/rtl8192se/sw.c
index 1bff2a0..5e16984 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192se/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192se/sw.c
@@ -294,6 +294,7 @@ static struct rtl_hal_ops rtl8192se_hal_ops = {
.set_bbreg = rtl92s_phy_set_bb_reg,
.get_rfreg = rtl92s_phy_query_rf_reg,
.set_rfreg = rtl92s_phy_set_rf_reg,
+ .get_btc_status = rtl_btc_status_false,
};
static struct rtl_mod_params rtl92se_mod_params = {
--
2.1.1
>From 4f3d6a80198c539bbf200ff3a6dd00689b50bf78 Mon Sep 17 00:00:00 2001
From: Larry Finger
Date: Sat, 25 Oct 2014 23:51:15 -0500
Subject: [PATCH 5/7] rtlwifi: rtl8192ce: Add missing section to read
descriptor setting
To: linvi...@tuxdriver.com
Cc: net...@vger.kernel.org,
troy_...@realsil.com.cn
The new version of rtlwifi needs code in rtl92ce_get_desc() that returns
the buffer address for read operations.
Signed-off-by: Larry Finger
---
drivers/net/wireless/rtlwifi/rtl8192ce/def.h | 2 ++
drivers/net/wireless/rtlwifi/rtl8192ce/trx.c | 3 +++
2 files changed, 5 insertions(+)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/def.h b/drivers/net/wireless/rtlwifi/rtl8192ce/def.h
index 831df10..9b660df 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/def.h
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/def.h
@@ -114,6 +114,8 @@
LE_BITS_TO_4BYTE(((__pcmdfbhdr) + 4), 16, 4)
#define GET_C2H_CMD_F
Re: brcm80211: use endian annotation for pmk related structure
On 10/31/14 15:26, Dan Carpenter wrote: On Fri, Oct 31, 2014 at 03:18:27PM +0100, Arend van Spriel wrote: Understood. Not sure what the motivation is to mistrust endian more. Endian data tends to come from suspicious places such as disk images, usb devices, and networks. Simply because there could be conversion errors? Anyway, the main question is whether pmkid_len is always between 0 and WLAN_PMKID_LEN. As far as I know it is. We could 1) add additional checks here, 2) make pmkid_len of u32 type, or 3) just mention the (sure) assumption in a comment. I would prefer option 2) or 3). I would prefer 2. Static checker warnings are a pain. Now who has been tinkering on static checkers ;-) Anyway, option 2) it is. Who will do the patch? :-p Regards, Arend -- 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: brcm80211: use endian annotation for pmk related structure
On Fri, Oct 31, 2014 at 03:18:27PM +0100, Arend van Spriel wrote: > Understood. Not sure what the motivation is to mistrust endian more. Endian data tends to come from suspicious places such as disk images, usb devices, and networks. > Simply because there could be conversion errors? Anyway, the main > question is whether pmkid_len is always between 0 and > WLAN_PMKID_LEN. As far as I know it is. We could 1) add additional > checks here, 2) make pmkid_len of u32 type, or 3) just mention the > (sure) assumption in a comment. I would prefer option 2) or 3). I would prefer 2. Static checker warnings are a pain. regards, dan carpenter -- 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: brcm80211: use endian annotation for pmk related structure
On 10/31/14 13:51, Dan Carpenter wrote:
Hello Arend van Spriel,
The patch 40c8e95af02d: "brcm80211: use endian annotation for pmk
related structure" from Oct 12, 2011, leads to the following static
checker warning:
drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c:2965
brcmf_cfg80211_set_pmksa()
warn: can 'pmkid_len' be negative?
drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
2950 brcmf_cfg80211_set_pmksa(struct wiphy *wiphy, struct net_device *ndev,
2951 struct cfg80211_pmksa *pmksa)
2952 {
2953 struct brcmf_cfg80211_info *cfg = wiphy_to_cfg(wiphy);
2954 struct brcmf_if *ifp = netdev_priv(ndev);
2955 struct pmkid_list *pmkids =&cfg->pmk_list->pmkids;
2956 s32 err = 0;
2957 int i;
2958 int pmkid_len;
2959
2960 brcmf_dbg(TRACE, "Enter\n");
2961 if (!check_vif_up(ifp->vif))
2962 return -EIO;
2963
2964 pmkid_len = le32_to_cpu(pmkids->npmkid);
The thinking behind this check is that endian data is less trust worthy
than cpu data. But probably this comes from the hardware so it's fine?
Anyway, let's assume pmkid_len = -1.
2965 for (i = 0; i< pmkid_len; i++)
2966 if (!memcmp(pmksa->bssid, pmkids->pmkid[i].BSSID,
ETH_ALEN))
2967 break;
We don't enter this loop.
2968 if (i< WL_NUM_PMKIDS_MAX) {
Zero is less than WL_NUM_PMKIDS_MAX.
2969 memcpy(pmkids->pmkid[i].BSSID, pmksa->bssid, ETH_ALEN);
2970 memcpy(pmkids->pmkid[i].PMKID, pmksa->pmkid,
WLAN_PMKID_LEN);
2971 if (i == pmkid_len) {
^^
This is false.
2972 pmkid_len++;
2973 pmkids->npmkid = cpu_to_le32(pmkid_len);
2974 }
2975 } else
2976 err = -EINVAL;
2977
2978 brcmf_dbg(CONN, "set_pmksa,IW_PMKSA_ADD - PMKID: %pM =\n",
2979pmkids->pmkid[pmkid_len].BSSID);
^^^
Underflow.
2980 for (i = 0; i< WLAN_PMKID_LEN; i++)
2981 brcmf_dbg(CONN, "%02x\n",
pmkids->pmkid[pmkid_len].PMKID[i]);
Underflow.
2982
2983 err = brcmf_update_pmklist(ndev, cfg->pmk_list, err);
2984
2985 brcmf_dbg(TRACE, "Exit\n");
2986 return err;
2987 }
Hi Dan,
Understood. Not sure what the motivation is to mistrust endian more.
Simply because there could be conversion errors? Anyway, the main
question is whether pmkid_len is always between 0 and WLAN_PMKID_LEN. As
far as I know it is. We could 1) add additional checks here, 2) make
pmkid_len of u32 type, or 3) just mention the (sure) assumption in a
comment. I would prefer option 2) or 3).
Regards,
Arend
--
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: PROBLEM: Boot failure with bad RIP value
On Tue, Oct 14, 2014 at 12:13:13AM -0400, S. Gilles wrote: > On Mon, Oct 13, 2014 at 10:41:26PM -0500, Larry Finger wrote: > > On 10/13/2014 06:45 PM, S. Gilles wrote: > > > (Sending this to the right people this time, hopefully.) > > > > > > I have been getting a consistent boot failure with 3.17, which I have > > > bisected to > > > > > > 38506ecefab911785d5e1aa5889f6eeb462e0954 is the first bad commit > > > commit 38506ecefab911785d5e1aa5889f6eeb462e0954 > > > Author: Larry Finger > > > Date: Mon Sep 22 09:39:19 2014 -0500 > > > > > > rtlwifi: rtl_pci: Start modification for new drivers > > > > > > Future patches will move the drivers for RTL8192EE and RTL8821AE > > > from staging to the regular wireless tree. Here, the necessary > > > features > > > are added to the PCI driver. Other files are touched due to changes > > > in the various data structs. > > > > > > Signed-off-by: Larry Finger > > > Signed-off-by: John W. Linville > > > > > > The end of the trace (hand-retyped, so there may be errors that > > > escaped me): > > > > > > R10: 825f2d80 R11: R12: 8800b4f107c0 > > > R13: 8800b4f124b8 R14: 1000 R15: 8800b4c7a000 > > > FS: 07fc66c938700() GS:88013e20() > > > knlGS: > > > CS: 0010 DS: ES: CR0: 80050033 > > > CR2: CR3: b5438000 CR4: 000407f0 > > > Stack: > > > a01e20d6 8800b4f12420 8800b4f107c0 880137d7fcd0 > > > a01c97b5 8800b4f107c0 8800b4c7a8d0 > > > 880137d7fd30 81577304 8800b4c7a8c0 > > > Call Trace: > > > [] ? rtl_pci_start+0x2b/0x15f [rtl_pci] > > > [] rtl_op_start+0x45/0x64 [rtlwifi] > > > [] ieee80211_do_open+0x152/0xb4b > > > [] ? mutex_unlock+0x9/0xb > > > [] ieee80211_open+0x4d/0x57 > > > [] __dev_open+0x8b/0xcb > > > [] __dev_change_flags+0xa4/0x13a > > > [] dev_change_flags+0x20/0x53 > > > [] devinet_ioctl+0x269/0x568 > > > [] inet_ioctl+0x81/0x9e > > > [] sock_do_ioctl+0x20/0x3d > > > [] sock_ioctl+0x20e/0x21a > > > [] do_vfs_ioctl+0x39e/0x467 > > > [] ? sysret_check+0x1b/0x56 > > > [] ? trace_hardirqs_on_caller+0x16e/0x18a > > > [] SyS_ioctl+0x38/0x5f > > > [] system_call_fastpath+0x16/0x1b > > > Code: Bad RIP value. > > > RIP [< (null)>] (null) > > > RSP > > > CR2: > > > ---[ end trace 7307d2524c1e640b ]--- > > > > > > This is extremely easy to test (boot) and seems 100% reproducible. > > > > > > I have submitted Bug 86211 - Boot failure: Bad RIP value for rtl8192ce > > > for this issue. > > > > I am traveling and it may be a few days before I am able to make a suitable > > test. In the meantime, please post the appropriate stanza for the Realtek > > device > > from the output of > > > > lspci -nn > > > > There are several different devices that use driver rtl8192ce, and I need > > to > > know which one you have so that I can duplicate the problem. > > Of course - I definitely should have mentioned that. > > $ lspci -nn | grep RTL > 03:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8188CE > 802.11b/g/n WiFi Adapter [10ec:8176] (rev 01) Any progress on this, or duplication? If this isn't replicable with the information in Bugzilla, I can provide anything requested. -- S. Gilles -- 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] mac80211: 802.11p OCB mode support
On Thu, 2014-10-30 at 11:42 +0100, Rostislav Lisovy wrote:
> +int ieee80211_ocb_join(struct ieee80211_sub_if_data *sdata,
> +struct ocb_setup *setup)
> +{
> + struct ieee80211_local *local = sdata->local;
> + struct ieee80211_if_ocb *ifocb = &sdata->u.ocb;
> + u32 changed = BSS_CHANGED_OCB;
> + int err;
> +
> + if (ifocb->joined == true)
> + return -EINVAL;
You could, potentially, use the fact that you have a channel context
assigned instead. However, locking might make that awkward, and this is
perfectly fine as well of course. It's probably not worth changing it.
Looks good to me.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] cfg80211: 802.11p OCB mode handling
On Thu, 2014-10-30 at 11:42 +0100, Rostislav Lisovy wrote:
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -263,6 +263,7 @@ struct ieee80211_vif_chanctx_switch {
> * @BSS_CHANGED_BANDWIDTH: The bandwidth used by this interface changed,
> * note that this is only called when it changes after the channel
> * context had been assigned.
> + * @BSS_CHANGED_OCB: OCB join status changed
> */
> enum ieee80211_bss_change {
> BSS_CHANGED_ASSOC = 1<<0,
> @@ -287,6 +288,7 @@ enum ieee80211_bss_change {
> BSS_CHANGED_P2P_PS = 1<<19,
> BSS_CHANGED_BEACON_INFO = 1<<20,
> BSS_CHANGED_BANDWIDTH = 1<<21,
> + BSS_CHANGED_OCB = 1<<22,
This should be in the mac80211 patch.
> + NL80211_CMD_JOIN_OCB,
> + NL80211_CMD_LEAVE_OCB,
> /* add new commands above here */
please leave a blank line before the comment
> @@ -2093,6 +2102,7 @@ enum nl80211_iftype {
> NL80211_IFTYPE_P2P_CLIENT,
> NL80211_IFTYPE_P2P_GO,
> NL80211_IFTYPE_P2P_DEVICE,
> + NL80211_IFTYPE_OCB,
This is causing a bunch of compiler warnings (warning: enumeration value
‘NL80211_IFTYPE_OCB’ not handled in switch, e.g. in mac80211/iface.c)
which I think you should address in this patch. That'll mean that you
modify even mac80211 and potentially some drivers, but I think that's
the right thing to do in this patch since it's the one changing the API
to introduce the new value.
The later patch can then add functionality to those new case labels in
mac80211 (this one of course adds it in cfg80211). For this patch they
should be with the error case that will typically exist.
> +static int nl80211_join_ocb(struct sk_buff *skb, struct genl_info *info)
> +{
> + struct cfg80211_registered_device *rdev = info->user_ptr[0];
> + struct net_device *dev = info->user_ptr[1];
> + struct ocb_setup setup = {};
> + int err;
> +
> + if (!info->attrs[NL80211_ATTR_WIPHY_FREQ])
> + return -EINVAL;
This check isn't necessary,
> + err = nl80211_parse_chandef(rdev, info, &setup.chandef);
> + if (err)
> + return err;
it's also done in this function.
I think there's one thing you forgot in this patch, namely
__cfg80211_leave() which you also need to make the __ version of the
leave function non-static for due to locking.
I noticed that the switch statement there has a default case - I'll
remove that, so be sure to rebase on mac80211-next.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/2] Add mcast event when hwsim radios are created and removed
On Fri, 2014-10-31 at 14:48 +0200, Jukka Rissanen wrote: > Hi, > > v3: > - rebased on top of the latest changes in upstream Both applied, thanks. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
re: brcm80211: use endian annotation for pmk related structure
Hello Arend van Spriel,
The patch 40c8e95af02d: "brcm80211: use endian annotation for pmk
related structure" from Oct 12, 2011, leads to the following static
checker warning:
drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c:2965
brcmf_cfg80211_set_pmksa()
warn: can 'pmkid_len' be negative?
drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
2950 brcmf_cfg80211_set_pmksa(struct wiphy *wiphy, struct net_device *ndev,
2951 struct cfg80211_pmksa *pmksa)
2952 {
2953 struct brcmf_cfg80211_info *cfg = wiphy_to_cfg(wiphy);
2954 struct brcmf_if *ifp = netdev_priv(ndev);
2955 struct pmkid_list *pmkids = &cfg->pmk_list->pmkids;
2956 s32 err = 0;
2957 int i;
2958 int pmkid_len;
2959
2960 brcmf_dbg(TRACE, "Enter\n");
2961 if (!check_vif_up(ifp->vif))
2962 return -EIO;
2963
2964 pmkid_len = le32_to_cpu(pmkids->npmkid);
The thinking behind this check is that endian data is less trust worthy
than cpu data. But probably this comes from the hardware so it's fine?
Anyway, let's assume pmkid_len = -1.
2965 for (i = 0; i < pmkid_len; i++)
2966 if (!memcmp(pmksa->bssid, pmkids->pmkid[i].BSSID,
ETH_ALEN))
2967 break;
We don't enter this loop.
2968 if (i < WL_NUM_PMKIDS_MAX) {
Zero is less than WL_NUM_PMKIDS_MAX.
2969 memcpy(pmkids->pmkid[i].BSSID, pmksa->bssid, ETH_ALEN);
2970 memcpy(pmkids->pmkid[i].PMKID, pmksa->pmkid,
WLAN_PMKID_LEN);
2971 if (i == pmkid_len) {
^^
This is false.
2972 pmkid_len++;
2973 pmkids->npmkid = cpu_to_le32(pmkid_len);
2974 }
2975 } else
2976 err = -EINVAL;
2977
2978 brcmf_dbg(CONN, "set_pmksa,IW_PMKSA_ADD - PMKID: %pM =\n",
2979pmkids->pmkid[pmkid_len].BSSID);
^^^
Underflow.
2980 for (i = 0; i < WLAN_PMKID_LEN; i++)
2981 brcmf_dbg(CONN, "%02x\n",
pmkids->pmkid[pmkid_len].PMKID[i]);
Underflow.
2982
2983 err = brcmf_update_pmklist(ndev, cfg->pmk_list, err);
2984
2985 brcmf_dbg(TRACE, "Exit\n");
2986 return err;
2987 }
regards,
dan carpenter
--
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 0/2] Add mcast event when hwsim radios are created and removed
Hi, v3: - rebased on top of the latest changes in upstream v2: - removed old patch 1 as that is already applied - added suitable prefixes to new function names - refactored the patch 1 so that multicast message building is separated into a more generic function - instead of passing radio parameters (6 pcs) into different functions separately, a struct is used instead v1: patch 1 renames HWSIM_CMD_CREATE_RADIO to HWSIM_CMD_NEW_RADIO and HWSIM_CMD_DESTROY_RADIO to HWSIM_CMD_DEL_RADIO. They are more fitting on how other pieces of the wireless system work. A define to old name is provided for backward compatibility. Patches 2 and 3 use the newly named enums and provide a way to inform the listeners on the multicast group "config" when new radio is created and existing radio is deleted. Jukka Rissanen (2): mac80211-hwsim: Provide multicast event for HWSIM_CMD_NEW_RADIO mac80211-hwsim: Provide multicast event for HWSIM_CMD_DEL_RADIO drivers/net/wireless/mac80211_hwsim.c | 329 +- 1 file changed, 245 insertions(+), 84 deletions(-) -- 1.8.3.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
[PATCH v3 2/2] mac80211-hwsim: Provide multicast event for HWSIM_CMD_DEL_RADIO
When deleting old radio via HWSIM_CMD_DEL_RADIO then listeners on the
multicast group "config" are informed.
Signed-off-by: Jukka Rissanen
---
drivers/net/wireless/mac80211_hwsim.c | 54 ++-
1 file changed, 47 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c
b/drivers/net/wireless/mac80211_hwsim.c
index 476c89c..209db62 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -2404,8 +2404,48 @@ failed:
return err;
}
-static void mac80211_hwsim_destroy_radio(struct mac80211_hwsim_data *data)
+static void hwsim_mcast_del_radio(int id, const char *hwname,
+ struct genl_info *info)
{
+ struct sk_buff *skb;
+ void *data;
+ int ret;
+
+ skb = genlmsg_new(GENLMSG_DEFAULT_SIZE, GFP_KERNEL);
+ if (!skb)
+ return;
+
+ data = genlmsg_put(skb, 0, 0, &hwsim_genl_family, 0,
+ HWSIM_CMD_DEL_RADIO);
+ if (!data)
+ goto error;
+
+ ret = nla_put_u32(skb, HWSIM_ATTR_RADIO_ID, id);
+ if (ret < 0)
+ goto error;
+
+ if (hwname) {
+ ret = nla_put(skb, HWSIM_ATTR_RADIO_NAME, strlen(hwname),
+ hwname);
+ if (ret < 0)
+ goto error;
+ }
+
+ genlmsg_end(skb, data);
+
+ hwsim_mcast_config_msg(skb, info);
+
+ return;
+
+error:
+ nlmsg_free(skb);
+}
+
+static void mac80211_hwsim_del_radio(struct mac80211_hwsim_data *data,
+const char *hwname,
+struct genl_info *info)
+{
+ hwsim_mcast_del_radio(data->idx, hwname, info);
debugfs_remove_recursive(data->debugfs);
ieee80211_unregister_hw(data->hw);
device_release_driver(data->dev);
@@ -2423,7 +2463,7 @@ static void mac80211_hwsim_free(void)
list))) {
list_del(&data->list);
spin_unlock_bh(&hwsim_radio_lock);
- mac80211_hwsim_destroy_radio(data);
+ mac80211_hwsim_del_radio(data, NULL, NULL);
spin_lock_bh(&hwsim_radio_lock);
}
spin_unlock_bh(&hwsim_radio_lock);
@@ -2683,7 +2723,7 @@ static int hwsim_new_radio_nl(struct sk_buff *msg, struct
genl_info *info)
return mac80211_hwsim_new_radio(info, ¶m);
}
-static int hwsim_destroy_radio_nl(struct sk_buff *msg, struct genl_info *info)
+static int hwsim_del_radio_nl(struct sk_buff *msg, struct genl_info *info)
{
struct mac80211_hwsim_data *data;
s64 idx = -1;
@@ -2709,7 +2749,7 @@ static int hwsim_destroy_radio_nl(struct sk_buff *msg,
struct genl_info *info)
list_del(&data->list);
spin_unlock_bh(&hwsim_radio_lock);
- mac80211_hwsim_destroy_radio(data);
+ mac80211_hwsim_del_radio(data, hwname, info);
return 0;
}
spin_unlock_bh(&hwsim_radio_lock);
@@ -2742,9 +2782,9 @@ static const struct genl_ops hwsim_ops[] = {
.flags = GENL_ADMIN_PERM,
},
{
- .cmd = HWSIM_CMD_DESTROY_RADIO,
+ .cmd = HWSIM_CMD_DEL_RADIO,
.policy = hwsim_genl_policy,
- .doit = hwsim_destroy_radio_nl,
+ .doit = hwsim_del_radio_nl,
.flags = GENL_ADMIN_PERM,
},
};
@@ -2754,7 +2794,7 @@ static void destroy_radio(struct work_struct *work)
struct mac80211_hwsim_data *data =
container_of(work, struct mac80211_hwsim_data, destroy_work);
- mac80211_hwsim_destroy_radio(data);
+ mac80211_hwsim_del_radio(data, NULL, NULL);
}
static void remove_user_radios(u32 portid)
--
1.8.3.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
[PATCH v3 1/2] mac80211-hwsim: Provide multicast event for HWSIM_CMD_NEW_RADIO
When adding new radio via HWSIM_CMD_NEW_RADIO then listeners on the
multicast group "config" are informed.
Signed-off-by: Jukka Rissanen
---
drivers/net/wireless/mac80211_hwsim.c | 275 --
1 file changed, 198 insertions(+), 77 deletions(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c
b/drivers/net/wireless/mac80211_hwsim.c
index 5dbaee3..476c89c 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -487,6 +487,14 @@ static struct genl_family hwsim_genl_family = {
.maxattr = HWSIM_ATTR_MAX,
};
+enum hwsim_multicast_groups {
+ HWSIM_MCGRP_CONFIG,
+};
+
+static const struct genl_multicast_group hwsim_mcgrps[] = {
+ [HWSIM_MCGRP_CONFIG] = { .name = "config", },
+};
+
/* MAC80211_HWSIM netlink policy */
static const struct nla_policy hwsim_genl_policy[HWSIM_ATTR_MAX + 1] = {
@@ -2025,12 +2033,124 @@ static const struct ieee80211_ops mac80211_hwsim_ops =
{
static struct ieee80211_ops mac80211_hwsim_mchan_ops;
-static int mac80211_hwsim_create_radio(int channels, const char *reg_alpha2,
- const struct ieee80211_regdomain *regd,
- bool reg_strict, bool p2p_device,
- bool use_chanctx, bool destroy_on_close,
- u32 portid, const char *hwname,
- bool no_vif)
+struct hwsim_new_radio_params {
+ unsigned int channels;
+ const char *reg_alpha2;
+ const struct ieee80211_regdomain *regd;
+ bool reg_strict;
+ bool p2p_device;
+ bool use_chanctx;
+ bool destroy_on_close;
+ const char *hwname;
+ bool no_vif;
+};
+
+static void hwsim_mcast_config_msg(struct sk_buff *mcast_skb,
+ struct genl_info *info)
+{
+ if (info)
+ genl_notify(&hwsim_genl_family, mcast_skb,
+ genl_info_net(info), info->snd_portid,
+ HWSIM_MCGRP_CONFIG, info->nlhdr, GFP_KERNEL);
+ else
+ genlmsg_multicast(&hwsim_genl_family, mcast_skb, 0,
+ HWSIM_MCGRP_CONFIG, GFP_KERNEL);
+}
+
+static struct sk_buff *build_radio_msg(int cmd, int id,
+ struct hwsim_new_radio_params *param)
+{
+ struct sk_buff *skb;
+ void *data;
+ int ret;
+
+ skb = genlmsg_new(GENLMSG_DEFAULT_SIZE, GFP_KERNEL);
+ if (!skb)
+ return NULL;
+
+ data = genlmsg_put(skb, 0, 0, &hwsim_genl_family, 0, cmd);
+ if (!data)
+ goto error;
+
+ ret = nla_put_u32(skb, HWSIM_ATTR_RADIO_ID, id);
+ if (ret < 0)
+ goto error;
+
+ if (param->channels) {
+ ret = nla_put_u32(skb, HWSIM_ATTR_CHANNELS, param->channels);
+ if (ret < 0)
+ goto error;
+ }
+
+ if (param->reg_alpha2) {
+ ret = nla_put(skb, HWSIM_ATTR_REG_HINT_ALPHA2, 2,
+ param->reg_alpha2);
+ if (ret < 0)
+ goto error;
+ }
+
+ if (param->regd) {
+ int i;
+
+ for (i = 0; hwsim_world_regdom_custom[i] != param->regd &&
+i < ARRAY_SIZE(hwsim_world_regdom_custom); i++)
+ ;
+
+ if (i < ARRAY_SIZE(hwsim_world_regdom_custom)) {
+ ret = nla_put_u32(skb, HWSIM_ATTR_REG_CUSTOM_REG, i);
+ if (ret < 0)
+ goto error;
+ }
+ }
+
+ if (param->reg_strict) {
+ ret = nla_put_flag(skb, HWSIM_ATTR_REG_STRICT_REG);
+ if (ret < 0)
+ goto error;
+ }
+
+ if (param->p2p_device) {
+ ret = nla_put_flag(skb, HWSIM_ATTR_SUPPORT_P2P_DEVICE);
+ if (ret < 0)
+ goto error;
+ }
+
+ if (param->use_chanctx) {
+ ret = nla_put_flag(skb, HWSIM_ATTR_USE_CHANCTX);
+ if (ret < 0)
+ goto error;
+ }
+
+ if (param->hwname) {
+ ret = nla_put(skb, HWSIM_ATTR_RADIO_NAME,
+ strlen(param->hwname), param->hwname);
+ if (ret < 0)
+ goto error;
+ }
+
+ genlmsg_end(skb, data);
+
+ return skb;
+
+error:
+ nlmsg_free(skb);
+ return NULL;
+}
+
+static void hswim_mcast_new_radio(int id, struct genl_info *info,
+ struct hwsim_new_radio_params *param)
+{
+ struct sk_buff *mcast_skb;
+
+ mcast_skb = build_radio_msg(HWSIM_CMD_NEW_RADIO, id, param);
+ if (!mcast_skb)
+ return;
+
+ hwsim_mcast_config_msg(mcast_skb, info);
+}
+
+static int mac80211_hwsim_new_radio(struct genl_info *info,
+
Re: [PATCH -stable] wireless: rt2x00: add new rt2800usb devices
On Fri, Oct 31, 2014 at 10:47:38AM +0100, Jiri Slaby wrote: > On 10/30/2014, 12:18 PM, Xose Vazquez Perez wrote: > > 0x0b05 0x17e8 RT5372 USB 2.0 bgn 2x2 ASUS USB-N14 > > 0x0411 0x0253 RT5572 USB 2.0 abgn 2x2 BUFFALO WLP-U2-300D > > 0x0df6 0x0078 RT Sitecom N300 > > (the same as previous) This is: committ 6a06e554daef86c4e8d290284927b081fedb249e Author: Xose Vazquez Perez Date: Fri Jul 11 21:46:57 2014 +0200 wireless: rt2x00: add new rt2800usb devices -- 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 -stable] rt2x00: support Ralink 5362.
On Fri, Oct 31, 2014 at 10:47:12AM +0100, Jiri Slaby wrote: > On 10/30/2014, 12:18 PM, Xose Vazquez Perez wrote: > > From: Canek Peláez Valdés > > Hi, what is this, please? No commit message, no upstream SHA, we cannot > take the two as they stand... This is: commit ac0372abf8524a7572a9cdaac6495eb2eba20457 Author: Canek Peláez Valdés Date: Sun Aug 24 19:06:11 2014 -0500 rt2x00: support Ralink 5362. -- 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 -stable] rt2x00: support Ralink 5362.
On 10/30/2014, 12:18 PM, Xose Vazquez Perez wrote:
> From: Canek Peláez Valdés
Hi, what is this, please? No commit message, no upstream SHA, we cannot
take the two as they stand...
> Cc: sta...@vger.kernel.org
> Acked-by: Stanislaw Gruszka
> Cc: Stanislaw Gruszka
> Cc: Helmut Schaa
> Cc: John W. Linville
> Cc: us...@rt2x00.serialmonkey.com
> Cc: linux-wireless@vger.kernel.org
> Signed-off-by: Canek Peláez Valdés
> Signed-off-by: John W. Linville
> ---
> drivers/net/wireless/rt2x00/rt2800.h| 4 +++-
> drivers/net/wireless/rt2x00/rt2800lib.c | 6 ++
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800.h
> b/drivers/net/wireless/rt2x00/rt2800.h
> index a394a9a..b7434df 100644
> --- a/drivers/net/wireless/rt2x00/rt2800.h
> +++ b/drivers/net/wireless/rt2x00/rt2800.h
> @@ -52,6 +52,7 @@
> * RF5592 2.4G/5G 2T2R
> * RF3070 2.4G 1T1R
> * RF5360 2.4G 1T1R
> + * RF5362 2.4G 1T1R
> * RF5370 2.4G 1T1R
> * RF5390 2.4G 1T1R
> */
> @@ -72,6 +73,7 @@
> #define RF3070 0x3070
> #define RF3290 0x3290
> #define RF5360 0x5360
> +#define RF5362 0x5362
> #define RF5370 0x5370
> #define RF5372 0x5372
> #define RF5390 0x5390
> @@ -2145,7 +2147,7 @@ struct mac_iveiv_entry {
> /* Bits [7-4] for RF3320 (RT3370/RT3390), on other chipsets reserved */
> #define RFCSR3_PA1_BIAS_CCK FIELD8(0x70)
> #define RFCSR3_PA2_CASCODE_BIAS_CCKK FIELD8(0x80)
> -/* Bits for RF3290/RF5360/RF5370/RF5372/RF5390/RF5392 */
> +/* Bits for RF3290/RF5360/RF5362/RF5370/RF5372/RF5390/RF5392 */
> #define RFCSR3_VCOCAL_EN FIELD8(0x80)
> /* Bits for RF3050 */
> #define RFCSR3_BIT1 FIELD8(0x02)
> diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c
> b/drivers/net/wireless/rt2x00/rt2800lib.c
> index 893c9d5..9f57a2d 100644
> --- a/drivers/net/wireless/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
> @@ -3186,6 +3186,7 @@ static void rt2800_config_channel(struct rt2x00_dev
> *rt2x00dev,
> break;
> case RF3070:
> case RF5360:
> + case RF5362:
> case RF5370:
> case RF5372:
> case RF5390:
> @@ -3203,6 +3204,7 @@ static void rt2800_config_channel(struct rt2x00_dev
> *rt2x00dev,
> rt2x00_rf(rt2x00dev, RF3290) ||
> rt2x00_rf(rt2x00dev, RF3322) ||
> rt2x00_rf(rt2x00dev, RF5360) ||
> + rt2x00_rf(rt2x00dev, RF5362) ||
> rt2x00_rf(rt2x00dev, RF5370) ||
> rt2x00_rf(rt2x00dev, RF5372) ||
> rt2x00_rf(rt2x00dev, RF5390) ||
> @@ -4317,6 +4319,7 @@ void rt2800_vco_calibration(struct rt2x00_dev
> *rt2x00dev)
> case RF3070:
> case RF3290:
> case RF5360:
> + case RF5362:
> case RF5370:
> case RF5372:
> case RF5390:
> @@ -7095,6 +7098,7 @@ static int rt2800_init_eeprom(struct rt2x00_dev
> *rt2x00dev)
> case RF3320:
> case RF3322:
> case RF5360:
> + case RF5362:
> case RF5370:
> case RF5372:
> case RF5390:
> @@ -7551,6 +7555,7 @@ static int rt2800_probe_hw_mode(struct rt2x00_dev
> *rt2x00dev)
> case RF3320:
> case RF3322:
> case RF5360:
> + case RF5362:
> case RF5370:
> case RF5372:
> case RF5390:
> @@ -7680,6 +7685,7 @@ static int rt2800_probe_hw_mode(struct rt2x00_dev
> *rt2x00dev)
> case RF3070:
> case RF3290:
> case RF5360:
> + case RF5362:
> case RF5370:
> case RF5372:
> case RF5390:
>
--
js
suse labs
--
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 -stable] wireless: rt2x00: add new rt2800usb devices
On 10/30/2014, 12:18 PM, Xose Vazquez Perez wrote:
> 0x0b05 0x17e8 RT5372 USB 2.0 bgn 2x2 ASUS USB-N14
> 0x0411 0x0253 RT5572 USB 2.0 abgn 2x2 BUFFALO WLP-U2-300D
> 0x0df6 0x0078 RT Sitecom N300
(the same as previous)
> Cc: sta...@vger.kernel.org
> Acked-by: Stanislaw Gruszka
> Cc: Stanislaw Gruszka
> Cc: Helmut Schaa
> Cc: John W. Linville
> Cc: us...@rt2x00.serialmonkey.com
> Cc: linux-wireless@vger.kernel.org
> Signed-off-by: Xose Vazquez Perez
> Signed-off-by: John W. Linville
> ---
> drivers/net/wireless/rt2x00/rt2800usb.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c
> b/drivers/net/wireless/rt2x00/rt2800usb.c
> index 832006b..573897b 100644
> --- a/drivers/net/wireless/rt2x00/rt2800usb.c
> +++ b/drivers/net/wireless/rt2x00/rt2800usb.c
> @@ -1284,6 +1284,8 @@ static struct usb_device_id rt2800usb_device_table[] = {
> /* Arcadyan */
> { USB_DEVICE(0x043e, 0x7a12) },
> { USB_DEVICE(0x043e, 0x7a32) },
> + /* ASUS */
> + { USB_DEVICE(0x0b05, 0x17e8) },
> /* Azurewave */
> { USB_DEVICE(0x13d3, 0x3329) },
> { USB_DEVICE(0x13d3, 0x3365) },
> @@ -1320,6 +1322,7 @@ static struct usb_device_id rt2800usb_device_table[] = {
> { USB_DEVICE(0x057c, 0x8501) },
> /* Buffalo */
> { USB_DEVICE(0x0411, 0x0241) },
> + { USB_DEVICE(0x0411, 0x0253) },
> /* D-Link */
> { USB_DEVICE(0x2001, 0x3c1a) },
> { USB_DEVICE(0x2001, 0x3c21) },
> @@ -1410,6 +1413,7 @@ static struct usb_device_id rt2800usb_device_table[] = {
> { USB_DEVICE(0x0df6, 0x0053) },
> { USB_DEVICE(0x0df6, 0x0069) },
> { USB_DEVICE(0x0df6, 0x006f) },
> + { USB_DEVICE(0x0df6, 0x0078) },
> /* SMC */
> { USB_DEVICE(0x083a, 0xa512) },
> { USB_DEVICE(0x083a, 0xc522) },
>
--
js
suse labs
--
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: iwlwifi: mvm: BACKPORT_WANT_DEV_COREDUMP?
On Fri, 2014-10-31 at 10:08 +0100, Johannes Berg wrote: > On Fri, 2014-10-31 at 10:06 +0100, Paul Bolle wrote: > > Perhaps you could also look into somehow guarding the call of > > dev_coredumpm(), that this commit added, with checks for > > CONFIG_DEV_COREDUMP. See, I had a quick look at all this and selecting > > WANT_DEV_COREDUMP might not be enough, because DISABLE_DEV_COREDUMP can > > still, well, disable DEV_COREDUMP. Or am I misreading the Kconfig > > symbols that regulate DEV_COREDUMP? > > No, you're correctly reading that. However, the devcoredump header file > provides simple functions in this case. That means there's some extra > work (allocating and filling the buffer just to free it immediately) but > it simplifies the code. I see. More than a quick look was required here. Thanks for explaining this! Paul Bolle -- 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: iwlwifi: mvm: BACKPORT_WANT_DEV_COREDUMP?
On Fri, 2014-10-31 at 10:06 +0100, Paul Bolle wrote:
> On Fri, 2014-10-31 at 09:45 +0100, Johannes Berg wrote:
> > On Fri, 2014-10-31 at 09:40 +0100, Paul Bolle wrote:
> > > Your commit aadede6e9f4c ("iwlwifi: mvm: port to devcoredump framework")
> > > landed in today's linux-next (next-20141031). It adds a select statement
> > > for BACKPORT_WANT_DEV_COREDUMP. There's no Kconfig symbol
> > > BACKPORT_WANT_DEV_COREDUMP so this select is currently a nop. (In
> > > https://lkml.org/lkml/2014/9/30/578 I proposed a patch that emits a
> > > warning in cases like this.)
> > >
> > > Did you perhaps meant to select WANT_DEV_COREDUMP?
> >
> > Yes. We'll fix it up in the iwlwifi tree.
> >
> > Thanks for the report!
>
> Perhaps you could also look into somehow guarding the call of
> dev_coredumpm(), that this commit added, with checks for
> CONFIG_DEV_COREDUMP. See, I had a quick look at all this and selecting
> WANT_DEV_COREDUMP might not be enough, because DISABLE_DEV_COREDUMP can
> still, well, disable DEV_COREDUMP. Or am I misreading the Kconfig
> symbols that regulate DEV_COREDUMP?
No, you're correctly reading that. However, the devcoredump header file
provides simple functions in this case. That means there's some extra
work (allocating and filling the buffer just to free it immediately) but
it simplifies the code.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: iwlwifi: mvm: BACKPORT_WANT_DEV_COREDUMP?
On Fri, 2014-10-31 at 09:45 +0100, Johannes Berg wrote:
> On Fri, 2014-10-31 at 09:40 +0100, Paul Bolle wrote:
> > Your commit aadede6e9f4c ("iwlwifi: mvm: port to devcoredump framework")
> > landed in today's linux-next (next-20141031). It adds a select statement
> > for BACKPORT_WANT_DEV_COREDUMP. There's no Kconfig symbol
> > BACKPORT_WANT_DEV_COREDUMP so this select is currently a nop. (In
> > https://lkml.org/lkml/2014/9/30/578 I proposed a patch that emits a
> > warning in cases like this.)
> >
> > Did you perhaps meant to select WANT_DEV_COREDUMP?
>
> Yes. We'll fix it up in the iwlwifi tree.
>
> Thanks for the report!
Perhaps you could also look into somehow guarding the call of
dev_coredumpm(), that this commit added, with checks for
CONFIG_DEV_COREDUMP. See, I had a quick look at all this and selecting
WANT_DEV_COREDUMP might not be enough, because DISABLE_DEV_COREDUMP can
still, well, disable DEV_COREDUMP. Or am I misreading the Kconfig
symbols that regulate DEV_COREDUMP?
Thanks,
Paul Bolle
--
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: iwlwifi: mvm: BACKPORT_WANT_DEV_COREDUMP?
On Fri, 2014-10-31 at 09:40 +0100, Paul Bolle wrote:
> Your commit aadede6e9f4c ("iwlwifi: mvm: port to devcoredump framework")
> landed in today's linux-next (next-20141031). It adds a select statement
> for BACKPORT_WANT_DEV_COREDUMP. There's no Kconfig symbol
> BACKPORT_WANT_DEV_COREDUMP so this select is currently a nop. (In
> https://lkml.org/lkml/2014/9/30/578 I proposed a patch that emits a
> warning in cases like this.)
>
> Did you perhaps meant to select WANT_DEV_COREDUMP?
Yes. We'll fix it up in the iwlwifi tree.
Thanks for the report!
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
iwlwifi: mvm: BACKPORT_WANT_DEV_COREDUMP?
Your commit aadede6e9f4c ("iwlwifi: mvm: port to devcoredump framework")
landed in today's linux-next (next-20141031). It adds a select statement
for BACKPORT_WANT_DEV_COREDUMP. There's no Kconfig symbol
BACKPORT_WANT_DEV_COREDUMP so this select is currently a nop. (In
https://lkml.org/lkml/2014/9/30/578 I proposed a patch that emits a
warning in cases like this.)
Did you perhaps meant to select WANT_DEV_COREDUMP? Or is the Kconfig
symbol BACKPORT_WANT_DEV_COREDUMP queued somewhere?
Paul Bolle
--
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] mac80211-hwsim: add frequency attribute to netlink pkts
On Fri, 2014-10-31 at 10:16 +0200, Jukka Rissanen wrote: > Hi Johannes, > > On pe, 2014-10-31 at 09:04 +0100, Johannes Berg wrote: > > On Fri, 2014-10-31 at 10:02 +0200, Jukka Rissanen wrote: > > > > > while rebasing my hwsim patches on top of Ben's patches, I noticed that > > > the freq attribute is not mentioned in hwsim_genl_policy struct. The > > > same applies also to radio name and vif attributes. Just wondered should > > > they be mentioned in the policy struct like the other attributes? > > > > Hmm, yes, they should be there. It's only important for the name, I > > guess, but better have them all. I can fix it or would you like to send > > a patch? > > Please fix it so it gets applied faster :) Done. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211-hwsim: add frequency attribute to netlink pkts
Hi Johannes, On pe, 2014-10-31 at 09:04 +0100, Johannes Berg wrote: > On Fri, 2014-10-31 at 10:02 +0200, Jukka Rissanen wrote: > > > while rebasing my hwsim patches on top of Ben's patches, I noticed that > > the freq attribute is not mentioned in hwsim_genl_policy struct. The > > same applies also to radio name and vif attributes. Just wondered should > > they be mentioned in the policy struct like the other attributes? > > Hmm, yes, they should be there. It's only important for the name, I > guess, but better have them all. I can fix it or would you like to send > a patch? Please fix it so it gets applied faster :) Cheers, Jukka -- 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] mac80211-hwsim: add frequency attribute to netlink pkts
On Fri, 2014-10-31 at 10:02 +0200, Jukka Rissanen wrote: > while rebasing my hwsim patches on top of Ben's patches, I noticed that > the freq attribute is not mentioned in hwsim_genl_policy struct. The > same applies also to radio name and vif attributes. Just wondered should > they be mentioned in the policy struct like the other attributes? Hmm, yes, they should be there. It's only important for the name, I guess, but better have them all. I can fix it or would you like to send a patch? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] ath10k: fix pm resume after suspend
Firmware was crashing when we were trying to warm reset it
after suspend. This was due to the fact that target registeres
can be accessed only if the hardware is awaken.
This patch makes sure to awake the device also on the hif up,
not only in case of probe call.
Signed-off-by: Bartosz Markowski
---
drivers/net/wireless/ath/ath10k/pci.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c
b/drivers/net/wireless/ath/ath10k/pci.c
index f5e426e..3a6b8a5 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1875,6 +1875,12 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot hif power up\n");
+ ret = ath10k_pci_wake(ar);
+ if (ret) {
+ ath10k_err(ar, "failed to wake up target: %d\n", ret);
+ return ret;
+ }
+
/*
* Bring the target up cleanly.
*
@@ -1888,13 +1894,13 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
ret = ath10k_pci_chip_reset(ar);
if (ret) {
ath10k_err(ar, "failed to reset chip: %d\n", ret);
- goto err;
+ goto err_sleep;
}
ret = ath10k_pci_init_pipes(ar);
if (ret) {
ath10k_err(ar, "failed to initialize CE: %d\n", ret);
- goto err;
+ goto err_sleep;
}
ret = ath10k_pci_init_config(ar);
@@ -1914,7 +1920,8 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
err_ce:
ath10k_pci_ce_deinit(ar);
-err:
+err_sleep:
+ ath10k_pci_sleep(ar);
return ret;
}
@@ -1925,6 +1932,8 @@ static void ath10k_pci_hif_power_down(struct ath10k *ar)
/* Currently hif_power_up performs effectively a reset and hif_stop
* resets the chip as well so there's no point in resetting here.
*/
+
+ ath10k_pci_sleep(ar);
}
#ifdef CONFIG_PM
@@ -2526,6 +2535,8 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
goto err_deinit_irq;
}
+ ath10k_pci_sleep(ar);
+
ret = ath10k_core_register(ar, chip_id);
if (ret) {
ath10k_err(ar, "failed to register driver core: %d\n", ret);
@@ -2577,7 +2588,6 @@ static void ath10k_pci_remove(struct pci_dev *pdev)
ath10k_pci_deinit_irq(ar);
ath10k_pci_ce_deinit(ar);
ath10k_pci_free_pipes(ar);
- ath10k_pci_sleep(ar);
ath10k_pci_release(ar);
ath10k_core_destroy(ar);
}
--
1.8.2
--
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] mac80211-hwsim: add frequency attribute to netlink pkts
Hi Ben & Johannes,
while rebasing my hwsim patches on top of Ben's patches, I noticed that
the freq attribute is not mentioned in hwsim_genl_policy struct. The
same applies also to radio name and vif attributes. Just wondered should
they be mentioned in the policy struct like the other attributes?
On ma, 2014-10-27 at 15:04 -0700, gree...@candelatech.com wrote:
> From: Ben Greear
>
> Add frequency attribute when sending to user-space over
> netlink socket. The frequency is currently ignored when
> receiving from user-space.
>
> Signed-off-by: Ben Greear
> ---
> drivers/net/wireless/mac80211_hwsim.c | 7 +++
> drivers/net/wireless/mac80211_hwsim.h | 4 +++-
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/mac80211_hwsim.c
> b/drivers/net/wireless/mac80211_hwsim.c
> index 270f8cd..b40435c 100644
> --- a/drivers/net/wireless/mac80211_hwsim.c
> +++ b/drivers/net/wireless/mac80211_hwsim.c
> @@ -906,6 +906,9 @@ static void mac80211_hwsim_tx_frame_nl(struct
> ieee80211_hw *hw,
> if (nla_put_u32(skb, HWSIM_ATTR_FLAGS, hwsim_flags))
> goto nla_put_failure;
>
> + if (nla_put_u32(skb, HWSIM_ATTR_FREQ, data->channel->center_freq))
> + goto nla_put_failure;
> +
> /* We get the tx control (rate and retries) info*/
>
> for (i = 0; i < IEEE80211_TX_MAX_RATES; i++) {
> @@ -2421,6 +2424,7 @@ static int hwsim_cloned_frame_received_nl(struct
> sk_buff *skb_2,
> int frame_data_len;
> void *frame_data;
> struct sk_buff *skb = NULL;
> + u32 freq;
>
> if (info->snd_portid != wmediumd_portid) {
> printk(KERN_DEBUG "mac80211-hwsim: port-id mismatch: %d %d\n",
> @@ -2468,6 +2472,9 @@ static int hwsim_cloned_frame_received_nl(struct
> sk_buff *skb_2,
>
> /* A frame is received from user space */
> memset(&rx_status, 0, sizeof(rx_status));
> + /* TODO: Check ATTR_FREQ if it exists, and maybe throw away off-channel
> + * packets?
> + */
> rx_status.freq = data2->channel->center_freq;
> rx_status.band = data2->channel->band;
> rx_status.rate_idx = nla_get_u32(info->attrs[HWSIM_ATTR_RX_RATE]);
> diff --git a/drivers/net/wireless/mac80211_hwsim.h
> b/drivers/net/wireless/mac80211_hwsim.h
> index e614a20..85da35a 100644
> --- a/drivers/net/wireless/mac80211_hwsim.h
> +++ b/drivers/net/wireless/mac80211_hwsim.h
> @@ -60,7 +60,7 @@ enum hwsim_tx_control_flags {
> * space, uses:
> * %HWSIM_ATTR_ADDR_TRANSMITTER, %HWSIM_ATTR_ADDR_RECEIVER,
> * %HWSIM_ATTR_FRAME, %HWSIM_ATTR_FLAGS, %HWSIM_ATTR_RX_RATE,
> - * %HWSIM_ATTR_SIGNAL, %HWSIM_ATTR_COOKIE
> + * %HWSIM_ATTR_SIGNAL, %HWSIM_ATTR_COOKIE, %HWSIM_ATTR_FREQ (optional)
> * @HWSIM_CMD_TX_INFO_FRAME: Transmission info report from user space to
> * kernel, uses:
> * %HWSIM_ATTR_ADDR_TRANSMITTER, %HWSIM_ATTR_FLAGS,
> @@ -113,6 +113,7 @@ enum {
> * single channel is supported
> * @HWSIM_ATTR_RADIO_NAME: Name of radio, e.g. phy666
> * @HWSIM_ATTR_NO_VIF: Do not create vif (wlanX) when creating radio.
> + * @HWSIM_ATTR_FREQ: Frequency at which packet is transmitted or received.
> * @__HWSIM_ATTR_MAX: enum limit
> */
>
> @@ -137,6 +138,7 @@ enum {
> HWSIM_ATTR_DESTROY_RADIO_ON_CLOSE,
> HWSIM_ATTR_RADIO_NAME,
> HWSIM_ATTR_NO_VIF,
> + HWSIM_ATTR_FREQ,
> __HWSIM_ATTR_MAX,
> };
> #define HWSIM_ATTR_MAX (__HWSIM_ATTR_MAX - 1)
Cheers,
Jukka
--
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 0/2] Add mcast event when hwsim radios are created and removed
Hi Jukka, Unfortunately this failed to apply, likely because I also applied some of Ben's patches in the meantime. Please rebase your patch on mac80211-next. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
