On Tue, Feb 12, 2019 at 08:03:17PM +0100, Johannes Berg wrote:
> commit 60854fd94573f0d3b80b55b40cf0140a0430f3ab
> Author: Bob Copeland
> Date: Wed Mar 2 10:09:20 2016 -0500
>
> mac80211: mesh: convert path table to rhashtable
>
> which is kinda old. Not sure wh
ches
the semantic of "tx fields under tx_lock." On the other hand, maybe it's
just me, but I tend to look askance at just-in-case READ_ONCEs sprinkled
about.
--
Bob Copeland %% https://bobcopeland.com/
> > +
> >
> > Just sanity checking - what's protecting htt->num_pending_tx? or is it
> > serialised some other way?
[...]
> I can't see that any of the examples applies, but let's add READ_ONCE(),
> to make sure that the compiler doesn&
report, is this
> intentional?
One for kbuildbot team I guess, not sure how it determines whom to email.
Personally I would be ok if only myself and maybe linux-wireless got the
emails for this tree since most build failures are similar noise.
--
Bob Copeland %% https://bobcopeland.com/
es prefixed by >>):
>
>drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_port_probe':
> >> drivers/net/ethernet/marvell/mvpp2.c:7618:49: error: passing argument 4 of
> >> 'mvpp2_port_copy_mac_addr' from incompatible pointer type
&g
re the only cases where "true" is passed).
Generally I try to avoid bool parameters where possible because when you
look at a callsite, you don't know immediately what "true" and "false"
mean, and also each one you add doubles the code paths through a given
function.
--
Bob Copeland %% http://bobcopeland.com/
are identical for the first 10 bytes */
> memset(&ht_oper->basic_set, 0, 16);
> - memcpy(&ht_oper->basic_set, &ht_cap->mcs, 10);
This change doesn't look right (basic mcs set will be all zeroes) but
then, neither does the original code. Basic MCS set for a mesh STA should
be the mandatory MCSes according to 9.7.4.
--
Bob Copeland %% http://bobcopeland.com/
27;ll give this a test on ath10k and wcn36xx as they are the ones most
likely to care about ordering.
--
Bob Copeland %% http://bobcopeland.com/
(struct ieee80211_sub_if_data
> *sdata,
> sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_10)
> return 0;
>
> +/* determine capability flags */
> + cap = sband->ht_cap.cap;
There is some weird whitespace here (space instead of tabs for the
comment).
--
Bob Copeland %% http://bobcopeland.com/
ot ESTAB and if so, decrease
> plink count and update beacon.
This should be fixed already (and properly) by the patch
"mac80211: Fix mesh estab links counting" -- please let us
know if you have a case that's still broken with that fix.
--
Bob Copeland %% http://bobcopeland.com/
if (!sdata->u.mesh.user_mpm) {
> changed |= mesh_plink_deactivate(sta);
> del_timer_sync(&sta->mesh->plink_timer);
> - }
> + } else
> + mesh_path_flush_by_nexthop(sta);
And this is already fixed in mac80211-next.
--
Bob Copeland %% http://bobcopeland.com/
On Mon, Jun 20, 2016 at 04:00:19PM +0300, Maxim Altshul wrote:
> 2. Implements the opcode and the mechanism that reports the rates
> in TI driver.
Does this mean TI driver will support mesh at some point?
--
Bob Copeland %% http://bobcopeland.com/
On Wed, Mar 16, 2016 at 11:36:31AM -0700, Dave Taht wrote:
> That is the sanest 802.11e queue behavior I have ever seen! (at both
> 6 and 300mbit! in the ath10k patched mac test)
Out of curiosity, why does BE have larger latency than BK in that chart?
I'd have expected the opposit
queues might have responses ready quicker).
Got it, that makes sense. Thanks for the explanation!
--
Bob Copeland %% http://bobcopeland.com/
d 1ms).
What about implementing ops->get_expected_throughput? This would be
useful for mesh (both 11s and batman) as well since they need to
estimate link quality to pick a path.
--
Bob Copeland %% http://bobcopeland.com/
On Thu, Mar 03, 2016 at 04:26:19PM +0100, Johannes Berg wrote:
> On Wed, 2016-03-02 at 10:09 -0500, Bob Copeland wrote:
> > In certain cases, the 802.11 mesh pathtable code wants to
> > iterate over all of the entries in the forwarding table from
> > the receive path, which
existing callsites to pass in GFP_KERNEL.
Cc: Thomas Graf
Cc: netdev@vger.kernel.org
Acked-by: Thomas Graf
Signed-off-by: Bob Copeland
---
(-RFC, +Thomas's Ack)
include/linux/rhashtable.h | 3 ++-
lib/rhashtable.c | 6 --
net/ipv6/ila/ila_xlat.c| 3 ++-
net/netfilter/nft_h
: Thomas Graf
Cc: netdev@vger.kernel.org
Signed-off-by: Bob Copeland
---
net/mac80211/ieee80211_i.h | 11 +-
net/mac80211/mesh.c | 6 -
net/mac80211/mesh.h | 31 +-
net/mac80211/mesh_pathtbl.c | 786 ++--
4 files changed, 259 insertions
On Tue, Mar 01, 2016 at 02:54:16PM +0100, Johannes Berg wrote:
> On Sun, 2016-02-28 at 20:06 -0500, Bob Copeland wrote:
> > In certain cases, the 802.11 mesh pathtable code wants to
> > iterate over all of the entries in the forwarding table from
> > the receive path, which
existing callsites to pass in GFP_KERNEL.
Cc: Thomas Graf
Cc: netdev@vger.kernel.org
Signed-off-by: Bob Copeland
---
include/linux/rhashtable.h | 3 ++-
lib/rhashtable.c | 6 --
net/ipv6/ila/ila_xlat.c| 3 ++-
net/netfilter/nft_hash.c | 4 ++--
net/netlink/af_netlink.c | 3
: Thomas Graf
Cc: netdev@vger.kernel.org
Signed-off-by: Bob Copeland
---
net/mac80211/ieee80211_i.h | 11 +-
net/mac80211/mesh.c | 6 -
net/mac80211/mesh.h | 31 +-
net/mac80211/mesh_pathtbl.c | 786 ++--
4 files changed, 259 insertions
21 matches
Mail list logo
