Re: [PATCH v2 00/10] rt2x00: rt2x00: improve calling conventions for register accessors
On Fri, May 19, 2017 at 8:44 AM, Tom Psyborg wrote: > warning: 'rt2800_bbp_read' used but never defined > static u8 rt2800_bbp_read(struct rt2x00_dev *rt2x00dev, >^ > /home/ubuntu/Music/openwrt/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7620/compat-wireless-2016-05-12/drivers/net/wireless/ralink/rt2x00/rt2800lib.h:262:13: > warning: 'rt2800_bbp_write' used but never defined > static void rt2800_bbp_write(struct rt2x00_dev *rt2x00dev, > ^ > CC [M] > /home/ubuntu/Music/openwrt/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7620/compat-wireless-2016-05-12/drivers/net/wireless/ralink/rt2x00/rt2800pci.o > In file included from > /home/ubuntu/Music/openwrt/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7620/compat-wireless-2016-05-12/drivers/net/wireless/ralink/rt2x00/rt2800pci.c:43:0: > /home/ubuntu/Music/openwrt/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7620/compat-wireless-2016-05-12/drivers/net/wireless/ralink/rt2x00/rt2800lib.h:259:11: > warning: 'rt2800_bbp_read' declared 'static' but never defined > [-Wunused-function] > static u8 rt2800_bbp_read(struct rt2x00_dev *rt2x00dev, >^ On which base version did you apply my patches? There may be a conflict against patches that are in your tree but not yet in linux-next, as I don't see the warning and also see no reference to rt2800_bbp_read in rt2800lib.h Arnd
Re: [PATCH v2 00/10] rt2x00: rt2x00: improve calling conventions for register accessors
On Fri, May 19, 2017 at 7:18 AM, Kalle Valo wrote:
> Arnd Bergmann writes:
>
>> I've managed to split up my long patch into a series of reasonble
>> steps now.
>>
>> The first two are required to fix a regression from commit 41977e86c984
>> ("rt2x00: add support for MT7620"), the rest are just cleanups to
>> have a consistent state across all the register access functions.
>
> Can these all go to 4.13 or would you prefer me to push the first two
> 4.12? Or what?
I think you can reasonably argue either way: the second patch does
fix a real bug that may or may not lead to an exploitable stack overflow
when CONFIG_KASAN is enabled, which would be a reason to put it
into 4.12. On the other hand, I have another 20 patches for similar
(or worse) stack overflow issues with KASAN that I'm hoping to all
get into 4.13 and backported into stable kernel later if necessary,
so we could treat this one like the others.
The only difference between this and the others is that in rt2x00 it
is a regression against 4.11, while the others have all been present
for a long time.
Arnd
Re: Make BCMA a menuconfig to ease disabling it all
Vincent Legoll wrote: > No need to get into the submenu to disable all BCMA-related config entries > > Signed-off-by: Vincent Legoll I would like to get an ack from someone before I'll apply this. Patch set to Deferred. -- https://patchwork.kernel.org/patch/9683685/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: mwifiex: add missing USB-descriptor endianness conversion
Johan Hovold wrote: > Add the missing endianness conversions to a debug statement printing > the USB device-descriptor bcdUSB field during probe. > > Signed-off-by: Johan Hovold Patch applied to wireless-drivers-next.git, thanks. a1ad7198202f mwifiex: add missing USB-descriptor endianness conversion -- https://patchwork.kernel.org/patch/9723847/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [01/11] mwifiex: fixup error cases in mwifiex_add_virtual_intf()
Brian Norris wrote:
> If we fail to add an interface in mwifiex_add_virtual_intf(), we might
> hit a BUG_ON() in the networking code, because we didn't tear things
> down properly. Among the problems:
>
> (a) when failing to allocate workqueues, we fail to unregister the
> netdev before calling free_netdev()
> (b) even if we do try to unregister the netdev, we're still holding the
> rtnl lock, so the device never properly unregistered; we'll be at
> state NETREG_UNREGISTERING, and then hit free_netdev()'s:
> BUG_ON(dev->reg_state != NETREG_UNREGISTERED);
> (c) we're allocating some dependent resources (e.g., DFS workqueues)
> after we've registered the interface; this may or may not cause
> problems, but it's good practice to allocate these before registering
> (d) we're not even trying to unwind anything when mwifiex_send_cmd() or
> mwifiex_sta_init_cmd() fail
>
> To fix these issues, let's:
>
> * add a stacked set of error handling labels, to keep error handling
>consistent and properly ordered (resolving (a) and (d))
> * move the workqueue allocations before the registration (to resolve
>(c); also resolves (b) by avoiding error cases where we have to
>unregister)
>
> [Incidentally, it's pretty easy to interrupt the alloc_workqueue() in,
> e.g., the following:
>
> iw phy phy0 interface add mlan0 type station
>
> by sending it SIGTERM.]
>
> This bugfix covers commits like commit 7d652034d1a0 ("mwifiex: channel
> switch support for mwifiex"), but parts of this bug exist all the way
> back to the introduction of dynamic interface handling in commit
> 93a1df48d224 ("mwifiex: add cfg80211 handlers add/del_virtual_intf").
>
> Cc:
> Signed-off-by: Brian Norris
11 patches applied to wireless-drivers-next.git, thanks.
8535107aa4ef mwifiex: fixup error cases in mwifiex_add_virtual_intf()
e0b636e5ee15 mwifiex: Don't release tx_ba_stream_tbl_lock while iterating
90ad0be83676 mwifiex: Don't release cmd_pending_q_lock while iterating
09bdb6500551 mwifiex: Add locking to mwifiex_11n_delba
0f13acf0c612 mwifiex: don't drop lock between list-retrieval / list-deletion
6eb2d002d4ea mwifiex: don't leak stashed beacon buffer on reset
bc69ca391eff mwifiex: remove useless 'mwifiex_lock'
7170862738dc mwifiex: remove redundant 'adapter' check in
mwifiex_adapter_cleanup
7ade530e7384 mwifiex: 11h: drop unnecessary check for '!priv'
fa4651e12ae8 mwifiex: pcie: remove useless pdev check
68efd0386988 mwifiex: pcie: stop setting/clearing 'surprise_removed'
--
https://patchwork.kernel.org/patch/9724599/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [v2] mwifiex: pcie: de-duplicate buffer allocation code
Brian Norris wrote: > This code was duplicated as part of the PCIe FLR code added to this > driver. Let's de-duplicate it to: > > * make things easier to read (mwifiex_pcie_free_buffers() now has a >corresponding mwifiex_pcie_alloc_buffers()) > * reduce likelihood of bugs > * make error logging equally verbose > * save lines of code! > > Also drop some of the commentary that isn't really needed. > > Signed-off-by: Brian Norris Patch applied to wireless-drivers-next.git, thanks. d41bf5c1c0ed mwifiex: pcie: de-duplicate buffer allocation code -- https://patchwork.kernel.org/patch/9734777/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: crash in r8723bs
On 19.05.2017 00:50, Ian W MORRISON wrote: > On 19 May 2017 at 05:03, Larry Finger wrote: >> On 05/17/2017 10:05 AM, Stefan Assmann wrote: >>> >>> Hi Larry, >>> >>> the rtl8723bs made it into staging, awesome. >>> I built a kernel to test it but it goes down the drain pretty quickly >>> on modprobe. Going forward who should I discuss bugs with? >>> >>> Here's what's going on atm. >>> >>>Stefan >>> > >>> [ 125.485622] CPU: 1 PID: 456 Comm: modprobe Tainted: G C >>> 4.12.0-rc1+ #1 > > If the kernel is built from v4.12-rc1 then you need to add > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?h=staging-linus&id=ca6e8cdbe1865caf7b05483e1a242e72d9bc919f Thanks Ian, that works. Stefan
Re: [PATCH v2 00/10] rt2x00: rt2x00: improve calling conventions for register accessors
Arnd Bergmann writes:
> I've managed to split up my long patch into a series of reasonble
> steps now.
>
> The first two are required to fix a regression from commit 41977e86c984
> ("rt2x00: add support for MT7620"), the rest are just cleanups to
> have a consistent state across all the register access functions.
Can these all go to 4.13 or would you prefer me to push the first two
4.12? Or what?
--
Kalle Valo
Re: [V3, 5/9] brcmfmac: add firmware feature detection for gscan feature
Arend Van Spriel writes: > On 18-5-2017 17:47, Kalle Valo wrote: >> Kalle Valo writes: >> >>> Arend Van Spriel wrote: From: Arend van Spriel Detect gscan support in firmware by doing pfn_gscan_cfg iovar with invalid version. Reviewed-by: Hante Meuleman Reviewed-by: Pieter-Paul Giesberts Reviewed-by: Franky Lin Signed-off-by: Arend van Spriel >>> >>> Failed to apply: >>> >>> fatal: sha1 information is lacking or useless >>> (drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c). >>> error: could not build fake ancestor >>> Applying: brcmfmac: add support multi-scheduled scan >>> Patch failed at 0001 brcmfmac: add support multi-scheduled scan >>> The copy of the patch that failed is found in: .git/rebase-apply/patch >>> >>> 5 patches set to Changes Requested. >>> >>> 9692541 [V3,5/9] brcmfmac: add firmware feature detection for gscan feature >>> 9692537 [V3,6/9] brcmfmac: move scheduled scan wiphy param setting to pno >>> module >>> 9692543 [V3,7/9] brcmfmac: add support multi-scheduled scan >>> 9692535 [V3,8/9] brcmfmac: add mutex to protect pno requests >>> 9692539 [V3,9/9] brcmfmac: add scheduled scan support for specified BSSIDs >> >> Actually I made a mistake and forgot to manually remove patches 5 and 6 >> from the tree after the conflict (I haven't automated that part yet in >> my script). So these are now applied: >> >> 9fe929aaace6 brcmfmac: add firmware feature detection for gscan feature >> 94ed6ffb7965 brcmfmac: move scheduled scan wiphy param setting to pno module >> >> Please resend patches 7-9 and double check that the tree looks ok :) > > Will do. These patches were in same series as cfg80211 changes and all > based on mac80211-next/master. I already mentioned to you and Johannes > in earlier version of the patch series (posted April 7) that this would > result in a merge conflict, but I can imagine that info got lost after > more than a month. Ah, I remember now. But yeah, too many emails so I tend to forget so old discussions while looking at patches. -- Kalle Valo
Re: [PATCH v2 4/5] wil6210: add option to ignore OTA regulatory hints
Maya Erez writes:
> On some platforms, the regulatory domain (country) is set
> using mechanisms external to WIFI, such as cellular modem
> and GPS. In these scenarios the regulatory hints that
> are received over the air (in beacons and similar) can
> conflict and even cause an incorrect country to be set.
> Add an option to ignore the OTA regulatory hints to better
> support such scenarios.
>
> Signed-off-by: Lior David
> Signed-off-by: Maya Erez
> ---
> drivers/net/wireless/ath/wil6210/cfg80211.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/wil6210/cfg80211.c
> b/drivers/net/wireless/ath/wil6210/cfg80211.c
> index 567fe43..0f297c0 100644
> --- a/drivers/net/wireless/ath/wil6210/cfg80211.c
> +++ b/drivers/net/wireless/ath/wil6210/cfg80211.c
> @@ -26,6 +26,11 @@
> module_param(disable_ap_sme, bool, 0444);
> MODULE_PARM_DESC(disable_ap_sme, " let user space handle AP mode SME");
>
> +static bool ignore_reg_hints;
> +module_param(ignore_reg_hints, bool, 0444);
> +MODULE_PARM_DESC(ignore_reg_hints,
> + " Ignore OTA regulatory hints (Default: false)");
> +
> #define CHAN60G(_channel, _flags) { \
> .band = NL80211_BAND_60GHZ, \
> .center_freq= 56160 + (2160 * (_channel)), \
> @@ -1763,6 +1768,11 @@ static void wil_wiphy_init(struct wiphy *wiphy)
>
> wiphy->n_vendor_commands = ARRAY_SIZE(wil_nl80211_vendor_commands);
> wiphy->vendor_commands = wil_nl80211_vendor_commands;
> +
> + if (ignore_reg_hints) {
> + wiphy->regulatory_flags |= REGULATORY_DISABLE_BEACON_HINTS;
> + wiphy->regulatory_flags |= REGULATORY_COUNTRY_IE_IGNORE;
> + }
I wonder should something like this be in cfg80211? Because I doubt
wil6210 is the only driver having this problem.
--
Kalle Valo
Re: [PATCH] brcmfmac: remove setting IBSS mode when stopping AP
Wright Feng writes:
> From: Chi-hsien Lin
>
> Setting IBSS mode when stopping AP may affect functionality of INFRA
> mode on another interface. For instance, if user creates and stops
> hostap daemon on virtual interface, then association cannot work on
> primary interface because default BSS has been set to IBSS mode in
> firmware side. The IBSS mode should be set when cfg80211 changes the
> interface.
>
> Reviewed-by: Wright Feng
> Signed-off-by: Chi-hsien Lin
> Signed-off-by: Wright Feng
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> index 944b83c..ce2a5b6 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -4658,9 +4658,6 @@ static int brcmf_cfg80211_stop_ap(struct wiphy *wiphy,
> struct net_device *ndev)
> err = brcmf_fil_cmd_int_set(ifp, BRCMF_C_SET_AP, 0);
> if (err < 0)
> brcmf_err("setting AP mode failed %d\n", err);
> - err = brcmf_fil_cmd_int_set(ifp, BRCMF_C_SET_INFRA, 0);
> - if (err < 0)
> - brcmf_err("setting INFRA mode failed %d\n", err);
The title talks about setting IBSS mode but the code looks to be about
setting INFRA mode. Is this correct?
--
Kalle Valo
Re: [PATCH 1/1] dt-binding: net: wireless: fix node name in the BCM43xx example
On Mon, May 15, 2017 at 10:13:56PM +0200, Martin Blumenstingl wrote: > The example in the BCM43xx documentation uses "brcmf" as node name. > However, wireless devices should be named "wifi" instead. Fix this to > make sure that .dts authors can simply use the documentation as > reference (or simply copy the node from the documentation and then > adjust only the board specific bits). > > Signed-off-by: Martin Blumenstingl > --- > Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied. Rob
[PATCH 00/29] Standardize doc formats - part 3
Each document under Documentation/*.txt has its own format. Some follow markup notations, some don't even have a title! In order to try to get some order on it, change the document style to the standard we're adopting after the adoption of ReStructured Text. The documents touched on this series now build fine with Sphinx, if renamed to *.rst extension. The main goal with this is to teach people by example about what format is expected on newer documents. It also helps to add those files to Kernel books. In order to make things more palatable, I'm spliting the conversion into three parts. This is part 3. Mauro Carvalho Chehab (29): pinctrl.txt: standardize document format pnp.txt: standardize document format preempt-locking.txt: standardize document format printk-formats.txt: standardize document format pwm.txt: standardize document format rbtree.txt: standardize document format remoteproc.txt: standardize document format rfkill.txt: standardize document format robust-futex-ABI.txt: standardize document format robust-futexes.txt: standardize document format rpmsg.txt: standardize document format rtc.txt: standardize document format SAK.txt: standardize document format sgi-ioc4.txt: standardize document format siphash.txt: standardize document format SM501.txt: standardize document format smsc_ece1099.txt: standardize document format static-keys.txt: standardize document format svga.txt: standardize document format sync_file.txt: standardize document format this_cpu_ops.txt: standardize document format unaligned-memory-access.txt: standardize document format vfio-mediated-device.txt: standardize document format vfio.txt: standardize document format video-output.txt: standardize document format xillybus.txt: standardize document format xz.txt: standardize document format zorro.txt: standardize document format dell_rbu.txt: standardize document format Documentation/SAK.txt | 65 +- Documentation/SM501.txt |9 +- Documentation/dell_rbu.txt| 81 ++- Documentation/pinctrl.txt | 1104 +++-- Documentation/pnp.txt | 343 + Documentation/preempt-locking.txt | 40 +- Documentation/printk-formats.txt | 416 ++- Documentation/pwm.txt | 46 +- Documentation/rbtree.txt | 88 +-- Documentation/remoteproc.txt | 320 + Documentation/rfkill.txt | 47 +- Documentation/robust-futex-ABI.txt| 14 +- Documentation/robust-futexes.txt | 12 +- Documentation/rpmsg.txt | 340 + Documentation/rtc.txt | 44 +- Documentation/sgi-ioc4.txt|4 + Documentation/siphash.txt | 186 ++--- Documentation/smsc_ece1099.txt|4 + Documentation/static-keys.txt | 199 +++--- Documentation/svga.txt| 146 ++-- Documentation/sync_file.txt | 23 +- Documentation/this_cpu_ops.txt| 49 +- Documentation/unaligned-memory-access.txt | 57 +- Documentation/vfio-mediated-device.txt| 252 +++ Documentation/vfio.txt| 261 +++ Documentation/video-output.txt| 54 +- Documentation/xillybus.txt| 29 +- Documentation/xz.txt | 182 ++--- Documentation/zorro.txt | 59 +- 29 files changed, 2437 insertions(+), 2037 deletions(-) -- 2.9.4
[PATCH 08/29] rfkill.txt: standardize document format
Each text file under Documentation follows a different format. Some doesn't even have titles! Change its representation to follow the adopted standard, using ReST markups for it to be parseable by Sphinx: - mark titles; - comment contents index; - mark literal blocks; - adjust identation. Signed-off-by: Mauro Carvalho Chehab --- Documentation/rfkill.txt | 47 ++- 1 file changed, 30 insertions(+), 17 deletions(-) diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt index 8c174063b3f0..d22feccedbd1 100644 --- a/Documentation/rfkill.txt +++ b/Documentation/rfkill.txt @@ -1,13 +1,17 @@ +=== rfkill - RF kill switch support === -1. Introduction -2. Implementation details -3. Kernel API -4. Userspace support +.. CONTENTS + 1. Introduction + 2. Implementation details + 3. Kernel API + 4. Userspace support -1. Introduction + +Introduction + The rfkill subsystem provides a generic interface to disabling any radio transmitter in the system. When a transmitter is blocked, it shall not @@ -21,17 +25,24 @@ aircraft. The rfkill subsystem has a concept of "hard" and "soft" block, which differ little in their meaning (block == transmitters off) but rather in whether they can be changed or not: - - hard block: read-only radio block that cannot be overridden by software - - soft block: writable radio block (need not be readable) that is set by - the system software. + + - hard block + read-only radio block that cannot be overridden by software + + - soft block + writable radio block (need not be readable) that is set by +the system software. The rfkill subsystem has two parameters, rfkill.default_state and -rfkill.master_switch_mode, which are documented in admin-guide/kernel-parameters.rst. +rfkill.master_switch_mode, which are documented in +admin-guide/kernel-parameters.rst. -2. Implementation details +Implementation details +== The rfkill subsystem is composed of three main components: + * the rfkill core, * the deprecated rfkill-input module (an input layer handler, being replaced by userspace policy code) and @@ -55,7 +66,8 @@ use the return value of rfkill_set_hw_state() unless the hardware actually keeps track of soft and hard block separately. -3. Kernel API +Kernel API +== Drivers for radio transmitters normally implement an rfkill driver. @@ -69,7 +81,7 @@ For some platforms, it is possible that the hardware state changes during suspend/hibernation, in which case it will be necessary to update the rfkill core with the current state is at resume time. -To create an rfkill driver, driver's Kconfig needs to have +To create an rfkill driver, driver's Kconfig needs to have:: depends on RFKILL || !RFKILL @@ -87,7 +99,8 @@ RFKill provides per-switch LED triggers, which can be used to drive LEDs according to the switch state (LED_FULL when blocked, LED_OFF otherwise). -5. Userspace support +Userspace support += The recommended userspace interface to use is /dev/rfkill, which is a misc character device that allows userspace to obtain and set the state of rfkill @@ -112,11 +125,11 @@ rfkill core framework. Additionally, each rfkill device is registered in sysfs and emits uevents. rfkill devices issue uevents (with an action of "change"), with the following -environment variables set: +environment variables set:: -RFKILL_NAME -RFKILL_STATE -RFKILL_TYPE + RFKILL_NAME + RFKILL_STATE + RFKILL_TYPE The contents of these variables corresponds to the "name", "state" and "type" sysfs files explained above. -- 2.9.4
Re: crash in r8723bs
On 19 May 2017 at 05:03, Larry Finger wrote: > On 05/17/2017 10:05 AM, Stefan Assmann wrote: >> >> Hi Larry, >> >> the rtl8723bs made it into staging, awesome. >> I built a kernel to test it but it goes down the drain pretty quickly >> on modprobe. Going forward who should I discuss bugs with? >> >> Here's what's going on atm. >> >>Stefan >> >> [ 125.485622] CPU: 1 PID: 456 Comm: modprobe Tainted: G C >> 4.12.0-rc1+ #1 If the kernel is built from v4.12-rc1 then you need to add https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?h=staging-linus&id=ca6e8cdbe1865caf7b05483e1a242e72d9bc919f Regards, Ian
Re: [PATCH v6] qtnfmac: introduce new FullMAC driver for Quantenna chipsets
Hello Johannes,
On Wed, May 17, 2017 at 03:12:33PM +0200, Johannes Berg wrote:
> Good job :)
>
> Let's merge this - the tiny fixes for things I found can come later.
>
> Some (mostly trivial) comments:
>
> * I'm surprised you don't support WEP - nice :)
> * I don't think returning -EFAULT from qtnf_add_virtual_intf is a good
>idea - perhaps better propagate the error or use -EIO?
> * the forward declaration of struct bus in pearl/pcie_bus_priv.h seems
> unnecessary
> * you might want to use a whitelist in qtnf_set_wiphy_params(), but
>it's not really important as we should add capability bits for
>everything that we add
> * qtnf_mgmt_frame_register()/cfg80211_rx_mgmt() aren't used correctly
>- since there's filtering further than the frame type/subtype, you
>need to check the return value of cfg80211_rx_mgmt(). If, for
>example, userspace only registers for a certain action frame
>category, you need to still reject the remaining ones yourself. We
>could extend the API here to give you the whole filter data as well,
>if that helps. Otherwise you need to handle the return value from
>cfg80211_rx_mgmt().
> * The ENOENT handling in qtnf_dump_station() surprises me, especially
>since there's no checking that this doesn't result in duplicate
>cfg80211_del_sta() calls due to races - if
>qtnf_event_handle_sta_deauth() wins to remove it with
>qtnf_sta_list_del() but qtnf_dump_station() already had it looked
>up? Seems like the whole handling in that function either needs to
>be the same as in the event, or just be removed and return -ENOENT
> * There seems to be little point in dynamically allocating the
>iface_comb in qtnf_wiphy_register() vs. just embedding it in struct
>qtnf_wmac or so?
> * qtnf_rx_frame() is declared but not used?
> * -D__CHECK_ENDIAN was always wrong, it should be -D__CHECK_ENDIAN__,
>but it's now also enabled by default so can be removed
> * I'm not sure there's much point in printing the failure code address
>(which should be static) in pr_err("skb DMA mapping error: %pad\n",
>&skb_paddr);
> * I like the real use of NAPI :)
> * However, is there any specific reason you're not using
>napi_gro_receive() rather than netif_receive_skb()? It seems using
>GRO would help TCP streams, in particular by reducing the number of
>ACKs
Thanks for the review ! Fixes will be queued to the upcoming patches with
various cleanups as well as new features.
> * with just a single (PCI-E) transport, I'm not sure I see much point
>in splitting it into a separate module, which necessitates the
>EXPORT_SYMBOL_GPL, which do take up a bit of space. But there are
>only 4, so it doesn't really matter :) One thing we did in iwlwifi
>was to not export if both are built-in, since nobody else should
>ever have any reason to access them.
The split was implementened in order to accommodate various bus drivers
supporting different hardware. We already have initial implementation of
another PCIe bus driver for previous generation SoC. That hardware is
different enough to justify a separate bus driver.
BTW, speaking about other backends... During previous reviews of this
patch we had a question regarding possible support of another previous
generation SoC connected to host CPU via RGMII interface. Is there any
legitimate (aka 'upstreamable') way to support such wireless cards ?
Thanks,
Sergey
Re: [V3, 5/9] brcmfmac: add firmware feature detection for gscan feature
On 18-5-2017 17:47, Kalle Valo wrote: > Kalle Valo writes: > >> Arend Van Spriel wrote: >>> From: Arend van Spriel >>> >>> Detect gscan support in firmware by doing pfn_gscan_cfg iovar with >>> invalid version. >>> >>> Reviewed-by: Hante Meuleman >>> Reviewed-by: Pieter-Paul Giesberts >>> Reviewed-by: Franky Lin >>> Signed-off-by: Arend van Spriel >> >> Failed to apply: >> >> fatal: sha1 information is lacking or useless >> (drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c). >> error: could not build fake ancestor >> Applying: brcmfmac: add support multi-scheduled scan >> Patch failed at 0001 brcmfmac: add support multi-scheduled scan >> The copy of the patch that failed is found in: .git/rebase-apply/patch >> >> 5 patches set to Changes Requested. >> >> 9692541 [V3,5/9] brcmfmac: add firmware feature detection for gscan feature >> 9692537 [V3,6/9] brcmfmac: move scheduled scan wiphy param setting to pno >> module >> 9692543 [V3,7/9] brcmfmac: add support multi-scheduled scan >> 9692535 [V3,8/9] brcmfmac: add mutex to protect pno requests >> 9692539 [V3,9/9] brcmfmac: add scheduled scan support for specified BSSIDs > > Actually I made a mistake and forgot to manually remove patches 5 and 6 > from the tree after the conflict (I haven't automated that part yet in > my script). So these are now applied: > > 9fe929aaace6 brcmfmac: add firmware feature detection for gscan feature > 94ed6ffb7965 brcmfmac: move scheduled scan wiphy param setting to pno module > > Please resend patches 7-9 and double check that the tree looks ok :) Will do. These patches were in same series as cfg80211 changes and all based on mac80211-next/master. I already mentioned to you and Johannes in earlier version of the patch series (posted April 7) that this would result in a merge conflict, but I can imagine that info got lost after more than a month. Regards, Arend
Re: crash in r8723bs
On 05/17/2017 10:05 AM, Stefan Assmann wrote: Hi Larry, the rtl8723bs made it into staging, awesome. I built a kernel to test it but it goes down the drain pretty quickly on modprobe. Going forward who should I discuss bugs with? Here's what's going on atm. Stefan [ 125.244195] r8723bs: module is from the staging directory, the quality is unknown, you have been warned. [ 125.262538] RTL8723BS: module init start [ 125.269377] RTL8723BS: rtl8723bs v4.3.5.5_12290.20140916_BTCOEX20140507-4E40 [ 125.275955] RTL8723BS: rtl8723bs BT-Coex version = BTCOEX20140507-4E40 [ 125.350236] pnetdev = e421c800 [ 125.444211] RTL8723BS: rtw_ndev_init(wlan0) [ 125.451896] [ cut here ] [ 125.459543] kernel BUG at net/wireless/core.h:111! [ 125.466098] invalid opcode: [#1] SMP [ 125.472524] Modules linked in: r8723bs(C+) cfg80211 rfkill hid_logitech_hidpp mmc_block crc32c_intel hid_logitech_dj i2c_hid sdhci_acpi sdhci mmc_core [ 125.485622] CPU: 1 PID: 456 Comm: modprobe Tainted: G C 4.12.0-rc1+ #1 [ 125.492260] Hardware name: AXDIA International GmbH Wintab Gen 8/Type2 - Board Product Name, BIOS AD890.1.02.022 09/25/2014 [ 125.505696] task: f5b46480 task.stack: e4724000 [ 125.512515] EIP: cfg80211_netdev_notifier_call+0x4f0/0x6b0 [cfg80211] [ 125.519329] EFLAGS: 00010246 CPU: 1 [ 125.526049] EAX: EBX: f5a88400 ECX: e4725ce8 EDX: 0010 [ 125.532748] ESI: EDI: ffed EBP: e4725c94 ESP: e4725bcc [ 125.539356] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 125.545890] CR0: 80050033 CR2: b7648a70 CR3: 24111000 CR4: 001006d0 [ 125.552462] Call Trace: [ 125.558947] ? smp_apic_timer_interrupt+0x38/0x50 [ 125.565407] ? ida_get_new_above+0xdd/0x2c0 [ 125.571792] ? inetdev_event+0x33/0x4e0 [ 125.578163] notifier_call_chain+0x4e/0x70 [ 125.584546] raw_notifier_call_chain+0x11/0x20 [ 125.590908] call_netdevice_notifiers_info+0x2a/0x60 [ 125.597268] register_netdevice+0x213/0x4d0 [ 125.603564] register_netdev+0x17/0x30 [ 125.609807] rtw_drv_register_netdev+0x5a/0x90 [r8723bs] [ 125.616013] rtw_drv_init+0x1e8/0x220 [r8723bs] [ 125.622122] sdio_bus_probe+0xe0/0x100 [mmc_core] [ 125.628166] driver_probe_device+0x249/0x430 [ 125.634174] __driver_attach+0xd9/0xe0 [ 125.640086] ? unbind_store+0x100/0x100 [ 125.645894] ? driver_probe_device+0x430/0x430 [ 125.651662] bus_for_each_dev+0x57/0xa0 [ 125.657354] driver_attach+0x19/0x20 [ 125.662972] ? driver_probe_device+0x430/0x430 [ 125.668553] bus_add_driver+0x15f/0x250 [ 125.674041] ? 0xf7f7f000 [ 125.679435] driver_register+0x56/0xd0 [ 125.684795] ? 0xf7f7f000 [ 125.690097] sdio_register_driver+0x1b/0x20 [mmc_core] [ 125.695440] rtw_drv_entry+0x52/0x1000 [r8723bs] [ 125.700729] do_one_initcall+0x46/0x170 [ 125.705981] ? kvfree+0x45/0x50 [ 125.711172] ? kmem_cache_alloc_trace+0x155/0x1c0 [ 125.716317] ? do_init_module+0x21/0x1c7 [ 125.721414] ? do_init_module+0x21/0x1c7 [ 125.726431] do_init_module+0x50/0x1c7 [ 125.731411] load_module+0x2170/0x2780 [ 125.736349] ? kernel_read_file+0x28f/0x2c0 [ 125.741262] SyS_finit_module+0xa7/0xe0 [ 125.746217] do_fast_syscall_32+0x6c/0x130 [ 125.751535] entry_SYSENTER_32+0x4e/0x7c [ 125.756495] EIP: 0xb77d8cc9 [ 125.761445] EFLAGS: 0246 CPU: 1 [ 125.766417] EAX: ffda EBX: 0006 ECX: 800459da EDX: [ 125.771486] ESI: 81c08f60 EDI: 81c094e8 EBP: 81c081d8 ESP: bfaf1b4c [ 125.776599] DS: 007b ES: 007b FS: GS: 0033 SS: 007b [ 125.781752] Code: ff b9 01 00 00 00 ba 03 00 00 00 83 a8 a4 fe ff ff 01 6a 00 2d 58 01 00 00 e8 4d 1e 5d d5 58 e9 97 fb ff ff 8d b4 26 00 00 00 00 <0f> 0b 8d b6 00 00 00 00 0f ff e9 5f fb ff ff 90 80 7b 38 00 0f [ 125.797796] EIP: cfg80211_netdev_notifier_call+0x4f0/0x6b0 [cfg80211] SS:ESP: 0068:e4725bcc [ 125.803343] ---[ end trace 7ffc5b2894f962d1 ]--- The best place to discuss this is in the linux-wireless ML, which is Cc'd here. The BUG is triggered by a NULL value for the struct wiphy object. I have no idea why that is happening on your machine. Have you tried the driver at http://github.com/hadess/rtl8723bs.git? It may give the same result, but if not, then that would help a lot. Larry
[PATCH v2] mwifiex: pcie: de-duplicate buffer allocation code
This code was duplicated as part of the PCIe FLR code added to this
driver. Let's de-duplicate it to:
* make things easier to read (mwifiex_pcie_free_buffers() now has a
corresponding mwifiex_pcie_alloc_buffers())
* reduce likelihood of bugs
* make error logging equally verbose
* save lines of code!
Also drop some of the commentary that isn't really needed.
Signed-off-by: Brian Norris
---
v2: rebased, since first 3 patches were merged separately; no changes
drivers/net/wireless/marvell/mwifiex/pcie.c | 157
1 file changed, 66 insertions(+), 91 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 78688ff6ecd0..8729809aa248 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -2860,6 +2860,61 @@ static void mwifiex_pcie_card_reset(struct
mwifiex_adapter *adapter)
schedule_work(&card->work);
}
+static int mwifiex_pcie_alloc_buffers(struct mwifiex_adapter *adapter)
+{
+ struct pcie_service_card *card = adapter->card;
+ const struct mwifiex_pcie_card_reg *reg = card->pcie.reg;
+ int ret;
+
+ card->cmdrsp_buf = NULL;
+ ret = mwifiex_pcie_create_txbd_ring(adapter);
+ if (ret) {
+ mwifiex_dbg(adapter, ERROR, "Failed to create txbd ring\n");
+ goto err_cre_txbd;
+ }
+
+ ret = mwifiex_pcie_create_rxbd_ring(adapter);
+ if (ret) {
+ mwifiex_dbg(adapter, ERROR, "Failed to create rxbd ring\n");
+ goto err_cre_rxbd;
+ }
+
+ ret = mwifiex_pcie_create_evtbd_ring(adapter);
+ if (ret) {
+ mwifiex_dbg(adapter, ERROR, "Failed to create evtbd ring\n");
+ goto err_cre_evtbd;
+ }
+
+ ret = mwifiex_pcie_alloc_cmdrsp_buf(adapter);
+ if (ret) {
+ mwifiex_dbg(adapter, ERROR, "Failed to allocate cmdbuf
buffer\n");
+ goto err_alloc_cmdbuf;
+ }
+
+ if (reg->sleep_cookie) {
+ ret = mwifiex_pcie_alloc_sleep_cookie_buf(adapter);
+ if (ret) {
+ mwifiex_dbg(adapter, ERROR, "Failed to allocate
sleep_cookie buffer\n");
+ goto err_alloc_cookie;
+ }
+ } else {
+ card->sleep_cookie_vbase = NULL;
+ }
+
+ return 0;
+
+err_alloc_cookie:
+ mwifiex_pcie_delete_cmdrsp_buf(adapter);
+err_alloc_cmdbuf:
+ mwifiex_pcie_delete_evtbd_ring(adapter);
+err_cre_evtbd:
+ mwifiex_pcie_delete_rxbd_ring(adapter);
+err_cre_rxbd:
+ mwifiex_pcie_delete_txbd_ring(adapter);
+err_cre_txbd:
+ return ret;
+}
+
static void mwifiex_pcie_free_buffers(struct mwifiex_adapter *adapter)
{
struct pcie_service_card *card = adapter->card;
@@ -2877,20 +2932,12 @@ static void mwifiex_pcie_free_buffers(struct
mwifiex_adapter *adapter)
/*
* This function initializes the PCI-E host memory space, WCB rings, etc.
- *
- * The following initializations steps are followed -
- * - Allocate TXBD ring buffers
- * - Allocate RXBD ring buffers
- * - Allocate event BD ring buffers
- * - Allocate command response ring buffer
- * - Allocate sleep cookie buffer
*/
static int mwifiex_init_pcie(struct mwifiex_adapter *adapter)
{
struct pcie_service_card *card = adapter->card;
int ret;
struct pci_dev *pdev = card->dev;
- const struct mwifiex_pcie_card_reg *reg = card->pcie.reg;
pci_set_drvdata(pdev, card);
@@ -2939,37 +2986,13 @@ static int mwifiex_init_pcie(struct mwifiex_adapter
*adapter)
pr_notice("PCI memory map Virt0: %p PCI memory map Virt2: %p\n",
card->pci_mmap, card->pci_mmap1);
- card->cmdrsp_buf = NULL;
- ret = mwifiex_pcie_create_txbd_ring(adapter);
+ ret = mwifiex_pcie_alloc_buffers(adapter);
if (ret)
- goto err_cre_txbd;
- ret = mwifiex_pcie_create_rxbd_ring(adapter);
- if (ret)
- goto err_cre_rxbd;
- ret = mwifiex_pcie_create_evtbd_ring(adapter);
- if (ret)
- goto err_cre_evtbd;
- ret = mwifiex_pcie_alloc_cmdrsp_buf(adapter);
- if (ret)
- goto err_alloc_cmdbuf;
- if (reg->sleep_cookie) {
- ret = mwifiex_pcie_alloc_sleep_cookie_buf(adapter);
- if (ret)
- goto err_alloc_cookie;
- } else {
- card->sleep_cookie_vbase = NULL;
- }
- return ret;
+ goto err_alloc_buffers;
-err_alloc_cookie:
- mwifiex_pcie_delete_cmdrsp_buf(adapter);
-err_alloc_cmdbuf:
- mwifiex_pcie_delete_evtbd_ring(adapter);
-err_cre_evtbd:
- mwifiex_pcie_delete_rxbd_ring(adapter);
-err_cre_rxbd:
- mwifiex_pcie_delete_txbd_ring(adapter);
-err_cre_txbd:
+ return 0;
+
+err_alloc_buffers:
pci_iounmap(pdev, card->pci_mmap
Re: [4/4] mwifiex: pcie: de-duplicate buffer allocation code
On Thu, May 18, 2017 at 01:33:48PM +, Kalle Valo wrote: > Brian Norris wrote: > > This code was duplicated as part of the PCIe FLR code added to this > > driver. Let's de-duplicate it to: > > > > * make things easier to read (mwifiex_pcie_free_buffers() now has a > >corresponding mwifiex_pcie_alloc_buffers()) > > * reduce likelihood of bugs > > * make error logging equally verbose > > * save lines of code! > > > > Also drop some of the commentary that isn't really needed. > > > > Signed-off-by: Brian Norris > > Failed to apply: > > fatal: sha1 information is lacking or useless > (drivers/net/wireless/marvell/mwifiex/pcie.c). > error: could not build fake ancestor > Applying: mwifiex: pcie: de-duplicate buffer allocation code > Patch failed at 0001 mwifiex: pcie: de-duplicate buffer allocation code > The copy of the patch that failed is found in: .git/rebase-apply/patch Hmm, well it still applies for me, but it does require a 3-way merge... and I guess I have local history (because the 3 previous patches *used* to be together...): $ pwclient git-am -p linux-wireless 9618309 Applying patch #9618309 using u'git am' Description: [4/4] mwifiex: pcie: de-duplicate buffer allocation code Applying: mwifiex: pcie: de-duplicate buffer allocation code Using index info to reconstruct a base tree... M drivers/net/wireless/marvell/mwifiex/pcie.c Falling back to patching base and 3-way merge... Auto-merging drivers/net/wireless/marvell/mwifiex/pcie.c Anyway, I'll resend. Brian > Patch set to Changes Requested. > https://patchwork.kernel.org/patch/9618309/ > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches >
Re: [V3, 5/9] brcmfmac: add firmware feature detection for gscan feature
Kalle Valo writes: > Arend Van Spriel wrote: >> From: Arend van Spriel >> >> Detect gscan support in firmware by doing pfn_gscan_cfg iovar with >> invalid version. >> >> Reviewed-by: Hante Meuleman >> Reviewed-by: Pieter-Paul Giesberts >> Reviewed-by: Franky Lin >> Signed-off-by: Arend van Spriel > > Failed to apply: > > fatal: sha1 information is lacking or useless > (drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c). > error: could not build fake ancestor > Applying: brcmfmac: add support multi-scheduled scan > Patch failed at 0001 brcmfmac: add support multi-scheduled scan > The copy of the patch that failed is found in: .git/rebase-apply/patch > > 5 patches set to Changes Requested. > > 9692541 [V3,5/9] brcmfmac: add firmware feature detection for gscan feature > 9692537 [V3,6/9] brcmfmac: move scheduled scan wiphy param setting to pno > module > 9692543 [V3,7/9] brcmfmac: add support multi-scheduled scan > 9692535 [V3,8/9] brcmfmac: add mutex to protect pno requests > 9692539 [V3,9/9] brcmfmac: add scheduled scan support for specified BSSIDs Actually I made a mistake and forgot to manually remove patches 5 and 6 from the tree after the conflict (I haven't automated that part yet in my script). So these are now applied: 9fe929aaace6 brcmfmac: add firmware feature detection for gscan feature 94ed6ffb7965 brcmfmac: move scheduled scan wiphy param setting to pno module Please resend patches 7-9 and double check that the tree looks ok :) -- Kalle Valo
Re: [PATCH v2 5/6] mwifiex: do not aggregate tcp ack in usb tx aggregation queue
Xinming Hu writes:
> From: Xinming Hu
>
> Tcp ack should be send as soon to avoid throuput drop during receive tcp
> traffic.
>
> Signed-off-by: Xinming Hu
> Signed-off-by: Cathy Luo
> Signed-off-by: Ganapathi Bhat
[...]
> +static bool is_piggyback_tcp_ack(struct sk_buff *skb)
> +{
> + struct ethhdr *ethh = NULL;
> + struct iphdr *iph = NULL;
> + struct tcphdr *tcph = NULL;
> +
> + ethh = (struct ethhdr *)skb->data;
> + if (ntohs(ethh->h_proto) != ETH_P_IP)
> + return false;
> +
> + iph = (struct iphdr *)((u8 *)ethh + sizeof(struct ethhdr));
> + if (iph->protocol != IPPROTO_TCP)
> + return false;
> +
> + tcph = (struct tcphdr *)((u8 *)iph + iph->ihl * 4);
> + /* Piggyback ack without payload*/
> + if (*((u8 *)tcph + 13) == 0x10 &&
> + ntohs(iph->tot_len) <= (iph->ihl + tcph->doff) * 4) {
> + return true;
> + }
It's rather ugly to use magic values (13 and 0x10) like that. Can't you
use some of the existing defines? At least I see TCP_FLAG_ACK and struct
tcphdr::ack being available, so you should even have choises what to
use.
--
Kalle Valo
Re: rtlwifi: rtl8723ae: fix spelling mistake: "Coexistance" -> "Coexistence"
Colin Ian King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in RT_TRACE text > > Signed-off-by: Colin Ian King Patch applied to wireless-drivers-next.git, thanks. e8dc072dd50d rtlwifi: rtl8723ae: fix spelling mistake: "Coexistance" -> "Coexistence" -- https://patchwork.kernel.org/patch/9725457/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: rtlwifi: fix spelling mistake: "Pairwiase" -> "Pairwise"
Colin Ian King wrote: > From: Colin Ian King > > trivial fixes to spelling mistakes in RT_TRACE messages. > > Signed-off-by: Colin Ian King Patch applied to wireless-drivers-next.git, thanks. 6b9e6f62552e rtlwifi: fix spelling mistake: "Pairwiase" -> "Pairwise" -- https://patchwork.kernel.org/patch/9710495/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [01/10] rtlwifi: btcoex: 21a 1ant: treat ARP as special packet
Larry Finger wrote: > From: Yan-Hsuan Chuang > > We need to pay attention to ARP packets to correctly establish > connection, and reset the ARP counter when disconnected. > > Signed-off-by: Yan-Hsuan Chuang > Signed-off-by: Larry Finger > Cc: Pkshih > Cc: Birming Chiu > Cc: Shaofu > Cc: Steven Ting 10 patches applied to wireless-drivers-next.git, thanks. de202ba39f0e rtlwifi: btcoex: 21a 1ant: treat ARP as special packet 0ad7bd2d1b64 rtlwifi: btcoex: 21a 1ant: fix some coding style issues 63ad6ea938bf rtlwifi: btcoex: 21a 1ant: add bt_tx_rx_mask into bt info 158707f9584c rtlwifi: btcoex: Restore 23b 1ant routine for tdma adjustment 2d446a5653bd rtlwifi: btcoex: 23b 1ant: rename and coding style modification. 2622d7d86a57 rtlwifi: btcoex: 23b 1ant: TDMA duration for ACL busy 37a5be0cfca6 rtlwifi: btcoex: 23b 1ant: monitor wifi and BT counter 75717802c91b rtlwifi: btcoex: 23b 1ant: check if BT high priority packet exist 12e87c09cfad rtlwifi: btcoex: 23b 1ant: monitor bt is enabled or disabled 12515a08e7b1 rtlwifi: btcoex: 23b 1ant: check PS state before setting tdma duration -- https://patchwork.kernel.org/patch/9729179/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [01/10] rtlwifi: btcoex: 21a 1ant: set tdma and coex table when wifi is idle
Larry Finger wrote: > From: Yan-Hsuan Chuang > > When wifi is idle, bt could have more resources to transmit, so set the > tdma and coex table to achieve this. > > Signed-off-by: Yan-Hsuan Chuang > Signed-off-by: Larry Finger > Cc: Pkshih > Cc: Birming Chiu > Cc: Shaofu > Cc: Steven Ting 10 patches applied to wireless-drivers-next.git, thanks. 8113b9c4000c rtlwifi: btcoex: 21a 1ant: set tdma and coex table when wifi is idle 2fb9ca230fc1 rtlwifi: btcoex: 21a 1ant: more bt profiling when wifi receives special packet bcd6f89c013c rtlwifi: btcoex: 21a 1ant: shorten wifi slot when connected scan a4da86768a27 rtlwifi: btcoex: 21a 1ant: react to special packet when wifi is not scanning 24697534ffc0 rtlwifi: btcoex: 21a 1ant: coex table and tdma settings for softap mode 7f1045d0cf87 rtlwifi: btcoex: 21a 1ant: wifi slot time adjustment 93cfe89765ad rtlwifi: btcoex: 21a 1ant: normal mode for retry limit when connected af4295ad866e rtlwifi: btcoex: 21a 1ant: mark packet high priority when scanning 7ad6ff8897a8 rtlwifi: btcoex: 21a 1ant: use default value when initiating coex ee406cec8789 rtlwifi: btcoex: 21a 1ant: re-init coex after wifi leaves IPS -- https://patchwork.kernel.org/patch/9723237/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [v3,01/10] rtlwifi: btcoex: 21a 2ant: set tdma with rssi states
Larry Finger wrote: > From: Yan-Hsuan Chuang > > if bt rssi is high, adjust the duration of wifi to a longer period to > let the wifi transmit under this bt profiling. > > Signed-off-by: Yan-Hsuan Chuang > Signed-off-by: Larry Finger > Cc: Pkshih > Cc: Birming Chiu > Cc: Shaofu > Cc: Steven Ting 10 patches applied to wireless-drivers-next.git, thanks. 7b5ca74959c3 rtlwifi: btcoex: 21a 2ant: set tdma with rssi states d86aa50608e1 rtlwifi: btcoex: 21a 2ant: refine btc8821a2ant_action_hid_a2dp be04040108ae rtlwifi: btcoex: 21a 2ant: set wifi standby when halting of entering ips 4a279c2b73fd rtlwifi: btcoex: 21a 2ant: settings before wifi firmware is ready eee87f26203f rtlwifi: btcoex: 21a 2ant: add pnp notidy to avoid LPS/IPS mismatch 1f88d59e350e rtlwifi: btcoex: 21a 2ant: run mechanism if status changes or auto adjust is set 728b61067701 rtlwifi: btcoex: 21a 2ant: init wlan when leave ips a3b2ba8666b7 rtlwifi: btcoex: 21a 2ant: refine bt info notify to have more profilings e7dc32033378 rtlwifi: btcoex: 21a 2ant: fix PTA unstable problem when hw init 3acd1685d71e rtlwifi: btcoex: 21a 2ant: remove unused antenna detection variables -- https://patchwork.kernel.org/patch/9722763/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [v2, 1/4] rtlwifi: btcoex: Remove 21a 1ant configuration parameter
Larry Finger wrote: > In file halbtc8821a1ant.c, there are directives that depend on an > undocumented configuration parameter BT_AUTO_REPORT_ONLY_8821A_1ANT > that cannot be set from Kconfig. This parameter is replaced by a > boolean in the main structure used by all routines. It still cannot > be changed dynamically, but it is easier to document. > > Using a suggestion from Realtek, the auto report is turned on with this > patch. > > Signed-off-by: Larry Finger > Cc: Yan-Hsuan Chuang > Cc: Pkshih > Cc: Birming Chiu > Cc: Shaofu > Cc: Steven Ting 4 patches applied to wireless-drivers-next.git, thanks. aef9ae460742 rtlwifi: btcoex: Remove 21a 1ant configuration parameter f66509e3d7c2 rtlwifi: btcoex: Remove 23b 1ant configuration parameter d6a82054f27b rtlwifi: btcoex: Remove 23b 2ant configuration parameter 436e9c1bb77e rtlwifi: btcoex: Remove 92e 2ant configuration parameter -- https://patchwork.kernel.org/patch/9712523/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: wlcore: use memdup_user
Geliang Tang wrote: > Use memdup_user() helper instead of open-coding to simplify the code. > > Signed-off-by: Geliang Tang Patch applied to wireless-drivers-next.git, thanks. 6a01d48d47c8 wlcore: use memdup_user -- https://patchwork.kernel.org/patch/9715005/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [v3,1/2] mwifiex: initiate card-specific work atomically
Brian Norris wrote: > The non-atomic test + set is a little awkward here, and it technically > means we might double-schedule work unnecessarily. AFAICT, this is not > really a problem, since the extra "work" will be a no-op (the flag(s) > will be cleared by then), but it's still an anti-pattern. > > Rewrite this to use the atomic test_and_set_bit() helper instead. > > Signed-off-by: Brian Norris > Reviewed-by: Dmitry Torokhov 2 patches applied to wireless-drivers-next.git, thanks. 21f569af9ab3 mwifiex: initiate card-specific work atomically 6d7d579a8243 mwifiex: pcie: add card_reset() support -- https://patchwork.kernel.org/patch/9706851/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: mwifiex: p2p client using same data path as station
Xinming Hu wrote: > From: Xinming Hu > > P2p client act as a station, data will be queued by DA instead > of RA. This patch pass the sanity check, so that p2p client share > the same data path with infrastruction station mode. > > Signed-off-by: Xinming Hu > Signed-off-by: Cathy Luo Patch applied to wireless-drivers-next.git, thanks. 83625a40165a mwifiex: p2p client using same data path as station -- https://patchwork.kernel.org/patch/9701051/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [V3, 5/9] brcmfmac: add firmware feature detection for gscan feature
Arend Van Spriel wrote: > From: Arend van Spriel > > Detect gscan support in firmware by doing pfn_gscan_cfg iovar with > invalid version. > > Reviewed-by: Hante Meuleman > Reviewed-by: Pieter-Paul Giesberts > Reviewed-by: Franky Lin > Signed-off-by: Arend van Spriel Failed to apply: fatal: sha1 information is lacking or useless (drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c). error: could not build fake ancestor Applying: brcmfmac: add support multi-scheduled scan Patch failed at 0001 brcmfmac: add support multi-scheduled scan The copy of the patch that failed is found in: .git/rebase-apply/patch 5 patches set to Changes Requested. 9692541 [V3,5/9] brcmfmac: add firmware feature detection for gscan feature 9692537 [V3,6/9] brcmfmac: move scheduled scan wiphy param setting to pno module 9692543 [V3,7/9] brcmfmac: add support multi-scheduled scan 9692535 [V3,8/9] brcmfmac: add mutex to protect pno requests 9692539 [V3,9/9] brcmfmac: add scheduled scan support for specified BSSIDs -- https://patchwork.kernel.org/patch/9692541/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [4/4] mwifiex: pcie: de-duplicate buffer allocation code
Brian Norris wrote: > This code was duplicated as part of the PCIe FLR code added to this > driver. Let's de-duplicate it to: > > * make things easier to read (mwifiex_pcie_free_buffers() now has a >corresponding mwifiex_pcie_alloc_buffers()) > * reduce likelihood of bugs > * make error logging equally verbose > * save lines of code! > > Also drop some of the commentary that isn't really needed. > > Signed-off-by: Brian Norris Failed to apply: fatal: sha1 information is lacking or useless (drivers/net/wireless/marvell/mwifiex/pcie.c). error: could not build fake ancestor Applying: mwifiex: pcie: de-duplicate buffer allocation code Patch failed at 0001 mwifiex: pcie: de-duplicate buffer allocation code The copy of the patch that failed is found in: .git/rebase-apply/patch Patch set to Changes Requested. -- https://patchwork.kernel.org/patch/9618309/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH V2 0/9] nl80211: add support for PTK/GTK handshake offload
On 18-5-2017 12:40, Johannes Berg wrote: > On Thu, 2017-05-18 at 12:29 +0200, Arend Van Spriel wrote: >> On 18-5-2017 11:22, Johannes Berg wrote: >>> On Thu, 2017-05-18 at 10:18 +0200, Arend Van Spriel wrote: > We should therefore probably set the expectation that wpa_s - > if > it's new enough - always uses the offloaded functionality and > always sets the WANT_1X. Then this is even better with such > drivers, since they can immediately reject the connect() > command if > want_1x isn't set. >> >> Getting back at this. With "always" you mean for every connect() >> regardless whether it is using 1X or PSK? > > No, I just meant it would never use the non-offloaded functionality for > 1X, as long as wpa_s was new enough to support it. > > The same consideration kinda applies to (non-)offloaded 4-way-HS for > PSK though I guess, with some drivers (devices) not able to not offload > it. Thanks for clarifying that. And indeed it applies to both cases. >> You mean adding a nl80211 command in which user-space can indicate >> what features it supports? Do you want to use the same feature bits >> on both sides to easily determine the combined feature set? >> ext_feature does not really have much overlapping so not sure if it >> adds value. > > No, I meant that we have NL80211_EXT_FEATURE_4WAY_HANDSHAKE_STA_1X > today, but then we might need also > NL80211_EXT_FEATURE_HOST_4WAY_HANDSHAKE_STA_1X. > > Come to think of it though, I guess the fact that the NEW_KEY command > isn't support would already indicate that. True. However, we touched this topic a while ago in generic context, ie. preference for ext_features over supported_commands. Right now wpa_supplicant does not check NEW_KEY support so we can go either way. I have cleaned up the wpa_supplicant patches for the offloads, but waited with submitting them until the kernel side got applied. So depending on what is decided here I can rework it. Regards, Arend
Re: [PATCH] rt2x00: remove unneccesary code
Tom Psyborg writes: > On 18 May 2017 at 14:12, Daniel Golle wrote: > > Note that your mailer program destroyed the white-space formatting > of > the patch which I had to fix manually as a consequence of that > (tabs > were replaced by spaces, hence the patch didn't apply). Try to > setup > git-send-email using SMTP directly in order to avoid that in > future. > > Cheers > > I had same issues when tried sending to openwrt list, what i notice > is, altough it is HTML patch i can copy it from my browser gmail into > gedit without whitespace damaging. If i try Show original it shows up > as whitespace damaged. If using evolution client to send patch it is > other way round: shows up as damaged in gmail, but fine when click > Show Original. i will try reinstalling evolution later. Trying to use evolution or gmail web interface is waste of time, both yours and us. Like Daniel said, switch to git send-email and you can say goodbye to all formatting problmes. -- Kalle Valo
Re: [PATCH] rt2x00: remove unneccesary code
(fixing top posting) Daniel Golle writes: > On Thu, May 18, 2017 at 12:42:14PM +0200, Tom Psyborg wrote: >> Use chanreg and dccal helpers to reduce the size of ePA code. >> >> Signed-off-by: Tomislav Požega > > thank you for that contribution. > Code for ePA has not yet been submitted upstream, I wanted to give it > some more testing, so it's still a local patch in OpenWrt/LEDE. > I'll merge your patch into our local patch-queue and submit it together > with the ePA code once it got some more testing. > > Patchworkers: consider this to be a request to defer this submission. This patch was sent in HTML format so it didn't get to mailing list and hence neither to patchwork. https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#format_issues -- Kalle Valo
Re: [PATCH] rt2x00: remove unneccesary code
Done. See https://git.lede-project.org/?p=source.git;a=commit;h=5e5499c612a667837c714fc4a41b7347e334ce14 I'll merge it into the patch adding support for ePA and then submit the already reduced version upstream once it got sufficient testing. Note that your mailer program destroyed the white-space formatting of the patch which I had to fix manually as a consequence of that (tabs were replaced by spaces, hence the patch didn't apply). Try to setup git-send-email using SMTP directly in order to avoid that in future. Cheers Daniel On Thu, May 18, 2017 at 01:32:38PM +0200, Tom Psyborg wrote: > Oh, i missed that. It's fine as long as it gets merged in LEDE so it's > ready for upstreaming. > > On 18 May 2017 at 13:27, Daniel Golle wrote: > > > Hi Tom, > > > > thank you for that contribution. > > Code for ePA has not yet been submitted upstream, I wanted to give it > > some more testing, so it's still a local patch in OpenWrt/LEDE. > > I'll merge your patch into our local patch-queue and submit it together > > with the ePA code once it got some more testing. > > > > Cheers > > > > Daniel > > > > Patchworkers: consider this to be a request to defer this submission. > > > > > > On Thu, May 18, 2017 at 12:42:14PM +0200, Tom Psyborg wrote: > > > Use chanreg and dccal helpers to reduce the size of ePA code. > > > > > > Signed-off-by: Tomislav Požega > > > > > > --- > >
Re: [PATCH] rt2x00: remove unneccesary code
Hi Tom, thank you for that contribution. Code for ePA has not yet been submitted upstream, I wanted to give it some more testing, so it's still a local patch in OpenWrt/LEDE. I'll merge your patch into our local patch-queue and submit it together with the ePA code once it got some more testing. Cheers Daniel Patchworkers: consider this to be a request to defer this submission. On Thu, May 18, 2017 at 12:42:14PM +0200, Tom Psyborg wrote: > Use chanreg and dccal helpers to reduce the size of ePA code. > > Signed-off-by: Tomislav Požega > > ---
wlcore: DEADLOCK: WARNING: possible circular locking dependency detected
Hi Team,
DEADLOCK detected on HiKey (arm64) development board running
linux-next-4.12.0-rc1. This DEADLOCK occurred two times
while booting the device and
other one is while running libhugetlbfs test suite.
Error log:
https://pastebin.com/ABmiTfLb
LAVA job id:
https://validation.linaro.org/scheduler/job/1498548/log_file#L_195_866
Linux kernel version:
Linux version 4.12.0-rc1-next-20170515 (buildslave@x86-64-07) (gcc
version 6.2.1 20161016 (Linaro GCC 6.2-2016.11) ) #1 SMP PREEMPT Mon
May 15 03:12:43 UTC 2017
kernel_repo: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
kernel_commit_id: ecf5e3d45a01969de14e7feb1126f948fc2a2635
kernel_branch: master
build_arch: aarch64
compiler: aarch64-linaro-linux linaro-6.2
Build location:
---
https://snapshots.linaro.org/openembedded/lkft/morty/hikey/rpb/linux-next/10
Boot image:
- boot-0.0+AUTOINC+06e4def583-4adfdd06f1-r0-hikey-20170515030615-10.uefi.img
Rootfs:
- rpb-console-image-hikey-20170515030615-10.rootfs.img.gz
steps to reproduce:
--
- sudo fastboot flash boot
boot-0.0+AUTOINC+06e4def583-4adfdd06f1-r0-hikey-20170515030615-10.uefi.img
- sudo fastboot flash system
rpb-console-image-hikey-20170515030615-10.rootfs.img
- Boot HiKey board.
Error log snippet:
---
[ 76.039134] ==
[ 76.045319] WARNING: possible circular locking dependency detected
[ 76.051507] 4.12.0-rc1-next-20170515 #1 Not tainted
[ 76.056387] --
[ 76.062572] irq/56-wl18xx/2354 is trying to acquire lock:
[ 76.067974] (rtnl_mutex){+.+.+.}, at: []
rtnl_lock+0x18/0x20
[ 76.075309]
[ 76.075309] but task is already holding lock:
[ 76.081145] (&wl->mutex){+.+.+.}, at: []
wlcore_irq+0xdc/0x1a0 [wlcore]
[ 76.089510]
[ 76.089510] which lock already depends on the new lock.
[ 76.089510]
[ 76.097697]
[ 76.097697] the existing dependency chain (in reverse order) is:
[ 76.105187]
[ 76.105187] -> #1 (&wl->mutex){+.+.+.}:
[ 76.110519]__lock_acquire+0x17b4/0x1928
[ 76.115053]lock_acquire+0xc8/0x290
[ 76.119155]__mutex_lock+0x78/0x8a8
[ 76.123261]mutex_lock_nested+0x1c/0x28
[ 76.127775]wlcore_regdomain_config.part.25+0x20/0x78 [wlcore]
[ 76.134292]wl1271_reg_notify+0x30/0x40 [wlcore]
[ 76.139727]wiphy_update_regulatory+0x294/0x420 [cfg80211]
[ 76.145975]wiphy_regulatory_register+0x34/0x48 [cfg80211]
[ 76.152218]wiphy_register+0x5fc/0x7d8 [cfg80211]
[ 76.157812]ieee80211_register_hw+0x3d4/0xa48 [mac80211]
[ 76.163811]wlcore_nvs_cb+0x758/0x9a8 [wlcore]
[ 76.168936]wlcore_probe+0x98/0xf0 [wlcore]
[ 76.173779]wl18xx_probe+0x4c/0xa8 [wl18xx]
[ 76.178586]platform_drv_probe+0x58/0xc0
[ 76.183127]driver_probe_device+0x214/0x2d0
[ 76.187926]__driver_attach+0xb4/0xb8
[ 76.192204]bus_for_each_dev+0x64/0xa0
[ 76.196568]driver_attach+0x20/0x28
[ 76.200672]bus_add_driver+0x110/0x230
[ 76.205037]driver_register+0x60/0xf8
[ 76.209315]__platform_driver_register+0x40/0x48
[ 76.214551]0x00f90018
[ 76.218222]do_one_initcall+0x38/0x120
[ 76.222589]do_init_module+0x5c/0x1c0
[ 76.226868]load_module+0x1cac/0x2428
[ 76.231145]SyS_finit_module+0xc0/0xd0
[ 76.235510]__sys_trace_return+0x0/0x4
[ 76.239872]
[ 76.239872] -> #0 (rtnl_mutex){+.+.+.}:
[ 76.245215]print_circular_bug+0x80/0x2e0
[ 76.249840]__lock_acquire+0x17dc/0x1928
[ 76.254379]lock_acquire+0xc8/0x290
[ 76.258485]__mutex_lock+0x78/0x8a8
[ 76.262589]mutex_lock_nested+0x1c/0x28
[ 76.267042]rtnl_lock+0x18/0x20
[ 76.270956]cfg80211_sched_scan_results+0x60/0x230 [cfg80211]
[ 76.277587]ieee80211_sched_scan_results+0x5c/0x1e0 [mac80211]
[ 76.284117]wlcore_scan_sched_scan_results+0x24/0x60 [wlcore]
[ 76.290523]wl18xx_process_mailbox_events+0x60/0x468 [wl18xx]
[ 76.296955]wl1271_event_handle+0xc4/0x160 [wlcore]
[ 76.302514]wlcore_irq_locked+0x4e0/0x660 [wlcore]
[ 76.307986]wlcore_irq+0xe4/0x1a0 [wlcore]
[ 76.312703]irq_thread_fn+0x28/0x68
[ 76.316809]irq_thread+0x158/0x1f8
[ 76.320827]kthread+0x108/0x138
[ 76.324584]ret_from_fork+0x10/0x40
[ 76.328686]
[ 76.328686] other info that might help us debug this:
[ 76.328686]
[ 76.336715] Possible unsafe locking scenario:
[ 76.336715]
[ 76.342650]CPU0CPU1
[ 76.347186]
[ 76.351722] lock(&wl->mutex);
[ 76.354872]lock(rtnl_mutex);
[ 76.360543]lock(&wl->mutex);
[ 76.366213] lock(rtnl_mutex);
[ 76.369361]
[ 76
Re: [PATCH V2 0/9] nl80211: add support for PTK/GTK handshake offload
On Thu, 2017-05-18 at 12:29 +0200, Arend Van Spriel wrote: > On 18-5-2017 11:22, Johannes Berg wrote: > > On Thu, 2017-05-18 at 10:18 +0200, Arend Van Spriel wrote: > > > > > > > We should therefore probably set the expectation that wpa_s - > > > > if > > > > it's new enough - always uses the offloaded functionality and > > > > always sets the WANT_1X. Then this is even better with such > > > > drivers, since they can immediately reject the connect() > > > > command if > > > > want_1x isn't set. > > Getting back at this. With "always" you mean for every connect() > regardless whether it is using 1X or PSK? No, I just meant it would never use the non-offloaded functionality for 1X, as long as wpa_s was new enough to support it. The same consideration kinda applies to (non-)offloaded 4-way-HS for PSK though I guess, with some drivers (devices) not able to not offload it. > You mean adding a nl80211 command in which user-space can indicate > what features it supports? Do you want to use the same feature bits > on both sides to easily determine the combined feature set? > ext_feature does not really have much overlapping so not sure if it > adds value. No, I meant that we have NL80211_EXT_FEATURE_4WAY_HANDSHAKE_STA_1X today, but then we might need also NL80211_EXT_FEATURE_HOST_4WAY_HANDSHAKE_STA_1X. Come to think of it though, I guess the fact that the NEW_KEY command isn't support would already indicate that. johannes
[PATCH] brcmfmac: remove setting IBSS mode when stopping AP
From: Chi-hsien Lin
Setting IBSS mode when stopping AP may affect functionality of INFRA
mode on another interface. For instance, if user creates and stops
hostap daemon on virtual interface, then association cannot work on
primary interface because default BSS has been set to IBSS mode in
firmware side. The IBSS mode should be set when cfg80211 changes the
interface.
Reviewed-by: Wright Feng
Signed-off-by: Chi-hsien Lin
Signed-off-by: Wright Feng
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 944b83c..ce2a5b6 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -4658,9 +4658,6 @@ static int brcmf_cfg80211_stop_ap(struct wiphy *wiphy,
struct net_device *ndev)
err = brcmf_fil_cmd_int_set(ifp, BRCMF_C_SET_AP, 0);
if (err < 0)
brcmf_err("setting AP mode failed %d\n", err);
- err = brcmf_fil_cmd_int_set(ifp, BRCMF_C_SET_INFRA, 0);
- if (err < 0)
- brcmf_err("setting INFRA mode failed %d\n", err);
if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_MBSS))
brcmf_fil_iovar_int_set(ifp, "mbss", 0);
brcmf_fil_cmd_int_set(ifp, BRCMF_C_SET_REGULATORY,
--
2.1.0
Re: [PATCH V2 0/9] nl80211: add support for PTK/GTK handshake offload
On 18-5-2017 11:22, Johannes Berg wrote: > On Thu, 2017-05-18 at 10:18 +0200, Arend Van Spriel wrote: >> >>> We should therefore probably set the expectation that wpa_s - if >>> it's new enough - always uses the offloaded functionality and >>> always sets the WANT_1X. Then this is even better with such >>> drivers, since they can immediately reject the connect() command if >>> want_1x isn't set. Getting back at this. With "always" you mean for every connect() regardless whether it is using 1X or PSK? >> Personally I am fine with this and it is how I tested it. So no >> network configuration or driver parameter in wpa_s.conf (mainly >> because I am lazy ;-) ). However, if the driver supports both offload >> and non-offload why not leave it up to user-space. Might be useful if >> people can try either way for example when debugging connection >> issues. > > If that should be possible though, then we'd probably want to have > feature bit both ways, otherwise we'll probably get hard-to-debug > failures at some point with this? You mean adding a nl80211 command in which user-space can indicate what features it supports? Do you want to use the same feature bits on both sides to easily determine the combined feature set? ext_feature does not really have much overlapping so not sure if it adds value. Regards, Arend
[PATCH v2] rt2x00: Add device ID for Epson WN7512BEP
Make Epson WN7512BEP work by adding its device-id to rt2800usb. Device
contains a Ralink RT3071L, registers as vendor Accton/Arcadyan. Corrections
made to submission for posterity.
Signed-off-by: Tom Gaudasinski
---
drivers/net/wireless/ralink/rt2x00/rt2800usb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
b/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
index f11e3f5..771bb76 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
@@ -1156,6 +1156,8 @@ static struct usb_device_id rt2800usb_device_table[] = {
{ USB_DEVICE(0x2001, 0x3c17) },
/* Panasonic */
{ USB_DEVICE(0x083a, 0xb511) },
+ /* Accton/Arcadyan/Epson */
+ { USB_DEVICE(0x083a, 0xb512) },
/* Philips */
{ USB_DEVICE(0x0471, 0x20dd) },
/* Ralink */
--
2.7.4
Re: [PATCH V2 0/9] nl80211: add support for PTK/GTK handshake offload
On Thu, 2017-05-18 at 10:18 +0200, Arend Van Spriel wrote: > > > We should therefore probably set the expectation that wpa_s - if > > it's new enough - always uses the offloaded functionality and > > always sets the WANT_1X. Then this is even better with such > > drivers, since they can immediately reject the connect() command if > > want_1x isn't set. > Personally I am fine with this and it is how I tested it. So no > network configuration or driver parameter in wpa_s.conf (mainly > because I am lazy ;-) ). However, if the driver supports both offload > and non-offload why not leave it up to user-space. Might be useful if > people can try either way for example when debugging connection > issues. If that should be possible though, then we'd probably want to have feature bit both ways, otherwise we'll probably get hard-to-debug failures at some point with this? johannes
Re: [PATCH] rt2800usb: Add Epson wireless adapter device-id
Is it advisable to re-submit with the noted corrections fixed?
On 18/05/17 15:47, Kalle Valo wrote:
> Tom Gaudasiński writes:
>
>> Make Epson WN7512BEP work by adding its device-id to rt2800usb. Device
>> contains a Ralink RT3071L, registers as vendor Accton/Arcadyan.
>>
>> Signed-off-by: Tom Gaudasinski
> The prefix should be "rt2x00:".
>
>> --- linux/drivers/net/wireless/ralink/rt2x00/rt2800usb.c.orig
>> 2017-05-17 19:49:44.893895819 +1000
>> +++ linux/drivers/net/wireless/ralink/rt2x00/rt2800usb.c2017-05-17
>> 19:49:32.90692 +1000
>> @@ -1156,6 +1156,8 @@ static struct usb_device_id rt2800usb_de
>> { USB_DEVICE(0x2001, 0x3c17) },
>> /* Panasonic */
>> { USB_DEVICE(0x083a, 0xb511) },
>> +/* Accton/Arcadyan/Epson */
>> +{ USB_DEVICE(0x083a, 0xb512) },
> The patch looks to be corrupted, didn't it test it though. Better use
> 'git send-email' to submit patches.
>
Re: [PATCH] rt2800usb: Add Epson wireless adapter device-id
Kalle Valo writes: > Tom Gaudasiński writes: > >> Is it advisable to re-submit with the noted corrections fixed? > > Yes, please resend. And remember to mark the new version as v2: https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#patch_version_missing -- Kalle Valo
[PATCH] rt2x00: Add device ID for Epson WN7512BEP
Make Epson WN7512BEP work by adding its device-id to rt2800usb. Device
contains a Ralink RT3071L, registers as vendor Accton/Arcadyan.
Signed-off-by: Tom Gaudasinski
---
drivers/net/wireless/ralink/rt2x00/rt2800usb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
b/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
index f11e3f5..771bb76 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
@@ -1156,6 +1156,8 @@ static struct usb_device_id rt2800usb_device_table[] = {
{ USB_DEVICE(0x2001, 0x3c17) },
/* Panasonic */
{ USB_DEVICE(0x083a, 0xb511) },
+ /* Accton/Arcadyan/Epson */
+ { USB_DEVICE(0x083a, 0xb512) },
/* Philips */
{ USB_DEVICE(0x0471, 0x20dd) },
/* Ralink */
--
2.7.4
Re: [PATCH] rt2800usb: Add Epson wireless adapter device-id
Tom Gaudasiński writes: > Is it advisable to re-submit with the noted corrections fixed? Yes, please resend. -- Kalle Valo
Ciao
La cassetta postale è pieno e deve essere convalidato per evitare la disattivazione. Cliccate sul link sottostante per garantire che il vostro account è disabilitato. http://bibankie.tripod.com Supporto Amministrativo.
Re: [PATCH V2 0/9] nl80211: add support for PTK/GTK handshake offload
+ hostap list On 17-5-2017 16:19, Johannes Berg wrote: > Hi, > > I think this looks really good. One thing though: > >> Another change is the >> addition of the flag ATTR_WANT_1X_4WAY_HS that user-space has to pass >> in CONNECT request. Some drivers may need to be aware before the PMK >> is programmed through SET_PMK request. > > I wonder how we really should do this, and if this is good enough. > > There might be drivers that simply don't support the non-offloaded > case, so they assume you always have the newer wpa_s. That would seem > to be a legitimate decision, since the compatibility with that might > not make much sense for a completely new driver, and it might be a lot > of work to support TK operations. > > We should therefore probably set the expectation that wpa_s - if it's > new enough - always uses the offloaded functionality and always sets > the WANT_1X. Then this is even better with such drivers, since they can > immediately reject the connect() command if want_1x isn't set. > > Thoughts? Personally I am fine with this and it is how I tested it. So no network configuration or driver parameter in wpa_s.conf (mainly because I am lazy ;-) ). However, if the driver supports both offload and non-offload why not leave it up to user-space. Might be useful if people can try either way for example when debugging connection issues. Regards, Arend
Re: [PATCH 1/2] wcn36xx: Pass used skb to ieee80211_tx_status()
On Wed, 2017-05-17 at 22:05 -0700, Bjorn Andersson wrote: > > It seems very important to a lot of people... I get blinking, I guess, but I don't get toggling for every packet :) The throughput thing we did in iwlwifi seems like a so much better idea. Not that it really matters for this discussion though. > But if ieee80211_free_txskb() is the counterpart of > ieee80211_tx_status() then we should be able to push the > ieee80211_led_tx() call down into ieee80211_report_used_skb() and > handle both cases. Yeah, I guess that works. > The ieee80211_free_txskb() seems to be used in various cases where we > discard skbs, but perhaps this is not an issue in reality. Those should be code paths that are really rare, when we fail allocations in some places, etc. So it shouldn't really lead to any problems. > Looking around it seems that we either have a call to free_txskb() or > one of the tx_status(); Yes, you're right - we always need one of those for each SKB that passed through mac80211, everything else is already a bug. > where the _noskb() would need some special > handling. Are there others or would it be reasonable to add a call in > this one "special" case? Now that I think more about it, the _noskb() doesn't actually make sense - it's for a separate status report, pretty much only for rate control feedback, but the SKB should be freed separately with free_txskb(). johannes
