On Sun, Jan 15, 2017 at 6:35 PM, Shawn Lin wrote:
> On 2017/1/16 5:41, Matt Ranostay wrote:
>>
>> On Thu, Jan 12, 2017 at 11:16 PM, Shawn Lin
>> wrote:
>>>
>>> On 2017/1/13 13:29, Matt Ranostay wrote:
Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
This can be abst
Hi Felix,
[auto build test WARNING on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Linus-L-ssing/bridge-multicast-to-unicast/20170118-120345
config: x86_64-rhel-7.2 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .
Hi Rafał,
[auto build test ERROR on wireless-drivers-next/master]
[cannot apply to v4.10-rc4 next-20170117]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Rafa-Mi-ecki/brcmfmac-use
On 01/17/2017 11:40 PM, Farhan Khan wrote:
Hi all,
I am having a bit of trouble understanding the rtl8188ee source,
specifically how its switch_channel function (rtl88e_phy_sw_chnl) works. I
gather that this function calls rtl88ee_phy_sw_chnl_callback, which in turn
calls _rtl88_phy_sw_chnl_step
On Tue, Jan 17, 2017 at 12:44:55PM -0800, Dmitry Torokhov wrote:
> On Tue, Jan 17, 2017 at 11:48:22AM -0800, Brian Norris wrote:
> > Also, FWIW, I did some fairly non-scientific tests of this on my
> > systems, and I didn't see much difference. I can run better tests, and
> > even collect data on h
Hi all,
I am having a bit of trouble understanding the rtl8188ee source,
specifically how its switch_channel function (rtl88e_phy_sw_chnl) works. I
gather that this function calls rtl88ee_phy_sw_chnl_callback, which in turn
calls _rtl88_phy_sw_chnl_step_by_step (
https://github.com/torvalds/linux/
From: Jes Sorensen
Device reported as working fine, so tell the driver not to warn about
it being untested.
Reported-by: Aex Aey
Signed-off-by: Jes Sorensen
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/realt
From: Axel Köllhofer
This was tested by David Patiño.
Reported-by: David Patiño
Signed-off-by: Axel Köllhofer
Signed-off-by: Jes Sorensen
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl
From: Jes Sorensen
Update copyright year and email address.
Signed-off-by: Jes Sorensen
---
MAINTAINERS| 2 +-
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 2 +-
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192c.c | 2 +-
drivers/net/w
From: Axel Köllhofer
These IDs originate from the vendor driver
Signed-off-by: Axel Köllhofer
Signed-off-by: Jes Sorensen
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
From: Jes Sorensen
TP-Link TL-WN822N v4 (2357:0108)
Reported-by: Gregory Auzanneau
Signed-off-by: Jes Sorensen
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
b/drivers/net/
From: Jes Sorensen
Hi,
This patchset adds some additional USB IDs for rtl8192eu devices, as
well as updates the email address and the copyright.
I've been preoccupied with some other stuff the last little while, so
I am a little out of touch with whether or not the patch window is
open at the m
A recent firmware change seems to have enabled thermal zones on the
iwlwifi driver. Unfortunately, my device fails when registering the
thermal zone. This doesn't stop the driver from attempting to unregister
the thermal zone at unload time, triggering a NULL pointer deference in
strlen() off the t
From: Gavin Li
brcmf_sdio_fromevntchan() was being called on the the data frame
rather than the software header, causing some frames to be
mischaracterized as on the event channel rather than the data channel.
This fixes a major performance regression (due to dropped packets).
Fixes: c56caa9db8
On 17 January 2017 at 23:55, wrote:
> From: Gavin Li
>
> brcmf_sdio_fromevntchan() was being called on the the data frame
> rather than the software header, causing some frames to be
> mischaracterized as on the event channel rather than the data channel.
>
> This fixes a major performance regre
From: Gavin Li
brcmf_sdio_fromevntchan() was being called on the the data frame
rather than the software header, causing some frames to be
mischaracterized as on the event channel rather than the data channel.
This fixes a major performance regression (due to dropped packets).
Fixes: c56caa9db8
From: Gavin Li
brcmf_sdio_fromevntchan() was being called on the the data frame
rather than the software header, causing some frames to be
mischaracterized as on the event channel rather than the data channel.
This fixes a major performance regression (due to dropped packets).
Fixes: c56caa9db8
From: Gavin Li
brcmf_sdio_fromevntchan() was being called on the the data frame
rather than the software header, causing some frames to be
mischaracterized as on the event channel rather than the data channel.
This fixes a major performance regression (due to dropped packets).
Fixes: c56caa9db8
From: Rafał Miłecki
This new helper reads extra frequency limits specified in DT and
disables unavailable chanels. This is useful for devices (like home
routers) with chipsets limited e.g. by board design.
In order to respect info read from DT we simply need to check for
IEEE80211_CHAN_DISABLED
On 17 January 2017 at 23:41, Rafał Miłecki wrote:
> On 17 January 2017 at 23:29, wrote:
>> From: Gavin Li
>>
>> brcmf_sdio_fromevntchan() was being called on the the hardware header
>> rather than the software header, causing some frames to be
>> mischaracterized as on the event channel rather
On 17 January 2017 at 23:29, wrote:
> From: Gavin Li
>
> brcmf_sdio_fromevntchan() was being called on the the hardware header
> rather than the software header, causing some frames to be
> mischaracterized as on the event channel rather than the data channel.
> This fixes the performance regres
From: Gavin Li
brcmf_sdio_fromevntchan() was being called on the the hardware header
rather than the software header, causing some frames to be
mischaracterized as on the event channel rather than the data channel.
This fixes the performance regression introduced in commit c56caa9d
where event pr
On Tue, Jan 17, 2017 at 11:48:22AM -0800, Brian Norris wrote:
> On Sun, Jan 15, 2017 at 04:54:52PM -0800, Dmitry Torokhov wrote:
> > On Fri, Jan 13, 2017 at 03:35:37PM -0800, Brian Norris wrote:
> > > The following sequence occurs when using IEEE power-save on 8997:
> > > (a) driver sees SLEEP even
From: Felix Fietkau
Implements an optional, per bridge port flag and feature to deliver
multicast packets to any host on the according port via unicast
individually. This is done by copying the packet per host and
changing the multicast destination MAC to a unicast one accordingly.
multicast-to-
On Sun, Jan 15, 2017 at 04:54:52PM -0800, Dmitry Torokhov wrote:
> On Fri, Jan 13, 2017 at 03:35:37PM -0800, Brian Norris wrote:
> > The following sequence occurs when using IEEE power-save on 8997:
> > (a) driver sees SLEEP event
> > (b) driver issues SLEEP CONFIRM
> > (c) driver recevies CMD inte
From: Rafał Miłecki
This change intends to make init/attach process easier to follow.
What driver were doing in brcmf_bus_start wasn't bus specific at all and
function brcmf_bus_stop wasn't undoing things done there. It seems
brcmf_detach was actually undoing things done in both: brcmf_attach an
From: Rafał Miłecki
Driver used to call brcmf_bus_detach only from one place and it already
contained a check for drvr not being NULL. We can get rid of this extra
function, call brcmf_bus_stop directly and simplify the code.
There also isn't brcmf_bus_attach function which one could expect so it
From: Rafał Miłecki
Function brcmf_c_set_joinpref_default is in common.c, so move it to the
related header. All other (touched) ones are in core.c so take them out
of the bus.h.
I just needed to include bus.h to have enum brcmf_bus_state defined.
Signed-off-by: Rafał Miłecki
---
.../net/wirele
From: Rafał Miłecki
Functions brcmf_c_prec_enq and brcmf_sdio_init don't exist so we
really don't need their declarations. Function brcmf_parse_tlvs is used
in cfg80211.c only so make it static and drop from header as well.
Signed-off-by: Rafał Miłecki
---
drivers/net/wireless/broadcom/brcm802
Board Data File (BDF) is loaded upon driver boot-up procedure. The right
board data file is identified, among others, by device and sybsystem ids.
The problem, however, can occur when the (default) board data file cannot
fulfill with the vendor requirements and it is necessary to use a different
b
Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> This reverts commit 4c81acab3816 ("bcma: init serial console directly
> from ChipCommon code") as it broke IRQ assignment. Getting IRQ with
> bcma_core_irq helper on SoC requires MIPS core to be set. It happens
> *after* ChipCommon initialization so
Larry Finger wrote:
> In commit c93ac39da0064 ("rtlwifi: Remove some redundant code), a goto
> statement was inadvertently left in the code.
>
> Fixes: c93ac39da0064 ("rtlwifi: Remove some redundant code)
> Reported-by: kbuild test robot
> Signed-off-by: Larry Finger
Patch applied to wireless-
Brian Norris wrote:
> Similar to commit fcd2042e8d36 ("mwifiex: printk() overflow with 32-byte
> SSIDs"), we failed to account for the existence of 32-char SSIDs in our
> debugfs code. Unlike in that case though, we zeroed out the containing
> struct first, and I'm pretty sure we're guaranteed to
Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> Our code was assigning number of channels to the index variable by
> default. If firmware reported channel we didn't predict this would
> result in using that initial index value and writing out of array. This
> never happened so far (we got a comple
Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> During init we take care of regulatory stuff by disabling all
> unavailable channels (see brcmf_construct_chaninfo) so this predisabling
> them is not really required (and this patch won't change any behavior).
> It will on the other hand allow more
Stanislaw Gruszka wrote:
> On rt2800usb, if we do not get TX status from HW, we assume frames were
> posted and after entry->last_action timeout, we forcibly provide TX
> status to mac80211. So it's not possible to detect hardware TX hung
> based on the timeout. Additionally TXRQ_PCNT tells on num
Arnd Bergmann wrote:
> Checking the firmware status from PCIe register only works
> if the register is available, otherwise we end up with
> random behavior:
>
> drivers/net/wireless/marvell/mwifiex/pcie.c: In function
> 'mwifiex_pcie_remove':
> drivers/net/wireless/marvell/mwifiex/pcie.c:585:5:
Kalle Valo writes:
> Stephen Rothwell writes:
>
>> Hi all,
>>
>> After merging the wireless-drivers-next tree, today's linux-next build
>> (x86_64 allmodconfig) produced this warning:
>>
>> drivers/net/wireless/marvell/mwifiex/pcie.c: In function
>> 'mwifiex_pcie_remove':
>> drivers/net/wireles
Amitkumar Karwar writes:
> Hi Kalle,
>
>> From: Kalle Valo [mailto:kv...@codeaurora.org]
>> Sent: Thursday, January 12, 2017 8:25 PM
>> To: Amitkumar Karwar
>> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
>> raja...@google.com; briannor...@google.com; dmitry.torok...@gmail.c
Rafał Miłecki writes:
> From: Rafał Miłecki
>
> We have generic place & helpers for storing platform driver data so
> there is no reason for using custom priv pointer.
>
> This allows cleaning up struct bcma_sflash from unneeded fields.
>
> Signed-off-by: Rafał Miłecki
> ---
> Kalle: This is mt
Hi Kalle,
> From: Kalle Valo [mailto:kv...@codeaurora.org]
> Sent: Thursday, January 12, 2017 8:25 PM
> To: Amitkumar Karwar
> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
> raja...@google.com; briannor...@google.com; dmitry.torok...@gmail.com;
> Xinming Hu
> Subject: Re: [1/
41 matches
Mail list logo
