On Wed, Apr 19, 2017 at 01:34:46PM +1000, Tobin C. Harding wrote:
> Hi Wolfram,
>
> May I please ask you with an ks7010 driver endianness question?
>
> Comments on the hostif_hdr data structure (ks_hostif.h) state that the
> target uses little endian byte order.
>
> /*
> * HOST-MAC I/F data
Hi Wolfram,
May I please ask you with an ks7010 driver endianness question?
Comments on the hostif_hdr data structure (ks_hostif.h) state that the
target uses little endian byte order.
/*
* HOST-MAC I/F data structure
* Byte alignmet Little Endian
*/
struct hostif_hdr {
u16 size;
These two patches finish the updates to btcoex for the 4.12 streeam.
Larry
Signed-off-by: Yan-Hsuan Chuang
Signed-off-by: Larry Finger
Cc: Pkshih
Cc: Birming Chiu
Cc: Shaofu
Cc:
From: Yan-Hsuan Chuang
Add if define ... endif to fix the unused warnings for 21a 2ant. The
routines in question are not needed at the moment, but will be
needed in the near future.
Signed-off-by: Yan-Hsuan Chuang
Signed-off-by: Larry Finger
From: Yan-Hsuan Chuang
Updates btcoexist to a newer version with some callbacks.
pre_load_firmware()
fix the unstable issues before FW is ready
power_on_seting()
fix the unstable issues before HW is ready
Add some notify functions, check hardware type and
On 18 April 2017 at 02:41, Johannes Berg wrote:
> On Thu, 2017-04-13 at 14:44 -0700, Joe Stringer wrote
> (something that never made it to the list, due to HTML formatting)
>>
>> I think that OVS was doing some more elaborate validation than most
>> users, so over time
Hi Johan,
On Tue, Apr 18, 2017 at 12:09:16PM +0200, Johan Hovold wrote:
> On Thu, Mar 30, 2017 at 12:15:34PM +0200, Johan Hovold wrote:
> > This started out with the observation that the nfcmrvl_uart driver
> > unconditionally dereferenced the tty class device despite the fact that
> > not every
Hi David,
This is the NFC pull request for 4.12. We have:
- Improvements for the pn533 command queue handling and device
registration order.
- Removal of platform data for the pn544 and st21nfca drivers.
- Additional device tree options to support more trf7970a hardware options.
- Support for
From: Sara Sharon
When FW fails to get block ack, it will send the notification with
0 items in the TFD queue elements. Allow this and handle accordingly.
Fixes: c46e7724bfe9 ("iwlwifi: mvm: support new BA notification response")
Signed-off-by: Sara Sharon
From: Liad Kaufman
Memory offsets and lengths for A000 HW is different
than currently specified.
Fixes: e34d975e40ff ("iwlwifi: Add a000 HW family support")
Signed-off-by: Liad Kaufman
Signed-off-by: Luca Coelho
---
From: Sara Sharon
Address 4 is reversed as well.
Signed-off-by: Sara Sharon
Signed-off-by: Luca Coelho
---
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff
From: Sara Sharon
API was changed once more to support 2 LMACs.
Adapt to change while preserving current functionality.
Signed-off-by: Sara Sharon
Signed-off-by: Luca Coelho
---
From: Sara Sharon
When we get SN that is smaller than SSN of the aggregation,
we shouldn't apply any reordering on them.
Further more, HW NSSN will be zeroed, which can cause us
to make some invalid decisions.
Detect the situation and invalidate the BAID.
Fixes:
From: Emmanuel Grumbach
The notification infrastructure (iwl_notification_wait_*
functions) allows to wait until a list of notifications
will come up from the firmware and to run a special handler
(notif_wait handler) when those are received.
The operation mode
From: Emmanuel Grumbach
In the end, the firmware doesn't want the SP len as present
in the WMM IE, but rather the actual number of frames.
Fixes: bd3c6cf901a8 ("iwlwifi: mvm: tell the firmware about the U-APSD
parameters")
Signed-off-by: Emmanuel Grumbach
From: Sara Sharon
Identify and load FW for a000 CDB product.
Signed-off-by: Sara Sharon
Signed-off-by: Luca Coelho
---
drivers/net/wireless/intel/iwlwifi/iwl-a000.c | 20
From: Sara Sharon
In a000 CDB firmware, we cannot update phy context to a
different band - we must first remove it and add it
again. Support this flow for all a000 devices since
we may have various combinations that cause us to fail
regardless if CDB is active.
From: Sara Sharon
Currently when rate isn't found (invalid rate or CCK rate in high
band) driver is assigning rate -1, which causes mac80211 to dump
it later with the cryptic rate value of 0xFF.
Instead, warn early and dump the frame in mvm.
Signed-off-by: Sara Sharon
From: Sara Sharon
For a000 devices, we don't really have multi RX queue for now,
until we have the RX queue configuration API.
Disable RX queue notification for now.
Signed-off-by: Sara Sharon
Signed-off-by: Luca Coelho
From: Emmanuel Grumbach
Omit 7265D and 3168 since those are now stuck on 30.
Signed-off-by: Emmanuel Grumbach
Signed-off-by: Luca Coelho
---
drivers/net/wireless/intel/iwlwifi/iwl-8000.c | 4 ++--
From: Tzipi Peres
Add one new PCI ID for the 8265 series.
Add three new PCI ID for the 8275 series.
Signed-off-by: Tzipi Peres
Signed-off-by: Luca Coelho
---
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 4
1 file
From: Haim Dreyfuss
To utilize the maximum allowed tx power, an additional table was added
to the BIOS. The table consists of up to seven different regions
(currently only three are in use). Each region contains per band:
1. Maximum allowed tx power on the band.
2. Tx
From: Sara Sharon
When we load firmware in extended mode (as we do by default for
now) driver should send a command what kind of commands ucode
should stop and wait for before proceeding with phy calibrations.
Support this command. Currently we only do NVM access - so mark
From: Luca Coelho
This workaround is not needed anymore. Remove it.
Signed-off-by: Luca Coelho
---
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 46 -
1 file changed, 46 deletions(-)
diff --git
From: Sara Sharon
In TVQM mode the queue ID is assigned after enablement.
Get rid of assuming pre-defined TX queue ID in functions
that will be used by TVQM allocation path.
Signed-off-by: Sara Sharon
Signed-off-by: Luca Coelho
From: Sara Sharon
Seems like HW is reversing addr3 in the MAC header of de-aggregated
AMSDU. Reverse it back.
Signed-off-by: Sara Sharon
Signed-off-by: Luca Coelho
---
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 7
From: Sara Sharon
In TVQM firmware returns the value of the queue ID and code
should accept it.
The TX queue config API was changed. Move to new API.
This has to be done in parallel in mvm and pcie.
Do not move yet to 512 queues since there are some opens
with enabling it.
From: David Spinadel
Change the value of TX_CMD_SEC_KEY_FROM_TABLE flag
in TX_CMD security flags to accommodate a FW API change.
Bump min API for 9000 series devices to 30 to keep the driver aligned
aligned the FW.
Signed-off-by: David Spinadel
From: Sara Sharon
This flag is used for mac80211 reordering. As we do reordering
ourselves, turning it on is misleading and pointless.
Signed-off-by: Sara Sharon
Signed-off-by: Luca Coelho
---
From: Liad Kaufman
Not only that this write is not needed (as FW does this
itself), on newer HW this register is write protected
so trying to write there will cause problems.
Signed-off-by: Liad Kaufman
Signed-off-by: Luca Coelho
From: Sara Sharon
In TVQM mode the TX responses were changed to include
queue number since legacy TX queue number retrieval cannot
be scaled up to 512 queues.
Support this change.
Signed-off-by: Sara Sharon
Signed-off-by: Luca Coelho
From: Sara Sharon
Access should be by rcu_dereference. Issue was found by sparse.
Fixes: 65e254821cee ("iwlwifi: mvm: use firmware station PM notification for
AP_LINK_PS")
Signed-off-by: Sara Sharon
Signed-off-by: Luca Coelho
From: Luca Coelho
The "invalid" label was a bit ugly and unnecessary. Remove it.
Signed-off-by: Luca Coelho
---
drivers/net/wireless/intel/iwlwifi/mvm/rx.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git
From: Luca Coelho
Hi,
This is the third patch set intended for v4.12. These are the changes:
* Heavy work for the A000 device series;
* Some cleanup patches;
* A couple of fixes;
* Start supporting FW API version 31;
* Geographical SAR support;
* Support a few
On 4/18/2017 10:55 AM, Johannes Berg wrote:
On Tue, 2017-04-18 at 10:53 +0200, Johannes Berg wrote:
Hi Arend,
Overall this looks good, and I've almost applied it - but I have a
question on this patch.
You have this list:
+ struct list_head sched_scan_req_list;
struct
On 04/18/2017 09:33 AM, Steve deRosier wrote:
Hi,
On Tue, Apr 18, 2017 at 7:50 AM, Simon Wunderlich > wrote:
Hi,
On Tuesday, April 18, 2017 2:36:54 PM CEST Kalle Valo wrote:
> Simon Wunderlich
Hi,
(sorry, resending due to my not noticing that gmail had changed my
default compose mode to HTML. Why does it randomly do that
sometimes?!?!)
On Tue, Apr 18, 2017 at 7:50 AM, Simon Wunderlich
wrote:
>
> Hi,
>
> On Tuesday, April 18, 2017 2:36:54 PM CEST Kalle Valo
Hi,
On Tuesday, April 18, 2017 2:36:54 PM CEST Kalle Valo wrote:
> Simon Wunderlich wrote:
> > From: Ben Greear
> >
> > Many chips support channels in licensed bands. Add support for those,
> > along with a corresponding kernel config option to
Simon Wunderlich wrote:
> From: Ben Greear
>
> Many chips support channels in licensed bands. Add support for those,
> along with a corresponding kernel config option to disable them by
> default. Note that these channels are not selectable even
Luca Coelho writes:
> On Tue, 2017-04-18 at 06:56 +, Kalle Valo wrote:
>> Kalle Valo writes:
>>
>> > Luca Coelho writes:
>> >
>> > > git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git
>> > >
When part of a bigger bandwidth (160 MHz) channel falls in DFS
channel range it is possible that the center frequency may not
necessarily be a radar channel. Remove the sanity check on channel
flag for IEEE80211_CHAN_RADAR in regulatory_propagate_dfs_state(),
this should fix the dfs state
On Tuesday 18 April 2017 04:20 PM, Johannes Berg wrote:
>
>> +void regulatory_propagate_dfs_state(struct wiphy *wiphy,
>> +struct cfg80211_chan_def
>> *chandef,
>> +enum nl80211_dfs_state
>> dfs_state,
>> +
On Thu, Apr 13, 2017 at 08:14:23AM +0530, Aditya Shankar wrote:
> On Tue, 11 Apr 2017 19:35:46 +0200
> Greg KH wrote:
>
> > On Tue, Apr 11, 2017 at 10:11:43PM +0530, Aditya Shankar wrote:
> > > Change the config packet format used in handle_set_wfi_drv_handler()
> > >
On Tue, Apr 11, 2017 at 10:11:43PM +0530, Aditya Shankar wrote:
> Change the config packet format used in handle_set_wfi_drv_handler()
> to align the host driver with the new format used in the wilc firmware.
>
> The change updates the format in which the host driver provides the
> firmware with
So actually, come to think of it ...
> > The mapping in samples/bpf/bpf_helpers.h, for example, for
> > mentioned
> > bpf_skb_load_bytes() would also work out of the box, since it takes
> > a
> > void *ctx as an argument, so you can just pass the __wifi_sk_buff
> > pointer as ctx there from
On Tue, 2017-04-18 at 12:58 +0200, Daniel Borkmann wrote:
>
> Note that for skbs the data / data_end model (aka direct read /
> write) is also supported. There's also a bpf_skb_pull_data() helper
> that pulls in data from non-linear parts if necessary (f.e. if data /
> data_end test in the
On 04/18/2017 11:55 AM, Johannes Berg wrote:
On Fri, 2017-04-14 at 11:51 -0700, Alexei Starovoitov wrote:
so today only 'len' field is needed,
Correct, the other __sk_buff fields don't apply.
It's more of an XDP model (with data/data_end), but as the SKB might be
non-linear at this point I
Dear Good Friend,
Sorry if this email came to you as a surprise,I am Dr.Dawuda Usman and
we are looking for a company or individual from your region to help us receive
investment fund and safekeeping.I will send you full details As soon
As I hear from you.
Thanks
Dr.Dawuda Usman
> +void regulatory_propagate_dfs_state(struct wiphy *wiphy,
> + struct cfg80211_chan_def
> *chandef,
> + enum nl80211_dfs_state
> dfs_state,
> + enum nl80211_radar_event event)
> +{
> + struct
Hi Xuebing,
I didn't try the QSDK on those devices, mainly because of its poor upstream
support/community involvement. We tried it on other devices, with "mixed"
results.
Cheers,
Simon
On Monday, April 17, 2017 10:19:02 PM CEST Xuebing Wang wrote:
> Hi Sven and Simon,
>
> Thank you
On Thu, Mar 30, 2017 at 12:15:34PM +0200, Johan Hovold wrote:
> This started out with the observation that the nfcmrvl_uart driver
> unconditionally dereferenced the tty class device despite the fact that
> not every tty has an associated struct device (Unix98 ptys). Some
> further changes were
On Fri, 2017-03-31 at 06:33 -0700, Ben Greear wrote:
>
> In my experience, the big problem with netlink is that if you write
> a patch that cannot make it upstream (or takes forever), then the
> netlink IDs conflict as upstream adds more stuff.
Sure, that's a common problem we all run into :)
>
On Fri, 2017-04-14 at 11:51 -0700, Alexei Starovoitov wrote:
>
> so today only 'len' field is needed,
Correct, the other __sk_buff fields don't apply.
It's more of an XDP model (with data/data_end), but as the SKB might be
non-linear at this point I prefer to have the SKB so that skb data
From: Tomislav Požega
update RF register 47 and 54 values according to vendor driver
Signed-off-by: Tomislav Požega
Signed-off-by: Daniel Golle
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 6 --
1 file
On Thu, 2017-04-13 at 14:44 -0700, Joe Stringer wrote
(something that never made it to the list, due to HTML formatting)
>
> I think that OVS was doing some more elaborate validation than most
> users, so over time we picked up a bunch of extra parsing code that
> layers on top of nla_parse(). I
From: Tomislav Požega
Use register values from init LNA function instead of the ones from
restore LNA function. Apply register values based on rx path
configuration.
Signed-off-by: Tomislav Požega
Signed-off-by: Daniel Golle
Hi Dave,
I hadn't realized that I actually had this many patches pending,
but most of them really are cleanups and little fixes. Despite a
bunch of driver changes, there don't seem to be any conflicts.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes
On Mon, 2017-04-17 at 15:59 -0700, Matthias Kaehlcke wrote:
> rate_flg is of type 'enum nl80211_attrs', however it is assigned with
> 'enum nl80211_rate_info' values. Change the type of rate_flg
> accordingly.
Applied this, and the other two patches you had (IBSS enum and array-
bounds)
johannes
On Thu, 2017-04-13 at 13:06 +0100, Arend van Spriel wrote:
> For multi-scheduled scan support in subsequent patch a request id
> will be added. This patch add this request id to the scheduled
> scan event messages. For now the request id will always be zero.
> With multi-scheduled scan its value
On Tue, 2017-04-18 at 10:53 +0200, Johannes Berg wrote:
> Hi Arend,
>
> Overall this looks good, and I've almost applied it - but I have a
> question on this patch.
>
> You have this list:
>
> > + struct list_head sched_scan_req_list;
> > struct cfg80211_sched_scan_request __rcu
Hi Arend,
Overall this looks good, and I've almost applied it - but I have a
question on this patch.
You have this list:
> + struct list_head sched_scan_req_list;
> struct cfg80211_sched_scan_request __rcu *sched_scan_req;
but you kept this. In fact, it's even still *used*. I don't
Hi Dave,
Here's a single remaining fix - it's not even super urgent for
this cycle since it's in a "fringe" feature, but it's for an
SKB out-of-bounds access.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit
On Tue, 2017-04-18 at 06:56 +, Kalle Valo wrote:
> Kalle Valo writes:
>
> > Luca Coelho writes:
> >
> > > Here's my first pull-request intended for v4.12. This is generic
> > > development work, nothing really stands out. More
> > > details in the
Kalle Valo writes:
> Luca Coelho writes:
>
>> Here's my first pull-request intended for v4.12. This is generic
>> development work, nothing really stands out. More
>> details in the tag description.
>>
>> I have sent this out before, and kbuildbot
Luca Coelho writes:
> Here's my first pull-request intended for v4.12. This is generic
> development work, nothing really stands out. More
> details in the tag description.
>
> I have sent this out before, and kbuildbot reported success.
>
> Please let me know if there are any
Hi,
Linus released 4.11-rc7 and said that it might be the last rc release.
Which means that the merge window is really close and I need to get all
the patches ready before it opens. So if there's anything you want to
have in 4.12 submit them NOW for wireless-drivers-next.
_Important_ bug fixes
66 matches
Mail list logo