On 6/19/2018 5:48 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
Most of firmwares support creating monitor interface. The newest ones
explicitly /announce/ it using a "monitor" entry in the list of
capabilities.
Check (and store) internally info about monitor mode support using a
new feature
On 6/19/2018 5:48 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
New Broadcom firmwares mark monitor mode packets using a newly defined
bit in the flags field. Use it to filter them out and pass to the
monitor interface. These defines were found in bcmmsgbuf.h from SDK.
As not every firmware
On pre-emption enabled kernels the following oops was being seen due to
missing local_bh_disable/local_bh_enable calls. mac80211 assumes that
pre-emption is disabled in the data path.
[ 5365.229756] Call Trace:
[ 5365.229762] dump_stack+0x5c/0x80
[ 5365.229766]
From: Rafał Miłecki
After a bit long discussions in various e-mail threads I'm coming with
this simple & small patchset. It isn't complete support for monitor mode
but just a pair of preparing patches that should be clear & well
discussed by now to make them acceptable.
The main missing bit is
From: Rafał Miłecki
New Broadcom firmwares mark monitor mode packets using a newly defined
bit in the flags field. Use it to filter them out and pass to the
monitor interface. These defines were found in bcmmsgbuf.h from SDK.
As not every firmware generates radiotap header this commit
From: Rafał Miłecki
Most of firmwares support creating monitor interface. The newest ones
explicitly /announce/ it using a "monitor" entry in the list of
capabilities.
Check (and store) internally info about monitor mode support using a
new feature flag. Once we sort out all details of handling
On 6/19/2018 5:48 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
After a bit long discussions in various e-mail threads I'm coming with
this simple & small patchset. It isn't complete support for monitor mode
but just a pair of preparing patches that should be clear & well
discussed by now to
On Tue, 19 Jun 2018 at 07:36, Rafał Miłecki wrote:
> On Mon, 18 Jun 2018 at 23:46, Rafał Miłecki wrote:
> > On Mon, 18 Jun 2018 at 21:36, Arend van Spriel
> > wrote:
> > >
> > > On 6/18/2018 1:54 PM, Rafał Miłecki wrote:
> > > > On Mon, 11 Jun 2018 at 12:48, Arend van Spriel
> > > > wrote:
> >
This is from my hacked 4.16.15+ kernel, with modified ath10k FW
that likes to crash a lot.
In this case, FW crashed near an ath10k module reload. I am not sure
if this is a bug in ath10k in particular, or mac80211 locking, or
a combination of both.
ath10k_pci :04:00.0: firmware crashed!
> Am I understanding correctly that in the latter (outgoing) case this
> might cause unencrypted packets to be transmitted?
Yes, if we have a driver handling the keys similar to ath9k which is not
implementing drv_flush (correctly) this is a possibility.
This ties somewhat into the discussion
On 2018-06-19 22:01, Arend van Spriel wrote:
On 6/19/2018 5:48 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
After a bit long discussions in various e-mail threads I'm coming with
this simple & small patchset. It isn't complete support for monitor
mode
but just a pair of preparing patches
Changes from v2:
- Fix amsdu setting in BA response
- Remove crash dump collection from OTP sectionas it can cause PCIe halt
Changes from v1:
- Removal of module parameters
- Addition of debugfs entries for configuring enhanced DMA
- Fixing kbuild bot error
- Enabling AMSDU by default (based on
Add changes to support initialization of Talyn-MB wil6210
device:
- Add definition for Talyn-MB new JTAG id
- Define talyn_mb_fw_mapping array
- Add Talyn-MB reset sequence
Signed-off-by: Maya Erez
---
drivers/net/wireless/ath/wil6210/main.c | 48 +++--
From: Gidon Studinski
In enhanced DMA the vrings are handled internally by the FW
and are not exposed to the driver.
Instead, the driver handles descriptor rings, which are mapped
by the FW to vrings.
The completions of the TX and RX descriptors are notified to
the driver using status rings.
In some cases where the device is stuck, reading from OTP
can timeout. As OTP section is known there is no need to read
it during device crash dump collection.
Adding a new field to struct fw_map to indicate if to include
this section in crash dump collection.
Signed-off-by: Maya Erez
---
From: Gidon Studinski
Enhanced DMA design includes the following rings:
- Single RX descriptor ring is used for all VIFs
- Multiple RX status rings are supported, to allow RSS
- TX descriptor ring is allocated per connection
- A single TX status ring is used for all TX descriptor rings
This
Talyn-MB introduces various of FW download options:
FW download via PCIe, SPI or PBL for secured access.
The boot and FW download path is determined based on the
OTP HW register. Driver reads this register as part of the
SW reset flow and performs the appropriate initialization
sequence.
From: Gidon Studinski
Enhanced DMA RX data path is handled using a single
RX descriptor ring for all VIFs.
Multiple RX status rings are supported, to allow RSS
and multi MSI support.
The driver gets the RX completions via the RX status rings.
The RX status message includes the completed RX
The enhanced DMA TX data path is handled using a descriptor
ring per connection and a single status ring.
The driver gets TX completions via the TX status ring. Each
status message points to the completed descriptor ring and
includes the number of completed descriptors in this ring.
Non TSO
Add debugfs support for enhanced DMA TX and RX descriptor rings,
TX and RX status rings and RX buffer management.
Run the following command to print the TX and RX status rings:
cat srings
Run the following command in order to select the status ring:
echo STATUS_RING_IDX > dbg_sring_index
Run
Hi Johannes,
> On Jun 15, 2018, at 7:30 AM, Johannes Berg wrote:
>
> On Fri, 2018-06-15 at 11:09 +, McGinn, Dan wrote:
>> Hi, I'm newly trying out Intel iwd daemon but I experience regular kernel
>> errors in 4.17, although WPA2-PSK connection remains stable. These errors
>> don't seem
On 6/19/2018 9:27 AM, Rafał Miłecki wrote:
On Mon, 11 Jun 2018 at 12:48, Arend van Spriel
wrote:
On 5/30/2018 1:52 PM, Rafał Miłecki wrote:
I'm providing extra version info of tested firmware images as requested
by Arend in another e-mail thread.
Looking into our firmware repo it there are
We can update wlcore to use PM runtime by adding functions for
wlcore_runtime_suspend() and wlcore_runtime_resume() and replacing
calls to wl1271_ps_elp_wakeup() and wl1271_ps_elp_sleep() with calls
to pm_runtime_get_sync() and pm_runtime_put().
Note that the new wlcore_runtime_suspend() and
On 19.06.2018 09:53, Arend van Spriel wrote:
On 6/19/2018 9:27 AM, Rafał Miłecki wrote:
On Mon, 11 Jun 2018 at 12:48, Arend van Spriel
wrote:
On 5/30/2018 1:52 PM, Rafał Miłecki wrote:
I'm providing extra version info of tested firmware images as requested
by Arend in another e-mail thread.
With runtime PM enabled, we now need to have wlcore enabled longer
until after we're done calling wlcore_cmd_regdomain_config_locked():
scan_complete_work()
wlcore_cmd_regdomain_config_locked()
wlcore_cmd_send_failsafe()
wl12xx_sdio_raw_read()
Note that this is not needed before runtime
From: Eyal Reizer
With runtime PM enabled, we can now use calls to pm_runtime_force_suspend
and pm_runtime_force_resume for enabling elp during suspend when wowlan
is enabled and waking the chip from elp on resume.
Remove the custom API that was used to ensure that the command
that is used to
With runtime PM tested working for wlcore with no autosuspend, we can
now enable autosuspend to cut down on enable/disable for interrupts.
Basically we just replace pm_runtime_put() with the autosuspend variants.
Let's use autosuspend delay of 50ms that MMC drivers typically use.
Signed-off-by:
We have wl12xx_boot() call wl12xx_enable_interrupts() and if we have
wl1271_op_add_interface() call pm_runtime_get_sync() before the interrupts
are enabled. And then we get the following error during boot:
wlcore: ERROR ELP wakeup timeout!
Let's fix this by first checking if we need to boot the
Otherwise we can get:
WARNING: CPU: 0 PID: 55 at drivers/net/wireless/ti/wlcore/io.h:84
I've only seen this few times with the runtime PM patches enabled
so this one is probably not needed before that. This seems to
work currently based on the current PM implementation timer. Let's
apply this
Hi all,
Here's the fourth version of wlcore runtime PM changes. Please
test one more time.
For testing, please make sure you have also applied patch
"[PATCHv2] wlcore: sdio: Fix flakey SDIO runtime PM handling"
to avoid bogus errors.
Regards,
Tony
Changes since v3:
- Fixed remaining known
After enabling runtime PM, if we force hardware reset multiple times with:
# echo 1 > /sys/kernel/debug/ieee80211/phy0/wlcore/start_recovery
We will after few tries get the following error:
wlcore: ERROR timeout waiting for the hardware to complete initialization
And then wlcore is unable to
The call to wl1271_ps_elp_wakeup() in wl12xx_queue_recovery_work() is
unpaired. Let's remove it and add paired calls to wl1271_recovery_work()
instead in preparation for changing things to use runtime PM.
Signed-off-by: Tony Lindgren
---
drivers/net/wireless/ti/wlcore/main.c | 10 --
1
On 2018-06-15 17:16, Janusz Dziedzic wrote:
2018-06-14 9:50 GMT+02:00 Arend van Spriel
:
On 6/13/2018 5:10 PM, Toke Høiland-Jørgensen wrote:
Tamizh Chelvam Raja writes:
This patchsets introduced new NL command and api to support
configuring txrate threshold for the connected stations and
On Mon, 11 Jun 2018 at 12:48, Arend van Spriel
wrote:
> On 5/30/2018 1:52 PM, Rafał Miłecki wrote:
> > I'm providing extra version info of tested firmware images as requested
> > by Arend in another e-mail thread.
>
> Looking into our firmware repo it there are two flags, ie. WL_MONITOR
> and
On 6/19/2018 10:32 AM, Rafał Miłecki wrote:
On 19.06.2018 09:53, Arend van Spriel wrote:
On 6/19/2018 9:27 AM, Rafał Miłecki wrote:
On Mon, 11 Jun 2018 at 12:48, Arend van Spriel
wrote:
On 5/30/2018 1:52 PM, Rafał Miłecki wrote:
I'm providing extra version info of tested firmware images as
Good Day;
Dear Respectful One,
I am SALINAS ROMANS from France. Please go through below my mail and
see if you can Assist for Our mutual benefit, My late Father was a
serving director of the Cocoa exporting board in lvory coast until his
death.
He died in motor accident one week after his trip
36 matches
Mail list logo
