* [PATCH 3/8] can: m_can: tag current CAN FD controllers as non-ISO
From: Marc Kleine-Budde @ 2015-01-15 16:11 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Oliver Hartkopp, linux-stable,
Marc Kleine-Budde
In-Reply-To: <1421338283-12417-1-git-send-email-mkl@pengutronix.de>
From: Oliver Hartkopp <socketcan@hartkopp.net>
During the CAN FD standardization process within the ISO it turned out that
the failure detection capability has to be improved.
The CAN in Automation organization (CiA) defined the already implemented CAN
FD controllers as 'non-ISO' and the upcoming improved CAN FD controllers as
'ISO' compliant. See at http://www.can-cia.com/index.php?id=1937
Finally there will be three types of CAN FD controllers in the future:
1. ISO compliant (fixed)
2. non-ISO compliant (fixed, like the M_CAN IP v3.0.1 in m_can.c)
3. ISO/non-ISO CAN FD controllers (switchable, like the PEAK USB FD)
So the current M_CAN driver for the M_CAN IP v3.0.1 has to expose its non-ISO
implementation by setting the CAN_CTRLMODE_FD_NON_ISO ctrlmode at startup.
As this bit cannot be switched at configuration time CAN_CTRLMODE_FD_NON_ISO
must not be set in ctrlmode_supported of the current M_CAN driver.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/m_can/m_can.c | 5 +++++
include/uapi/linux/can/netlink.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index d7bc462aafdc..244529881be9 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -955,6 +955,11 @@ static struct net_device *alloc_m_can_dev(void)
priv->can.data_bittiming_const = &m_can_data_bittiming_const;
priv->can.do_set_mode = m_can_set_mode;
priv->can.do_get_berr_counter = m_can_get_berr_counter;
+
+ /* CAN_CTRLMODE_FD_NON_ISO is fixed with M_CAN IP v3.0.1 */
+ priv->can.ctrlmode = CAN_CTRLMODE_FD_NON_ISO;
+
+ /* CAN_CTRLMODE_FD_NON_ISO can not be changed with M_CAN IP v3.0.1 */
priv->can.ctrlmode_supported = CAN_CTRLMODE_LOOPBACK |
CAN_CTRLMODE_LISTENONLY |
CAN_CTRLMODE_BERR_REPORTING |
diff --git a/include/uapi/linux/can/netlink.h b/include/uapi/linux/can/netlink.h
index 3e4323a3918d..94ffe0c83ce7 100644
--- a/include/uapi/linux/can/netlink.h
+++ b/include/uapi/linux/can/netlink.h
@@ -98,6 +98,7 @@ struct can_ctrlmode {
#define CAN_CTRLMODE_BERR_REPORTING 0x10 /* Bus-error reporting */
#define CAN_CTRLMODE_FD 0x20 /* CAN FD mode */
#define CAN_CTRLMODE_PRESUME_ACK 0x40 /* Ignore missing CAN ACKs */
+#define CAN_CTRLMODE_FD_NON_ISO 0x80 /* CAN FD in non-ISO mode */
/*
* CAN device statistics
--
2.1.4
^ permalink raw reply related
* [PATCH 5/8] can: kvaser_usb: Don't free packets when tight on URBs
From: Marc Kleine-Budde @ 2015-01-15 16:11 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Ahmed S. Darwish, linux-stable,
Marc Kleine-Budde
In-Reply-To: <1421338283-12417-1-git-send-email-mkl@pengutronix.de>
From: "Ahmed S. Darwish" <ahmed.darwish@valeo.com>
Flooding the Kvaser CAN to USB dongle with multiple reads and
writes in high frequency caused seemingly-random panics in the
kernel.
On further inspection, it seems the driver erroneously freed the
to-be-transmitted packet upon getting tight on URBs and returning
NETDEV_TX_BUSY, leading to invalid memory writes and double frees
at a later point in time.
Note:
Finding no more URBs/transmit-contexts and returning NETDEV_TX_BUSY
is a driver bug in and out of itself: it means that our start/stop
queue flow control is broken.
This patch only fixes the (buggy) error handling code; the root
cause shall be fixed in a later commit.
Acked-by: Olivier Sobrie <olivier@sobrie.be>
Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/usb/kvaser_usb.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/net/can/usb/kvaser_usb.c b/drivers/net/can/usb/kvaser_usb.c
index 541fb7a05625..2e7d513a7c11 100644
--- a/drivers/net/can/usb/kvaser_usb.c
+++ b/drivers/net/can/usb/kvaser_usb.c
@@ -1294,12 +1294,14 @@ static netdev_tx_t kvaser_usb_start_xmit(struct sk_buff *skb,
if (!urb) {
netdev_err(netdev, "No memory left for URBs\n");
stats->tx_dropped++;
- goto nourbmem;
+ dev_kfree_skb(skb);
+ return NETDEV_TX_OK;
}
buf = kmalloc(sizeof(struct kvaser_msg), GFP_ATOMIC);
if (!buf) {
stats->tx_dropped++;
+ dev_kfree_skb(skb);
goto nobufmem;
}
@@ -1334,6 +1336,7 @@ static netdev_tx_t kvaser_usb_start_xmit(struct sk_buff *skb,
}
}
+ /* This should never happen; it implies a flow control bug */
if (!context) {
netdev_warn(netdev, "cannot find free context\n");
ret = NETDEV_TX_BUSY;
@@ -1364,9 +1367,6 @@ static netdev_tx_t kvaser_usb_start_xmit(struct sk_buff *skb,
if (unlikely(err)) {
can_free_echo_skb(netdev, context->echo_index);
- skb = NULL; /* set to NULL to avoid double free in
- * dev_kfree_skb(skb) */
-
atomic_dec(&priv->active_tx_urbs);
usb_unanchor_urb(urb);
@@ -1388,8 +1388,6 @@ releasebuf:
kfree(buf);
nobufmem:
usb_free_urb(urb);
-nourbmem:
- dev_kfree_skb(skb);
return ret;
}
--
2.1.4
^ permalink raw reply related
* [PATCH 6/8] can: kvaser_usb: Reset all URB tx contexts upon channel close
From: Marc Kleine-Budde @ 2015-01-15 16:11 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Ahmed S. Darwish, linux-stable,
Marc Kleine-Budde
In-Reply-To: <1421338283-12417-1-git-send-email-mkl@pengutronix.de>
From: "Ahmed S. Darwish" <ahmed.darwish@valeo.com>
Flooding the Kvaser CAN to USB dongle with multiple reads and
writes in very high frequency (*), closing the CAN channel while
all the transmissions are on (#), opening the device again (@),
then sending a small number of packets would make the driver
enter an almost infinite loop of:
[....]
[15959.853988] kvaser_usb 4-3:1.0 can0: cannot find free context
[15959.853990] kvaser_usb 4-3:1.0 can0: cannot find free context
[15959.853991] kvaser_usb 4-3:1.0 can0: cannot find free context
[15959.853993] kvaser_usb 4-3:1.0 can0: cannot find free context
[15959.853994] kvaser_usb 4-3:1.0 can0: cannot find free context
[15959.853995] kvaser_usb 4-3:1.0 can0: cannot find free context
[....]
_dragging the whole system down_ in the process due to the
excessive logging output.
Initially, this has caused random panics in the kernel due to a
buggy error recovery path. That got fixed in an earlier commit.(%)
This patch aims at solving the root cause. -->
16 tx URBs and contexts are allocated per CAN channel per USB
device. Such URBs are protected by:
a) A simple atomic counter, up to a value of MAX_TX_URBS (16)
b) A flag in each URB context, stating if it's free
c) The fact that ndo_start_xmit calls are themselves protected
by the networking layers higher above
After grabbing one of the tx URBs, if the driver noticed that all
of them are now taken, it stops the netif transmission queue.
Such queue is worken up again only if an acknowedgment was received
from the firmware on one of our earlier-sent frames.
Meanwhile, upon channel close (#), the driver sends a CMD_STOP_CHIP
to the firmware, effectively closing all further communication. In
the high traffic case, the atomic counter remains at MAX_TX_URBS,
and all the URB contexts remain marked as active. While opening
the channel again (@), it cannot send any further frames since no
more free tx URB contexts are available.
Reset all tx URB contexts upon CAN channel close.
(*) 50 parallel instances of `cangen0 -g 0 -ix`
(#) `ifconfig can0 down`
(@) `ifconfig can0 up`
(%) "can: kvaser_usb: Don't free packets when tight on URBs"
Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/usb/kvaser_usb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/can/usb/kvaser_usb.c b/drivers/net/can/usb/kvaser_usb.c
index 2e7d513a7c11..9accc8272c27 100644
--- a/drivers/net/can/usb/kvaser_usb.c
+++ b/drivers/net/can/usb/kvaser_usb.c
@@ -1246,6 +1246,9 @@ static int kvaser_usb_close(struct net_device *netdev)
if (err)
netdev_warn(netdev, "Cannot stop device, error %d\n", err);
+ /* reset tx contexts */
+ kvaser_usb_unlink_tx_urbs(priv);
+
priv->can.state = CAN_STATE_STOPPED;
close_candev(priv->netdev);
--
2.1.4
^ permalink raw reply related
* [PATCH 8/8] can: kvaser_usb: Don't dereference skb after a netif_rx()
From: Marc Kleine-Budde @ 2015-01-15 16:11 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel, Ahmed S. Darwish, Marc Kleine-Budde
In-Reply-To: <1421338283-12417-1-git-send-email-mkl@pengutronix.de>
From: "Ahmed S. Darwish" <ahmed.darwish@valeo.com>
We should not touch the packet after a netif_rx: it might
get freed behind our back.
Suggested-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/usb/kvaser_usb.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/net/can/usb/kvaser_usb.c b/drivers/net/can/usb/kvaser_usb.c
index cc7bfc0c0a71..c32cd61073bc 100644
--- a/drivers/net/can/usb/kvaser_usb.c
+++ b/drivers/net/can/usb/kvaser_usb.c
@@ -520,10 +520,10 @@ static void kvaser_usb_tx_acknowledge(const struct kvaser_usb *dev,
skb = alloc_can_err_skb(priv->netdev, &cf);
if (skb) {
cf->can_id |= CAN_ERR_RESTARTED;
- netif_rx(skb);
stats->rx_packets++;
stats->rx_bytes += cf->can_dlc;
+ netif_rx(skb);
} else {
netdev_err(priv->netdev,
"No memory left for err_skb\n");
@@ -770,10 +770,9 @@ static void kvaser_usb_rx_error(const struct kvaser_usb *dev,
priv->can.state = new_state;
- netif_rx(skb);
-
stats->rx_packets++;
stats->rx_bytes += cf->can_dlc;
+ netif_rx(skb);
}
static void kvaser_usb_rx_can_err(const struct kvaser_usb_net_priv *priv,
@@ -805,10 +804,9 @@ static void kvaser_usb_rx_can_err(const struct kvaser_usb_net_priv *priv,
stats->rx_over_errors++;
stats->rx_errors++;
- netif_rx(skb);
-
stats->rx_packets++;
stats->rx_bytes += cf->can_dlc;
+ netif_rx(skb);
}
}
@@ -887,10 +885,9 @@ static void kvaser_usb_rx_can_msg(const struct kvaser_usb *dev,
cf->can_dlc);
}
- netif_rx(skb);
-
stats->rx_packets++;
stats->rx_bytes += cf->can_dlc;
+ netif_rx(skb);
}
static void kvaser_usb_start_chip_reply(const struct kvaser_usb *dev,
--
2.1.4
^ permalink raw reply related
* pull-request: can 2015-01-15
From: Marc Kleine-Budde @ 2015-01-15 16:11 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel
Hello David,
this is a pull request of 8 patches.
Ahmed S. Darwish contributes 4 fixes for the kvaser_usb driver. The two patches
by Oliver Hartkopp mark the m_can driver as non-ISO, as the CANFD standard was
updated. Roger Quadros's patch for the c_can driver fixes the register access
during RAMINIT. And one patch by my, which updates the MAINTAINERS file, as we
moved the git repos to the kernel.org infrastructure.
regards,
Marc
---
The following changes since commit 16dde0d6ac159531a5e03cd3f8bc8a401d9f3fb6:
be2net: Allow GRE to work concurrently while a VxLAN tunnel is configured (2015-01-15 01:55:05 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git tags/linux-can-fixes-for-3.19-20150115
for you to fetch changes up to a58518ccf39f86f898a65201518dd8e799b3abeb:
can: kvaser_usb: Don't dereference skb after a netif_rx() (2015-01-15 16:58:02 +0100)
----------------------------------------------------------------
linux-can-fixes-for-3.19-20150115
----------------------------------------------------------------
Ahmed S. Darwish (4):
can: kvaser_usb: Don't free packets when tight on URBs
can: kvaser_usb: Reset all URB tx contexts upon channel close
can: kvaser_usb: Don't send a RESET_CHIP for non-existing channels
can: kvaser_usb: Don't dereference skb after a netif_rx()
Marc Kleine-Budde (1):
MAINTAINERS: update linux-can git repositories
Oliver Hartkopp (2):
can: dev: fix crtlmode_supported check
can: m_can: tag current CAN FD controllers as non-ISO
Roger Quadros (1):
can: c_can: use regmap_update_bits() to modify RAMINIT register
MAINTAINERS | 6 ++++--
drivers/net/can/c_can/c_can_platform.c | 29 ++++++++++++++++++-----------
drivers/net/can/dev.c | 8 ++++++--
drivers/net/can/m_can/m_can.c | 5 +++++
drivers/net/can/usb/kvaser_usb.c | 31 +++++++++++++++----------------
include/uapi/linux/can/netlink.h | 1 +
6 files changed, 49 insertions(+), 31 deletions(-)
^ permalink raw reply
* [PATCH 1/8] MAINTAINERS: update linux-can git repositories
From: Marc Kleine-Budde @ 2015-01-15 16:11 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel, Marc Kleine-Budde
In-Reply-To: <1421338283-12417-1-git-send-email-mkl@pengutronix.de>
The linux-can upstream git repositories are now hosted on kernel.org, update
MAINTAINERS accordingly.
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
MAINTAINERS | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 600d2aad8276..efa5f8d4086d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2346,7 +2346,8 @@ CAN NETWORK LAYER
M: Oliver Hartkopp <socketcan@hartkopp.net>
L: linux-can@vger.kernel.org
W: http://gitorious.org/linux-can
-T: git git://gitorious.org/linux-can/linux-can-next.git
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git
S: Maintained
F: Documentation/networking/can.txt
F: net/can/
@@ -2361,7 +2362,8 @@ M: Wolfgang Grandegger <wg@grandegger.com>
M: Marc Kleine-Budde <mkl@pengutronix.de>
L: linux-can@vger.kernel.org
W: http://gitorious.org/linux-can
-T: git git://gitorious.org/linux-can/linux-can-next.git
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git
S: Maintained
F: drivers/net/can/
F: include/linux/can/dev.h
--
2.1.4
^ permalink raw reply related
* [PATCH 2/8] can: dev: fix crtlmode_supported check
From: Marc Kleine-Budde @ 2015-01-15 16:11 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Oliver Hartkopp, Wolfgang Grandegger,
linux-stable, Marc Kleine-Budde
In-Reply-To: <1421338283-12417-1-git-send-email-mkl@pengutronix.de>
From: Oliver Hartkopp <socketcan@hartkopp.net>
When changing flags in the CAN drivers ctrlmode the provided new content has to
be checked whether the bits are allowed to be changed. The bits that are to be
changed are given as a bitfield in cm->mask. Therefore checking against
cm->flags is wrong as the content can hold any kind of values.
The iproute2 tool sets the bits in cm->mask and cm->flags depending on the
detected command line options. To be robust against bogus user space
applications additionally sanitize the provided flags with the provided mask.
Cc: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/dev.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index 3ec8f6f25e5f..847c1f813261 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -807,10 +807,14 @@ static int can_changelink(struct net_device *dev,
if (dev->flags & IFF_UP)
return -EBUSY;
cm = nla_data(data[IFLA_CAN_CTRLMODE]);
- if (cm->flags & ~priv->ctrlmode_supported)
+
+ /* check whether changed bits are allowed to be modified */
+ if (cm->mask & ~priv->ctrlmode_supported)
return -EOPNOTSUPP;
+
+ /* clear bits to be modified and copy the flag values */
priv->ctrlmode &= ~cm->mask;
- priv->ctrlmode |= cm->flags;
+ priv->ctrlmode |= (cm->flags & cm->mask);
/* CAN_CTRLMODE_FD can only be set when driver supports FD */
if (priv->ctrlmode & CAN_CTRLMODE_FD)
--
2.1.4
^ permalink raw reply related
* [PATCH 4/8] can: c_can: use regmap_update_bits() to modify RAMINIT register
From: Marc Kleine-Budde @ 2015-01-15 16:11 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel, Roger Quadros, Marc Kleine-Budde
In-Reply-To: <1421338283-12417-1-git-send-email-mkl@pengutronix.de>
From: Roger Quadros <rogerq@ti.com>
use of regmap_read() and regmap_write() in c_can_hw_raminit_syscon()
is not safe as the RAMINIT register can be shared between different drivers
at least for TI SoCs.
To make the modification atomic we switch to using regmap_update_bits().
regmap_update_bits() skips writing to the register if it's read content is the
same as what is going to be written. This causes an issue for us when we
need to clear the DONE bit with the initial condition START:0, DONE:1 as
DONE bit must be written with 1 to clear it.
So we defer the clearing of DONE bit to later when we set the START bit.
There we are sure that START bit is changed from 0 to 1 so the write of
1 to already set DONE bit will happen.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/c_can/c_can_platform.c | 29 ++++++++++++++++++-----------
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/net/can/c_can/c_can_platform.c b/drivers/net/can/c_can/c_can_platform.c
index f363972cd77d..e36d10520e24 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -103,27 +103,34 @@ static void c_can_hw_raminit_syscon(const struct c_can_priv *priv, bool enable)
mask = 1 << raminit->bits.start | 1 << raminit->bits.done;
regmap_read(raminit->syscon, raminit->reg, &ctrl);
- /* We clear the done and start bit first. The start bit is
+ /* We clear the start bit first. The start bit is
* looking at the 0 -> transition, but is not self clearing;
- * And we clear the init done bit as well.
* NOTE: DONE must be written with 1 to clear it.
+ * We can't clear the DONE bit here using regmap_update_bits()
+ * as it will bypass the write if initial condition is START:0 DONE:1
+ * e.g. on DRA7 which needs START pulse.
*/
- ctrl &= ~(1 << raminit->bits.start);
- ctrl |= 1 << raminit->bits.done;
- regmap_write(raminit->syscon, raminit->reg, ctrl);
+ ctrl &= ~mask; /* START = 0, DONE = 0 */
+ regmap_update_bits(raminit->syscon, raminit->reg, mask, ctrl);
- ctrl &= ~(1 << raminit->bits.done);
- c_can_hw_raminit_wait_syscon(priv, mask, ctrl);
+ /* check if START bit is 0. Ignore DONE bit for now
+ * as it can be either 0 or 1.
+ */
+ c_can_hw_raminit_wait_syscon(priv, 1 << raminit->bits.start, ctrl);
if (enable) {
- /* Set start bit and wait for the done bit. */
+ /* Clear DONE bit & set START bit. */
ctrl |= 1 << raminit->bits.start;
- regmap_write(raminit->syscon, raminit->reg, ctrl);
-
+ /* DONE must be written with 1 to clear it */
+ ctrl |= 1 << raminit->bits.done;
+ regmap_update_bits(raminit->syscon, raminit->reg, mask, ctrl);
+ /* prevent further clearing of DONE bit */
+ ctrl &= ~(1 << raminit->bits.done);
/* clear START bit if start pulse is needed */
if (raminit->needs_pulse) {
ctrl &= ~(1 << raminit->bits.start);
- regmap_write(raminit->syscon, raminit->reg, ctrl);
+ regmap_update_bits(raminit->syscon, raminit->reg,
+ mask, ctrl);
}
ctrl |= 1 << raminit->bits.done;
--
2.1.4
^ permalink raw reply related
* [PATCH 7/8] can: kvaser_usb: Don't send a RESET_CHIP for non-existing channels
From: Marc Kleine-Budde @ 2015-01-15 16:11 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Ahmed S. Darwish, Olivier Sobrie,
linux-stable, Marc Kleine-Budde
In-Reply-To: <1421338283-12417-1-git-send-email-mkl@pengutronix.de>
From: "Ahmed S. Darwish" <ahmed.darwish@valeo.com>
Recent Leaf firmware versions (>= 3.1.557) do not allow to send
commands for non-existing channels. If a command is sent for a
non-existing channel, the firmware crashes.
Reported-by: Christopher Storah <Christopher.Storah@invetech.com.au>
Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/usb/kvaser_usb.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/can/usb/kvaser_usb.c b/drivers/net/can/usb/kvaser_usb.c
index 9accc8272c27..cc7bfc0c0a71 100644
--- a/drivers/net/can/usb/kvaser_usb.c
+++ b/drivers/net/can/usb/kvaser_usb.c
@@ -1503,6 +1503,10 @@ static int kvaser_usb_init_one(struct usb_interface *intf,
struct kvaser_usb_net_priv *priv;
int i, err;
+ err = kvaser_usb_send_simple_msg(dev, CMD_RESET_CHIP, channel);
+ if (err)
+ return err;
+
netdev = alloc_candev(sizeof(*priv), MAX_TX_URBS);
if (!netdev) {
dev_err(&intf->dev, "Cannot alloc candev\n");
@@ -1607,9 +1611,6 @@ static int kvaser_usb_probe(struct usb_interface *intf,
usb_set_intfdata(intf, dev);
- for (i = 0; i < MAX_NET_DEVICES; i++)
- kvaser_usb_send_simple_msg(dev, CMD_RESET_CHIP, i);
-
err = kvaser_usb_get_software_info(dev);
if (err) {
dev_err(&intf->dev,
--
2.1.4
^ permalink raw reply related
* Re: [PATCH] net: smc91x: Add Atari EtherNAT support
From: Nicolas Pitre @ 2015-01-15 16:13 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: David S. Miller, netdev, linux-m68k, Michael Schmitz,
Michael Schmitz
In-Reply-To: <1421327175-7613-1-git-send-email-geert@linux-m68k.org>
On Thu, 15 Jan 2015, Geert Uytterhoeven wrote:
> From: Michael Schmitz <schmitzmic@gmail.com>
>
> Add Atari specific code to the smc91x Ethernet driver. This code is used
> on the EtherNAT adapter card for the Atari Falcon extension port.
>
> Signed-off-by: Michael Schmitz <schmitz@debian.org>
> Tested-by: Christian Steigies <cts@debian.org>
> [geert: Sort Kconfig entries, split in hard and soft dependencies]
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Long gone is the time I had access to hardware with this ethernet chip,
but FWIW:
Acked-by: Nicolas Pitre <nico@fluxnic.net>
> ---
> drivers/net/ethernet/smsc/Kconfig | 10 ++++++----
> drivers/net/ethernet/smsc/smc91x.h | 21 +++++++++++++++++++++
> 2 files changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/smsc/Kconfig b/drivers/net/ethernet/smsc/Kconfig
> index 9468e64e6007bd2e..3e97a8b43147cc7c 100644
> --- a/drivers/net/ethernet/smsc/Kconfig
> +++ b/drivers/net/ethernet/smsc/Kconfig
> @@ -5,8 +5,9 @@
> config NET_VENDOR_SMSC
> bool "SMC (SMSC)/Western Digital devices"
> default y
> - depends on ARM || ISA || MAC || ARM64 || MIPS || M32R || SUPERH || \
> - BLACKFIN || MN10300 || COLDFIRE || XTENSA || NIOS2 || PCI || PCMCIA
> + depends on ARM || ARM64 || ATARI_ETHERNAT || BLACKFIN || COLDFIRE || \
> + ISA || M32R || MAC || MIPS || MN10300 || NIOS2 || PCI || \
> + PCMCIA || SUPERH || XTENSA
> ---help---
> If you have a network (Ethernet) card belonging to this class, say Y
> and read the Ethernet-HOWTO, available from
> @@ -38,8 +39,9 @@ config SMC91X
> tristate "SMC 91C9x/91C1xxx support"
> select CRC32
> select MII
> - depends on (ARM || M32R || SUPERH || MIPS || BLACKFIN || \
> - MN10300 || COLDFIRE || ARM64 || XTENSA || NIOS2) && (!OF || GPIOLIB)
> + depends on !OF || GPIOLIB
> + depends on ARM || ARM64 || ATARI_ETHERNAT || BLACKFIN || COLDFIRE || \
> + M32R || MIPS || MN10300 || NIOS2 || SUPERH || XTENSA
> ---help---
> This is a driver for SMC's 91x series of Ethernet chipsets,
> including the SMC91C94 and the SMC91C111. Say Y if you want it
> diff --git a/drivers/net/ethernet/smsc/smc91x.h b/drivers/net/ethernet/smsc/smc91x.h
> index 2a38dacbbd27fba4..be67baf5f6778d08 100644
> --- a/drivers/net/ethernet/smsc/smc91x.h
> +++ b/drivers/net/ethernet/smsc/smc91x.h
> @@ -216,6 +216,27 @@ SMC_outw(u16 val, void __iomem *ioaddr, int reg)
>
> #include <unit/smc91111.h>
>
> +#elif defined(CONFIG_ATARI)
> +
> +#define SMC_CAN_USE_8BIT 1
> +#define SMC_CAN_USE_16BIT 1
> +#define SMC_CAN_USE_32BIT 1
> +#define SMC_NOWAIT 1
> +
> +#define SMC_inb(a, r) readb((a) + (r))
> +#define SMC_inw(a, r) readw((a) + (r))
> +#define SMC_inl(a, r) readl((a) + (r))
> +#define SMC_outb(v, a, r) writeb(v, (a) + (r))
> +#define SMC_outw(v, a, r) writew(v, (a) + (r))
> +#define SMC_outl(v, a, r) writel(v, (a) + (r))
> +#define SMC_insw(a, r, p, l) readsw((a) + (r), p, l)
> +#define SMC_outsw(a, r, p, l) writesw((a) + (r), p, l)
> +#define SMC_insl(a, r, p, l) readsl((a) + (r), p, l)
> +#define SMC_outsl(a, r, p, l) writesl((a) + (r), p, l)
> +
> +#define RPC_LSA_DEFAULT RPC_LED_100_10
> +#define RPC_LSB_DEFAULT RPC_LED_TX_RX
> +
> #elif defined(CONFIG_ARCH_MSM)
>
> #define SMC_CAN_USE_8BIT 0
> --
> 1.9.1
>
>
^ permalink raw reply
* ANNOUNCEMENT: linux-can repos are now at kernel.org
From: Marc Kleine-Budde @ 2015-01-15 16:14 UTC (permalink / raw)
To: linux-can@vger.kernel.org; +Cc: netdev
[-- Attachment #1: Type: text/plain, Size: 502 bytes --]
-T: git git://gitorious.org/linux-can/linux-can-next.git
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git
'Nuff Said!
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: ANNOUNCEMENT: linux-can repos are now at kernel.org
From: Oliver Hartkopp @ 2015-01-15 17:03 UTC (permalink / raw)
To: Marc Kleine-Budde, linux-can@vger.kernel.org; +Cc: netdev
In-Reply-To: <54B7E77C.5040509@pengutronix.de>
Very cool!
That was really fast.
Thanks,
Oliver
On 15.01.2015 17:14, Marc Kleine-Budde wrote:
> -T: git git://gitorious.org/linux-can/linux-can-next.git
> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git
> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git
>
> 'Nuff Said!
>
^ permalink raw reply
* Re: Re: Re: Re: [bisected regression] e1000e: "Detected Hardware Unit Hang"
From: Thomas Jarosch @ 2015-01-15 17:04 UTC (permalink / raw)
To: Eric Dumazet
Cc: 'Linux Netdev List', Eric Dumazet, Jeff Kirsher,
e1000-devel
In-Reply-To: <1421337658.11734.76.camel@edumazet-glaptop2.roam.corp.google.com>
On Thursday, 15. January 2015 08:00:58 Eric Dumazet wrote:
> Please apply this patch, and try to lower
> /proc/sys/net/core/gro_max_frags and see if this makes a difference
> (leaving GRO enabled)
>
> (start with 7 and increase it, limit being 17)
Patch applied to 3.19-rc4+.
Results:
7: hang
8: hang
9: hang
10: hang
11: hang
12: hang
13: hang
14: hang
15: hang
16: hang
17: hang
for the sake of completeness:
1: hang
2: hang
3: hang
4: hang
5: hang
6: hang
Regarding the test procedure: I stopped the download script on the client,
changed gro_max_frags and started the download again. No cable unplugging /
reboot of the box in between. Just mentioning it to make sure it somehow
does not affect what we actually wanted to test.
Additional tests have been done with gro_max_frags 1, 7 and 17:
- stop networking + unload e1000e -> restart -> download: hang
One thing I can say from the testing: The more I increase gro_max_frags,
the longer it takes to trigger it. I tried each setting below three times.
A value of 17 is really noticeable.
1: 3-8 seconds till hang
7: 7-10 seconds till hang
17: 23-26 seconds till hang
Thomas
^ permalink raw reply
* Re: [PATCH for 3.19 3/3] rtlwifi: rtl8192ee: Fix several bugs
From: Larry Finger @ 2015-01-15 17:05 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Troy Tan,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <87bnm0xoar.fsf-HodKDYzPHsUD5k0oWYwrnHL1okKdlPRT@public.gmane.org>
On 01/15/2015 05:42 AM, Kalle Valo wrote:
> Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> writes:
>
>> From: Troy Tan <troy_tan-kXabqFNEczNtrwSWzY7KCg@public.gmane.org>
>>
>> The following bugs are fixed in this driver:
>> 1. Problems parsing C2H CMD
>> 2. An ad-hoc connection can cause a TX freeze.
>> 3. There are additional conditions that cause a TX freeze.
>> 4. The previous code failed to handle situations where an RX
>> descriptor was unavailable.
>>
>> Signed-off-by: Troy Tan <troy_tan-kXabqFNEczNtrwSWzY7KCg@public.gmane.org>
>> Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
>
> Is this really so important that it should go to 3.19? A patch titled
> "Fix several bugs" immediately makes me cautious and then I look at the
> patch itself I see rewriting functions instead of simple bug fixes. From
> a quick look this looks more -next material than 3.19.
It is not a simple rewrite of functions. Tho mishandling of the descriptor ring
buffer locks up the device and requires a cold boot. These patches prevent that
from happening.
Yes, the patches are rather larger than I would like at the -rc4 stage, and I
defer to your judgement. At least we have an external source of corrected code
for users of 3.18 and 3.19.
Larry
--
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
* [PATCH iproute2] tests: Add few 'ip link' related tests
From: Vadim Kochan @ 2015-01-15 16:59 UTC (permalink / raw)
To: netdev; +Cc: Vadim Kochan
From: Vadim Kochan <vadim4j@gmail.com>
Added two tests which checks the following fixed issues:
1) Bug when not possible add new virtual interface via:
$ ip link add dev XXX type
It was fixed a few releases ago.
2) Crash on older kernels when VF rate info does not exist:
$ ip link show
Used dump file from William Dauchy <william@gandi.net>:
testsuite/tests/ip/link/dev_wo_vf_rate.nl
So 'ip link show' replaced by 'ip -d monitor file ...' which does
the same thing.
Also added new func in testsuite/lib/generic.sh to gen new random dev name.
Added 'clean' dependency on running all tests.
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
---
testsuite/Makefile | 3 ++-
testsuite/lib/generic.sh | 8 +++++++-
testsuite/tests/ip/link/dev_wo_vf_rate.nl | Bin 0 -> 14076 bytes
testsuite/tests/ip/link/new_link.t | 11 +++++++++++
testsuite/tests/ip/link/show_dev_wo_vf_rate.t | 6 ++++++
5 files changed, 26 insertions(+), 2 deletions(-)
create mode 100644 testsuite/tests/ip/link/dev_wo_vf_rate.nl
create mode 100755 testsuite/tests/ip/link/new_link.t
create mode 100755 testsuite/tests/ip/link/show_dev_wo_vf_rate.t
diff --git a/testsuite/Makefile b/testsuite/Makefile
index 2ba9547..a2c8a2d 100644
--- a/testsuite/Makefile
+++ b/testsuite/Makefile
@@ -31,12 +31,13 @@ listtests:
alltests: $(TESTS)
clean:
+ @echo "Removing $(RESULTS_DIR) dir ..."
@rm -rf $(RESULTS_DIR)
distclean: clean
echo "Entering iproute2" && cd iproute2 && $(MAKE) distclean && cd ..;
-$(TESTS):
+$(TESTS): clean
@mkdir -p $(RESULTS_DIR)
@for d in $(TESTS_DIR); do \
diff --git a/testsuite/lib/generic.sh b/testsuite/lib/generic.sh
index 8f76e49..3473cc1 100644
--- a/testsuite/lib/generic.sh
+++ b/testsuite/lib/generic.sh
@@ -62,8 +62,9 @@ ts_ip()
TMP_OUT=`mktemp /tmp/tc_testsuite.XXXXXX` || exit
$IP $@ 2> $TMP_ERR > $TMP_OUT
+ RET=$?
- if [ -s $TMP_ERR ]; then
+ if [ -s $TMP_ERR ] || [ "$RET" != "0" ]; then
ts_err "${SCRIPT}: ${DESC} failed:"
ts_err "command: $IP $@"
ts_err "stderr output:"
@@ -91,3 +92,8 @@ ts_qdisc_available()
return 1;
fi
}
+
+rand_dev()
+{
+ echo "dev-$(tr -dc "[:alpha:]" < /dev/urandom | head -c 6)"
+}
diff --git a/testsuite/tests/ip/link/dev_wo_vf_rate.nl b/testsuite/tests/ip/link/dev_wo_vf_rate.nl
new file mode 100644
index 0000000000000000000000000000000000000000..40fa87ff1b158fb972e064efb38f76b0e9a56697
GIT binary patch
literal 14076
zcmeI2QD_`h6o$|4X4B1fZMT}ns!(GsCQqft8lx5o_Nk#2gn}Z4n3_#@VcVp2BSi%l
zK`m6<ASk{l3L;Xdtzh4LXw?UwEWQ;H>|<XAeW{rB{P)gj@7$T$&U9yYCpZUo?##V+
z&N*}MnQzaXnJq-Lk$)l|{C)nwxqpi^KR{HbES=`#u}x?l$YprDm#`&TM>(o55*6q!
zb)4tkkUXi*T+a%)Z-E|A^#$7Mln*Km1sYXlo*q(Vi3aKD;<4q*a)q|j2GuucGkCJq
zDyp+|k0Sdi@-ln2m0iT|)VKO4ZE=*})4fVJbioD$cFa;AC2zZuy`N6-ST&5X6EATo
z_D|Z(Qu>&6?e@!KMAvgf!`ULof*!D8j*?c3=uZxngEPAQq%()pN?GQnhhmRa(B~Ye
z(A8pTJ~c$m=QA9IL@)C6>*%|64N6VG20Ecbn#D)dZ_ng7{!(c-0=xKL9c<UZr)`+;
zOIvp4ZN_9&6znPMI2q#Etu(4TaUM8>c>-r(+vLpn!)W(%rl8In<u>%!oLR?bA34VJ
ztQhmlKitHza7C5aH$^e#k$UUmB_c2eF@vZ9V+O7g?SGr-@R?S2`HvUO)6{;^Q==<_
z>do$84D>@_0|GlJ{cNG$mN0hAbE5V)&o%c8v{}vJPc*{gl%a9wPJSu7_~x%4nmyh7
z_^&agr0#58Q&RsW`ra<_Op1tpM9YpZCUc_~rNvu9zm6*12K{mj{n*D3`lUV&UV1%g
zUn49sc-a(QK6ek%rHYrAh=1`}t|P~0gqN_`DKAAobcv6sGkGaYxZrel&nWIuE#r2B
zQ{U?X846^*F1%akI<{ai+lX9uP#2Sz_NB|1*yo1jC0w(3`6zUChnGJ%y!^2}FE4v}
zc^~`4;Y(kR5Iyaa-ff1{cPQW`^h00+0y_{tTe`))?Zm!YQ?#QXUVc;E_S@cCu&z#d
zdFYwH@;|S(*YAYC>a-Sl`4vy<)WPKPQdrOom<Gw1u9*`N(6<-W;%^Wy<vPl@;ic#a
z^4a92-ABg6uJ_|*!?T9Xs7xa3EEb&nass-*ORO!BU&22#zx<t34!`^o(_*e;p=TrK
zmrDz^g~i#0xmO#KXQCxokY`GMWapU}Yh3fbA)*<df$Jo112<(ZWn5tg;%7^@xVN3y
zcWa7v1a3kSlB1F2Xjs#Jeag!m#E{&^DDlH>((4>evgfMfjQGT^D3Lh0ZZ}AW9+z?D
zXmZ^_?wic9FI~pOJ~u3LVB2EOW6;%a=E$1Kk2%Oo5Afy_nE*KKh=T|@j8vM;k=z${
zAbz%Vi+kINeYd7)M@eSR)Y+6d(PlHaw}ia>H+p(HfVkbdu%FDqn$%*>E?h?+nbSm`
zBkLNQIT&+rc8UjWMkW9b#~|u?nxjWp4m*%2w(S1}t)aWyBr|8__2e=~QsrjA^hg|B
z>&K+}_#|!wF=yI2C&_CojH$(($KiG#nZwWRGbGPC{FsB(11wnSB6B3q5#~g(C2@gq
z?3E;$In!rS=EM~T5?gD9IZJ$x;_1w-ZxZl*frmMh7@s>~&a^sjlu+V*A;kT@P*nwP
z)ceBsZ)C3Q^FIF$JSm0-<Tq<ogf#>FzA%Z;a&|wPT;8nJIq$aL=Chozw)~#u`0)nM
z9;_Va3E1c>Z}z9W2|Le8=S_7_%A2rrnUsEU@uumM-{Ad<yx-r%Zw!`}57le0%+A%9
zs&lx0a0lY|{bktqR>%XRe18dh$aOw@YwX6@yD57x9$}<Rck}x;UXLEH%^$8L=H1oJ
z?~6wGmD=tEudl+4@&B<;T>LrV!yl{-g+KTPWWMs+?8L;AedW&T$F&Wg?nt>4HrA8Q
zozu*nt1D^V6Lvn6(yyD`DH+^Z&)jJouhr}PC3rvcoyj*o+V<UhDR;ugU(&g=%G@cv
PlX55Qd?uw|T-^B&_@nmR
literal 0
HcmV?d00001
diff --git a/testsuite/tests/ip/link/new_link.t b/testsuite/tests/ip/link/new_link.t
new file mode 100755
index 0000000..549ff25
--- /dev/null
+++ b/testsuite/tests/ip/link/new_link.t
@@ -0,0 +1,11 @@
+#!/bin/sh
+
+source lib/generic.sh
+
+ts_log "[Testing add/del virtual links]"
+
+NEW_DEV="$(rand_dev)"
+
+ts_ip "$0" "Add $NEW_DEV dummy interface" link add dev $NEW_DEV type dummy
+ts_ip "$0" "Show $NEW_DEV dummy interface" link show dev $NEW_DEV
+ts_ip "$0" "Del $NEW_DEV dummy interface" link del dev $NEW_DEV
diff --git a/testsuite/tests/ip/link/show_dev_wo_vf_rate.t b/testsuite/tests/ip/link/show_dev_wo_vf_rate.t
new file mode 100755
index 0000000..a600ba6
--- /dev/null
+++ b/testsuite/tests/ip/link/show_dev_wo_vf_rate.t
@@ -0,0 +1,6 @@
+#!/bin/sh
+
+source lib/generic.sh
+
+NL_FILE="tests/ip/link/dev_wo_vf_rate.nl"
+ts_ip "$0" "Show VF devices w/o VF rate info" -d monitor file $NL_FILE
--
2.1.3
^ permalink raw reply related
* Re: [net-next 16/17] i40e: Support for NPAR iSCSI partition with DCB
From: Or Gerlitz @ 2015-01-15 17:11 UTC (permalink / raw)
To: Jeff Kirsher
Cc: David Miller, Neerav Parikh, Linux Netdev List, nhorman, sassmann,
jogreene
In-Reply-To: <1421324368-6860-17-git-send-email-jeffrey.t.kirsher@intel.com>
On Thu, Jan 15, 2015 at 2:19 PM, Jeff Kirsher
<jeffrey.t.kirsher@intel.com> wrote:
> --- a/drivers/net/ethernet/intel/i40e/i40e_type.h
> +++ b/drivers/net/ethernet/intel/i40e/i40e_type.h
> @@ -211,6 +211,7 @@ struct i40e_hw_capabilities {
> bool evb_802_1_qbh; /* Bridge Port Extension */
> bool dcb;
> bool fcoe;
> + bool iscsi; /* Indicates iSCSI enabled */
> bool mfp_mode_1;
> bool mgmt_cem;
> bool ieee_1588;
Hey Jeff, just a 0.02$ small tip... you can easily save the annoying
addition of bool X_is_supported/enabled cap variable for every new cap
with having a 64 bit flags field with a bit per feature... it also
makes the code much more readable.
^ permalink raw reply
* Re: [net-next 13/17] i40e: AQ API updates for new commands
From: Or Gerlitz @ 2015-01-15 17:14 UTC (permalink / raw)
To: Jeff Kirsher
Cc: David Miller, Shannon Nelson, Linux Netdev List, nhorman,
sassmann, jogreene, Kamil Krawczyk
In-Reply-To: <1421324368-6860-14-git-send-email-jeffrey.t.kirsher@intel.com>
On Thu, Jan 15, 2015 at 2:19 PM, Jeff Kirsher
<jeffrey.t.kirsher@intel.com> wrote:
> From: Shannon Nelson <shannon.nelson@intel.com>
>
> Add lldp control commands, add oem ocsd and ocbb commands, and fix up
> NVM config read and write data structs.
Sounds to me like a proofed nightmare for someone doing future
bisection and landing here... we want kernel patches to be made of
basically one logical change, right?
^ permalink raw reply
* Re: [PATCH for 3.19 2/3] rtlwifi: Fix handling of new style descriptors
From: Larry Finger @ 2015-01-15 17:14 UTC (permalink / raw)
To: Kalle Valo, 谭杭波
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <87y4p4w8wb.fsf-HodKDYzPHsUD5k0oWYwrnHL1okKdlPRT@public.gmane.org>
On 01/15/2015 06:00 AM, Kalle Valo wrote:
> Hi Troy,
>
> please avoid top-posting.
>
> 谭杭波 <troy_tan-kXabqFNEczNtrwSWzY7KCg@public.gmane.org> writes:
>
>> You can find get_available_desc here:
>>
>> diff --git a/drivers/net/wireless/rtlwifi/pci.c b/drivers/net/wireless/rtlwifi/
>> pci.c
>> index e25faac..a62170e 100644
>> --- a/drivers/net/wireless/rtlwifi/pci.c
>> +++ b/drivers/net/wireless/rtlwifi/pci.c
>> @@ -578,6 +578,13 @@ static void _rtl_pci_tx_isr(struct ieee80211_hw *hw, int
>> prio)
>> else
>> entry = (u8 *)(&ring->desc[ring->idx]);
>>
>> + if (rtlpriv->cfg->ops->get_available_desc &&
>> + rtlpriv->cfg->ops->get_available_desc(hw, prio) <= 1) {
>> + RT_TRACE(rtlpriv, (COMP_INTR | COMP_SEND), DBG_DMESG,
>> + "no available desc!\n");
>> + return;
>> + }
>
> I don't see rtlpriv->cfg->ops->get_available_desc set here, only being
> called?
Only one of the drivers (rtl8192ee) needs to implement that routine, which is
the reason it is checked for non-NULL before it is called. The implementation is
in patch 3 in file rtl8192ee/sw.c where it says:
@@ -241,6 +239,7 @@ static struct rtl_hal_ops rtl8192ee_hal_ops = {
.set_desc = rtl92ee_set_desc,
.get_desc = rtl92ee_get_desc,
.is_tx_desc_closed = rtl92ee_is_tx_desc_closed,
+ .get_available_desc = rtl92ee_get_available_desc,
.tx_polling = rtl92ee_tx_polling,
.enable_hw_sec = rtl92ee_enable_hw_security_config,
.init_sw_leds = rtl92ee_init_sw_leds,
Larry
--
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: [net-next 13/17] i40e: AQ API updates for new commands
From: Nelson, Shannon @ 2015-01-15 17:19 UTC (permalink / raw)
To: Or Gerlitz, Kirsher, Jeffrey T
Cc: David Miller, Linux Netdev List, nhorman@redhat.com,
sassmann@redhat.com, jogreene@redhat.com, Krawczyk, Kamil
In-Reply-To: <CAJ3xEMiCLBjuUSh1HGhfJU0gqA7J1MHsp0riLU5kk_uwkAdFqg@mail.gmail.com>
> From: Or Gerlitz [mailto:gerlitz.or@gmail.com]
> Sent: Thursday, January 15, 2015 9:14 AM
>
> On Thu, Jan 15, 2015 at 2:19 PM, Jeff Kirsher
> <jeffrey.t.kirsher@intel.com> wrote:
> > From: Shannon Nelson <shannon.nelson@intel.com>
> >
> > Add lldp control commands, add oem ocsd and ocbb commands, and fix up
> > NVM config read and write data structs.
>
> Sounds to me like a proofed nightmare for someone doing future
> bisection and landing here... we want kernel patches to be made of
> basically one logical change, right?
Yes, but note that these are mostly API additions for transactions that aren't used in the code quite yet. There are a couple of defines that get changed as well, but they aren't used yet either else they'd be accompanied by related code changes.
sln
^ permalink raw reply
* Re: Re: Re: Re: [bisected regression] e1000e: "Detected Hardware Unit Hang"
From: Eric Dumazet @ 2015-01-15 17:20 UTC (permalink / raw)
To: Thomas Jarosch
Cc: 'Linux Netdev List', Eric Dumazet, Jeff Kirsher,
e1000-devel
In-Reply-To: <1837410.pEGIH05mML@storm>
On Thu, 2015-01-15 at 18:04 +0100, Thomas Jarosch wrote:
> On Thursday, 15. January 2015 08:00:58 Eric Dumazet wrote:
> > Please apply this patch, and try to lower
> > /proc/sys/net/core/gro_max_frags and see if this makes a difference
> > (leaving GRO enabled)
> >
> > (start with 7 and increase it, limit being 17)
>
> Patch applied to 3.19-rc4+.
>
> Results:
> 7: hang
> 8: hang
> 9: hang
> 10: hang
> 11: hang
> 12: hang
> 13: hang
> 14: hang
> 15: hang
> 16: hang
> 17: hang
>
> for the sake of completeness:
> 1: hang
This is weird : This should have same effect then GRO off (at most one
segment per packet)
> 2: hang
> 3: hang
> 4: hang
> 5: hang
> 6: hang
>
> Regarding the test procedure: I stopped the download script on the client,
> changed gro_max_frags and started the download again. No cable unplugging /
> reboot of the box in between. Just mentioning it to make sure it somehow
> does not affect what we actually wanted to test.
>
> Additional tests have been done with gro_max_frags 1, 7 and 17:
> - stop networking + unload e1000e -> restart -> download: hang
>
> One thing I can say from the testing: The more I increase gro_max_frags,
> the longer it takes to trigger it. I tried each setting below three times.
> A value of 17 is really noticeable.
>
> 1: 3-8 seconds till hang
> 7: 7-10 seconds till hang
> 17: 23-26 seconds till hang
Could you try the following ?
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 38cb586b1bf42fa7a50e19f3e650e8c139788820..6d93facddab78f8db7000fddaa24322651a0eae9 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -1264,7 +1264,7 @@ static bool e1000_clean_tx_irq(struct e1000_ring *tx_ring)
netdev_completed_queue(netdev, pkts_compl, bytes_compl);
-#define TX_WAKE_THRESHOLD 32
+#define TX_WAKE_THRESHOLD (MAX_SKB_FRAGS * 3 + 2)
if (count && netif_carrier_ok(netdev) &&
e1000_desc_unused(tx_ring) >= TX_WAKE_THRESHOLD) {
/* Make sure that anybody stopping the queue after this
@@ -5650,10 +5650,7 @@ static netdev_tx_t e1000_xmit_frame(struct sk_buff *skb,
netdev_sent_queue(netdev, skb->len);
e1000_tx_queue(tx_ring, tx_flags, count);
/* Make sure there is space in the ring for the next send. */
- e1000_maybe_stop_tx(tx_ring,
- (MAX_SKB_FRAGS *
- DIV_ROUND_UP(PAGE_SIZE,
- adapter->tx_fifo_limit) + 2));
+ e1000_maybe_stop_tx(tx_ring, 3 * MAX_SKB_FRAGS + 2);
} else {
dev_kfree_skb_any(skb);
tx_ring->buffer_info[first].time_stamp = 0;
^ permalink raw reply related
* Re: [bisected regression] e1000e: "Detected Hardware Unit Hang"
From: Thomas Jarosch @ 2015-01-15 17:37 UTC (permalink / raw)
To: Eric Dumazet; +Cc: e1000-devel, 'Linux Netdev List', Eric Dumazet
In-Reply-To: <1421342437.11734.79.camel@edumazet-glaptop2.roam.corp.google.com>
On Thursday, 15. January 2015 09:20:37 Eric Dumazet wrote:
> > for the sake of completeness:
> > 1: hang
>
> This is weird : This should have same effect then GRO off (at most one
> segment per packet)
I thought so, too. OTOH the code path was changed from
"goto merge" to "return -E2BIG". I didn't look at the code
what happens at the "merge" label.
> Could you try the following ?
>
> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
> b/drivers/net/ethernet/intel/e1000e/netdev.c index
> 38cb586b1bf42fa7a50e19f3e650e8c139788820..6d93facddab78f8db7000fddaa24322
> 651a0eae9 100644 --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> @@ -1264,7 +1264,7 @@ static bool e1000_clean_tx_irq(struct e1000_ring
> *tx_ring)
>
> netdev_completed_queue(netdev, pkts_compl, bytes_compl);
>
> -#define TX_WAKE_THRESHOLD 32
> +#define TX_WAKE_THRESHOLD (MAX_SKB_FRAGS * 3 + 2)
> if (count && netif_carrier_ok(netdev) &&
> e1000_desc_unused(tx_ring) >= TX_WAKE_THRESHOLD) {
> /* Make sure that anybody stopping the queue after this
> @@ -5650,10 +5650,7 @@ static netdev_tx_t e1000_xmit_frame(struct sk_buff
> *skb, netdev_sent_queue(netdev, skb->len);
> e1000_tx_queue(tx_ring, tx_flags, count);
> /* Make sure there is space in the ring for the next send. */
> - e1000_maybe_stop_tx(tx_ring,
> - (MAX_SKB_FRAGS *
> - DIV_ROUND_UP(PAGE_SIZE,
> - adapter->tx_fifo_limit) + 2));
> + e1000_maybe_stop_tx(tx_ring, 3 * MAX_SKB_FRAGS + 2);
> } else {
> dev_kfree_skb_any(skb);
> tx_ring->buffer_info[first].time_stamp = 0;
I was just about to leave the office... and switched the test box back on.
Also reverted to vanilla 3.19-rc4+ and applied the above patch instead.
Still hangs. Grrr. More testing tomorrow.
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [net-next 13/17] i40e: AQ API updates for new commands
From: Or Gerlitz @ 2015-01-15 18:04 UTC (permalink / raw)
To: Nelson, Shannon
Cc: Kirsher, Jeffrey T, David Miller, Linux Netdev List,
nhorman@redhat.com, sassmann@redhat.com, jogreene@redhat.com,
Krawczyk, Kamil
In-Reply-To: <FC41C24E35F18A40888AACA1A36F3E418ADD335B@fmsmsx115.amr.corp.intel.com>
On Thu, Jan 15, 2015 at 7:19 PM, Nelson, Shannon
<shannon.nelson@intel.com> wrote:
>> From: Or Gerlitz [mailto:gerlitz.or@gmail.com]
>> Sent: Thursday, January 15, 2015 9:14 AM
>>
>> On Thu, Jan 15, 2015 at 2:19 PM, Jeff Kirsher
>> <jeffrey.t.kirsher@intel.com> wrote:
>> > From: Shannon Nelson <shannon.nelson@intel.com>
>> >
>> > Add lldp control commands, add oem ocsd and ocbb commands, and fix up
>> > NVM config read and write data structs.
>>
>> Sounds to me like a proofed nightmare for someone doing future
>> bisection and landing here... we want kernel patches to be made of
>> basically one logical change, right?
>
> Yes, but note that these are mostly API additions for transactions that aren't used in the code quite yet. There are a couple of defines that get changed as well, but they aren't used yet either else they'd be accompanied by related code changes.
So NVM config read and write data structs aren't in use? anyway, this
way or another, I think we should stick to the practice of avoiding to
load few different changes on one patch
^ permalink raw reply
* Re: [PATCH] net: Add ndo_gso_check
From: Or Gerlitz @ 2015-01-15 18:18 UTC (permalink / raw)
To: Tom Herbert
Cc: Alexander Duyck, John Fastabend, Jeff Kirsher, David Miller,
Linux Netdev List, Thomas Graf, Pravin Shelar, Andy Zhou
In-Reply-To: <CA+mtBx9HMuMnsmN0rjqV9-5iK9H6b+J8OZQsmmbFHwjm+qW7bQ@mail.gmail.com>
On Mon, Oct 6, 2014 at 11:28 PM, Tom Herbert <therbert@google.com> wrote:
> On Mon, Oct 6, 2014 at 1:22 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
>> Are we going to have a session on the encapsulation/offloads design @ LPC?
> yes, I will talk about FOU and GUE implementation. You should
> abstracts in the schedule now.
Hi Tom, so that LPC discussion eventually didn't made it to happen...
I saw [1] you're planning (hopefully exiting) three parts discussion @
netdev01
I would strongly vote for his to be on the workshops/tutorials days,
i.e not limited to 45m or alike... and the 1st part you plan for an
updated reply of your LSK preso [2] which missed LPC?
[1] https://netdev01.org/news/22
[2] http://vger.kernel.org/encapsulation_offloads.pdf
>> I think a replay of your LKS presentation along with open discussion
>> on how to get there with the legacy requirements could be very
>> helpful.
^ permalink raw reply
* [PATCH net] ip: zero sockaddr returned on error queue
From: Willem de Bruijn @ 2015-01-15 18:18 UTC (permalink / raw)
To: netdev; +Cc: davem, Willem de Bruijn
From: Willem de Bruijn <willemb@google.com>
The sockaddr is returned in IP(V6)_RECVERR as part of errhdr. That
structure is defined and allocated on the stack as
struct {
struct sock_extended_err ee;
struct sockaddr_in(6) offender;
} errhdr;
The second part is only initialized for certain SO_EE_ORIGIN values.
Always initialize it completely.
An MTU exceeded error on a SOCK_RAW/IPPROTO_RAW is one example that
would return uninitialized bytes.
Signed-off-by: Willem de Bruijn <willemb@google.com>
----
Also verified that there is no padding between errhdr.ee and
errhdr.offender that could leak additional kernel data.
---
net/ipv4/ip_sockglue.c | 8 ++------
net/ipv6/datagram.c | 10 +++-------
2 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index 8a89c73..6b85adb 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -461,17 +461,13 @@ int ip_recv_error(struct sock *sk, struct msghdr *msg, int len, int *addr_len)
memcpy(&errhdr.ee, &serr->ee, sizeof(struct sock_extended_err));
sin = &errhdr.offender;
- sin->sin_family = AF_UNSPEC;
+ memset(sin, 0, sizeof(*sin));
if (serr->ee.ee_origin == SO_EE_ORIGIN_ICMP ||
ipv4_pktinfo_prepare_errqueue(sk, skb, serr->ee.ee_origin)) {
- struct inet_sock *inet = inet_sk(sk);
-
sin->sin_family = AF_INET;
sin->sin_addr.s_addr = ip_hdr(skb)->saddr;
- sin->sin_port = 0;
- memset(&sin->sin_zero, 0, sizeof(sin->sin_zero));
- if (inet->cmsg_flags)
+ if (inet_sk(sk)->cmsg_flags)
ip_cmsg_recv(msg, skb);
}
diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
index 100c589..49f5e73 100644
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -393,11 +393,10 @@ int ipv6_recv_error(struct sock *sk, struct msghdr *msg, int len, int *addr_len)
memcpy(&errhdr.ee, &serr->ee, sizeof(struct sock_extended_err));
sin = &errhdr.offender;
- sin->sin6_family = AF_UNSPEC;
+ memset(sin, 0, sizeof(*sin));
+
if (serr->ee.ee_origin != SO_EE_ORIGIN_LOCAL) {
sin->sin6_family = AF_INET6;
- sin->sin6_flowinfo = 0;
- sin->sin6_port = 0;
if (np->rxopt.all) {
if (serr->ee.ee_origin != SO_EE_ORIGIN_ICMP &&
serr->ee.ee_origin != SO_EE_ORIGIN_ICMP6)
@@ -412,12 +411,9 @@ int ipv6_recv_error(struct sock *sk, struct msghdr *msg, int len, int *addr_len)
ipv6_iface_scope_id(&sin->sin6_addr,
IP6CB(skb)->iif);
} else {
- struct inet_sock *inet = inet_sk(sk);
-
ipv6_addr_set_v4mapped(ip_hdr(skb)->saddr,
&sin->sin6_addr);
- sin->sin6_scope_id = 0;
- if (inet->cmsg_flags)
+ if (inet_sk(sk)->cmsg_flags)
ip_cmsg_recv(msg, skb);
}
}
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* Re: [PATCH net-next RFC 1/5] net-timestamp: no-payload option
From: Willem de Bruijn @ 2015-01-15 18:22 UTC (permalink / raw)
To: Richard Cochran
Cc: Network Development, David Miller, Eric Dumazet, Andy Lutomirski
In-Reply-To: <20150111202650.GB4214@localhost.localdomain>
On Sun, Jan 11, 2015 at 3:26 PM, Richard Cochran
<richardcochran@gmail.com> wrote:
> On Fri, Jan 09, 2015 at 12:31:55PM -0500, Willem de Bruijn wrote:
>> diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
>> index a317797..d81ef70 100644
>> --- a/net/ipv4/ip_sockglue.c
>> +++ b/net/ipv4/ip_sockglue.c
>> @@ -440,7 +440,7 @@ static bool ipv4_pktinfo_prepare_errqueue(const struct sock *sk,
>>
>> if ((ee_origin != SO_EE_ORIGIN_TIMESTAMPING) ||
>> (!(sk->sk_tsflags & SOF_TIMESTAMPING_OPT_CMSG)) ||
>> - (!skb->dev))
>> + (!skb->dev) || (!skb->len))
>> return false;
>
> Nit: You have already tested for the condition (!skb->len) ...
Thanks! I'll fix that when I send v1.
I had planned to do that today, but will hold off a bit to avoid merge
conflicts with a fix queued for net (http://patchwork.ozlabs.org/patch/429553/)
I will drop patches 4 and 5 when sending out v1, btw.
>
>>
>> info->ipi_spec_dst.s_addr = ip_hdr(skb)->saddr;
>> @@ -483,7 +483,7 @@ int ip_recv_error(struct sock *sk, struct msghdr *msg, int len, int *addr_len)
>>
>> serr = SKB_EXT_ERR(skb);
>>
>> - if (sin) {
>> + if (sin && skb->len) {
>> sin->sin_family = AF_INET;
>> sin->sin_addr.s_addr = *(__be32 *)(skb_network_header(skb) +
>> serr->addr_offset);
>> @@ -496,8 +496,9 @@ int ip_recv_error(struct sock *sk, struct msghdr *msg, int len, int *addr_len)
>> sin = &errhdr.offender;
>> sin->sin_family = AF_UNSPEC;
>>
>> - if (serr->ee.ee_origin == SO_EE_ORIGIN_ICMP ||
>> - ipv4_pktinfo_prepare_errqueue(sk, skb, serr->ee.ee_origin)) {
>> + if (skb->len &&
>> + (serr->ee.ee_origin == SO_EE_ORIGIN_ICMP ||
>> + ipv4_pktinfo_prepare_errqueue(sk, skb, serr->ee.ee_origin))) {
>
> ... here.
>
>> struct inet_sock *inet = inet_sk(sk);
>>
>> sin->sin_family = AF_INET;
>
> Thanks,
> Richard
^ 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