[PATCH net-next] net: bgmac: support Ethernet core on BCM53573 SoCs

From: Rafał Miłecki BCM53573 is a new series of Broadcom's SoCs. It's based on ARM and can be found in two packages (versions): BCM53573 and BCM47189. It shares some code with the Northstar family, but also requires some new quirks. First of all there can be up to 2 Ethernet

Re: [Make-wifi-fast] [PATCH v2] mac80211: Move crypto IV generation to after TXQ dequeue.

> well, we're getting there. the results of both patch attempts were > really nice, and brought encrypted performance with fq back into line > with unencrypted. Still running crypted tests as I write... > > So fixing TKIP would be next, forcing the AP to use that? What other > scenarios do we

Re: [PATCH v2] mac80211: Move crypto IV generation to after TXQ dequeue.

Hi, You need to work on coding style, a lot of your indentation is completely messed up. > + switch (sdata->vif.type) { > + case NL80211_IFTYPE_STATION: > + if (sdata->u.mgd.use_4addr) { > + pn_offs = 30; > + break; > + } >

Re: [Make-wifi-fast] [PATCH v2] mac80211: Move crypto IV generation to after TXQ dequeue.

On Wed, Aug 17, 2016 at 9:49 PM, Johannes Berg wrote: > Hi, > > You need to work on coding style, a lot of your indentation is > completely messed up. > >> + switch (sdata->vif.type) { >> + case NL80211_IFTYPE_STATION: >> + if

Re: [PATCHv6 1/2] add basic register-field manipulation macros

On Wed, Aug 17, 2016 at 10:11 AM, Jakub Kicinski wrote: > On Wed, 17 Aug 2016 09:33:26 -0700, Linus Torvalds wrote: >> >> I'm not a huge fan, since the interface fundamentally seems to be >> oddly designed (why pass in the mask rather than "start bit + >> length"?).

Re: [PATCHv6 1/2] add basic register-field manipulation macros

On Wed, 17 Aug 2016 09:33:26 -0700, Linus Torvalds wrote: > On Wed, Aug 17, 2016 at 3:31 AM, Kalle Valo wrote: > > > > Are people ok with this? I think they are useful and I can take these > > through my tree, but I would prefer to get an ack from other maintainers > >

Re: [PATCHv6 1/2] add basic register-field manipulation macros

On Wed, Aug 17, 2016 at 3:31 AM, Kalle Valo wrote: > > Are people ok with this? I think they are useful and I can take these > through my tree, but I would prefer to get an ack from other maintainers > first. Dave? Andrew? I'm not a huge fan, since the interface

[PATCH] ath10k: improve wake_tx_queue ops performance

txqs_lock is interfering with wake_tx_queue submitting more frames. so queues don't get filled in and don't keep firmware/hardware busy enough. This change helps to reduce the txqs_lock contention and wake_tx_queue() blockage to being possible in txrx_unref(). To reduce turn around time of

[PATCH v2] mac80211: Move crypto IV generation to after TXQ dequeue.

The FQ portion of the intermediate queues will reorder packets, which means that crypto IV generation needs to happen after dequeue when they are enabled, or the receiver will throw packets away when receiving them. This fixes the performance regression introduced by enabling softq in ath9k. Cc:

Re: [PATCH] mac80211: Move crypto IV generation to after TXQ dequeue.

Johannes Berg writes: > On Wed, 2016-08-17 at 15:16 +0200, Toke Høiland-Jørgensen wrote: >> Johannes Berg writes: >> >> > >> > > >> > > @@ -1573,6 +1574,7 @@ struct ieee80211_key_conf { >> > >  u8 iv_len; >> > >  u8

Re: [PATCH] mac80211: Move crypto IV generation to after TXQ dequeue.

On Wed, 2016-08-17 at 15:16 +0200, Toke Høiland-Jørgensen wrote: > Johannes Berg writes: > > > > > > > > > @@ -1573,6 +1574,7 @@ struct ieee80211_key_conf { > > >   u8 iv_len; > > >   u8 hw_key_idx; > > >   u8 flags; > > > + u8 pn_offs; > > > > > This is completely

Re: [PATCH] mac80211: Move crypto IV generation to after TXQ dequeue.

Johannes Berg writes: >> @@ -1573,6 +1574,7 @@ struct ieee80211_key_conf { >>  u8 iv_len; >>  u8 hw_key_idx; >>  u8 flags; >> +u8 pn_offs; >> > This is completely wrong. Well, the ieee80211_fast_tx struct is not available in ieee80211_tx_dequeue, and

Re: [PATCH] mac80211: Move crypto IV generation to after TXQ dequeue.

> @@ -1573,6 +1574,7 @@ struct ieee80211_key_conf { >   u8 iv_len; >   u8 hw_key_idx; >   u8 flags; > + u8 pn_offs; > This is completely wrong. johannes

[PATCH] mac80211: Move crypto IV generation to after TXQ dequeue.

The FQ portion of the intermediate queues will reorder packets, which means that crypto IV generation needs to happen after dequeue when they are enabled, or the receiver will throw packets away when receiving them. This fixes the performance regression introduced by enabling softq in ath9k. Cc:

Re: On the ath9k performance regression with FQ and crypto

Felix Fietkau writes: > I have not done any further tests, but based on your analysis, I think I > finally understand what's causing this issue: > The CCMP PN (crypto IV) is assigned in the tx path before a packet is > put into the txq. It is also used to protect against replay

Re: Configuring Minstrel-Blues

Hi Mike, I am working on the Minstrel-Blues part to get it integrated into minstrel_ht. My working demo is with ath5k an legacy minstrel. As soon as I have a testing patch, I am going to announce it here. Greetings from Berlin Thomas > On 15 Aug 2016, at 23:41, Mike Mu

[PATCH] ath10k: suppress warnings when getting wmi WDS peer event id

From: Mohammed Shafi Shajakhan 'WMI_10_4_WDS_PEER_EVENTID' is not yet handled/implemented for WDS mode, as of nowsuppress the warning message "Unknown eventid: 36903" Signed-off-by: Mohammed Shafi Shajakhan --- found this issue while

Re: [PATCHv6 1/2] add basic register-field manipulation macros

Jakub Kicinski writes: > Common approach to accessing register fields is to define > structures or sets of macros containing mask and shift pair. > Operations on the register are then performed as follows: > > field = (reg >> shift) & mask; > > reg &= ~(mask <<