On Friday, June 24, 2016 02:34:30 PM Martin Blumenstingl wrote:
> This makes it possible to configure ath9k based devices using
> devicetree. That makes some out-of-tree "convert devicetree to
> ath9k_platform_data glue"-code obsolete.
Hm, what about the embedded ath9k pcie chips that need the ear
On Sat, Jun 25, 2016 at 2:01 PM, Christian Lamparter
wrote:
> On Friday, June 24, 2016 02:34:30 PM Martin Blumenstingl wrote:
>> This makes it possible to configure ath9k based devices using
>> devicetree. That makes some out-of-tree "convert devicetree to
>> ath9k_platform_data glue"-code obsolet
The mac80211_hwsim driver is currently defining the QCA vendor ID
0x001374 for some reason.
Also, all current vendor commands are using the "QCA_" prefix, hence the
reason why I decided to add the new vendor command with the "QCA_"
prefix as well.
Anyway, I understand that you don't want the
On Sat, Jun 25, 2016 at 06:08:01PM +0200, Erik Stromdahl wrote:
> The mac80211_hwsim driver is currently defining the QCA vendor ID
> 0x001374 for some reason.
That is used for allowing nl80211 vendor specific commands and events to
be tested. The particular vendor command was properly assigned fr
Flag rfchange_inprogress in struct rtl_ps_ctl is protected by a spinlock
in most routines but not in rtl88e_dm_watchdog(), which could
lead to a race condition. The necessary locking to prevent this condition
is added.
Reported-by: Pavel Andrianov
Signed-off-by: Larry Finger
Cc: Pavel Andrianov
Commit 4b9d8d67b44a ("rtlwifi: rtl8192cu: Remove unused parameter") reworked
this routine. Those changes were later reverted by commit d3feae41a347
("rtlwifi: Update power-save routines for 062814 driver").
There were two changes in commit 4b9d8d67b44a. The first of these removed
a parameter from
This set of patches removes an unused paramter from routine
rtl_ps_set_rf_state()
in rtlwifi. The routine is also no longer exported. In addition, a potential
race condition in 5 of the drivers is fixed.
This material is suitable for kernel 4.8. To my knowledge, the race condition
has not been sh
Flag rfchange_inprogress in struct rtl_ps_ctl is protected by a spinlock
in most routines but not in rtl8723e_dm_watchdog(), which could
lead to a race condition. The necessary locking to prevent this condition
is added.
Reported-by: Pavel Andrianov
Signed-off-by: Larry Finger
Cc: Pavel Andriano
Flag rfchange_inprogress in struct rtl_ps_ctl is protected by a spinlock
in most routines but not in rtl8723be_dm_watchdog(), which could
lead to a race condition. The necessary locking to prevent this condition
is added.
Reported-by: Pavel Andrianov
Signed-off-by: Larry Finger
Cc: Pavel Andrian
Flag rfchange_inprogress in struct rtl_ps_ctl is protected by a spinlock
in most routines but not in rtl92ee_dm_watchdog(), which could
lead to a race condition. The necessary locking to prevent this condition
is added.
Reported-by: Pavel Andrianov
Signed-off-by: Larry Finger
Cc: Pavel Andrianov
Flag rfchange_inprogress in struct rtl_ps_ctl is protected by a spinlock
in most routines but not in rtl8821ae_dm_watchdog() which could
lead to a race condition. The necessary locking to prevent this condition
is added.
Reported-by: Pavel Andrianov
Signed-off-by: Larry Finger
Cc: Pavel Andriano
Hello Ben,
On Thu, Jun 23, 2016 at 10:12:01AM -0700, Ben Greear wrote:
> On 06/23/2016 09:40 AM, Mohammed Shafi Shajakhan wrote:
> >From: Mohammed Shafi Shajakhan
> >
> >For chipsets like QCA99X0, IPQ4019 and later we are not getting proper
> >NULL func status (always acked/successs !!) when host
On Saturday, June 25, 2016 05:08:29 PM Martin Blumenstingl wrote:
> On Sat, Jun 25, 2016 at 2:01 PM, Christian Lamparter
> wrote:
> > On Friday, June 24, 2016 02:34:30 PM Martin Blumenstingl wrote:
> >> This makes it possible to configure ath9k based devices using
> >> devicetree. That makes some
The rtlwifi family of drivers use similar routines to extract hardware
information from EFUSE. This set of patches create a common routine to
extract this data, and converts most of the drivers to use this routine.
In addition, a complicated set of if ... else if ... else statements are
present in
The driver for RTL8723AE chips is converted to use the common routine
for getting the hardware information.
Reported-by: Arnd Bergmann
Signed-off-by: Larry Finger
Cc: Arnd Bergmann
---
.../net/wireless/realtek/rtlwifi/rtl8723ae/hw.c| 76 --
1 file changed, 11 insertions
All of the rtlwifi family of drivers have a similar routine that acquires
the hardware info from efuse and initializes a number of variables in the
driver's private area. A common routine is created for all drivers to use.
Reported-by: Arnd Bergmann
Signed-off-by: Larry Finger
Cc: Arnd Bergmann
The driver for RTL8192DE chips is converted to use the common routine
for getting the hardware information.
Reported-by: Arnd Bergmann
Signed-off-by: Larry Finger
Cc: Arnd Bergmann
---
.../net/wireless/realtek/rtlwifi/rtl8192de/hw.c| 77 +-
1 file changed, 15 insertions
This driver contains some complicated if ... else if ... else constructions.
These are replaced by switch statements to improve readability.
Signed-off-by: Larry Finger
---
.../net/wireless/realtek/rtlwifi/rtl8723ae/hw.c| 210 +++--
1 file changed, 107 insertions(+), 103 dele
The driver for RTL8821AE chips is converted to use the common routine
for getting the hardware information.
Reported-by: Arnd Bergmann
Signed-off-by: Larry Finger
Cc: Arnd Bergmann
---
.../net/wireless/realtek/rtlwifi/rtl8821ae/hw.c| 84 +++---
1 file changed, 11 insertions
The driver for RTL8192CE chips is converted to use the common routine
for getting the hardware information.
Reported-by: Arnd Bergmann
Signed-off-by: Larry Finger
Cc: Arnd Bergmann
---
.../net/wireless/realtek/rtlwifi/rtl8192ce/hw.c| 83 --
1 file changed, 12 insertions
The driver for RTL8723BE chips is converted to use the common routine
for getting the hardware information.
Reported-by: Arnd Bergmann
Signed-off-by: Larry Finger
Cc: Arnd Bergmann
---
.../net/wireless/realtek/rtlwifi/rtl8723be/hw.c| 74 --
1 file changed, 12 insertions
The driver for RTL8192EE chips is converted to use the common routine
for getting the hardware information.
Reported-by: Arnd Bergmann
Signed-off-by: Larry Finger
Cc: Arnd Bergmann
---
.../net/wireless/realtek/rtlwifi/rtl8192ee/hw.c| 73 --
1 file changed, 12 insertions
The driver for RTL8188EE chips is converted to use the common routine
for getting the hardware information.
Reported-by: Arnd Bergmann
Signed-off-by: Larry Finger
Cc: Arnd Bergmann
---
.../net/wireless/realtek/rtlwifi/rtl8188ee/hw.c| 76 --
1 file changed, 13 insertions
The driver for RTL8192CU chips is converted to use the common routine
for getting the hardware information.
Reported-by: Arnd Bergmann
Signed-off-by: Larry Finger
Cc: Arnd Bergmann
---
.../net/wireless/realtek/rtlwifi/rtl8192cu/hw.c| 61 ++
1 file changed, 15 insertions
On Sat, 2016-06-25 at 21:32 +0300, Jouni Malinen wrote:
>
> All you need to do is to prepare a hostap.git contribution that
> requests a new subcommand/attribute to be assigned and once that gets
> applied to the hostap.git master branch, the values have been
> assigned and can be used for whateve
[1.] Broadcom Corporation BCM43602 - wrong icon after resume
[2.] After suspending and resuming the cabled icon is shown instead of
wifi. The WiFi still works.
On startup it shows some strange errors on dmesg:
Bluetooth: hci0: BCM20703A1
Bluetooth: hci0: BCM (001.001.005) build
IPv6: ADDRCONF
On Thu, Jun 23, 2016 at 01:36:18PM +0100, Luis de Bethencourt wrote:
> If there was an error, returning -EINVAL is more appropriate than -1.
>
> Signed-off-by: Luis de Bethencourt
> Reviewed-by: Julian Calaby
> ---
> drivers/staging/wilc1000/wilc_debugfs.c | 4 ++--
> 1 file changed, 2 insertio
On Thu, Jun 23, 2016 at 01:36:17PM +0100, Luis de Bethencourt wrote:
> The common format to check if a function returned an error pointer is to
> use PTR_ERR(). Instead of ERR_PTR() which is used to return said errors.
>
> Signed-off-by: Luis de Bethencourt
> Reviewed-by: Julian Calaby
> ---
>
On 25/06/16 22:36, Greg KH wrote:
> On Thu, Jun 23, 2016 at 01:36:17PM +0100, Luis de Bethencourt wrote:
>> The common format to check if a function returned an error pointer is to
>> use PTR_ERR(). Instead of ERR_PTR() which is used to return said errors.
>>
>> Signed-off-by: Luis de Bethencourt
When sending an email regarding a patch to wilc1000, you get the following
automatic replies:
"Sung_hoon Cho is no longer with Atmel Corporation."
"Kang_hee Park is no longer with Atmel Corporation."
"Dong_ho Shin is no longer with Atmel Corporation."
"Bo_moon Kim is no longer with Atmel Corporatio
When sending an email regarding a patch to wilc1000, you get the following
automatic replies:
"Sung_hoon Cho is no longer with Atmel Corporation."
"Kang_hee Park is no longer with Atmel Corporation."
"Dong_ho Shin is no longer with Atmel Corporation."
"Bo_moon Kim is no longer with Atmel Corporatio
This debugging macro can expand to a lot of code.
Make it a function to reduce code size.
(x86-64 defconfig w/ all rtlwifi drivers and allyesconfig)
$ size drivers/net/wireless/realtek/rtlwifi/built-in.o*
textdata bss dec hex filename
900083 2004991907 1102489 10d299
dri
We've accumulated a couple of different fixes now to mesh_sta_cleanup()
due to the different paths that user_mpm and !user_mpm cases take -- one
fix to flush nexthop paths and one to fix the counting.
The only caller of mesh_plink_deactivate() is mesh_sta_cleanup(), so we
can push the user_mpm che
On Sat, 2016-06-25 at 14:53 -0500, Larry Finger wrote:
> This driver contains some complicated if ... else if ... else constructions.
> These are replaced by switch statements to improve readability.
[]
> diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c
> b/drivers/net/wireless/rea
On Sat, 2016-06-25 at 14:53 -0500, Larry Finger wrote:
> All of the rtlwifi family of drivers have a similar routine that acquires
> the hardware info from efuse and initializes a number of variables in the
> driver's private area. A common routine is created for all drivers to use.
[]
> diff --git
On 06/25/2016 11:53 AM, Mohammed Shafi Shajakhan wrote:
Hello Ben,
On Thu, Jun 23, 2016 at 10:12:01AM -0700, Ben Greear wrote:
On 06/23/2016 09:40 AM, Mohammed Shafi Shajakhan wrote:
From: Mohammed Shafi Shajakhan
For chipsets like QCA99X0, IPQ4019 and later we are not getting proper
NULL fu
36 matches
Mail list logo
