Re: rtl8192ce kernel panics since 3.17(?)
On 02/12/2015 11:27 AM, Johannes Löthberg wrote: On 12/02, Larry Finger wrote: On 02/12/2015 06:10 AM, Johannes Löthberg wrote: Since sometime around version 3.16 or 3.17 I've been getting a lot of occasional kernel panics related to my wifi driver. My laptop has a Realtek RTL8188CE wireless card and uses the rtl8192ce driver. I have pictures of what I think is two identical kernel panics, a couple of days apart: https://lh4.googleusercontent.com/yjwOnrDmioCwuC8FqIXlKMiBTOXddLyJkWTiInJoX2o=w421-h569-no https://lh3.googleusercontent.com/-xM-1wSsVu4c/VKxDnlkgBbI/Ing/HxtqgHgglHY/w421-h569-no/IMG_20150106_212020.jpg It only seems to happen when I have several days of uptime on my laptop and just use sleep all the time instead of shutting it down. Also I have a picture of a kernel panic that is different from the previous ones: https://lh3.googleusercontent.com/-Hj06Csglpa0/VKrI1al6QbI/Imk/VzhmN-dfSB0/w657-h486-no/IMG_20150105_182236.jpg Not sure how to debug it really, but figured that sending in a report would be worth a shot. What kernel were you running when you made the photos? Use the command 'uname -r'. When I get that information, I can then use the dump trace to determine the locations of the oops. Larry For the first photo it was 3.18.3 and for the second one it seems like it should be 3.18.1 from looking at my package manager's log. OK, that makes more sense than your original report of problems starting with 3.16 or 3.17. That bug was fixed in 3.18.4. 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
[PATCH] nfc: logging neatening
Add missing terminating newlines to nfc_info and nfc_err
to avoid possible interleaving from other messages.
Miscellanea:
o typo fix of unknonwn in message
o remove unnecessary OOM messages as there's a generic dump_stack()
o realign arguments
Signed-off-by: Joe Perches j...@perches.com
---
drivers/nfc/microread/i2c.c | 2 +-
drivers/nfc/nfcmrvl/main.c | 4 ++--
drivers/nfc/nfcmrvl/usb.c | 18 +-
drivers/nfc/pn533.c | 2 +-
drivers/nfc/pn544/i2c.c | 7 ++-
drivers/nfc/port100.c | 36 ++--
drivers/nfc/st21nfcb/i2c.c | 5 +
drivers/nfc/st21nfcb/ndlc.c | 5 ++---
8 files changed, 36 insertions(+), 43 deletions(-)
diff --git a/drivers/nfc/microread/i2c.c b/drivers/nfc/microread/i2c.c
index df85cd3..661e2c8 100644
--- a/drivers/nfc/microread/i2c.c
+++ b/drivers/nfc/microread/i2c.c
@@ -286,7 +286,7 @@ static int microread_i2c_probe(struct i2c_client *client,
if (r 0)
goto err_irq;
- nfc_info(client-dev, Probed);
+ nfc_info(client-dev, Probed\n);
return 0;
diff --git a/drivers/nfc/nfcmrvl/main.c b/drivers/nfc/nfcmrvl/main.c
index 85e8bcf..ad4933c 100644
--- a/drivers/nfc/nfcmrvl/main.c
+++ b/drivers/nfc/nfcmrvl/main.c
@@ -111,7 +111,7 @@ struct nfcmrvl_private *nfcmrvl_nci_register_dev(void
*drv_data,
priv-ndev = nci_allocate_device(nfcmrvl_nci_ops, protocols, 0, 0);
if (!priv-ndev) {
- nfc_err(dev, nci_allocate_device failed);
+ nfc_err(dev, nci_allocate_device failed\n);
rc = -ENOMEM;
goto error;
}
@@ -120,7 +120,7 @@ struct nfcmrvl_private *nfcmrvl_nci_register_dev(void
*drv_data,
rc = nci_register_device(priv-ndev);
if (rc) {
- nfc_err(dev, nci_register_device failed %d, rc);
+ nfc_err(dev, nci_register_device failed %d\n, rc);
nci_free_device(priv-ndev);
goto error;
}
diff --git a/drivers/nfc/nfcmrvl/usb.c b/drivers/nfc/nfcmrvl/usb.c
index 3221ca3..6cf15c1 100644
--- a/drivers/nfc/nfcmrvl/usb.c
+++ b/drivers/nfc/nfcmrvl/usb.c
@@ -80,7 +80,7 @@ static void nfcmrvl_bulk_complete(struct urb *urb)
if (!urb-status) {
if (nfcmrvl_nci_recv_frame(drv_data-priv, urb-transfer_buffer,
urb-actual_length) 0)
- nfc_err(drv_data-udev-dev, corrupted Rx packet);
+ nfc_err(drv_data-udev-dev, corrupted Rx packet\n);
}
if (!test_bit(NFCMRVL_USB_BULK_RUNNING, drv_data-flags))
@@ -96,7 +96,7 @@ static void nfcmrvl_bulk_complete(struct urb *urb)
*/
if (err != -EPERM err != -ENODEV)
nfc_err(drv_data-udev-dev,
- urb %p failed to resubmit (%d), urb, -err);
+ urb %p failed to resubmit (%d)\n, urb, -err);
usb_unanchor_urb(urb);
}
}
@@ -137,7 +137,7 @@ nfcmrvl_submit_bulk_urb(struct nfcmrvl_usb_drv_data
*drv_data, gfp_t mem_flags)
if (err) {
if (err != -EPERM err != -ENODEV)
nfc_err(drv_data-udev-dev,
- urb %p submission failed (%d), urb, -err);
+ urb %p submission failed (%d)\n, urb, -err);
usb_unanchor_urb(urb);
}
@@ -153,7 +153,7 @@ static void nfcmrvl_tx_complete(struct urb *urb)
struct nfcmrvl_private *priv = nci_get_drvdata(ndev);
struct nfcmrvl_usb_drv_data *drv_data = priv-drv_data;
- nfc_info(priv-dev, urb %p status %d count %d,
+ nfc_info(priv-dev, urb %p status %d count %d\n,
urb, urb-status, urb-actual_length);
spin_lock(drv_data-txlock);
@@ -253,7 +253,7 @@ static int nfcmrvl_usb_nci_send(struct nfcmrvl_private
*priv,
if (err) {
if (err != -EPERM err != -ENODEV)
nfc_err(drv_data-udev-dev,
- urb %p submission failed (%d), urb, -err);
+ urb %p submission failed (%d)\n, urb, -err);
kfree(urb-setup_packet);
usb_unanchor_urb(urb);
} else {
@@ -293,7 +293,7 @@ static int nfcmrvl_probe(struct usb_interface *intf,
int i;
struct usb_device *udev = interface_to_usbdev(intf);
- nfc_info(udev-dev, intf %p id %p, intf, id);
+ nfc_info(udev-dev, intf %p id %p\n, intf, id);
drv_data = devm_kzalloc(intf-dev, sizeof(*drv_data), GFP_KERNEL);
if (!drv_data)
@@ -348,7 +348,7 @@ static void nfcmrvl_disconnect(struct usb_interface *intf)
if (!drv_data)
return;
- nfc_info(drv_data-udev-dev, intf %p, intf);
+ nfc_info(drv_data-udev-dev, intf %p\n, intf);
nfcmrvl_nci_unregister_dev(drv_data-priv);
@@ -360,7 +360,7 @@ static int
Re: [PATCH v2 2/2] NFC: Add ACPI support for NXP PN544
Hello Robert,
On Thu, Feb 12, 2015 at 07:48:43PM +0200, Robert Dolca wrote:
On Thu, Feb 12, 2015 at 09:14:59AM +0100, Uwe Kleine-König wrote:
On Mon, Jan 26, 2015 at 01:13:37PM +0200, Robert Dolca wrote:
+ /* Get EN GPIO from ACPI */
+ gpiod_en = devm_gpiod_get_index(dev, PN544_GPIO_NAME_EN, 1);
Actually devm_gpiod_get_index takes 4 arguments. In your case you should
also pass GPIOD_OUT_LOW, then you can skip the gpiod_direction_output
part below.
+ if (IS_ERR(gpiod_en)) {
+ nfc_err(dev,
+ Unable to get EN GPIO\n);
+ return -ENODEV;
+ }
+
+ phy-gpio_en = desc_to_gpio(gpiod_en);
Why don't you save a reference to the gpiod instead? Mixing usage of raw
and gpiod might result in surprising results. For example
gpiod_direction_output(gpiod_en, 0);
might actually have the same result as
gpio_direction_output(gpio_en, 1);
if the matching gpio is marked as active low.
+
+ /* Configuration EN GPIO */
+ ret = gpiod_direction_output(gpiod_en, 0);
+ if (ret) {
+ nfc_err(dev, Fail EN pin direction\n);
+ return ret;
+ }
+
+ /* Get FW GPIO from ACPI */
+ gpiod_fw = devm_gpiod_get_index(dev, PN544_GPIO_NAME_FW, 2);
+ if (IS_ERR(gpiod_fw)) {
+ nfc_err(dev,
+ Unable to get FW GPIO\n);
+ return -ENODEV;
+ }
+
+ phy-gpio_fw = desc_to_gpio(gpiod_fw);
+
+ /* Configuration FW GPIO */
+ ret = gpiod_direction_output(gpiod_fw, 0);
+ if (ret) {
+ nfc_err(dev, Fail FW pin direction\n);
+ return ret;
+ }
The same comments apply here.
+
+ /* Get IRQ GPIO */
+ gpiod_irq = devm_gpiod_get_index(dev, PN544_GPIO_NAME_IRQ, 0);
+ if (IS_ERR(gpiod_irq)) {
+ nfc_err(dev,
+ Unable to get IRQ GPIO\n);
+ return -ENODEV;
+ }
+
+ phy-gpio_irq = desc_to_gpio(gpiod_irq);
+
+ /* Configure IRQ GPIO */
+ ret = gpiod_direction_input(gpiod_irq);
+ if (ret) {
+ nfc_err(dev, Fail IRQ pin direction\n);
+ return ret;
+ }
+
+ /* Map the pin to an IRQ */
+ ret = gpiod_to_irq(gpiod_irq);
+ if (ret 0) {
+ nfc_err(dev, Fail pin IRQ mapping\n);
+ return ret;
+ }
and here.
Also as far as I know the device tree implementation will not give you the
gpiod data structure. It gives you only the gpio index.
What is the device tree implementation? If devm_gpiod_get_index gets
the information which gpio to use from a device tree that doesn't change
the return type, you still get a struct gpio_desc pointer. And it can
very well return a descriptor with GPIO_ACTIVE_LOW set, see the
implementation of of_find_gpio.
Keeping both gpiod and gpio depending on the enumeration method is unscallable
so I didn't choose that.
And if the descriptor has GPIO_ACTIVE_LOW set, you should better not
ignore it. The best thing to do here AFAIUI is to first convert the
driver to gpiod and then add your ACPI support in an additional patch.
And then please (this was the main motivation for my reply) your the
4-parameter version of devm_gpiod_get_index.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
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
rtl8192ce kernel panics since 3.17(?)
Since sometime around version 3.16 or 3.17 I've been getting a lot of occasional kernel panics related to my wifi driver. My laptop has a Realtek RTL8188CE wireless card and uses the rtl8192ce driver. I have pictures of what I think is two identical kernel panics, a couple of days apart: https://lh4.googleusercontent.com/yjwOnrDmioCwuC8FqIXlKMiBTOXddLyJkWTiInJoX2o=w421-h569-no https://lh3.googleusercontent.com/-xM-1wSsVu4c/VKxDnlkgBbI/Ing/HxtqgHgglHY/w421-h569-no/IMG_20150106_212020.jpg It only seems to happen when I have several days of uptime on my laptop and just use sleep all the time instead of shutting it down. Also I have a picture of a kernel panic that is different from the previous ones: https://lh3.googleusercontent.com/-Hj06Csglpa0/VKrI1al6QbI/Imk/VzhmN-dfSB0/w657-h486-no/IMG_20150105_182236.jpg Not sure how to debug it really, but figured that sending in a report would be worth a shot. [Note: I'm not subscribed to the ML, so please CC me in replies.] -- Sincerely, Johannes Löthberg PGP Key ID: 0x50FB9B273A9D0BB5 https://theos.kyriasis.com/~kyrias/ pgpST8ClgtzH1.pgp Description: PGP signature
[PATCH] ath10k: Increase AST table SKID length limit
The current SKID length configuration causes firmware
to reject peer creation for not able to allocate
AST entries for peers. This issue is observed when
least significant 3 bytes are used ramdomly to create
client MAC addresses.
AST table SKID length configuration is increased to
maximum value to fix this issue.
Signed-off-by: SenthilKumar Jegadeesan sjega...@qti.qualcomm.com
---
drivers/net/wireless/ath/ath10k/hw.h | 1 +
drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/hw.h
b/drivers/net/wireless/ath/ath10k/hw.h
index 460771f..b86996e 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -254,6 +254,7 @@ struct ath10k_pktlog_hdr {
/* 10.2 parameters */
#define TARGET_10_2_DMA_BURST_SIZE 1
+#define TARGET_10_2_AST_SKID_LIMIT 128
/* Target specific defines for WMI-TLV firmware */
#define TARGET_TLV_NUM_VDEVS 3
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c
b/drivers/net/wireless/ath/ath10k/wmi.c
index aeea1c7..13290da 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -3920,7 +3920,7 @@ static struct sk_buff *ath10k_wmi_10_2_op_gen_init(struct
ath10k *ar)
config.num_peers = __cpu_to_le32(TARGET_10X_NUM_PEERS);
config.num_peer_keys = __cpu_to_le32(TARGET_10X_NUM_PEER_KEYS);
config.num_tids = __cpu_to_le32(TARGET_10X_NUM_TIDS);
- config.ast_skid_limit = __cpu_to_le32(TARGET_10X_AST_SKID_LIMIT);
+ config.ast_skid_limit = __cpu_to_le32(TARGET_10_2_AST_SKID_LIMIT);
config.tx_chain_mask = __cpu_to_le32(TARGET_10X_TX_CHAIN_MASK);
config.rx_chain_mask = __cpu_to_le32(TARGET_10X_RX_CHAIN_MASK);
config.rx_timeout_pri_vo = __cpu_to_le32(TARGET_10X_RX_TIMEOUT_LO_PRI);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] iwl4965: Enable checking of format strings
On Thu, Feb 12 2015, Rustad, Mark D mark.d.rus...@intel.com wrote: On Feb 11, 2015, at 2:51 PM, Rasmus Villemoes li...@rasmusvillemoes.dk wrote: Since these fmt_* variables are just const char*, and not const char[], gcc (and smatch) doesn't to type checking of the arguments to the printf functions. Since the linker knows perfectly well to merge identical string constants, there's no point in having three static pointers waste memory and give an extra level of indirection. This removes over 100 non-constant format argument warnings from smatch, accounting for about 20% of all such warnings in an allmodconfig. Signed-off-by: Rasmus Villemoes li...@rasmusvillemoes.dk --- drivers/net/wireless/iwlegacy/4965-debug.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/iwlegacy/4965-debug.c b/drivers/net/wireless/iwlegacy/4965-debug.c index e0597bfdddb8..18855325cc1c 100644 --- a/drivers/net/wireless/iwlegacy/4965-debug.c +++ b/drivers/net/wireless/iwlegacy/4965-debug.c @@ -28,10 +28,9 @@ #include common.h #include 4965.h -static const char *fmt_value = %-30s %10u\n; -static const char *fmt_table = %-30s %10u %10u %10u %10u\n; -static const char *fmt_header = -%-32scurrent cumulative delta max\n; Why not change these to: static const char fmt_value[] = %-30s %10u\n; static const char fmt_table[] = %-30s %10u %10u %10u %10u\n; static const char fmt_header[] = %-32scurrent cumulative delta max\n; I think that is better than the macros and avoids the extra pointers that I agree are useless. Rather weak arguments, but I have three of them :-) (1) If I'm reading some code and spot a non-constant format argument, I sometimes track back to see how e.g. fmt_value is defined. If I then see it's a macro, I immediately think ok, the compiler is doing type-checking. If it is a const char[], I have to remember that gcc also does it in that case (as opposed to for example const char*const). (2) The names of these variables themselves may end up wasting a few bytes in the image. (3) gcc/the linker doesn't merge identical const char[] arrays across translation units. It also doesn't consider their tails for merging with string literals. So although these specific strings are unlikely to appear elsewhere, a string such as %10u\n or max\n couldn't be merged with one of the above. Rasmus -- 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: rtl8192ce kernel panics since 3.17(?)
On 02/12/2015 03:54 PM, Johannes Löthberg wrote: On 12/02, Larry Finger wrote: OK, that makes more sense than your original report of problems starting with 3.16 or 3.17. That bug was fixed in 3.18.4. Well, I'm rather sure that I had some panics in 3.17 due to it, but I have no photographic evidence anymore alas. And d'oh, should have tried a newer kernel before sending it in, was meaning to report it for a while but never ended up to, sorry. Any idea about the third kernel panic photo? Trying to trace it back on my kernel leads to a nonsense location. If it happens again, capture the trace as you did, then find the location in one of the rtl* routines that crashed. In the picture you sent, that is _rtl_pci_interrupt+0x3d0 and that is in rtl_pci. To find the code section that crashed, start in the kernel source directory and do the following: gdb drivers/net/wireless/rtlwifi/rtl_pci.ko l *_rtl_pci_interrupt+0x3d0 quit Adjust the driver and location to match the new crash. Send me the output of the l command. 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: [PATCH 1/3] ath: Introduce chirp parameter used by DFS
On 02/12/2015 01:17 PM, Peter Oh wrote:
Some of radar types such as FCC radar type 5 require
to look up chirp in pulse to detect genuine radar and
it will prevent DFS channels from false radar detection.
Signed-off-by: Peter Oh p...@qca.qualcomm.com
---
drivers/net/wireless/ath/dfs_pattern_detector.c | 52
-
drivers/net/wireless/ath/dfs_pattern_detector.h | 4 ++
2 files changed, 30 insertions(+), 26 deletions(-)
diff --git a/drivers/net/wireless/ath/dfs_pattern_detector.c
b/drivers/net/wireless/ath/dfs_pattern_detector.c
index 3d57f87..b1de8c6 100644
--- a/drivers/net/wireless/ath/dfs_pattern_detector.c
+++ b/drivers/net/wireless/ath/dfs_pattern_detector.c
@@ -48,23 +48,23 @@ struct radar_types {
#define WIDTH_LOWER(X) ((X*(100-WIDTH_TOLERANCE)+50)/100)
#define WIDTH_UPPER(X) ((X*(100+WIDTH_TOLERANCE)+50)/100)
-#define ETSI_PATTERN(ID, WMIN, WMAX, PMIN, PMAX, PRF, PPB) \
+#define ETSI_PATTERN(ID, WMIN, WMAX, PMIN, PMAX, PRF, PPB, CHIRP) \
{ \
ID, WIDTH_LOWER(WMIN), WIDTH_UPPER(WMAX), \
(PRF2PRI(PMAX) - PRI_TOLERANCE),\
(PRF2PRI(PMIN) * PRF + PRI_TOLERANCE), PRF, PPB * PRF, \
- PPB_THRESH(PPB), PRI_TOLERANCE, \
+ PPB_THRESH(PPB), PRI_TOLERANCE, CHIRP \
}
/* radar types as defined by ETSI EN-301-893 v1.5.1 */
static const struct radar_detector_specs etsi_radar_ref_types_v15[] = {
- ETSI_PATTERN(0, 0, 1, 700, 700, 1, 18),
- ETSI_PATTERN(1, 0, 5, 200, 1000, 1, 10),
- ETSI_PATTERN(2, 0, 15, 200, 1600, 1, 15),
- ETSI_PATTERN(3, 0, 15, 2300, 4000, 1, 25),
- ETSI_PATTERN(4, 20, 30, 2000, 4000, 1, 20),
- ETSI_PATTERN(5, 0, 2, 300, 400, 3, 10),
- ETSI_PATTERN(6, 0, 2, 400, 1200, 3, 15),
+ ETSI_PATTERN(0, 0, 1, 700, 700, 1, 18, false),
+ ETSI_PATTERN(1, 0, 5, 200, 1000, 1, 10, false),
+ ETSI_PATTERN(2, 0, 15, 200, 1600, 1, 15, false),
+ ETSI_PATTERN(3, 0, 15, 2300, 4000, 1, 25, false),
+ ETSI_PATTERN(4, 20, 30, 2000, 4000, 1, 20, false),
+ ETSI_PATTERN(5, 0, 2, 300, 400, 3, 10, false),
+ ETSI_PATTERN(6, 0, 2, 400, 1200, 3, 15, false),
};
static const struct radar_types etsi_radar_types_v15 = {
@@ -73,21 +73,21 @@ static const struct radar_types etsi_radar_types_v15 =
{
.radar_types= etsi_radar_ref_types_v15,
};
-#define FCC_PATTERN(ID, WMIN, WMAX, PMIN, PMAX, PRF, PPB) \
+#define FCC_PATTERN(ID, WMIN, WMAX, PMIN, PMAX, PRF, PPB, CHIRP) \
{ \
ID, WIDTH_LOWER(WMIN), WIDTH_UPPER(WMAX), \
PMIN - PRI_TOLERANCE, \
PMAX * PRF + PRI_TOLERANCE, PRF, PPB * PRF, \
- PPB_THRESH(PPB), PRI_TOLERANCE, \
+ PPB_THRESH(PPB), PRI_TOLERANCE, CHIRP \
}
static const struct radar_detector_specs fcc_radar_ref_types[] = {
- FCC_PATTERN(0, 0, 1, 1428, 1428, 1, 18),
- FCC_PATTERN(1, 0, 5, 150, 230, 1, 23),
- FCC_PATTERN(2, 6, 10, 200, 500, 1, 16),
- FCC_PATTERN(3, 11, 20, 200, 500, 1, 12),
- FCC_PATTERN(4, 50, 100, 1000, 2000, 1, 1),
- FCC_PATTERN(5, 0, 1, 333, 333, 1, 9),
+ FCC_PATTERN(0, 0, 1, 1428, 1428, 1, 18, false),
+ FCC_PATTERN(1, 0, 5, 150, 230, 1, 23, false),
+ FCC_PATTERN(2, 6, 10, 200, 500, 1, 16, false),
+ FCC_PATTERN(3, 11, 20, 200, 500, 1, 12, false),
+ FCC_PATTERN(4, 50, 100, 1000, 2000, 1, 1, true),
+ FCC_PATTERN(5, 0, 1, 333, 333, 1, 9, false),
};
static const struct radar_types fcc_radar_types = {
@@ -98,15 +98,15 @@ static const struct radar_types fcc_radar_types = {
#define JP_PATTERN FCC_PATTERN
static const struct radar_detector_specs jp_radar_ref_types[] = {
- JP_PATTERN(0, 0, 1, 1428, 1428, 1, 18),
- JP_PATTERN(1, 2, 3, 3846, 3846, 1, 18),
- JP_PATTERN(2, 0, 1, 1388, 1388, 1, 18),
- JP_PATTERN(3, 1, 2, 4000, 4000, 1, 18),
- JP_PATTERN(4, 0, 5, 150, 230, 1, 23),
- JP_PATTERN(5, 6, 10, 200, 500, 1, 16),
- JP_PATTERN(6, 11, 20, 200, 500, 1, 12),
- JP_PATTERN(7, 50, 100, 1000, 2000, 1, 20),
- JP_PATTERN(5, 0, 1, 333, 333, 1, 9),
+ JP_PATTERN(0, 0, 1, 1428, 1428, 1, 18, false),
+ JP_PATTERN(1, 2, 3, 3846, 3846, 1, 18, false),
+ JP_PATTERN(2, 0, 1, 1388, 1388, 1, 18, false),
+ JP_PATTERN(3, 1, 2, 4000, 4000, 1, 18, false),
+ JP_PATTERN(4, 0, 5, 150, 230, 1, 23, false),
+ JP_PATTERN(5, 6, 10, 200, 500, 1, 16, false),
+ JP_PATTERN(6, 11, 20, 200, 500, 1, 12, false),
+ JP_PATTERN(7, 50, 100, 1000, 2000, 1, 20, false),
+ JP_PATTERN(5, 0, 1, 333, 333, 1, 9, false),
};
static const struct radar_types jp_radar_types = {
diff --git
cw1200 - deadlock warning on imx6 quad core
[ 108.191975] ==
[ 108.198157] [ INFO: possible circular locking dependency detected ]
[ 108.204430] 3.17.2 #9 Not tainted
[ 108.207748] ---
[ 108.214018] kworker/u8:1/30 is trying to acquire lock:
[ 108.219160] (priv-conf_mutex){+.+.+.}, at: [80442380]
cw1200_bss_params_work+0x24/0x4c
[ 108.227593]
[ 108.227593] but task is already holding lock:
[ 108.233430] ((priv-bss_params_work)){+.+...}, at: [8003dd44]
process_one_work+0x13c/0x3fc
[ 108.242111]
[ 108.242111] which lock already depends on the new lock.
[ 108.242111]
[ 108.250294]
[ 108.250294] the existing dependency chain (in reverse order) is:
[ 108.257780]
- #2 ((priv-bss_params_work)){+.+...}:
[ 108.263065][8003cf10] flush_work+0x44/0x268
[ 108.268138][8003eac0] __cancel_work_timer+0x88/0x12c
[ 108.273992][8003eb90] cancel_work_sync+0x14/0x18
[ 108.279497][804410ac] __cw1200_cqm_bssloss_sm+0x30/0x148
[ 108.285699][804438b8] cw1200_bss_info_changed+0x23c/0xc78
[ 108.291988][8066c23c]
ieee80211_bss_info_change_notify+0xa8/0x11c
[ 108.298980][806b12cc] ieee80211_assoc_success+0x7cc/0xa18
[ 108.305273][8069cefc] ieee80211_rx_mgmt_assoc_resp+0x13c/0x26c
[ 108.311994][8069d32c] ieee80211_sta_rx_queued_mgmt+0x28c/0x5e8
[ 108.318714][8067ba94] ieee80211_iface_work+0x280/0x354
[ 108.324747][8003ddb0] process_one_work+0x1a8/0x3fc
[ 108.330426][8003e158] worker_thread+0x118/0x4d0
[ 108.335844][80042fec] kthread+0xd0/0xec
[ 108.340567][8000eac8] ret_from_fork+0x14/0x2c
[ 108.345817]
- #1 ((priv-bss_loss_lock)-rlock){+.+...}:
[ 108.351623][806b631c] _raw_spin_lock+0x34/0x44
[ 108.356958][804438a4] cw1200_bss_info_changed+0x228/0xc78
[ 108.363246][8066c23c]
ieee80211_bss_info_change_notify+0xa8/0x11c
[ 108.370230] [806b12cc] ieee80211_assoc_success+0x7cc/0xa18
[ 108.376597][8069cefc] ieee80211_rx_mgmt_assoc_resp+0x13c/0x26c
[ 108.383318][8069d32c] ieee80211_sta_rx_queued_mgmt+0x28c/0x5e8
[ 108.390038][8067ba94] ieee80211_iface_work+0x280/0x354
[ 108.396066][8003ddb0] process_one_work+0x1a8/0x3fc
[ 108.401745][8003e158] worker_thread+0x118/0x4d0
[ 108.407163][80042fec] kthread+0xd0/0xec
[ 108.411885][8000eac8] ret_from_fork+0x14/0x2c
[ 108.417131]
- #0 (priv-conf_mutex){+.+.+.}:
[ 108.421808][800600d8] lock_acquire+0x68/0x7c
[ 108.426971][806b446c] mutex_lock_nested+0x5c/0x3c0
[ 108.432651][80442380] cw1200_bss_params_work+0x24/0x4c
[ 108.438682][8003ddb0] process_one_work+0x1a8/0x3fc
[ 108.444361][8003e158] worker_thread+0x118/0x4d0
[ 108.449780][80042fec] kthread+0xd0/0xec
[ 108.454502][8000eac8] ret_from_fork+0x14/0x2c
[ 108.459749]
[ 108.459749] other info that might help us debug this:
[ 108.459749]
[ 108.467758] Chain exists of:
priv-conf_mutex -- (priv-bss_loss_lock)-rlock --
(priv-bss_params_work)
[ 108.478281] Possible unsafe locking scenario:
[ 108.478281]
[ 108.484204]CPU0CPU1
[ 108.488736]
[ 108.493268] lock((priv-bss_params_work));
[ 108.497655] lock((priv-bss_loss_lock)-rlock);
[ 108.505081] lock((priv-bss_params_work));
[ 108.511987] lock(priv-conf_mutex);
[ 108.515766]
[ 108.515766] *** DEADLOCK ***
[ 108.515766]
[ 108.521692] 2 locks held by kworker/u8:1/30:
[ 108.525964] #0: (%scw1200_wq){.+.+.+}, at: [8003dd44]
process_one_work+0x13c/0x3fc
[ 108.534308] #1: ((priv-bss_params_work)){+.+...}, at:
[8003dd44] process_one_work+0x13c/0x3fc
[ 108.543433]
[ 108.543433] stack backtrace:
[ 108.547799] CPU: 2 PID: 30 Comm: kworker/u8:1 Not tainted 3.17.2 #9
[ 108.554074] Workqueue: cw1200_wq cw1200_bss_params_work
[ 108.559315] Backtrace:
[ 108.561791] [80011dc0] (dump_backtrace) from [80011f60]
(show_stack+0x18/0x1c)
[ 108.569363] r6:80b28700 r5: r4: r3:be1d3a80
[ 108.575094] [80011f48] (show_stack) from [806af960]
(dump_stack+0x80/0x9c)
[ 108.582325] [806af8e0] (dump_stack) from [806ad704]
(print_circular_bug+0x284/0x2dc)
[ 108.590417] r5:80b28a30 r4:80b26610
[ 108.594032] [806ad480] (print_circular_bug) from [8005f864]
(__lock_acquire+0x19c8/0x1d0c)
[ 108.602645] r10:0110 r9:be1d3f08 r8:80b28a30 r7:
r6:811ba594 r5:be1d3ef0
[ 108.610555] r4:be1d3a80 r3:be1d3ef0
[ 108.614168] [8005de9c] (__lock_acquire) from [800600d8]
(lock_acquire+0x68/0x7c)
[ 108.621914] r10:be21 r9:be1d3a80 r8:be21 r7:
r6:6013 r5:be21
[ 108.629826] r4:
[ 108.632384] [80060070] (lock_acquire) from [806b446c]
(mutex_lock_nested+0x5c/0x3c0)
[ 108.640477] r7:- r6:8116af54 r5:80442380 r4:bd6895ac
[ 108.646294] [806b4410] (mutex_lock_nested) from [80442380]
[PATCH 1/3] ath: Introduce chirp parameter used by DFS
Some of radar types such as FCC radar type 5 require
to look up chirp in pulse to detect genuine radar and
it will prevent DFS channels from false radar detection.
Signed-off-by: Peter Oh p...@qca.qualcomm.com
---
drivers/net/wireless/ath/dfs_pattern_detector.c | 52 -
drivers/net/wireless/ath/dfs_pattern_detector.h | 4 ++
2 files changed, 30 insertions(+), 26 deletions(-)
diff --git a/drivers/net/wireless/ath/dfs_pattern_detector.c
b/drivers/net/wireless/ath/dfs_pattern_detector.c
index 3d57f87..b1de8c6 100644
--- a/drivers/net/wireless/ath/dfs_pattern_detector.c
+++ b/drivers/net/wireless/ath/dfs_pattern_detector.c
@@ -48,23 +48,23 @@ struct radar_types {
#define WIDTH_LOWER(X) ((X*(100-WIDTH_TOLERANCE)+50)/100)
#define WIDTH_UPPER(X) ((X*(100+WIDTH_TOLERANCE)+50)/100)
-#define ETSI_PATTERN(ID, WMIN, WMAX, PMIN, PMAX, PRF, PPB) \
+#define ETSI_PATTERN(ID, WMIN, WMAX, PMIN, PMAX, PRF, PPB, CHIRP) \
{ \
ID, WIDTH_LOWER(WMIN), WIDTH_UPPER(WMAX), \
(PRF2PRI(PMAX) - PRI_TOLERANCE),\
(PRF2PRI(PMIN) * PRF + PRI_TOLERANCE), PRF, PPB * PRF, \
- PPB_THRESH(PPB), PRI_TOLERANCE, \
+ PPB_THRESH(PPB), PRI_TOLERANCE, CHIRP \
}
/* radar types as defined by ETSI EN-301-893 v1.5.1 */
static const struct radar_detector_specs etsi_radar_ref_types_v15[] = {
- ETSI_PATTERN(0, 0, 1, 700, 700, 1, 18),
- ETSI_PATTERN(1, 0, 5, 200, 1000, 1, 10),
- ETSI_PATTERN(2, 0, 15, 200, 1600, 1, 15),
- ETSI_PATTERN(3, 0, 15, 2300, 4000, 1, 25),
- ETSI_PATTERN(4, 20, 30, 2000, 4000, 1, 20),
- ETSI_PATTERN(5, 0, 2, 300, 400, 3, 10),
- ETSI_PATTERN(6, 0, 2, 400, 1200, 3, 15),
+ ETSI_PATTERN(0, 0, 1, 700, 700, 1, 18, false),
+ ETSI_PATTERN(1, 0, 5, 200, 1000, 1, 10, false),
+ ETSI_PATTERN(2, 0, 15, 200, 1600, 1, 15, false),
+ ETSI_PATTERN(3, 0, 15, 2300, 4000, 1, 25, false),
+ ETSI_PATTERN(4, 20, 30, 2000, 4000, 1, 20, false),
+ ETSI_PATTERN(5, 0, 2, 300, 400, 3, 10, false),
+ ETSI_PATTERN(6, 0, 2, 400, 1200, 3, 15, false),
};
static const struct radar_types etsi_radar_types_v15 = {
@@ -73,21 +73,21 @@ static const struct radar_types etsi_radar_types_v15 = {
.radar_types= etsi_radar_ref_types_v15,
};
-#define FCC_PATTERN(ID, WMIN, WMAX, PMIN, PMAX, PRF, PPB) \
+#define FCC_PATTERN(ID, WMIN, WMAX, PMIN, PMAX, PRF, PPB, CHIRP) \
{ \
ID, WIDTH_LOWER(WMIN), WIDTH_UPPER(WMAX), \
PMIN - PRI_TOLERANCE, \
PMAX * PRF + PRI_TOLERANCE, PRF, PPB * PRF, \
- PPB_THRESH(PPB), PRI_TOLERANCE, \
+ PPB_THRESH(PPB), PRI_TOLERANCE, CHIRP \
}
static const struct radar_detector_specs fcc_radar_ref_types[] = {
- FCC_PATTERN(0, 0, 1, 1428, 1428, 1, 18),
- FCC_PATTERN(1, 0, 5, 150, 230, 1, 23),
- FCC_PATTERN(2, 6, 10, 200, 500, 1, 16),
- FCC_PATTERN(3, 11, 20, 200, 500, 1, 12),
- FCC_PATTERN(4, 50, 100, 1000, 2000, 1, 1),
- FCC_PATTERN(5, 0, 1, 333, 333, 1, 9),
+ FCC_PATTERN(0, 0, 1, 1428, 1428, 1, 18, false),
+ FCC_PATTERN(1, 0, 5, 150, 230, 1, 23, false),
+ FCC_PATTERN(2, 6, 10, 200, 500, 1, 16, false),
+ FCC_PATTERN(3, 11, 20, 200, 500, 1, 12, false),
+ FCC_PATTERN(4, 50, 100, 1000, 2000, 1, 1, true),
+ FCC_PATTERN(5, 0, 1, 333, 333, 1, 9, false),
};
static const struct radar_types fcc_radar_types = {
@@ -98,15 +98,15 @@ static const struct radar_types fcc_radar_types = {
#define JP_PATTERN FCC_PATTERN
static const struct radar_detector_specs jp_radar_ref_types[] = {
- JP_PATTERN(0, 0, 1, 1428, 1428, 1, 18),
- JP_PATTERN(1, 2, 3, 3846, 3846, 1, 18),
- JP_PATTERN(2, 0, 1, 1388, 1388, 1, 18),
- JP_PATTERN(3, 1, 2, 4000, 4000, 1, 18),
- JP_PATTERN(4, 0, 5, 150, 230, 1, 23),
- JP_PATTERN(5, 6, 10, 200, 500, 1, 16),
- JP_PATTERN(6, 11, 20, 200, 500, 1, 12),
- JP_PATTERN(7, 50, 100, 1000, 2000, 1, 20),
- JP_PATTERN(5, 0, 1, 333, 333, 1, 9),
+ JP_PATTERN(0, 0, 1, 1428, 1428, 1, 18, false),
+ JP_PATTERN(1, 2, 3, 3846, 3846, 1, 18, false),
+ JP_PATTERN(2, 0, 1, 1388, 1388, 1, 18, false),
+ JP_PATTERN(3, 1, 2, 4000, 4000, 1, 18, false),
+ JP_PATTERN(4, 0, 5, 150, 230, 1, 23, false),
+ JP_PATTERN(5, 6, 10, 200, 500, 1, 16, false),
+ JP_PATTERN(6, 11, 20, 200, 500, 1, 12, false),
+ JP_PATTERN(7, 50, 100, 1000, 2000, 1, 20, false),
+ JP_PATTERN(5, 0, 1, 333, 333, 1, 9, false),
};
static const struct radar_types jp_radar_types = {
diff --git a/drivers/net/wireless/ath/dfs_pattern_detector.h
[PATCH 2/3] ath10k: Update chirp value in pulse event
Firmware reports chirp status in phy error event if it's detected and the chirp status is valuable to distinguish radar types. So save it to use for DFS parttern detector. Signed-off-by: Peter Oh p...@qca.qualcomm.com --- drivers/net/wireless/ath/ath10k/wmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c index 81561e4..0c06361 100644 --- a/drivers/net/wireless/ath/ath10k/wmi.c +++ b/drivers/net/wireless/ath/ath10k/wmi.c @@ -2550,7 +2550,7 @@ static void ath10k_dfs_radar_report(struct ath10k *ar, pe.freq = ar-hw-conf.chandef.chan-center_freq; pe.width = width; pe.rssi = rssi; - + pe.chirp = (MS(reg0, RADAR_REPORT_REG0_PULSE_IS_CHIRP) != 0); ath10k_dbg(ar, ATH10K_DBG_REGULATORY, dfs add pulse freq: %d, width: %d, rssi %d, tsf: %llX\n, pe.freq, pe.width, pe.rssi, pe.ts); -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ath: Enhance radar detection by looking up chirp
Certain radar types such as FCC radar type 5 are using chirp in their pulses, hence looking up the chirp status will enhance to avoid false radar detection. Signed-off-by: Peter Oh p...@qca.qualcomm.com --- drivers/net/wireless/ath/dfs_pri_detector.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/net/wireless/ath/dfs_pri_detector.c b/drivers/net/wireless/ath/dfs_pri_detector.c index 43b6081..1b5ad19 100644 --- a/drivers/net/wireless/ath/dfs_pri_detector.c +++ b/drivers/net/wireless/ath/dfs_pri_detector.c @@ -390,6 +390,10 @@ static struct pri_sequence *pri_detector_add_pulse(struct pri_detector *de, if ((ts - de-last_ts) rs-max_pri_tolerance) /* if delta to last pulse is too short, don't use this pulse */ return NULL; + /* radar detector spec needs chirp, but not detected */ + if (rs-chirp rs-chirp != event-chirp) + return NULL; + de-last_ts = ts; max_updated_seq = pseq_handler_add_to_existing_seqs(de, ts); -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl8192ce kernel panics since 3.17(?)
On 12/02, Larry Finger wrote: OK, that makes more sense than your original report of problems starting with 3.16 or 3.17. That bug was fixed in 3.18.4. Well, I'm rather sure that I had some panics in 3.17 due to it, but I have no photographic evidence anymore alas. And d'oh, should have tried a newer kernel before sending it in, was meaning to report it for a while but never ended up to, sorry. Any idea about the third kernel panic photo? -- Sincerely, Johannes Löthberg PGP Key ID: 0x50FB9B273A9D0BB5 https://theos.kyriasis.com/~kyrias/ pgp6Vp9EuXe7q.pgp Description: PGP signature
Wifi outside the faraday cage (was: Throughput regression with `tcp: refine TSO autosizing`)
On Fri, Feb 6, 2015 at 1:57 AM, Michal Kazior michal.kaz...@tieto.com wrote: On 5 February 2015 at 20:50, Dave Taht dave.t...@gmail.com wrote: [...] And I really, really, really wish, that just once during this thread, someone had bothered to try running a test at a real world MCS rate - say MCS1, or MCS4, and measured the latency under load of that... Time between frame submission to firmware and tx-completion on one of my ath10k machines: THANK YOU for running these tests! Legacy 54mbps: ~18ms Legacy 6mbps: ~37ms legacy rates are what many people actually achieve, given the limited market penetration ac has on clients and APs. 11n MCS 3 (nss=0): ~13ms 11n MCS 8 (nss=1): ~6-8ms 11ac NSS=1 MCS=2: ~4-6ms 11ac NSS=2 MCS=0: ~5-8ms Keep in mind this is a clean room environment so retransmissions are kept at minimum. Obviously with a noisy environment you'll get retries at different rates and higher latency. It is difficult to reconcile the results you get in the clean room with the results I get from measurements in the real wold. I encourage you to go test your code in coffee shops, in offices with wifi, and in hotels and apartment buildings in preference to testing in the lab. I typically measure induced delays in the 3 to 6 second range in your typical conference scenario, which I measure at every conference I go to. The latest talk, including data on that, is friday morning, starting at 2:15 or so, at nznog: http://new.livestream.com/i-filmservices/NZNOG2015/videos/75358960 1) In the real world, I rarely see the maximum *rates*. I am personally quite fond of designing stuff with gears out of the middle of the Boston Gear Catalog. [1]. In looking over my largely outdoor wifi network, I see a cluster of values around mcs11, followed\by mcs4,3, 7 and 0, and *nothing* with MCS15. David lang is planning on doing some measurements at the SCALE conference next week, and I expect heaps of data from that, but I strongly suspect that the vast majority of connections in every circumstance except the test-bench are not even coming close to the maximum MCS rate in the standard(s). I would have thought that the lessons of the chromecast, where *every* attempt at reviewing it in an office environment failed, might have supplied industry clue that even 20Mbit to a given station is impossible in many cases due to airtime contention. Aggregates should be sized to have a maximum of 2 full ones stacked up at the rate being achieved for the destination, and the rest backlogged in the qdisc layer, if possible. 37ms backed up in the firmware is a lot, considering that the test above had no airtime contention in it, and no multicast. Drivers need to be aware that every TXOP is precious. I could see having a watchdog timer set on getting one packet into a wifi driver to wait a few hundred usec longer to fire off the write to the hardware in order to maximize aggregation by accumulating more packets to aggregate. I have hopes for xmit_more also being useful, but I am really not sure how well that works on single cores, interactions with napi, and with other wifi aggregates. It looks like adding xmit_more to the ag71xx driver will be easy... 2) In the real world I see media acquisition times *far* greater than 1ms. Please feel free to test your drivers in coffee shops, in the office, at hotels, in apartments... And retries... let's not talk about retries... 3) Longer AMPDUs lead to more tail loss and retries I have a paper around here somewhere that shows AMPDU loss and retries go up disproportionately as the length of transmission approaches 4ms. I hate drawing a conclusion from a paper I can't find, but my overall take on it is that as media acquisition time and retransmits go up, reducing AMPDU size from the maximum down to about 1ms at the current rate would lead to more fair, responsive, and fast-feeling wifi for everyone, improve ack clocking, flow mixing for web traffic, etc, etc. 4) There is some fairly decent academic work on other aspects of excessive buffering at lower rates http://hph16.uwaterloo.ca/~bshihada/publications/buffer-AMPDU.pdf (there are problems with this paper, but at least it tests n) and see google scholar for bufferbloat related papers in 2014 and later on wifi and LTE. 5) As for rate control, Minstrel was designed in an era when there wasn't one AP for every 4 people in the USA. Other people's rate controllers are even dumber, and minstrel-ht itself needs a hard look at n speeds, much less ac speeds. 6) Everything I say above applies to both stations and APs. APs have FAR worse problems, where per-tid (station) queuing is really needed in order to effectively aggregate when two or more stations are in use. Statistically, with two or more stations using traffic, aggregation possibilities will go down rapidly on a FIFO, (and go down even faster with FQ in place without per sta queuing!), and with the usual fixed buffersize underneath that, without per-tid
Re: [PATCH v2 2/2] NFC: Add ACPI support for NXP PN544
Hello,
On Mon, Jan 26, 2015 at 01:13:37PM +0200, Robert Dolca wrote:
+ /* Get EN GPIO from ACPI */
+ gpiod_en = devm_gpiod_get_index(dev, PN544_GPIO_NAME_EN, 1);
Actually devm_gpiod_get_index takes 4 arguments. In your case you should
also pass GPIOD_OUT_LOW, then you can skip the gpiod_direction_output
part below.
+ if (IS_ERR(gpiod_en)) {
+ nfc_err(dev,
+ Unable to get EN GPIO\n);
+ return -ENODEV;
+ }
+
+ phy-gpio_en = desc_to_gpio(gpiod_en);
Why don't you save a reference to the gpiod instead? Mixing usage of raw
and gpiod might result in surprising results. For example
gpiod_direction_output(gpiod_en, 0);
might actually have the same result as
gpio_direction_output(gpio_en, 1);
if the matching gpio is marked as active low.
+
+ /* Configuration EN GPIO */
+ ret = gpiod_direction_output(gpiod_en, 0);
+ if (ret) {
+ nfc_err(dev, Fail EN pin direction\n);
+ return ret;
+ }
+
+ /* Get FW GPIO from ACPI */
+ gpiod_fw = devm_gpiod_get_index(dev, PN544_GPIO_NAME_FW, 2);
+ if (IS_ERR(gpiod_fw)) {
+ nfc_err(dev,
+ Unable to get FW GPIO\n);
+ return -ENODEV;
+ }
+
+ phy-gpio_fw = desc_to_gpio(gpiod_fw);
+
+ /* Configuration FW GPIO */
+ ret = gpiod_direction_output(gpiod_fw, 0);
+ if (ret) {
+ nfc_err(dev, Fail FW pin direction\n);
+ return ret;
+ }
The same comments apply here.
+
+ /* Get IRQ GPIO */
+ gpiod_irq = devm_gpiod_get_index(dev, PN544_GPIO_NAME_IRQ, 0);
+ if (IS_ERR(gpiod_irq)) {
+ nfc_err(dev,
+ Unable to get IRQ GPIO\n);
+ return -ENODEV;
+ }
+
+ phy-gpio_irq = desc_to_gpio(gpiod_irq);
+
+ /* Configure IRQ GPIO */
+ ret = gpiod_direction_input(gpiod_irq);
+ if (ret) {
+ nfc_err(dev, Fail IRQ pin direction\n);
+ return ret;
+ }
+
+ /* Map the pin to an IRQ */
+ ret = gpiod_to_irq(gpiod_irq);
+ if (ret 0) {
+ nfc_err(dev, Fail pin IRQ mapping\n);
+ return ret;
+ }
and here.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
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 2/7] ath10k: implement chanctx API
On 6 February 2015 at 13:02, Michal Kazior michal.kaz...@tieto.com wrote: The chanctx API will allow ath10k to support multi-channel operation. Signed-off-by: Michal Kazior michal.kaz...@tieto.com [...] I'll post a v4 later including an AP CSA fix for an issue I've introduced in v3. v4 will also make AP CSA work with qca6174. Michał -- 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: NULL pointer dereference in ath_isr+0x27/0x250 [ath9k]
Davide Pesavento wrote: I have no experience in debugging kernel panics, but running gdb on vmlinux seems to point to the test_bit() call in ath_isr, which dereferences the struct ath_common *common pointer. I looked around a bit and noticed that in ath9k/pci.c:ath_pci_probe(), the interrupt handler is registered with request_irq() before invoking ath9k_init_device(), which takes care of allocating the ath_hw structure. Therefore it might happen that an interrupt fires and ath_isr() tries to use the structure before it's allocated. Please try with a recent kernel that contains these fixes IRQ handling: commit 56bdbe0d6ac59c3eb17c2b9d715fb2e41467e354 Author: Felix Fietkau n...@openwrt.org Date: Sun Nov 30 21:58:30 2014 +0100 ath9k: prevent early IRQs from accessing hardware commit ef739ab6aac38b25e473f418ecfe1fb433346fa1 Author: Felix Fietkau n...@openwrt.org Date: Sun Nov 30 21:58:31 2014 +0100 ath9k: set ATH_OP_INVALID before disabling hardware Sujith -- 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: btcoex subsystem
Hi Kalle, I will work on combining the latest BT drivers from Realtek with btusb to see if I can achieve a patch that will both work with the Realtek hardware, and get approval from the reviewers. What would be an approved method of communicating between two kernel modules? Is there some example in the kernel that I could study? We need a btcoex subsystem that both WiFi and Bluetooth can register to and communicate with. The need for this seems to periodically come up, I remember needing something like that back in the Maemo wl1251 days and also ath6kl needed this. Are there any ideas for this subsystem? How would this btcoex subsystem work? What kind of information would it provide? Is this something we should discuss at Ottawa? sadly something came up and I am not making it to Ottawa. However we should be talking about this at some point since Bluetooth has MWS for its coexistence which could be a good starting point. Something we have to look into for the Bluetooth subsystem at some point. Regards Marcel -- 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] mwifiex: DMA alignment for RX packets
This patch adds support for DMA alignment of sk_buffs
allocated for RX.
Patch also adds support to modify skb allocation flags.
Signed-off-by: Marc Yang yangy...@marvell.com
Signed-off-by: Qingshui Gao ga...@marvell.com
Signed-off-by: Cathy Luo c...@marvell.com
Signed-off-by: Avinash Patil pat...@marvell.com
---
drivers/net/wireless/mwifiex/decl.h | 1 +
drivers/net/wireless/mwifiex/main.h | 4
drivers/net/wireless/mwifiex/pcie.c | 6 --
drivers/net/wireless/mwifiex/sdio.c | 5 +++--
drivers/net/wireless/mwifiex/util.c | 23 +++
5 files changed, 35 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/decl.h
b/drivers/net/wireless/mwifiex/decl.h
index b364a2c..e7324da 100644
--- a/drivers/net/wireless/mwifiex/decl.h
+++ b/drivers/net/wireless/mwifiex/decl.h
@@ -33,6 +33,7 @@
#define MWIFIEX_MAX_BSS_NUM (3)
#define MWIFIEX_DMA_ALIGN_SZ 64
+#define MWIFIEX_RX_HEADROOM64
#define MAX_TXPD_SZ32
#define INTF_HDR_ALIGN 4
diff --git a/drivers/net/wireless/mwifiex/main.h
b/drivers/net/wireless/mwifiex/main.h
index 2089a30..16be45e 100644
--- a/drivers/net/wireless/mwifiex/main.h
+++ b/drivers/net/wireless/mwifiex/main.h
@@ -140,6 +140,9 @@ enum {
#define MWIFIEX_DRV_INFO_SIZE_MAX 0x4
+/* Address alignment */
+#define MWIFIEX_ALIGN_ADDR(p, a) (((long)(p) + (a) - 1) ~((a) - 1))
+
struct mwifiex_dbg {
u32 num_cmd_host_to_card_failure;
u32 num_cmd_sleep_cfm_host_to_card_failure;
@@ -1418,6 +1421,7 @@ u8 mwifiex_adjust_data_rate(struct mwifiex_private *priv,
u8 rx_rate, u8 ht_info);
void mwifiex_dump_drv_info(struct mwifiex_adapter *adapter);
+void *mwifiex_alloc_rx_buf(int rx_len, gfp_t flags);
#ifdef CONFIG_DEBUG_FS
void mwifiex_debugfs_init(void);
diff --git a/drivers/net/wireless/mwifiex/pcie.c
b/drivers/net/wireless/mwifiex/pcie.c
index 0640bd6..4b463c3 100644
--- a/drivers/net/wireless/mwifiex/pcie.c
+++ b/drivers/net/wireless/mwifiex/pcie.c
@@ -498,7 +498,8 @@ static int mwifiex_init_rxq_ring(struct mwifiex_adapter
*adapter)
for (i = 0; i MWIFIEX_MAX_TXRX_BD; i++) {
/* Allocate skb here so that firmware can DMA data from it */
- skb = dev_alloc_skb(MWIFIEX_RX_DATA_BUF_SIZE);
+ skb = mwifiex_alloc_rx_buf(MWIFIEX_RX_DATA_BUF_SIZE,
+ GFP_KERNEL | GFP_DMA);
if (!skb) {
dev_err(adapter-dev,
Unable to allocate skb for RX ring.\n);
@@ -1297,7 +1298,8 @@ static int mwifiex_pcie_process_recv_data(struct
mwifiex_adapter *adapter)
}
}
- skb_tmp = dev_alloc_skb(MWIFIEX_RX_DATA_BUF_SIZE);
+ skb_tmp = mwifiex_alloc_rx_buf(MWIFIEX_RX_DATA_BUF_SIZE,
+ GFP_KERNEL | GFP_DMA);
if (!skb_tmp) {
dev_err(adapter-dev,
Unable to allocate skb.\n);
diff --git a/drivers/net/wireless/mwifiex/sdio.c
b/drivers/net/wireless/mwifiex/sdio.c
index 78a9e86..57d85ab 100644
--- a/drivers/net/wireless/mwifiex/sdio.c
+++ b/drivers/net/wireless/mwifiex/sdio.c
@@ -1357,7 +1357,7 @@ static int mwifiex_process_int_status(struct
mwifiex_adapter *adapter)
return -1;
rx_len = (u16) (rx_blocks * MWIFIEX_SDIO_BLOCK_SIZE);
- skb = dev_alloc_skb(rx_len);
+ skb = mwifiex_alloc_rx_buf(rx_len, GFP_KERNEL | GFP_DMA);
if (!skb)
return -1;
@@ -1454,7 +1454,8 @@ static int mwifiex_process_int_status(struct
mwifiex_adapter *adapter)
}
rx_len = (u16) (rx_blocks * MWIFIEX_SDIO_BLOCK_SIZE);
- skb = dev_alloc_skb(rx_len);
+ skb = mwifiex_alloc_rx_buf(rx_len,
+ GFP_KERNEL | GFP_DMA);
if (!skb) {
dev_err(adapter-dev, %s: failed to alloc skb,
diff --git a/drivers/net/wireless/mwifiex/util.c
b/drivers/net/wireless/mwifiex/util.c
index 47e215b..2148a57 100644
--- a/drivers/net/wireless/mwifiex/util.c
+++ b/drivers/net/wireless/mwifiex/util.c
@@ -631,3 +631,26 @@ void mwifiex_hist_data_reset(struct mwifiex_private *priv)
for (ix = 0; ix MWIFIEX_MAX_SIG_STRENGTH; ix++)
atomic_set(phist_data-sig_str[ix], 0);
}
+
+void *mwifiex_alloc_rx_buf(int rx_len, gfp_t flags)
+{
+ struct sk_buff *skb;
+ int buf_len, pad;
+
+ buf_len = rx_len + MWIFIEX_RX_HEADROOM + MWIFIEX_DMA_ALIGN_SZ;
+
+ skb = __dev_alloc_skb(buf_len, flags);
+
+ if (!skb)
+ return NULL;
+
+ skb_reserve(skb, MWIFIEX_RX_HEADROOM);
+
+ pad = MWIFIEX_ALIGN_ADDR(skb-data, MWIFIEX_DMA_ALIGN_SZ) -
+
Re: [PATCH] iwl4965: Enable checking of format strings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/12/15 2:20 AM, Rasmus Villemoes wrote: Rather weak arguments, but I have three of them :-) Yes, weak. All three. (1) If I'm reading some code and spot a non-constant format argument, I sometimes track back to see how e.g. fmt_value is defined. If I then see it's a macro, I immediately think ok, the compiler is doing type-checking. If it is a const char[], I have to remember that gcc also does it in that case (as opposed to for example const char*const). GCC should check in both cases. The case you are replacing was not const char * const, but only const char *. Still, the compiler really should check either form, even though theoretically the pointer in the latter case could be changed, but the initial const value should be a good indication of what the parameters are expected to be. No real reason for the compiler not to check it. (2) The names of these variables themselves may end up wasting a few bytes in the image. Maybe in a debug image, but they should be stripped from any normal image. Really not a factor. (3) gcc/the linker doesn't merge identical const char[] arrays across translation units. It also doesn't consider their tails for merging with string literals. So although these specific strings are unlikely to appear elsewhere, a string such as %10u\n or max\n couldn't be merged with one of the above. I haven't checked, but there is no theoretical reason that const char [] items could not be merged exactly as the literals are. Considering the boundaries the compiler guys push on optimization, doing such merging would be tame by comparison (speculative stores make me crazy). -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJU3a3+AAoJEDwO/+eO4+5unvMP/jwxA4GmwC0d3VdGsVTJkMVd zg+jwbkhnMiaEj6uPAwV5LXV/IGyuYFgNjoiNDg9RD3trV9/3YAxdAKw1ffO+PWe lnmXSxaapLlCTapOsUdXPg88z9muQKrcfhnGyi+jt3BFeccXgtlHLsR0qVa4ddJw KVHByPg+AlTSNzSnROxHH3UAbxEuZmDy+g+xfbEFLCKNCgtrSX5jGyG2vJIY3lhF 40VIdriUHz1QW4C1YYeJWMKwzml7Kln3u0T5MfDEtDfy6n7hiBhHczEgPjf7dnzd aY4+VtKTyjPWLRhyDoJfR9maaV9TsYHpheSuUVzAGwvb85wH32ugdfmcW2RPnRfC n9ThhtWd1WdJJpmq0xhLjc9bc3nrxJO8b2J/GMsT6SjGBhPGaaJSWY37UPhhOJOj akKkA6QwD0u6Yoc3de7unGsiKWayD7e2k3w3bus+kCSspmyn/OnkzZRc0X3nXd20 suAWNZTalLWioqvI/hyvH3GMZxIuHTJoLRpTm+K7BQs7gBM9pD7OJOpn7XLtk2PM zPfEj8fAUMV17lzFdBP+M+pGT3HzjWVwTIUgujdA4vL6eqB1W+3fR7kqjUuQYc69 aBaMde//i+HUPzTHZht2qXEb6K9EvSsz/XlhQrtAyu2gYY8PwchdZXH0NbAGqJ9C 4BEAO4HYJijd4vVSNBFO =utge -END PGP SIGNATURE- -- 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] ath10k: Increase AST table SKID length limit
On 02/12/2015 01:28 AM, SenthilKumar Jegadeesan wrote:
The current SKID length configuration causes firmware
to reject peer creation for not able to allocate
AST entries for peers. This issue is observed when
least significant 3 bytes are used ramdomly to create
client MAC addresses.
AST table SKID length configuration is increased to
maximum value to fix this issue.
If your firmware is like 10.1, then probably AST length should
really be same as config.num_peers?
10.1 firmware definitely has same or similar issue in it's
AST table handling, for what that is worth.
Thanks,
Ben
Signed-off-by: SenthilKumar Jegadeesan sjega...@qti.qualcomm.com
---
drivers/net/wireless/ath/ath10k/hw.h | 1 +
drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/hw.h
b/drivers/net/wireless/ath/ath10k/hw.h
index 460771f..b86996e 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -254,6 +254,7 @@ struct ath10k_pktlog_hdr {
/* 10.2 parameters */
#define TARGET_10_2_DMA_BURST_SIZE1
+#define TARGET_10_2_AST_SKID_LIMIT 128
/* Target specific defines for WMI-TLV firmware */
#define TARGET_TLV_NUM_VDEVS 3
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c
b/drivers/net/wireless/ath/ath10k/wmi.c
index aeea1c7..13290da 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -3920,7 +3920,7 @@ static struct sk_buff *ath10k_wmi_10_2_op_gen_init(struct
ath10k *ar)
config.num_peers = __cpu_to_le32(TARGET_10X_NUM_PEERS);
config.num_peer_keys = __cpu_to_le32(TARGET_10X_NUM_PEER_KEYS);
config.num_tids = __cpu_to_le32(TARGET_10X_NUM_TIDS);
- config.ast_skid_limit = __cpu_to_le32(TARGET_10X_AST_SKID_LIMIT);
+ config.ast_skid_limit = __cpu_to_le32(TARGET_10_2_AST_SKID_LIMIT);
config.tx_chain_mask = __cpu_to_le32(TARGET_10X_TX_CHAIN_MASK);
config.rx_chain_mask = __cpu_to_le32(TARGET_10X_RX_CHAIN_MASK);
config.rx_timeout_pri_vo = __cpu_to_le32(TARGET_10X_RX_TIMEOUT_LO_PRI);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ben Greear gree...@candelatech.com
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
[PATCH] ath10k: fix AP/IBSS CSA with template based fw
qca6174 with wmi-tlv firmware uses offloaded
beaconing scheme (i.e. templates). This requires a
little different approach when implementing CSA.
Add missing code to update CS count and report CSA
completion to mac80211. Without it channel switch
was never finished.
To avoid races during interface teardown data_lock
has been used to protect is_up and is_started so
they can be compared against before scheduling
count down work.
Signed-off-by: Michal Kazior michal.kaz...@tieto.com
---
@Kalle: I'm deferring the chanctx patchset v4
until this gets applied. I'd like to avoid posting
patches without a valid parent id and leaving you
with some weird conflicts and implicit depndencies
in the code to deal with.
drivers/net/wireless/ath/ath10k/core.h| 1 +
drivers/net/wireless/ath/ath10k/mac.c | 70 ++-
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 8
3 files changed, 77 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index d60e46f..43fa2ec 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -320,6 +320,7 @@ struct ath10k_vif {
int num_legacy_stations;
int txpower;
struct wmi_wmm_params_all_arg wmm_params;
+ struct work_struct ap_csa_work;
};
struct ath10k_vif_iter {
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index d6d2f0f..631e73b 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1055,6 +1055,10 @@ static int ath10k_mac_setup_bcn_tmpl(struct ath10k_vif
*arvif)
if (!test_bit(WMI_SERVICE_BEACON_OFFLOAD, ar-wmi.svc_map))
return 0;
+ if (arvif-vdev_type != WMI_VDEV_TYPE_AP
+ arvif-vdev_type != WMI_VDEV_TYPE_IBSS)
+ return 0;
+
bcn = ieee80211_beacon_get_template(hw, vif, offs);
if (!bcn) {
ath10k_warn(ar, failed to get beacon template from
mac80211\n);
@@ -1100,6 +1104,9 @@ static int ath10k_mac_setup_prb_tmpl(struct ath10k_vif
*arvif)
if (!test_bit(WMI_SERVICE_BEACON_OFFLOAD, ar-wmi.svc_map))
return 0;
+ if (arvif-vdev_type != WMI_VDEV_TYPE_AP)
+ return 0;
+
prb = ieee80211_proberesp_get(hw, vif);
if (!prb) {
ath10k_warn(ar, failed to get probe resp template from
mac80211\n);
@@ -1129,10 +1136,9 @@ static void ath10k_control_beaconing(struct ath10k_vif
*arvif,
if (!info-enable_beacon) {
ath10k_vdev_stop(arvif);
+ spin_lock_bh(arvif-ar-data_lock);
arvif-is_started = false;
arvif-is_up = false;
-
- spin_lock_bh(arvif-ar-data_lock);
ath10k_mac_vif_beacon_free(arvif);
spin_unlock_bh(arvif-ar-data_lock);
@@ -1335,6 +1341,49 @@ static int ath10k_mac_vif_disable_keepalive(struct
ath10k_vif *arvif)
return 0;
}
+static void ath10k_mac_vif_ap_csa_count_down(struct ath10k_vif *arvif)
+{
+ struct ath10k *ar = arvif-ar;
+ struct ieee80211_vif *vif = arvif-vif;
+ int ret;
+
+ if (arvif-vdev_type != WMI_VDEV_TYPE_AP)
+ return;
+
+ if (!vif-csa_active)
+ return;
+
+ if (!arvif-is_up)
+ return;
+
+ if (!ieee80211_csa_is_complete(vif)) {
+ ieee80211_csa_update_counter(vif);
+
+ ret = ath10k_mac_setup_bcn_tmpl(arvif);
+ if (ret)
+ ath10k_warn(ar, failed to update bcn tmpl during csa:
%d\n,
+ ret);
+
+ ret = ath10k_mac_setup_prb_tmpl(arvif);
+ if (ret)
+ ath10k_warn(ar, failed to update prb tmpl during csa:
%d\n,
+ ret);
+ } else {
+ ieee80211_csa_finish(vif);
+ }
+}
+
+static void ath10k_mac_vif_ap_csa_work(struct work_struct *work)
+{
+ struct ath10k_vif *arvif = container_of(work, struct ath10k_vif,
+ ap_csa_work);
+ struct ath10k *ar = arvif-ar;
+
+ mutex_lock(ar-conf_mutex);
+ ath10k_mac_vif_ap_csa_count_down(arvif);
+ mutex_unlock(ar-conf_mutex);
+}
+
/**/
/* Station management */
/**/
@@ -1852,7 +1901,9 @@ static void ath10k_bss_assoc(struct ieee80211_hw *hw,
return;
}
+ spin_lock_bh(arvif-ar-data_lock);
arvif-is_up = true;
+ spin_unlock_bh(arvif-ar-data_lock);
}
static void ath10k_bss_disassoc(struct ieee80211_hw *hw,
@@ -1874,7 +1925,9 @@ static void ath10k_bss_disassoc(struct ieee80211_hw *hw,
arvif-def_wep_key_idx = -1;
+ spin_lock_bh(arvif-ar-data_lock);
arvif-is_up = false;
+ spin_unlock_bh(arvif-ar-data_lock);
}
static int
Re: [PATCH] ath10k: Fix interrupt storm
Moreover I'm pretty sure this patch breaks STA 4addr bridging. I'm worried it also breaks other stuff (e.g some IBSS usecases or even some AP usecases) but I don't have time to check this now. Can you please elaborate on this one?. I can review if we can for these cases as well before disabling promiscuous mode. Instead of making the fix specific to some interface type (AP), it will be good to understand the issue with STA and IBSS if we disable promiscuous mode. As you know, it will be uglier if the fix has to be interface specific. 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
[PATCH 1/3] mwifiex: add cfg80211 set_default_mgmt_key handler
From: Xinming Hu h...@marvell.com
It is observed that hostapd failed to setup with management frame
protection mode enabled when using mwifiex.
This is because hostapd will try to install IGTK using
cfg80211 set_default_mgmt_key handler.
we have already support IGTK install in set_key handler, so just work
around this issue by add an empty cfg80211_set_default_mgmt_key handler.
Signed-off-by: Xinming Hu h...@marvell.com
Signed-off-by: Cathy Luo c...@marvell.com
Signed-off-by: Li Long lon...@marvell.com
Signed-off-by: Avinash Patil pat...@marvell.com
---
drivers/net/wireless/mwifiex/cfg80211.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/net/wireless/mwifiex/cfg80211.c
b/drivers/net/wireless/mwifiex/cfg80211.c
index 5f3c1d3..ab7643d 100644
--- a/drivers/net/wireless/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/mwifiex/cfg80211.c
@@ -415,6 +415,18 @@ mwifiex_cfg80211_add_key(struct wiphy *wiphy, struct
net_device *netdev,
}
/*
+ * CFG802.11 operation handler to set default mgmt key.
+ */
+static int
+mwifiex_cfg80211_set_default_mgmt_key(struct wiphy *wiphy,
+ struct net_device *netdev,
+ u8 key_index)
+{
+ wiphy_dbg(wiphy, set default mgmt key, key index=%d\n, key_index);
+ return 0;
+}
+
+/*
* This function sends domain information to the firmware.
*
* The following information are passed to the firmware -
@@ -3280,6 +3292,7 @@ static struct cfg80211_ops mwifiex_cfg80211_ops = {
.leave_ibss = mwifiex_cfg80211_leave_ibss,
.add_key = mwifiex_cfg80211_add_key,
.del_key = mwifiex_cfg80211_del_key,
+ .set_default_mgmt_key = mwifiex_cfg80211_set_default_mgmt_key,
.mgmt_tx = mwifiex_cfg80211_mgmt_tx,
.mgmt_frame_register = mwifiex_cfg80211_mgmt_frame_register,
.remain_on_channel = mwifiex_cfg80211_remain_on_channel,
--
1.8.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
[PATCH 2/3] mwifiex: WMM AC parameter configuration for AP mode
From: Xinming Hu h...@marvell.com
This patch add cfg80211 set_txq_params handler for mwifiex.
This will be used to configure WMM AC parameters in AP mode.
Signed-off-by: Xinming Hu h...@marvell.com
Signed-off-by: Cathy Luo c...@marvell.com
Signed-off-by: Avinash Patil pat...@marvell.com
---
drivers/net/wireless/mwifiex/cfg80211.c| 70 ++
drivers/net/wireless/mwifiex/decl.h| 11 +
drivers/net/wireless/mwifiex/fw.h | 2 +
drivers/net/wireless/mwifiex/ioctl.h | 1 +
drivers/net/wireless/mwifiex/sta_cmdresp.c | 37
drivers/net/wireless/mwifiex/uap_cmd.c | 20 +
drivers/net/wireless/mwifiex/wmm.h | 11 -
7 files changed, 141 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/cfg80211.c
b/drivers/net/wireless/mwifiex/cfg80211.c
index ab7643d..f933159 100644
--- a/drivers/net/wireless/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/mwifiex/cfg80211.c
@@ -1552,6 +1552,75 @@ static int mwifiex_cfg80211_change_beacon(struct wiphy
*wiphy,
return 0;
}
+/* cfg80211 operation handler for set_txq_params.
+ * Function retrieves and sets modified AP WMM params to FW.
+ */
+static int mwifiex_cfg80211_set_txq_params(struct wiphy *wiphy,
+ struct net_device *dev,
+ struct ieee80211_txq_params *params)
+{
+ struct mwifiex_private *priv = mwifiex_netdev_get_priv(dev);
+ struct mwifiex_types_wmm_info *wmm_info;
+ u8 ac;
+
+ if (!priv || !params)
+ return -EINVAL;
+
+ if (GET_BSS_ROLE(priv) != MWIFIEX_BSS_ROLE_UAP) {
+ wiphy_err(wiphy, %s: bss_type mismatched\n, __func__);
+ return -EINVAL;
+ }
+
+ wmm_info = priv-bss_cfg.ap_wmm_params;
+ memset(wmm_info, 0, sizeof(*wmm_info));
+
+ if (mwifiex_send_cmd(priv, HostCmd_CMD_UAP_SYS_CONFIG,
+HostCmd_ACT_GEN_GET,
+UAP_WMM_PARAMS_I, wmm_info, true)) {
+ wiphy_err(wiphy, Failed to Get AP wmm params\n);
+ return -1;
+ }
+
+ switch (params-ac) {
+ case NL80211_AC_VO:
+ ac = 3;
+ break;
+ case NL80211_AC_VI:
+ ac = 2;
+ break;
+ case NL80211_AC_BK:
+ ac = 1;
+ break;
+ case NL80211_AC_BE:
+ ac = 0;
+ break;
+ default:
+ wiphy_err(wiphy, unknown ac in set_txq_params\n);
+ return -EINVAL;
+ }
+
+ wiphy_dbg(wiphy,
+ set_txq_params ac=%d, txop=%d, cw min=%d, max=%d, aifs=%d\n,
+ ac, params-txop, params-cwmin, params-cwmax, params-aifs);
+
+ memset(wmm_info-ac_params[ac], 0, sizeof(wmm_info-ac_params[ac]));
+ wmm_info-ac_params[ac].aci_aifsn_bitmap = params-aifs MWIFIEX_AIFSN;
+ wmm_info-ac_params[ac].ecw_bitmap |= ilog2(params-cwmin + 1)
+ MWIFIEX_ECW_MIN;
+ wmm_info-ac_params[ac].ecw_bitmap |= (ilog2(params-cwmax + 1) 4)
+ MWIFIEX_ECW_MAX;
+ wmm_info-ac_params[ac].tx_op_limit = cpu_to_le16(params-txop);
+
+ if (mwifiex_send_cmd(priv, HostCmd_CMD_UAP_SYS_CONFIG,
+HostCmd_ACT_GEN_SET,
+UAP_WMM_PARAMS_I, wmm_info, false)) {
+ wiphy_err(wiphy, Failed to set AP wmm params\n);
+ return -1;
+ }
+
+ return 0;
+}
+
/* cfg80211 operation handler for del_station.
* Function deauthenticates station which value is provided in mac parameter.
* If mac is NULL/broadcast, all stations in associated station list are
@@ -3304,6 +3373,7 @@ static struct cfg80211_ops mwifiex_cfg80211_ops = {
.start_ap = mwifiex_cfg80211_start_ap,
.stop_ap = mwifiex_cfg80211_stop_ap,
.change_beacon = mwifiex_cfg80211_change_beacon,
+ .set_txq_params = mwifiex_cfg80211_set_txq_params,
.set_cqm_rssi_config = mwifiex_cfg80211_set_cqm_rssi_config,
.set_antenna = mwifiex_cfg80211_set_antenna,
.del_station = mwifiex_cfg80211_del_station,
diff --git a/drivers/net/wireless/mwifiex/decl.h
b/drivers/net/wireless/mwifiex/decl.h
index 88d0ead..0059d6f 100644
--- a/drivers/net/wireless/mwifiex/decl.h
+++ b/drivers/net/wireless/mwifiex/decl.h
@@ -183,6 +183,17 @@ struct mwifiex_txinfo {
u64 cookie;
};
+enum ieee_types_wmm_aciaifsn_bitmasks {
+ MWIFIEX_AIFSN = (BIT(0) | BIT(1) | BIT(2) | BIT(3)),
+ MWIFIEX_ACM = BIT(4),
+ MWIFIEX_ACI = (BIT(5) | BIT(6)),
+};
+
+enum ieee_types_wmm_ecw_bitmasks {
+ MWIFIEX_ECW_MIN = (BIT(0) | BIT(1) | BIT(2) | BIT(3)),
+ MWIFIEX_ECW_MAX = (BIT(4) | BIT(5) | BIT(6) | BIT(7)),
+};
+
enum mwifiex_wmm_ac_e {
WMM_AC_BK,
WMM_AC_BE,
Re: [RFT] ath10k: restart fw on tx-credit timeout
On 02/11/2015 10:55 PM, Michal Kazior wrote: On 11 February 2015 at 23:25, Ben Greear gree...@candelatech.com wrote: On 02/10/2015 09:01 AM, Ben Greear wrote: I've hacked CT firmware to do a flush of all vdevs itself when it detects WMI hang. I don't have a good test bed to reproduce the problem reliably, but I should know after a few days if the flush works at all. If not, then it's a moot point anyway. So, this appears to at least partially work. But, what we notice is that when using multiple station vdevs, the system pretty much becomes useless if we get any significant number of stuck or slow-to-transmit management buffers over WMI. Part of this is because WMI messages are sent when holding rtnl much of the time, I think. Most, if not all, WMI commands are sent while holding conf_mutex. This lock is taken in many situations including when RTNL is held so your observation isn't entirely correct but isn't wrong either. I would guess that an AP with lots of peers associated might have similar problems if peers are not ACKing packets reliably. It's not the ACKing per se. It's whether stations are asleep and unresponsive or not. You could do funny DoS attacks with a single ath9k card (using virtual stations) on ath10k APs now I guess :-) In our lab we have some setups where there should be no power-save at all, but still see this issue. Unlucky (or nefarious) broken-ness in the peer can seem to mostly hang the local system due to the 'not entirely correct' assumption above :) Probably the only useful way to fix this is to make the firmware and driver able to send management frames over the normal transport like every other data packet? Agreed. HTT should've been used for entire traffic, including management frames. The workaround could've been to guarantee to have only 1 wmi-mgmt-tx in-flight but since tx-credits aren't replenished predictably you'll end up with the patch I originally did, i.e. sleep 2*bcn intval and wmi-peer-flush-tids after each unicast mgmt frame to a known station. Even assuming I have the tx-credits replenishment fixed, that work-around would make sending sending mgt frames to many peers very slow when at least a few peers are not answering quickly, right? Any idea what it wasn't written like that to begin with? Beats me. This might be something I can fix in CT firmware..but trying to kick a release out the door, so I think I'll put this off for a bit. Thanks, Ben -- Ben Greear gree...@candelatech.com 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
[PATCH 3/3] mwifiex: add cfg80211 set_mac_acl handler for AP mode
From: Xinming Hu h...@marvell.com
This patch add cfg80211 set_mac_acl handler for AP mode, this handler
will be used by user space application to configure accept/deny mac
address list throgh nl80211/cfg80211.
Signed-off-by: Xinming Hu h...@marvell.com
Signed-off-by: Cathy Luo c...@marvell.com
Signed-off-by: Avinash Patil pat...@marvell.com
---
drivers/net/wireless/mwifiex/cfg80211.c | 61 +
drivers/net/wireless/mwifiex/decl.h | 5 +++
drivers/net/wireless/mwifiex/fw.h | 9 +
drivers/net/wireless/mwifiex/ioctl.h| 6
drivers/net/wireless/mwifiex/uap_cmd.c | 25 ++
5 files changed, 106 insertions(+)
diff --git a/drivers/net/wireless/mwifiex/cfg80211.c
b/drivers/net/wireless/mwifiex/cfg80211.c
index f933159..d1a684a 100644
--- a/drivers/net/wireless/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/mwifiex/cfg80211.c
@@ -1621,6 +1621,64 @@ static int mwifiex_cfg80211_set_txq_params(struct wiphy
*wiphy,
return 0;
}
+/* cfg80211 operation handler for set_mac_acl.
+ * function sets station mac address filter params to FW.
+ */
+static int mwifiex_cfg80211_set_mac_acl(struct wiphy *wiphy,
+ struct net_device *dev,
+ const struct cfg80211_acl_data *params)
+{
+ struct mwifiex_private *priv = mwifiex_netdev_get_priv(dev);
+ struct mwifiex_ds_mac_filter *mac_filter;
+
+ if (!priv || !params)
+ return -EINVAL;
+
+ if (GET_BSS_ROLE(priv) != MWIFIEX_BSS_ROLE_UAP) {
+ wiphy_err(wiphy, %s: bss_type mismatched\n, __func__);
+ return -EINVAL;
+ }
+
+ mac_filter = kzalloc(sizeof(*mac_filter), GFP_KERNEL);
+ if (!mac_filter)
+ return -ENOMEM;
+
+ wiphy_dbg(wiphy, set_mac_acl, n_acl_entries=%d, acl_policy=%d\n,
+ params-n_acl_entries, params-acl_policy);
+
+ mac_filter-mac_count = (params-n_acl_entries =
+MWIFIEX_MAX_MAC_FILTER_NUM) ?
+params-n_acl_entries :
+MWIFIEX_MAX_MAC_FILTER_NUM;
+
+ switch (params-acl_policy) {
+ case NL80211_ACL_POLICY_DENY_UNLESS_LISTED:
+ mac_filter-filter_mode = MWIFIEX_MAC_FILTER_MODE_ALLOW_MAC;
+ break;
+ case NL80211_ACL_POLICY_ACCEPT_UNLESS_LISTED:
+ mac_filter-filter_mode = MWIFIEX_MAC_FILTER_MODE_BLOCK_MAC;
+ break;
+ default:
+ wiphy_err(wiphy, unknown ACL policy\n);
+ kfree(mac_filter);
+ return -EINVAL;
+ }
+
+ memcpy(mac_filter-mac_list, params-mac_addrs,
+ sizeof(struct mac_address) * mac_filter-mac_count);
+
+ if (mwifiex_send_cmd(priv, HostCmd_CMD_UAP_SYS_CONFIG,
+HostCmd_ACT_GEN_SET,
+UAP_MAC_FILTER_I, mac_filter, false)) {
+ wiphy_err(wiphy, Failed to set AP mac acl params\n);
+ kfree(mac_filter);
+ return -1;
+ }
+
+ kfree(mac_filter);
+ return 0;
+}
+
/* cfg80211 operation handler for del_station.
* Function deauthenticates station which value is provided in mac parameter.
* If mac is NULL/broadcast, all stations in associated station list are
@@ -3374,6 +3432,7 @@ static struct cfg80211_ops mwifiex_cfg80211_ops = {
.stop_ap = mwifiex_cfg80211_stop_ap,
.change_beacon = mwifiex_cfg80211_change_beacon,
.set_txq_params = mwifiex_cfg80211_set_txq_params,
+ .set_mac_acl = mwifiex_cfg80211_set_mac_acl,
.set_cqm_rssi_config = mwifiex_cfg80211_set_cqm_rssi_config,
.set_antenna = mwifiex_cfg80211_set_antenna,
.del_station = mwifiex_cfg80211_del_station,
@@ -3487,6 +3546,8 @@ int mwifiex_register_cfg80211(struct mwifiex_adapter
*adapter)
wiphy-cipher_suites = mwifiex_cipher_suites;
wiphy-n_cipher_suites = ARRAY_SIZE(mwifiex_cipher_suites);
+ wiphy-max_acl_mac_addrs = MWIFIEX_MAX_MAC_FILTER_NUM;
+
ether_addr_copy(wiphy-perm_addr, adapter-perm_addr);
wiphy-signal_type = CFG80211_SIGNAL_TYPE_MBM;
wiphy-flags |= WIPHY_FLAG_HAVE_AP_SME |
diff --git a/drivers/net/wireless/mwifiex/decl.h
b/drivers/net/wireless/mwifiex/decl.h
index 0059d6f..b364a2c 100644
--- a/drivers/net/wireless/mwifiex/decl.h
+++ b/drivers/net/wireless/mwifiex/decl.h
@@ -110,6 +110,11 @@
#define MWIFIEX_A_BAND_START_FREQ 5000
+#define MWIFIEX_MAC_FILTER_MODE_DISABLE0
+#define MWIFIEX_MAC_FILTER_MODE_ALLOW_MAC 1
+#define MWIFIEX_MAC_FILTER_MODE_BLOCK_MAC 2
+#define MWIFIEX_MAX_MAC_FILTER_NUM 16
+
enum mwifiex_bss_type {
MWIFIEX_BSS_TYPE_STA = 0,
MWIFIEX_BSS_TYPE_UAP = 1,
diff --git a/drivers/net/wireless/mwifiex/fw.h
b/drivers/net/wireless/mwifiex/fw.h
index 2a38964..408c1eb 100644
---
Re: rtl8192ce kernel panics since 3.17(?)
On 02/12/2015 06:10 AM, Johannes Löthberg wrote: Since sometime around version 3.16 or 3.17 I've been getting a lot of occasional kernel panics related to my wifi driver. My laptop has a Realtek RTL8188CE wireless card and uses the rtl8192ce driver. I have pictures of what I think is two identical kernel panics, a couple of days apart: https://lh4.googleusercontent.com/yjwOnrDmioCwuC8FqIXlKMiBTOXddLyJkWTiInJoX2o=w421-h569-no https://lh3.googleusercontent.com/-xM-1wSsVu4c/VKxDnlkgBbI/Ing/HxtqgHgglHY/w421-h569-no/IMG_20150106_212020.jpg It only seems to happen when I have several days of uptime on my laptop and just use sleep all the time instead of shutting it down. Also I have a picture of a kernel panic that is different from the previous ones: https://lh3.googleusercontent.com/-Hj06Csglpa0/VKrI1al6QbI/Imk/VzhmN-dfSB0/w657-h486-no/IMG_20150105_182236.jpg Not sure how to debug it really, but figured that sending in a report would be worth a shot. What kernel were you running when you made the photos? Use the command 'uname -r'. When I get that information, I can then use the dump trace to determine the locations of the oops. 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: Throughput regression with `tcp: refine TSO autosizing`
On Wed, Feb 11, 2015 at 11:48 PM, Michal Kazior michal.kaz...@tieto.com wrote:
On 11 February 2015 at 09:57, Michal Kazior michal.kaz...@tieto.com wrote:
On 10 February 2015 at 15:19, Johannes Berg johan...@sipsolutions.net
wrote:
On Tue, 2015-02-10 at 11:33 +0100, Michal Kazior wrote:
+ if (msdu-sk) {
+ ewma_add(ar-tx_delay_us,
+ktime_to_ns(ktime_sub(ktime_get(),
skb_cb-stamp)) /
+NSEC_PER_USEC);
+
+ ACCESS_ONCE(msdu-sk-sk_tx_completion_delay_cushion) =
+ (ewma_read(ar-tx_delay_us) *
+msdu-sk-sk_pacing_rate) 20;
+ }
To some extent, every wifi driver is going to have this problem. Perhaps
we should do this in mac80211?
Good point. I was actually thinking about it. I can try cooking a
patch unless you want to do it yourself :-)
I've taken a look into this. The most obvious place to add the
timestamp for each packet would be ieee80211_tx_info (i.e. the
skb-cb[48]). The problem is it's very tight there. Even squeezing 2
bytes (allowing up to 64ms of tx completion delay which I'm worried
I will argue strongly in favor of never allowing more than 4ms packets
to accumulate in the firmware.
won't be enough) will be troublesome. Some drivers already use every
last byte of their allowance on 64bit archs (e.g. ar5523 uses entire
40 bytes of driver_data).
I wonder if it's okay to bump skb-cb to 56 bytes to avoid the cascade
of changes required to implement the tx completion delay accounting?
Michał
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Dave Täht
thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
--
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: rtl8192ce kernel panics since 3.17(?)
On 12/02, Larry Finger wrote: On 02/12/2015 06:10 AM, Johannes Löthberg wrote: Since sometime around version 3.16 or 3.17 I've been getting a lot of occasional kernel panics related to my wifi driver. My laptop has a Realtek RTL8188CE wireless card and uses the rtl8192ce driver. I have pictures of what I think is two identical kernel panics, a couple of days apart: https://lh4.googleusercontent.com/yjwOnrDmioCwuC8FqIXlKMiBTOXddLyJkWTiInJoX2o=w421-h569-no https://lh3.googleusercontent.com/-xM-1wSsVu4c/VKxDnlkgBbI/Ing/HxtqgHgglHY/w421-h569-no/IMG_20150106_212020.jpg It only seems to happen when I have several days of uptime on my laptop and just use sleep all the time instead of shutting it down. Also I have a picture of a kernel panic that is different from the previous ones: https://lh3.googleusercontent.com/-Hj06Csglpa0/VKrI1al6QbI/Imk/VzhmN-dfSB0/w657-h486-no/IMG_20150105_182236.jpg Not sure how to debug it really, but figured that sending in a report would be worth a shot. What kernel were you running when you made the photos? Use the command 'uname -r'. When I get that information, I can then use the dump trace to determine the locations of the oops. Larry For the first photo it was 3.18.3 and for the second one it seems like it should be 3.18.1 from looking at my package manager's log. -- Sincerely, Johannes Löthberg PGP Key ID: 0x50FB9B273A9D0BB5 https://theos.kyriasis.com/~kyrias/ pgpmwQG2V7Hl7.pgp Description: PGP signature
Re: [PATCH v2 2/2] NFC: Add ACPI support for NXP PN544
Hi Uwe,
On Thu, Feb 12, 2015 at 09:14:59AM +0100, Uwe Kleine-König wrote:
On Mon, Jan 26, 2015 at 01:13:37PM +0200, Robert Dolca wrote:
+ /* Get EN GPIO from ACPI */
+ gpiod_en = devm_gpiod_get_index(dev, PN544_GPIO_NAME_EN, 1);
Actually devm_gpiod_get_index takes 4 arguments. In your case you should
also pass GPIOD_OUT_LOW, then you can skip the gpiod_direction_output
part below.
+ if (IS_ERR(gpiod_en)) {
+ nfc_err(dev,
+ Unable to get EN GPIO\n);
+ return -ENODEV;
+ }
+
+ phy-gpio_en = desc_to_gpio(gpiod_en);
Why don't you save a reference to the gpiod instead? Mixing usage of raw
and gpiod might result in surprising results. For example
gpiod_direction_output(gpiod_en, 0);
might actually have the same result as
gpio_direction_output(gpio_en, 1);
if the matching gpio is marked as active low.
+
+ /* Configuration EN GPIO */
+ ret = gpiod_direction_output(gpiod_en, 0);
+ if (ret) {
+ nfc_err(dev, Fail EN pin direction\n);
+ return ret;
+ }
+
+ /* Get FW GPIO from ACPI */
+ gpiod_fw = devm_gpiod_get_index(dev, PN544_GPIO_NAME_FW, 2);
+ if (IS_ERR(gpiod_fw)) {
+ nfc_err(dev,
+ Unable to get FW GPIO\n);
+ return -ENODEV;
+ }
+
+ phy-gpio_fw = desc_to_gpio(gpiod_fw);
+
+ /* Configuration FW GPIO */
+ ret = gpiod_direction_output(gpiod_fw, 0);
+ if (ret) {
+ nfc_err(dev, Fail FW pin direction\n);
+ return ret;
+ }
The same comments apply here.
+
+ /* Get IRQ GPIO */
+ gpiod_irq = devm_gpiod_get_index(dev, PN544_GPIO_NAME_IRQ, 0);
+ if (IS_ERR(gpiod_irq)) {
+ nfc_err(dev,
+ Unable to get IRQ GPIO\n);
+ return -ENODEV;
+ }
+
+ phy-gpio_irq = desc_to_gpio(gpiod_irq);
+
+ /* Configure IRQ GPIO */
+ ret = gpiod_direction_input(gpiod_irq);
+ if (ret) {
+ nfc_err(dev, Fail IRQ pin direction\n);
+ return ret;
+ }
+
+ /* Map the pin to an IRQ */
+ ret = gpiod_to_irq(gpiod_irq);
+ if (ret 0) {
+ nfc_err(dev, Fail pin IRQ mapping\n);
+ return ret;
+ }
and here.
I didn't use gpiod_* functions because the existing enumeration method for
platform init and device tree was using gpio_* functions.
Also as far as I know the device tree implementation will not give you the
gpiod data structure. It gives you only the gpio index.
Keeping both gpiod and gpio depending on the enumeration method is unscallable
so I didn't choose that.
Regards,
Robert
--
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
