* Re: [PATCH v4 1/5] net: Introduce new feature setting ops
From: David Miller @ 2011-02-07 20:51 UTC (permalink / raw)
To: bhutchings; +Cc: mirq-linux, netdev
In-Reply-To: <1297107597.4077.8.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 07 Feb 2011 19:39:57 +0000
> On Thu, 2011-02-03 at 15:21 +0100, Michał Mirosław wrote:
>> This introduces a new framework to handle device features setting.
>> It consists of:
>> - new fields in struct net_device:
>> + hw_features - features that hw/driver supports toggling
>> + wanted_features - features that user wants enabled, when possible
>> - new netdev_ops:
>> + feat = ndo_fix_features(dev, feat) - API checking constraints for
>> enabling features or their combinations
>> + ndo_set_features(dev) - API updating hardware state to match
>> changed dev->features
>> - new ethtool commands:
>> + ETHTOOL_GFEATURES/ETHTOOL_SFEATURES: get/set dev->wanted_features
>> and trigger device reconfiguration if resulting dev->features
>> changed
>> + ETHTOOL_GSTRINGS(ETH_SS_FEATURES): get feature bits names (meaning)
>>
>> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/5] genirq: Add IRQ affinity notifiers
From: Ben Hutchings @ 2011-02-07 20:44 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: David Miller, netdev, linux-net-drivers, therbert
In-Reply-To: <alpine.LFD.2.00.1101221735080.31804@localhost6.localdomain6>
On Sat, 2011-01-22 at 17:38 +0100, Thomas Gleixner wrote:
> B1;2401;0cOn Wed, 19 Jan 2011, David Miller wrote:
> > You said you had stuff before Ben's patches, and that's why you needed
> > to provide me with an -rc1 relative version of his commits.
>
> I hope a rc2 relative version works as well :)
>
> > If that's not the case, then yes it would work just fine.
> >
> > Just give me the URL to pull from, thanks!
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git irq/numa
>
> @Ben: Your patch was pretty white space damaged. Please be more
> careful next time.
Oh, I see that struct irq_affinity_notify members were indented with
spaces; is that what you mean? Sorry, I've no idea how that happened.
Anyway, thanks for applying this.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] GRO: fix merging a paged skb after non-paged skbs
From: Ben Hutchings @ 2011-02-07 20:39 UTC (permalink / raw)
To: Michal Schmidt; +Cc: David Miller, netdev, Herbert Xu, linux-net-drivers
In-Reply-To: <1295918675.4105.5.camel@localhost>
On Tue, 2011-01-25 at 11:24 +1000, Ben Hutchings wrote:
> On Mon, 2011-01-24 at 18:47 +0100, Michal Schmidt wrote:
> > Suppose that several linear skbs of the same flow were received by GRO. They
> > were thus merged into one skb with a frag_list. Then a new skb of the same flow
> > arrives, but it is a paged skb with data starting in its frags[].
> >
> > Before adding the skb to the frag_list skb_gro_receive() will of course adjust
> > the skb to throw away the headers. It correctly modifies the page_offset and
> > size of the frag, but it leaves incorrect information in the skb:
> > ->data_len is not decreased at all.
> > ->len is decreased only by headlen, as if no change were done to the frag.
> > Later in a receiving process this causes skb_copy_datagram_iovec() to return
> > -EFAULT and this is seen in userspace as the result of the recv() syscall.
> >
> > In practice the bug can be reproduced with the sfc driver. By default the
> > driver uses an adaptive scheme when it switches between using
> > napi_gro_receive() (with skbs) and napi_gro_frags() (with pages). The bug is
> > reproduced when under rx load with enough successful GRO merging the driver
> > decides to switch from the former to the latter.
> [...]
>
> This is odd because I thought we made sure to flush before making such a
> change. Perhaps that got lost during the conversion from inet_lro to
> GRO?
That is indeed the case; commit da3bc07171dff957906cbe2ad5abb443eccf57c4
made the following deletions:
- /* Both our generic-LRO and SFC-SSR support skb and page based
- * allocation, but neither support switching from one to the
- * other on the fly. If we spot that the allocation mode has
- * changed, then flush the LRO state.
- */
- if (unlikely(channel->rx_alloc_pop_pages != (rx_buf->page != NULL))) {
- efx_flush_lro(channel);
- channel->rx_alloc_pop_pages = (rx_buf->page != NULL);
- }
Ben.
> Anyway, thanks very much for fixing this.
>
> Ben.
>
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH v4 3/5] net: use ndo_fix_features for ethtool_ops->set_flags
From: Ben Hutchings @ 2011-02-07 19:46 UTC (permalink / raw)
To: Michał Mirosław; +Cc: netdev
In-Reply-To: <bbe7e5742ffe44fb2938b7b6c2c656395fc361ac.1296741562.git.mirq-linux@rere.qmqm.pl>
On Thu, 2011-02-03 at 15:21 +0100, Michał Mirosław wrote:
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> ---
> net/core/ethtool.c | 31 +++++++++++++++++++++++++++++--
> 1 files changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
> index 555accf..6e7c6f2 100644
> --- a/net/core/ethtool.c
> +++ b/net/core/ethtool.c
> @@ -240,6 +240,34 @@ static int ethtool_set_features(struct net_device *dev, void __user *useraddr)
> return ret;
> }
>
> +static int __ethtool_set_flags(struct net_device *dev, u32 data)
> +{
> + u32 changed;
> +
> + if (data & ~flags_dup_features)
> + return -EINVAL;
> +
> + /* legacy set_flags() op */
> + if (dev->ethtool_ops->set_flags) {
> + if (unlikely(dev->hw_features & flags_dup_features))
> + netdev_warn(dev,
> + "driver BUG: mixed hw_features and set_flags()\n");
> + return dev->ethtool_ops->set_flags(dev, data);
> + }
> +
> + /* allow changing only bits set in hw_features */
> + changed = (data ^ dev->wanted_features) & flags_dup_features;
> + if (changed & ~dev->hw_features)
> + return -EOPNOTSUPP;
[...]
The error code should only be EOPNOTSUPP if (dev->hw_features &
flags_dup_features) == 0. Otherwise it should be EINVAL.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH 2/2] USB CDC NCM errata updates for cdc_ncm host driver
From: Alexey Orishko @ 2011-02-07 19:45 UTC (permalink / raw)
To: netdev; +Cc: linux-usb, davem, gregkh, yauheni.kaliuta, Alexey Orishko
In-Reply-To: <1297107910-18263-1-git-send-email-alexey.orishko@stericsson.com>
Specification links:
- CDC NCM errata link:
http://www.usb.org/developers/devclass_docs/NCM10_012011.zip
- CDC and WMC errata link:
http://www.usb.org/developers/devclass_docs/CDC1.2_WMC1.1_012011.zip
Changes:
- driver updated to match cdc.h header with errata changes
- added support for USB_CDC_SET_NTB_INPUT_SIZE control request with
8 byte length
- fixes to comply with specification: send only control requests supported by
device, set number of datagrams for IN direction, connection speed structure
update, etc.
- packet loss fixed for tx direction; misleading flag renamed.
- adjusted hard_mtu value.
Signed-off-by: Alexey Orishko <alexey.orishko@stericsson.com>
---
drivers/net/usb/cdc_ncm.c | 227 +++++++++++++++++++++++++++++----------------
1 files changed, 147 insertions(+), 80 deletions(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 04e8ce1..7113168 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1,7 +1,7 @@
/*
* cdc_ncm.c
*
- * Copyright (C) ST-Ericsson 2010
+ * Copyright (C) ST-Ericsson 2010-2011
* Contact: Alexey Orishko <alexey.orishko@stericsson.com>
* Original author: Hans Petter Selasky <hans.petter.selasky@stericsson.com>
*
@@ -54,7 +54,7 @@
#include <linux/usb/usbnet.h>
#include <linux/usb/cdc.h>
-#define DRIVER_VERSION "17-Jan-2011"
+#define DRIVER_VERSION "7-Feb-2011"
/* CDC NCM subclass 3.2.1 */
#define USB_CDC_NCM_NDP16_LENGTH_MIN 0x10
@@ -77,6 +77,9 @@
*/
#define CDC_NCM_DPT_DATAGRAMS_MAX 32
+/* Maximum amount of IN datagrams in NTB */
+#define CDC_NCM_DPT_DATAGRAMS_IN_MAX 0 /* unlimited */
+
/* Restart the timer, if amount of datagrams is less than given value */
#define CDC_NCM_RESTART_TIMER_DATAGRAM_CNT 3
@@ -85,11 +88,6 @@
(sizeof(struct usb_cdc_ncm_nth16) + sizeof(struct usb_cdc_ncm_ndp16) + \
(CDC_NCM_DPT_DATAGRAMS_MAX + 1) * sizeof(struct usb_cdc_ncm_dpe16))
-struct connection_speed_change {
- __le32 USBitRate; /* holds 3GPP downlink value, bits per second */
- __le32 DSBitRate; /* holds 3GPP uplink value, bits per second */
-} __attribute__ ((packed));
-
struct cdc_ncm_data {
struct usb_cdc_ncm_nth16 nth16;
struct usb_cdc_ncm_ndp16 ndp16;
@@ -198,10 +196,10 @@ static u8 cdc_ncm_setup(struct cdc_ncm_ctx *ctx)
{
struct usb_cdc_notification req;
u32 val;
- __le16 max_datagram_size;
u8 flags;
u8 iface_no;
int err;
+ u16 ntb_fmt_supported;
iface_no = ctx->control->cur_altsetting->desc.bInterfaceNumber;
@@ -223,6 +221,9 @@ static u8 cdc_ncm_setup(struct cdc_ncm_ctx *ctx)
ctx->tx_remainder = le16_to_cpu(ctx->ncm_parm.wNdpOutPayloadRemainder);
ctx->tx_modulus = le16_to_cpu(ctx->ncm_parm.wNdpOutDivisor);
ctx->tx_ndp_modulus = le16_to_cpu(ctx->ncm_parm.wNdpOutAlignment);
+ /* devices prior to NCM Errata shall set this field to zero */
+ ctx->tx_max_datagrams = le16_to_cpu(ctx->ncm_parm.wNtbOutMaxDatagrams);
+ ntb_fmt_supported = le16_to_cpu(ctx->ncm_parm.bmNtbFormatsSupported);
if (ctx->func_desc != NULL)
flags = ctx->func_desc->bmNetworkCapabilities;
@@ -231,22 +232,58 @@ static u8 cdc_ncm_setup(struct cdc_ncm_ctx *ctx)
pr_debug("dwNtbInMaxSize=%u dwNtbOutMaxSize=%u "
"wNdpOutPayloadRemainder=%u wNdpOutDivisor=%u "
- "wNdpOutAlignment=%u flags=0x%x\n",
+ "wNdpOutAlignment=%u wNtbOutMaxDatagrams=%u flags=0x%x\n",
ctx->rx_max, ctx->tx_max, ctx->tx_remainder, ctx->tx_modulus,
- ctx->tx_ndp_modulus, flags);
+ ctx->tx_ndp_modulus, ctx->tx_max_datagrams, flags);
- /* max count of tx datagrams without terminating NULL entry */
- ctx->tx_max_datagrams = CDC_NCM_DPT_DATAGRAMS_MAX;
+ /* max count of tx datagrams */
+ if ((ctx->tx_max_datagrams == 0) ||
+ (ctx->tx_max_datagrams > CDC_NCM_DPT_DATAGRAMS_MAX))
+ ctx->tx_max_datagrams = CDC_NCM_DPT_DATAGRAMS_MAX;
/* verify maximum size of received NTB in bytes */
- if ((ctx->rx_max <
- (CDC_NCM_MIN_HDR_SIZE + CDC_NCM_MIN_DATAGRAM_SIZE)) ||
- (ctx->rx_max > CDC_NCM_NTB_MAX_SIZE_RX)) {
+ if (ctx->rx_max < USB_CDC_NCM_NTB_MIN_IN_SIZE) {
+ pr_debug("Using min receive length=%d\n",
+ USB_CDC_NCM_NTB_MIN_IN_SIZE);
+ ctx->rx_max = USB_CDC_NCM_NTB_MIN_IN_SIZE;
+ }
+
+ if (ctx->rx_max > CDC_NCM_NTB_MAX_SIZE_RX) {
pr_debug("Using default maximum receive length=%d\n",
CDC_NCM_NTB_MAX_SIZE_RX);
ctx->rx_max = CDC_NCM_NTB_MAX_SIZE_RX;
}
+ /* inform device about NTB input size changes */
+ if (ctx->rx_max != le32_to_cpu(ctx->ncm_parm.dwNtbInMaxSize)) {
+ req.bmRequestType = USB_TYPE_CLASS | USB_DIR_OUT |
+ USB_RECIP_INTERFACE;
+ req.bNotificationType = USB_CDC_SET_NTB_INPUT_SIZE;
+ req.wValue = 0;
+ req.wIndex = cpu_to_le16(iface_no);
+
+ if (flags & USB_CDC_NCM_NCAP_NTB_INPUT_SIZE) {
+ struct usb_cdc_ncm_ndp_input_size ndp_in_sz;
+
+ req.wLength = 8;
+ ndp_in_sz.dwNtbInMaxSize = cpu_to_le32(ctx->rx_max);
+ ndp_in_sz.wNtbInMaxDatagrams =
+ cpu_to_le16(CDC_NCM_DPT_DATAGRAMS_MAX);
+ ndp_in_sz.wReserved = 0;
+ err = cdc_ncm_do_request(ctx, &req, &ndp_in_sz, 0, NULL,
+ 1000);
+ } else {
+ __le32 dwNtbInMaxSize = cpu_to_le32(ctx->rx_max);
+
+ req.wLength = 4;
+ err = cdc_ncm_do_request(ctx, &req, &dwNtbInMaxSize, 0,
+ NULL, 1000);
+ }
+
+ if (err)
+ pr_debug("Setting NTB Input Size failed\n");
+ }
+
/* verify maximum size of transmitted NTB in bytes */
if ((ctx->tx_max <
(CDC_NCM_MIN_HDR_SIZE + CDC_NCM_MIN_DATAGRAM_SIZE)) ||
@@ -297,47 +334,84 @@ static u8 cdc_ncm_setup(struct cdc_ncm_ctx *ctx)
/* additional configuration */
/* set CRC Mode */
- req.bmRequestType = USB_TYPE_CLASS | USB_DIR_OUT | USB_RECIP_INTERFACE;
- req.bNotificationType = USB_CDC_SET_CRC_MODE;
- req.wValue = cpu_to_le16(USB_CDC_NCM_CRC_NOT_APPENDED);
- req.wIndex = cpu_to_le16(iface_no);
- req.wLength = 0;
-
- err = cdc_ncm_do_request(ctx, &req, NULL, 0, NULL, 1000);
- if (err)
- pr_debug("Setting CRC mode off failed\n");
+ if (flags & USB_CDC_NCM_NCAP_CRC_MODE) {
+ req.bmRequestType = USB_TYPE_CLASS | USB_DIR_OUT |
+ USB_RECIP_INTERFACE;
+ req.bNotificationType = USB_CDC_SET_CRC_MODE;
+ req.wValue = cpu_to_le16(USB_CDC_NCM_CRC_NOT_APPENDED);
+ req.wIndex = cpu_to_le16(iface_no);
+ req.wLength = 0;
+
+ err = cdc_ncm_do_request(ctx, &req, NULL, 0, NULL, 1000);
+ if (err)
+ pr_debug("Setting CRC mode off failed\n");
+ }
- /* set NTB format */
- req.bmRequestType = USB_TYPE_CLASS | USB_DIR_OUT | USB_RECIP_INTERFACE;
- req.bNotificationType = USB_CDC_SET_NTB_FORMAT;
- req.wValue = cpu_to_le16(USB_CDC_NCM_NTB16_FORMAT);
- req.wIndex = cpu_to_le16(iface_no);
- req.wLength = 0;
+ /* set NTB format, if both formats are supported */
+ if (ntb_fmt_supported & USB_CDC_NCM_NTH32_SIGN) {
+ req.bmRequestType = USB_TYPE_CLASS | USB_DIR_OUT |
+ USB_RECIP_INTERFACE;
+ req.bNotificationType = USB_CDC_SET_NTB_FORMAT;
+ req.wValue = cpu_to_le16(USB_CDC_NCM_NTB16_FORMAT);
+ req.wIndex = cpu_to_le16(iface_no);
+ req.wLength = 0;
+
+ err = cdc_ncm_do_request(ctx, &req, NULL, 0, NULL, 1000);
+ if (err)
+ pr_debug("Setting NTB format to 16-bit failed\n");
+ }
- err = cdc_ncm_do_request(ctx, &req, NULL, 0, NULL, 1000);
- if (err)
- pr_debug("Setting NTB format to 16-bit failed\n");
+ ctx->max_datagram_size = CDC_NCM_MIN_DATAGRAM_SIZE;
/* set Max Datagram Size (MTU) */
- req.bmRequestType = USB_TYPE_CLASS | USB_DIR_IN | USB_RECIP_INTERFACE;
- req.bNotificationType = USB_CDC_GET_MAX_DATAGRAM_SIZE;
- req.wValue = 0;
- req.wIndex = cpu_to_le16(iface_no);
- req.wLength = cpu_to_le16(2);
+ if (flags & USB_CDC_NCM_NCAP_MAX_DATAGRAM_SIZE) {
+ __le16 max_datagram_size;
+ u16 eth_max_sz = le16_to_cpu(ctx->ether_desc->wMaxSegmentSize);
+
+ req.bmRequestType = USB_TYPE_CLASS | USB_DIR_IN |
+ USB_RECIP_INTERFACE;
+ req.bNotificationType = USB_CDC_GET_MAX_DATAGRAM_SIZE;
+ req.wValue = 0;
+ req.wIndex = cpu_to_le16(iface_no);
+ req.wLength = cpu_to_le16(2);
+
+ err = cdc_ncm_do_request(ctx, &req, &max_datagram_size, 0, NULL,
+ 1000);
+ if (err) {
+ pr_debug("GET_MAX_DATAGRAM_SIZE failed, use size=%u\n",
+ CDC_NCM_MIN_DATAGRAM_SIZE);
+ } else {
+ ctx->max_datagram_size = le16_to_cpu(max_datagram_size);
+ /* Check Eth descriptor value */
+ if (eth_max_sz < CDC_NCM_MAX_DATAGRAM_SIZE) {
+ if (ctx->max_datagram_size > eth_max_sz)
+ ctx->max_datagram_size = eth_max_sz;
+ } else {
+ if (ctx->max_datagram_size >
+ CDC_NCM_MAX_DATAGRAM_SIZE)
+ ctx->max_datagram_size =
+ CDC_NCM_MAX_DATAGRAM_SIZE;
+ }
- err = cdc_ncm_do_request(ctx, &req, &max_datagram_size, 0, NULL, 1000);
- if (err) {
- pr_debug(" GET_MAX_DATAGRAM_SIZE failed, using size=%u\n",
- CDC_NCM_MIN_DATAGRAM_SIZE);
- /* use default */
- ctx->max_datagram_size = CDC_NCM_MIN_DATAGRAM_SIZE;
- } else {
- ctx->max_datagram_size = le16_to_cpu(max_datagram_size);
+ if (ctx->max_datagram_size < CDC_NCM_MIN_DATAGRAM_SIZE)
+ ctx->max_datagram_size =
+ CDC_NCM_MIN_DATAGRAM_SIZE;
+
+ /* if value changed, update device */
+ req.bmRequestType = USB_TYPE_CLASS | USB_DIR_OUT |
+ USB_RECIP_INTERFACE;
+ req.bNotificationType = USB_CDC_SET_MAX_DATAGRAM_SIZE;
+ req.wValue = 0;
+ req.wIndex = cpu_to_le16(iface_no);
+ req.wLength = 2;
+ max_datagram_size = cpu_to_le16(ctx->max_datagram_size);
+
+ err = cdc_ncm_do_request(ctx, &req, &max_datagram_size,
+ 0, NULL, 1000);
+ if (err)
+ pr_debug("SET_MAX_DATAGRAM_SIZE failed\n");
+ }
- if (ctx->max_datagram_size < CDC_NCM_MIN_DATAGRAM_SIZE)
- ctx->max_datagram_size = CDC_NCM_MIN_DATAGRAM_SIZE;
- else if (ctx->max_datagram_size > CDC_NCM_MAX_DATAGRAM_SIZE)
- ctx->max_datagram_size = CDC_NCM_MAX_DATAGRAM_SIZE;
}
if (ctx->netdev->mtu != (ctx->max_datagram_size - ETH_HLEN))
@@ -466,19 +540,13 @@ static int cdc_ncm_bind(struct usbnet *dev, struct usb_interface *intf)
ctx->ether_desc =
(const struct usb_cdc_ether_desc *)buf;
-
dev->hard_mtu =
le16_to_cpu(ctx->ether_desc->wMaxSegmentSize);
- if (dev->hard_mtu <
- (CDC_NCM_MIN_DATAGRAM_SIZE - ETH_HLEN))
- dev->hard_mtu =
- CDC_NCM_MIN_DATAGRAM_SIZE - ETH_HLEN;
-
- else if (dev->hard_mtu >
- (CDC_NCM_MAX_DATAGRAM_SIZE - ETH_HLEN))
- dev->hard_mtu =
- CDC_NCM_MAX_DATAGRAM_SIZE - ETH_HLEN;
+ if (dev->hard_mtu < CDC_NCM_MIN_DATAGRAM_SIZE)
+ dev->hard_mtu = CDC_NCM_MIN_DATAGRAM_SIZE;
+ else if (dev->hard_mtu > CDC_NCM_MAX_DATAGRAM_SIZE)
+ dev->hard_mtu = CDC_NCM_MAX_DATAGRAM_SIZE;
break;
case USB_CDC_NCM_TYPE:
@@ -628,13 +696,13 @@ cdc_ncm_fill_tx_frame(struct cdc_ncm_ctx *ctx, struct sk_buff *skb)
u32 offset;
u32 last_offset;
u16 n = 0;
- u8 timeout = 0;
+ u8 ready2send = 0;
/* if there is a remaining skb, it gets priority */
if (skb != NULL)
swap(skb, ctx->tx_rem_skb);
else
- timeout = 1;
+ ready2send = 1;
/*
* +----------------+
@@ -682,9 +750,10 @@ cdc_ncm_fill_tx_frame(struct cdc_ncm_ctx *ctx, struct sk_buff *skb)
for (; n < ctx->tx_max_datagrams; n++) {
/* check if end of transmit buffer is reached */
- if (offset >= ctx->tx_max)
+ if (offset >= ctx->tx_max) {
+ ready2send = 1;
break;
-
+ }
/* compute maximum buffer size */
rem = ctx->tx_max - offset;
@@ -711,9 +780,7 @@ cdc_ncm_fill_tx_frame(struct cdc_ncm_ctx *ctx, struct sk_buff *skb)
}
ctx->tx_rem_skb = skb;
skb = NULL;
-
- /* loop one more time */
- timeout = 1;
+ ready2send = 1;
}
break;
}
@@ -756,7 +823,7 @@ cdc_ncm_fill_tx_frame(struct cdc_ncm_ctx *ctx, struct sk_buff *skb)
ctx->tx_curr_last_offset = last_offset;
goto exit_no_skb;
- } else if ((n < ctx->tx_max_datagrams) && (timeout == 0)) {
+ } else if ((n < ctx->tx_max_datagrams) && (ready2send == 0)) {
/* wait for more frames */
/* push variables */
ctx->tx_curr_skb = skb_out;
@@ -813,7 +880,7 @@ cdc_ncm_fill_tx_frame(struct cdc_ncm_ctx *ctx, struct sk_buff *skb)
cpu_to_le16(sizeof(ctx->tx_ncm.nth16));
ctx->tx_ncm.nth16.wSequence = cpu_to_le16(ctx->tx_seq);
ctx->tx_ncm.nth16.wBlockLength = cpu_to_le16(last_offset);
- ctx->tx_ncm.nth16.wFpIndex = ALIGN(sizeof(struct usb_cdc_ncm_nth16),
+ ctx->tx_ncm.nth16.wNdpIndex = ALIGN(sizeof(struct usb_cdc_ncm_nth16),
ctx->tx_ndp_modulus);
memcpy(skb_out->data, &(ctx->tx_ncm.nth16), sizeof(ctx->tx_ncm.nth16));
@@ -825,13 +892,13 @@ cdc_ncm_fill_tx_frame(struct cdc_ncm_ctx *ctx, struct sk_buff *skb)
rem = sizeof(ctx->tx_ncm.ndp16) + ((ctx->tx_curr_frame_num + 1) *
sizeof(struct usb_cdc_ncm_dpe16));
ctx->tx_ncm.ndp16.wLength = cpu_to_le16(rem);
- ctx->tx_ncm.ndp16.wNextFpIndex = 0; /* reserved */
+ ctx->tx_ncm.ndp16.wNextNdpIndex = 0; /* reserved */
- memcpy(((u8 *)skb_out->data) + ctx->tx_ncm.nth16.wFpIndex,
+ memcpy(((u8 *)skb_out->data) + ctx->tx_ncm.nth16.wNdpIndex,
&(ctx->tx_ncm.ndp16),
sizeof(ctx->tx_ncm.ndp16));
- memcpy(((u8 *)skb_out->data) + ctx->tx_ncm.nth16.wFpIndex +
+ memcpy(((u8 *)skb_out->data) + ctx->tx_ncm.nth16.wNdpIndex +
sizeof(ctx->tx_ncm.ndp16),
&(ctx->tx_ncm.dpe16),
(ctx->tx_curr_frame_num + 1) *
@@ -961,7 +1028,7 @@ static int cdc_ncm_rx_fixup(struct usbnet *dev, struct sk_buff *skb_in)
goto error;
}
- temp = le16_to_cpu(ctx->rx_ncm.nth16.wFpIndex);
+ temp = le16_to_cpu(ctx->rx_ncm.nth16.wNdpIndex);
if ((temp + sizeof(ctx->rx_ncm.ndp16)) > actlen) {
pr_debug("invalid DPT16 index\n");
goto error;
@@ -1048,10 +1115,10 @@ error:
static void
cdc_ncm_speed_change(struct cdc_ncm_ctx *ctx,
- struct connection_speed_change *data)
+ struct usb_cdc_speed_change *data)
{
- uint32_t rx_speed = le32_to_cpu(data->USBitRate);
- uint32_t tx_speed = le32_to_cpu(data->DSBitRate);
+ uint32_t rx_speed = le32_to_cpu(data->DLBitRRate);
+ uint32_t tx_speed = le32_to_cpu(data->ULBitRate);
/*
* Currently the USB-NET API does not support reporting the actual
@@ -1092,7 +1159,7 @@ static void cdc_ncm_status(struct usbnet *dev, struct urb *urb)
/* test for split data in 8-byte chunks */
if (test_and_clear_bit(EVENT_STS_SPLIT, &dev->flags)) {
cdc_ncm_speed_change(ctx,
- (struct connection_speed_change *)urb->transfer_buffer);
+ (struct usb_cdc_speed_change *)urb->transfer_buffer);
return;
}
@@ -1120,12 +1187,12 @@ static void cdc_ncm_status(struct usbnet *dev, struct urb *urb)
break;
case USB_CDC_NOTIFY_SPEED_CHANGE:
- if (urb->actual_length <
- (sizeof(*event) + sizeof(struct connection_speed_change)))
+ if (urb->actual_length < (sizeof(*event) +
+ sizeof(struct usb_cdc_speed_change)))
set_bit(EVENT_STS_SPLIT, &dev->flags);
else
cdc_ncm_speed_change(ctx,
- (struct connection_speed_change *) &event[1]);
+ (struct usb_cdc_speed_change *) &event[1]);
break;
default:
--
1.7.4
^ permalink raw reply related
* [PATCH 1/2] CDC NCM errata updates for cdc.h
From: Alexey Orishko @ 2011-02-07 19:45 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
gregkh-l3A5Bk7waGM, yauheni.kaliuta-xNZwKgViW5gAvxtiuMwx3w,
Alexey Orishko
Changes are based on the following documents:
- CDC NCM errata:
http://www.usb.org/developers/devclass_docs/NCM10_012011.zip
- CDC and WMC errata link:
http://www.usb.org/developers/devclass_docs/CDC1.2_WMC1.1_012011.zip
Signed-off-by: Alexey Orishko <alexey.orishko-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>
---
include/linux/usb/cdc.h | 23 ++++++++++++++++++-----
1 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/include/linux/usb/cdc.h b/include/linux/usb/cdc.h
index 5e86dc7..81a9279 100644
--- a/include/linux/usb/cdc.h
+++ b/include/linux/usb/cdc.h
@@ -89,7 +89,7 @@ struct usb_cdc_acm_descriptor {
#define USB_CDC_COMM_FEATURE 0x01
#define USB_CDC_CAP_LINE 0x02
-#define USB_CDC_CAP_BRK 0x04
+#define USB_CDC_CAP_BRK 0x04
#define USB_CDC_CAP_NOTIFY 0x08
/* "Union Functional Descriptor" from CDC spec 5.2.3.8 */
@@ -271,6 +271,11 @@ struct usb_cdc_notification {
__le16 wLength;
} __attribute__ ((packed));
+struct usb_cdc_speed_change {
+ __le32 DLBitRRate; /* contains the downlink bit rate (IN pipe) */
+ __le32 ULBitRate; /* contains the uplink bit rate (OUT pipe) */
+} __attribute__ ((packed));
+
/*-------------------------------------------------------------------------*/
/*
@@ -292,7 +297,7 @@ struct usb_cdc_ncm_ntb_parameters {
__le16 wNdpOutDivisor;
__le16 wNdpOutPayloadRemainder;
__le16 wNdpOutAlignment;
- __le16 wPadding2;
+ __le16 wNtbOutMaxDatagrams;
} __attribute__ ((packed));
/*
@@ -307,7 +312,7 @@ struct usb_cdc_ncm_nth16 {
__le16 wHeaderLength;
__le16 wSequence;
__le16 wBlockLength;
- __le16 wFpIndex;
+ __le16 wNdpIndex;
} __attribute__ ((packed));
struct usb_cdc_ncm_nth32 {
@@ -315,7 +320,7 @@ struct usb_cdc_ncm_nth32 {
__le16 wHeaderLength;
__le16 wSequence;
__le32 dwBlockLength;
- __le32 dwFpIndex;
+ __le32 dwNdpIndex;
} __attribute__ ((packed));
/*
@@ -337,7 +342,7 @@ struct usb_cdc_ncm_dpe16 {
struct usb_cdc_ncm_ndp16 {
__le32 dwSignature;
__le16 wLength;
- __le16 wNextFpIndex;
+ __le16 wNextNdpIndex;
struct usb_cdc_ncm_dpe16 dpe16[0];
} __attribute__ ((packed));
@@ -375,6 +380,7 @@ struct usb_cdc_ncm_ndp32 {
#define USB_CDC_NCM_NCAP_ENCAP_COMMAND (1 << 2)
#define USB_CDC_NCM_NCAP_MAX_DATAGRAM_SIZE (1 << 3)
#define USB_CDC_NCM_NCAP_CRC_MODE (1 << 4)
+#define USB_CDC_NCM_NCAP_NTB_INPUT_SIZE (1 << 5)
/* CDC NCM subclass Table 6-3: NTB Parameter Structure */
#define USB_CDC_NCM_NTB16_SUPPORTED (1 << 0)
@@ -392,6 +398,13 @@ struct usb_cdc_ncm_ndp32 {
#define USB_CDC_NCM_NTB_MIN_IN_SIZE 2048
#define USB_CDC_NCM_NTB_MIN_OUT_SIZE 2048
+/* NTB Input Size Structure */
+struct usb_cdc_ncm_ndp_input_size {
+ __le32 dwNtbInMaxSize;
+ __le16 wNtbInMaxDatagrams;
+ __le16 wReserved;
+} __attribute__ ((packed));
+
/* CDC NCM subclass 6.2.11 SetCrcMode */
#define USB_CDC_NCM_CRC_NOT_APPENDED 0x00
#define USB_CDC_NCM_CRC_APPENDED 0x01
--
1.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 related
* Re: [PATCH v4 1/5] net: Introduce new feature setting ops
From: Ben Hutchings @ 2011-02-07 19:39 UTC (permalink / raw)
To: Michał Mirosław; +Cc: netdev
In-Reply-To: <9327efbf43fadeadd7017926962c65c95288d50e.1296741561.git.mirq-linux@rere.qmqm.pl>
On Thu, 2011-02-03 at 15:21 +0100, Michał Mirosław wrote:
> This introduces a new framework to handle device features setting.
> It consists of:
> - new fields in struct net_device:
> + hw_features - features that hw/driver supports toggling
> + wanted_features - features that user wants enabled, when possible
> - new netdev_ops:
> + feat = ndo_fix_features(dev, feat) - API checking constraints for
> enabling features or their combinations
> + ndo_set_features(dev) - API updating hardware state to match
> changed dev->features
> - new ethtool commands:
> + ETHTOOL_GFEATURES/ETHTOOL_SFEATURES: get/set dev->wanted_features
> and trigger device reconfiguration if resulting dev->features
> changed
> + ETHTOOL_GSTRINGS(ETH_SS_FEATURES): get feature bits names (meaning)
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/5] enic: updates to version 2.1.1.6
From: David Miller @ 2011-02-07 19:39 UTC (permalink / raw)
To: vkolluri; +Cc: netdev
In-Reply-To: <212AA327A3557741A058E787E06188730549170E@xmb-sjc-219.amer.cisco.com>
From: "Vasanthy Kolluri (vkolluri)" <vkolluri@cisco.com>
Date: Mon, 7 Feb 2011 11:32:08 -0800
> Hi David,
>
> The below patch series should apply clean on top of another enic patch
> "enic: Decouple mac address registration and deregistration from port
> profile set operation" submitted earlier by roprabhu@cisco.com. Just
> want to ensure that it's not missed.
>
> Please let me know if there is still a need to re-spin.
How in the world was I supposed to know about this dependency?
Tell me.
^ permalink raw reply
* Re: [PATCH 00/20] world-writable files in sysfs and debugfs
From: Matthew Garrett @ 2011-02-07 19:38 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: linux-kernel, linux-omap, linux-arm-kernel, linux-usb,
linux-media, socketcan-core, netdev, platform-driver-x86,
acpi4asus-user, rtc-linux, linux-scsi, open-iscsi, linux-mtd,
security
In-Reply-To: <20110204140033.GA31184@albatros>
Thanks, I've applied the x86 platform driver ones.
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* RE: [net-next-2.6 PATCH 0/5] enic: updates to version 2.1.1.6
From: Vasanthy Kolluri (vkolluri) @ 2011-02-07 19:32 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110206.111856.39183676.davem@davemloft.net>
Hi David,
The below patch series should apply clean on top of another enic patch
"enic: Decouple mac address registration and deregistration from port
profile set operation" submitted earlier by roprabhu@cisco.com. Just
want to ensure that it's not missed.
Please let me know if there is still a need to re-spin.
Thanks
Vasanthy
-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
On Behalf Of David Miller
Sent: Sunday, February 06, 2011 11:19 AM
To: Vasanthy Kolluri (vkolluri)
Cc: netdev@vger.kernel.org
Subject: Re: [net-next-2.6 PATCH 0/5] enic: updates to version 2.1.1.6
From: Vasanthy Kolluri <vkolluri@cisco.com>
Date: Fri, 04 Feb 2011 18:17:00 -0800
> The following series implements enic driver updates:
>
> 1/5 - Clean up: Organize devcmd wrapper routines
> 2/5 - Bug Fix: Fix return values of enic_add/del_station_addr routines
> 3/5 - Bug Fix: Reorder firmware devcmds - CMD_INIT and
CMD_IG_VLAN_REWRITE_MODE
> 4/5 - Clean up: Remove support for an older version of hardware
> 5/5 - Update MAINTAINERS
>
> Signed-off-by: Christian Benvenuti <benve@cisco.com>
> Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com>
> Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>
> Signed-off-by: David Wang <dwang2@cisco.com>
These patches do not apply cleanly to current net-next-2.6, please
respin them.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] bonding/vlan: Avoid mangled NAs on slaves without VLAN tag insertion
From: Ben Hutchings @ 2011-02-07 19:20 UTC (permalink / raw)
To: stable; +Cc: Jay Vosburgh, David Miller, netdev, bonding-devel
This is related to commit f88a4a9b65a6f3422b81be995535d0e69df11bb8
upstream, but the bug cannot be properly fixed without the other
changes to VLAN tagging in 2.6.37.
bond_na_send() attempts to insert a VLAN tag in between building and
sending packets of the respective formats. If the slave does not
implement hardware VLAN tag insertion then vlan_put_tag() will mangle
the network-layer header because the Ethernet header is not present at
this point (unlike in bond_arp_send()).
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
This fix is applicable to versions [2.6.29, 2.6.36]. The context for
the second hunk needs to be reduced to 1 line for versions < 2.6.33
(git am -C1) as the logging call was changed.
Ben.
drivers/net/bonding/bond_ipv6.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/net/bonding/bond_ipv6.c b/drivers/net/bonding/bond_ipv6.c
index 121b073..78eb5fa 100644
--- a/drivers/net/bonding/bond_ipv6.c
+++ b/drivers/net/bonding/bond_ipv6.c
@@ -70,6 +70,13 @@ static void bond_na_send(struct net_device *slave_dev,
};
struct sk_buff *skb;
+ /* The Ethernet header is built in ndisc_send_skb(), not
+ * ndisc_build_skb(), so we cannot insert a VLAN tag. Only an
+ * out-of-line tag inserted by the hardware will work.
+ */
+ if (vlan_id && !(slave_dev->features & NETIF_F_HW_VLAN_TX))
+ return;
+
icmp6h.icmp6_router = router;
icmp6h.icmp6_solicited = 0;
icmp6h.icmp6_override = 1;
@@ -88,7 +95,7 @@ static void bond_na_send(struct net_device *slave_dev,
}
if (vlan_id) {
- skb = vlan_put_tag(skb, vlan_id);
+ skb = __vlan_hwaccel_put_tag(skb, vlan_id);
if (!skb) {
pr_err("failed to insert VLAN tag\n");
return;
--
1.7.2.3
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* Trouble Shooting ipsec
From: Stephen Clark @ 2011-02-07 19:17 UTC (permalink / raw)
To: Linux Kernel Network Developers
Hello,
How do I find out what is happening to my packets thru my ipsec tunnel.
They just seem to disappear on the remote side.
I have successfully got the pings thru
when everything has an ipv6 address, but am not successful when trying
to connect two ipv4 lans across an ipv6 ipsec tunnel. All fw chains both
4 and 6
are set to ACCEPT. NAT is turned off.
eth0 eth1
eth1 eth0
10.1.254.254/17 2001:xxxx:1628::254 <----ipv6 internet ----->
2001:xxxx:e334::254 10.0.254.254/17
12:00:02.296972 IP6 2001:xxxx:1628::254 > 2001:xxxx:e334::254:
ESP(spi=0x07454bc3,seq=0x28b), length 132
12:00:03.308751 IP6 2001:xxxx:1628::254 > 2001:xxxx:e334::254:
ESP(spi=0x07454bc3,seq=0x28c), length 132
12:00:04.296857 IP6 2001:xxxx:1628::254 > 2001:xxxx:e334::254:
ESP(spi=0x07454bc3,seq=0x28d), length 132
12:00:05.293748 IP6 2001:xxxx:1628::254 > 2001:xxxx:e334::254:
ESP(spi=0x07454bc3,seq=0x28e), length 132
12:00:06.296623 IP6 2001:xxxx:1628::254 > 2001:xxxx:e334::254:
ESP(spi=0x07454bc3,seq=0x28f), length 132
I have posted to the ipsec-devel list and haven't gotten any responses.
Also I have spent 2 days googling with
no results about the above setup. Is it even possible to tunnel ipv4
packet thru an ipv6 ipsec tunnel?
Thanks,
Steve
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
^ permalink raw reply
* BUG? behaviour mismatch between ipv4 and ipv6 in UDP rx path
From: Chris Friesen @ 2011-02-07 18:29 UTC (permalink / raw)
To: netdev, Linux Kernel Mailing List, pekkas, davem, yoshfuji
Hi,
One of our guys is seeing occasional dropped ipv4 packets coming in on
an ipv6 udp socket obtained via socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP).
Here's what he says:
"The problem happens when release_sock() goes down an interesting code
path. If (sk->sk_backlog.tail) is non-NULL then release_sock() invokes
__release_sock() which loops over all queue packets and invokes the
socket's backlog receive function for each previously queued packet.
Now for the interesting part. The UDPv6 backlog receive function (in
net/ipv6/udp.c, udpv6_queue_rcv_skb()) invokes xfrm6_policy_check() to
confirm that the packet is allowed, but the problem is that it calls
this function regardless of whether the packet is IPv4 or IPv6. The
xfrm6_policy_check() function then assumes that it is an IPv6 packet and
tries to match a policy based on its packet header... but that clearly
won't work because the addresses that it finds when it decodes the skb
are completely bogus."
Looking at the ipv4 code, git commit 9382177 split __udp_queue_rcv_skb()
out of udp_queue_rcv_skb(). It was done for locking purposes, but it
also means that backlog_rcv is bound to __udp_queue_rcv_skb(), which
doesn't call xfrm4_policy_check().
Should a new function __udpv6_queue_rcv_skb() be split out from
udpv6_queue_rcv_skb() and bound to backlog_rcv to resolve the xfrm
issue? What about the locking that was the reason for the split in the
ipv4 case--is there a similar problem with ipv6?
Thanks,
Chris
--
Chris Friesen
Software Developer
GENBAND
chris.friesen@genband.com
www.genband.com
^ permalink raw reply
* RE: [net-next-2.6 2/3] igb: add support for VF Transmit rate limit using iproute2
From: Levy, Lior @ 2011-02-07 18:08 UTC (permalink / raw)
To: David Miller, Kirsher, Jeffrey T
Cc: netdev@vger.kernel.org, gospo@redhat.com, bphilips@novell.com
In-Reply-To: <20110128.163817.193721063.davem@davemloft.net>
Thank you Dave for your input.
I agree that there isn't a very good reason to log these messages.
People can use the "ip show" command to query the TX rate limit for each vf.
BTW - this feature is being configured via iproute2 and not ethtool. But still the concept is the same.
We'll re-submit the patch soon.
Regards,
Lior.
-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On Behalf Of David Miller
Sent: Friday, January 28, 2011 4:38 PM
To: Kirsher, Jeffrey T
Cc: Levy, Lior; netdev@vger.kernel.org; gospo@redhat.com; bphilips@novell.com
Subject: Re: [net-next-2.6 2/3] igb: add support for VF Transmit rate limit using iproute2
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 28 Jan 2011 04:29:38 -0800
> + if (tx_rate != 0)
> + dev_info(&adapter->pdev->dev,
> + "Setting Transmit rate of %d Mbps for VF %d\n",
> + tx_rate, vf);
> + else
> + dev_info(&adapter->pdev->dev,
> + "Transmit rate limit for VF %d is disabled\n", vf);
If you're going to print this, use netdev_info(netdev, ...).
But I think you shouldn't be logging anything at all.
No other ethtool operation logs what it did except in extremely
exceptional error conditions. And there is nothing special
about this VF rate limiting ethtool operation to justify these
extraneous logging messages.
If people want to know if the VF is rate limited, and by how much,
then can query the configuration using ethtool.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: About bittiming calculation result
From: Wolfgang Grandegger @ 2011-02-07 15:52 UTC (permalink / raw)
To: Tomoya MORINAGA
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4D4FDEF9.2030305-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On 02/07/2011 01:00 PM, Wolfgang Grandegger wrote:
> Hi Tomoya,
>
> On 02/07/2011 12:38 PM, Tomoya MORINAGA wrote:
>> Hi,
>>
>> I have a question for bittiming-value calculated by Can-core.
>>
>> In case setting like below,
>> - ip link set can0 type can bitrate 800000
>> - clock=50MHz
>> - Use pch_can
>>
>> Can-core calculates like below
>> brp=21
>> seg1=1
>> seg2=1
>> sjw=1
>> prop_seg=0
>>
>> Is "prop_seg=0" true ?
>
> Well, only prop_seg+phase_seg=tseg1 is relevant and the pch_can driver
> sets the allowed minimum "tseg1_min1" currently to 1:
>
> static struct can_bittiming_const pch_can_bittiming_const = {
> .name = KBUILD_MODNAME,
> .tseg1_min = 1,
> .tseg1_max = 16,
> .tseg2_min = 1,
> .tseg2_max = 8,
> .sjw_max = 4,
> .brp_min = 1,
> .brp_max = 1024, /* 6bit + extended 4bit */
> .brp_inc = 1,
> };
>
>> seg1/seg2/sjw/prop_seg must be more than 1 ?
>
> Then "tseg1_min" should be set to *2*.
>
>> Also I can see the following kernel error log.
>> bitrate error 0.7%
>
> A clock frequency of 50 MHz is sub-optimal for CAN and some
> bit-rates cannot be reproduced properly. Here is the output of
> the can-utils program "can-calc-bit-timing" (with an entry for
> the pch-can added):
>
> $ ./can-calc-bit-timing pch-can
> Bit timing parameters for pch-can with 50.000000 MHz ref clock
> nominal real Bitrt nom real SampP
> Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP Bitrate Error SampP SampP Error CNF1 CNF2 CNF3
> 1000000 100 3 3 3 1 5 1000000 0.0% 75.0% 70.0% 6.7% 0x05 0x92 0x02
> 800000 420 0 1 1 1 21 793650 0.8% 80.0% 66.6% 16.8% 0x15 0xff 0x00
> 500000 100 8 8 3 1 5 500000 0.0% 87.5% 85.0% 2.9% 0x05 0xbf 0x02
> 250000 500 3 3 1 1 25 250000 0.0% 87.5% 87.5% 0.0% 0x19 0x92 0x00
> 125000 500 6 7 2 1 25 125000 0.0% 87.5% 87.5% 0.0% 0x19 0xb5 0x01
> 100000 500 8 8 3 1 25 100000 0.0% 87.5% 85.0% 2.9% 0x19 0xbf 0x02
> 50000 2500 3 3 1 1 125 50000 0.0% 87.5% 87.5% 0.0% 0x7d 0x92 0x00
> 20000 2500 8 8 3 1 125 20000 0.0% 87.5% 85.0% 2.9% 0x7d 0xbf 0x02
> 10000 12500 3 3 1 1 625 10000 0.0% 87.5% 87.5% 0.0% 0x71 0x92 0x00
>
> As you can see, especially 800000 gives rather bad results.
BTW, it's always possible to specify optimized bit-timing parameters
directly, e.g. the following seem better:
800000 60 12 4 4 4 3 793650 0.8% 80.0% 81.0% 1.2%
You could set these with:
$ ip link set can0 type can \
tq 60 prop-seg 12 phase-seg1 4 phase-seg2 4 sjw 4
Wolfgang.
^ permalink raw reply
* Re: 6to4 NAT ?
From: Matthias Urlichs @ 2011-02-07 13:55 UTC (permalink / raw)
To: Jasper Spaans; +Cc: netdev
In-Reply-To: <20110207124138.GW3731@deee.intern.smurf.noris.de>
Hello,
> Sounds to me like you're looking for nat64. No built in support is
> available afaik, but http://ecdysis.viagenie.ca/ provides a netfilter
> module.
Alternately, there seems to be a stateless program which does the same
thing via a TUN interface:
http://www.litech.org/tayga/
This solutions seems superior to the ecdysis kernel module because
* stateless
* no out-of-tree kernel code with concurrency issues
* while it's userland code, I don't expect to have much traffic
* it can support multiple IPv4 networks on one system
(we have customers with overlapping RFC1912 address ranges)
* more flexible deployment
--
-- Matthias Urlichs
^ permalink raw reply
* Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX
From: Nicolas de Pesloüan @ 2011-02-07 12:09 UTC (permalink / raw)
To: chriss; +Cc: netdev, Simon Arlott
In-Reply-To: <loom.20110206T203347-475@post.gmane.org>
Le 06/02/2011 20:37, chriss a écrit :
> Jesse Gross<jesse<at> nicira.com> writes:
>
>>
>> You should either attached a bridge to a vlan device or stack a vlan
>> device on the bridge port depending on what you are trying to achieve.
>>
>> The bridge handler takes all packets of the device that it is attached
>> to, so having a vlan also attached to the same device will not work.
>> You may get different results on older kernels depending on what NIC
>> you were using but that was a bug.
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo<at> vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>
>
> Hi and thanks for your reply
>
> I tried that.
>
> I had under 2.6.36.3 following combination:
>
> eth1 in br0 -> all traffic without vlan id
> eth1.3 -> traffic with vlan 3
>
> with 2.6.37 i should do the following
> eth1 in br0 -> traffic w/o vlans
> and br0.3 -> traffic with vlan id 3
>
> But still there is no rx for vlan 3.
> Any suggestions? Or am i missing something?
I think you should have a look at ebtables command, in particular, the BROUTING chain of broute
table. If this chain ask the packet to be dropped, then bridge will ignore it and give a chance to
the upper layer to use it. Upper layer might be IP, or in your particular setup, VLAN.
HTH,
Nicolas.
In order for eth1.3 to receive the traffic with VLANID=3, while having the bridge get everything
else, you should add an entry to the
^ permalink raw reply
* Re: About bittiming calculation result
From: Wolfgang Grandegger @ 2011-02-07 12:00 UTC (permalink / raw)
To: Tomoya MORINAGA
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5009516791F146C49C73FAC57C437313-c0cKtqp5df7I9507bXv2FdBPR1lH4CV8@public.gmane.org>
Hi Tomoya,
On 02/07/2011 12:38 PM, Tomoya MORINAGA wrote:
> Hi,
>
> I have a question for bittiming-value calculated by Can-core.
>
> In case setting like below,
> - ip link set can0 type can bitrate 800000
> - clock=50MHz
> - Use pch_can
>
> Can-core calculates like below
> brp=21
> seg1=1
> seg2=1
> sjw=1
> prop_seg=0
>
> Is "prop_seg=0" true ?
Well, only prop_seg+phase_seg=tseg1 is relevant and the pch_can driver
sets the allowed minimum "tseg1_min1" currently to 1:
static struct can_bittiming_const pch_can_bittiming_const = {
.name = KBUILD_MODNAME,
.tseg1_min = 1,
.tseg1_max = 16,
.tseg2_min = 1,
.tseg2_max = 8,
.sjw_max = 4,
.brp_min = 1,
.brp_max = 1024, /* 6bit + extended 4bit */
.brp_inc = 1,
};
> seg1/seg2/sjw/prop_seg must be more than 1 ?
Then "tseg1_min" should be set to *2*.
> Also I can see the following kernel error log.
> bitrate error 0.7%
A clock frequency of 50 MHz is sub-optimal for CAN and some
bit-rates cannot be reproduced properly. Here is the output of
the can-utils program "can-calc-bit-timing" (with an entry for
the pch-can added):
$ ./can-calc-bit-timing pch-can
Bit timing parameters for pch-can with 50.000000 MHz ref clock
nominal real Bitrt nom real SampP
Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP Bitrate Error SampP SampP Error CNF1 CNF2 CNF3
1000000 100 3 3 3 1 5 1000000 0.0% 75.0% 70.0% 6.7% 0x05 0x92 0x02
800000 420 0 1 1 1 21 793650 0.8% 80.0% 66.6% 16.8% 0x15 0xff 0x00
500000 100 8 8 3 1 5 500000 0.0% 87.5% 85.0% 2.9% 0x05 0xbf 0x02
250000 500 3 3 1 1 25 250000 0.0% 87.5% 87.5% 0.0% 0x19 0x92 0x00
125000 500 6 7 2 1 25 125000 0.0% 87.5% 87.5% 0.0% 0x19 0xb5 0x01
100000 500 8 8 3 1 25 100000 0.0% 87.5% 85.0% 2.9% 0x19 0xbf 0x02
50000 2500 3 3 1 1 125 50000 0.0% 87.5% 87.5% 0.0% 0x7d 0x92 0x00
20000 2500 8 8 3 1 125 20000 0.0% 87.5% 85.0% 2.9% 0x7d 0xbf 0x02
10000 12500 3 3 1 1 625 10000 0.0% 87.5% 87.5% 0.0% 0x71 0x92 0x00
As you can see, especially 800000 gives rather bad results.
Wolfgang.
^ permalink raw reply
* About bittiming calculation result
From: Tomoya MORINAGA @ 2011-02-07 11:38 UTC (permalink / raw)
To: wg, socketcan-core; +Cc: netdev, linux-kernel
In-Reply-To: <20110204.130649.112613896.davem@davemloft.net>
Hi,
I have a question for bittiming-value calculated by Can-core.
In case setting like below,
- ip link set can0 type can bitrate 800000
- clock=50MHz
- Use pch_can
Can-core calculates like below
brp=21
seg1=1
seg2=1
sjw=1
prop_seg=0
Is "prop_seg=0" true ?
seg1/seg2/sjw/prop_seg must be more than 1 ?
Also I can see the following kernel error log.
bitrate error 0.7%
Thanks,
-----------------------------------------
Tomoya MORINAGA
OKI SEMICONDUCTOR CO., LTD.
^ permalink raw reply
* Re: 6to4 NAT ?
From: Jasper Spaans @ 2011-02-07 10:27 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: netdev@vger.kernel.org
In-Reply-To: <iiofpe$1j4$1@dough.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 580 bytes --]
On 07/02/11 10:59, Matthias Urlichs wrote:
> The problem: I have a 10.*/8 ipv4 network which I want to reach via ipv6.
> I.e., what I need is some sort of 6to4 NAT so that traffic from [whereever]
> to e.g. fec0:dead:beef:1234::10.1.2.3 ends up as coming from e.g. 10.0.0.1
> on the IPv4 side.
Sounds to me like you're looking for nat64. No built in support is
available afaik, but http://ecdysis.viagenie.ca/ provides a netfilter
module.
Cheers,
Jasper
--
Ir. Jasper Spaans
Fox-IT Experts in IT Security!
T: +31 (0) 15 284 79 99
KvK Haaglanden 27301624
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4121 bytes --]
^ permalink raw reply
* Re: x25: possible skb leak on bad facilities
From: Andrew Hendry @ 2011-02-07 10:08 UTC (permalink / raw)
To: David Miller; +Cc: apw, john, linux-x25, netdev, linux-kernel, tim.gardner
In-Reply-To: <AANLkTik8hg5G2FYDCoRgh72v-_euGWKix9Fxm89UdXie@mail.gmail.com>
Originally x25_parse_facilities returned
-1 for an error
0 meaning 0 length facilities
>0 the length of the facilities parsed.
5ef41308f94dc introduced more error checking in x25_parse_facilities
however used 0 to indicate bad parsing
a6331d6f9a429 followed this further for DTE facilities, again using 0 for bad parsing.
The meaning of 0 got confused in the callers.
If the facilities are messed up we can't determine where the data starts.
So patch makes all parsing errors return -1 and ensures callers close and don't use the skb further.
Reported-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Andrew Hendry <andrew.hendry@gmail.com>
---
net/x25/x25_facilities.c | 28 +++++++++++++++++++---------
net/x25/x25_in.c | 14 +++++++++++---
2 files changed, 30 insertions(+), 12 deletions(-)
diff --git a/net/x25/x25_facilities.c b/net/x25/x25_facilities.c
index 55187c8..4062075 100644
--- a/net/x25/x25_facilities.c
+++ b/net/x25/x25_facilities.c
@@ -27,9 +27,19 @@
#include <net/sock.h>
#include <net/x25.h>
-/*
- * Parse a set of facilities into the facilities structures. Unrecognised
- * facilities are written to the debug log file.
+/**
+ * x25_parse_facilities - Parse facilities from skb into the facilities structs
+ *
+ * @skb: sk_buff to parse
+ * @facilities: Regular facilites, updated as facilities are found
+ * @dte_facs: ITU DTE facilities, updated as DTE facilities are found
+ * @vc_fac_mask: mask is updated with all facilities found
+ *
+ * Return codes:
+ * -1 - Parsing error, caller should drop call and clean up
+ * 0 - Parse OK, this skb has no facilities
+ * >0 - Parse OK, returns the length of the facilities header
+ *
*/
int x25_parse_facilities(struct sk_buff *skb, struct x25_facilities *facilities,
struct x25_dte_facilities *dte_facs, unsigned long *vc_fac_mask)
@@ -62,7 +72,7 @@ int x25_parse_facilities(struct sk_buff *skb, struct x25_facilities *facilities,
switch (*p & X25_FAC_CLASS_MASK) {
case X25_FAC_CLASS_A:
if (len < 2)
- return 0;
+ return -1;
switch (*p) {
case X25_FAC_REVERSE:
if((p[1] & 0x81) == 0x81) {
@@ -107,7 +117,7 @@ int x25_parse_facilities(struct sk_buff *skb, struct x25_facilities *facilities,
break;
case X25_FAC_CLASS_B:
if (len < 3)
- return 0;
+ return -1;
switch (*p) {
case X25_FAC_PACKET_SIZE:
facilities->pacsize_in = p[1];
@@ -130,7 +140,7 @@ int x25_parse_facilities(struct sk_buff *skb, struct x25_facilities *facilities,
break;
case X25_FAC_CLASS_C:
if (len < 4)
- return 0;
+ return -1;
printk(KERN_DEBUG "X.25: unknown facility %02X, "
"values %02X, %02X, %02X\n",
p[0], p[1], p[2], p[3]);
@@ -139,18 +149,18 @@ int x25_parse_facilities(struct sk_buff *skb, struct x25_facilities *facilities,
break;
case X25_FAC_CLASS_D:
if (len < p[1] + 2)
- return 0;
+ return -1;
switch (*p) {
case X25_FAC_CALLING_AE:
if (p[1] > X25_MAX_DTE_FACIL_LEN || p[1] <= 1)
- return 0;
+ return -1;
dte_facs->calling_len = p[2];
memcpy(dte_facs->calling_ae, &p[3], p[1] - 1);
*vc_fac_mask |= X25_MASK_CALLING_AE;
break;
case X25_FAC_CALLED_AE:
if (p[1] > X25_MAX_DTE_FACIL_LEN || p[1] <= 1)
- return 0;
+ return -1;
dte_facs->called_len = p[2];
memcpy(dte_facs->called_ae, &p[3], p[1] - 1);
*vc_fac_mask |= X25_MASK_CALLED_AE;
diff --git a/net/x25/x25_in.c b/net/x25/x25_in.c
index f729f02..15de65f 100644
--- a/net/x25/x25_in.c
+++ b/net/x25/x25_in.c
@@ -91,10 +91,10 @@ static int x25_state1_machine(struct sock *sk, struct sk_buff *skb, int frametyp
{
struct x25_address source_addr, dest_addr;
int len;
+ struct x25_sock *x25 = x25_sk(sk);
switch (frametype) {
case X25_CALL_ACCEPTED: {
- struct x25_sock *x25 = x25_sk(sk);
x25_stop_timer(sk);
x25->condition = 0x00;
@@ -113,14 +113,16 @@ static int x25_state1_machine(struct sock *sk, struct sk_buff *skb, int frametyp
&dest_addr);
if (len > 0)
skb_pull(skb, len);
+ else if (len < 0)
+ goto out_clear;
len = x25_parse_facilities(skb, &x25->facilities,
&x25->dte_facilities,
&x25->vc_facil_mask);
if (len > 0)
skb_pull(skb, len);
- else
- return -1;
+ else if (len < 0)
+ goto out_clear;
/*
* Copy any Call User Data.
*/
@@ -144,6 +146,12 @@ static int x25_state1_machine(struct sock *sk, struct sk_buff *skb, int frametyp
}
return 0;
+
+out_clear:
+ x25_write_internal(sk, X25_CLEAR_REQUEST);
+ x25->state = X25_STATE_2;
+ x25_start_t23timer(sk);
+ return 0;
}
/*
--
1.7.1
On Mon, 2011-02-07 at 17:29 +1100, Andrew Hendry wrote:
> The issue is a bit more complex than Andy's patch, I think I have a full fix.
> Burning it in on test system now, if thats OK ill post patch in a few hours.
>
>
> On Mon, Feb 7, 2011 at 3:28 PM, David Miller <davem@davemloft.net> wrote:
> > From: Andrew Hendry <andrew.hendry@gmail.com>
> > Date: Tue, 1 Feb 2011 22:55:13 +1100
> >
> >> There are two callers, when I was crashing it I don't remember it
> >> using the backlog path.
> >> x25_process_rx_frame is called from both x25_backlog_rcv and also
> >> x25_receive_data (via x25_lapb_receive_frame)
> >>
> >> But reviewing that second path now it looks like it will also leak, -1
> >> would make it skip the kfree_skb there as well.
> >> So patch looks good to me, when I have some time I'll run it through
> >> the environment I had setup originally to confirm.
> >
> > Andrew, have you had a chance to do this yet?
> >
^ permalink raw reply related
* 6to4 NAT ?
From: Matthias Urlichs @ 2011-02-07 9:59 UTC (permalink / raw)
To: netdev
Hello,
The problem: I have a 10.*/8 ipv4 network which I want to reach via ipv6.
I.e., what I need is some sort of 6to4 NAT so that traffic from [whereever]
to e.g. fec0:dead:beef:1234::10.1.2.3 ends up as coming from e.g. 10.0.0.1
on the IPv4 side.
"Classic" NAT, in other words, except that (a) one side is on IPv6, and
(b) the destination's v4 address is the tail end of the v6 address.
Cisco boxes can apparently do that. I want my Linux box to do it too. :-P
Is there something like this already out there, or do I need to copy
the NAT kernel modules and start hacking?
(This is not a tunnel: I don't want the IPv6 packets to get encapsulated
in IPv4. That'd require all the systems on the 10.* net to have their own
local tunnel interface. I can't do that.)
--
-- Matthias Urlichs
^ permalink raw reply
* Re: [patch] IPVS: precedence bug in ip_vs_sync_switch_mode()
From: Hans Schillstrom @ 2011-02-07 9:34 UTC (permalink / raw)
To: Dan Carpenter
Cc: Wensong Zhang, Simon Horman, Julian Anastasov, hans.schillstrom,
Patrick McHardy, David S. Miller, netdev, lvs-devel,
netfilter-devel, kernel-janitors
>---- Original Message ----
>From: Dan Carpenter <error27@gmail.com>
>To: "Wensong Zhang" <wensong@linux-vs.org>
>Cc: "Simon Horman" <horms@verge.net.au>, "Julian Anastasov" <ja@ssi.bg>, hans.schillstrom@ericsson.com, "Patrick McHardy" <kaber@trash.net>, "David S. Miller" <davem@davemloft.net>, netdev@vger.kernel.org, lvs-devel@vger.kernel.org, netfilter-devel@vger.kernel.org, kernel-janitors@vger.kernel.org
>Sent: Mon, Feb 7, 2011, 9:39 AM
>Subject: [patch] IPVS: precedence bug in ip_vs_sync_switch_mode()
>
>'!' has higher precedence than '&'. IP_VS_STATE_MASTER is 0x1 so
>the original code is equivelent to if (!ipvs->sync_state) ...
>
Oops,
Thanks
Hans
>Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Hans Schillstrom <hans.schillstrom@ericsson.com>
>
>diff --git a/net/netfilter/ipvs/ip_vs_sync.c b/net/netfilter/ipvs/ip_vs_sync.c
>index 2a2a836..d1b7298 100644
>--- a/net/netfilter/ipvs/ip_vs_sync.c
>+++ b/net/netfilter/ipvs/ip_vs_sync.c
>@@ -392,7 +392,7 @@ void ip_vs_sync_switch_mode(struct net *net, int mode)
> {
> struct netns_ipvs *ipvs = net_ipvs(net);
>
>- if (!ipvs->sync_state & IP_VS_STATE_MASTER)
>+ if (!(ipvs->sync_state & IP_VS_STATE_MASTER))
> return;
> if (mode == ipvs->sysctl_sync_ver || !ipvs->sync_buff)
> return;
>--
^ permalink raw reply
* Re: x25: possible skb leak on bad facilities
From: John Hughes @ 2011-02-07 9:25 UTC (permalink / raw)
To: Andy Whitcroft
Cc: Andrew Hendry, David S. Miller, linux-x25, netdev, linux-kernel,
Tim Gardner
In-Reply-To: <20110131130826.GC16804@shadowen.org>
On 31/01/11 14:08, Andy Whitcroft wrote:
> Looking at the changes introduced in the commit below, we seem to
> introduce an skb leak when a packet with bad facilities are present:
>
> commit a6331d6f9a4298173b413cf99a40cc86a9d92c37
> Author: andrew hendry<andrew.hendry@gmail.com>
> Date: Wed Nov 3 12:54:53 2010 +0000
>
> memory corruption in X.25 facilities parsing
>
> If I am understanding things correctly then we trigger a -1 return to
> the main packet dispatch loop, this being non-zero implies that we have
> requeued the skb and it should not be freed. As it was not requeued,
> I believe the skb is no longer referenced and then is leaked.
>
> Perhaps someone better aquainted with this code could review my analysis
> in the patch leader below. If accurate I believe we need the patch below
> to resolve this. If it is not then I suspect a comment is required on
> the -1 return.
>
> Thoughts?
>
Sadly, after nearly 30 years (1982-2010) we've just closed our last X.25
line so I can no longer test this.
Sorry.
^ permalink raw reply
* [PATCH] IPVS: precedence bug in ip_vs_sync_switch_mode()
From: Simon Horman @ 2011-02-07 9:19 UTC (permalink / raw)
To: netdev, netfilter-devel, netfilter, lvs-devel
Cc: Julian Anastasov, Hans Schillstrom, Dan Carpenter,
Patrick McHardy, Simon Horman
In-Reply-To: <1297070381-24377-1-git-send-email-horms@verge.net.au>
From: Dan Carpenter <error27@gmail.com>
'!' has higher precedence than '&'. IP_VS_STATE_MASTER is 0x1 so
the original code is equivelent to if (!ipvs->sync_state) ...
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
net/netfilter/ipvs/ip_vs_sync.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_sync.c b/net/netfilter/ipvs/ip_vs_sync.c
index 2a2a836..d1b7298 100644
--- a/net/netfilter/ipvs/ip_vs_sync.c
+++ b/net/netfilter/ipvs/ip_vs_sync.c
@@ -392,7 +392,7 @@ void ip_vs_sync_switch_mode(struct net *net, int mode)
{
struct netns_ipvs *ipvs = net_ipvs(net);
- if (!ipvs->sync_state & IP_VS_STATE_MASTER)
+ if (!(ipvs->sync_state & IP_VS_STATE_MASTER))
return;
if (mode == ipvs->sysctl_sync_ver || !ipvs->sync_buff)
return;
--
1.7.2.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox