On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> From: Tom Rix
>
> This is a upcoming change to clean up a new warning treewide.
> I am wondering if the change could be one mega patch (see below) or
> normal patch per file about 100 patches or somewhere half way by collecting
>
Hello.
I found some kind of "degradation" in a driver for adapter
Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter
Generally, "airodump-ng" utility works with firmware-5.bin but doesn't
work with the latest firmware-6.bin.
https://forum.aircrack-ng.org/index.php/topic,2545.msg13665.html#m
This series adds two new options in the 'iproute2/tipc' command, enabling users
to use the new TIPC encryption features, i.e. the master key and rekeying which
have been recently merged in kernel.
The help menu of the "tipc node set key" command is also updated accordingly:
# tipc node set key --
In addition to the support of master key in kernel, we add the 'master'
option to the 'tipc node set key' command for user to be able to
specify a key as master key during the key setting. This is carried out
by turning on the new netlink flag - 'TIPC_NLA_NODE_KEY_MASTER'.
For example:
$ tipc node
As supported in kernel, the TIPC encryption rekeying can be tuned using
the netlink attribute - 'TIPC_NLA_NODE_REKEYING'. Now we add the
'rekeying' option correspondingly to the 'tipc node set key' command so
that user will be able to perform that tuning:
tipc node set key rekeying REKEYING
where
On 10/17/2020 3:17 PM, Vladimir Oltean wrote:
On Sat, Oct 17, 2020 at 03:11:52PM -0700, Florian Fainelli wrote:
slave_dev->needed_headroom += master->needed_headroom;
slave_dev->needed_tailroom += master->needed_tailroom;
Not positive you need that because you may be account
On Sun, Oct 18, 2020 at 01:15:51AM +0200, Andrew Lunn wrote:
> > +/* Driver statistics, other than those in struct rtnl_link_stats64.
> > + * These are collected per-CPU and aggregated by ethtool.
> > + */
> > +struct dsa_slave_stats {
> > + __u64 tx_reallocs;
> > + struct u64
On Sun, Oct 18, 2020 at 01:31:20AM +0300, Vladimir Oltean wrote:
> On Sun, Oct 18, 2020 at 01:01:04AM +0300, Vladimir Oltean wrote:
> > > + return pskb_expand_head(skb, headroom, tailroom, GFP_ATOMIC);
> > ~
> > err = pskb_expand_h
On Sat, 17 Oct 2020 15:45:57 +0200 Heiner Kallweit wrote:
> When __napi_schedule_irqoff was added with bc9ad166e38a
> ("net: introduce napi_schedule_irqoff()") the commit message stated:
> "Many NIC drivers can use it from their hard IRQ handler instead of
> generic variant."
Eric, do you think it
> +/* Driver statistics, other than those in struct rtnl_link_stats64.
> + * These are collected per-CPU and aggregated by ethtool.
> + */
> +struct dsa_slave_stats {
> + __u64 tx_reallocs;
> + struct u64_stats_sync syncp;
> +} __aligned(1 * sizeof(u64));
The convention
Hi Vladimir
> For example, the tail tagging driver for Marvell 88E6060 currently
> reallocates _every_single_frame_ on TX. Is that an obvious
> indication that nobody is using it?
We have had very few patches for that driver, so i would agree with
you, it is probably not used any more. It could e
On Sun, Oct 18, 2020 at 12:19:25AM +0200, Ard Biesheuvel wrote:
> (cc'ing some folks who may care about functional networking on SynQuacer)
>
> On Sat, 17 Oct 2020 at 21:49, Andrew Lunn wrote:
> >
> > > So we can fix this firmware by just setting phy-mode to the empty
> > > string, right?
> >
> >
On Sun, Oct 18, 2020 at 01:01:04AM +0300, Vladimir Oltean wrote:
> > + return pskb_expand_head(skb, headroom, tailroom, GFP_ATOMIC);
> ~
> err = pskb_expand_head(skb, headroom, tailroom, GFP_ATOMIC);
> if (err < 0 || !p
On Sun, Oct 18, 2020 at 12:36:10AM +0300, Vladimir Oltean wrote:
> diff --git a/net/dsa/tag_gswip.c b/net/dsa/tag_gswip.c
> index 408d4af390a0..cde93ccb21ac 100644
> --- a/net/dsa/tag_gswip.c
> +++ b/net/dsa/tag_gswip.c
> @@ -63,10 +63,6 @@ static struct sk_buff *gswip_tag_xmit(struct sk_buff *skb,
(cc'ing some folks who may care about functional networking on SynQuacer)
On Sat, 17 Oct 2020 at 21:49, Andrew Lunn wrote:
>
> > So we can fix this firmware by just setting phy-mode to the empty
> > string, right?
>
> I've never actually tried it, but i think so. There are no DT files
> actually
On Sat, Oct 17, 2020 at 03:11:52PM -0700, Florian Fainelli wrote:
> > slave_dev->needed_headroom += master->needed_headroom;
> > slave_dev->needed_tailroom += master->needed_tailroom;
>
> Not positive you need that because you may be account for more head or tail
> room than necessary.
>
On 10/17/2020 2:35 PM, Vladimir Oltean wrote:
DSA needs to push a header onto every packet on TX, and this might cause
reallocation under certain scenarios, which might affect, for example,
performance.
But reallocated packets are not standardized in struct pcpu_sw_netstats,
struct net_device
On 10/17/2020 3:01 PM, Vladimir Oltean wrote:
On Sun, Oct 18, 2020 at 12:36:00AM +0300, Vladimir Oltean wrote:
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index d4326940233c..790f5c8deb13 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -548,6 +548,36 @@ netdev_tx_t dsa_enqueue_skb(st
On Sun, Oct 18, 2020 at 12:36:00AM +0300, Vladimir Oltean wrote:
> diff --git a/net/dsa/slave.c b/net/dsa/slave.c
> index d4326940233c..790f5c8deb13 100644
> --- a/net/dsa/slave.c
> +++ b/net/dsa/slave.c
> @@ -548,6 +548,36 @@ netdev_tx_t dsa_enqueue_skb(struct sk_buff *skb, struct
> net_device *d
Now that we have a central TX reallocation procedure that accounts for
the tagger's needed headroom in a generic way, we can remove the
skb_cow_head call.
Similar to the EtherType DSA tagger, the old Marvell tagger can
transform an 802.1Q header if present into a DSA tag, so there is no
headroom r
Now that we have a central TX reallocation procedure that accounts for
the tagger's needed headroom in a generic way, we can remove the
skb_cow_head call.
Signed-off-by: Vladimir Oltean
---
net/dsa/tag_lan9303.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/net/dsa/tag_lan9303.c b/
Now that we have a central TX reallocation procedure that accounts for
the tagger's needed headroom in a generic way, we can remove the
skb_cow_head call.
Cc: Per Forlin
Cc: Oleksij Rempel
Signed-off-by: Vladimir Oltean
---
net/dsa/tag_ar9331.c | 3 ---
1 file changed, 3 deletions(-)
diff --g
Now that we have a central TX reallocation procedure that accounts for
the tagger's needed headroom in a generic way, we can remove the
skb_cow_head call.
This one is interesting, the DSA tag is 8 bytes on RX and 4 bytes on TX.
Because DSA is unaware of asymmetrical tag lengths, the overhead/neede
Now that we have a central TX reallocation procedure that accounts for
the tagger's needed headroom in a generic way, we can remove the
skb_cow_head call.
Cc: Florian Fainelli
Signed-off-by: Vladimir Oltean
---
net/dsa/tag_brcm.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/net/dsa/tag
Now that we have a central TX reallocation procedure that accounts for
the tagger's needed headroom in a generic way, we can remove the
skb_cow_head call.
Note that the VLAN code path needs a smaller extra headroom than the
regular EtherType DSA path. That isn't a problem, because this tagger
decl
Now that we have a central TX reallocation procedure that accounts for
the tagger's needed headroom in a generic way, we can remove the
skb_cow_head call.
Cc: DENG Qingfang
Cc: Sean Wang
Cc: John Crispin
Signed-off-by: Vladimir Oltean
---
net/dsa/tag_mtk.c | 3 ---
1 file changed, 3 deletions
Now that we have a central TX reallocation procedure that accounts for
the tagger's needed headroom in a generic way, we can remove the
skb_cow_head call.
Signed-off-by: Vladimir Oltean
---
net/dsa/tag_ocelot.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/net/dsa/tag_ocelot.c b/net/
DSA needs to push a header onto every packet on TX, and this might cause
reallocation under certain scenarios, which might affect, for example,
performance.
But reallocated packets are not standardized in struct pcpu_sw_netstats,
struct net_device_stats or anywhere else, it seems, so we need to ro
From: Christian Eggers
The caller (dsa_slave_xmit) guarantees that the frame length is at least
ETH_ZLEN and that enough memory for tail tagging is available.
Signed-off-by: Christian Eggers
Signed-off-by: Vladimir Oltean
---
net/dsa/tag_ksz.c | 73 ++--
From: Christian Eggers
The caller (dsa_slave_xmit) guarantees that the frame length is at least
ETH_ZLEN and that enough memory for tail tagging is available.
Signed-off-by: Christian Eggers
Signed-off-by: Vladimir Oltean
---
net/dsa/tag_trailer.c | 31 ++-
1 file
Now that we have a central TX reallocation procedure that accounts for
the tagger's needed headroom in a generic way, we can remove the
skb_cow_head call.
Cc: John Crispin
Cc: Alexander Lobakin
Signed-off-by: Vladimir Oltean
---
net/dsa/tag_qca.c | 3 ---
1 file changed, 3 deletions(-)
diff -
At the moment, taggers are left with the task of ensuring that the skb
headers are writable (which they aren't, if the frames were cloned for
TX timestamping, for flooding by the bridge, etc), and that there is
enough space in the skb data area for the DSA tag to be pushed.
Moreover, the life of t
Christian has reported buggy usage of skb_put() in tag_ksz.c, which is
only triggerable in real life using his not-yet-published patches for
IEEE 1588 timestamping on Micrel KSZ switches.
The concrete problem there is that the driver can end up calling
skb_put() and exceed the end of the skb data
On Sat, Oct 17, 2020 at 10:56:24PM +0200, Christian Eggers wrote:
> The status page seems to be out of date:
> http://vger.kernel.org/~davem/net-next.html
Yeah, it can do that sometimes. Extremely rarely, but it happens. But
net-next is still closed, nonetheless.
> The FAQ says: "Do not send new
> diff --git a/drivers/staging/octeon/ethernet-rx.c
> b/drivers/staging/octeon/ethernet-rx.c
> index 2c16230..9ebd665 100644
> --- a/drivers/staging/octeon/ethernet-rx.c
> +++ b/drivers/staging/octeon/ethernet-rx.c
> @@ -69,15 +69,17 @@ static inline int cvm_oct_check_rcv_error(struct cvmx_wqe
>
On Sat, Oct 17, 2020 at 9:10 AM wrote:
>
> From: Tom Rix
>
> This is a upcoming change to clean up a new warning treewide.
> I am wondering if the change could be one mega patch (see below) or
> normal patch per file about 100 patches or somewhere half way by collecting
> early acks.
>
> clang ha
On Saturday, 17 October 2020, 21:12:47 CEST, Vladimir Oltean wrote:
> On Sat, Oct 17, 2020 at 08:53:19PM +0200, Christian Eggers wrote:
> > > Does 1588 work for you using this change, or you haven't finished
> > > implementing it yet? If you haven't, I would suggest finishing that
> > > part first.
> --- a/drivers/staging/octeon/ethernet.c
> +++ b/drivers/staging/octeon/ethernet.c
> @@ -13,6 +13,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -892,6 +893,14 @@ static int cvm_oct_probe(struct platform_device *pdev)
>
> + if (priv->of_node &&
> of_phy_is_fixed_link(priv->of_node)) {
> + if (of_phy_register_fixed_link(priv->of_node)) {
> + netdev_err(dev, "Failed to register
> fixed link for interface %d, port %d\n",
> +
> - err = mdiobus_register(priv->mii_bus);
> + mdio_np = of_get_child_by_name(np, "mdio");
> + if (mdio_np)
> + err = of_mdiobus_register(priv->mii_bus, mdio_np);
> + else
> + err = mdiobus_register(priv->mii_bus);
of_mdiobus_register() will do the right thi
On Thu, Oct 15, 2020 at 03:49:16PM +0300, Ivan Mikhaylov wrote:
> Split MDIO registration and PHY connect into ftgmac100_setup_mdio and
> ftgmac100_mii_probe.
>
> Signed-off-by: Ivan Mikhaylov
> ---
> drivers/net/ethernet/faraday/ftgmac100.c | 92
> 1 file changed, 47 in
On Sat, Oct 17 2020 at 16:15, Alex Belits wrote:
> On Sat, 2020-10-17 at 18:08 +0200, Thomas Gleixner wrote:
>> On Sat, Oct 17 2020 at 01:08, Alex Belits wrote:
>> > I think that the goal of "finding source of disturbance" interface
>> > is
>> > different from what can be accomplished by tracing in
> So we can fix this firmware by just setting phy-mode to the empty
> string, right?
I've never actually tried it, but i think so. There are no DT files
actually doing that, so you really do need to test it and see. And
there might be some differences between device_get_phy_mode() and
of_get_phy_m
Hello!
On 10/1/20 10:13 AM, Andrew Gabbasov wrote:
The patch was set to the "Changes Requested" state -- most probably because
of this
mail. Though unintentionally, it served to throttle actions on this patch. I
did only
remember about this patch yesterday... :-)
[...]
>> In the function ra
> +static void mv88e6393x_phylink_validate(struct mv88e6xxx_chip *chip, int
> port,
> + unsigned long *mask,
> + struct phylink_link_state *state)
> +{
> + if (port == 0 || port >= 9) {
> + phylink_set(mask, 10
On 16.10.20 21:36, Marc Kleine-Budde wrote:
On 2/14/20 1:09 PM, Oleksij Rempel wrote:
Hi all,
any comments on this patch?
I'm going to take this patch now for 5.10Comments?
Yes.
Removing the sk reference will lead to the effect, that you will receive
the CAN frames you have sent on
On Sat, Oct 17, 2020 at 08:53:19PM +0200, Christian Eggers wrote:
> > Does 1588 work for you using this change, or you haven't finished
> > implementing it yet? If you haven't, I would suggest finishing that
> > part first.
> Yes it does. Just after finishing this topic, I would to sent the patches
I've managed to reproduce the issue, or at least a related issue. Can
you try the draft patch below and see if that fixes it?
[PATCH] mac80211: fix regression where EAPOL frames were sent in plaintext
When sending EAPOL frames via NL80211 they are treated as injected
frames in mac80211. Due to co
On Sat, 2020-10-17 at 20:21 +0200, Julia Lawall wrote:
> On Sat, 17 Oct 2020, Joe Perches wrote:
> > On Sat, 2020-10-17 at 09:09 -0700, t...@redhat.com wrote:
> > > From: Tom Rix
> > >
> > > This is a upcoming change to clean up a new warning treewide.
> > > I am wondering if the change could be
On Sat, 17 Oct 2020 at 20:27, Andrew Lunn wrote:
>
> On Sat, Oct 17, 2020 at 08:11:24PM +0200, Ard Biesheuvel wrote:
> > On Sat, 17 Oct 2020 at 20:04, Andrew Lunn wrote:
> > >
> > > > I have tried this, and it seems to fix the issue. I will send out a
> > > > patch against the netsec driver.
> >
Hi Vladimir,
On Saturday, 17 October 2020, 02:48:16 CEST, Vladimir Oltean wrote:
> On Fri, Oct 16, 2020 at 10:02:24PM +0200, Christian Eggers wrote:
> > Ensure that the skb is not cloned and has enough tail room for the tail
> > tag. This code will be removed from the drivers in the next commits.
Extend the 'bridge mdb' command for the following syntax:
bridge mdb add dev br0 port swp0 grp 01:02:03:04:05:06 permanent
Signed-off-by: Vladimir Oltean
---
bridge/mdb.c | 54 ++
include/uapi/linux/if_bridge.h | 2 ++
2 files changed, 43 insert
From: Nikolay Aleksandrov
Extend the bridge multicast control and data path to configure routes
for L2 (non-IP) multicast groups.
The uapi struct br_mdb_entry union u is extended with another variant,
interpretation, mac_addr, which does not change the structure size, and
which is valid when the
- Original Message -
> From: "Jakub Kicinski"
> To: "Eelco Chaudron"
> Cc: netdev@vger.kernel.org, da...@davemloft.net, d...@openvswitch.org,
> pab...@redhat.com, pshe...@ovn.org,
> jle...@redhat.com, bige...@linutronix.de, "i maximets"
> Sent: Saturday, October 17, 2020 1:46:07 AM
>
On Sat, Oct 17, 2020 at 08:11:24PM +0200, Ard Biesheuvel wrote:
> On Sat, 17 Oct 2020 at 20:04, Andrew Lunn wrote:
> >
> > > I have tried this, and it seems to fix the issue. I will send out a
> > > patch against the netsec driver.
> >
> > Please also fix the firmware so it does not pass rgmii.
>
The flow_lookup() function uses per CPU variables, which must be called
with BH disabled. However, this is fine in the general NAPI use case
where the local BH is disabled. But, it's also called from the netlink
context. The below patch makes sure that even in the netlink path, the
BH is disabled.
On Sat, 17 Oct 2020, Joe Perches wrote:
> On Sat, 2020-10-17 at 09:09 -0700, t...@redhat.com wrote:
> > From: Tom Rix
> >
> > This is a upcoming change to clean up a new warning treewide.
> > I am wondering if the change could be one mega patch (see below) or
> > normal patch per file about 10
On Sat, 17 Oct 2020 at 20:11, Ard Biesheuvel wrote:
>
> On Sat, 17 Oct 2020 at 20:04, Andrew Lunn wrote:
> >
> > > I have tried this, and it seems to fix the issue. I will send out a
> > > patch against the netsec driver.
> >
> > Please also fix the firmware so it does not pass rgmii.
> >
> > If
On Sat, 17 Oct 2020 at 20:04, Andrew Lunn wrote:
>
> > I have tried this, and it seems to fix the issue. I will send out a
> > patch against the netsec driver.
>
> Please also fix the firmware so it does not pass rgmii.
>
> If there are pure DT systems, which do require phy-mode to be used, we
> w
> I have tried this, and it seems to fix the issue. I will send out a
> patch against the netsec driver.
Please also fix the firmware so it does not pass rgmii.
If there are pure DT systems, which do require phy-mode to be used, we
will need to revert your proposed change in order to make the MAC
> Would EDK2 take care of the RGMII Rx/Tx delays even when configured to
> use a DT instead of ACPI?
But what about those users using u-boot and DT, not EDK2?
Andrew
On Sat, 2020-10-17 at 09:09 -0700, t...@redhat.com wrote:
> From: Tom Rix
>
> This is a upcoming change to clean up a new warning treewide.
> I am wondering if the change could be one mega patch (see below) or
> normal patch per file about 100 patches or somewhere half way by collecting
> early a
Hi Ard,
[...]
> > > > You can also use '' as the phy-mode, which results in
> > > > PHY_INTERFACE_MODE_NA, which effectively means, don't touch the PHY
> > > > mode, something else has already set it up. This might actually be the
> > > > correct way to go for ACPI. In the DT world, we tend to ass
On Sat, 17 Oct 2020 at 18:14, Ilias Apalodimas
wrote:
>
> Hi Ard,
>
> On Sat, Oct 17, 2020 at 05:18:16PM +0200, Ard Biesheuvel wrote:
> > On Sat, 17 Oct 2020 at 17:11, Andrew Lunn wrote:
> > >
> > > On Sat, Oct 17, 2020 at 04:46:23PM +0200, Ard Biesheuvel wrote:
> > > > On Sat, 17 Oct 2020 at 16:
On Sat, 2020-10-17 at 18:08 +0200, Thomas Gleixner wrote:
> On Sat, Oct 17 2020 at 01:08, Alex Belits wrote:
> > On Mon, 2020-10-05 at 14:52 -0400, Nitesh Narayan Lal wrote:
> > > On 10/4/20 7:14 PM, Frederic Weisbecker wrote:
> > I think that the goal of "finding source of disturbance" interface
Hi Ard,
On Sat, Oct 17, 2020 at 05:18:16PM +0200, Ard Biesheuvel wrote:
> On Sat, 17 Oct 2020 at 17:11, Andrew Lunn wrote:
> >
> > On Sat, Oct 17, 2020 at 04:46:23PM +0200, Ard Biesheuvel wrote:
> > > On Sat, 17 Oct 2020 at 16:44, Andrew Lunn wrote:
> > > >
> > > > On Sat, Oct 17, 2020 at 04:20
From: Tom Rix
This is a upcoming change to clean up a new warning treewide.
I am wondering if the change could be one mega patch (see below) or
normal patch per file about 100 patches or somewhere half way by collecting
early acks.
clang has a number of useful, new warnings see
https://clang.llv
On Sat, Oct 17 2020 at 01:08, Alex Belits wrote:
> On Mon, 2020-10-05 at 14:52 -0400, Nitesh Narayan Lal wrote:
>> On 10/4/20 7:14 PM, Frederic Weisbecker wrote:
> I think that the goal of "finding source of disturbance" interface is
> different from what can be accomplished by tracing in two ways:
On Fri, Oct 16, 2020 at 09:56:22AM -0700, Florian Fainelli wrote:
> I probably missed parts of this long discussion, but for this generation
> of switches, does that mean that you will only allow a bridge with
> vlan_filtering=1 to be configured and also refuse toggling of
> vlan_filtering at run t
On 10/14/20 4:31 PM, Jacob Keller wrote:
> For some devices, updating the flash can take significant time during
> operations where no status can meaningfully be reported. This can be
> somewhat confusing to a user who sees devlink appear to hang on the
> terminal waiting for the device to update.
On 10/13/20 8:32 AM, Guillaume Nault wrote:
> @@ -41,12 +44,12 @@ static void usage(void)
>
> static bool can_modify_mpls_fields(unsigned int action)
> {
> - return action == TCA_MPLS_ACT_PUSH || action == TCA_MPLS_ACT_MODIFY;
> + return action == TCA_MPLS_ACT_PUSH || action == TCA_MPLS
On Sat, 17 Oct 2020 at 17:11, Andrew Lunn wrote:
>
> On Sat, Oct 17, 2020 at 04:46:23PM +0200, Ard Biesheuvel wrote:
> > On Sat, 17 Oct 2020 at 16:44, Andrew Lunn wrote:
> > >
> > > On Sat, Oct 17, 2020 at 04:20:36PM +0200, Ard Biesheuvel wrote:
> > > > Hello all,
> > > >
> > > > I just upgraded
On Sat, Oct 17, 2020 at 04:46:23PM +0200, Ard Biesheuvel wrote:
> On Sat, 17 Oct 2020 at 16:44, Andrew Lunn wrote:
> >
> > On Sat, Oct 17, 2020 at 04:20:36PM +0200, Ard Biesheuvel wrote:
> > > Hello all,
> > >
> > > I just upgraded my arm64 SynQuacer box to 5.8.16 and lost all network
> > > connec
On Sat, Oct 17, 2020 at 02:48:56PM +0200, Arnd Bergmann wrote:
> On Fri, Oct 16, 2020 at 4:12 PM Andrew Lunn wrote:
> >
> > > One drawback of your approach is that
> > > you cannot set KBUILD_CFLAGS_W1_20200930
> > > until you eliminate all the warnings in the
> > > sub-directory in interest.
> >
On Sat, 17 Oct 2020 at 16:44, Andrew Lunn wrote:
>
> On Sat, Oct 17, 2020 at 04:20:36PM +0200, Ard Biesheuvel wrote:
> > Hello all,
> >
> > I just upgraded my arm64 SynQuacer box to 5.8.16 and lost all network
> > connectivity.
>
> Hi Ard
>
> Please could you point me at the DT files.
>
> > This b
On Sat, Oct 17, 2020 at 04:20:36PM +0200, Ard Biesheuvel wrote:
> Hello all,
>
> I just upgraded my arm64 SynQuacer box to 5.8.16 and lost all network
> connectivity.
Hi Ard
Please could you point me at the DT files.
> This box has a on-SoC socionext 'netsec' network controller wired to
> a Rea
Hello all,
I just upgraded my arm64 SynQuacer box to 5.8.16 and lost all network
connectivity. This box has a on-SoC socionext 'netsec' network
controller wired to a Realtek 80211e PHY, and this was working without
problems until the following commit was merged
commit bbc4d71d63549bcd003a430de18a
When __napi_schedule_irqoff was added with bc9ad166e38a
("net: introduce napi_schedule_irqoff()") the commit message stated:
"Many NIC drivers can use it from their hard IRQ handler instead of
generic variant."
It turned out that this most of the time isn't safe in certain
configurations:
- if CONF
Introduced in 0eeb075fad73, the "ignore_routes_with_linkdown" sysctl
ignores a route whose interface is down. It is provided as a
per-interface sysctl. However, while a "all" variant is exposed, it
was a noop since it was never evaluated. We use the usual "or" logic
for this kind of sysctls.
Teste
On Fri, Oct 16, 2020 at 10:02:38AM +0800, zhudi wrote:
> "ip addr show" command execute error when we have a physical
> network card with number of VFs larger than 247.
>
> The return value of if_nlmsg_size() in rtnl_calcit() will exceed
> range of u16 data type when any network cards has a larger
On 2020-10-16 12:42 p.m., Vlad Buslov wrote:
All action print callbacks have arg==NULL check and return at the
beginning. To print action type we need either to have dedicated
'brief_dump' callback instead of reusing print_aop() or extend/refactor
print_aop() implementation for all actions to a
Hi!
> +static int idt82p33_adjwritephase(struct ptp_clock_info *ptp, s32
> +offsetNs) {
adj_write_phase?
> + struct idt82p33_channel *channel =
> + container_of(ptp, struct idt82p33_channel, caps);
> + struct idt82p33 *idt82p33 = channel->idt82p33;
> + s64 offsetInFs;
>
On Fri Oct 16 2020, Florian Fainelli wrote:
> I probably missed parts of this long discussion, but for this generation
> of switches, does that mean that you will only allow a bridge with
> vlan_filtering=1 to be configured and also refuse toggling of
> vlan_filtering at run time?
Nope. To sum up
On Fri, 2020-10-16 at 20:29 +0300, Ido Schimmel wrote:
> From: Ido Schimmel
>
> While insertion of 16k nexthops all using the same netdev ('dummy10')
> takes less than a second, deletion takes about 130 seconds:
>
> # time -p ip -b nexthop.batch
> real 0.29
> user 0.01
> sys 0.15
>
> # time -p
Hi Loic,
On 10/16/20 2:20 AM, Loic Poulain wrote:
This patch adds a new network driver implementing MHI transport for
network packets. Packets can be in any format, though QMAP (rmnet)
is the usual protocol (flow control + PDN mux).
It support two MHI devices, IP_HW0 which is, the path to the I
From: Sven Auhagen
The igb XDP xmit back function should only return
defined error codes.
Signed-off-by: Sven Auhagen
---
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
b/drivers/net/ether
From: Sven Auhagen
add metasize if it is set in xdp
Signed-off-by: Sven Auhagen
Suggested-by: Maciej Fijalkowski
Reviewed-by: Maciej Fijalkowski
---
drivers/net/ethernet/intel/igb/igb_main.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
b/
From: Sven Auhagen
This patch series addresses some of the comments that came back
after the igb XDP patch was accepted.
Most of it is code cleanup.
The last patch contains a fix for a tx queue timeout
that can occur when using xdp.
Signed-off-by: Sven Auhagen
Change from v1:
* Drop patch
From: Sven Auhagen
Since it is a new XDP implementation change xdp_do_flush_map
to xdp_do_flush.
Signed-off-by: Sven Auhagen
Suggested-by: Maciej Fijalkowski
Reviewed-by: Maciej Fijalkowski
---
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
From: Sven Auhagen
Increase the packet header padding to include double VLAN tagging.
This patch uses a macro for this.
Signed-off-by: Sven Auhagen
Suggested-by: Maciej Fijalkowski
---
drivers/net/ethernet/intel/igb/igb.h | 5 +
drivers/net/ethernet/intel/igb/igb_main.c | 7 +++
From: Sven Auhagen
Add an extack error message when the RX buffer size is too small
for the frame size.
Signed-off-by: Sven Auhagen
Suggested-by: Maciej Fijalkowski
Reviewed-by: Maciej Fijalkowski
---
drivers/net/ethernet/intel/igb/igb_main.c | 12 +++-
1 file changed, 7 insertions(+
From: Sven Auhagen
Since we share the transmit queue with the slow path,
it is possible that we run into a transmit queue timeout.
This will reset the queue.
This happens under high load when the fast path is using the
transmit queue pretty much exclusively.
By setting the transmit queues trans_
92 matches
Mail list logo
