On Fri, Feb 12, 2021 at 07:46:30PM -0800, Florian Fainelli wrote:
> Avoid a forward declaration by moving the callers of
> bcm54xx_config_clock_delay() below its body.
>
> Signed-off-by: Florian Fainelli
> ---
Reviewed-by: Vladimir Oltean
On Fri, Feb 12, 2021 at 07:46:31PM -0800, Florian Fainelli wrote:
> We have a number of unused flags defined today and since we are scarce
> on space and may need to introduce new flags in the future remove and
> shift every existing flag down into a contiguous assignment.
> PHY_BCM_FLAGS_MODE_1000
On Fri, Feb 12, 2021 at 07:46:32PM -0800, Florian Fainelli wrote:
> BCM54210E/BCM50212E has been verified to work correctly with the
> auto-power down configuration done by bcm54xx_adjust_rxrefclk(), add it
> to the list of PHYs working.
>
> While we are at it, provide an appropriate name for the
On Fri, Feb 12, 2021 at 08:18:40PM -0600, Robert Hancock wrote:
> + if (!phydev->sfp_bus &&
> + (!phydev->attached_dev || !phydev->attached_dev->sfp_bus)) {
First, do we want this to be repeated in every driver?
Second, are you sure this is the correct condition to be using for
this?
On Sat, Feb 13, 2021 at 03:42:46PM +0800, kernel test robot wrote:
>ld: net/dsa/tag_ocelot_8021q.o: in function `ocelot_xmit_ptp':
> >> net/dsa/tag_ocelot_8021q.c:34: undefined reference to
> >> `ocelot_port_inject_frame'
Good catch, the problem is that the DSA taggers can be built without
su
On Sun, Jan 31, 2021 at 12:19:50PM +, Russell King - ARM Linux admin wrote:
> On Sun, Jan 31, 2021 at 11:12:14AM +, Russell King - ARM Linux admin
> wrote:
> > I discussed it with Andrew earlier last year, and his response was:
> >
> > DT configuration of pause for fixed link probably is
From: Alexander Duyck
Date: Thu, 11 Feb 2021 19:18:45 -0800
> On Thu, Feb 11, 2021 at 11:00 AM Alexander Lobakin wrote:
> >
> > Reuse the old and forgotten SKB_ALLOC_NAPI to add an option to get
> > an skbuff_head from the NAPI cache instead of inplace allocation
> > inside __alloc_skb().
> > Th
From: Alexander Duyck
Date: Thu, 11 Feb 2021 19:28:52 -0800
> On Thu, Feb 11, 2021 at 10:57 AM Alexander Lobakin wrote:
> >
> > This function isn't much needed as NAPI skb queue gets bulk-freed
> > anyway when there's no more room, and even may reduce the efficiency
> > of bulk operations.
> > I
Style agrees with surrounding code
Thanks,
Jefferson
From efa185ac1a2b4716c6b5cf4e75c1eb0e9216893a Mon Sep 17 00:00:00 2001
From: Jefferson Carpenter
Date: Sat, 13 Feb 2021 16:00:15 +
Subject: [PATCH] lib/parman: Delete newline
Signed-off-by: Jefferson Carpenter
---
lib/parman.c | 1 -
1
Currently, all sorts of skb allocation always do allocate
skbuff_heads one by one via kmem_cache_alloc().
On the other hand, we have percpu napi_alloc_cache to store
skbuff_heads queued up for freeing and flush them by bulks.
We can use this cache not only for bulk-wiping, but also to obtain
heads
__build_skb_around() can never fail and always returns passed skb.
Make it return void to simplify and optimize the code.
Signed-off-by: Alexander Lobakin
---
net/core/skbuff.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
Eversince the introduction of __kmalloc_reserve(), "ip" argument
hasn't been used. _RET_IP_ is embedded inside
kmalloc_node_track_caller().
Remove the redundant macro and rename the function after it.
Signed-off-by: Alexander Lobakin
---
net/core/skbuff.c | 7 ++-
1 file changed, 2 insertion
Use unlikely() annotations for skbuff_head and data similarly to the
two other allocation functions and remove totally redundant goto.
Signed-off-by: Alexander Lobakin
---
net/core/skbuff.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/net/core/skbuff.c b/net/co
Just call __build_skb_around() instead of open-coding it.
Signed-off-by: Alexander Lobakin
---
net/core/skbuff.c | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 88566de26cd1..1c6f6ef70339 100644
--- a/net/core/skb
In preparation before reusing several functions in all three skb
allocation variants, move __alloc_skb() next to the
__netdev_alloc_skb() and __napi_alloc_skb().
No functional changes.
Signed-off-by: Alexander Lobakin
---
net/core/skbuff.c | 284 +++---
1
NAPI cache structures will be used for allocating skbuff_heads,
so move their declarations a bit upper.
Signed-off-by: Alexander Lobakin
---
net/core/skbuff.c | 90 +++
1 file changed, 45 insertions(+), 45 deletions(-)
diff --git a/net/core/skbuff.c b
Instead of just bulk-flushing skbuff_heads queued up through
napi_consume_skb() or __kfree_skb_defer(), try to reuse them
on allocation path.
If the cache is empty on allocation, bulk-allocate the first
16 elements, which is more efficient than per-skb allocation.
If the cache is full on freeing, b
{,__}napi_alloc_skb() is mostly used either for optional non-linear
receive methods (usually controlled via Ethtool private flags and off
by default) and/or for Rx copybreaks.
Use __napi_build_skb() here for obtaining skbuff_heads from NAPI cache
instead of inplace allocations. This includes both k
Reuse the old and forgotten SKB_ALLOC_NAPI to add an option to get
an skbuff_head from the NAPI cache instead of inplace allocation
inside __alloc_skb().
This implies that the function is called from softirq or BH-off
context, not for allocating a clone or from a distant node.
Cc: Alexander Duyck
This function isn't much needed as NAPI skb queue gets bulk-freed
anyway when there's no more room, and even may reduce the efficiency
of bulk operations.
It will be even less needed after reusing skb cache on allocation path,
so remove it and this way lighten network softirqs a bit.
Suggested-by:
napi_frags_finish() and napi_skb_finish() can only be called inside
NAPI Rx context, so we can feed NAPI cache with skbuff_heads that
got NAPI_MERGED_FREE verdict instead of immediate freeing.
Replace __kfree_skb() with __kfree_skb_defer() in napi_skb_finish()
and move napi_skb_free_stolen_head() t
From: Eric Dumazet
My prior cleanup missed that tcp_data_ready() has to look at SOCK_DONE.
Otherwise, an application using SO_RCVLOWAT will not get EPOLLIN event
if a FIN is received in the middle of expected payload.
The reason SOCK_DONE is not examined in tcp_epollin_ready()
is that tcp_poll()
Am 10.02.21 um 11:34 schrieb Reindl Harald:
Am 07.02.21 um 20:38 schrieb Jozsef Kadlecsik:
On Sun, 7 Feb 2021, Reindl Harald wrote:
well, the most important thing is that the firewall-vm stops to
kernel-panic
why is that still not part of 5.10.14 given how old that issue is :-(
https:/
On 2021-02-12 20:42, Sukadev Bhattiprolu wrote:
The work queue is used to queue reset requests like CHANGE-PARAM or
FAILOVER resets for the worker thread. When the adapter is being
removed
the adapter state is set to VNIC_REMOVING and the work queue is flushed
so no new work is added. However t
Am 13.02.21 um 17:09 schrieb Reindl Harald:
Am 10.02.21 um 11:34 schrieb Reindl Harald:
Am 07.02.21 um 20:38 schrieb Jozsef Kadlecsik:
On Sun, 7 Feb 2021, Reindl Harald wrote:
well, the most important thing is that the firewall-vm stops to
kernel-panic
why is that still not part of 5
Am 2021-02-13 01:18, schrieb Russell King - ARM Linux admin:
On Fri, Feb 12, 2021 at 11:40:59PM +0100, Michael Walle wrote:
Fun fact, now it may be the other way around. If the bootloader
doesn't
configure it and the PHY isn't reset by the hardware, it won't work in
the bootloader after a reboo
On Fri, Feb 12, 2021 at 02:21:04PM -0800, Andrii Nakryiko wrote:
> On Fri, Feb 12, 2021 at 2:05 PM Jiri Olsa wrote:
> >
> > Currently when processing DWARF function, we check its entrypoint
> > against ftrace addresses, assuming that the ftrace address matches
> > with function's entrypoint.
> >
>
On Fri, Feb 12, 2021 at 06:23:56PM -0600, Robert Hancock wrote:
> Newer versions of the Xilinx AXI Ethernet core (specifically version 7.2 or
> later) allow the core to be configured with a PHY interface mode of "Both",
Hi Robert
Is it possible to read the version of the core from a register? Is
Currently when processing DWARF function, we check its entrypoint
against ftrace addresses, assuming that the ftrace address matches
with function's entrypoint.
This is not the case on some architectures as reported by Nathan
when building kernel on arm [1].
Fixing the check to take into account
On Fri, 12 Feb 2021 at 20:06, Chris Leech wrote:
>
> On Sun, Feb 07, 2021 at 08:13:13PM +0200, Shai Malin wrote:
> > Queue Initialization:
> > =
> > The nvme-tcp-offload ULP module shall register with the existing
> > nvmf_transport_ops (.name = "tcp_offload"), nvme_ctrl_ops and
On Fri, Feb 12, 2021 at 08:18:40PM -0600, Robert Hancock wrote:
> bcm54xx_config_init was modifying the PHY LED configuration to enable link
> and activity indications. However, some SFP modules (such as Bel-Fuse
> SFP-1GBT-06) have no LEDs but use the LED outputs to control the SFP LOS
> signal, a
Am 2021-02-13 01:36, schrieb Vladimir Oltean:
On Fri, Feb 12, 2021 at 11:40:59PM +0100, Michael Walle wrote:
Am 2021-02-12 18:23, schrieb Vladimir Oltean:
> From: Vladimir Oltean
>
> Currently Linux has no control over whether a MAC-to-PHY interface uses
> in-band signaling or not, even though
> Thanks, but I'm not sure I understand the difference between "rate
> adaption" and symbol repetition. The SGMII link is always 1.25Gb,
> right? If the media side is 100Mbit it will repeat the symbol 10
> times or 100 times in case of 10Mbit. What is "rate adaption" then?
Hi Michael
Some multiG
The usage of in_interrupt() in non-core code is phased out. Ideally the
information of the calling context should be passed by the callers or the
functions be split as appropriate.
The attempt to consolidate the code by passing an arguemnt or by
distangling it failed due lack of knowledge about th
On Sat, Feb 13, 2021 at 05:41:55PM +0100, Michael Walle wrote:
> Am 2021-02-13 01:18, schrieb Russell King - ARM Linux admin:
> > That is a function of the interface mode and the PHY capabilities.
> >
> > 1) if the PHY supports rate adaption, and is programmed for that, then
> >the PHY link no
Am 2021-02-13 17:53, schrieb Michael Walle:
Am 2021-02-13 01:36, schrieb Vladimir Oltean:
But the Atheros PHY seems to have a problem with the SGMII link
if there is no autoneg.
No matter what I do, I can't get any traffic though if its not
gigabit on the copper side. Unfortunately, I don't have
This patchset changes the context of MLD module.
Before this patchset, MLD functions are atomic context so it couldn't use
sleepable functions and flags.
There are several reasons why MLD functions are under atomic context.
1. It uses timer API.
Timer expiration functions are executed in the atomi
mcast.c has several timers for delaying works.
Timer's expire handler is working under atomic context so it can't use
sleepable things such as GFP_KERNEL, mutex, etc.
In order to use sleepable APIs, it converts from timers to delayed work.
But there are some critical sections, which is used by both
In the ifmcaddr6->mca_flags, there are follows flags.
MAF_TIMER_RUNNING
MAF_LAST_REPORTER
MAF_LOADED
MAF_NOREPORT
MAF_GSQUERY
The mca_flags value will be protected by a spinlock since
the next patches. But MAF_LOADED and MAF_NOREPORT do not need
spinlock because they will be protected by RTNL.
So,
The goal of mc_delrec_work delayed work is to call mld_clear_delrec().
The mld_clear_delrec() is called under both data path and control path.
So, the context of mld_clear_delrec() can be atomic.
But this function accesses struct ifmcaddr6 and struct ip6_sf_list.
These structures are going to be pr
The sflist has been protected by rwlock so that the critical section
is atomic context.
In order to switch this context, changing locking is needed.
The sflist actually already protected by RTNL So if it's converted
to use RCU, its control path context can be switched to sleepable.
Suggested-by: C
The purpose of mc_lock is to protect inet6_dev->mc_tomb.
But mc_tomb is already protected by RTNL and all functions,
which manipulate mc_tomb are called under RTNL.
So, mc_lock is not needed.
Furthermore, it is spinlock so the critical section is atomic.
In order to reduce atomic context, it should
The ifmcaddr6 has been protected by inet6_dev->lock(rwlock) so that
the critical section is atomic context. In order to switch this context,
changing locking is needed. The ifmcaddr6 actually already protected by
RTNL So if it's converted to use RCU, its control path context can be
switched to slee
The ip6_sf_list has been protected by mca_lock(spin_lock) so that the
critical section is atomic context. In order to switch this context,
changing locking is needed. The ip6_sf_list actually already protected
by RTNL So if it's converted to use RCU, its control path context can
be switched to slee
On Sat, Feb 13, 2021 at 06:09:13PM +0100, Michael Walle wrote:
> Am 2021-02-13 17:53, schrieb Michael Walle:
> > Am 2021-02-13 01:36, schrieb Vladimir Oltean:
> > But the Atheros PHY seems to have a problem with the SGMII link
> > if there is no autoneg.
> > No matter what I do, I can't get any tra
On 2/8/21 1:42 PM, Petr Machata wrote:
> To illustrate the usage, consider the following commands:
>
> # ip nexthop add id 1 via 192.0.2.2 dev dummy1
> # ip nexthop add id 2 via 192.0.2.3 dev dummy1
> # ip nexthop add id 10 group 1/2 type resilient \
> buckets 8 idle_timer 60 unbalanced_t
On Sat, Feb 13, 2021 at 9:51 AM Taehee Yoo wrote:
> -static void mld_dad_start_timer(struct inet6_dev *idev, unsigned long delay)
> +static void mld_dad_start_work(struct inet6_dev *idev, unsigned long delay)
> {
> unsigned long tv = prandom_u32() % delay;
>
> - if (!mod_timer(&idev
On Sat, Feb 13, 2021 at 5:46 PM Jiri Olsa wrote:
>
> Currently when processing DWARF function, we check its entrypoint
> against ftrace addresses, assuming that the ftrace address matches
> with function's entrypoint.
>
> This is not the case on some architectures as reported by Nathan
> when buil
On Sat, Feb 13, 2021 at 11:57:03AM -0700, David Ahern wrote:
> On 2/8/21 1:42 PM, Petr Machata wrote:
> > To illustrate the usage, consider the following commands:
> >
> > # ip nexthop add id 1 via 192.0.2.2 dev dummy1
> > # ip nexthop add id 2 via 192.0.2.3 dev dummy1
> > # ip nexthop add id 1
On 2/13/21 12:16 PM, Ido Schimmel wrote:
> On Sat, Feb 13, 2021 at 11:57:03AM -0700, David Ahern wrote:
>> On 2/8/21 1:42 PM, Petr Machata wrote:
>>> To illustrate the usage, consider the following commands:
>>>
>>> # ip nexthop add id 1 via 192.0.2.2 dev dummy1
>>> # ip nexthop add id 2 via 192.
On 2/8/21 1:42 PM, Petr Machata wrote:
> @@ -52,8 +53,50 @@ enum {
> NHA_FDB,/* flag; nexthop belongs to a bridge fdb */
> /* if NHA_FDB is added, OIF, BLACKHOLE, ENCAP cannot be set */
>
> + /* nested; resilient nexthop group attributes */
> + NHA_RES_GROUP,
> + /
On Sat, Feb 13, 2021 at 9:52 AM Taehee Yoo wrote:
>
> The goal of mc_delrec_work delayed work is to call mld_clear_delrec().
> The mld_clear_delrec() is called under both data path and control path.
> So, the context of mld_clear_delrec() can be atomic.
> But this function accesses struct ifmcaddr
On 2/8/21 1:42 PM, Petr Machata wrote:
> @@ -212,7 +254,7 @@ static inline bool nexthop_is_multipath(const struct
> nexthop *nh)
> struct nh_group *nh_grp;
>
> nh_grp = rcu_dereference_rtnl(nh->nh_grp);
> - return nh_grp->mpath;
> + return nh_g
On 2/8/21 1:42 PM, Petr Machata wrote:
> diff --git a/net/ipv4/nexthop.c b/net/ipv4/nexthop.c
> index 5d560d381070..4ce282b0a65f 100644
> --- a/net/ipv4/nexthop.c
> +++ b/net/ipv4/nexthop.c> @@ -734,6 +834,22 @@ static struct nexthop
*nexthop_select_path_mp(struct nh_group *nhg, int hash)
> r
Hi Taehee,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Taehee-Yoo/mld-change-context-from-atomic-to-sleepable/20210214-015930
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/ne
On Fri, Feb 12, 2021 at 04:12:20PM +0100, Maxime Chevallier wrote:
> +static void mvneta_setup_rx_prio_map(struct mvneta_port *pp)
> +{
> + int i;
> + u32 val = 0;
Hi Maxime
Reverse Chrismtass tree please.
Andrew
your patches still show up as 8 individual emails.
Did you use 'git send-email --thread --no-chain-reply-to' as Jakub
suggested? Please read the git-send-email man page for what the options do.
Am 2021-02-13 19:56, schrieb Vladimir Oltean:
On Sat, Feb 13, 2021 at 06:09:13PM +0100, Michael Walle wrote:
Am 2021-02-13 17:53, schrieb Michael Walle:
> Am 2021-02-13 01:36, schrieb Vladimir Oltean:
> But the Atheros PHY seems to have a problem with the SGMII link
> if there is no autoneg.
> N
Hi Taehee,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Taehee-Yoo/mld-change-context-from-atomic-to-sleepable/20210214-015930
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/ne
On Sat, Feb 13, 2021 at 08:57:46PM +0100, Michael Walle wrote:
> > On the other hand, I never meant for the inband autoneg setting to only
> > be configurable both ways.
>
> Then why is there a "bool enabled"?
Let me stress the word _only_ both ways. The whole point of the "bool
enabled" is to att
On Sat, Feb 13, 2021 at 12:17:54PM -0700, David Ahern wrote:
> On 2/13/21 12:16 PM, Ido Schimmel wrote:
> > On Sat, Feb 13, 2021 at 11:57:03AM -0700, David Ahern wrote:
> >> On 2/8/21 1:42 PM, Petr Machata wrote:
> >>> To illustrate the usage, consider the following commands:
> >>>
> >>> # ip next
On Sat, Feb 13, 2021 at 08:57:46PM +0100, Michael Walle wrote:
> But then why bother with config_inband_aneg() at all and just enable
> it unconditionally in config_init(). [and maybe keep the return -EINVAL].
> Which then begs the question, does it makes sense on (Q)SGMII links at
> all?
There ar
On Sat, Feb 13, 2021 at 12:16:45PM -0700, David Ahern wrote:
> On 2/8/21 1:42 PM, Petr Machata wrote:
> > @@ -52,8 +53,50 @@ enum {
> > NHA_FDB,/* flag; nexthop belongs to a bridge fdb */
> > /* if NHA_FDB is added, OIF, BLACKHOLE, ENCAP cannot be set */
> >
> > + /* nested; res
On Sat, Feb 13, 2021 at 12:38:47PM -0700, David Ahern wrote:
> On 2/8/21 1:42 PM, Petr Machata wrote:
> > diff --git a/net/ipv4/nexthop.c b/net/ipv4/nexthop.c
> > index 5d560d381070..4ce282b0a65f 100644
> > --- a/net/ipv4/nexthop.c
> > +++ b/net/ipv4/nexthop.c> @@ -734,6 +834,22 @@ static struct ne
On Sat, Feb 13, 2021 at 6:10 AM Alexander Lobakin wrote:
>
> Currently, all sorts of skb allocation always do allocate
> skbuff_heads one by one via kmem_cache_alloc().
> On the other hand, we have percpu napi_alloc_cache to store
> skbuff_heads queued up for freeing and flush them by bulks.
>
> W
From: Vladimir Oltean
This series moves the restriction messages printed by the DSA core, and
by some individual device drivers, into the netlink extended ack
structure, to be communicated to user space where possible, or still
printed to the kernel log from the bridge layer.
Vladimir Oltean (5)
From: Vladimir Oltean
The benefit is the ability to propagate errors from switchdev drivers
for the SWITCHDEV_ATTR_ID_BRIDGE_VLAN_FILTERING and
SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL attributes.
Signed-off-by: Vladimir Oltean
---
include/net/switchdev.h | 3 ++-
net/bridge/br_mrp_switch
From: Vladimir Oltean
Allow drivers to communicate their restrictions to user space directly,
instead of printing to the kernel log. Where the conversion would have
been lossy and things like VLAN ID could no longer be conveyed (due to
the lack of support for printf format specifier in netlink ex
From: Vladimir Oltean
The bridge sysfs interface stores parameters for the STP, VLAN,
multicast etc subsystems using a predefined function prototype.
Sometimes the underlying function being called supports a netlink
extended ack message, and we ignore it.
Let's expand the store_bridge_parm funct
From: Vladimir Oltean
Some drivers can't dynamically change the VLAN filtering option, or
impose some restrictions, it would be nice to propagate this info
through netlink instead of printing it to a kernel log that might never
be read. Also netlink extack includes the module that emitted the
mes
From: Vladimir Oltean
This function is identical with br_vlan_filter_toggle.
Signed-off-by: Vladimir Oltean
---
net/bridge/br_netlink.c | 2 +-
net/bridge/br_private.h | 5 ++---
net/bridge/br_vlan.c| 7 +--
3 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/net/bridge/br_
From: Vladimir Oltean
The sja1105 driver has a limitation, extensively described under
Documentation/networking/dsa/sja1105.rst and
Documentation/networking/devlink/sja1105.rst, which says that when the
ports are under a bridge with vlan_filtering=1, traffic to and from
the network stack is not p
Hi Taehee,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Taehee-Yoo/mld-change-context-from-atomic-to-sleepable/20210214-015930
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/ne
From: Cong Wang
Currently, we compute ->data_end with a compile-time constant
offset of skb. But as Jakub pointed out, we can actually compute
it in eBPF JIT code at run-time, so that we can competely get
rid of ->data_end. This is similar to skb_shinfo(skb) computation
in bpf_convert_shinfo_acce
From: Cong Wang
As suggested by John, clean up sockmap related Kconfigs:
Reduce the scope of CONFIG_BPF_STREAM_PARSER down to TCP stream
parser, to reflect its name.
Make the rest sockmap code simply depend on CONFIG_BPF_SYSCALL.
And leave CONFIG_NET_SOCK_MSG untouched, as it is used by
non-soc
From: Cong Wang
These two eBPF programs are tied to BPF_SK_SKB_STREAM_PARSER
and BPF_SK_SKB_STREAM_VERDICT, rename them to reflect the fact
they are only used for TCP. And save the name 'skb_verdict' for
general use later.
Cc: John Fastabend
Cc: Daniel Borkmann
Cc: Jakub Sitnicki
Reviewed-by:
From: Cong Wang
Currently TCP_SKB_CB() is hard-coded in skmsg code, it certainly
does not work for any other non-TCP protocols. We can move them to
skb ext instead of playing with skb cb, which is harder to make
correct.
Cc: John Fastabend
Cc: Daniel Borkmann
Cc: Jakub Sitnicki
Reviewed-by: L
From: Cong Wang
struct sk_psock_parser is embedded in sk_psock, it is
unnecessary as skb verdict also uses ->saved_data_ready.
We can simply fold these fields into sk_psock, and get rid
of ->enabled.
Cc: John Fastabend
Cc: Daniel Borkmann
Cc: Jakub Sitnicki
Cc: Lorenz Bauer
Signed-off-by: Co
From: Cong Wang
This patchset is the first series of patches separated out from
the original large patchset, to make reviews easier. This patchset
does not add any new feature or change any functionality but merely
cleans up the existing sockmap and skmsg code and refactors it, to
prepare for the
From: Mat Martineau
Date: Fri, 12 Feb 2021 20:46:30 -0800 (PST)
> On Fri, 12 Feb 2021, Mat Martineau wrote:
>
>> This series from the MPTCP tree adds genl multicast events that are
>> important for implementing a userspace path manager. In MPTCP, a path
>> manager is responsible for adding or re
From: Vladimir Oltean
Changes in v2:
Add stub definition for ocelot_port_inject_frame when switch driver is
not compiled in.
This is part two of the errata workaround begun here:
https://patchwork.kernel.org/project/netdevbpf/cover/20210129010009.3959398-1-olte...@gmail.com/
Now that we have ba
From: Vladimir Oltean
Since the xtr (extraction) IRQ of the ocelot switch is not shared, then
if it fired, it means that some data must be present in the queues of
the CPU port module. So simplify the code.
Signed-off-by: Vladimir Oltean
Reviewed-by: Florian Fainelli
---
Changes in v2:
None.
From: Vladimir Oltean
The ocelot_rx_frame_word() function can return a negative error code,
however this isn't being checked for consistently. Errors being ignored
have not been seen in practice though.
Also, some constructs can be simplified by using "goto" instead of
repeated "break" statement
From: Vladimir Oltean
It appears that the intention of this snippet of code is to not exit
ocelot_xtr_irq_handler() while in the middle of extracting a frame.
The problem in extracting it word by word is that future extraction
attempts are really easy to get desynchronized, since the IRQ handler
From: Vladimir Oltean
This looks a bit nicer than the open-coded "(x + 3) % 4" idiom.
Signed-off-by: Vladimir Oltean
---
Changes in v2:
None.
drivers/net/ethernet/mscc/ocelot_net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mscc/ocelot_net.c
b/dr
From: Vladimir Oltean
The felix DSA driver will inject some frames through register MMIO, same
as ocelot switchdev currently does. So we need to be able to reuse the
common code.
Also create some shim definitions, since the DSA tagger can be compiled
without support for the switch driver.
Signe
From: Vladimir Oltean
There is one place where we cannot avoid accessing driver data, and that
is 2-step PTP TX timestamping, since the switch wants us to provide a
timestamp request ID through the injection header, which naturally must
come from a sequence number kept by the driver (it is genera
From: Vladimir Oltean
The Injection Frame Header and Extraction Frame Header that the switch
prepends to frames over the NPI port is also prepended to frames
delivered over the CPU port module's queues.
Let's unify the handling of the frame headers by making the ocelot
driver call some helpers e
From: Vladimir Oltean
For TX timestamping, we use the felix_txtstamp method which is common
with the regular (non-8021q) ocelot tagger. This method says that skb
deferral is needed, prepares a timestamp request ID, and puts a clone of
the skb in a queue waiting for the timestamp IRQ.
felix_txtst
From: Vladimir Oltean
The ocelot tagger is a hot mess currently, it relies on memory
initialized by the attached driver for basic frame transmission.
This is against all that DSA tagging protocols stand for, which is that
the transmission and reception of a DSA-tagged frame, the data path,
should
From: Vladimir Oltean
Taggers should be written to do something valid irrespective of the
switch driver that they are attached to. This is even more true now,
because since the introduction of the .change_tag_protocol method, a
certain tagger is not necessarily strictly associated with a driver a
From: Vladimir Oltean
Since the felix DSA driver will need to poll the CPU port module for
extracted frames as well, let's create some common functions that read
an Extraction Frame Header, and then an skb, from a CPU extraction
group.
We abuse the struct ocelot_ops :: port_to_netdev function a
From: Vladimir Oltean
Since the tag_8021q tagger is software-defined, it has no means by
itself for retrieving hardware timestamps of PTP event messages.
Because we do want to support PTP on ocelot even with tag_8021q, we need
to use the CPU port module for that. The RX timestamp is present in t
Hello:
This series was applied to netdev/net-next.git (refs/heads/master):
On Sat, 13 Feb 2021 14:10:43 + you wrote:
> Currently, all sorts of skb allocation always do allocate
> skbuff_heads one by one via kmem_cache_alloc().
> On the other hand, we have percpu napi_alloc_cache to store
> sk
> Will do. Are you planning to hold off your tests until v3? It shouldn't take
> too
> long.
Sure, we will wait for v3
On 2/9/21 2:12 AM, Amit Cohen wrote:
> The kernel signals when offload fails using the 'RTM_F_OFFLOAD_FAILED'
> flag. Print it to help users understand the offload state of the route.
> The "rt_" prefix is used in order to distinguish it from the offload state
> of nexthops, similar to "rt_offload"
On 2/5/21 11:36 PM, Thayne McCombs wrote:
> The sport and dport conditions in expressions were inconsistent on
> whether there should be a ":" at the beginning of the port when only a
> port was provided depending on the family. The link and netlink
> families required a ":" to work. The vsock fami
The AR8031 has two register sets: Copper and Fiber. The fiber page is
used in case of 100Base-FX and 1000Base-X. But more importantly it is
also used for the SGMII link. Add support to switch between these two.
Signed-off-by: Michael Walle
---
drivers/net/phy/at803x.c | 35 ++
at803x_aneg_done() checks if auto-negotiation is completed on the SGMII
side. This doesn't take the mdio bus lock and the page switching is
open-coded. Now that we have proper page support, just use
phy_read_paged(). Also use phydev->interface to check if we have an
SGMII link instead of reading th
Add paging support to the QCA AR8031/33 PHY. This will be needed if we
add support for the .config_inband_aneg callback, see series [1]. But it
also turns out, that the driver already accessed the fiber page all along
without proper locking. Patch 2 will fix that.
[1] https://lore.kernel.org/netde
1 - 100 of 129 matches
Mail list logo
