shows HT40 is capable.
Now, I understand why you rejected this patch.
But now, when disable_ht=1, no HT Capabilities element in beacon even
though the node supports HT.
My trailing patch could solve the issue.
Masashi Honma.
AP_SUP_WIDTH_20_40 bit in beacon was below.
hostapd0.conf
IEEE80211_HT_CAP_SUP_WIDTH_20_40 = 1
hostapd1.conf
IEEE80211_HT_CAP_SUP_WIDTH_20_40 = 0
So I think the bit should be zero if disabled also for mesh peer.
Masashi Honma.
On 2016年08月01日 19:03, Johannes Berg wrote:
But why is that behaviour *correct*? We still support 40 MHz bandwidth
things, we just don't use them if we disable HT40.
I could not fully understand your concern...
Do you mean we have 2 bugs about disabling HT40 ?
1) bits in HT capabilities IE
2)
On 2016年07月22日 14:26, Masashi Honma wrote:
> On 2016年07月14日 05:07, Yaniv Machani wrote:
>> +
>> +/* if channel width is 20MHz - configure HT capab accordingly*/
>> +if (sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_20) {
>> +cap &=
On 2016年07月14日 05:07, Yaniv Machani wrote:
+
+ /* if channel width is 20MHz - configure HT capab accordingly*/
+ if (sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_20) {
+ cap &= ~IEEE80211_HT_CAP_SUP_WIDTH_20_40;
+ cap &= ~IEEE80211_HT_CAP_DSSSCCK
On 2016年07月12日 05:01, David Miller wrote:
The code is correct and optimal as-is. There is no gain to your
changes. gfp_any() will do the right thing.
In fact, your change makes the code more error prone because if any
of these code paths get moved into an atomic context they will break
unless
This commit extends rtnl_unicast() to specify GFP flags.
This commit depends on Eric Dumazet's commits below.
ipv4: do not abuse GFP_ATOMIC in inet_netconf_notify_devconf()
ipv6: do not abuse GFP_ATOMIC in inet6_netconf_notify_devconf()
Signed-off-by: Masashi Honma
---
in
On 2016年07月06日 09:28, Masashi Honma wrote:
> Though netlink_broadcast() ...
Thanks for reply of David Miller, Eric Dumazet, David Teigrand.
On the basis of their comment, only rtnl_unicast() looks need to add gfp
flag
argument. So I will drop almost of patches except 0005.
I will send patch
On 2016年07月09日 01:08, David Teigland wrote:
On Thu, Jul 07, 2016 at 09:35:45AM +0900, Masashi Honma wrote:
At the fs/dlm/netlink.c#dlm_timeout_warn(),
prepare_data allocates buffer with GFP_NOFS
and send_data() sends the buffer.
But send_data() uses GFP_KERNEL or GFP_ATOMIC inside it.
Should
On 2016年07月08日 11:56, Eric Dumazet wrote:
Managing to mix GFP_ATOMIC and GFP_KERNEL almost randomly as you did in
this patch is definitely not good.
Further more, RTNL is a mutex, held in control path, designed to allow
schedules and waiting for memory under pressure.
We do not want to encoura
At the fs/dlm/netlink.c#dlm_timeout_warn(),
prepare_data allocates buffer with GFP_NOFS
and send_data() sends the buffer.
But send_data() uses GFP_KERNEL or GFP_ATOMIC inside it.
Should it be replaced by GFP_NOFS ?
Masashi Honma
cgit/linux/kernel/git/davem/net-next.git/tree/net/netlabel
Where is a correct tree ?
Regards,
Masashi Honma.
Signed-off-by: Masashi Honma
---
drivers/net/gtp.c | 3 ++-
drivers/net/team/team.c | 5 +++--
drivers/net/wireless/mac80211_hwsim.c | 2 +-
fs/dlm/netlink.c | 2 +-
include/net/genetlink.h | 8 +---
kernel/taskstats.c
Add allocation flag to genlmsg_reply() and remove netlink_unicast()
temporal functionality for stepwise modification.
Signed-off-by: Masashi Honma
---
drivers/block/drbd/drbd_nl.c | 2 +-
drivers/net/wireless/mac80211_hwsim.c | 2 +-
include/net/genetlink.h | 7
Signed-off-by: Masashi Honma
---
include/linux/netfilter/nfnetlink.h | 2 +-
net/netfilter/nfnetlink.c | 4 ++--
net/netfilter/nfnetlink_log.c | 4 ++--
net/netfilter/nfnetlink_queue.c | 3 ++-
4 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/include/linux
Signed-off-by: Masashi Honma
---
drivers/infiniband/core/iwpm_msg.c | 6 +++---
drivers/infiniband/core/iwpm_util.c | 5 +++--
drivers/infiniband/core/iwpm_util.h | 1 +
drivers/infiniband/core/netlink.c | 4 ++--
include/rdma/rdma_netlink.h | 3 ++-
5 files changed, 11 insertions
Signed-off-by: Masashi Honma
---
crypto/crypto_user.c | 3 ++-
drivers/infiniband/core/netlink.c | 2 +-
include/net/genetlink.h | 2 +-
include/net/netlink.h | 6 --
net/core/rtnetlink.c | 2 +-
net/netfilter/nf_tables_api.c | 10
Signed-off-by: Masashi Honma
---
include/linux/rtnetlink.h | 3 ++-
net/core/net_namespace.c | 2 +-
net/core/rtnetlink.c | 10 ++
net/dcb/dcbnl.c | 2 +-
net/decnet/dn_route.c | 3 ++-
net/ipv4/devinet.c| 2 +-
net/ipv4/ipmr.c | 6 --
net
y guessing based on context. If we
could not determine the value, we remain it gfp_any(). We welcome
comments like "this gfp_any() should be GFP_KERNEL". Of course other
comments are welcome as well.
This series of patches are not tested.
This is a RFC because this does not fix existing issu
ned-off-by: Masashi Honma
---
drivers/connector/connector.c| 2 +-
include/linux/netlink.h | 3 ++-
include/net/netlink.h| 2 +-
kernel/audit.c | 9 +
net/core/rtnetlink.c | 2 +-
net/ipv4/fib_frontend.c
The fib6_get_table() is called twice to show the warning.
This patch reduces calling the function.
Signed-off-by: Masashi Honma
---
include/net/ip6_fib.h | 2 +-
net/ipv6/fib6_rules.c | 3 ++-
net/ipv6/ip6_fib.c| 10 +++---
net/ipv6/route.c | 13 -
4 files changed, 14
On 2015/10/19 15:09, David Miller wrote:
This is not correct.
The whole point of the test is so that the kernel log message
warning for failing to provide NLM_F_CREATE can be printed
in precisely the correct conditions.
Thanks. Now I understand importance of the warning.
Though fib6_get_table
These lines could be aggregated to one line because fib6_new_table() calls
fib6_get_table() inside on both cases CONFIG_IPV6_MULTIPLE_TABLES is enabled or
not.
Signed-off-by: Masashi Honma
---
net/ipv6/route.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/net
23 matches
Mail list logo
