* Re: [PATCH net-next v4 3/3] net: dsa: enable flooding for bridge ports
From: Florian Fainelli @ 2019-02-20 21:51 UTC (permalink / raw)
To: Russell King, Andrew Lunn, Vivien Didelot
Cc: Heiner Kallweit, David S. Miller, netdev
In-Reply-To: <E1gwYuS-0001b7-L7@rmk-PC.armlinux.org.uk>
On 2/20/19 12:56 PM, Russell King wrote:
> Switches work by learning the MAC address for each attached station by
> monitoring traffic from each station. When a station sends a packet,
> the switch records which port the MAC address is connected to.
>
> With IPv4 networking, before communication commences with a neighbour,
> an ARP packet is broadcasted to all stations asking for the MAC address
> corresponding with the IPv4. The desired station responds with an ARP
> reply, and the ARP reply causes the switch to learn which port the
> station is connected to.
>
> With IPv6 networking, the situation is rather different. Rather than
> broadcasting ARP packets, a "neighbour solicitation" is multicasted
> rather than broadcasted. This multicast needs to reach the intended
> station in order for the neighbour to be discovered.
>
> Once a neighbour has been discovered, and entered into the sending
> stations neighbour cache, communication can restart at a point later
> without sending a new neighbour solicitation, even if the entry in
> the neighbour cache is marked as stale. This can be after the MAC
> address has expired from the forwarding cache of the DSA switch -
> when that occurs, there is a long pause in communication.
>
> Our DSA implementation for mv88e6xxx switches disables flooding of
> multicast and unicast frames for bridged ports. As per the above
> description, this is fine for IPv4 networking, since the broadcasted
> ARP queries will be sent to and received by all stations on the same
> network. However, this breaks IPv6 very badly - blocking neighbour
> solicitations and later causing connections to stall.
>
> The defaults that the Linux bridge code expect from bridges are for
> unknown unicast and unknown multicast frames to be flooded to all ports
> on the bridge, which is at odds to the defaults adopted by our DSA
> implementation for mv88e6xxx switches.
>
> This commit enables by default flooding of both unknown unicast and
> unknown multicast frames whenever a port is added to a bridge, and
> disables the flooding when a port leaves the bridge. This means that
> mv88e6xxx DSA switches now behave as per the bridge(8) man page, and
> IPv6 works flawlessly through such a switch.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH net-next v4 2/3] net: dsa: mv88e6xxx: add support for bridge flags
From: Florian Fainelli @ 2019-02-20 21:51 UTC (permalink / raw)
To: Russell King, Andrew Lunn, Vivien Didelot
Cc: Heiner Kallweit, David S. Miller, netdev
In-Reply-To: <E1gwYuN-0001as-7s@rmk-PC.armlinux.org.uk>
On 2/20/19 12:55 PM, Russell King wrote:
> Add support for the bridge flags to Marvell 88e6xxx bridges, allowing
> the multicast and unicast flood properties to be controlled. These
> can be controlled on a per-port basis via commands such as:
>
> bridge link set dev lan1 flood on|off
> bridge link set dev lan1 mcast_flood on|off
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH net-next v4 1/3] net: dsa: add support for bridge flags
From: Florian Fainelli @ 2019-02-20 21:46 UTC (permalink / raw)
To: Russell King, Andrew Lunn, Vivien Didelot
Cc: Heiner Kallweit, David S. Miller, netdev
In-Reply-To: <E1gwYuI-0001aX-2u@rmk-PC.armlinux.org.uk>
On 2/20/19 12:55 PM, Russell King wrote:
> The Linux bridge implementation allows various properties of the bridge
> to be controlled, such as flooding unknown unicast and multicast frames.
> This patch adds the necessary DSA infrastructure to allow the Linux
> bridge support to control these properties for DSA switches.
>
> Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* [PATCH net] net: socket: add check for negative optlen in compat setsockopt
From: Jann Horn @ 2019-02-20 21:34 UTC (permalink / raw)
To: David S. Miller, jannh; +Cc: netdev, linux-kernel
__sys_setsockopt() already checks for `optlen < 0`. Add an equivalent check
to the compat path for robustness. This has to be `> INT_MAX` instead of
`< 0` because the signedness of `optlen` is different here.
Signed-off-by: Jann Horn <jannh@google.com>
---
net/compat.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/compat.c b/net/compat.c
index 959d1c51826d..3d348198004f 100644
--- a/net/compat.c
+++ b/net/compat.c
@@ -388,8 +388,12 @@ static int __compat_sys_setsockopt(int fd, int level, int optname,
char __user *optval, unsigned int optlen)
{
int err;
- struct socket *sock = sockfd_lookup(fd, &err);
+ struct socket *sock;
+
+ if (optlen > INT_MAX)
+ return -EINVAL;
+ sock = sockfd_lookup(fd, &err);
if (sock) {
err = security_socket_setsockopt(sock, level, optname);
if (err) {
--
2.21.0.rc0.258.g878e2cd30e-goog
^ permalink raw reply related
* Re: bug report: iwlwifi: mvm: support mac80211 TXQs model
From: Johannes Berg @ 2019-02-20 21:12 UTC (permalink / raw)
To: Colin Ian King, Sara Sharon, Emmanuel Grumbach, Luca Coelho,
Intel Linux Wireless, linux-wireless@vger.kernel.org, netdev
Cc: Kalle Valo, David S. Miller, linux-kernel@vger.kernel.org
In-Reply-To: <427786ae-159a-a7d1-2334-46656d3f2b51@canonical.com>
On Wed, 2019-02-20 at 14:40 +0000, Colin Ian King wrote:
>
> ..when the used_hw_queues initialization was removed:
>
> @@ -360,8 +300,6 @@ int iwl_mvm_mac_ctxt_init(struct iwl_mvm *mvm,
> struct ieee80211_vif *vif)
> mvm->hw, IEEE80211_IFACE_ITER_RESUME_ALL,
> iwl_mvm_mac_iface_iterator, &data);
>
> - used_hw_queues = iwl_mvm_get_used_hw_queues(mvm, vif);
> -
> /*
> * In the case we're getting here during resume, it's similar to
> * firmware restart, and with RESUME_ALL the iterator will find
>
>
> I'm not 100% sure if the right thing to do is just to now initialize
> used_hw_queues to zero; it's not entirely clear what the initial value
> should be now.
My gut feeling says that we should just remove all of the code - we no
longer use the vif->hw_queue stuff. Which also explains why we didn't
notice any problems from this :)
Something like
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
index aa308f7e7989..f90383943c62 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
@@ -263,8 +263,7 @@ int iwl_mvm_mac_ctxt_init(struct iwl_mvm *mvm, struct ieee80211_vif *vif)
.found_vif = false,
};
u32 ac;
- int ret, i, queue_limit;
- unsigned long used_hw_queues;
+ int ret, i;
lockdep_assert_held(&mvm->mutex);
@@ -341,38 +340,9 @@ int iwl_mvm_mac_ctxt_init(struct iwl_mvm *mvm, struct ieee80211_vif *vif)
INIT_LIST_HEAD(&mvmvif->time_event_data.list);
mvmvif->time_event_data.id = TE_MAX;
- /* No need to allocate data queues to P2P Device MAC and NAN.*/
if (vif->type == NL80211_IFTYPE_P2P_DEVICE ||
- vif->type == NL80211_IFTYPE_NAN) {
- for (ac = 0; ac < IEEE80211_NUM_ACS; ac++)
- vif->hw_queue[ac] = IEEE80211_INVAL_HW_QUEUE;
-
+ vif->type == NL80211_IFTYPE_NAN)
return 0;
- }
-
- /*
- * queues in mac80211 almost entirely independent of
- * the ones here - no real limit
- */
- queue_limit = IEEE80211_MAX_QUEUES;
-
- /*
- * Find available queues, and allocate them to the ACs. When in
- * DQA-mode they aren't really used, and this is done only so the
- * mac80211 ieee80211_check_queues() function won't fail
- */
- for (ac = 0; ac < IEEE80211_NUM_ACS; ac++) {
- u8 queue = find_first_zero_bit(&used_hw_queues, queue_limit);
-
- if (queue >= queue_limit) {
- IWL_ERR(mvm, "Failed to allocate queue\n");
- ret = -EIO;
- goto exit_fail;
- }
-
- __set_bit(queue, &used_hw_queues);
- vif->hw_queue[ac] = queue;
- }
/* Allocate the CAB queue for softAP and GO interfaces */
if (vif->type == NL80211_IFTYPE_AP ||
I'll think about it a bit more and test it out, thanks for the report!
johannes
^ permalink raw reply related
* Re: [PATCH 6/6] net: ethernet: ti: cpsw: deprecate cpsw-phy-sel driver
From: Tony Lindgren @ 2019-02-20 21:01 UTC (permalink / raw)
To: David Miller
Cc: grygorii.strashko, kishon, robh+dt, netdev, nsekhar, linux-kernel,
linux-omap, devicetree, linux-arm-kernel
In-Reply-To: <20190220.124155.2226787912266109280.davem@davemloft.net>
* David Miller <davem@davemloft.net> [190220 20:42]:
> From: Tony Lindgren <tony@atomide.com>
> Date: Wed, 20 Feb 2019 12:33:26 -0800
>
> > * David Miller <davem@davemloft.net> [190220 19:23]:
> >> From: Grygorii Strashko <grygorii.strashko@ti.com>
> >> Date: Wed, 20 Feb 2019 17:25:19 +0200
> >>
> >> > Deprecate cpsw-phy-sel driver as it's been replaced with new
> >> > TI phy-gmii-sel PHY driver.
> >> >
> >> > Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> >>
> >> Acked-by: David S. Miller <davem@davemloft.net>
> >
> > Thanks for the ack, but actually I'd prefer you to pick
> > this patch at some future date. I suggest Grygorii just
> > repost this one after v5.1-rc1.
>
> It's so much easier if you group this with those DT changes, they
> logically belong together as well and it helps someone reading
> the changes in the tree also if they are side by side.
I agree that a group of patches should go together in
most cases.
> Why don't you want to integrate this with them?
Because the arm-soc tree wants dts changes separately in
general. The dts changes are considered firmware describing
hardware. And it makes it possible to split the arm-soc pile
of patches into multiple pull requests. In theory there
should be no dependency between dts changes and driver
changes, but in reality that's not always the case :)
What I can do is set up a separate branch with just this
patch on top of the dts changes that the arm-soc guys can
then merge towards the end of the merge cycle. If that
works for you, let me know and I'll do it.
Regards,
Tony
^ permalink raw reply
* [PATCH net-next v4 3/3] net: dsa: enable flooding for bridge ports
From: Russell King @ 2019-02-20 20:56 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Vivien Didelot
Cc: Heiner Kallweit, David S. Miller, netdev
In-Reply-To: <20190220205525.nji63ntsthxbus4l@shell.armlinux.org.uk>
Switches work by learning the MAC address for each attached station by
monitoring traffic from each station. When a station sends a packet,
the switch records which port the MAC address is connected to.
With IPv4 networking, before communication commences with a neighbour,
an ARP packet is broadcasted to all stations asking for the MAC address
corresponding with the IPv4. The desired station responds with an ARP
reply, and the ARP reply causes the switch to learn which port the
station is connected to.
With IPv6 networking, the situation is rather different. Rather than
broadcasting ARP packets, a "neighbour solicitation" is multicasted
rather than broadcasted. This multicast needs to reach the intended
station in order for the neighbour to be discovered.
Once a neighbour has been discovered, and entered into the sending
stations neighbour cache, communication can restart at a point later
without sending a new neighbour solicitation, even if the entry in
the neighbour cache is marked as stale. This can be after the MAC
address has expired from the forwarding cache of the DSA switch -
when that occurs, there is a long pause in communication.
Our DSA implementation for mv88e6xxx switches disables flooding of
multicast and unicast frames for bridged ports. As per the above
description, this is fine for IPv4 networking, since the broadcasted
ARP queries will be sent to and received by all stations on the same
network. However, this breaks IPv6 very badly - blocking neighbour
solicitations and later causing connections to stall.
The defaults that the Linux bridge code expect from bridges are for
unknown unicast and unknown multicast frames to be flooded to all ports
on the bridge, which is at odds to the defaults adopted by our DSA
implementation for mv88e6xxx switches.
This commit enables by default flooding of both unknown unicast and
unknown multicast frames whenever a port is added to a bridge, and
disables the flooding when a port leaves the bridge. This means that
mv88e6xxx DSA switches now behave as per the bridge(8) man page, and
IPv6 works flawlessly through such a switch.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
net/dsa/port.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/net/dsa/port.c b/net/dsa/port.c
index 6df29bddf37e..7bc2a5ad95c6 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -105,16 +105,23 @@ int dsa_port_bridge_join(struct dsa_port *dp, struct net_device *br)
};
int err;
- /* Here the port is already bridged. Reflect the current configuration
- * so that drivers can program their chips accordingly.
+ /* Set the flooding mode before joining the port in the switch */
+ err = dsa_port_bridge_flags(dp, BR_FLOOD | BR_MCAST_FLOOD, NULL);
+ if (err)
+ return err;
+
+ /* Here the interface is already bridged. Reflect the current
+ * configuration so that drivers can program their chips accordingly.
*/
dp->bridge_dev = br;
err = dsa_port_notify(dp, DSA_NOTIFIER_BRIDGE_JOIN, &info);
/* The bridging is rolled back on error */
- if (err)
+ if (err) {
+ dsa_port_bridge_flags(dp, 0, NULL);
dp->bridge_dev = NULL;
+ }
return err;
}
@@ -137,6 +144,9 @@ void dsa_port_bridge_leave(struct dsa_port *dp, struct net_device *br)
if (err)
pr_err("DSA: failed to notify DSA_NOTIFIER_BRIDGE_LEAVE\n");
+ /* Port is leaving the bridge, disable flooding */
+ dsa_port_bridge_flags(dp, 0, NULL);
+
/* Port left the bridge, put in BR_STATE_DISABLED by the bridge layer,
* so allow it to be in BR_STATE_FORWARDING to be kept functional
*/
--
2.7.4
^ permalink raw reply related
* [PATCH net-next v4 2/3] net: dsa: mv88e6xxx: add support for bridge flags
From: Russell King @ 2019-02-20 20:55 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Vivien Didelot
Cc: Heiner Kallweit, David S. Miller, netdev
In-Reply-To: <20190220205525.nji63ntsthxbus4l@shell.armlinux.org.uk>
Add support for the bridge flags to Marvell 88e6xxx bridges, allowing
the multicast and unicast flood properties to be controlled. These
can be controlled on a per-port basis via commands such as:
bridge link set dev lan1 flood on|off
bridge link set dev lan1 mcast_flood on|off
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/dsa/mv88e6xxx/chip.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 32e7af5caa69..cc7ce06b6d58 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -4692,6 +4692,22 @@ static int mv88e6xxx_port_mdb_del(struct dsa_switch *ds, int port,
return err;
}
+static int mv88e6xxx_port_egress_floods(struct dsa_switch *ds, int port,
+ bool unicast, bool multicast)
+{
+ struct mv88e6xxx_chip *chip = ds->priv;
+ int err = -EOPNOTSUPP;
+
+ mutex_lock(&chip->reg_lock);
+ if (chip->info->ops->port_set_egress_floods)
+ err = chip->info->ops->port_set_egress_floods(chip, port,
+ unicast,
+ multicast);
+ mutex_unlock(&chip->reg_lock);
+
+ return err;
+}
+
static const struct dsa_switch_ops mv88e6xxx_switch_ops = {
#if IS_ENABLED(CONFIG_NET_DSA_LEGACY)
.probe = mv88e6xxx_drv_probe,
@@ -4719,6 +4735,7 @@ static const struct dsa_switch_ops mv88e6xxx_switch_ops = {
.set_ageing_time = mv88e6xxx_set_ageing_time,
.port_bridge_join = mv88e6xxx_port_bridge_join,
.port_bridge_leave = mv88e6xxx_port_bridge_leave,
+ .port_egress_floods = mv88e6xxx_port_egress_floods,
.port_stp_state_set = mv88e6xxx_port_stp_state_set,
.port_fast_age = mv88e6xxx_port_fast_age,
.port_vlan_filtering = mv88e6xxx_port_vlan_filtering,
--
2.7.4
^ permalink raw reply related
* [PATCH net-next v4 1/3] net: dsa: add support for bridge flags
From: Russell King @ 2019-02-20 20:55 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Vivien Didelot
Cc: Heiner Kallweit, David S. Miller, netdev
In-Reply-To: <20190220205525.nji63ntsthxbus4l@shell.armlinux.org.uk>
The Linux bridge implementation allows various properties of the bridge
to be controlled, such as flooding unknown unicast and multicast frames.
This patch adds the necessary DSA infrastructure to allow the Linux
bridge support to control these properties for DSA switches.
Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
include/net/dsa.h | 2 ++
net/dsa/dsa_priv.h | 2 ++
net/dsa/port.c | 17 +++++++++++++++++
net/dsa/slave.c | 6 ++++++
4 files changed, 27 insertions(+)
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 7f2a668ef2cc..2c2c10812814 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -400,6 +400,8 @@ struct dsa_switch_ops {
void (*port_stp_state_set)(struct dsa_switch *ds, int port,
u8 state);
void (*port_fast_age)(struct dsa_switch *ds, int port);
+ int (*port_egress_floods)(struct dsa_switch *ds, int port,
+ bool unicast, bool multicast);
/*
* VLAN support
diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h
index 1f4972dab9f2..f4f99ec29f5d 100644
--- a/net/dsa/dsa_priv.h
+++ b/net/dsa/dsa_priv.h
@@ -160,6 +160,8 @@ int dsa_port_mdb_add(const struct dsa_port *dp,
struct switchdev_trans *trans);
int dsa_port_mdb_del(const struct dsa_port *dp,
const struct switchdev_obj_port_mdb *mdb);
+int dsa_port_bridge_flags(const struct dsa_port *dp, unsigned long flags,
+ struct switchdev_trans *trans);
int dsa_port_vlan_add(struct dsa_port *dp,
const struct switchdev_obj_port_vlan *vlan,
struct switchdev_trans *trans);
diff --git a/net/dsa/port.c b/net/dsa/port.c
index 2d7e01b23572..6df29bddf37e 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -177,6 +177,23 @@ int dsa_port_ageing_time(struct dsa_port *dp, clock_t ageing_clock,
return dsa_port_notify(dp, DSA_NOTIFIER_AGEING_TIME, &info);
}
+int dsa_port_bridge_flags(const struct dsa_port *dp, unsigned long flags,
+ struct switchdev_trans *trans)
+{
+ struct dsa_switch *ds = dp->ds;
+ int port = dp->index;
+ int err = 0;
+
+ if (switchdev_trans_ph_prepare(trans))
+ return 0;
+
+ if (ds->ops->port_egress_floods)
+ err = ds->ops->port_egress_floods(ds, port, flags & BR_FLOOD,
+ flags & BR_MCAST_FLOOD);
+
+ return err;
+}
+
int dsa_port_fdb_add(struct dsa_port *dp, const unsigned char *addr,
u16 vid)
{
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 2e5e7c04821b..f99161c3b1ea 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -295,6 +295,9 @@ static int dsa_slave_port_attr_set(struct net_device *dev,
case SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME:
ret = dsa_port_ageing_time(dp, attr->u.ageing_time, trans);
break;
+ case SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS:
+ ret = dsa_port_bridge_flags(dp, attr->u.brport_flags, trans);
+ break;
default:
ret = -EOPNOTSUPP;
break;
@@ -384,6 +387,9 @@ static int dsa_slave_port_attr_get(struct net_device *dev,
switch (attr->id) {
case SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT:
attr->u.brport_flags_support = 0;
+ if (ds->ops->port_egress_floods)
+ attr->u.brport_flags_support |= BR_FLOOD |
+ BR_MCAST_FLOOD;
break;
default:
return -EOPNOTSUPP;
--
2.7.4
^ permalink raw reply related
* [PATCH net-next v4 0/3] net: dsa: mv88e6xxx: fix IPv6
From: Russell King - ARM Linux admin @ 2019-02-20 20:55 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Vivien Didelot
Cc: David S. Miller, Heiner Kallweit, netdev
We have had some emails in private over this issue, this is my current
patch set rebased on top of net-next which provides working IPv6 (and
probably other protocols as well) over mv88e6xxx DSA switches.
The problem comes down to mv88e6xxx defaulting to not flood unknown
unicast and multicast datagrams, as they would be by dumb switches,
and as the Linux bridge code does by default.
There is also the issue of IPv6 over a vlan that is transparent to the
bridge; the multicast querier will not reach inside the vlan, and so
the switch can not learn about multicast routing within the vlan.
These flood settings can be disabled via the Linux bridge code if it's
desired to make the switch behave more like a managed switch, eg, by
enabling the multicast querier. However, the multicast querier
defaults to being disabled which effectively means that by default,
mv88e6xxx switches block all multicast traffic. This is at odds with
the Linux bridge documentation, and the defaults that the Linux bridge
code adopts.
So, this patch set adds DSA support for Linux bridge flags, adds
mv88e6xxx support for the unicast and multicast flooding flags, and
lastly enables flooding of these frames by default to match the
Linux bridge defaults.
drivers/net/dsa/mv88e6xxx/chip.c | 17 +++++++++++++++++
include/net/dsa.h | 2 ++
net/dsa/dsa_priv.h | 2 ++
net/dsa/port.c | 33 ++++++++++++++++++++++++++++++---
net/dsa/slave.c | 6 ++++++
5 files changed, 57 insertions(+), 3 deletions(-)
v2: fix a couple of compile errors in patch 2 and patch 3 (oops).
v3: change interface between core DSA and drivers
v4: fix comments from v3
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: linux-next: Fixes tag needs some work in the net-next tree
From: David Miller @ 2019-02-20 20:42 UTC (permalink / raw)
To: sbrivio; +Cc: jiri, vkoul, sfr, netdev, linux-next, linux-kernel, andrew
In-Reply-To: <20190220213729.49deb54f@redhat.com>
From: Stefano Brivio <sbrivio@redhat.com>
Date: Wed, 20 Feb 2019 21:37:29 +0100
> On Wed, 20 Feb 2019 12:25:48 -0800 (PST)
> David Miller <davem@davemloft.net> wrote:
>
>> From: Stefano Brivio <sbrivio@redhat.com>
>> Date: Wed, 20 Feb 2019 20:59:10 +0100
>>
>> > On Wed, 20 Feb 2019 11:02:01 -0800 (PST)
>> > David Miller <davem@davemloft.net> wrote:
>> >
>> >> From: Jiri Pirko <jiri@resnulli.us>
>> >> Date: Wed, 20 Feb 2019 09:36:11 +0100
>> >>
>> >> > Would be good to have some robot checking "Fixes" sanity...
>> >>
>> >> I want to add a script to my trees that locally do it for me but the
>> >> backlog for patch review for me is so huge that I never get to "fun"
>> >> tasks like that....
>> >
>> > If it helps, this is what I use after being bitten once:
>>
>> Awesome, thanks! You put this in as a pre-commit script?
>
> Nope, I use it before sending patches out with git send-email.
>
> But you can use this as .git/hooks/commit-msg, just skip taking the
> tree as second argument, something like this (just quickly tested):
Awesome, thank you!
^ permalink raw reply
* Re: [PATCH 6/6] net: ethernet: ti: cpsw: deprecate cpsw-phy-sel driver
From: David Miller @ 2019-02-20 20:41 UTC (permalink / raw)
To: tony
Cc: grygorii.strashko, kishon, robh+dt, netdev, nsekhar, linux-kernel,
linux-omap, devicetree, linux-arm-kernel
In-Reply-To: <20190220203326.GT15711@atomide.com>
From: Tony Lindgren <tony@atomide.com>
Date: Wed, 20 Feb 2019 12:33:26 -0800
> * David Miller <davem@davemloft.net> [190220 19:23]:
>> From: Grygorii Strashko <grygorii.strashko@ti.com>
>> Date: Wed, 20 Feb 2019 17:25:19 +0200
>>
>> > Deprecate cpsw-phy-sel driver as it's been replaced with new
>> > TI phy-gmii-sel PHY driver.
>> >
>> > Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>>
>> Acked-by: David S. Miller <davem@davemloft.net>
>
> Thanks for the ack, but actually I'd prefer you to pick
> this patch at some future date. I suggest Grygorii just
> repost this one after v5.1-rc1.
It's so much easier if you group this with those DT changes, they
logically belong together as well and it helps someone reading
the changes in the tree also if they are side by side.
Why don't you want to integrate this with them?
^ permalink raw reply
* Re: linux-next: Fixes tag needs some work in the net-next tree
From: Stefano Brivio @ 2019-02-20 20:37 UTC (permalink / raw)
To: David Miller; +Cc: jiri, vkoul, sfr, netdev, linux-next, linux-kernel, andrew
In-Reply-To: <20190220.122548.2257661716734858013.davem@davemloft.net>
On Wed, 20 Feb 2019 12:25:48 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: Stefano Brivio <sbrivio@redhat.com>
> Date: Wed, 20 Feb 2019 20:59:10 +0100
>
> > On Wed, 20 Feb 2019 11:02:01 -0800 (PST)
> > David Miller <davem@davemloft.net> wrote:
> >
> >> From: Jiri Pirko <jiri@resnulli.us>
> >> Date: Wed, 20 Feb 2019 09:36:11 +0100
> >>
> >> > Would be good to have some robot checking "Fixes" sanity...
> >>
> >> I want to add a script to my trees that locally do it for me but the
> >> backlog for patch review for me is so huge that I never get to "fun"
> >> tasks like that....
> >
> > If it helps, this is what I use after being bitten once:
>
> Awesome, thanks! You put this in as a pre-commit script?
Nope, I use it before sending patches out with git send-email.
But you can use this as .git/hooks/commit-msg, just skip taking the
tree as second argument, something like this (just quickly tested):
#!/bin/sh
grep "^Fixes: " "${1}" | while read -r f; do
sha="$(echo "${f}" | cut -d' ' -f2)"
if [ -z "${sha}" ] || [ "${f}" != "$(git show -s --abbrev=12 --pretty=format:"Fixes: %h (\"%s\")" "${sha}" 2>/dev/null)" ]; then
echo "Bad tag: ${f}" && exit 1
fi
done
--
Stefano
^ permalink raw reply
* Re: linux-next: Fixes tag needs some work in the net-next tree
From: Jiri Pirko @ 2019-02-20 20:26 UTC (permalink / raw)
To: David Miller; +Cc: vkoul, sfr, netdev, linux-next, linux-kernel, andrew
In-Reply-To: <20190220.122522.1237657062289636264.davem@davemloft.net>
Wed, Feb 20, 2019 at 09:25:22PM CET, davem@davemloft.net wrote:
>From: Jiri Pirko <jiri@resnulli.us>
>Date: Wed, 20 Feb 2019 20:58:11 +0100
>
>> Wed, Feb 20, 2019 at 08:02:01PM CET, davem@davemloft.net wrote:
>>>From: Jiri Pirko <jiri@resnulli.us>
>>>Date: Wed, 20 Feb 2019 09:36:11 +0100
>>>
>>>> Would be good to have some robot checking "Fixes" sanity...
>>>
>>>I want to add a script to my trees that locally do it for me but the
>>
>> When it is in tree, it's already late. The robot has to check
>> emails/patchwork.
>
>It's for me, on my computer, to abort things when I try to commit
>with a bad fixes tag or missing signoff.
Okay, but still, robot checking emails/patchwork would safe you some
overhead.
^ permalink raw reply
* Re: [PATCH 6/6] net: ethernet: ti: cpsw: deprecate cpsw-phy-sel driver
From: Tony Lindgren @ 2019-02-20 20:33 UTC (permalink / raw)
To: David Miller
Cc: grygorii.strashko, kishon, robh+dt, netdev, nsekhar, linux-kernel,
linux-omap, devicetree, linux-arm-kernel
In-Reply-To: <20190220.112244.1206973642383679896.davem@davemloft.net>
* David Miller <davem@davemloft.net> [190220 19:23]:
> From: Grygorii Strashko <grygorii.strashko@ti.com>
> Date: Wed, 20 Feb 2019 17:25:19 +0200
>
> > Deprecate cpsw-phy-sel driver as it's been replaced with new
> > TI phy-gmii-sel PHY driver.
> >
> > Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>
> Acked-by: David S. Miller <davem@davemloft.net>
Thanks for the ack, but actually I'd prefer you to pick
this patch at some future date. I suggest Grygorii just
repost this one after v5.1-rc1.
This way I can keep my last pending v5.1 branch limited
to dts changes to make the arm-soc life easier.
Regards,
Tony
^ permalink raw reply
* Re: mlx5 stable backport help
From: David Miller @ 2019-02-20 20:27 UTC (permalink / raw)
To: saeedm; +Cc: netdev, ogerlitz
In-Reply-To: <33b67a2b9a67bc9fe307edc0a3eeeab875598a09.camel@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Wed, 20 Feb 2019 20:01:00 +0000
> On Tue, 2019-02-19 at 22:36 -0800, David Miller wrote:
>> 218d05ce326f9e1b40a56085431fa1068b43d5d9 ("net/mlx5e: Don't overwrite
>> pedit action when multiple pedit used")
>>
>
> I tried and this patch applies smoothly on 4.19.
Does not apply to v4.19.24 which is the current stable release.
[davem@localhost linux-stable]$ git am QUEUE/mlx5e/0002-net-mlx5e-Don-t-overwrite-pedit-action-when-multiple.patch
Applying: net/mlx5e: Don't overwrite pedit action when multiple pedit used
error: patch failed: drivers/net/ethernet/mellanox/mlx5/core/en_tc.c:128
error: drivers/net/ethernet/mellanox/mlx5/core/en_tc.c: patch does not apply
Patch failed at 0001 net/mlx5e: Don't overwrite pedit action when multiple pedit used
hint: Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
^ permalink raw reply
* [PATCH] isdn_common: Mark expected switch fall-throughs
From: Gustavo A. R. Silva @ 2019-02-20 20:25 UTC (permalink / raw)
To: Karsten Keil; +Cc: netdev, linux-kernel, Gustavo A. R. Silva, Kees Cook
In preparation to enabling -Wimplicit-fallthrough, mark switch
cases where we are expecting to fall through.
This patch fixes the following warnings:
drivers/isdn/i4l/isdn_common.c: In function ‘isdn_wildmat’:
drivers/isdn/i4l/isdn_common.c:173:5: warning: this statement may fall through [-Wimplicit-fallthrough=]
p++;
~^~
drivers/isdn/i4l/isdn_common.c:174:3: note: here
default:
^~~~~~~
CC [M] drivers/leds/leds-lp8788.o
CC [M] drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smu10_smumgr.o
drivers/isdn/i4l/isdn_common.c: In function ‘isdn_status_callback’:
drivers/isdn/i4l/isdn_common.c:729:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
if (divert_if)
^
drivers/isdn/i4l/isdn_common.c:732:2: note: here
default:
^~~~~~~
Warning level 3 was used: -Wimplicit-fallthrough=3
Notice that, in this particular case, the code comment is modified
in accordance with what GCC is expecting to find.
This patch is part of the ongoing efforts to enable
-Wimplicit-fallthrough.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/isdn/i4l/isdn_common.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/isdn/i4l/isdn_common.c b/drivers/isdn/i4l/isdn_common.c
index 6a5b3f00f9ad..74ee00f5b310 100644
--- a/drivers/isdn/i4l/isdn_common.c
+++ b/drivers/isdn/i4l/isdn_common.c
@@ -166,11 +166,9 @@ isdn_wildmat(char *s, char *p)
for (; *p; s++, p++)
switch (*p) {
case '\\':
- /*
- * Literal match with following character,
- * fall through.
- */
+ /* Literal match with following character. */
p++;
+ /* fall through */
default:
if (*s != *p)
return (*s == '\0') ? 2 : 1;
@@ -729,6 +727,7 @@ isdn_status_callback(isdn_ctrl *c)
if (divert_if)
return (divert_if->stat_callback(c));
#endif /* CONFIG_ISDN_DIVERSION */
+ /* fall through */
default:
return -1;
}
--
2.20.1
^ permalink raw reply related
* Re: linux-next: Fixes tag needs some work in the net-next tree
From: David Miller @ 2019-02-20 20:25 UTC (permalink / raw)
To: sbrivio; +Cc: jiri, vkoul, sfr, netdev, linux-next, linux-kernel, andrew
In-Reply-To: <20190220205910.7bd7fd40@redhat.com>
From: Stefano Brivio <sbrivio@redhat.com>
Date: Wed, 20 Feb 2019 20:59:10 +0100
> On Wed, 20 Feb 2019 11:02:01 -0800 (PST)
> David Miller <davem@davemloft.net> wrote:
>
>> From: Jiri Pirko <jiri@resnulli.us>
>> Date: Wed, 20 Feb 2019 09:36:11 +0100
>>
>> > Would be good to have some robot checking "Fixes" sanity...
>>
>> I want to add a script to my trees that locally do it for me but the
>> backlog for patch review for me is so huge that I never get to "fun"
>> tasks like that....
>
> If it helps, this is what I use after being bitten once:
Awesome, thanks! You put this in as a pre-commit script?
^ permalink raw reply
* Re: linux-next: Fixes tag needs some work in the net-next tree
From: David Miller @ 2019-02-20 20:25 UTC (permalink / raw)
To: jiri; +Cc: vkoul, sfr, netdev, linux-next, linux-kernel, andrew
In-Reply-To: <20190220195811.GO3080@nanopsycho>
From: Jiri Pirko <jiri@resnulli.us>
Date: Wed, 20 Feb 2019 20:58:11 +0100
> Wed, Feb 20, 2019 at 08:02:01PM CET, davem@davemloft.net wrote:
>>From: Jiri Pirko <jiri@resnulli.us>
>>Date: Wed, 20 Feb 2019 09:36:11 +0100
>>
>>> Would be good to have some robot checking "Fixes" sanity...
>>
>>I want to add a script to my trees that locally do it for me but the
>
> When it is in tree, it's already late. The robot has to check
> emails/patchwork.
It's for me, on my computer, to abort things when I try to commit
with a bad fixes tag or missing signoff.
^ permalink raw reply
* Re: linux-next: Fixes tag needs some work in the net-next tree
From: Jiri Pirko @ 2019-02-20 19:58 UTC (permalink / raw)
To: David Miller; +Cc: vkoul, sfr, netdev, linux-next, linux-kernel, andrew
In-Reply-To: <20190220.110201.2245447687492293995.davem@davemloft.net>
Wed, Feb 20, 2019 at 08:02:01PM CET, davem@davemloft.net wrote:
>From: Jiri Pirko <jiri@resnulli.us>
>Date: Wed, 20 Feb 2019 09:36:11 +0100
>
>> Would be good to have some robot checking "Fixes" sanity...
>
>I want to add a script to my trees that locally do it for me but the
When it is in tree, it's already late. The robot has to check
emails/patchwork.
>backlog for patch review for me is so huge that I never get to "fun"
>tasks like that....
>
>This has been discussed before too.
^ permalink raw reply
* Re: mlx5 stable backport help
From: Saeed Mahameed @ 2019-02-20 20:01 UTC (permalink / raw)
To: davem@davemloft.net; +Cc: netdev@vger.kernel.org, Or Gerlitz
In-Reply-To: <20190219.223612.1535166672416390768.davem@davemloft.net>
On Tue, 2019-02-19 at 22:36 -0800, David Miller wrote:
> Saeed and Or,
>
> I need help backporting two changes for -stable. Namely:
Hi Dave Thanks for trying,
>
> 6707f74be8621ae067d2cf1c4485900e2742c20f ("net/mlx5e: Update hw flows
> when encap source mac changed")
The fixes tag of the above commit is wrong and it should have been
commit e32ee6c78efa6a32bff782bbe7a9970b018996ca
Author: Eli Britstein <elibr@mellanox.com>
Date: Mon Dec 3 17:09:54 2018 +0200
net/mlx5e: Support tunnel encap over tagged Ethernet
Before this patch we didn't have the support for "tunnel encap over
tagged Ethernet" which introduced the whole route_dev logic to generate
the encap headers, so the patch should only exist in -rc, let's just
skip it.
> 218d05ce326f9e1b40a56085431fa1068b43d5d9 ("net/mlx5e: Don't overwrite
> pedit action when multiple pedit used")
>
I tried and this patch applies smoothly on 4.19.
let me know if you need further assistance.
Thanks,
Saeed
> For example, with the first one, not only has the code moved into
> tc_tun.c but also we require the addition of
> get_route_and_out_devs(),
> the passing in of the &route_dev, and also all of the new
> dst_is_lag_dev logic. That's like 4 or 5 commits worth.
>
> Thanks.
^ permalink raw reply
* Re: linux-next: Fixes tag needs some work in the net-next tree
From: Stefano Brivio @ 2019-02-20 19:59 UTC (permalink / raw)
To: David Miller; +Cc: jiri, vkoul, sfr, netdev, linux-next, linux-kernel, andrew
In-Reply-To: <20190220.110201.2245447687492293995.davem@davemloft.net>
On Wed, 20 Feb 2019 11:02:01 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: Jiri Pirko <jiri@resnulli.us>
> Date: Wed, 20 Feb 2019 09:36:11 +0100
>
> > Would be good to have some robot checking "Fixes" sanity...
>
> I want to add a script to my trees that locally do it for me but the
> backlog for patch review for me is so huge that I never get to "fun"
> tasks like that....
If it helps, this is what I use after being bitten once:
#!/bin/sh
[ ${#} -ne 2 ] && echo "Usage: %0 PATCH_FILE GIT_TREE" && exit 1
grep "^Fixes: " "${1}" | while read -r f; do
sha="$(echo "${f}" | cut -d' ' -f2)"
if [ -z "${sha}" ] || [ "${f}" != "$(git -C "${2}" show -s --abbrev=12 --pretty=format:"Fixes: %h (\"%s\")" "${sha}" 2>/dev/null)" ]; then
echo "Bad tag: ${f}" && exit 1
fi
done
--
Stefano
^ permalink raw reply
* [RFC] odd checks in AF_UNIX ->recvmsg()
From: Al Viro @ 2019-02-20 19:47 UTC (permalink / raw)
To: netdev
Can ->recvmsg() (or ->splice_read(), for that matter)
overlap with ->release() of the socket it's reading from?
I'd always assumed that to be impossible, but we have this
in unix_stream_read_generic():
redo:
unix_state_lock(sk);
if (sock_flag(sk, SOCK_DEAD)) {
err = -ECONNRESET;
goto unlock;
}
last = skb = skb_peek(&sk->sk_receive_queue);
last_len = last ? last->len : 0;
...
and sk comes from state->socket->sk, i.e. sock->sk of unix_stream_recvmsg()
and unix_stream_splice_read(). IOW, the socket being read from. And
SOCK_DEAD is only set by sock_orphan(), which means that socket would
have to have gone through ->release().
What am I missing and how is that supposed to be triggered? Note that
e.g. shutdown(2) doesn't set SOCK_DEAD - its effects are in ->sk_shutdown
and the same unix_stream_read_generic() does check for those separately.
^ permalink raw reply
* Re: [PATCH net v2] af_packet: fix raw sockets over 6in4 tunnel
From: David Miller @ 2019-02-20 19:33 UTC (permalink / raw)
To: willemdebruijn.kernel; +Cc: sashal, nicolas.dichtel, netdev, willemb, maximmi
In-Reply-To: <CAF=yD-+M=FG+a1ykO5ucBSfE0vvV3C_cNBUH1p55Cy1e7mHA-g@mail.gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Wed, 20 Feb 2019 13:39:23 -0500
> On Mon, Feb 18, 2019 at 1:50 PM Sasha Levin <sashal@kernel.org> wrote:
>> Should this go to -stable as well? The patch it fixes is in 4.20.
>
> I believe so. It was also backported to 4.19 stable.
Ok, I'll submit it, thanks.
^ permalink raw reply
* [PATCH net-next 10/10] mlxsw: spectrum_buffers: Reject overlarge headroom size requests
From: Ido Schimmel @ 2019-02-20 19:32 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, Jiri Pirko, Petr Machata, mlxsw,
Ido Schimmel
In-Reply-To: <20190220193141.16498-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
cap_max_headroom_size holds maximum headroom size supported.
Overstepping that limit might under certain conditions lead to ASIC
freeze.
Query and store the value, and add mlxsw_sp_sb_max_headroom_cells() for
obtaining the stored value. In __mlxsw_sp_port_headroom_set(), reject
requests where the total port buffer is larger than the advertised
maximum.
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/resources.h | 2 ++
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 13 ++++++++++++-
drivers/net/ethernet/mellanox/mlxsw/spectrum.h | 1 +
.../ethernet/mellanox/mlxsw/spectrum_buffers.c | 16 ++++++++++++++++
4 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/resources.h b/drivers/net/ethernet/mellanox/mlxsw/resources.h
index b8b3a01c2a9e..773ef7fdb285 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/resources.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/resources.h
@@ -26,6 +26,7 @@ enum mlxsw_res_id {
MLXSW_RES_ID_MAX_LAG_MEMBERS,
MLXSW_RES_ID_MAX_BUFFER_SIZE,
MLXSW_RES_ID_CELL_SIZE,
+ MLXSW_RES_ID_MAX_HEADROOM_SIZE,
MLXSW_RES_ID_ACL_MAX_TCAM_REGIONS,
MLXSW_RES_ID_ACL_MAX_TCAM_RULES,
MLXSW_RES_ID_ACL_MAX_REGIONS,
@@ -79,6 +80,7 @@ static u16 mlxsw_res_ids[] = {
[MLXSW_RES_ID_MAX_LAG_MEMBERS] = 0x2521,
[MLXSW_RES_ID_MAX_BUFFER_SIZE] = 0x2802, /* Bytes */
[MLXSW_RES_ID_CELL_SIZE] = 0x2803, /* Bytes */
+ [MLXSW_RES_ID_MAX_HEADROOM_SIZE] = 0x2811, /* Bytes */
[MLXSW_RES_ID_ACL_MAX_TCAM_REGIONS] = 0x2901,
[MLXSW_RES_ID_ACL_MAX_TCAM_RULES] = 0x2902,
[MLXSW_RES_ID_ACL_MAX_REGIONS] = 0x2903,
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
index c1ec4f89973b..f018b0607dac 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -852,8 +852,12 @@ int __mlxsw_sp_port_headroom_set(struct mlxsw_sp_port *mlxsw_sp_port, int mtu,
u8 pfc_en = !!my_pfc ? my_pfc->pfc_en : 0;
u16 delay = !!my_pfc ? my_pfc->delay : 0;
char pbmc_pl[MLXSW_REG_PBMC_LEN];
+ u32 taken_headroom_cells = 0;
+ u32 max_headroom_cells;
int i, j, err;
+ max_headroom_cells = mlxsw_sp_sb_max_headroom_cells(mlxsw_sp);
+
mlxsw_reg_pbmc_pack(pbmc_pl, mlxsw_sp_port->local_port, 0, 0);
err = mlxsw_reg_query(mlxsw_sp->core, MLXSW_REG(pbmc), pbmc_pl);
if (err)
@@ -864,6 +868,7 @@ int __mlxsw_sp_port_headroom_set(struct mlxsw_sp_port *mlxsw_sp_port, int mtu,
bool pfc = false;
u16 thres_cells;
u16 delay_cells;
+ u16 total_cells;
bool lossy;
for (j = 0; j < IEEE_8021QAZ_MAX_TCS; j++) {
@@ -881,7 +886,13 @@ int __mlxsw_sp_port_headroom_set(struct mlxsw_sp_port *mlxsw_sp_port, int mtu,
thres_cells = mlxsw_sp_pg_buf_threshold_get(mlxsw_sp, mtu);
delay_cells = mlxsw_sp_pg_buf_delay_get(mlxsw_sp, mtu, delay,
pfc, pause_en);
- mlxsw_sp_pg_buf_pack(pbmc_pl, i, thres_cells + delay_cells,
+ total_cells = thres_cells + delay_cells;
+
+ taken_headroom_cells += total_cells;
+ if (taken_headroom_cells > max_headroom_cells)
+ return -ENOBUFS;
+
+ mlxsw_sp_pg_buf_pack(pbmc_pl, i, total_cells,
thres_cells, lossy);
}
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.h b/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
index 976843917c95..8bb83d0facc2 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
@@ -373,6 +373,7 @@ int mlxsw_sp_sb_occ_tc_port_bind_get(struct mlxsw_core_port *mlxsw_core_port,
u32 *p_cur, u32 *p_max);
u32 mlxsw_sp_cells_bytes(const struct mlxsw_sp *mlxsw_sp, u32 cells);
u32 mlxsw_sp_bytes_cells(const struct mlxsw_sp *mlxsw_sp, u32 bytes);
+u32 mlxsw_sp_sb_max_headroom_cells(const struct mlxsw_sp *mlxsw_sp);
extern const struct mlxsw_sp_sb_vals mlxsw_sp1_sb_vals;
extern const struct mlxsw_sp_sb_vals mlxsw_sp2_sb_vals;
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c
index 65ef4a9f6afb..9a79b5e11597 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c
@@ -85,6 +85,7 @@ struct mlxsw_sp_sb {
struct mlxsw_sp_sb_pr *prs;
struct mlxsw_sp_sb_port *ports;
u32 cell_size;
+ u32 max_headroom_cells;
u64 sb_size;
};
@@ -113,6 +114,11 @@ u32 mlxsw_sp_bytes_cells(const struct mlxsw_sp *mlxsw_sp, u32 bytes)
return DIV_ROUND_UP(bytes, mlxsw_sp->sb->cell_size);
}
+u32 mlxsw_sp_sb_max_headroom_cells(const struct mlxsw_sp *mlxsw_sp)
+{
+ return mlxsw_sp->sb->max_headroom_cells;
+}
+
static struct mlxsw_sp_sb_pr *mlxsw_sp_sb_pr_get(struct mlxsw_sp *mlxsw_sp,
u16 pool_index)
{
@@ -789,6 +795,7 @@ const struct mlxsw_sp_sb_vals mlxsw_sp2_sb_vals = {
int mlxsw_sp_buffers_init(struct mlxsw_sp *mlxsw_sp)
{
+ u32 max_headroom_size;
u16 ing_pool_count;
u16 eg_pool_count;
int err;
@@ -799,12 +806,21 @@ int mlxsw_sp_buffers_init(struct mlxsw_sp *mlxsw_sp)
if (!MLXSW_CORE_RES_VALID(mlxsw_sp->core, MAX_BUFFER_SIZE))
return -EIO;
+ if (!MLXSW_CORE_RES_VALID(mlxsw_sp->core, MAX_HEADROOM_SIZE))
+ return -EIO;
+
mlxsw_sp->sb = kzalloc(sizeof(*mlxsw_sp->sb), GFP_KERNEL);
if (!mlxsw_sp->sb)
return -ENOMEM;
mlxsw_sp->sb->cell_size = MLXSW_CORE_RES_GET(mlxsw_sp->core, CELL_SIZE);
mlxsw_sp->sb->sb_size = MLXSW_CORE_RES_GET(mlxsw_sp->core,
MAX_BUFFER_SIZE);
+ max_headroom_size = MLXSW_CORE_RES_GET(mlxsw_sp->core,
+ MAX_HEADROOM_SIZE);
+ /* Round down, because this limit must not be overstepped. */
+ mlxsw_sp->sb->max_headroom_cells = max_headroom_size /
+ mlxsw_sp->sb->cell_size;
+
err = mlxsw_sp_sb_ports_init(mlxsw_sp);
if (err)
goto err_sb_ports_init;
--
2.20.1
^ permalink raw reply related
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