Jens Axboe writes:
> 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 de
From: Ping-Ke Shih
btcoex needs to sleep, thus it must run in thread context.
Signed-off-by: Ping-Ke Shih
Signed-off-by: Larry Finger
---
drivers/net/wireless/realtek/rtlwifi/base.c| 92 ++
drivers/net/wireless/realtek/rtlwifi/base.h| 3 +
.../net/wireless
From: Ping-Ke Shih
When ant_sel is set, we need to fill single_ant_path to select correct
antenna path.
Signed-off-by: Ping-Ke Shih
Signed-off-by: Larry Finger
---
drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/driv
From: Ping-Ke Shih
File halbtcoutsrc.c is a better place for routine rtl_get_hwpg_ant_num()
than file rtl_btc.c.
Signed-off-by: Ping-Ke Shih
Signed-off-by: Larry Finger
---
.../net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c| 12
drivers/net/wireless/realtek/rtlwifi/btc
From: Ping-Ke Shih
The new code handles the package-type of the chip.
Signed-off-by: Ping-Ke Shih
Signed-off-by: Larry Finger
---
.../realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 7 +
.../wireless/realtek/rtlwifi/btcoexist/rtl_btc.h | 2 ++
drivers/net/wireless/realtek/rtlwifi/efu
From: Ping-Ke Shih
Routine rtl_get_hwpg_bt_type() is better in halbtcoutsrc.c than in
rtl_btc.c.
Signed-off-by: Ping-Ke Shih
Signed-off-by: Larry Finger
---
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 5 +
drivers/net/wireless/realtek/rtlwifi/btcoexist/rtl_btc.c |
From: Ping-Ke Shih
Some devices with RTL8732BE wifi/Bluetooth adapters are shipped with only
a single antenna. On a subset of these, the EEPROM is incorectly coded
to indicate the wrong connection. The resulting problems have been fixed
for wifi. This change handles them for BT.
Signed-off-by: P
From: Ping-Ke Shih
The new value is needed for future capability.
Signed-off-by: Ping-Ke Shih
Signed-off-by: Larry Finger
---
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc
These 11 changes fix a number of deficiencies. None of them are
serious enough to be pushed to stable; however they help in the
stability of the drivers, and in the robustness of authentication/
association.
This material should be sent to the 4.11 stream.
Signed-off-by: Larry Finger
---
Larry F
From: Ping-Ke Shih
There is a potential race condition when the control byte of a CAM
entry is written first. Write in reverse order to correct the condition.
Signed-off-by: Ping-Ke Shih
Signed-off-by: shaofu
Signed-off-by: Larry Finger
---
drivers/net/wireless/realtek/rtlwifi/cam.c | 6 +++-
From: Ping-Ke Shih
We assign different retry limit according to vif type, because
it can boost performance in field.
Signed-off-by: Ping-Ke Shih
Signed-off-by: shaofu
Signed-off-by: Larry Finger
---
drivers/net/wireless/realtek/rtlwifi/core.c | 21 ++---
drivers/net/wireless/
This routine uses its own debugging macros These are changed to use the
the recently rewritten RT_TRACE macro. There are also some renamed
variables that were missed in the previous step.
The only functional change is that some debugging statements have been
dropped based on the final code supplie
From: Ping-Ke Shih
Routine halbtc_get() will need to be able to get the vendor ID.
Signed-off-by: Ping-Ke Shih
Signed-off-by: Larry Finger
---
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 3 +++
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h | 7 +++
2 fi
On Wed, Dec 21, 2016 at 11:18:33PM -0500, Geoff Lansberry wrote:
> The TRF7970A has configuration options for supporting hardware designs
> with 1.8 Volt or 3.3 Volt IO. This commit adds a device tree option,
> using a fixed regulator binding, for setting the io voltage to match
> the hardware co
On 01/20/2017 08:14 AM, Bharat Kumar Gogada wrote:
> 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 chec
Hi
On Fri, Jan 20, 2017 at 03:32:19PM +0100, Daniel Golle wrote:
> On Fri, Jan 20, 2017 at 02:28:23PM +0100, Stanislaw Gruszka wrote:
> > Repost patches from Daniel with updated clock handling and
> > correct author of RT5350 patch.
> >
> > Note I did not test patches on SOC devices, but getting
On 20/01/17 15:45, Ben Greear wrote:
On 01/20/2017 06:29 AM, Wojciech Dubowik wrote:
I have been debugging customer reported timeout and loss of
communication and I have relaized that I don't have such a lossy
environment available in the lab. To speed up debugging I have
written frame corru
On 20/01/17 16:07, Kalle Valo wrote:
+config ATH9K_FRAME_LOSS_SIMULATOR
+ bool "Atheros ath9k frame loss simulator"
+ depends on ATH9K && ATH9K_DEBUGFS && DEBUG_FS
+ default n
+ ---help---
+ Say N. This option should be used only to test fail paths
+ and
Wojciech Dubowik writes:
> Add debugfs entries to corrupt specified frame types
> by invering fcs field upon transmissionm with given probability.
>
> Select frames to be corrupted.
> /corrupt_fcs_fram_mask:
> Bit 16 - Null function
> Bit 15 - QoS Null function
> Bit 14 - EAPOL
> Bit 13 - Act
On 01/20/2017 06:29 AM, Wojciech Dubowik wrote:
I have been debugging customer reported timeout and loss of
communication and I have relaized that I don't have such a lossy
environment available in the lab. To speed up debugging I have
written frame corruption simulator which will allow me to
t
Hi Stanislaw,
On Fri, Jan 20, 2017 at 02:28:23PM +0100, Stanislaw Gruszka wrote:
> Repost patches from Daniel with updated clock handling and
> correct author of RT5350 patch.
>
> Note I did not test patches on SOC devices, but getting
> clock frequency is simple and should be trouble-free.
Than
When this flag is present the transmitted frame fcs field
bits are inverted in hardware so the frame is being treated
as corrupted on the recevieng node.
It's used by frame corruption simulator coming on the following
patch.
Signed-off-by: Wojciech Dubowik
---
drivers/net/wireless/ath/ath9k/ar90
I have been debugging customer reported timeout and loss of
communication and I have relaized that I don't have such a lossy
environment available in the lab. To speed up debugging I have
written frame corruption simulator which will allow me to
totally loose specific types of packets. I have been
Add debugfs entries to corrupt specified frame types
by invering fcs field upon transmissionm with given probability.
Select frames to be corrupted.
/corrupt_fcs_fram_mask:
Bit 16 - Null function
Bit 15 - QoS Null function
Bit 14 - EAPOL
Bit 13 - Action
Bit 12 - Deauthentication
Bit 11 - Aut
> 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
On Fri, Jan 20, 2017 at 02:28:24PM +0100, Stanislaw Gruszka wrote:
> Since clk_get() is not trivial add copy of clk pointer to rt2x00dev
> for System On Chip devices and initialize it on probe routine.
>
> Signed-off-by: Stanislaw Gruszka
Acked-by: Daniel Golle
Since clk_get() is not trivial add copy of clk pointer to rt2x00dev
for System On Chip devices and initialize it on probe routine.
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/ralink/rt2x00/rt2x00.h| 4
drivers/net/wireless/ralink/rt2x00/rt2x00soc.c | 1 +
2 files changed,
From: Daniel Golle
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
Repost patches from Daniel with updated clock handling and
correct author of RT5350 patch.
Note I did not test patches on SOC devices, but getting
clock frequency is simple and should be trouble-free.
Daniel Golle (1):
rt2x00: rt2800lib: add support for RT3352 with 20MHz crystal
Serge Vasilugi
From: Serge Vasilugin
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 G
On Thu, Jan 19, 2017 at 02:38:45PM +0100, Daniel Golle wrote:
> 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.htm
Hi Daniel
On Fri, Jan 20, 2017 at 12:42:44AM +0100, Daniel Golle wrote:
> +int rt2800_probe_clk(struct rt2x00_dev *rt2x00dev)
> +{
> + struct hw_mode_spec *spec = &rt2x00dev->spec;
> + struct clk *clk = clk_get(rt2x00dev->dev, NULL);
> +
> + if (IS_ERR(clk))
> + return PTR_
On 20 January 2017 at 13:51, Kalle Valo wrote:
> Michal Kazior wrote:
>> Firmware files are versioned to prevent older
>> driver instances to load unsupported firmware
>> blobs. This is reflected with a fallback logic
>> which attempts to load several firmware files.
>>
>> This however produced a
On 20 January 2017 at 12:37, Arend Van Spriel
wrote:
> On 20-1-2017 12:17, Rafał Miłecki wrote:
>> On 01/20/2017 11:26 AM, Arend Van Spriel wrote:
>>> On 18-1-2017 15:27, Rafał Miłecki wrote:
From: Rafał Miłecki
This macro accepts an extra argument of struct brcmf_pub pointer. It
>
Michal Kazior wrote:
> Firmware files are versioned to prevent older
> driver instances to load unsupported firmware
> blobs. This is reflected with a fallback logic
> which attempts to load several firmware files.
>
> This however produced a lot of unnecessary
> warnings sometimes confusing user
David Miller writes:
> 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:
>>>
I'm responsible for
On 20-1-2017 12:17, Rafał Miłecki wrote:
> On 01/20/2017 11:26 AM, Arend Van Spriel wrote:
>> On 18-1-2017 15:27, Rafał Miłecki wrote:
>>> From: Rafał Miłecki
>>>
>>> This macro accepts an extra argument of struct brcmf_pub pointer. It
>>> allows referencing struct device and printing error using
On 01/20/2017 11:26 AM, Arend Van Spriel wrote:
On 18-1-2017 15:27, Rafał Miłecki wrote:
From: Rafał Miłecki
This macro accepts an extra argument of struct brcmf_pub pointer. It
allows referencing struct device and printing error using dev_err. This
is very useful on devices with more than one
Hi,
>
>
> This patch should be enhanced with the smb_xx() calls as suggested by by Lino.
>
If you do this, please place the smp_rmb() before the if condition in the irq
handler like
smp_rmb();
if (rtlpci->irq_enabled == 0) {
return ret;
as I think that the suggestion I made before was no
On 20-1-2017 11:58, Rafał Miłecki wrote:
> On 20 January 2017 at 11:14, Arend Van Spriel
> wrote:
>> On 20-1-2017 11:13, Arend Van Spriel wrote:
>>> On 18-1-2017 15:27, Rafał Miłecki wrote:
From: Rafał Miłecki
This allows simplifying the code by adding a simple IS_ENABLED check for
On 20 January 2017 at 11:14, Arend Van Spriel
wrote:
> On 20-1-2017 11:13, Arend Van Spriel wrote:
>> On 18-1-2017 15:27, Rafał Miłecki wrote:
>>> From: Rafał Miłecki
>>>
>>> This allows simplifying the code by adding a simple IS_ENABLED check for
>>> CONFIG_BRCMDB symbol.
>
> Actually it should
On 18-1-2017 15:27, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> This macro accepts an extra argument of struct brcmf_pub pointer. It
> allows referencing struct device and printing error using dev_err. This
> is very useful on devices with more than one wireless card suppored by
> brcmfmac.
On 16 January 2017 at 11:17, Martin Blumenstingl
wrote:
> BCM43455 is a more recent revision of the BCM4345. Some of the BCM43455
> got a dedicated SDIO device ID which is currently not supported by
> brcmfmac.
> Adding the new sdio_device_id to brcmfmac is enough to get the BCM43455
> supported b
On 19-1-2017 10:51, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> It was left after reworking PCIe reset in commit 07fe2e38c7fd
> ("brcmfmac: Reset PCIE devices after recognition.").
>
> Cc: Hante Meuleman
Acked-by: Arend van Spriel
> Signed-off-by: Rafał Miłecki
> ---
> drivers/net/wireles
Larry Finger wrote:
> 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
3 patches applied to wireless-drivers-next.git, thanks.
On 20-1-2017 11:13, Arend Van Spriel wrote:
> On 18-1-2017 15:27, Rafał Miłecki wrote:
>> From: Rafał Miłecki
>>
>> This allows simplifying the code by adding a simple IS_ENABLED check for
>> CONFIG_BRCMDB symbol.
Actually it should be CONFIG_BRCMDBG above.
Kalle,
Can you fix that in the commit
On 18-1-2017 15:27, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> This allows simplifying the code by adding a simple IS_ENABLED check for
> CONFIG_BRCMDB symbol.
Nice!
Acked-by: Arend van Spriel
> Signed-off-by: Rafał Miłecki
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
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
Rafał Miłecki wrote:
> 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
> Acked
Gavin Li 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 regression (due to dropp
Jes Sorensen wrote:
> 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
5 patches applied to wireless-drivers-next.git, thanks.
d607e396566a rtl8xxxu: Mark 8192eu device 0x
Martin Blumenstingl wrote:
> BCM43455 is a more recent revision of the BCM4345. Some of the BCM43455
> got a dedicated SDIO device ID which is currently not supported by
> brcmfmac.
> Adding the new sdio_device_id to brcmfmac is enough to get the BCM43455
> supported because the chip itself is alr
Brian Norris wrote:
> Marvell folks tell me this is a debugging event that the driver doesn't
> need to handle, but on 8997 w/ firmware 16.68.1.p97, I see several of
> these sorts of messages at (for instance) boot time:
>
> [ 13.825848] mwifiex_pcie :01:00.0: event: unknown event id: 0x63
Brian Norris wrote:
> Depending on system factors (e.g., the PCIe link PM state), the first
> read to wake up the Wifi firmware can take a long time. There is no
> reason to use a (blocking, non-posted) read at this point, so let's just
> use a write instead. Write vs. read doesn't matter function
Extend ieee80211_cqm_rssi_notify with a rssi_level parameter so that
this information can be passed to netlink clients in the next patch, if
available. Most drivers will have this value at hand. wl1251 receives
events from the firmware that only tell it whether latest measurement
is above or belo
Change the SET CQM command's RSSI threshold attribute to accept any
number of thresholds as a sorted array. The API should be backwards
compatible so that if one s32 threshold value is passed the old
mechanism is enabled. The netlink event generated is the same in both
cases. Userspace can check
Support .set_cqm_rssi_range_config if the beacons are available for
processing in mac80211. There's no reason that this couldn't be
offloaded by mac80211-based drivers but there's no driver method for
that added in this patch as I don't have the hardware.
The NL80211_EXT_FEATURE_CQM_RSSI_LIST fea
Update the drivers to pass the RSSI level as a cfg80211_cqm_rssi_notify
parameter and pass this value to userspace in a new nl80211 attribute.
This helps both userspace and also helps in the implementation of the
multiple RSSI thresholds CQM mechanism.
Note for marvell/mwifiex I pass 0 for the RSS
58 matches
Mail list logo
