* Re: [PATCH v4 3/5] cfg80211: Accept multiple RSSI thresholds for CQM
From: Johannes Berg @ 2017-02-08 9:58 UTC (permalink / raw)
To: Andrew Zaborowski, linux-wireless
In-Reply-To: <20170125114344.8179-3-andrew.zaborowski@intel.com>
> This method doesn't have a hysteresis parameter because there's no
> benefit to the cfg80211 code from having the hysteresis be handled by
> hardware/driver in terms of the number of wakeups. At the same time
> it would likely be less consistent between drivers if offloaded or
> done in the drivers.
I'm not really sure I buy this.
What if I configure a few ranges, and let's say one of the boundaries
is -50dBm. Now if I sit just on that value of -50dBm and thus my signal
fluctuates say -48..-52, I'd have to continuously wake up the host.
You try to avoid that here, I think:
+ if (low > (s32) (last - hyst))
+ low = last - hyst;
+ if (high < (s32) (last + hyst))
+ high = last + hyst;
but it's not clear to me that this is effective?
Let's see. last is -52, so low will be -60 and high will be -50.
Let's say hyst is 3 since I chose the ranges so closely. I'm guessing a
higher hysteresis and larger ranges would actually be better, but let's
stick to this for the sake of the example.
last-hyst = -55, so low isn't > that, low = -60
last+hyst = -49, so high = -49
but now it still fluctuates around -50, so if I next hit -48 you do the
same dance again with -50/-40, getting -51/-40 and never really
applying a full hysteresis, no?
I'll probably see an intermediate value of -50 at some point, but I'll
never actually *report* it, so "last" can switch between -48 and -52
constantly in this scenario, no?
I think it would make sense to unconditionally apply the hysteresis to
low/high, i.e. always set
low = low - hyst
high = high + hyst
so that you get "sticky" ranges once you're in them?
> + if (!wiphy_ext_feature_isset(&rdev->wiphy,
> +
> NL80211_EXT_FEATURE_CQM_RSSI_LIST))
> + return
> -EOPNOTSUPP;
That check should be earlier in the function
cfg80211_cqm_rssi_update(), no?
johannes
^ permalink raw reply
* Re: [PATCH 1/5] nl80211: fix validation of scheduled scan info for wowlan netdetect
From: Arend Van Spriel @ 2017-02-08 9:56 UTC (permalink / raw)
To: Johannes Berg, Kalle Valo; +Cc: linux-wireless
In-Reply-To: <1486545047.4603.14.camel@sipsolutions.net>
On 8-2-2017 10:10, Johannes Berg wrote:
> On Fri, 2017-01-27 at 12:09 +0000, Arend van Spriel wrote:
>> For wowlan netdetect a separate limit is defined for the number of
>> matchsets. Currently, this limit is ignored and the regular limit
>> for scheduled scan matchsets, ie. struct wiphy::max_match_sets, is
>> used for the net-detect case as well.
>
> Applied.
>
> This means that brmcfmac is now broken in mac80211-next for a bit, but
> once it hits net-next and I merge back everything will be fine again,
> so just a few days (and I assume nobody us using brcmfmac from
> mac80211-next anyway ... wireless-testing will be fine)
Well. Almost nobody :-p
Gr. AvS
^ permalink raw reply
* Re: [PATCH] cfg80211: make rdev assignment clearer in nl80211_testmode_dump()
From: Johannes Berg @ 2017-02-08 9:06 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, Luca Coelho
In-Reply-To: <20170207201356.4752-1-luca@coelho.fi>
On Tue, 2017-02-07 at 22:13 +0200, Luca Coelho wrote:
> From: Luca Coelho <luciano.coelho@intel.com>
>
> Avoid assigning rdev to NULL when we already have it and getting it
> again from the wiphy index, by moving this code to relevant if block.
Applied.
johannes
^ permalink raw reply
* Re: [PATCH] nl80211: add HT/VHT capabilities to AP parameters
From: Johannes Berg @ 2017-02-08 9:06 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless
In-Reply-To: <20170207204044.1950-1-luca@coelho.fi>
On Tue, 2017-02-07 at 22:40 +0200, Luca Coelho wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> For the benefit of drivers that rebuild IEs in firmware, parse the
> IEs for HT/VHT capabilities and the respective membership selector
> in the (extended) supported rates. This avoids duplicating the same
> code into all drivers that need this information.
>
Applied.
johannes
^ permalink raw reply
* Re: [PATCH v4 2/5] cfg80211: Pass new RSSI level in CQM RSSI notification
From: Johannes Berg @ 2017-02-08 9:47 UTC (permalink / raw)
To: Andrew Zaborowski, linux-wireless
In-Reply-To: <20170125114344.8179-2-andrew.zaborowski@intel.com>
Ok, I've applied patches 1-2 right now, that really makes sense
regardless of the others.
johannes
^ permalink raw reply
* Re: [PATCH net] brcmfmac: clear skb head state on xmit
From: Paolo Abeni @ 2017-02-08 9:29 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Arend Van Spriel, Kalle Valo, linux-wireless@vger.kernel.org,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
Franky Lin, hante Meuleman
In-Reply-To: <CACna6rxc6kAtAbknMGVoW5jWoxnUibD83jcVsHmU6gWhSVTWzQ@mail.gmail.com>
On Wed, 2017-02-08 at 09:52 +0100, Rafał Miłecki wrote:
> On 8 February 2017 at 09:38, Paolo Abeni <pabeni@redhat.com> wrote:
> > On Tue, 2017-02-07 at 20:23 +0100, Arend Van Spriel wrote:
> > > On 7-2-2017 17:50, Paolo Abeni wrote:
> > > > the skbs can be held by the driver for a long time, so we need
> > > > to clear any state on xmit to avoid hanging other subsystems.
> > > > The skbs are already orphaned later in cmsg code, so we just
> > > > need to clear the nf/dst/secpath.
> > > > Do it early, while the relevant entries are hopefully still
> > > > hot in the cache.
> > >
> > > What is this about really? A bit more background about the issue
> > > might
> > > help understanding the need for this patch. Is this really
> > > specific
> > > to
> > > brcmfmac. For instance is something similar already done in
> > > mac80211?
> >
> > The issue is apparently driver specific, as reported in:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1294415
> >
> > This is caused by xmit skbs carrying a notrack ct entry not being
> > freed
> > by the device driver in a timely manner. Removing the ct module
> > waits
> > for such entries refcount going to zero and hangs the kernel in
> > busy
> > loop (for several minutes).
> >
> > The relevant skbs are icmp6 packets (ND if I recall correctly, they
> > bcast packets at the mac level).
> >
> > The only other known device driver suffering for the issue is the
> > infiniband ipoib driver, I send a separate patch for it.
> >
> > I lack the broadcom h/w, but with infiniband the bug can be
> > reproduced
> > with the following steps:
> >
> > - ensure ipv6 is enabled on the target device, and firewalld is
> > running
> > (e.g. the module nf_conntrack_ipv6 is loaded)
> > - assign a static ip to the device
> > - shut down the firewall (e.g. try to remove the module
> > nf_conntrack)
> >
> > For the brcmfmac driver most probably it is necessary being
> > disassociated from the AP before shutting down the firewall (but I
> > can't double check). This is probably why mac80211 does not suffer
> > this
> > issue.
> >
> > The root cause for the issue could be actually a firmware issue,
> > any
> > better clues are more than welcome!
>
> Do I get this correctly brcmfmac gets some skb for transmitting it
> and
> doesn't free it for few minutes? It sounds like some bug that should
> be fixed instead of hiding it.
I mostly agreed, but please also note that early clearing the skb head
state makes sense from a performance pov: we can do the costly,
required, atomic operations while the data is still hot in the cpu L1
cache.
I'm unable to find anything obvious at the driver level, and I think
the root cause could be in the firmware. I hope some more knowledgeable
than me on this topics can have a better look.
Thank you,
Paolo
^ permalink raw reply
* Re: [PATCH V3 2/9] brcmfmac: switch to C function (__brcmf_err) for printing errors
From: Arend Van Spriel @ 2017-02-08 9:15 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo
Cc: Franky Lin, Hante Meuleman, Pieter-Paul Giesberts, Franky Lin,
linux-wireless, brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <20170202213321.11591-2-zajec5@gmail.com>
On 2-2-2017 22:33, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> This will allow extending code and using more detailed messages e.g.
> with the help of dev_err.
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> V3: Keep IS_ENABLED check in the macro as suggested by Felix
> ---
> .../net/wireless/broadcom/brcm80211/brcmfmac/common.c | 16 ++++++++++++++++
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h | 6 +++---
> 2 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> index f7c8c2e80349..33b133f7e63a 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> @@ -218,6 +218,22 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
> return err;
> }
>
> +#ifndef CONFIG_BRCM_TRACING
> +void __brcmf_err(const char *func, const char *fmt, ...)
> +{
> + struct va_format vaf;
> + va_list args;
> +
> + va_start(args, fmt);
> +
> + vaf.fmt = fmt;
> + vaf.va = &args;
> + pr_err("%s: %pV", func, &vaf);
> +
> + va_end(args);
> +}
> +#endif
> +
> #if defined(CONFIG_BRCM_TRACING) || defined(CONFIG_BRCMDBG)
> void __brcmf_dbg(u32 level, const char *func, const char *fmt, ...)
> {
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
> index 1fe4aa973a92..441a6661eac0 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
> @@ -45,6 +45,8 @@
> #undef pr_fmt
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> +__printf(2, 3)
> +void __brcmf_err(const char *func, const char *fmt, ...);
> #ifndef CONFIG_BRCM_TRACING
> /* Macro for error messages. net_ratelimit() is used when driver
> * debugging is not selected. When debugging the driver error
> @@ -53,11 +55,9 @@
> #define brcmf_err(fmt, ...) \
> do { \
> if (IS_ENABLED(CONFIG_BRCMDBG) || net_ratelimit()) \
> - pr_err("%s: " fmt, __func__, ##__VA_ARGS__); \
> + __brcmf_err(__func__, fmt, ##__VA_ARGS__); \
> } while (0)
> #else
> -__printf(2, 3)
> -void __brcmf_err(const char *func, const char *fmt, ...);
> #define brcmf_err(fmt, ...) \
> __brcmf_err(__func__, fmt, ##__VA_ARGS__)
> #endif
>
^ permalink raw reply
* Re: [PATCH 1/5] nl80211: fix validation of scheduled scan info for wowlan netdetect
From: Johannes Berg @ 2017-02-08 9:10 UTC (permalink / raw)
To: Arend van Spriel, Kalle Valo; +Cc: linux-wireless
In-Reply-To: <1485518971-28183-2-git-send-email-arend.vanspriel@broadcom.com>
On Fri, 2017-01-27 at 12:09 +0000, Arend van Spriel wrote:
> For wowlan netdetect a separate limit is defined for the number of
> matchsets. Currently, this limit is ignored and the regular limit
> for scheduled scan matchsets, ie. struct wiphy::max_match_sets, is
> used for the net-detect case as well.
Applied.
This means that brmcfmac is now broken in mac80211-next for a bit, but
once it hits net-next and I merge back everything will be fine again,
so just a few days (and I assume nobody us using brcmfmac from
mac80211-next anyway ... wireless-testing will be fine)
johannes
^ permalink raw reply
* Re: [PATCH V3 1/9] brcmfmac: merge two brcmf_err macros into one
From: Arend Van Spriel @ 2017-02-08 9:02 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo
Cc: Franky Lin, Hante Meuleman, Pieter-Paul Giesberts, Franky Lin,
linux-wireless, brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <20170202213321.11591-1-zajec5@gmail.com>
On 2-2-2017 22:33, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> This allows simplifying the code by adding a simple IS_ENABLED check for
> CONFIG_BRCMDB symbol.
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> V3: Re-add this patch (it was initially submited as RFC)
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
> index 6687812770cc..1fe4aa973a92 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
> @@ -45,20 +45,16 @@
> #undef pr_fmt
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> +#ifndef CONFIG_BRCM_TRACING
> /* Macro for error messages. net_ratelimit() is used when driver
> * debugging is not selected. When debugging the driver error
> * messages are as important as other tracing or even more so.
> */
> -#ifndef CONFIG_BRCM_TRACING
> -#ifdef CONFIG_BRCMDBG
> -#define brcmf_err(fmt, ...) pr_err("%s: " fmt, __func__, ##__VA_ARGS__)
> -#else
> #define brcmf_err(fmt, ...) \
> do { \
> - if (net_ratelimit()) \
> + if (IS_ENABLED(CONFIG_BRCMDBG) || net_ratelimit()) \
> pr_err("%s: " fmt, __func__, ##__VA_ARGS__); \
> } while (0)
> -#endif
> #else
> __printf(2, 3)
> void __brcmf_err(const char *func, const char *fmt, ...);
>
^ permalink raw reply
* Re: [patch] mac80211: check for allocation failure in debugfs code
From: Johannes Berg @ 2017-02-08 9:05 UTC (permalink / raw)
To: Dan Carpenter, Ben Greear; +Cc: linux-wireless, kernel-janitors
In-Reply-To: <20170207132052.GE27416@mwanda>
On Tue, 2017-02-07 at 16:20 +0300, Dan Carpenter wrote:
> kmalloc() can fail. Also let's move the allocation out of the
> declaration block so it's easier to read.
>
Applied, thanks.
johannes
^ permalink raw reply
* Re: [PATCH net] brcmfmac: clear skb head state on xmit
From: Rafał Miłecki @ 2017-02-08 8:52 UTC (permalink / raw)
To: Paolo Abeni
Cc: Arend Van Spriel, Kalle Valo, linux-wireless@vger.kernel.org,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
Franky Lin, hante Meuleman
In-Reply-To: <1486543119.2533.3.camel@redhat.com>
On 8 February 2017 at 09:38, Paolo Abeni <pabeni@redhat.com> wrote:
> On Tue, 2017-02-07 at 20:23 +0100, Arend Van Spriel wrote:
>> On 7-2-2017 17:50, Paolo Abeni wrote:
>> > the skbs can be held by the driver for a long time, so we need
>> > to clear any state on xmit to avoid hanging other subsystems.
>> > The skbs are already orphaned later in cmsg code, so we just
>> > need to clear the nf/dst/secpath.
>> > Do it early, while the relevant entries are hopefully still
>> > hot in the cache.
>>
>> What is this about really? A bit more background about the issue
>> might
>> help understanding the need for this patch. Is this really specific
>> to
>> brcmfmac. For instance is something similar already done in mac80211?
>
> The issue is apparently driver specific, as reported in:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=3D1294415
>
> This is caused by xmit skbs carrying a notrack ct entry not being freed
> by the device driver in a timely manner. Removing the ct module waits
> for such entries refcount going to zero and hangs the kernel in busy
> loop (for several minutes).
>
> The relevant skbs are icmp6 packets (ND if I recall correctly, they
> bcast packets at the mac level).
>
> The only other known device driver suffering for the issue is the
> infiniband ipoib driver, I send a separate patch for it.
>
> I lack the broadcom h/w, but with infiniband the bug can be reproduced
> with the following steps:
>
> - ensure ipv6 is enabled on the target device, and firewalld is running
> (e.g. the module nf_conntrack_ipv6 is loaded)
> - assign a static ip to the device
> - shut down the firewall (e.g. try to remove the module nf_conntrack)
>
> For the brcmfmac driver most probably it is necessary being
> disassociated from the AP before shutting down the firewall (but I
> can't double check). This is probably why mac80211 does not suffer this
> issue.
>
> The root cause for the issue could be actually a firmware issue, any
> better clues are more than welcome!
Do I get this correctly brcmfmac gets some skb for transmitting it and
doesn't free it for few minutes? It sounds like some bug that should
be fixed instead of hiding it.
--=20
Rafa=C5=82
^ permalink raw reply
* Re: [PATCH net] brcmfmac: clear skb head state on xmit
From: Paolo Abeni @ 2017-02-08 8:38 UTC (permalink / raw)
To: Arend Van Spriel, Kalle Valo
Cc: linux-wireless, brcm80211-dev-list.pdl, Franky Lin,
hante Meuleman
In-Reply-To: <f755ffe7-ea05-7481-af51-da2489bc8a43@broadcom.com>
On Tue, 2017-02-07 at 20:23 +0100, Arend Van Spriel wrote:
> On 7-2-2017 17:50, Paolo Abeni wrote:
> > the skbs can be held by the driver for a long time, so we need
> > to clear any state on xmit to avoid hanging other subsystems.
> > The skbs are already orphaned later in cmsg code, so we just
> > need to clear the nf/dst/secpath.
> > Do it early, while the relevant entries are hopefully still
> > hot in the cache.
>
> What is this about really? A bit more background about the issue
> might
> help understanding the need for this patch. Is this really specific
> to
> brcmfmac. For instance is something similar already done in mac80211?
The issue is apparently driver specific, as reported in:
https://bugzilla.redhat.com/show_bug.cgi?id=1294415
This is caused by xmit skbs carrying a notrack ct entry not being freed
by the device driver in a timely manner. Removing the ct module waits
for such entries refcount going to zero and hangs the kernel in busy
loop (for several minutes).
The relevant skbs are icmp6 packets (ND if I recall correctly, they
bcast packets at the mac level).
The only other known device driver suffering for the issue is the
infiniband ipoib driver, I send a separate patch for it.
I lack the broadcom h/w, but with infiniband the bug can be reproduced
with the following steps:
- ensure ipv6 is enabled on the target device, and firewalld is running
(e.g. the module nf_conntrack_ipv6 is loaded)
- assign a static ip to the device
- shut down the firewall (e.g. try to remove the module nf_conntrack)
For the brcmfmac driver most probably it is necessary being
disassociated from the AP before shutting down the firewall (but I
can't double check). This is probably why mac80211 does not suffer this
issue.
The root cause for the issue could be actually a firmware issue, any
better clues are more than welcome!
Thank you,
Paolo
^ permalink raw reply
* Re: [PATCH v2 2/3] mac80211: Make mesh failure moving average configurable
From: Johannes Berg @ 2017-02-08 8:31 UTC (permalink / raw)
To: Rajkumar Manoharan; +Cc: linux-wireless, rmanohar
In-Reply-To: <1485893272-6893-2-git-send-email-rmanohar@qca.qualcomm.com>
On Tue, 2017-01-31 at 12:07 -0800, Rajkumar Manoharan wrote:
> Currently mesh moving fail average is calculated based on constant
> weight factor. In worst case moving average reaches threshold by
> considering 16 msdu tx ack status and deactivates mesh path. Having
> a constant weight factor might not be suitable for all environments.
> So make it tunable parameter and also lower default weight to 10 so
> that mesh broken link calculation will consider more packet status
> (32 msdus ack status) before dropping mesh path.
I don't think this makes a lot of sense, and with a conversion to the
EWMA helpers it would probably not really be possible anyway.
johannes
^ permalink raw reply
* Re: [PATCH v2 1/3] mac80211: fix mesh moving average stuck
From: Johannes Berg @ 2017-02-08 8:30 UTC (permalink / raw)
To: Rajkumar Manoharan; +Cc: linux-wireless, rmanohar
In-Reply-To: <1485893272-6893-1-git-send-email-rmanohar@qca.qualcomm.com>
On Tue, 2017-01-31 at 12:07 -0800, Rajkumar Manoharan wrote:
> As moving average is not considering fractional part after
> certain ratio, it will stuck at the same state. For example
> with current values, moving average stuck at 96 and it will
> not move forward. Fortunately current threshold is matching
> against 95%. If thresold is increased more than 96, mesh path
> never be deactivated under worst case. Fix failure average
> movement by bumping up average at stuck state.
This is ... really strange to me.
Can't we just actually take into account fractional parts instead?
I think you should instead convert this to the EMWA helpers (see
include/linux/average.h).
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: Remove VHT Capabilities/Operation IEs from mesh beacon if VHT was disabled
From: Johannes Berg @ 2017-02-08 8:22 UTC (permalink / raw)
To: Masashi Honma; +Cc: linux-wireless
In-Reply-To: <1485993928-3822-1-git-send-email-masashi.honma@gmail.com>
> This patch removes VHT Capabilities/Operation IEs when the
> wpa_supplicant.conf includes disable_vht=1. We recognize the local
> peer
> as 11ac ready, when it has more than 80MHz band width. Because
> net/mac80211/util.c#ieee80211_build_preq_ies_band() uses 80MHz
> threshold
> for VHT Capabilities IE inclusion.
I believe this is incorrect the way you've written it, we shouldn't
disable VHT because 80 MHz isn't *used* right now.
The code you reference checks if 80 MHz was technically *supported*,
and that's really only because we otherwise can't connect to a BSS
network that supports VHT, since the AP might switch from 20/40 to
80/160, and we can't say that we don't support 80 (since we have to
support it if we support VHT.)
> sband = local->hw.wiphy->bands[band];
> if (!sband->vht_cap.vht_supported ||
> - sdata->vif.bss_conf.chandef.width ==
> NL80211_CHAN_WIDTH_20_NOHT ||
> - sdata->vif.bss_conf.chandef.width ==
> NL80211_CHAN_WIDTH_5 ||
> - sdata->vif.bss_conf.chandef.width ==
> NL80211_CHAN_WIDTH_10)
> + !(sdata->vif.bss_conf.chandef.width ==
> NL80211_CHAN_WIDTH_80 ||
> + sdata->vif.bss_conf.chandef.width ==
> NL80211_CHAN_WIDTH_80P80 ||
> + sdata->vif.bss_conf.chandef.width ==
> NL80211_CHAN_WIDTH_160))
> return 0;
>
But using the current bandwidth as you do now seems incorrect to me.
johannes
^ permalink raw reply
* RE: [PATCH v9] Add new mac80211 driver mwlwifi.
From: David Lin @ 2017-02-08 7:55 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Steve deRosier, Kalle Valo, linux-wireless@vger.kernel.org,
Johannes Berg, Chor Teck Law, James Lin, Pete Hsieh
In-Reply-To: <CACna6rwE1YE6bokFehgRNsyRGNGORbrYcnuUR-df286h0K4KXw@mail.gmail.com>
PiBGcm9tOiBSYWZhxYIgTWnFgmVja2kgW21haWx0bzp6YWplYzVAZ21haWwuY29tXSB3b3J0ZTog
DQo+IE9uIDggRmVicnVhcnkgMjAxNyBhdCAwODoyOCwgRGF2aWQgTGluIDxkbGluQG1hcnZlbGwu
Y29tPiB3cm90ZToNCj4gPj4gRnJvbTogUmFmYcWCIE1pxYJlY2tpIFttYWlsdG86emFqZWM1QGdt
YWlsLmNvbV0gd29ydGU6DQo+ID4+IFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDgsIDIwMTcg
MzoyNCBQTSBPbiA4IEZlYnJ1YXJ5IDIwMTcgYXQNCj4gPj4gMDc6MzAsIERhdmlkIExpbiA8ZGxp
bkBtYXJ2ZWxsLmNvbT4gd3JvdGU6DQo+ID4+ID4gc3RldmUuZGVyb3NpZXJAZ21haWwuY29tIFtt
YWlsdG86c3RldmUuZGVyb3NpZXJAZ21haWwuY29tXSB3cm90ZToNCj4gPj4gPj4gT24gVHVlLCBG
ZWIgNywgMjAxNyBhdCAxMDoxNSBQTSwgRGF2aWQgTGluIDxkbGluQG1hcnZlbGwuY29tPiB3cm90
ZToNCj4gPj4gPj4gPj4gUmFmYcWCIE1pxYJlY2tpIFttYWlsdG86emFqZWM1QGdtYWlsLmNvbV0g
d3JvdGU6DQo+ID4+ID4+ID4+IFBsZWFzZSB1c2UgaWVlZTgwMjExLWZyZXEtbGltaXQ6DQo+ID4+
ID4+ID4+IGh0dHBzOi8vZ2l0Lmtlcm5lbC5vcmcvY2dpdC9saW51eC9rZXJuZWwvZ2l0L2RhdmVt
L25ldC1uZXh0LmdpdA0KPiA+PiA+PiA+PiAvY28NCj4gPj4gPj4gPj4gbW1pDQo+ID4+ID4+ID4+
IHQvP2lkPWIzDQo+ID4+ID4+ID4+IDMwYjI1ZWFhYmRhMDBkNzRlNDc1NjZkOTIwMDkwN2RhMzgx
ODk2DQo+ID4+ID4+ID4+DQo+ID4+ID4+ID4+IE1vc3QgbGlrZWx5IHdpdGggd2lwaHlfcmVhZF9v
Zl9mcmVxX2xpbWl0cyBoZWxwZXI6DQo+ID4+ID4+ID4+IGh0dHBzOi8vZ2l0Lmtlcm5lbC5vcmcv
Y2dpdC9saW51eC9rZXJuZWwvZ2l0L2RhdmVtL25ldC1uZXh0LmdpdA0KPiA+PiA+PiA+PiAvY28N
Cj4gPj4gPj4gPj4gbW1pDQo+ID4+ID4+ID4+IHQvP2lkPWU2DQo+ID4+ID4+ID4+IDkxYWMyZjc1
YjY5YmVlNzQzZjAzNzBkNzk0NTRiYTQ0MjliMTc1DQo+ID4+ID4+ID4NCj4gPj4gPj4gPiBJIGFs
cmVhZHkgcmVwbGllZCBtZWFuaW5nIG9mIHRoZXNlIHBhcmFtZXRlcnM6DQo+ID4+ID4+ID4gPG1h
cnZlbGwsMmdoej4gaXMgdXNlZCB0byBkaXNhYmxlIDJnIGJhbmQuDQo+ID4+ID4+ID4gPG1hcnZl
bGwsNWdoej4gaXMgdXNlZCB0byBkaXNhYmxlIDVnIGJhbmQuDQo+ID4+ID4+ID4gPG1hcnZlbGws
IGNoYWlubWFzaz4gaXMgdXNlZCB0byBzcGVjaWZ5IGFudGVubmEgbnVtYmVyIChpZg0KPiA+PiA+
PiA+IGRlZmF1bHQgbnVtYmVyDQo+ID4+ID4+IGlzIHN1aXRhYmxlIGZvciB5b3UsIHRoZXJlIGlz
IG5vIG5lZWQgdG8gdXNlIHRoaXMgcGFyYW1ldGVyKS4NCj4gPj4gPj4gPiA8bWFydmVsbCxwb3dl
cnRhYmxlPiBzaG91bGQgbm90IGJlIHVzZWQgZm9yIGNoaXAgd2l0aCBkZXZpY2UNCj4gPj4gPj4g
PiBwb3dlcg0KPiA+PiB0YWJsZS4NCj4gPj4gPj4gSW4gZmFjdCwgdGhpcyBwYXJhbWV0ZXIgc2hv
dWxkIG5vdCBiZSB1c2VkIGFueSBtb3JlLg0KPiA+PiA+PiA+DQo+ID4+ID4+DQo+ID4+ID4+IERh
dmlkLCBJIHRoaW5rIHlvdSdyZSBub3QgdW5kZXJzdGFuZGluZyB0aGUgY29tbWVudCwgb3IgYXQg
bGVhc3QNCj4gPj4gPj4gdGhhdCdzIHdoYXQgaXQgbG9va3MgbGlrZSB0byBtZS4gWWVzLCB5b3Ug
ZGlkIHJlcGx5IGFzIHRvIHRoZSBtZWFuaW5nLg0KPiA+PiA+PiBBbmQsIHlvdXIgcmVwbHksIHdo
aWxlIGluZm9ybWF0aXZlLCBkaWRuJ3QgdGVsbCB1cyB5b3UgdW5kZXJzdG9vZA0KPiA+PiA+PiBh
bmQgd2VyZSB3aWxsaW5nIHRvIGZpeCB0aGUgcHJvYmxlbS4gSSBkb3VidCB5b3UgbWVhbnQgaXQg
dGhpcw0KPiA+PiA+PiB3YXksIGJ1dCBpdCBmZWVscyBkZWZlbnNpdmUgYW5kIGxpa2UgYSBicnVz
aC1vZmYuDQo+ID4+ID4+DQo+ID4+ID4+IEZpcnN0IG9mZiwgeW91IHdpbGwgc3RpbGwgaGF2ZSB0
byBkb2N1bWVudCBhbnkgRFQgYmluZGluZ3MgeW91J3JlDQo+ID4+ID4+IGFkZGluZy4gSnVzdCBi
ZWNhdXNlIHlvdSBhbnN3ZXIgdGhlIHF1ZXN0aW9uIGluIHRoZSByZXZpZXcgZG9lc24ndA0KPiA+
PiA+PiBtZWFuIHlvdSdyZSBub3QgcmVzcG9uc2libGUgZm9yIGRvaW5nIHNvLg0KPiA+PiA+Pg0K
PiA+PiA+PiBBbmQgc2Vjb25kIG9mZiwgSSB0aGluayB0aGF0IFJhZmFsIChhbmQgc29ycnkgYWJv
dXQgbXkgc3BlbGxpbmcsDQo+ID4+ID4+IGxvb2tzIGxpa2UgdGhlcmUncyBzb21lIHNvcnQgb2Yg
YWNjZW50IG9uIHRoZSBsIHRoYXQgSSBkb24ndCBrbm93DQo+ID4+ID4+IGhvdyB0byBtYWtlIG15
IGtleWJvYXJkIGRvKSBpcyBzYXlpbmc6IHRoZXJlJ3MgYWxyZWFkeSBzb21lDQo+ID4+ID4+IGdl
bmVyaWMgYmluZGluZ3MgdGhhdCBjYW4gYmUgdXNlZCB0byBkaXNhYmxlIHRoZSAyZyBvciA1ZyBi
YW5kcy4NCj4gPj4gPj4gR3JhbnRlZCB0aGV5J3JlIGV2ZW4gbmV3ZXIgdGhhbiB5b3VyIHBhdGNo
LCBidXQgSSBkbyB0aGluayBpZiBzYWlkDQo+ID4+ID4+IGJpbmRpbmdzIGV4aXN0IGFuZA0KPiA+
PiBhcmUgYXBwcm9wcmlhdGUsIHlvdSBzaG91bGQgdXNlIHRoZW0uDQo+ID4+ID4+DQo+ID4+ID4+
IC0gU3RldmUNCj4gPj4gPg0KPiA+PiA+IFRoZXNlIHBhcmFtZXRlcnMgYXJlIG1hcnZlbGwgcHJv
cHJpZXRhcnkgcGFyYW1ldGVycywgSSBkb24ndCB0aGluaw0KPiA+PiA+IGl0IHNob3VsZA0KPiA+
PiBiZSBhZGRlZCB0byBEVCBiaW5kaW5ncy4NCj4gPj4NCj4gPj4gU3RldmUgaXMgY29ycmVjdC4N
Cj4gPj4NCj4gPj4gWW91IGhhdmUgdG8gZG9jdW1lbnQgbmV3IHByb3BlcnRpZXMsIGp1c3QgYmVj
YXVzZSB0aGV5IGFyZSBNYXJ2ZWxsDQo+ID4+IHNwZWNpZmljIGRvZXNuJ3QgY2hhbmdlIGFueXRo
aW5nLiBZb3UganVzdCBkb2N1bWVudCB0aGVtIGluIGEgcHJvcGVyDQo+IHBsYWNlLg0KPiA+Pg0K
PiA+DQo+ID4gQWxsIHJpZ2h0LiBJIHdpbGwgZG8gdGhhdC4NCj4gPg0KPiA+Pg0KPiA+PiA+IEJU
VywgPG1hcnZlbGwsMmdoej4gYW5kIDxtYXJ2ZWxsLDVnaHo+IGFyZSBvbmx5IHVzZWQgZm9yIG13
bHdpZmkgdG8NCj4gPj4gPiByZXBvcnQNCj4gPj4gc3VwcG9ydGVkIGJhbmRzLCBpdCBpcyBub3Qg
cmVsYXRlZCB0byBsaW1pdGF0aW9uIG9mIGZyZXF1ZW5jeS4NCj4gPj4NCj4gPj4gSG93IHJlcG9y
dGluZyBhIHNpbmdsZSBiYW5kIGRvZXNuJ3QgbGltaXQgcmVwb3J0ZWQgZnJlcXVlbmNpZXM/IFlv
dQ0KPiA+PiBjYW4gYWNoaWV2ZSBleGFjdGx5IHRoZSBzYW1lIHVzaW5nIGdlbmVyaWMgcHJvcGVy
dHksIHNvIHRoZXJlIGlzIG5vDQo+ID4+IHBsYWNlIGZvciBNYXJ2ZWxsIHNwZWNpZmljIG9uZXMu
DQo+ID4+DQo+ID4+IEluIGZhY3QgdGhlcmUgd2VyZSBkcml2ZXJzIG9mIDMgdmVuZG9ycyByZXF1
aXJpbmcgYmFuZC9mcmVxLXJlbGF0ZWQNCj4gPj4gZGVzY3JpcHRpb24gaW4gRFQ6IEJyb2FkY29t
LCBNYXJ2ZWxsICYgTWVkaWF0ZWsuIFRoaXMgcHJvcGVydHkgd2FzDQo+ID4+IGRpc2N1c3NlZCAm
IGRlc2lnbmVkIHRvIHN1cHBvcnQgYWxsIGxpbWl0YXRpb24gY2FzZXMgd2UgZm91bmQNCj4gPj4g
cG9zc2libGUgdG8gbWFrZSBpdCB1c2FibGUgd2l0aA0KPiA+PiAoaG9wZWZ1bGx5KSBhbGwgZHJp
dmVycy4NCj4gPj4NCj4gPg0KPiA+IEkgb25seSBuZWVkIHNpbXBsZSB3YXkgdG8gZGlzYWJsZSAy
ZyBvciA1ZyBiYW5kLiBJIHdpbGwgZm9sbG93IHlvdXIgc3VnZ2VzdGlvbg0KPiB0byBkb2N1bWVu
dCB0aGVzZSBtYXJ2ZWxsIHByb3ByaWV0YXJ5IHBhcmFtZXRlcnMuDQo+IA0KPiBTZXJpb3VzbHk/
IFJlZnVzaW5nIHRvIHVzZSBnZW5lcmljIGJpbmRpbmcgYmVjYXVzZSB5b3UgdGhpbmsgbWFydmVs
bCw1Z2h6OyBpcw0KPiBzaW1wbGVyIHRoYW4gaWVlZTgwMjExLWZyZXEtbGltaXQgPSA8MjQwMjAw
MCAyNDgyMDAwPjsgKG5vdCB0byBtZW50aW9uIHlvdXINCj4gcHJvcGVydHkgc2VlbXMgcmV2ZXJz
ZWQhKT8NCj4gDQo+IEkgZG9uJ3Qga25vdyBob3cgZWxzZSB0byBleHBsYWluIHRoaXMgdG8geW91
LiBXZSBkb24ndCB3YW50IGR1cGxpY2F0ZWQNCj4gcHJvcGVydGllcyB3aGVyZSBvbmUgY2FuIHdv
cmsuIEp1c3QgdXNlIGV4aXN0aW5nIG9uZS4gRG9uJ3QgYWRkIG5ldyBvbmUgZXZlbg0KPiBpZiBk
b2N1bWVudGVkLg0KPiANCg0KQWxsIHJpZ2h0LiBJIHdpbGwgY2hlY2sgYW5kIGxldCBwYXRjaCB2
MTAgdG8gdXNlIGl0LiBGb3IgcHJldmlvdXMgcGFyYW1ldGVycywgdGhleSB3aWxsIG9ubHkgYmUg
dXNlZCBieSBwcmV2aW91cyBPcGVuV3J0IHByb2plY3RzLg0KDQpUaGFua3MsDQpEYXZpZA0KDQo+
IC0tDQo+IFJhZmHFgg0K
^ permalink raw reply
* Re: [PATCH v3 0/2] mac80211: use crypto shash for AES cmac
From: Johannes Berg @ 2017-02-08 8:19 UTC (permalink / raw)
To: Ard Biesheuvel, linux-wireless; +Cc: davem, netdev, jouni
In-Reply-To: <1486378168-31028-1-git-send-email-ard.biesheuvel@linaro.org>
Both applied, thanks.
johannes
^ permalink raw reply
* Re: [PATCH] Print text for disassociation reason.
From: Johannes Berg @ 2017-02-08 8:18 UTC (permalink / raw)
To: arekm; +Cc: linux-wireless
In-Reply-To: <201702061453.08816.a.miskiewicz@gmail.com>
> Don't know why it wasn't printed there with
> ieee80211_get_reason_code_string in first
> place. Works for me:
>
> kernel: wlan0: disassociated from 04:b0:20:33:ff:1f (Reason:
> 34=DISASSOC_LOW_ACK)
This patch needs a "mac80211: " prefix, and I'd prefer no . at the end
(but that's not a hard rule)
> ps. can't send patch in normal way due to postmaster@vger weirdness,
> so inserted
> below
>
> From c9b55bb44fe0b902f376a41fa930c9a67a438511 Mon Sep 17 00:00:00
> 2001
> From: =?UTF-8?q?Arkadiusz=20Mi=C5=9Bkiewicz?= <arekm@maven.pl>
> Date: Mon, 6 Feb 2017 14:45:15 +0100
> Subject: [PATCH] Print text for disassociation reason.
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> When disassociation happens only numeric reason is printed
> in ieee80211_rx_mgmt_disassoc(). Add text variant, too.
>
> Signed-off-by: Arkadiusz Miśkiewicz <arekm@maven.pl>
This is useless to me, please resubmit without all the fluff. You can
insert a "From: " line into the first line of the email *body* to get
the author correct, if you can't actually send it from the correct
email address. git send-email will even do that for you.
johannes
^ permalink raw reply
* Re: [PATCH v3 1/2] mac80211: fils_aead: Use crypto api CMAC shash rather than bare cipher
From: Johannes Berg @ 2017-02-08 7:46 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: <linux-wireless@vger.kernel.org>, David S. Miller,
<netdev@vger.kernel.org>, Jouni Malinen
In-Reply-To: <CAKv+Gu9Be-bA-Trn5cMwVvf4+yMm8w2Krm59WGAhdM3bxBSJfw@mail.gmail.com>
On Wed, 2017-02-08 at 07:45 +0000, Ard Biesheuvel wrote:
> On 8 February 2017 at 07:00, Johannes Berg <johannes@sipsolutions.net
> > wrote:
> > This looks strange to me:
> >
> > > +static int aes_s2v(struct crypto_shash *tfm,
> > > size_t num_elem, const u8 *addr[], size_t len[],
> > > u8 *v)
> > > {
> > > - u8 d[AES_BLOCK_SIZE], tmp[AES_BLOCK_SIZE];
> > > + u8 d[AES_BLOCK_SIZE], tmp[AES_BLOCK_SIZE] = {};
> > > + SHASH_DESC_ON_STACK(desc, tfm);
> >
> > desc declared
> >
> > >
> > > + crypto_shash_digest(desc, tmp, AES_BLOCK_SIZE, d);
> >
> > used here
> >
>
> Each digest() call combines a init()/update()/final() sequence
>
> > > + crypto_shash_init(desc);
> >
> > but initialized now?
> >
>
> ... for the 6th time, or so. The final vector may require two
> update()s, so we cannot use digest() here. But we can use finup() for
> the last one, which combines update() and final().
>
> Hence,
>
> init()/finup()
>
> or
>
> init()/update()/finup()
>
> depending on the length of the last vector.
Great, thanks for the explanation :)
johannes
^ permalink raw reply
* Re: [PATCH v3 1/2] mac80211: fils_aead: Use crypto api CMAC shash rather than bare cipher
From: Ard Biesheuvel @ 2017-02-08 7:45 UTC (permalink / raw)
To: Johannes Berg
Cc: <linux-wireless@vger.kernel.org>, David S. Miller,
<netdev@vger.kernel.org>, Jouni Malinen
In-Reply-To: <1486537227.4603.2.camel@sipsolutions.net>
On 8 February 2017 at 07:00, Johannes Berg <johannes@sipsolutions.net> wrote:
> This looks strange to me:
>
>> +static int aes_s2v(struct crypto_shash *tfm,
>> size_t num_elem, const u8 *addr[], size_t len[],
>> u8 *v)
>> {
>> - u8 d[AES_BLOCK_SIZE], tmp[AES_BLOCK_SIZE];
>> + u8 d[AES_BLOCK_SIZE], tmp[AES_BLOCK_SIZE] = {};
>> + SHASH_DESC_ON_STACK(desc, tfm);
>
> desc declared
>
>>
>> + crypto_shash_digest(desc, tmp, AES_BLOCK_SIZE, d);
>
> used here
>
Each digest() call combines a init()/update()/final() sequence
>> + crypto_shash_init(desc);
>
> but initialized now?
>
... for the 6th time, or so. The final vector may require two
update()s, so we cannot use digest() here. But we can use finup() for
the last one, which combines update() and final().
Hence,
init()/finup()
or
init()/update()/finup()
depending on the length of the last vector.
^ permalink raw reply
* Re: [PATCH v9] Add new mac80211 driver mwlwifi.
From: Rafał Miłecki @ 2017-02-08 7:44 UTC (permalink / raw)
To: David Lin
Cc: Steve deRosier, Kalle Valo, linux-wireless@vger.kernel.org,
Johannes Berg, Chor Teck Law, James Lin, Pete Hsieh
In-Reply-To: <8492870c897543a1b3c635a96f1066cb@SC-EXCH02.marvell.com>
On 8 February 2017 at 08:28, David Lin <dlin@marvell.com> wrote:
>> From: Rafa=C5=82 Mi=C5=82ecki [mailto:zajec5@gmail.com] worte:
>> Sent: Wednesday, February 08, 2017 3:24 PM
>> On 8 February 2017 at 07:30, David Lin <dlin@marvell.com> wrote:
>> > steve.derosier@gmail.com [mailto:steve.derosier@gmail.com] wrote:
>> >> On Tue, Feb 7, 2017 at 10:15 PM, David Lin <dlin@marvell.com> wrote:
>> >> >> Rafa=C5=82 Mi=C5=82ecki [mailto:zajec5@gmail.com] wrote:
>> >> >> Please use ieee80211-freq-limit:
>> >> >> https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/co
>> >> >> mmi
>> >> >> t/?id=3Db3
>> >> >> 30b25eaabda00d74e47566d9200907da381896
>> >> >>
>> >> >> Most likely with wiphy_read_of_freq_limits helper:
>> >> >> https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/co
>> >> >> mmi
>> >> >> t/?id=3De6
>> >> >> 91ac2f75b69bee743f0370d79454ba4429b175
>> >> >
>> >> > I already replied meaning of these parameters:
>> >> > <marvell,2ghz> is used to disable 2g band.
>> >> > <marvell,5ghz> is used to disable 5g band.
>> >> > <marvell, chainmask> is used to specify antenna number (if default
>> >> > number
>> >> is suitable for you, there is no need to use this parameter).
>> >> > <marvell,powertable> should not be used for chip with device power
>> table.
>> >> In fact, this parameter should not be used any more.
>> >> >
>> >>
>> >> David, I think you're not understanding the comment, or at least
>> >> that's what it looks like to me. Yes, you did reply as to the meaning=
.
>> >> And, your reply, while informative, didn't tell us you understood and
>> >> were willing to fix the problem. I doubt you meant it this way, but
>> >> it feels defensive and like a brush-off.
>> >>
>> >> First off, you will still have to document any DT bindings you're
>> >> adding. Just because you answer the question in the review doesn't
>> >> mean you're not responsible for doing so.
>> >>
>> >> And second off, I think that Rafal (and sorry about my spelling,
>> >> looks like there's some sort of accent on the l that I don't know how
>> >> to make my keyboard do) is saying: there's already some generic
>> >> bindings that can be used to disable the 2g or 5g bands. Granted
>> >> they're even newer than your patch, but I do think if said bindings e=
xist and
>> are appropriate, you should use them.
>> >>
>> >> - Steve
>> >
>> > These parameters are marvell proprietary parameters, I don't think it =
should
>> be added to DT bindings.
>>
>> Steve is correct.
>>
>> You have to document new properties, just because they are Marvell speci=
fic
>> doesn't change anything. You just document them in a proper place.
>>
>
> All right. I will do that.
>
>>
>> > BTW, <marvell,2ghz> and <marvell,5ghz> are only used for mwlwifi to re=
port
>> supported bands, it is not related to limitation of frequency.
>>
>> How reporting a single band doesn't limit reported frequencies? You can
>> achieve exactly the same using generic property, so there is no place fo=
r
>> Marvell specific ones.
>>
>> In fact there were drivers of 3 vendors requiring band/freq-related desc=
ription
>> in DT: Broadcom, Marvell & Mediatek. This property was discussed & desig=
ned
>> to support all limitation cases we found possible to make it usable with
>> (hopefully) all drivers.
>>
>
> I only need simple way to disable 2g or 5g band. I will follow your sugge=
stion to document these marvell proprietary parameters.
Seriously? Refusing to use generic binding because you think
marvell,5ghz;
is simpler than
ieee80211-freq-limit =3D <2402000 2482000>;
(not to mention your property seems reversed!)?
I don't know how else to explain this to you. We don't want duplicated
properties where one can work. Just use existing one. Don't add new
one even if documented.
--=20
Rafa=C5=82
^ permalink raw reply
* RE: [PATCH v9] Add new mac80211 driver mwlwifi.
From: David Lin @ 2017-02-08 7:28 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Steve deRosier, Kalle Valo, linux-wireless@vger.kernel.org,
Johannes Berg, Chor Teck Law, James Lin, Pete Hsieh
In-Reply-To: <CACna6rz8chrPU+yZC0xakKVeLFm8fgpDoSFP_Vyo8mH1C+DCzQ@mail.gmail.com>
PiBGcm9tOiBSYWZhxYIgTWnFgmVja2kgW21haWx0bzp6YWplYzVAZ21haWwuY29tXSB3b3J0ZToN
Cj4gU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwOCwgMjAxNyAzOjI0IFBNDQo+IE9uIDggRmVi
cnVhcnkgMjAxNyBhdCAwNzozMCwgRGF2aWQgTGluIDxkbGluQG1hcnZlbGwuY29tPiB3cm90ZToN
Cj4gPiBzdGV2ZS5kZXJvc2llckBnbWFpbC5jb20gW21haWx0bzpzdGV2ZS5kZXJvc2llckBnbWFp
bC5jb21dIHdyb3RlOg0KPiA+PiBPbiBUdWUsIEZlYiA3LCAyMDE3IGF0IDEwOjE1IFBNLCBEYXZp
ZCBMaW4gPGRsaW5AbWFydmVsbC5jb20+IHdyb3RlOg0KPiA+PiA+PiBSYWZhxYIgTWnFgmVja2kg
W21haWx0bzp6YWplYzVAZ21haWwuY29tXSB3cm90ZToNCj4gPj4gPj4gUGxlYXNlIHVzZSBpZWVl
ODAyMTEtZnJlcS1saW1pdDoNCj4gPj4gPj4gaHR0cHM6Ly9naXQua2VybmVsLm9yZy9jZ2l0L2xp
bnV4L2tlcm5lbC9naXQvZGF2ZW0vbmV0LW5leHQuZ2l0L2NvDQo+ID4+ID4+IG1taQ0KPiA+PiA+
PiB0Lz9pZD1iMw0KPiA+PiA+PiAzMGIyNWVhYWJkYTAwZDc0ZTQ3NTY2ZDkyMDA5MDdkYTM4MTg5
Ng0KPiA+PiA+Pg0KPiA+PiA+PiBNb3N0IGxpa2VseSB3aXRoIHdpcGh5X3JlYWRfb2ZfZnJlcV9s
aW1pdHMgaGVscGVyOg0KPiA+PiA+PiBodHRwczovL2dpdC5rZXJuZWwub3JnL2NnaXQvbGludXgv
a2VybmVsL2dpdC9kYXZlbS9uZXQtbmV4dC5naXQvY28NCj4gPj4gPj4gbW1pDQo+ID4+ID4+IHQv
P2lkPWU2DQo+ID4+ID4+IDkxYWMyZjc1YjY5YmVlNzQzZjAzNzBkNzk0NTRiYTQ0MjliMTc1DQo+
ID4+ID4NCj4gPj4gPiBJIGFscmVhZHkgcmVwbGllZCBtZWFuaW5nIG9mIHRoZXNlIHBhcmFtZXRl
cnM6DQo+ID4+ID4gPG1hcnZlbGwsMmdoej4gaXMgdXNlZCB0byBkaXNhYmxlIDJnIGJhbmQuDQo+
ID4+ID4gPG1hcnZlbGwsNWdoej4gaXMgdXNlZCB0byBkaXNhYmxlIDVnIGJhbmQuDQo+ID4+ID4g
PG1hcnZlbGwsIGNoYWlubWFzaz4gaXMgdXNlZCB0byBzcGVjaWZ5IGFudGVubmEgbnVtYmVyIChp
ZiBkZWZhdWx0DQo+ID4+ID4gbnVtYmVyDQo+ID4+IGlzIHN1aXRhYmxlIGZvciB5b3UsIHRoZXJl
IGlzIG5vIG5lZWQgdG8gdXNlIHRoaXMgcGFyYW1ldGVyKS4NCj4gPj4gPiA8bWFydmVsbCxwb3dl
cnRhYmxlPiBzaG91bGQgbm90IGJlIHVzZWQgZm9yIGNoaXAgd2l0aCBkZXZpY2UgcG93ZXINCj4g
dGFibGUuDQo+ID4+IEluIGZhY3QsIHRoaXMgcGFyYW1ldGVyIHNob3VsZCBub3QgYmUgdXNlZCBh
bnkgbW9yZS4NCj4gPj4gPg0KPiA+Pg0KPiA+PiBEYXZpZCwgSSB0aGluayB5b3UncmUgbm90IHVu
ZGVyc3RhbmRpbmcgdGhlIGNvbW1lbnQsIG9yIGF0IGxlYXN0DQo+ID4+IHRoYXQncyB3aGF0IGl0
IGxvb2tzIGxpa2UgdG8gbWUuIFllcywgeW91IGRpZCByZXBseSBhcyB0byB0aGUgbWVhbmluZy4N
Cj4gPj4gQW5kLCB5b3VyIHJlcGx5LCB3aGlsZSBpbmZvcm1hdGl2ZSwgZGlkbid0IHRlbGwgdXMg
eW91IHVuZGVyc3Rvb2QgYW5kDQo+ID4+IHdlcmUgd2lsbGluZyB0byBmaXggdGhlIHByb2JsZW0u
IEkgZG91YnQgeW91IG1lYW50IGl0IHRoaXMgd2F5LCBidXQNCj4gPj4gaXQgZmVlbHMgZGVmZW5z
aXZlIGFuZCBsaWtlIGEgYnJ1c2gtb2ZmLg0KPiA+Pg0KPiA+PiBGaXJzdCBvZmYsIHlvdSB3aWxs
IHN0aWxsIGhhdmUgdG8gZG9jdW1lbnQgYW55IERUIGJpbmRpbmdzIHlvdSdyZQ0KPiA+PiBhZGRp
bmcuIEp1c3QgYmVjYXVzZSB5b3UgYW5zd2VyIHRoZSBxdWVzdGlvbiBpbiB0aGUgcmV2aWV3IGRv
ZXNuJ3QNCj4gPj4gbWVhbiB5b3UncmUgbm90IHJlc3BvbnNpYmxlIGZvciBkb2luZyBzby4NCj4g
Pj4NCj4gPj4gQW5kIHNlY29uZCBvZmYsIEkgdGhpbmsgdGhhdCBSYWZhbCAoYW5kIHNvcnJ5IGFi
b3V0IG15IHNwZWxsaW5nLA0KPiA+PiBsb29rcyBsaWtlIHRoZXJlJ3Mgc29tZSBzb3J0IG9mIGFj
Y2VudCBvbiB0aGUgbCB0aGF0IEkgZG9uJ3Qga25vdyBob3cNCj4gPj4gdG8gbWFrZSBteSBrZXli
b2FyZCBkbykgaXMgc2F5aW5nOiB0aGVyZSdzIGFscmVhZHkgc29tZSBnZW5lcmljDQo+ID4+IGJp
bmRpbmdzIHRoYXQgY2FuIGJlIHVzZWQgdG8gZGlzYWJsZSB0aGUgMmcgb3IgNWcgYmFuZHMuIEdy
YW50ZWQNCj4gPj4gdGhleSdyZSBldmVuIG5ld2VyIHRoYW4geW91ciBwYXRjaCwgYnV0IEkgZG8g
dGhpbmsgaWYgc2FpZCBiaW5kaW5ncyBleGlzdCBhbmQNCj4gYXJlIGFwcHJvcHJpYXRlLCB5b3Ug
c2hvdWxkIHVzZSB0aGVtLg0KPiA+Pg0KPiA+PiAtIFN0ZXZlDQo+ID4NCj4gPiBUaGVzZSBwYXJh
bWV0ZXJzIGFyZSBtYXJ2ZWxsIHByb3ByaWV0YXJ5IHBhcmFtZXRlcnMsIEkgZG9uJ3QgdGhpbmsg
aXQgc2hvdWxkDQo+IGJlIGFkZGVkIHRvIERUIGJpbmRpbmdzLg0KPiANCj4gU3RldmUgaXMgY29y
cmVjdC4NCj4gDQo+IFlvdSBoYXZlIHRvIGRvY3VtZW50IG5ldyBwcm9wZXJ0aWVzLCBqdXN0IGJl
Y2F1c2UgdGhleSBhcmUgTWFydmVsbCBzcGVjaWZpYw0KPiBkb2Vzbid0IGNoYW5nZSBhbnl0aGlu
Zy4gWW91IGp1c3QgZG9jdW1lbnQgdGhlbSBpbiBhIHByb3BlciBwbGFjZS4NCj4gDQoNCkFsbCBy
aWdodC4gSSB3aWxsIGRvIHRoYXQuDQoNCj4gDQo+ID4gQlRXLCA8bWFydmVsbCwyZ2h6PiBhbmQg
PG1hcnZlbGwsNWdoej4gYXJlIG9ubHkgdXNlZCBmb3IgbXdsd2lmaSB0byByZXBvcnQNCj4gc3Vw
cG9ydGVkIGJhbmRzLCBpdCBpcyBub3QgcmVsYXRlZCB0byBsaW1pdGF0aW9uIG9mIGZyZXF1ZW5j
eS4NCj4gDQo+IEhvdyByZXBvcnRpbmcgYSBzaW5nbGUgYmFuZCBkb2Vzbid0IGxpbWl0IHJlcG9y
dGVkIGZyZXF1ZW5jaWVzPyBZb3UgY2FuDQo+IGFjaGlldmUgZXhhY3RseSB0aGUgc2FtZSB1c2lu
ZyBnZW5lcmljIHByb3BlcnR5LCBzbyB0aGVyZSBpcyBubyBwbGFjZSBmb3INCj4gTWFydmVsbCBz
cGVjaWZpYyBvbmVzLg0KPiANCj4gSW4gZmFjdCB0aGVyZSB3ZXJlIGRyaXZlcnMgb2YgMyB2ZW5k
b3JzIHJlcXVpcmluZyBiYW5kL2ZyZXEtcmVsYXRlZCBkZXNjcmlwdGlvbg0KPiBpbiBEVDogQnJv
YWRjb20sIE1hcnZlbGwgJiBNZWRpYXRlay4gVGhpcyBwcm9wZXJ0eSB3YXMgZGlzY3Vzc2VkICYg
ZGVzaWduZWQNCj4gdG8gc3VwcG9ydCBhbGwgbGltaXRhdGlvbiBjYXNlcyB3ZSBmb3VuZCBwb3Nz
aWJsZSB0byBtYWtlIGl0IHVzYWJsZSB3aXRoDQo+IChob3BlZnVsbHkpIGFsbCBkcml2ZXJzLg0K
PiANCg0KSSBvbmx5IG5lZWQgc2ltcGxlIHdheSB0byBkaXNhYmxlIDJnIG9yIDVnIGJhbmQuIEkg
d2lsbCBmb2xsb3cgeW91ciBzdWdnZXN0aW9uIHRvIGRvY3VtZW50IHRoZXNlIG1hcnZlbGwgcHJv
cHJpZXRhcnkgcGFyYW1ldGVycy4NCg0KVGhhbmtzLA0KRGF2aWQNCg0KPiAtLQ0KPiBSYWZhxYIN
Cg==
^ permalink raw reply
* Re: [PATCH v9] Add new mac80211 driver mwlwifi.
From: Rafał Miłecki @ 2017-02-08 7:23 UTC (permalink / raw)
To: David Lin
Cc: Steve deRosier, Kalle Valo, linux-wireless@vger.kernel.org,
Johannes Berg, Chor Teck Law, James Lin, Pete Hsieh
In-Reply-To: <def0e631e44d4b44a87124a5b530d6ec@SC-EXCH02.marvell.com>
On 8 February 2017 at 07:30, David Lin <dlin@marvell.com> wrote:
> steve.derosier@gmail.com [mailto:steve.derosier@gmail.com] wrote:
>> On Tue, Feb 7, 2017 at 10:15 PM, David Lin <dlin@marvell.com> wrote:
>> >> Rafa=C5=82 Mi=C5=82ecki [mailto:zajec5@gmail.com] wrote:
>> >> Please use ieee80211-freq-limit:
>> >> https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commi
>> >> t/?id=3Db3
>> >> 30b25eaabda00d74e47566d9200907da381896
>> >>
>> >> Most likely with wiphy_read_of_freq_limits helper:
>> >> https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commi
>> >> t/?id=3De6
>> >> 91ac2f75b69bee743f0370d79454ba4429b175
>> >
>> > I already replied meaning of these parameters:
>> > <marvell,2ghz> is used to disable 2g band.
>> > <marvell,5ghz> is used to disable 5g band.
>> > <marvell, chainmask> is used to specify antenna number (if default num=
ber
>> is suitable for you, there is no need to use this parameter).
>> > <marvell,powertable> should not be used for chip with device power tab=
le.
>> In fact, this parameter should not be used any more.
>> >
>>
>> David, I think you're not understanding the comment, or at least that's =
what it
>> looks like to me. Yes, you did reply as to the meaning.
>> And, your reply, while informative, didn't tell us you understood and we=
re
>> willing to fix the problem. I doubt you meant it this way, but it feels =
defensive
>> and like a brush-off.
>>
>> First off, you will still have to document any DT bindings you're adding=
. Just
>> because you answer the question in the review doesn't mean you're not
>> responsible for doing so.
>>
>> And second off, I think that Rafal (and sorry about my spelling, looks l=
ike
>> there's some sort of accent on the l that I don't know how to make my
>> keyboard do) is saying: there's already some generic bindings that can b=
e used
>> to disable the 2g or 5g bands. Granted they're even newer than your patc=
h,
>> but I do think if said bindings exist and are appropriate, you should us=
e them.
>>
>> - Steve
>
> These parameters are marvell proprietary parameters, I don't think it sho=
uld be added to DT bindings.
Steve is correct.
You have to document new properties, just because they are Marvell
specific doesn't change anything. You just document them in a proper
place.
> BTW, <marvell,2ghz> and <marvell,5ghz> are only used for mwlwifi to repor=
t supported bands, it is not related to limitation of frequency.
How reporting a single band doesn't limit reported frequencies? You
can achieve exactly the same using generic property, so there is no
place for Marvell specific ones.
In fact there were drivers of 3 vendors requiring band/freq-related
description in DT: Broadcom, Marvell & Mediatek. This property was
discussed & designed to support all limitation cases we found possible
to make it usable with (hopefully) all drivers.
--=20
Rafa=C5=82
^ permalink raw reply
* Re: [PATCH v3 1/2] mac80211: fils_aead: Use crypto api CMAC shash rather than bare cipher
From: Johannes Berg @ 2017-02-08 7:00 UTC (permalink / raw)
To: Ard Biesheuvel, linux-wireless; +Cc: davem, netdev, jouni
In-Reply-To: <1486378168-31028-2-git-send-email-ard.biesheuvel@linaro.org>
This looks strange to me:
> +static int aes_s2v(struct crypto_shash *tfm,
> size_t num_elem, const u8 *addr[], size_t len[],
> u8 *v)
> {
> - u8 d[AES_BLOCK_SIZE], tmp[AES_BLOCK_SIZE];
> + u8 d[AES_BLOCK_SIZE], tmp[AES_BLOCK_SIZE] = {};
> + SHASH_DESC_ON_STACK(desc, tfm);
desc declared
>
> + crypto_shash_digest(desc, tmp, AES_BLOCK_SIZE, d);
used here
> + crypto_shash_init(desc);
but initialized now?
johannes
^ permalink raw reply
* Re: Changing of WMM queue parameters forbidden for IBSS interfaces
From: Johannes Berg @ 2017-02-08 6:58 UTC (permalink / raw)
To: Jörg Pommnitz, linux-wireless
In-Reply-To: <CAEvAWuH-HkC1VNbtLZdjtNQehcE2CR+k0RP=24xMx3TTxzFdUg@mail.gmail.com>
On Wed, 2017-02-01 at 15:24 +0100, Jörg Pommnitz wrote:
> Hello all,
>
> I'm trying to change the WMM parameters for an IBSS network. I'm
> adding a command to set txq_params to iw. Sadly the current kernel
> code explicitly denies this for interfaces other than AP and P2P (see
> http://lxr.free-electrons.com/source/net/wireless/nl80211.c#L2279).
>
> Is there a reason why this should not be done for IBSS interfaces?
I guess the whole thing was just ignored - we should also *adopt* the
EDCA parameters when joining an IBSS network, which I don't think we do
either.
I'm not sure we can actually modify them on the fly though - since
adoption is required, such changes would have a hard time propagating
through.
If really necessary, we'd have to implement adoption and probably only
allow setting it at IBSS creation time.
johannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox