Hello,
>>> 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.
>
> Sadly, I think man
Hi Johannes,
On 06/29/2018 05:01 AM, Johannes Berg wrote:
Hi Denis,
Hope you don't mind me adding the list to the explanations, so they're
recorded. Your questions are completely reasonable, after all :-)
Absolutely do not mind.
So I've been poking around a bit more in nl80211/mac80211 stu
On Friday, June 29, 2018 05:39 PM, Ulf Hansson wrote:
On 27 June 2018 at 20:58, Daniel Mack wrote:
Prior to commit 573185cc7e64 ("mmc: core: Invoke sdio func driver's PM
callbacks from the sdio bus"), the MMC core used to call into the power
management functions of SDIO clients itself and remov
On 27 June 2018 at 20:58, Daniel Mack wrote:
> Prior to commit 573185cc7e64 ("mmc: core: Invoke sdio func driver's PM
> callbacks from the sdio bus"), the MMC core used to call into the power
> management functions of SDIO clients itself and removed the card if the
> return code was non-zero. IOW,
In the error path of the IRQ handler, don't free the skb in flight. The
callback in the digital core will do that for us, so this is another
double-free that leads to memory corruptions.
The assignment of 'wtx' doesn't make sense as the variable is not read
after it is written. Drop it.
Signed-of
This flag is unneccesary. We can just nullify `ddev' instead after we freed
it.
Signed-off-by: Daniel Mack
---
drivers/nfc/st95hf/core.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/nfc/st95hf/core.c b/drivers/nfc/st95hf/core.c
index a50a95cfcfd8..ef91ca8b5
Initialization is unneccessary when the variable is written before it is
read. There were some occasions in which the driver would initialize `ret'
during declaration without need.
Purely a cosmetic change with no functional impact.
Signed-off-by: Daniel Mack
---
drivers/net/wireless/ath/wcn36x
> Sergey Matyukevich writes:
>
> >> Sergey Matyukevich wrote:
> >>
> >> > From: Igor Mitsyanko
> >> >
> >> > Implement net_device_ops::ndo_set_mac_address callback to allow for
> >> > setting interface MAC address. Implementation is done through existing
> >> > CHANGE_INTF firmware command. All
Loic Poulain wrote:
> This is an obvious copy & paste bug.
>
> Signed-off-by: Loic Poulain
> Signed-off-by: Kalle Valo
3 patches applied to ath-next branch of ath.git, thanks.
10db60b9fab7 wcn36xx: Fix WEP104 encryption type
e3160542ab48 wcn36xx: Track associated stations
216da1287a8a wcn36x
Add mt76_{incr,decr} utility routines to increment/decrement a value
with wrap-around (they will be used by mt76x2 DFS sw detector)
Signed-off-by: Lorenzo Bianconi
---
drivers/net/wireless/mediatek/mt76/mt76.h | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/net/wireless
Introduce sw event ring buffer to queue DFS pulses loaded from the hw.
Radar pulses will be used in DFS sw detector
Signed-off-by: Lorenzo Bianconi
---
.../net/wireless/mediatek/mt76/mt76x2_dfs.c | 139 +-
.../net/wireless/mediatek/mt76/mt76x2_dfs.h | 27
2 files change
Add sw DFS pattern detector support for mt76x2 based devices.
Dfs pattern supported:
- short pulse radar patterns
- staggered radar patterns
Signed-off-by: Lorenzo Bianconi
---
.../net/wireless/mediatek/mt76/mt76x2_dfs.c | 231 +-
.../net/wireless/mediatek/mt76/mt76x2_dfs.h |
Add sw pattern detector statistics to mt76x2 debugfs.
Moreover track down number of allocated sequence by the detector
Signed-off-by: Lorenzo Bianconi
---
drivers/net/wireless/mediatek/mt76/mt76x2_debugfs.c | 8
drivers/net/wireless/mediatek/mt76/mt76x2_dfs.c | 11 ++-
driv
Add sw DFS pattern detector support for mt76x2 based devices.
Dfs pattern supported:
- short pulse radar patterns
- staggered radar patterns
Changes since v1:
- improve code readability of mt76x2_dfs_fetch_event()
adding macros for event fields
Lorenzo Bianconi (4):
mt76: introduce mt76_{incr
On 2018-06-29 09:03, Kalle Valo wrote:
Rafał Miłecki writes:
From: Rafał Miłecki
Depending on used build-time options some firmwares may already
include
radiotap header in passed monitor frames. Add a new feature flag to
store info about it. It's needed for proper handling of received
fra
On 2018-06-29 15:18, Johannes Berg wrote:
On Fri, 2018-05-25 at 16:36 +0530, Balaji Pothunoori wrote:
This patch is to display the average ack signal,
last ack signal of tx ack packets.
Please resend this with the required kernel changes.
johannes
Sure Johannes.
Regards,
Balaji.
Hi,
On Tue, 2018-06-19 at 22:12 +0200, Alexander Wetzel wrote:
> > 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 (cor
Hi Denis,
Hope you don't mind me adding the list to the explanations, so they're
recorded. Your questions are completely reasonable, after all :-)
> So I've been poking around a bit more in nl80211/mac80211 stuff and I
> was curious how exactly NEW_KEY/SET_KEY are supposed to be used. The
> do
On Fri, 2018-05-25 at 16:36 +0530, Balaji Pothunoori wrote:
> This patch is to display the average ack signal,
> last ack signal of tx ack packets.
Please resend this with the required kernel changes.
johannes
> +static void ieee80211_sta_mon_txrate_thold_check(struct sta_info *sta)
> +{
> + struct rate_info rinfo;
> + enum nl80211_sta_mon_txrate_threshold_event sta_txrate_event;
> + int txrate;
> +
> + if (!sta->txrate_high)
> + return;
> +
> + sta_set_rate_info_tx(sta,
I'd say squash this with patch 1 - there's no point in adding the
configurations if you can't use them :-)
> +void
> +cfg80211_sta_mon_txrate_notify(struct net_device *dev, const u8 *peer,
> + enum nl80211_sta_mon_txrate_threshold_event txrate_event,
> + u32 txrate_level, g
On Wed, 2018-06-13 at 16:28 +0530, Tamizh chelvam wrote:
> + if (sta->txrate_low == low_txrate_thold &&
> + sta->txrate_high == high_txrate_thold)
> + goto unlock;
> +
> + sta->txrate_low = low_txrate_thold;
> + sta->txrate_high = high_txrate_thold;
You don't really
On Wed, 2018-06-13 at 16:28 +0530, Tamizh chelvam wrote:
> Add support to configure station specific txrate threshold
> to monitor variation in the txrate for a station. Configuration
> is passed using NL80211_ATTR_STA_MON_LOW_TXRATE_THOLD and
> NL80211_ATTR_STA_MON_HIGH_TXRATE_THOLD in NL80211_CMD
Sergey Matyukevich writes:
>> Sergey Matyukevich wrote:
>>
>> > From: Igor Mitsyanko
>> >
>> > Implement net_device_ops::ndo_set_mac_address callback to allow for
>> > setting interface MAC address. Implementation is done through existing
>> > CHANGE_INTF firmware command. All validation is to
On Wed, 2018-06-13 at 16:15 +0530, Tamizh chelvam wrote:
> Add set_sta_mon_rssi_range_config api to support
> configuring low and high RSSI threshold values
> for a connected station. And trigger an event if a
> station's signal strength goes out of configured
> range.
Same here, let's not worry a
On Wed, 2018-06-13 at 16:15 +0530, Tamizh chelvam wrote:
> Change the NL80211_CMD_STA_MON RSSI threshold attribut to
This seems weird - you just introduced it a few patches back, and now
you change it and even worry about compatibility and have both cfg80211
callbacks etc. Just remove set_sta_mon_
On Wed, 2018-06-13 at 16:15 +0530, Tamizh chelvam wrote:
>
> + if (sta->rssi_thold && bss_conf->enable_beacon) {
> + int last_event = sta->last_sta_mon_event_signal;
> + int thold = sta->rssi_thold;
> + int hyst = sta->rssi_hyst;
> + int sig = -e
On Wed, 2018-06-13 at 16:15 +0530, Tamizh chelvam wrote:
> Add cfg80211_sta_mon_rssi_notify api to update user space upon
> crossing the configured rssi threshold of a station.
> NL80211_CMD_NOTIFY_STA_MON introduced to send this event to
> userspace along with NL80211_ATTR_STA_MON_RSSI_THRESHOLD_E
The subjects are a bit confusing - I think you should align the cfg80211
and mac80211 ones so it's clearer that this one is implementing the
previous one's API. Peer vs. station, and mac80211 doesn't add API but
implements it.
This patch doesn't really do anything though, so I guess you need to
co
On Wed, 2018-06-13 at 16:15 +0530, Tamizh chelvam wrote:
>
> + * @NL80211_ATTR_STA_MON: Station's connection monitor configuration in a
> + * nested attribute with %NL80211_ATTR_STA_MON_* sub-attributes.
Can't we reuse the existing attributes in this nesting?
> +/**
> + * enum nl80211_sta_mon_
> Sergey Matyukevich wrote:
>
> > From: Igor Mitsyanko
> >
> > Implement net_device_ops::ndo_set_mac_address callback to allow for
> > setting interface MAC address. Implementation is done through existing
> > CHANGE_INTF firmware command. All validation is to be done by firmware.
> >
> > Signed
On Wed, 2018-06-13 at 16:15 +0530, Tamizh chelvam wrote:
>
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index 5fbfe61..3e123a3 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -4139,7 +4139,7 @@ static inline struct wiphy *wiphy_new(const struct
> cfg8
On Tue, 2018-06-26 at 12:46 +0530, Manikanta Pubbisetty wrote:
>
> - if (test_bit(IEEE80211_TXQ_STOP, &txqi->flags))
> + if (test_bit(IEEE80211_TXQ_STOP, &txqi->flags) ||
> + test_bit(IEEE80211_TXQ_PAUSED, &txqi->flags))
> goto out;
>
> + if (local->txqs_stopped
(Was "Re: [PATCH v3 00/19] rtlwifi: halmac: Add new module halmac",
changing the title to reflect what we are discussing)
Pkshih writes:
> On Thu, 2018-05-24 at 11:27 +0300, Kalle Valo wrote:
>>
>> You are missing my point: I don't even have time to review huge rtlwifi
>> patches when they are
(Was "Re: [PATCH v4 0/9] rtlwifi: btcoex: Add 8822b btcoex support" but
I'll change the title to get more visibility as this is a general advice
for everyone)
Pkshih writes:
> I would like to send v5 to change the order of this patchset like:
> rtlwifi: btcoex: remove comments that are not mea
On Tue, 2018-06-26 at 18:01 +0530, Manikanta Pubbisetty wrote:
>
> Valid point, txqs_paused is set in ieee80211_tx_dequeue; I was thinking
> a case where tx_dequeue is called without rcu_read_lock but seems that
> is not the case. All drivers using wake_tx_queue seems are using
> rcu_read_lock
On Tue, 2018-06-26 at 13:25 +0200, Toke Høiland-Jørgensen wrote:
> Manikanta Pubbisetty writes:
>
> > We can still invoke netif stop/wake APIs when wake_tx_queue is
> > implemented but this could lead to packet drops in network layer;
> > adding stop/start logic for software TXQs in mac80211 inst
On Tue, 2018-06-19 at 10:39 -0500, Denis Kenzior wrote:
> 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.
Applied, but I've done some major edits to the comm
From: Johannes Berg
At the very least we should check the return value if
nla_parse_nested() is called with a non-NULL policy.
Signed-off-by: Johannes Berg
---
net/wireless/nl80211.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/net/wireless/nl80211.c b/
Pkshih writes:
> On Tue, 2018-05-29 at 08:18 +0300, Kalle Valo wrote:
>> writes:
>>
>> > From: Ping-Ke Shih
>> >
>> > The format of C2H data is ID(1 byte) + Length(1 byte) + value, and it is
>> > more readable to use macros to access C2H data.
>> >
>> > Signed-off-by: Ping-Ke Shih
>>
>> [...
Ping-Ke Shih wrote:
> From: Ping-Ke Shih
>
> Without this patch, firmware will not run properly on rtl8821ae, and it
> causes bad user experience. For example, bad connection performance with
> low rate, higher power consumption, and so on.
>
> rtl8821ae uses two kinds of firmwares for normal
Rafał Miłecki writes:
> From: Rafał Miłecki
>
> Depending on used build-time options some firmwares may already include
> radiotap header in passed monitor frames. Add a new feature flag to
> store info about it. It's needed for proper handling of received frames
> before passing them up.
>
> Si
42 matches
Mail list logo
