On 20 January 2017 at 03:42, Shawn Lin wrote:
> On 2017/1/19 22:13, Ulf Hansson wrote:
>>
>> +Shawn
>>
>> On 13 January 2017 at 06:29, Matt Ranostay
>> wrote:
>>>
>>> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
>>> This can be abstracted to other chipsets if needed in the future.
On 2017/1/19 22:13, Ulf Hansson wrote:
+Shawn
On 13 January 2017 at 06:29, Matt Ranostay wrote:
Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
This can be abstracted to other chipsets if needed in the future.
Cc: Tony Lindgren
Cc: Ulf Hansson
Signed-off-by: Matt Ranostay
---
On 01/19/2017 04:14 AM, Bharat Kumar Gogada wrote:
-Realtek 8192CE chipset maintains local irq flags after enabling/disabling
hardware interrupts.
-Hardware interrupts are enabled before enabling the local irq
flags(these flags are being checked in interrupt handler),
leading to race condition on
Hi Michel,
[auto build test ERROR on wireless-drivers-next/master]
[cannot apply to v4.10-rc4 next-20170119]
[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/Daniel-Golle/rt2x00-add-support-for
On Wed, Dec 21, 2016 at 11:18:32PM -0500, Geoff Lansberry wrote:
> The TRF7970A has configuration options to support hardware designs
> which use a 27.12MHz clock. This commit adds a device tree option
> 'clock-frequency' to support configuring the this chip for default
> 13.56MHz clock or the opti
On Rt3352 the driver needs to know the frequency of an external
crystal which can be either 40 MHz (as on all other WiSoCs until now)
or 20 MHz.
Get the clock attached by ramips WiSoC platform code which probes
SYSC_REG_SYSCFG (added by John Crispin in commit 6ac8579b96e3b) and
introduce a new flag
Hi,
On 19.01.2017 19:08, Larry Finger wrote:
On 01/19/2017 08:35 AM, Lino Sanfilippo wrote:
Hi,
altek/rtlwifi/rtl8192ce/hw.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
index a47be73..143766c4 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
+++ b/drivers/net/wirel
This driver is being added for Fedora users, and will then be added
to the mainline kernel.
Signed-off-by: Larry Finger
c: Hans de Goede
---
WHENCE | 13 +
rtlwifi/rtl8723bs_ap_wowlan.bin | Bin 0 -> 20886 bytes
rtlwifi/rtl8723bs_bt.bin| Bin 0 -> 91
On Thu, Jan 19, 2017 at 02:30:14PM +0100, Daniel Golle wrote:
> Hi Stanislaw,
>
> On Wed, Jan 18, 2017 at 03:30:02PM +0100, Stanislaw Gruszka wrote:
> > On Mon, Jan 16, 2017 at 04:15:56AM +0100, Daniel Golle wrote:
> > > Signed-off-by: Gabor Juhos
> > > Signed-off-by: Mathias Kresin
> > > Signed
On Thu, Jan 19, 2017 at 09:08:34PM +0200, Kalle Valo wrote:
> Daniel Golle writes:
>
> > From: Michel Stempin
> >
> > Support for the RT5350 WiSoC was added to OpenWrt after having a
> > lengthy debate about the legality of the original submission, see
> > https://lists.openwrt.org/pipermail/ope
The firmware is read from disk as a little-endian byte string. The code
that loads the firmware into the device transfers it as 4-byte quantities.
The routines that write multi-byte quantities on BE hardware assume that
the data are in CPU order, and automatically do the conversion to the LE
order
These drivers use a set of complicated macros to extract and insert
information for the RX and TX descriptors. Driver rtl8192cu had a
different set than was used for the PCI-based drivers. To simplify
the code, rtl8192cu is switched to use the common version. In the
process, two errors in those com
Although these drivers do not have any Sparse messages indication
problems with endian operations, there are two places where the
information being processed is little endian, but was being processed
in cpu order. The first of these is in downloading firmware. Rather
than do a double conversion for
This driver requires a checksum for the descriptors so that the wifi
chip is assured that the USB transmission was correct. These entries
are little-endian, but the driver was always using cpu order in the
calculation. As a result, the driver failed on BE hardware.
Signed-off-by: Larry Finger
Cc:
On 19 January 2017 at 21:10, Kalle Valo wrote:
> Ulf Hansson writes:
>
>> Twisting my head around how this could be integrated smoothly into
>> pwrseq simple. No, I just can find a good way forward without messing
>> up pwrseq simple itself.
>>
>> So, for now I decided (once more :-), that let's
Ulf Hansson writes:
> Twisting my head around how this could be integrated smoothly into
> pwrseq simple. No, I just can find a good way forward without messing
> up pwrseq simple itself.
>
> So, for now I decided (once more :-), that let's keep this as separate driver!
>
> Perhaps, following dev
From: Kalle Valo
Date: Thu, 19 Jan 2017 20:08:30 +0200
> "John W. Linville" writes:
>
>> I forgot to Cc Johannes and Kalle...
>
> Also adding linux-wireless.
>
>> On Thu, Jan 19, 2017 at 09:15:09AM -0500, John W. Linville wrote:
>>> On Thu, Jan 19, 2017 at 07:35:22AM -0500, David Arcari wrote
On Thu, 19 Jan 2017 03:45:10 +0100
Linus Lüssing wrote:
> 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
Daniel Golle writes:
> From: Michel Stempin
>
> Support for the RT5350 WiSoC was added to OpenWrt after having a
> lengthy debate about the legality of the original submission, see
> https://lists.openwrt.org/pipermail/openwrt-devel/2013-January/018224.html
> MTK/Ralink Acked replied and says we
"John W. Linville" writes:
> I forgot to Cc Johannes and Kalle...
Also adding linux-wireless.
> On Thu, Jan 19, 2017 at 09:15:09AM -0500, John W. Linville wrote:
>> On Thu, Jan 19, 2017 at 07:35:22AM -0500, David Arcari wrote:
>> > On 01/18/2017 11:45 AM, David Miller wrote:
>> > > From: David
On 01/19/2017 08:35 AM, Lino Sanfilippo wrote:
Hi,
altek/rtlwifi/rtl8192ce/hw.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
index a47be73..143766c4 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
@@ -1306,9 +1
These two debugging formss implement debugging using rather complicated
macro constructions. These are replaced with compiled code that is easier
to understand.
Signed-off-by: Larry Finger
Cc: Ping-Ke Shih
---
V2 - No changes.
---
drivers/net/wireless/realtek/rtlwifi/debug.c | 42 ++
As the kernel provides access to module parameters through entries in
/sys/module//parameters/, there is no need for a private
interface. Thus the existing code for setting the debug level is
removed.
Reported-by: Kalle Valo
Signed-off-by: Larry Finger
Cc: Ping-Ke Shih
---
V2 - Switched the dyn
This set of patches modifies the debug system by replacing some
complicated macros with the equivalent operations in C. Then, the
COMP_XX component debugging is converted into a debug mask. Finally,
code that allows the dynamic setting of the debug level is removed.
All that functionality is alread
The debugging macros contain a parameter COMP_XX that could be used as a
mask; however, the code turns all these various bits on at the same time.
This change implements them as a proper mask, and adds module parameters
to set the mask at load time.
The current name "debug" for the debug level has
Hi,
altek/rtlwifi/rtl8192ce/hw.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
> index a47be73..143766c4 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
> @@ -1306,9 +1306,9 @@ void rtl92ce_enable_interrupt(str
+Shawn
On 13 January 2017 at 06:29, Matt Ranostay wrote:
> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
> This can be abstracted to other chipsets if needed in the future.
>
> Cc: Tony Lindgren
> Cc: Ulf Hansson
> Signed-off-by: Matt Ranostay
> ---
> drivers/mmc/core/Kconfig
Hi Johannes,
Sorry for the late response:(
On 2017-01-09 16:06, Johannes Berg wrote:
Is it fine to have something like this
1) We can have this btcoex_priority value as a optional value in
btcoex enable command like below
iw phyX btcoex_state [prirority(vendor spcific
value)]
2) Or we can h
From: Michel Stempin
Support for the RT5350 WiSoC was added to OpenWrt after having a
lengthy debate about the legality of the original submission, see
https://lists.openwrt.org/pipermail/openwrt-devel/2013-January/018224.html
MTK/Ralink Acked replied and says we can merge this patch under the GP
Wei Yongjun wrote:
> From: Wei Yongjun
>
> Fixes the following sparse warning:
>
> drivers/net/wireless/ath/ath6kl/sdio.c:716:55: warning:
> Using plain integer as NULL pointer
>
> Signed-off-by: Wei Yongjun
Patch applied to ath-next branch of ath.git, thanks.
96d179b517a9 ath6kl: fix warn
Hi Stanislaw,
On Wed, Jan 18, 2017 at 03:30:02PM +0100, Stanislaw Gruszka wrote:
> On Mon, Jan 16, 2017 at 04:15:56AM +0100, Daniel Golle wrote:
> > Signed-off-by: Gabor Juhos
> > Signed-off-by: Mathias Kresin
> > Signed-off-by: Daniel Golle
> > ---
> > drivers/net/wireless/ralink/rt2x00/rt280
Kalle Valo wrote:
> From: Mohammed Shafi Shajakhan
>
> Dump Copy Engine source and destination ring addresses.
> This is useful information to debug firmware crashes, assertes or hangs over
> long run
> assessing the Copy Engine Register status. This also enables dumping CE
> register status in
Mohammed Shafi Shajakhan wrote:
> From: Mohammed Shafi Shajakhan
>
> Not clearing the previous tx bit rate status
> results in a ambigous tx bit rate reporting to
> mac80211/cfg80211, for example the previous bit
> rate status would have been marked as legacy rate
> , while the current rate woul
Michal Kazior wrote:
> Station pointers are RCU protected so driver must
> be extra careful if it tries to store them
> internally for later use outside of the RCU
> section it obtained it in.
>
> It was possible for station teardown to race with
> some htt events. The possible outcome could be a
On 19-1-2017 13:36, Lior David wrote:
> On 1/19/2017 2:24 PM, Valo, Kalle wrote:
>> Maya Erez writes:
>>
>>> From: Lior David
>>>
>>> In fine timing measurements, the calculation is affected by
>>> 2 parts: timing of packets over the air, which is platform
>>> independent, and platform-specific d
On 19-1-2017 13:00, Luca Coelho wrote:
> On Thu, 2017-01-19 at 10:01 +, Arend van Spriel wrote:
>> For wowlan netdetect a separate limit is defined for the number of
>> matchsets. Currently, this limit is ignored and the regular limit
>> for scheduled scan matchsets, ie. struct wiphy::max_mat
Stanislaw Gruszka wrote:
> Since rt2800pci update beacon settings asynchronously from
> tbtt tasklet, without beacon_skb_mutex protection, number of
> currently active beacons entries can be different than
> number pointed by rt2x00dev->intf_beaconing. Remove warning
> about that inconsistency.
>
On 18 January 2017 at 08:50, Matt Ranostay wrote:
> 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 sequenc
Daniel Golle wrote:
> From: Serge Vasilugin
>
> Simple patch to correct HT20/HT40 filter setting.
> Tested with Rt3290, Rt3352 and Rt5350
>
> Signed-off-by: Serge Vasilugin
> Signed-off-by: Daniel Golle
> Acked-by: Stanislaw Gruszka
3 patches applied to wireless-drivers-next.git, thanks.
e
Amitkumar Karwar wrote:
> From: Xinming Hu
>
> We already ensure 64 bytes alignment and add padding if required
> during skb_aggr allocation.
>
> Alignment and padding in mwifiex_11n_form_amsdu_txpd() is redundant.
> We may end up accessing more data than allocated size with this.
>
> This pat
Larry Finger wrote:
> The firmware is read from disk as a little-endian byte string. The code
> that loads the firmware into the device transfers it as 4-byte quantities.
> The routines that write multi-byte quantities on BE hardware assume that
> the data are in CPU order, and automatically do th
Pan Bian wrote:
> Function lbs_cmd_802_11_sleep_params() always return 0, even if the call
> to lbs_cmd_with_response() fails. In this case, the parameter @sp will
> keep uninitialized. Because the return value is 0, its caller (say
> lbs_sleepparams_read()) will not detect the error, and will cop
Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> We may want to use Open Firmware for other devices than just SDIO ones.
> In future we may want to support more Broadcom properties so there is
> really no reason for such limitation.
>
> Call brcmf_of_probe for all kind of devices & move extra cond
On 1/19/2017 2:24 PM, Valo, Kalle wrote:
> Maya Erez writes:
>
>> From: Lior David
>>
>> In fine timing measurements, the calculation is affected by
>> 2 parts: timing of packets over the air, which is platform
>> independent, and platform-specific delays, which are dependent
>> on things like a
Maya Erez writes:
> From: Lior David
>
> In fine timing measurements, the calculation is affected by
> 2 parts: timing of packets over the air, which is platform
> independent, and platform-specific delays, which are dependent
> on things like antenna cable length and type.
> Add a sysfs file wh
On Thu, 2017-01-19 at 10:01 +, Arend van Spriel wrote:
> For wowlan netdetect a separate limit is defined for the number of
> matchsets. Currently, this limit is ignored and the regular limit
> for scheduled scan matchsets, ie. struct wiphy::max_match_sets, is
> used for the net-detect case as
-Realtek 8192CE chipset maintains local irq flags after enabling/disabling
hardware interrupts.
-Hardware interrupts are enabled before enabling the local irq
flags(these flags are being checked in interrupt handler),
leading to race condition on some RP, where the irq line between
bridge and G
For wowlan netdetect a separate limit is defined for the number of
matchsets. Currently, this limit is ignored and the regular limit
for scheduled scan matchsets, ie. struct wiphy::max_match_sets, is
used for the net-detect case as well.
Cc: Luciano Coelho
Signed-off-by: Arend van Spriel
---
ne
On 19/01/17 03:45, Linus Lüssing wrote:
> 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 destinat
From: Rafał Miłecki
It was left after reworking PCIe reset in commit 07fe2e38c7fd
("brcmfmac: Reset PCIE devices after recognition.").
Cc: Hante Meuleman
Signed-off-by: Rafał Miłecki
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 1 -
1 file changed, 1 deletion(-)
diff --git a
Larry Finger writes:
> On 01/18/2017 08:49 AM, Kalle Valo wrote:
>> Larry Finger wrote:
>>> The previous commit changes the debug system to use a mask to select
>>> which components are to be debugged. Now, we add the necessary code
>>> to change the mask from sysfs.
>>>
>>> Signed-off-by: Larry
Gavin Li writes:
> I think calling this a performance regression is a bit understated; my
> download speed jumped from 1Mbit/s back up to 40MBit/s after applying
> the patch due to the sheer amount of packets being incorrectly
> processed.
>
> In addition, processing arbitrary data frames as firm
Gavin Li writes:
> Should I make a v4 patch with an updated log?
No need, I'll just copy your description of the bug to the commit log
before I commit it.
--
Kalle Valo
53 matches
Mail list logo
