* [RFC 3/3] net: dsa: mv88e6xxx: setup PVT
From: Vivien Didelot @ 2016-04-20 20:26 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel, David S. Miller, Florian Fainelli,
Andrew Lunn, Jiri Pirko, Vivien Didelot
In-Reply-To: <1461183969-24610-1-git-send-email-vivien.didelot@savoirfairelinux.com>
Instead of allowing any external frame to egress any internal port,
configure the Cross-chip Port VLAN Table (PVT) to forbid that.
When an external source port joins or leaves a bridge crossing this
switch, mask it in the PVT to allow or forbid frames to egress.
Add support for the cross-chip bridge notification to the 6352 family.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
drivers/net/dsa/mv88e6352.c | 1 +
drivers/net/dsa/mv88e6xxx.c | 137 +++++++++++++++++++++++++++++++++++++++++++-
drivers/net/dsa/mv88e6xxx.h | 2 +
3 files changed, 138 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dsa/mv88e6352.c b/drivers/net/dsa/mv88e6352.c
index 4afc24d..03ab309 100644
--- a/drivers/net/dsa/mv88e6352.c
+++ b/drivers/net/dsa/mv88e6352.c
@@ -364,6 +364,7 @@ struct dsa_switch_driver mv88e6352_switch_driver = {
.port_fdb_add = mv88e6xxx_port_fdb_add,
.port_fdb_del = mv88e6xxx_port_fdb_del,
.port_fdb_dump = mv88e6xxx_port_fdb_dump,
+ .cross_chip_bridge = mv88e6xxx_cross_chip_bridge,
};
MODULE_ALIAS("platform:mv88e6172");
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index e35bc9f..dccefdb 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -481,6 +481,14 @@ static bool mv88e6xxx_has_stu(struct dsa_switch *ds)
return false;
}
+static bool mv88e6xxx_has_pvt(struct dsa_switch *ds)
+{
+ if (mv88e6xxx_6185_family(ds))
+ return false;
+
+ return true;
+}
+
/* We expect the switch to perform auto negotiation if there is a real
* phy. However, in the case of a fixed link phy, we force the port
* settings from the fixed link settings.
@@ -2228,8 +2236,69 @@ static int _mv88e6xxx_pvt_cmd(struct dsa_switch *ds, int src_dev, int src_port,
return _mv88e6xxx_pvt_wait(ds);
}
+static int _mv88e6xxx_pvt_read(struct dsa_switch *ds, int src_dev, int src_port,
+ u16 *data)
+{
+ int ret;
+
+ ret = _mv88e6xxx_pvt_wait(ds);
+ if (ret < 0)
+ return ret;
+
+ ret = _mv88e6xxx_pvt_cmd(ds, src_dev, src_port,
+ GLOBAL2_PVT_ADDR_OP_READ);
+ if (ret < 0)
+ return ret;
+
+ ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL2, GLOBAL2_PVT_DATA);
+ if (ret < 0)
+ return ret;
+
+ *data = ret;
+
+ return 0;
+}
+
+static int _mv88e6xxx_pvt_write(struct dsa_switch *ds, int src_dev,
+ int src_port, u16 data)
+{
+ int err;
+
+ err = _mv88e6xxx_pvt_wait(ds);
+ if (err)
+ return err;
+
+ err = _mv88e6xxx_reg_write(ds, REG_GLOBAL2, GLOBAL2_PVT_DATA, data);
+ if (err)
+ return err;
+
+ return _mv88e6xxx_pvt_cmd(ds, src_dev, src_port,
+ GLOBAL2_PVT_ADDR_OP_WRITE_PVLAN);
+}
+
+static int _mv88e6xxx_pvt_map(struct dsa_switch *ds, int src_dev, int src_port,
+ struct net_device *bridge)
+{
+ struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
+ u16 pvlan = 0;
+ int port;
+
+ for (port = 0; port < ps->info->num_ports; ++port) {
+ /* Frames from external ports can egress DSA and CPU ports */
+ if (dsa_is_cpu_port(ds, port) || dsa_is_dsa_port(ds, port))
+ pvlan |= BIT(port);
+
+ /* Frames can egress bridge group members */
+ if (bridge && ps->ports[port].bridge_dev == bridge)
+ pvlan |= BIT(port);
+ }
+
+ return _mv88e6xxx_pvt_write(ds, src_dev, src_port, pvlan);
+}
+
static int _mv88e6xxx_pvt_init(struct dsa_switch *ds)
{
+ int src_dev, src_port;
int err;
/* Clear 5 Bit Port for usage with Marvell Link Street devices:
@@ -2240,8 +2309,21 @@ static int _mv88e6xxx_pvt_init(struct dsa_switch *ds)
if (err)
return err;
- /* Allow any external frame to egress any internal port */
- return _mv88e6xxx_pvt_cmd(ds, 0, 0, GLOBAL2_PVT_ADDR_OP_INIT_ONES);
+ /* Forbid every port of potential neighbor switches to egress frames on
+ * the normal ports of this switch.
+ */
+ for (src_dev = 0; src_dev < 32; ++src_dev) {
+ if (src_dev == ds->index)
+ continue;
+
+ for (src_port = 0; src_port < 16; ++src_port) {
+ err = _mv88e6xxx_pvt_map(ds, src_dev, src_port, NULL);
+ if (err)
+ return err;
+ }
+ }
+
+ return 0;
}
int mv88e6xxx_port_bridge_join(struct dsa_switch *ds, int port,
@@ -2286,6 +2368,35 @@ unlock:
return err;
}
+static int _mv88e6xxx_pvt_unmap_local(struct dsa_switch *ds, int port)
+{
+ u16 pvlan;
+ int src_dev, src_port, err;
+
+ for (src_dev = 0; src_dev < 32; ++src_dev) {
+ if (src_dev == ds->index)
+ continue;
+
+ for (src_port = 0; src_port < 16; ++src_port) {
+ err = _mv88e6xxx_pvt_read(ds, src_dev, src_port,
+ &pvlan);
+ if (err)
+ return err;
+
+ /* Forbid external normal frames to egress this port */
+ if (pvlan & BIT(port)) {
+ err = _mv88e6xxx_pvt_write(ds, src_dev,
+ src_port,
+ pvlan & ~BIT(port));
+ if (err)
+ return err;
+ }
+ }
+ }
+
+ return 0;
+}
+
void mv88e6xxx_port_bridge_leave(struct dsa_switch *ds, int port)
{
struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
@@ -2308,6 +2419,28 @@ void mv88e6xxx_port_bridge_leave(struct dsa_switch *ds, int port)
if (_mv88e6xxx_port_based_vlan_map(ds, i))
netdev_warn(ds->ports[i], "failed to remap\n");
+ if (mv88e6xxx_has_pvt(ds) && _mv88e6xxx_pvt_unmap_local(ds, port))
+ netdev_err(ds->ports[port], "failed to unmap\n");
+
+ mutex_unlock(&ps->smi_mutex);
+}
+
+void mv88e6xxx_cross_chip_bridge(struct dsa_switch *ds, int sw_index,
+ int sw_port, struct net_device *bridge)
+{
+ struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
+
+ if (!mv88e6xxx_has_pvt(ds))
+ return;
+
+ /* Update the Cross-chip Port VLAN Table (PVT) entry for this external
+ * source port to map which internal ports frames are allowed to egress.
+ */
+
+ mutex_lock(&ps->smi_mutex);
+ if (_mv88e6xxx_pvt_map(ds, sw_index, sw_port, bridge))
+ dev_err(ds->master_dev, "failed to access PVT for sw%dp%d\n",
+ sw_index, sw_port);
mutex_unlock(&ps->smi_mutex);
}
diff --git a/drivers/net/dsa/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx.h
index dd63377..ea214f2 100644
--- a/drivers/net/dsa/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx.h
@@ -523,6 +523,8 @@ int mv88e6xxx_port_fdb_del(struct dsa_switch *ds, int port,
int mv88e6xxx_port_fdb_dump(struct dsa_switch *ds, int port,
struct switchdev_obj_port_fdb *fdb,
int (*cb)(struct switchdev_obj *obj));
+void mv88e6xxx_cross_chip_bridge(struct dsa_switch *ds, int sw_index,
+ int sw_port, struct net_device *bridge);
int mv88e6xxx_phy_page_read(struct dsa_switch *ds, int port, int page, int reg);
int mv88e6xxx_phy_page_write(struct dsa_switch *ds, int port, int page,
int reg, int val);
--
2.8.0
^ permalink raw reply related
* Re: [PATCH net-next v6] rtnetlink: add new RTM_GETSTATS message to dump link stats
From: Roopa Prabhu @ 2016-04-20 20:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev, jhs, tgraf, nicolas.dichtel, nikolay
In-Reply-To: <20160420.160849.1254968687102415877.davem@davemloft.net>
On 4/20/16, 1:08 PM, David Miller wrote:
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
> Date: Wed, 20 Apr 2016 08:43:43 -0700
>
>> This patch adds a new RTM_GETSTATS message to query link stats via netlink
>> from the kernel. RTM_NEWLINK also dumps stats today, but RTM_NEWLINK
>> returns a lot more than just stats and is expensive in some cases when
>> frequent polling for stats from userspace is a common operation.
> With nla_align_64bit() now working properly, I've applied this and it works
> on sparc64 too.
>
> Thanks!
Thank you.
^ permalink raw reply
* Re: drop all fragments inside tx queue if one gets dropped
From: Rick Jones @ 2016-04-20 20:45 UTC (permalink / raw)
To: Michael Richardson, netdev, linux-wpan; +Cc: Alexander Aring
In-Reply-To: <11312.1461183334@obiwan.sandelman.ca>
For the "everything old is new again" files, back in the 1990s, it was
noticed that on the likes of a netperf UDP_STREAM test on HP-UX, with
fragmentation taking place, it was possible to consume 100% of the link
bandwidth and have 0% effective throughput because the transmit queue
was kept full with IP datagram fragments which could not possibly be
reassembled (*) because one or more of the fragments of a datagram were
dropped because the transmit queue was full.
HP-UX implemented "packet trains" where all the fragments of a
fragmented datagram were presented to the driver, which then either
queued them all, or none of them.
I don't recall seeing similar poor behaviour in Linux; I would have
assumed that the intra-stack flow-control "took care" of it. Perhaps
there is something specific to wpan which precludes that?
happy benchmarking,
rick jones
^ permalink raw reply
* [net-next resubmit PATCH v2 0/3] Feature tweaks/fixes follow-up to GSO partial patches
From: Alexander Duyck @ 2016-04-20 20:50 UTC (permalink / raw)
To: netdev, davem, alexander.duyck
This patch series is a set of minor fix-ups and tweaks following the GSO
partial and TSO with IPv4 ID mangling patches. It mostly is just meant to
make certain that if we have GSO partial support at the device we can make
use of it from the far end of the tunnel.
I submitted this earlier today but it was set as RFC in patchwork. This is
a submission for net-next and not an RFC so I am resubmitting.
v2: Added cover page which was forgotten with first submission.
Added patch that enables TSOv4 IP ID mangling w/ tunnels and/or VLANs.
---
Alexander Duyck (3):
netdev_features: Fold NETIF_F_ALL_TSO into NETIF_F_GSO_SOFTWARE
veth: Update features to include all tunnel GSO types
net: Add support for IP ID mangling TSO in cases that require encapsulation
drivers/net/veth.c | 7 +++----
include/linux/netdev_features.h | 8 +++-----
net/core/dev.c | 11 +++++++++++
3 files changed, 17 insertions(+), 9 deletions(-)
^ permalink raw reply
* [net-next resubmit PATCH v2 1/3] netdev_features: Fold NETIF_F_ALL_TSO into NETIF_F_GSO_SOFTWARE
From: Alexander Duyck @ 2016-04-20 20:50 UTC (permalink / raw)
To: netdev, davem, alexander.duyck
In-Reply-To: <20160420204900.4029.42938.stgit@ahduyck-xeon-server>
This patch folds NETIF_F_ALL_TSO into the bitmask for NETIF_F_GSO_SOFTWARE.
The idea is to avoid duplication of defines since the only difference
between the two was the GSO_UDP bit.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
---
include/linux/netdev_features.h | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
index 15eb0b12fff9..bc8736266749 100644
--- a/include/linux/netdev_features.h
+++ b/include/linux/netdev_features.h
@@ -152,11 +152,6 @@ enum {
#define NETIF_F_GSO_MASK (__NETIF_F_BIT(NETIF_F_GSO_LAST + 1) - \
__NETIF_F_BIT(NETIF_F_GSO_SHIFT))
-/* List of features with software fallbacks. */
-#define NETIF_F_GSO_SOFTWARE (NETIF_F_TSO | NETIF_F_TSO_ECN | \
- NETIF_F_TSO_MANGLEID | \
- NETIF_F_TSO6 | NETIF_F_UFO)
-
/* List of IP checksum features. Note that NETIF_F_ HW_CSUM should not be
* set in features when NETIF_F_IP_CSUM or NETIF_F_IPV6_CSUM are set--
* this would be contradictory
@@ -170,6 +165,9 @@ enum {
#define NETIF_F_ALL_FCOE (NETIF_F_FCOE_CRC | NETIF_F_FCOE_MTU | \
NETIF_F_FSO)
+/* List of features with software fallbacks. */
+#define NETIF_F_GSO_SOFTWARE (NETIF_F_ALL_TSO | NETIF_F_UFO)
+
/*
* If one device supports one of these features, then enable them
* for all in netdev_increment_features.
^ permalink raw reply related
* [net-next resubmit PATCH v2 2/3] veth: Update features to include all tunnel GSO types
From: Alexander Duyck @ 2016-04-20 20:50 UTC (permalink / raw)
To: netdev, davem, alexander.duyck
In-Reply-To: <20160420204900.4029.42938.stgit@ahduyck-xeon-server>
This patch adds support for the checksum enabled versions of UDP and GRE
tunnels. With this change we should be able to send and receive GSO frames
of these types over the veth pair without needing to segment the packets.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
---
drivers/net/veth.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index 4f30a6ae50d0..f37a6e61d4ad 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -312,10 +312,9 @@ static const struct net_device_ops veth_netdev_ops = {
.ndo_set_rx_headroom = veth_set_rx_headroom,
};
-#define VETH_FEATURES (NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_ALL_TSO | \
- NETIF_F_HW_CSUM | NETIF_F_RXCSUM | NETIF_F_HIGHDMA | \
- NETIF_F_GSO_GRE | NETIF_F_GSO_UDP_TUNNEL | \
- NETIF_F_GSO_IPIP | NETIF_F_GSO_SIT | NETIF_F_UFO | \
+#define VETH_FEATURES (NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_HW_CSUM | \
+ NETIF_F_RXCSUM | NETIF_F_HIGHDMA | \
+ NETIF_F_GSO_SOFTWARE | NETIF_F_GSO_ENCAP_ALL | \
NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_CTAG_RX | \
NETIF_F_HW_VLAN_STAG_TX | NETIF_F_HW_VLAN_STAG_RX )
^ permalink raw reply related
* [net-next resubmit PATCH v2 3/3] net: Add support for IP ID mangling TSO in cases that require encapsulation
From: Alexander Duyck @ 2016-04-20 20:51 UTC (permalink / raw)
To: netdev, davem, alexander.duyck
In-Reply-To: <20160420204900.4029.42938.stgit@ahduyck-xeon-server>
This patch adds support for NETIF_F_TSO_MANGLEID if a given tunnel supports
NETIF_F_TSO. This way if needed a device can then later enable the TSO
with IP ID mangling and the tunnels on top of that device can then also
make use of the IP ID mangling as well.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
---
net/core/dev.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index 52d446b2cb99..6324bc9267f7 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -7029,8 +7029,19 @@ int register_netdevice(struct net_device *dev)
if (!(dev->flags & IFF_LOOPBACK))
dev->hw_features |= NETIF_F_NOCACHE_COPY;
+ /* If IPv4 TCP segmentation offload is supported we should also
+ * allow the device to enable segmenting the frame with the option
+ * of ignoring a static IP ID value. This doesn't enable the
+ * feature itself but allows the user to enable it later.
+ */
if (dev->hw_features & NETIF_F_TSO)
dev->hw_features |= NETIF_F_TSO_MANGLEID;
+ if (dev->vlan_features & NETIF_F_TSO)
+ dev->vlan_features |= NETIF_F_TSO_MANGLEID;
+ if (dev->mpls_features & NETIF_F_TSO)
+ dev->mpls_features |= NETIF_F_TSO_MANGLEID;
+ if (dev->hw_enc_features & NETIF_F_TSO)
+ dev->hw_enc_features |= NETIF_F_TSO_MANGLEID;
/* Make NETIF_F_HIGHDMA inheritable to VLAN devices.
*/
^ permalink raw reply related
* Re: [PATCH net-next v6] rtnetlink: add new RTM_GETSTATS message to dump link stats
From: Elad Raz @ 2016-04-20 20:57 UTC (permalink / raw)
To: Roopa Prabhu
Cc: netdev@vger.kernel.org, jhs@mojatatu.com, davem@davemloft.net,
tgraf@suug.ch, nicolas.dichtel@6wind.com,
nikolay@cumulusnetworks.com
In-Reply-To: <1461167023-7640-1-git-send-email-roopa@cumulusnetworks.com>
> On 20 Apr 2016, at 6:43 PM, Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
>
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> This patch adds a new RTM_GETSTATS message to query link stats via netlink
> from the kernel. RTM_NEWLINK also dumps stats today, but RTM_NEWLINK
> returns a lot more than just stats and is expensive in some cases when
> frequent polling for stats from userspace is a common operation.
>
> RTM_GETSTATS is an attempt to provide a light weight netlink message
> to explicity query only link stats from the kernel on an interface.
> The idea is to also keep it extensible so that new kinds of stats can be
> added to it in the future.
>
> This patch adds the following attribute for NETDEV stats:
> struct nla_policy ifla_stats_policy[IFLA_STATS_MAX + 1] = {
> [IFLA_STATS_LINK_64] = { .len = sizeof(struct rtnl_link_stats64) },
> };
>
> Like any other rtnetlink message, RTM_GETSTATS can be used to get stats of
> a single interface or all interfaces with NLM_F_DUMP.
>
> Future possible new types of stat attributes:
> link af stats:
> - IFLA_STATS_LINK_IPV6 (nested. for ipv6 stats)
> - IFLA_STATS_LINK_MPLS (nested. for mpls/mdev stats)
> extended stats:
> - IFLA_STATS_LINK_EXTENDED (nested. extended software netdev stats like bridge,
> vlan, vxlan etc)
> - IFLA_STATS_LINK_HW_EXTENDED (nested. extended hardware stats which are
> available via ethtool today)
I think that it’s better to have IFLA_STATS_LINK_CPU_ONLY attribute. The default stat should be aggregation of HW only packets and packets that got trapped to CPU together.
>
> This patch also declares a filter mask for all stat attributes.
> User has to provide a mask of stats attributes to query. filter mask
> can be specified in the new hdr 'struct if_stats_msg' for stats messages.
> Other important field in the header is the ifindex.
>
> This api can also include attributes for global stats (eg tcp) in the future.
> When global stats are included in a stats msg, the ifindex in the header
> must be zero. A single stats message cannot contain both global and
> netdev specific stats. To easily distinguish them, netdev specific stat
> attributes name are prefixed with IFLA_STATS_LINK_
>
> Without any attributes in the filter_mask, no stats will be returned.
>
> This patch has been tested with mofified iproute2 ifstat.
>
> Suggested-by: Jamal Hadi Salim <jhs@mojatatu.com>
> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Nice work! Thank you Roopa!
^ permalink raw reply
* [RESEND] Re: updating carl9170-1.fw in linux-firmware.git
From: Christian Lamparter @ 2016-04-20 21:11 UTC (permalink / raw)
To: Kalle Valo
Cc: Lauri Kasanen, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linux Firmware Maintainers,
Xose Vazquez Perez
In-Reply-To: <87a8koiubz.fsf-HodKDYzPHsUD5k0oWYwrnHL1okKdlPRT@public.gmane.org>
On Wednesday, April 20, 2016 10:59:44 AM Kalle Valo wrote:
> Christian Lamparter <chunkeey-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> writes:
>
> > On Monday, April 18, 2016 07:42:05 PM Kalle Valo wrote:
> >> Christian Lamparter <chunkeey-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> writes:
> >>
> >> > On Monday, April 18, 2016 06:45:09 PM Kalle Valo wrote:
> >> >
> >> >> Why even mention anything about a "special firmware" as the firmware is
> >> >> already available from linux-firmware.git?
> >> >
> >> > Yes and no. 1.9.6 is in linux-firmware.git. I've tried to add 1.9.9 too
> >> > but that failed.
> >> > <http://comments.gmane.org/gmane.linux.kernel.wireless.general/114639>
> >>
> >> Rick's comment makes sense to me, better just to provide the latest
> >> version. No need to unnecessary confuse the users. And if someone really
> >> wants to use an older version that she can retrieve it from the git
> >> history.
> >
> > Part of the fun here is that firmware is GPLv2. The linux-firmware.git has
> > to point to or add the firmware source to their tree. They have added every
> > single source file to it.... instead of "packaging" it in a tar.bz2/gz/xz
> > like you normally do for release sources.
> >
> > If you want to read more about it:
> > <http://www.spinics.net/lists/linux-wireless/msg101868.html>
>
> Yeah, that's more work. I get that. But I'm still not understanding
> what's the actual problem which prevents us from updating carl9170
> firmware in linux-firmware.
I'm not sure, but why not ask? I've added the cc'ed Linux Firmware
Maintainers. So for those people reading the fw list:
What would it take to update the carl9170-1.fw firmware file in your
repository to the latest version?
Who has to sent the firmware update. Does it have to be the person who
sent the first request? (Xose)? The maintainer of the firmware (me)?
someone from Qualcomm Atheros? Or someone else (specific)? (the
firmware is licensed as GPLv2 - in theory anyone should be able to
do that)
How should the firmware source update be handled? Currently the latest
.tar.xz of the firmware has ~130kb. The formated patches from 1.9.6 to
latest are about ~100kb (182 individual patches).
How does linux-firmware handle new binary firmware images and new
sources? What if carl9170fw-2.bin is added. Do we need another
source directory for this in the current tree then? Because
carl9170fw-1.bin will still be needed for backwards compatibility
so we basically need to duplicate parts of the source?
Also, how's the situation with ath9k_htc? The 1.4.0 image contains
some GPLv2 code as well? So, why is there no source in the tree, but
just the link to it? Because, I would like to do basically the same
for carl9170fw and just add a link to the carl9170fw repository and
save everyone this source update "song and dance".
Regards,
Christian
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 02/19] io-mapping: Specify mapping size for io_mapping_map_wc()
From: Luis R. Rodriguez @ 2016-04-20 21:23 UTC (permalink / raw)
To: Chris Wilson, Luis R. Rodriguez, intel-gfx, Tvrtko Ursulin,
Mika Kuoppala, Joonas Lahtinen, Tvrtko Ursulin, Daniel Vetter,
Jani Nikula, David Airlie, Yishai Hadas, Dan Williams,
Ingo Molnar, Peter Zijlstra (Intel), David Hildenbrand, dri-devel,
netdev, linux-rdma, linux-kernel
In-Reply-To: <20160420191432.GK17454@nuc-i3427.alporthouse.com>
On Wed, Apr 20, 2016 at 08:14:32PM +0100, Chris Wilson wrote:
> On Wed, Apr 20, 2016 at 08:58:44PM +0200, Luis R. Rodriguez wrote:
> > On Wed, Apr 20, 2016 at 07:42:13PM +0100, Chris Wilson wrote:
> > > The ioremap() hidden behind the io_mapping_map_wc() convenience helper
> > > can be used for remapping multiple pages. Extend the helper so that
> > > future callers can use it for larger ranges.
> > >
> > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> > > Cc: Daniel Vetter <daniel.vetter@intel.com>
> > > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > > Cc: David Airlie <airlied@linux.ie>
> > > Cc: Yishai Hadas <yishaih@mellanox.com>
> > > Cc: Dan Williams <dan.j.williams@intel.com>
> > > Cc: Ingo Molnar <mingo@kernel.org>
> > > Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
> > > Cc: David Hildenbrand <dahi@linux.vnet.ibm.com>
> > > Cc: Luis R. Rodriguez <mcgrof@kernel.org>
> > > Cc: intel-gfx@lists.freedesktop.org
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc: netdev@vger.kernel.org
> > > Cc: linux-rdma@vger.kernel.org
> > > Cc: linux-kernel@vger.kernel.org
> >
> > We have 2 callers today, in the future, can you envision
> > this API getting more options? If so, in order to avoid the
> > pain of collateral evolutions I can suggest a descriptor
> > being passed with the required settings / options. This lets
> > you evolve the API without needing to go in and modify
> > old users. If you choose not to that's fine too, just
> > figured I'd chime in with that as I've seen the pain
> > with other APIs, and I'm putting an end to the needless
> > set of collateral evolutions this way.
>
> Do you have a good example in mind? I've one more patch to try and take
> advantage of the io-mapping (that may or not be such a good idea in
> practice) but I may as well see if I can make io_mapping more useful
> when I do.
Sure, here's my current version of the revamp of the firmware API
to a more flexible API, which lets us compartamentalize the
usermode helper, and through the new API avoids the issues with further
future collateral evolutions. It is still being baked, I'm fine tuning
the SmPL to folks automatically do conversion if they want:
https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux.git/log/?h=20160417-sysdata-api-v1
It also has a test driver (which I'd also recommend if you can pull off).
It would be kind of hard to do something like a lib/io-mapping_test.c
given there is no real device to ioremap -- _but_ perhaps regular
RAM can be used for fake a device MMIO. I am not sure if its even
possible... but if so it would not only be useful for something
like your API but also for testing ioremap() and friends, and
any possible aliasing bombs we may want to vet for. It also hints
how we may in the future be able to automatically write test drivers
for APIs for us through inference, but that needs a lot of more love
to make it tangible.
Luis
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: qdisc spin lock
From: Michael Ma @ 2016-04-20 21:24 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Cong Wang, Linux Kernel Network Developers
In-Reply-To: <1460125157.6473.434.camel@edumazet-glaptop3.roam.corp.google.com>
2016-04-08 7:19 GMT-07:00 Eric Dumazet <eric.dumazet@gmail.com>:
> On Thu, 2016-03-31 at 16:48 -0700, Michael Ma wrote:
>> I didn't really know that multiple qdiscs can be isolated using MQ so
>> that each txq can be associated with a particular qdisc. Also we don't
>> really have multiple interfaces...
>>
>> With this MQ solution we'll still need to assign transmit queues to
>> different classes by doing some math on the bandwidth limit if I
>> understand correctly, which seems to be less convenient compared with
>> a solution purely within HTB.
>>
>> I assume that with this solution I can still share qdisc among
>> multiple transmit queues - please let me know if this is not the case.
>
> Note that this MQ + HTB thing works well, unless you use a bonding
> device. (Or you need the MQ+HTB on the slaves, with no way of sharing
> tokens between the slaves)
Actually MQ+HTB works well for small packets - like flow of 512 byte
packets can be throttled by HTB using one txq without being affected
by other flows with small packets. However I found using this solution
large packets (10k for example) will only achieve very limited
bandwidth. In my test I used MQ to assign one txq to a HTB which sets
rate at 1Gbit/s, 512 byte packets can achieve the ceiling rate by
using 30 threads. But sending 10k packets using 10 threads has only 10
Mbit/s with the same TC configuration. If I increase burst and cburst
of HTB to some extreme large value (like 50MB) the ceiling rate can be
hit.
The strange thing is that I don't see this problem when using HTB as
the root. So txq number seems to be a factor here - however it's
really hard to understand why would it only affect larger packets. Is
this a known issue? Any suggestion on how to investigate the issue
further? Profiling shows that the cpu utilization is pretty low.
>
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bb1d912323d5dd50e1079e389f4e964be14f0ae3
>
> bonding can not really be used as a true MQ device yet.
>
> I might send a patch to disable this 'bonding feature' if no slave sets
> a queue_id.
>
>
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 4/4] drm/i915: Move ioremap_wc tracking onto VMA
From: Luis R. Rodriguez @ 2016-04-20 21:27 UTC (permalink / raw)
To: Luis R. Rodriguez, Chris Wilson, David Airlie,
netdev-u79uwXL29TY76Z2rM5mHXA,
intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Ingo Molnar,
Peter Zijlstra (Intel),
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Daniel Vetter, Dan Williams,
Yishai Hadas, David Hildenbrand
In-Reply-To: <20160420111730.GL2510-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
On Wed, Apr 20, 2016 at 01:17:30PM +0200, Daniel Vetter wrote:
> On Wed, Apr 20, 2016 at 11:10:54AM +0200, Luis R. Rodriguez wrote:
> > Reason I ask is since I noticed a while ago a lot of drivers
> > were using info->fix.smem_start and info->fix.smem_len consistently
> > for their ioremap'd areas it might make sense instead to let the
> > internal framebuffer (register_framebuffer()) optionally manage the
> > ioremap_wc() for drivers, given that this is pretty generic stuff.
>
> All that legacy fbdev stuff is just for legacy support, and I prefer to
> have that as dumb as possible. There's been some discussion even around
> lifting the "kick out firmware fb driver" out of fbdev, since we'd need it
> to have a simple drm driver for e.g. uefi.
>
> But I definitely don't want a legacy horror show like fbdev to
> automagically take care of device mappings for drivers.
Makes sense, it also still begs the question if more modern APIs
could manage the ioremap for you. Evidence shows people get
sloppy and if things were done internally with helpers it may
be easier to later make adjustments.
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH net-next] macvlan: fix failure during registration v2
From: Francesco Ruggeri @ 2016-04-20 21:38 UTC (permalink / raw)
To: netdev
Cc: Francesco Ruggeri, David S. Miller, Eric W. Biederman,
Mahesh Bandewar
If macvlan_common_newlink fails in register_netdevice after macvlan_init
then it decrements port->count twice, first in macvlan_uninit (from
register_netdevice or rollback_registered) and then again in
macvlan_common_newlink.
A similar problem may exist in the ipvlan driver.
This patch consolidates modifications to port->count into macvlan_init
and macvlan_uninit (thanks to Eric Biederman for suggesting this approach).
In macvtap_device_event it also avoids cleaning up in NETDEV_UNREGISTER
if NETDEV_REGISTER had previously failed.
Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
---
drivers/net/macvlan.c | 10 ++++------
drivers/net/macvtap.c | 2 ++
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 2bcf1f3..cb01023 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -795,6 +795,7 @@ static int macvlan_init(struct net_device *dev)
{
struct macvlan_dev *vlan = netdev_priv(dev);
const struct net_device *lowerdev = vlan->lowerdev;
+ struct macvlan_port *port = vlan->port;
dev->state = (dev->state & ~MACVLAN_STATE_MASK) |
(lowerdev->state & MACVLAN_STATE_MASK);
@@ -812,6 +813,8 @@ static int macvlan_init(struct net_device *dev)
if (!vlan->pcpu_stats)
return -ENOMEM;
+ port->count += 1;
+
return 0;
}
@@ -1312,10 +1315,9 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
return err;
}
- port->count += 1;
err = register_netdevice(dev);
if (err < 0)
- goto destroy_port;
+ return err;
dev->priv_flags |= IFF_MACVLAN;
err = netdev_upper_dev_link(lowerdev, dev);
@@ -1330,10 +1332,6 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
unregister_netdev:
unregister_netdevice(dev);
-destroy_port:
- port->count -= 1;
- if (!port->count)
- macvlan_port_destroy(lowerdev);
return err;
}
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 95394ed..e770221 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -1303,6 +1303,8 @@ static int macvtap_device_event(struct notifier_block *unused,
}
break;
case NETDEV_UNREGISTER:
+ if (vlan->minor == 0)
+ break;
devt = MKDEV(MAJOR(macvtap_major), vlan->minor);
device_destroy(macvtap_class, devt);
macvtap_free_minor(vlan);
--
1.8.1.4
^ permalink raw reply related
* Re: [PATCH V2] net: stmmac: socfpga: Remove re-registration of reset controller
From: Dinh Nguyen @ 2016-04-20 21:17 UTC (permalink / raw)
To: Marek Vasut, netdev
Cc: peppe.cavallaro, alexandre.torgue, Matthew Gerlach,
David S . Miller
In-Reply-To: <1461110753-7641-1-git-send-email-marex@denx.de>
On 04/19/2016 07:05 PM, Marek Vasut wrote:
> Both socfpga_dwmac_parse_data() in dwmac-socfpga.c and stmmac_dvr_probe()
> in stmmac_main.c functions call devm_reset_control_get() to register an
> reset controller for the stmmac. This results in an attempt to register
> two reset controllers for the same non-shared reset line.
>
> The first attempt to register the reset controller works fine. The second
> attempt fails with warning from the reset controller core, see below.
> The warning is produced because the reset line is non-shared and thus
> it is allowed to have only up-to one reset controller associated with
> that reset line, not two or more.
>
> The solution is not great. Since the hardware needs to toggle the reset
> before calling stmmac_dvr_probe() to perform mandatory preconfiguration,
> this patch splits socfpga_dwmac_init_probe() from socfpga_dwmac_init().
>
> The socfpga_dwmac_init_probe() temporarily registers the reset controller,
> performs the pre-configuration and unregisters the reset controller again.
> This function is only called from the socfpga_dwmac_probe().
>
> The original socfpga_dwmac_init() is tweaked to use reset controller
> pointer from the stmmac_priv (private data of the stmmac core) instead
> of the local instance, which was used before.
>
> Finally, plat_dat->exit and socfpga_dwmac_exit() is no longer necessary,
> since the functionality is already performed by the stmmac core.
>
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1 at drivers/reset/core.c:187 __of_reset_control_get+0x218/0x270
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc4-next-20160419-00015-gabb2477-dirty #4
> Hardware name: Altera SOCFPGA
> [<c010f290>] (unwind_backtrace) from [<c010b82c>] (show_stack+0x10/0x14)
> [<c010b82c>] (show_stack) from [<c0373da4>] (dump_stack+0x94/0xa8)
> [<c0373da4>] (dump_stack) from [<c011bcc0>] (__warn+0xec/0x104)
> [<c011bcc0>] (__warn) from [<c011bd88>] (warn_slowpath_null+0x20/0x28)
> [<c011bd88>] (warn_slowpath_null) from [<c03a6eb4>] (__of_reset_control_get+0x218/0x270)
> [<c03a6eb4>] (__of_reset_control_get) from [<c03a701c>] (__devm_reset_control_get+0x54/0x90)
> [<c03a701c>] (__devm_reset_control_get) from [<c041fa30>] (stmmac_dvr_probe+0x1b4/0x8e8)
> [<c041fa30>] (stmmac_dvr_probe) from [<c04298c8>] (socfpga_dwmac_probe+0x1b8/0x28c)
> [<c04298c8>] (socfpga_dwmac_probe) from [<c03d6ffc>] (platform_drv_probe+0x4c/0xb0)
> [<c03d6ffc>] (platform_drv_probe) from [<c03d54ec>] (driver_probe_device+0x224/0x2bc)
> [<c03d54ec>] (driver_probe_device) from [<c03d5630>] (__driver_attach+0xac/0xb0)
> [<c03d5630>] (__driver_attach) from [<c03d382c>] (bus_for_each_dev+0x6c/0xa0)
> [<c03d382c>] (bus_for_each_dev) from [<c03d4ad4>] (bus_add_driver+0x1a4/0x21c)
> [<c03d4ad4>] (bus_add_driver) from [<c03d60ac>] (driver_register+0x78/0xf8)
> [<c03d60ac>] (driver_register) from [<c0101760>] (do_one_initcall+0x40/0x170)
> [<c0101760>] (do_one_initcall) from [<c0800e38>] (kernel_init_freeable+0x1dc/0x27c)
> [<c0800e38>] (kernel_init_freeable) from [<c05d1bd4>] (kernel_init+0x8/0x114)
> [<c05d1bd4>] (kernel_init) from [<c01076f8>] (ret_from_fork+0x14/0x3c)
> ---[ end trace 059d2fbe87608fa9 ]---
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Matthew Gerlach <mgerlach@opensource.altera.com>
> Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
> Cc: David S. Miller <davem@davemloft.net>
> ---
> V2: Add missing stmmac_rst = NULL; into socfpga_dwmac_init_probe()
> ---
> .../net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 70 ++++++++++++----------
> 1 file changed, 39 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> index 76d671e..5885a2e 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> @@ -49,7 +49,6 @@ struct socfpga_dwmac {
> u32 reg_shift;
> struct device *dev;
> struct regmap *sys_mgr_base_addr;
> - struct reset_control *stmmac_rst;
> void __iomem *splitter_base;
> bool f2h_ptp_ref_clk;
> };
> @@ -92,15 +91,6 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac *dwmac, struct device *
> struct device_node *np_splitter;
> struct resource res_splitter;
>
> - dwmac->stmmac_rst = devm_reset_control_get(dev,
> - STMMAC_RESOURCE_NAME);
> - if (IS_ERR(dwmac->stmmac_rst)) {
> - dev_info(dev, "Could not get reset control!\n");
> - if (PTR_ERR(dwmac->stmmac_rst) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> - dwmac->stmmac_rst = NULL;
> - }
> -
> dwmac->interface = of_get_phy_mode(np);
>
> sys_mgr_base_addr = syscon_regmap_lookup_by_phandle(np, "altr,sysmgr-syscon");
> @@ -194,30 +184,23 @@ static int socfpga_dwmac_setup(struct socfpga_dwmac *dwmac)
> return 0;
> }
>
> -static void socfpga_dwmac_exit(struct platform_device *pdev, void *priv)
> -{
> - struct socfpga_dwmac *dwmac = priv;
> -
> - /* On socfpga platform exit, assert and hold reset to the
> - * enet controller - the default state after a hard reset.
> - */
> - if (dwmac->stmmac_rst)
> - reset_control_assert(dwmac->stmmac_rst);
> -}
> -
> static int socfpga_dwmac_init(struct platform_device *pdev, void *priv)
> {
> - struct socfpga_dwmac *dwmac = priv;
> + struct socfpga_dwmac *dwmac = priv;
> struct net_device *ndev = platform_get_drvdata(pdev);
> struct stmmac_priv *stpriv = NULL;
> int ret = 0;
>
> - if (ndev)
> - stpriv = netdev_priv(ndev);
> + if (!ndev)
> + return -EINVAL;
> +
> + stpriv = netdev_priv(ndev);
> + if (!stpriv)
> + return -EINVAL;
>
> /* Assert reset to the enet controller before changing the phy mode */
> - if (dwmac->stmmac_rst)
> - reset_control_assert(dwmac->stmmac_rst);
> + if (stpriv->stmmac_rst)
> + reset_control_assert(stpriv->stmmac_rst);
>
> /* Setup the phy mode in the system manager registers according to
> * devicetree configuration
> @@ -227,8 +210,8 @@ static int socfpga_dwmac_init(struct platform_device *pdev, void *priv)
> /* Deassert reset for the phy configuration to be sampled by
> * the enet controller, and operation to start in requested mode
> */
> - if (dwmac->stmmac_rst)
> - reset_control_deassert(dwmac->stmmac_rst);
> + if (stpriv->stmmac_rst)
> + reset_control_deassert(stpriv->stmmac_rst);
>
> /* Before the enet controller is suspended, the phy is suspended.
> * This causes the phy clock to be gated. The enet controller is
> @@ -245,12 +228,38 @@ static int socfpga_dwmac_init(struct platform_device *pdev, void *priv)
> * control register 0, and can be modified by the phy driver
> * framework.
> */
> - if (stpriv && stpriv->phydev)
> + if (stpriv->phydev)
> phy_resume(stpriv->phydev);
>
> return ret;
> }
>
> +static int socfpga_dwmac_init_probe(struct socfpga_dwmac *dwmac)
> +{
> + struct reset_control *stmmac_rst;
> + int ret;
> +
> + stmmac_rst = reset_control_get(dwmac->dev, STMMAC_RESOURCE_NAME);
> + if (IS_ERR(stmmac_rst)) {
> + dev_info(dwmac->dev, "Could not get reset control!\n");
> + if (PTR_ERR(stmmac_rst) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + stmmac_rst = NULL;
> + }
> +
> + if (stmmac_rst)
> + reset_control_assert(stmmac_rst);
> +
> + ret = socfpga_dwmac_setup(dwmac);
> +
> + if (stmmac_rst) {
> + reset_control_deassert(stmmac_rst);
> + reset_control_put(stmmac_rst);
> + }
> +
> + return ret;
> +}
I don't think you this function because...
> +
> static int socfpga_dwmac_probe(struct platform_device *pdev)
> {
> struct plat_stmmacenet_data *plat_dat;
> @@ -279,10 +288,9 @@ static int socfpga_dwmac_probe(struct platform_device *pdev)
>
> plat_dat->bsp_priv = dwmac;
> plat_dat->init = socfpga_dwmac_init;
> - plat_dat->exit = socfpga_dwmac_exit;
> plat_dat->fix_mac_speed = socfpga_dwmac_fix_mac_speed;
>
> - ret = socfpga_dwmac_init(pdev, plat_dat->bsp_priv);
> + ret = socfpga_dwmac_init_probe(dwmac);
> if (ret)
> return ret;
>
>
if you modify the patch to call stmmac_dvr_probe() before calling
socfpga_dwmac_init(), then you would already have the reset control
information.
Something like this:
---------------------------------8<--------------------------------
@@ -269,14 +252,13 @@ static int socfpga_dwmac_probe(struct
platform_device *pdev)
plat_dat->bsp_priv = dwmac;
plat_dat->init = socfpga_dwmac_init;
- plat_dat->exit = socfpga_dwmac_exit;
plat_dat->fix_mac_speed = socfpga_dwmac_fix_mac_speed;
- ret = socfpga_dwmac_init(pdev, plat_dat->bsp_priv);
- if (ret)
- return ret;
+ ret = stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
- return stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
+ if (!ret)
+ ret = socfpga_dwmac_init(pdev, plat_dat->bsp_priv);
+ return ret;
}
What do you think?
Dinh
^ permalink raw reply
* [PATCH net] atl2: Disable unimplemented scatter/gather feature
From: Ben Hutchings @ 2016-04-20 22:23 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Justin Yackoski
[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]
atl2 includes NETIF_F_SG in hw_features even though it has no support
for non-linear skbs. This bug was originally harmless since the
driver does not claim to implement checksum offload and that used to
be a requirement for SG.
Now that SG and checksum offload are independent features, if you
explicitly enable SG *and* use one of the rare protocols that can use
SG without checkusm offload, this potentially leaks sensitive
information (before you notice that it just isn't working). Therefore
this obscure bug has been designated CVE-2016-2117.
Reported-by: Justin Yackoski <jyackoski@crypto-nite.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Fixes: ec5f06156423 ("net: Kill link between CSUM and SG features.")
---
drivers/net/ethernet/atheros/atlx/atl2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/atheros/atlx/atl2.c b/drivers/net/ethernet/atheros/atlx/atl2.c
index 8f76f4558a88..2ff465848b65 100644
--- a/drivers/net/ethernet/atheros/atlx/atl2.c
+++ b/drivers/net/ethernet/atheros/atlx/atl2.c
@@ -1412,7 +1412,7 @@ static int atl2_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
err = -EIO;
- netdev->hw_features = NETIF_F_SG | NETIF_F_HW_VLAN_CTAG_RX;
+ netdev->hw_features = NETIF_F_HW_VLAN_CTAG_RX;
netdev->features |= (NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_CTAG_RX);
/* Init PHY as early as possible due to power saving issue */
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply related
* Re: [PATCH V2] net: stmmac: socfpga: Remove re-registration of reset controller
From: Marek Vasut @ 2016-04-20 22:27 UTC (permalink / raw)
To: Dinh Nguyen, netdev
Cc: peppe.cavallaro, alexandre.torgue, Matthew Gerlach,
David S . Miller
In-Reply-To: <5717F1DF.1020004@opensource.altera.com>
On 04/20/2016 11:17 PM, Dinh Nguyen wrote:
> On 04/19/2016 07:05 PM, Marek Vasut wrote:
>> Both socfpga_dwmac_parse_data() in dwmac-socfpga.c and stmmac_dvr_probe()
>> in stmmac_main.c functions call devm_reset_control_get() to register an
>> reset controller for the stmmac. This results in an attempt to register
>> two reset controllers for the same non-shared reset line.
>>
>> The first attempt to register the reset controller works fine. The second
>> attempt fails with warning from the reset controller core, see below.
>> The warning is produced because the reset line is non-shared and thus
>> it is allowed to have only up-to one reset controller associated with
>> that reset line, not two or more.
>>
>> The solution is not great. Since the hardware needs to toggle the reset
>> before calling stmmac_dvr_probe() to perform mandatory preconfiguration,
>> this patch splits socfpga_dwmac_init_probe() from socfpga_dwmac_init().
>>
>> The socfpga_dwmac_init_probe() temporarily registers the reset controller,
>> performs the pre-configuration and unregisters the reset controller again.
>> This function is only called from the socfpga_dwmac_probe().
>>
>> The original socfpga_dwmac_init() is tweaked to use reset controller
>> pointer from the stmmac_priv (private data of the stmmac core) instead
>> of the local instance, which was used before.
>>
>> Finally, plat_dat->exit and socfpga_dwmac_exit() is no longer necessary,
>> since the functionality is already performed by the stmmac core.
>>
>> ------------[ cut here ]------------
>> WARNING: CPU: 0 PID: 1 at drivers/reset/core.c:187 __of_reset_control_get+0x218/0x270
>> Modules linked in:
>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc4-next-20160419-00015-gabb2477-dirty #4
>> Hardware name: Altera SOCFPGA
>> [<c010f290>] (unwind_backtrace) from [<c010b82c>] (show_stack+0x10/0x14)
>> [<c010b82c>] (show_stack) from [<c0373da4>] (dump_stack+0x94/0xa8)
>> [<c0373da4>] (dump_stack) from [<c011bcc0>] (__warn+0xec/0x104)
>> [<c011bcc0>] (__warn) from [<c011bd88>] (warn_slowpath_null+0x20/0x28)
>> [<c011bd88>] (warn_slowpath_null) from [<c03a6eb4>] (__of_reset_control_get+0x218/0x270)
>> [<c03a6eb4>] (__of_reset_control_get) from [<c03a701c>] (__devm_reset_control_get+0x54/0x90)
>> [<c03a701c>] (__devm_reset_control_get) from [<c041fa30>] (stmmac_dvr_probe+0x1b4/0x8e8)
>> [<c041fa30>] (stmmac_dvr_probe) from [<c04298c8>] (socfpga_dwmac_probe+0x1b8/0x28c)
>> [<c04298c8>] (socfpga_dwmac_probe) from [<c03d6ffc>] (platform_drv_probe+0x4c/0xb0)
>> [<c03d6ffc>] (platform_drv_probe) from [<c03d54ec>] (driver_probe_device+0x224/0x2bc)
>> [<c03d54ec>] (driver_probe_device) from [<c03d5630>] (__driver_attach+0xac/0xb0)
>> [<c03d5630>] (__driver_attach) from [<c03d382c>] (bus_for_each_dev+0x6c/0xa0)
>> [<c03d382c>] (bus_for_each_dev) from [<c03d4ad4>] (bus_add_driver+0x1a4/0x21c)
>> [<c03d4ad4>] (bus_add_driver) from [<c03d60ac>] (driver_register+0x78/0xf8)
>> [<c03d60ac>] (driver_register) from [<c0101760>] (do_one_initcall+0x40/0x170)
>> [<c0101760>] (do_one_initcall) from [<c0800e38>] (kernel_init_freeable+0x1dc/0x27c)
>> [<c0800e38>] (kernel_init_freeable) from [<c05d1bd4>] (kernel_init+0x8/0x114)
>> [<c05d1bd4>] (kernel_init) from [<c01076f8>] (ret_from_fork+0x14/0x3c)
>> ---[ end trace 059d2fbe87608fa9 ]---
>>
>> Signed-off-by: Marek Vasut <marex@denx.de>
>> Cc: Matthew Gerlach <mgerlach@opensource.altera.com>
>> Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
>> Cc: David S. Miller <davem@davemloft.net>
>> ---
>> V2: Add missing stmmac_rst = NULL; into socfpga_dwmac_init_probe()
>> ---
>> .../net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 70 ++++++++++++----------
>> 1 file changed, 39 insertions(+), 31 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
>> index 76d671e..5885a2e 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
>> @@ -49,7 +49,6 @@ struct socfpga_dwmac {
>> u32 reg_shift;
>> struct device *dev;
>> struct regmap *sys_mgr_base_addr;
>> - struct reset_control *stmmac_rst;
>> void __iomem *splitter_base;
>> bool f2h_ptp_ref_clk;
>> };
>> @@ -92,15 +91,6 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac *dwmac, struct device *
>> struct device_node *np_splitter;
>> struct resource res_splitter;
>>
>> - dwmac->stmmac_rst = devm_reset_control_get(dev,
>> - STMMAC_RESOURCE_NAME);
>> - if (IS_ERR(dwmac->stmmac_rst)) {
>> - dev_info(dev, "Could not get reset control!\n");
>> - if (PTR_ERR(dwmac->stmmac_rst) == -EPROBE_DEFER)
>> - return -EPROBE_DEFER;
>> - dwmac->stmmac_rst = NULL;
>> - }
>> -
>> dwmac->interface = of_get_phy_mode(np);
>>
>> sys_mgr_base_addr = syscon_regmap_lookup_by_phandle(np, "altr,sysmgr-syscon");
>> @@ -194,30 +184,23 @@ static int socfpga_dwmac_setup(struct socfpga_dwmac *dwmac)
>> return 0;
>> }
>>
>> -static void socfpga_dwmac_exit(struct platform_device *pdev, void *priv)
>> -{
>> - struct socfpga_dwmac *dwmac = priv;
>> -
>> - /* On socfpga platform exit, assert and hold reset to the
>> - * enet controller - the default state after a hard reset.
>> - */
>> - if (dwmac->stmmac_rst)
>> - reset_control_assert(dwmac->stmmac_rst);
>> -}
>> -
>> static int socfpga_dwmac_init(struct platform_device *pdev, void *priv)
>> {
>> - struct socfpga_dwmac *dwmac = priv;
>> + struct socfpga_dwmac *dwmac = priv;
>> struct net_device *ndev = platform_get_drvdata(pdev);
>> struct stmmac_priv *stpriv = NULL;
>> int ret = 0;
>>
>> - if (ndev)
>> - stpriv = netdev_priv(ndev);
>> + if (!ndev)
>> + return -EINVAL;
>> +
>> + stpriv = netdev_priv(ndev);
>> + if (!stpriv)
>> + return -EINVAL;
>>
>> /* Assert reset to the enet controller before changing the phy mode */
>> - if (dwmac->stmmac_rst)
>> - reset_control_assert(dwmac->stmmac_rst);
>> + if (stpriv->stmmac_rst)
>> + reset_control_assert(stpriv->stmmac_rst);
>>
>> /* Setup the phy mode in the system manager registers according to
>> * devicetree configuration
>> @@ -227,8 +210,8 @@ static int socfpga_dwmac_init(struct platform_device *pdev, void *priv)
>> /* Deassert reset for the phy configuration to be sampled by
>> * the enet controller, and operation to start in requested mode
>> */
>> - if (dwmac->stmmac_rst)
>> - reset_control_deassert(dwmac->stmmac_rst);
>> + if (stpriv->stmmac_rst)
>> + reset_control_deassert(stpriv->stmmac_rst);
>>
>> /* Before the enet controller is suspended, the phy is suspended.
>> * This causes the phy clock to be gated. The enet controller is
>> @@ -245,12 +228,38 @@ static int socfpga_dwmac_init(struct platform_device *pdev, void *priv)
>> * control register 0, and can be modified by the phy driver
>> * framework.
>> */
>> - if (stpriv && stpriv->phydev)
>> + if (stpriv->phydev)
>> phy_resume(stpriv->phydev);
>>
>> return ret;
>> }
>>
>> +static int socfpga_dwmac_init_probe(struct socfpga_dwmac *dwmac)
>> +{
>> + struct reset_control *stmmac_rst;
>> + int ret;
>> +
>> + stmmac_rst = reset_control_get(dwmac->dev, STMMAC_RESOURCE_NAME);
>> + if (IS_ERR(stmmac_rst)) {
>> + dev_info(dwmac->dev, "Could not get reset control!\n");
>> + if (PTR_ERR(stmmac_rst) == -EPROBE_DEFER)
>> + return -EPROBE_DEFER;
>> + stmmac_rst = NULL;
>> + }
>> +
>> + if (stmmac_rst)
>> + reset_control_assert(stmmac_rst);
>> +
>> + ret = socfpga_dwmac_setup(dwmac);
>> +
>> + if (stmmac_rst) {
>> + reset_control_deassert(stmmac_rst);
>> + reset_control_put(stmmac_rst);
>> + }
>> +
>> + return ret;
>> +}
>
> I don't think you this function because...
>
>> +
>> static int socfpga_dwmac_probe(struct platform_device *pdev)
>> {
>> struct plat_stmmacenet_data *plat_dat;
>> @@ -279,10 +288,9 @@ static int socfpga_dwmac_probe(struct platform_device *pdev)
>>
>> plat_dat->bsp_priv = dwmac;
>> plat_dat->init = socfpga_dwmac_init;
>> - plat_dat->exit = socfpga_dwmac_exit;
>> plat_dat->fix_mac_speed = socfpga_dwmac_fix_mac_speed;
>>
>> - ret = socfpga_dwmac_init(pdev, plat_dat->bsp_priv);
>> + ret = socfpga_dwmac_init_probe(dwmac);
>> if (ret)
>> return ret;
>>
>>
>
> if you modify the patch to call stmmac_dvr_probe() before calling
> socfpga_dwmac_init(), then you would already have the reset control
> information.
I was under the impression that you must call socfpga_dwmac_init()
before stmmac_dvr_probe() for whatever hardware-related reason. If
you are absolutely certain this is not necessary, then that's just
perfect and the patch can be simplified even further -- just remove
the call to socfpga_dwmac_init() from probe altogether , the dwmac
core code will call plat_dat->init at the end of probe .
So shall we do that ? I am happy to spin V3 like that if you confirm
that it's legal to do things in the aforementioned order.
> Something like this:
>
> ---------------------------------8<--------------------------------
>
> @@ -269,14 +252,13 @@ static int socfpga_dwmac_probe(struct
> platform_device *pdev)
>
> plat_dat->bsp_priv = dwmac;
> plat_dat->init = socfpga_dwmac_init;
> - plat_dat->exit = socfpga_dwmac_exit;
> plat_dat->fix_mac_speed = socfpga_dwmac_fix_mac_speed;
>
> - ret = socfpga_dwmac_init(pdev, plat_dat->bsp_priv);
> - if (ret)
> - return ret;
> + ret = stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
>
> - return stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
> + if (!ret)
> + ret = socfpga_dwmac_init(pdev, plat_dat->bsp_priv);
> + return ret;
> }
>
>
> What do you think?
> Dinh
>
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: qdisc spin lock
From: Eric Dumazet @ 2016-04-20 22:34 UTC (permalink / raw)
To: Michael Ma; +Cc: Cong Wang, Linux Kernel Network Developers
In-Reply-To: <CAAmHdhzAEG-oXsA0P1mEJfseBTUdU7X_bEhgvkCLOLcqOHcQSw@mail.gmail.com>
On Wed, 2016-04-20 at 14:24 -0700, Michael Ma wrote:
> 2016-04-08 7:19 GMT-07:00 Eric Dumazet <eric.dumazet@gmail.com>:
> > On Thu, 2016-03-31 at 16:48 -0700, Michael Ma wrote:
> >> I didn't really know that multiple qdiscs can be isolated using MQ so
> >> that each txq can be associated with a particular qdisc. Also we don't
> >> really have multiple interfaces...
> >>
> >> With this MQ solution we'll still need to assign transmit queues to
> >> different classes by doing some math on the bandwidth limit if I
> >> understand correctly, which seems to be less convenient compared with
> >> a solution purely within HTB.
> >>
> >> I assume that with this solution I can still share qdisc among
> >> multiple transmit queues - please let me know if this is not the case.
> >
> > Note that this MQ + HTB thing works well, unless you use a bonding
> > device. (Or you need the MQ+HTB on the slaves, with no way of sharing
> > tokens between the slaves)
>
> Actually MQ+HTB works well for small packets - like flow of 512 byte
> packets can be throttled by HTB using one txq without being affected
> by other flows with small packets. However I found using this solution
> large packets (10k for example) will only achieve very limited
> bandwidth. In my test I used MQ to assign one txq to a HTB which sets
> rate at 1Gbit/s, 512 byte packets can achieve the ceiling rate by
> using 30 threads. But sending 10k packets using 10 threads has only 10
> Mbit/s with the same TC configuration. If I increase burst and cburst
> of HTB to some extreme large value (like 50MB) the ceiling rate can be
> hit.
>
> The strange thing is that I don't see this problem when using HTB as
> the root. So txq number seems to be a factor here - however it's
> really hard to understand why would it only affect larger packets. Is
> this a known issue? Any suggestion on how to investigate the issue
> further? Profiling shows that the cpu utilization is pretty low.
You could try
perf record -a -g -e skb:kfree_skb sleep 5
perf report
So that you see where the packets are dropped.
Chances are that your UDP sockets SO_SNDBUF is too big, and packets are
dropped at qdisc enqueue time, instead of having backpressure.
^ permalink raw reply
* linux-next: zillions of lockdep whinges in include/net/sock.h:1408
From: Valdis Kletnieks @ 2016-04-21 0:30 UTC (permalink / raw)
To: Hannes Frederic Sowa, David S. Miller; +Cc: netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2126 bytes --]
linux-next 20160420 is whining at an incredible rate - in 20 minutes of
uptime, I piled up some 41,000 hits from all over the place (cleaned up
to skip the CPU and PID so the list isn't quite so long):
% grep include/net/sock.h /var/log/messages | cut -f5- -d: | sed -e 's/PID: [0-9]* /PID: (elided) /' -e 's/CPU: [0-3]/CPU: +/' | sort | uniq -c | sort -nr
13468 CPU: + PID: (elided) at include/net/sock.h:1408 tcp_v6_rcv+0xc20/0xcb0
9770 CPU: + PID: (elided) at include/net/sock.h:1408 udp_queue_rcv_skb+0x3ca/0x6d0
7706 CPU: + PID: (elided) at include/net/sock.h:1408 sock_owned_by_user+0x91/0xa0
2818 CPU: + PID: (elided) at include/net/sock.h:1408 udpv6_queue_rcv_skb+0x3b6/0x6d0
1981 CPU: + PID: (elided) at include/net/sock.h:1408 tcp_write_timer+0xf2/0x110
1954 CPU: + PID: (elided) at include/net/sock.h:1408 tcp_delack_timer+0x110/0x130
1912 CPU: + PID: (elided) at include/net/sock.h:1408 tcp_keepalive_timer+0x136/0x2c0
882 CPU: + PID: (elided) at include/net/sock.h:1408 tcp_close+0x226/0x4f0
804 CPU: + PID: (elided) at include/net/sock.h:1408 tcp_tasklet_func+0x192/0x1e0
28 CPU: + PID: (elided) at include/net/sock.h:1408 tcp_child_process+0x17a/0x350
2 CPU: + PID: (elided) at include/net/sock.h:1408 tcp_v6_err+0x401/0x660
2 CPU: + PID: (elided) at include/net/sock.h:1408 tcp_v6_err+0x1fd/0x660
Seems to be from this commit, which is apparently over-stringent or
isn't handling some case correctly:
commit fafc4e1ea1a4c1eb13a30c9426fb799f5efacbc3
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Fri Apr 8 15:11:27 2016 +0200
sock: tigthen lockdep checks for sock_owned_by_user
sock_owned_by_user should not be used without socket lock held. It seems
to be a common practice to check .owned before lock reclassification, so
provide a little help to abstract this check away.
Cc: linux-cifs@vger.kernel.org
Cc: linux-bluetooth@vger.kernel.org
Cc: linux-nfs@vger.kernel.org
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
[-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --]
^ permalink raw reply
* Re: [PATCH net 4/4] net/mlx4_en: Split SW RX dropped counter per RX ring
From: Eric Dumazet @ 2016-04-21 1:02 UTC (permalink / raw)
To: Or Gerlitz
Cc: David S. Miller, netdev, Eran Ben Elisha, Yishai Hadas,
Saeed Mahameed
In-Reply-To: <571799A3.402@mellanox.com>
On Wed, 2016-04-20 at 18:00 +0300, Or Gerlitz wrote:
> Just to be sure, you'd like me to re-spin this and fix the reporter name?
Absolutely not, I believe patchwork should handle this just fine.
Patchwork does not understand the "Fixes:" tag yet, but Reported-by: is
fine.
^ permalink raw reply
* [PATCH net] Driver: Vmxnet3: set CHECKSUM_UNNECESSARY for IPv6 packets
From: Shrikrishna Khare @ 2016-04-21 1:12 UTC (permalink / raw)
To: netdev, linux-kernel, pv-drivers; +Cc: Shrikrishna Khare, Jin Heo
For IPv6, if the device indicates that the checksum is correct, set
CHECKSUM_UNNECESSARY.
Reported-by: Subbarao Narahari <snarahari@vmware.com>
Signed-off-by: Shrikrishna Khare <skhare@vmware.com>
Signed-off-by: Jin Heo <heoj@vmware.com>
---
drivers/net/vmxnet3/vmxnet3_drv.c | 12 ++++++++----
drivers/net/vmxnet3/vmxnet3_int.h | 4 ++--
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index fc895d0..4a67e4f 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -1152,12 +1152,16 @@ vmxnet3_rx_csum(struct vmxnet3_adapter *adapter,
union Vmxnet3_GenericDesc *gdesc)
{
if (!gdesc->rcd.cnc && adapter->netdev->features & NETIF_F_RXCSUM) {
- /* typical case: TCP/UDP over IP and both csums are correct */
- if ((le32_to_cpu(gdesc->dword[3]) & VMXNET3_RCD_CSUM_OK) ==
- VMXNET3_RCD_CSUM_OK) {
+ if (gdesc->rcd.v4 &&
+ (le32_to_cpu(gdesc->dword[3]) &
+ VMXNET3_RCD_CSUM_OK) == VMXNET3_RCD_CSUM_OK) {
+ skb->ip_summed = CHECKSUM_UNNECESSARY;
+ BUG_ON(!(gdesc->rcd.tcp || gdesc->rcd.udp));
+ BUG_ON(gdesc->rcd.frg);
+ } else if (gdesc->rcd.v6 && (le32_to_cpu(gdesc->dword[3]) &
+ (1 << VMXNET3_RCD_TUC_SHIFT))) {
skb->ip_summed = CHECKSUM_UNNECESSARY;
BUG_ON(!(gdesc->rcd.tcp || gdesc->rcd.udp));
- BUG_ON(!(gdesc->rcd.v4 || gdesc->rcd.v6));
BUG_ON(gdesc->rcd.frg);
} else {
if (gdesc->rcd.csum) {
diff --git a/drivers/net/vmxnet3/vmxnet3_int.h b/drivers/net/vmxnet3/vmxnet3_int.h
index 729c344..c482539 100644
--- a/drivers/net/vmxnet3/vmxnet3_int.h
+++ b/drivers/net/vmxnet3/vmxnet3_int.h
@@ -69,10 +69,10 @@
/*
* Version numbers
*/
-#define VMXNET3_DRIVER_VERSION_STRING "1.4.6.0-k"
+#define VMXNET3_DRIVER_VERSION_STRING "1.4.7.0-k"
/* a 32-bit int, each byte encode a verion number in VMXNET3_DRIVER_VERSION */
-#define VMXNET3_DRIVER_VERSION_NUM 0x01040600
+#define VMXNET3_DRIVER_VERSION_NUM 0x01040700
#if defined(CONFIG_PCI_MSI)
/* RSS only makes sense if MSI-X is supported. */
--
1.9.1
^ permalink raw reply related
* [PATCH net] openvswitch: use flow protocol when recalculating ipv6 checksums
From: Simon Horman @ 2016-04-21 1:49 UTC (permalink / raw)
To: Pravin Shelar, David Miller
Cc: Jesse Gross, netdev, dev, Simon Horman, Jarno Rajahalme
When using masked actions the ipv6_proto field of an action
to set IPv6 fields may be zero rather than the prevailing protocol
which will result in skipping checksum recalculation.
This patch resolves the problem by relying on the protocol
in the flow key rather than that in the set field action.
Fixes: 83d2b9ba1abc ("net: openvswitch: Support masked set actions.")
Cc: Jarno Rajahalme <jrajahalme@nicira.com>
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
* Found using tcpdump to examine the checksums of packets.
* I believe a similar fix is required for the user-space implementation
of the datapath. I plan to look into that unless someone else wishes to.
---
net/openvswitch/actions.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
index e9dd47b2a85b..879185fe183f 100644
--- a/net/openvswitch/actions.c
+++ b/net/openvswitch/actions.c
@@ -461,7 +461,7 @@ static int set_ipv6(struct sk_buff *skb, struct sw_flow_key *flow_key,
mask_ipv6_addr(saddr, key->ipv6_src, mask->ipv6_src, masked);
if (unlikely(memcmp(saddr, masked, sizeof(masked)))) {
- set_ipv6_addr(skb, key->ipv6_proto, saddr, masked,
+ set_ipv6_addr(skb, flow_key->ip.proto, saddr, masked,
true);
memcpy(&flow_key->ipv6.addr.src, masked,
sizeof(flow_key->ipv6.addr.src));
@@ -483,7 +483,7 @@ static int set_ipv6(struct sk_buff *skb, struct sw_flow_key *flow_key,
NULL, &flags)
!= NEXTHDR_ROUTING);
- set_ipv6_addr(skb, key->ipv6_proto, daddr, masked,
+ set_ipv6_addr(skb, flow_key->ip.proto, daddr, masked,
recalc_csum);
memcpy(&flow_key->ipv6.addr.dst, masked,
sizeof(flow_key->ipv6.addr.dst));
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* IPv6 patch mysteriously breaks IPv4 VPN
From: Valdis Kletnieks @ 2016-04-21 2:24 UTC (permalink / raw)
To: bjorn, David S. Miller; +Cc: netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 3699 bytes --]
I'll say up front - no, I do *not* have a clue why this commit causes this
problem - it makes exactly zero fsking sense.
Scenario: $WORK is blessed with a Juniper VPN system. I've been
seeing for a while now (since Dec-ish) an issue where at startup,
the tun0 device will get wedged. ifconfig reports this:
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1400
inet 172.27.1.165 netmask 255.255.255.255 destination 172.27.1.165
inet6 fe80::6802:d95c:f3f4:2a6f prefixlen 64 scopeid 0x20<link>
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 48 (48.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
and no more packets cross - not even a ping.
Yes, the tunnel is ipv4 only, and only ipv4 routes get set by the VPN software.
bisect results confirmed - linux-next 20160327 is bad, but 20160420 with this
one conmmit reverted works.
% git bisect bad
cc9da6cc4f56e05cc9e591459fe0192727ff58b3 is the first bad commit
commit cc9da6cc4f56e05cc9e591459fe0192727ff58b3
Author: Bjørn Mork <bjorn@mork.no>
Date: Wed Dec 16 16:44:38 2015 +0100
ipv6: addrconf: use stable address generator for ARPHRD_NONE
Add a new address generator mode, using the stable address generator
with an automatically generated secret. This is intended as a default
address generator mode for device types with no EUI64 implementation.
The new generator is used for ARPHRD_NONE interfaces initially, adding
default IPv6 autoconf support to e.g. tun interfaces.
If the addrgenmode is set to 'random', either by default or manually,
and no stable secret is available, then a random secret is used as
input for the stable-privacy address generator. The secret can be
read and modified like manually configured secrets, using the proc
interface. Modifying the secret will change the addrgen mode to
'stable-privacy' to indicate that it operates on a known secret.
Existing behaviour of the 'stable-privacy' mode is kept unchanged. If
a known secret is available when the device is created, then the mode
will default to 'stable-privacy' as before. The mode can be manually
set to 'random' but it will behave exactly like 'stable-privacy' in
this case. The secret will not change.
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: åè¤è±æ <hideaki.yoshifuji@miraclelinux.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
(Sorry for the delay in reporting this - bisecting this proved to be
a bear and a half, because this problematic commit landed only about 10 commits after
this one:
git bisect start
# good: [1bd4978a88ac2589f3105f599b1d404a312fb7f6] tun: honor IFF_UP in tun_get_user()
which fixed a *different* issue that prevented the tun device from getting
created at all (or it was immediately taken back down by the VPN software).
End result was that unless I gave a "known good" start point in that dozen
commit range, there's be a month's worth of 'git commit skip' to wade through.
I got damned lucky and found a record on one of my servers of an ssh over VPN,
and correlated it to the one day that linux-next had the above fix for the
previous issue, and wasn't broken by this current issue....)
[-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --]
^ permalink raw reply
* Re: [PATCH V2] net: stmmac: socfpga: Remove re-registration of reset controller
From: Dinh Nguyen @ 2016-04-21 2:44 UTC (permalink / raw)
To: Marek Vasut, netdev
Cc: peppe.cavallaro, alexandre.torgue, Matthew Gerlach,
David S . Miller
In-Reply-To: <5718023F.1060707@denx.de>
On 04/20/2016 05:27 PM, Marek Vasut wrote:
> On 04/20/2016 11:17 PM, Dinh Nguyen wrote:
>> On 04/19/2016 07:05 PM, Marek Vasut wrote:
>>> Both socfpga_dwmac_parse_data() in dwmac-socfpga.c and stmmac_dvr_probe()
>>> in stmmac_main.c functions call devm_reset_control_get() to register an
>>> reset controller for the stmmac. This results in an attempt to register
>>> two reset controllers for the same non-shared reset line.
>>>
>>> The first attempt to register the reset controller works fine. The second
>>> attempt fails with warning from the reset controller core, see below.
>>> The warning is produced because the reset line is non-shared and thus
>>> it is allowed to have only up-to one reset controller associated with
>>> that reset line, not two or more.
>>>
>>> The solution is not great. Since the hardware needs to toggle the reset
>>> before calling stmmac_dvr_probe() to perform mandatory preconfiguration,
>>> this patch splits socfpga_dwmac_init_probe() from socfpga_dwmac_init().
>>>
>>> The socfpga_dwmac_init_probe() temporarily registers the reset controller,
>>> performs the pre-configuration and unregisters the reset controller again.
>>> This function is only called from the socfpga_dwmac_probe().
>>>
>>> The original socfpga_dwmac_init() is tweaked to use reset controller
>>> pointer from the stmmac_priv (private data of the stmmac core) instead
>>> of the local instance, which was used before.
>>>
>>> Finally, plat_dat->exit and socfpga_dwmac_exit() is no longer necessary,
>>> since the functionality is already performed by the stmmac core.
>>>
>>> ------------[ cut here ]------------
>>> WARNING: CPU: 0 PID: 1 at drivers/reset/core.c:187 __of_reset_control_get+0x218/0x270
>>> Modules linked in:
>>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc4-next-20160419-00015-gabb2477-dirty #4
>>> Hardware name: Altera SOCFPGA
>>> [<c010f290>] (unwind_backtrace) from [<c010b82c>] (show_stack+0x10/0x14)
>>> [<c010b82c>] (show_stack) from [<c0373da4>] (dump_stack+0x94/0xa8)
>>> [<c0373da4>] (dump_stack) from [<c011bcc0>] (__warn+0xec/0x104)
>>> [<c011bcc0>] (__warn) from [<c011bd88>] (warn_slowpath_null+0x20/0x28)
>>> [<c011bd88>] (warn_slowpath_null) from [<c03a6eb4>] (__of_reset_control_get+0x218/0x270)
>>> [<c03a6eb4>] (__of_reset_control_get) from [<c03a701c>] (__devm_reset_control_get+0x54/0x90)
>>> [<c03a701c>] (__devm_reset_control_get) from [<c041fa30>] (stmmac_dvr_probe+0x1b4/0x8e8)
>>> [<c041fa30>] (stmmac_dvr_probe) from [<c04298c8>] (socfpga_dwmac_probe+0x1b8/0x28c)
>>> [<c04298c8>] (socfpga_dwmac_probe) from [<c03d6ffc>] (platform_drv_probe+0x4c/0xb0)
>>> [<c03d6ffc>] (platform_drv_probe) from [<c03d54ec>] (driver_probe_device+0x224/0x2bc)
>>> [<c03d54ec>] (driver_probe_device) from [<c03d5630>] (__driver_attach+0xac/0xb0)
>>> [<c03d5630>] (__driver_attach) from [<c03d382c>] (bus_for_each_dev+0x6c/0xa0)
>>> [<c03d382c>] (bus_for_each_dev) from [<c03d4ad4>] (bus_add_driver+0x1a4/0x21c)
>>> [<c03d4ad4>] (bus_add_driver) from [<c03d60ac>] (driver_register+0x78/0xf8)
>>> [<c03d60ac>] (driver_register) from [<c0101760>] (do_one_initcall+0x40/0x170)
>>> [<c0101760>] (do_one_initcall) from [<c0800e38>] (kernel_init_freeable+0x1dc/0x27c)
>>> [<c0800e38>] (kernel_init_freeable) from [<c05d1bd4>] (kernel_init+0x8/0x114)
>>> [<c05d1bd4>] (kernel_init) from [<c01076f8>] (ret_from_fork+0x14/0x3c)
>>> ---[ end trace 059d2fbe87608fa9 ]---
>>>
>>> Signed-off-by: Marek Vasut <marex@denx.de>
>>> Cc: Matthew Gerlach <mgerlach@opensource.altera.com>
>>> Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
>>> Cc: David S. Miller <davem@davemloft.net>
>>> ---
>>> V2: Add missing stmmac_rst = NULL; into socfpga_dwmac_init_probe()
>>> ---
>>> .../net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 70 ++++++++++++----------
>>> 1 file changed, 39 insertions(+), 31 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
>>> index 76d671e..5885a2e 100644
>>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
>>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
>>> @@ -49,7 +49,6 @@ struct socfpga_dwmac {
>>> u32 reg_shift;
>>> struct device *dev;
>>> struct regmap *sys_mgr_base_addr;
>>> - struct reset_control *stmmac_rst;
>>> void __iomem *splitter_base;
>>> bool f2h_ptp_ref_clk;
>>> };
>>> @@ -92,15 +91,6 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac *dwmac, struct device *
>>> struct device_node *np_splitter;
>>> struct resource res_splitter;
>>>
>>> - dwmac->stmmac_rst = devm_reset_control_get(dev,
>>> - STMMAC_RESOURCE_NAME);
>>> - if (IS_ERR(dwmac->stmmac_rst)) {
>>> - dev_info(dev, "Could not get reset control!\n");
>>> - if (PTR_ERR(dwmac->stmmac_rst) == -EPROBE_DEFER)
>>> - return -EPROBE_DEFER;
>>> - dwmac->stmmac_rst = NULL;
>>> - }
>>> -
>>> dwmac->interface = of_get_phy_mode(np);
>>>
>>> sys_mgr_base_addr = syscon_regmap_lookup_by_phandle(np, "altr,sysmgr-syscon");
>>> @@ -194,30 +184,23 @@ static int socfpga_dwmac_setup(struct socfpga_dwmac *dwmac)
>>> return 0;
>>> }
>>>
>>> -static void socfpga_dwmac_exit(struct platform_device *pdev, void *priv)
>>> -{
>>> - struct socfpga_dwmac *dwmac = priv;
>>> -
>>> - /* On socfpga platform exit, assert and hold reset to the
>>> - * enet controller - the default state after a hard reset.
>>> - */
>>> - if (dwmac->stmmac_rst)
>>> - reset_control_assert(dwmac->stmmac_rst);
>>> -}
>>> -
>>> static int socfpga_dwmac_init(struct platform_device *pdev, void *priv)
>>> {
>>> - struct socfpga_dwmac *dwmac = priv;
>>> + struct socfpga_dwmac *dwmac = priv;
>>> struct net_device *ndev = platform_get_drvdata(pdev);
>>> struct stmmac_priv *stpriv = NULL;
>>> int ret = 0;
>>>
>>> - if (ndev)
>>> - stpriv = netdev_priv(ndev);
>>> + if (!ndev)
>>> + return -EINVAL;
>>> +
>>> + stpriv = netdev_priv(ndev);
>>> + if (!stpriv)
>>> + return -EINVAL;
>>>
>>> /* Assert reset to the enet controller before changing the phy mode */
>>> - if (dwmac->stmmac_rst)
>>> - reset_control_assert(dwmac->stmmac_rst);
>>> + if (stpriv->stmmac_rst)
>>> + reset_control_assert(stpriv->stmmac_rst);
>>>
>>> /* Setup the phy mode in the system manager registers according to
>>> * devicetree configuration
>>> @@ -227,8 +210,8 @@ static int socfpga_dwmac_init(struct platform_device *pdev, void *priv)
>>> /* Deassert reset for the phy configuration to be sampled by
>>> * the enet controller, and operation to start in requested mode
>>> */
>>> - if (dwmac->stmmac_rst)
>>> - reset_control_deassert(dwmac->stmmac_rst);
>>> + if (stpriv->stmmac_rst)
>>> + reset_control_deassert(stpriv->stmmac_rst);
>>>
>>> /* Before the enet controller is suspended, the phy is suspended.
>>> * This causes the phy clock to be gated. The enet controller is
>>> @@ -245,12 +228,38 @@ static int socfpga_dwmac_init(struct platform_device *pdev, void *priv)
>>> * control register 0, and can be modified by the phy driver
>>> * framework.
>>> */
>>> - if (stpriv && stpriv->phydev)
>>> + if (stpriv->phydev)
>>> phy_resume(stpriv->phydev);
>>>
>>> return ret;
>>> }
>>>
>>> +static int socfpga_dwmac_init_probe(struct socfpga_dwmac *dwmac)
>>> +{
>>> + struct reset_control *stmmac_rst;
>>> + int ret;
>>> +
>>> + stmmac_rst = reset_control_get(dwmac->dev, STMMAC_RESOURCE_NAME);
>>> + if (IS_ERR(stmmac_rst)) {
>>> + dev_info(dwmac->dev, "Could not get reset control!\n");
>>> + if (PTR_ERR(stmmac_rst) == -EPROBE_DEFER)
>>> + return -EPROBE_DEFER;
>>> + stmmac_rst = NULL;
>>> + }
>>> +
>>> + if (stmmac_rst)
>>> + reset_control_assert(stmmac_rst);
>>> +
>>> + ret = socfpga_dwmac_setup(dwmac);
>>> +
>>> + if (stmmac_rst) {
>>> + reset_control_deassert(stmmac_rst);
>>> + reset_control_put(stmmac_rst);
>>> + }
>>> +
>>> + return ret;
>>> +}
>>
>> I don't think you this function because...
>>
>>> +
>>> static int socfpga_dwmac_probe(struct platform_device *pdev)
>>> {
>>> struct plat_stmmacenet_data *plat_dat;
>>> @@ -279,10 +288,9 @@ static int socfpga_dwmac_probe(struct platform_device *pdev)
>>>
>>> plat_dat->bsp_priv = dwmac;
>>> plat_dat->init = socfpga_dwmac_init;
>>> - plat_dat->exit = socfpga_dwmac_exit;
>>> plat_dat->fix_mac_speed = socfpga_dwmac_fix_mac_speed;
>>>
>>> - ret = socfpga_dwmac_init(pdev, plat_dat->bsp_priv);
>>> + ret = socfpga_dwmac_init_probe(dwmac);
>>> if (ret)
>>> return ret;
>>>
>>>
>>
>> if you modify the patch to call stmmac_dvr_probe() before calling
>> socfpga_dwmac_init(), then you would already have the reset control
>> information.
>
> I was under the impression that you must call socfpga_dwmac_init()
> before stmmac_dvr_probe() for whatever hardware-related reason. If
> you are absolutely certain this is not necessary, then that's just
> perfect and the patch can be simplified even further -- just remove
> the call to socfpga_dwmac_init() from probe altogether , the dwmac
> core code will call plat_dat->init at the end of probe .
>
> So shall we do that ? I am happy to spin V3 like that if you confirm
> that it's legal to do things in the aforementioned order.
>
AFAICT, I don't see any reason why the socfpga_dwmac_init() has to go
before the stmmac_dvr_probe(). I tested this by using U-Boot to put the
PHY modes in the system manager into a different mode, and put the
ethernet IP into reset. Linux was able to use ethernet just fine with
the aformentioned order.
So yes, please spin V3.
Thanks,
Dinh
^ permalink raw reply
* [PATCH net v2 0/3] drivers: net: cpsw: phy-handle fixes
From: David Rivshin (Allworx) @ 2016-04-21 3:51 UTC (permalink / raw)
To: netdev, linux-omap
Cc: linux-arm-kernel, devicetree, linux-kernel, David Miller,
Mugunthan V N, Grygorii Strashko, Andrew Goodbody, Markus Brunner,
Nicolas Chauvet
From: David Rivshin <drivshin@allworx.com>
The first patch fixes a bug that makes dual_emac mode break if
either slave uses the phy-handle property in the devicetree.
The second patch fixes some cosmetic problems with error messages,
and also makes the binding documentation more explicit.
The third patch cleans up the fixed-link case to work like
the now-fixed phy-handle case.
I have tested on the following hardware configurations:
- (EVMSK) dual emac, phy_id property in both slaves
- (EVMSK) dual emac, phy-handle property in both slaves
- (BeagleBoneBlack) single emac, phy_id property
- (custom) single emac, fixed-link subnode
Nicolas Chauvet reported testing on an HP t410 (dm8148).
Markus Brunner reported testing v1 on the following [1]:
- emac0 with phy_id and emac1 with fixed phy
- emac0 with phy-handle and emac1 with fixed phy
- emac0 with fixed phy and emac1 with fixed phy
Changes since v1 [2]:
- Rebased
- Added Tested-by from Nicolas Chauvet on all patches
- Added Acked-by from Rob Herring for the binding change in patch 2 [3]
[1] http://www.spinics.net/lists/netdev/msg357890.html
[2] http://www.spinics.net/lists/netdev/msg357772.html
[3] http://www.spinics.net/lists/netdev/msg358254.html
David Rivshin (3):
drivers: net: cpsw: fix parsing of phy-handle DT property in dual_emac
config
drivers: net: cpsw: fix error messages when using phy-handle DT
property
drivers: net: cpsw: use of_phy_connect() in fixed-link case
Documentation/devicetree/bindings/net/cpsw.txt | 4 +--
drivers/net/ethernet/ti/cpsw.c | 41 +++++++++++++-------------
drivers/net/ethernet/ti/cpsw.h | 1 +
3 files changed, 23 insertions(+), 23 deletions(-)
--
2.5.5
^ permalink raw reply
* [PATCH net v2 0/3] drivers: net: cpsw: phy-handle fixes
From: David Rivshin (Allworx) @ 2016-04-21 4:00 UTC (permalink / raw)
To: netdev, linux-omap
Cc: devicetree, Mugunthan V N, Grygorii Strashko, Markus Brunner,
Nicolas Chauvet
From: David Rivshin <drivshin@allworx.com>
The first patch fixes a bug that makes dual_emac mode break if
either slave uses the phy-handle property in the devicetree.
The second patch fixes some cosmetic problems with error messages,
and also makes the binding documentation more explicit.
The third patch cleans up the fixed-link case to work like
the now-fixed phy-handle case.
I have tested on the following hardware configurations:
- (EVMSK) dual emac, phy_id property in both slaves
- (EVMSK) dual emac, phy-handle property in both slaves
- (BeagleBoneBlack) single emac, phy_id property
- (custom) single emac, fixed-link subnode
Nicolas Chauvet reported testing on an HP t410 (dm8148).
Markus Brunner reported testing v1 on the following [1]:
- emac0 with phy_id and emac1 with fixed phy
- emac0 with phy-handle and emac1 with fixed phy
- emac0 with fixed phy and emac1 with fixed phy
Changes since v1 [2]:
- Rebased
- Added Tested-by from Nicolas Chauvet on all patches
- Added Acked-by from Rob Herring for the binding change in patch 2 [3]
[1] http://www.spinics.net/lists/netdev/msg357890.html
[2] http://www.spinics.net/lists/netdev/msg357772.html
[3] http://www.spinics.net/lists/netdev/msg358254.html
David Rivshin (3):
drivers: net: cpsw: fix parsing of phy-handle DT property in dual_emac
config
drivers: net: cpsw: fix error messages when using phy-handle DT
property
drivers: net: cpsw: use of_phy_connect() in fixed-link case
Documentation/devicetree/bindings/net/cpsw.txt | 4 +--
drivers/net/ethernet/ti/cpsw.c | 41 +++++++++++++-------------
drivers/net/ethernet/ti/cpsw.h | 1 +
3 files changed, 23 insertions(+), 23 deletions(-)
--
2.5.5
^ permalink raw reply
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