* [patch net-next v2 3/4] net: move vlan pop/push functions into common code
From: Jiri Pirko @ 2014-11-12 14:52 UTC (permalink / raw)
To: netdev
Cc: davem, jhs, pshelar, therbert, edumazet, willemb, dborkman, mst,
fw, Paul.Durrant, tgraf
In-Reply-To: <1415803950-9838-1-git-send-email-jiri@resnulli.us>
So it can be used from out of openvswitch code.
Did couple of cosmetic changes on the way, namely variable naming and
adding support for 8021AD proto.
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
v1->v2:
- adjusted to fix recent ovs changes
- included change to use make_writable suggested by Eric
include/linux/skbuff.h | 2 ++
net/core/skbuff.c | 78 +++++++++++++++++++++++++++++++++++++++++++++
net/openvswitch/actions.c | 81 +++++------------------------------------------
3 files changed, 88 insertions(+), 73 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index e045516..78c299f 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -2679,6 +2679,8 @@ unsigned int skb_gso_transport_seglen(const struct sk_buff *skb);
struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features);
struct sk_buff *skb_vlan_untag(struct sk_buff *skb);
int skb_ensure_writable(struct sk_buff *skb, int write_len);
+int skb_vlan_pop(struct sk_buff *skb);
+int skb_vlan_push(struct sk_buff *skb, __be16 vlan_proto, u16 vlan_tci);
struct skb_checksum_ops {
__wsum (*update)(const void *mem, int len, __wsum wsum);
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index d11bbe0..c7d3000 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -4163,6 +4163,84 @@ int skb_ensure_writable(struct sk_buff *skb, int write_len)
}
EXPORT_SYMBOL(skb_ensure_writable);
+/* remove VLAN header from packet and update csum accordingly. */
+static int __skb_vlan_pop(struct sk_buff *skb, u16 *vlan_tci)
+{
+ struct vlan_hdr *vhdr;
+ int err;
+
+ err = skb_ensure_writable(skb, VLAN_ETH_HLEN);
+ if (unlikely(err))
+ return err;
+
+ skb_postpull_rcsum(skb, skb->data + (2 * ETH_ALEN), VLAN_HLEN);
+
+ vhdr = (struct vlan_hdr *)(skb->data + ETH_HLEN);
+ *vlan_tci = ntohs(vhdr->h_vlan_TCI);
+
+ memmove(skb->data + VLAN_HLEN, skb->data, 2 * ETH_ALEN);
+ __skb_pull(skb, VLAN_HLEN);
+
+ vlan_set_encap_proto(skb, vhdr);
+ skb->mac_header += VLAN_HLEN;
+ if (skb_network_offset(skb) < ETH_HLEN)
+ skb_set_network_header(skb, ETH_HLEN);
+ skb_reset_mac_len(skb);
+
+ return 0;
+}
+
+int skb_vlan_pop(struct sk_buff *skb)
+{
+ u16 vlan_tci;
+ __be16 vlan_proto;
+ int err;
+
+ if (likely(vlan_tx_tag_present(skb))) {
+ skb->vlan_tci = 0;
+ } else {
+ if (unlikely((skb->protocol != htons(ETH_P_8021Q) &&
+ skb->protocol != htons(ETH_P_8021AD)) ||
+ skb->len < VLAN_ETH_HLEN))
+ return 0;
+
+ err = __skb_vlan_pop(skb, &vlan_tci);
+ if (err)
+ return err;
+ }
+ /* move next vlan tag to hw accel tag */
+ if (likely((skb->protocol != htons(ETH_P_8021Q) &&
+ skb->protocol != htons(ETH_P_8021AD)) ||
+ skb->len < VLAN_ETH_HLEN))
+ return 0;
+
+ vlan_proto = skb->protocol;
+ err = __skb_vlan_pop(skb, &vlan_tci);
+ if (unlikely(err))
+ return err;
+
+ __vlan_hwaccel_put_tag(skb, vlan_proto, vlan_tci);
+ return 0;
+}
+EXPORT_SYMBOL(skb_vlan_pop);
+
+int skb_vlan_push(struct sk_buff *skb, __be16 vlan_proto, u16 vlan_tci)
+{
+ if (vlan_tx_tag_present(skb)) {
+ /* push down current VLAN tag */
+ if (!__vlan_put_tag(skb, skb->vlan_proto,
+ vlan_tx_tag_get(skb)))
+ return -ENOMEM;
+
+ if (skb->ip_summed == CHECKSUM_COMPLETE)
+ skb->csum = csum_add(skb->csum, csum_partial(skb->data
+ + (2 * ETH_ALEN), VLAN_HLEN, 0));
+ }
+ __vlan_hwaccel_put_tag(skb, vlan_proto, vlan_tci);
+ return 0;
+}
+EXPORT_SYMBOL(skb_vlan_push);
+
/**
* alloc_skb_with_frags - allocate skb with page frags
*
diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
index 04c9680..e1a5182 100644
--- a/net/openvswitch/actions.c
+++ b/net/openvswitch/actions.c
@@ -206,91 +206,26 @@ static int set_mpls(struct sk_buff *skb, struct sw_flow_key *key,
return 0;
}
-/* remove VLAN header from packet and update csum accordingly. */
-static int __pop_vlan_tci(struct sk_buff *skb, __be16 *current_tci)
-{
- struct vlan_hdr *vhdr;
- int err;
-
- err = skb_ensure_writable(skb, VLAN_ETH_HLEN);
- if (unlikely(err))
- return err;
-
- skb_postpull_rcsum(skb, skb->data + (2 * ETH_ALEN), VLAN_HLEN);
-
- vhdr = (struct vlan_hdr *)(skb->data + ETH_HLEN);
- *current_tci = vhdr->h_vlan_TCI;
-
- memmove(skb->data + VLAN_HLEN, skb->data, 2 * ETH_ALEN);
- __skb_pull(skb, VLAN_HLEN);
-
- vlan_set_encap_proto(skb, vhdr);
- skb->mac_header += VLAN_HLEN;
-
- if (skb_network_offset(skb) < ETH_HLEN)
- skb_set_network_header(skb, ETH_HLEN);
-
- /* Update mac_len for subsequent MPLS actions */
- skb_reset_mac_len(skb);
- return 0;
-}
-
static int pop_vlan(struct sk_buff *skb, struct sw_flow_key *key)
{
- __be16 tci;
int err;
- if (likely(vlan_tx_tag_present(skb))) {
- skb->vlan_tci = 0;
- } else {
- if (unlikely(skb->protocol != htons(ETH_P_8021Q) ||
- skb->len < VLAN_ETH_HLEN))
- return 0;
-
- err = __pop_vlan_tci(skb, &tci);
- if (err)
- return err;
- }
- /* move next vlan tag to hw accel tag */
- if (likely(skb->protocol != htons(ETH_P_8021Q) ||
- skb->len < VLAN_ETH_HLEN)) {
+ err = skb_vlan_pop(skb);
+ if (vlan_tx_tag_present(skb))
+ invalidate_flow_key(key);
+ else
key->eth.tci = 0;
- return 0;
- }
-
- invalidate_flow_key(key);
- err = __pop_vlan_tci(skb, &tci);
- if (unlikely(err))
- return err;
-
- __vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), ntohs(tci));
- return 0;
+ return err;
}
static int push_vlan(struct sk_buff *skb, struct sw_flow_key *key,
const struct ovs_action_push_vlan *vlan)
{
- if (unlikely(vlan_tx_tag_present(skb))) {
- u16 current_tag;
-
- /* push down current VLAN tag */
- current_tag = vlan_tx_tag_get(skb);
-
- if (!__vlan_put_tag(skb, skb->vlan_proto, current_tag))
- return -ENOMEM;
- /* Update mac_len for subsequent MPLS actions */
- skb->mac_len += VLAN_HLEN;
-
- if (skb->ip_summed == CHECKSUM_COMPLETE)
- skb->csum = csum_add(skb->csum, csum_partial(skb->data
- + (2 * ETH_ALEN), VLAN_HLEN, 0));
-
+ if (vlan_tx_tag_present(skb))
invalidate_flow_key(key);
- } else {
+ else
key->eth.tci = vlan->vlan_tci;
- }
- __vlan_hwaccel_put_tag(skb, vlan->vlan_tpid, ntohs(vlan->vlan_tci) & ~VLAN_TAG_PRESENT);
- return 0;
+ return skb_vlan_push(skb, vlan->vlan_tpid, ntohs(vlan->vlan_tci) & ~VLAN_TAG_PRESENT);
}
static int set_eth_addr(struct sk_buff *skb, struct sw_flow_key *key,
--
1.9.3
^ permalink raw reply related
* [patch net-next v2 2/4] net: move make_writable helper into common code
From: Jiri Pirko @ 2014-11-12 14:52 UTC (permalink / raw)
To: netdev
Cc: davem, jhs, pshelar, therbert, edumazet, willemb, dborkman, mst,
fw, Paul.Durrant, tgraf
In-Reply-To: <1415803950-9838-1-git-send-email-jiri@resnulli.us>
note that skb_make_writable already exists in net/netfilter/core.c
but does something slightly different.
Suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
include/linux/skbuff.h | 1 +
net/core/skbuff.c | 12 ++++++++++++
net/openvswitch/actions.c | 39 ++++++++++++++-------------------------
3 files changed, 27 insertions(+), 25 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 73c370e..e045516 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -2678,6 +2678,7 @@ void skb_scrub_packet(struct sk_buff *skb, bool xnet);
unsigned int skb_gso_transport_seglen(const struct sk_buff *skb);
struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features);
struct sk_buff *skb_vlan_untag(struct sk_buff *skb);
+int skb_ensure_writable(struct sk_buff *skb, int write_len);
struct skb_checksum_ops {
__wsum (*update)(const void *mem, int len, __wsum wsum);
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 7001896..d11bbe0 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -4151,6 +4151,18 @@ err_free:
}
EXPORT_SYMBOL(skb_vlan_untag);
+int skb_ensure_writable(struct sk_buff *skb, int write_len)
+{
+ if (!pskb_may_pull(skb, write_len))
+ return -ENOMEM;
+
+ if (!skb_cloned(skb) || skb_clone_writable(skb, write_len))
+ return 0;
+
+ return pskb_expand_head(skb, 0, 0, GFP_ATOMIC);
+}
+EXPORT_SYMBOL(skb_ensure_writable);
+
/**
* alloc_skb_with_frags - allocate skb with page frags
*
diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
index 749a301..04c9680 100644
--- a/net/openvswitch/actions.c
+++ b/net/openvswitch/actions.c
@@ -119,17 +119,6 @@ static bool is_flow_key_valid(const struct sw_flow_key *key)
return !!key->eth.type;
}
-static int make_writable(struct sk_buff *skb, int write_len)
-{
- if (!pskb_may_pull(skb, write_len))
- return -ENOMEM;
-
- if (!skb_cloned(skb) || skb_clone_writable(skb, write_len))
- return 0;
-
- return pskb_expand_head(skb, 0, 0, GFP_ATOMIC);
-}
-
static int push_mpls(struct sk_buff *skb, struct sw_flow_key *key,
const struct ovs_action_push_mpls *mpls)
{
@@ -171,7 +160,7 @@ static int pop_mpls(struct sk_buff *skb, struct sw_flow_key *key,
struct ethhdr *hdr;
int err;
- err = make_writable(skb, skb->mac_len + MPLS_HLEN);
+ err = skb_ensure_writable(skb, skb->mac_len + MPLS_HLEN);
if (unlikely(err))
return err;
@@ -201,7 +190,7 @@ static int set_mpls(struct sk_buff *skb, struct sw_flow_key *key,
__be32 *stack;
int err;
- err = make_writable(skb, skb->mac_len + MPLS_HLEN);
+ err = skb_ensure_writable(skb, skb->mac_len + MPLS_HLEN);
if (unlikely(err))
return err;
@@ -223,7 +212,7 @@ static int __pop_vlan_tci(struct sk_buff *skb, __be16 *current_tci)
struct vlan_hdr *vhdr;
int err;
- err = make_writable(skb, VLAN_ETH_HLEN);
+ err = skb_ensure_writable(skb, VLAN_ETH_HLEN);
if (unlikely(err))
return err;
@@ -308,7 +297,7 @@ static int set_eth_addr(struct sk_buff *skb, struct sw_flow_key *key,
const struct ovs_key_ethernet *eth_key)
{
int err;
- err = make_writable(skb, ETH_HLEN);
+ err = skb_ensure_writable(skb, ETH_HLEN);
if (unlikely(err))
return err;
@@ -410,8 +399,8 @@ static int set_ipv4(struct sk_buff *skb, struct sw_flow_key *key,
struct iphdr *nh;
int err;
- err = make_writable(skb, skb_network_offset(skb) +
- sizeof(struct iphdr));
+ err = skb_ensure_writable(skb, skb_network_offset(skb) +
+ sizeof(struct iphdr));
if (unlikely(err))
return err;
@@ -448,8 +437,8 @@ static int set_ipv6(struct sk_buff *skb, struct sw_flow_key *key,
__be32 *saddr;
__be32 *daddr;
- err = make_writable(skb, skb_network_offset(skb) +
- sizeof(struct ipv6hdr));
+ err = skb_ensure_writable(skb, skb_network_offset(skb) +
+ sizeof(struct ipv6hdr));
if (unlikely(err))
return err;
@@ -491,7 +480,7 @@ static int set_ipv6(struct sk_buff *skb, struct sw_flow_key *key,
return 0;
}
-/* Must follow make_writable() since that can move the skb data. */
+/* Must follow skb_ensure_writable() since that can move the skb data. */
static void set_tp_port(struct sk_buff *skb, __be16 *port,
__be16 new_port, __sum16 *check)
{
@@ -521,8 +510,8 @@ static int set_udp(struct sk_buff *skb, struct sw_flow_key *key,
struct udphdr *uh;
int err;
- err = make_writable(skb, skb_transport_offset(skb) +
- sizeof(struct udphdr));
+ err = skb_ensure_writable(skb, skb_transport_offset(skb) +
+ sizeof(struct udphdr));
if (unlikely(err))
return err;
@@ -546,8 +535,8 @@ static int set_tcp(struct sk_buff *skb, struct sw_flow_key *key,
struct tcphdr *th;
int err;
- err = make_writable(skb, skb_transport_offset(skb) +
- sizeof(struct tcphdr));
+ err = skb_ensure_writable(skb, skb_transport_offset(skb) +
+ sizeof(struct tcphdr));
if (unlikely(err))
return err;
@@ -572,7 +561,7 @@ static int set_sctp(struct sk_buff *skb, struct sw_flow_key *key,
int err;
unsigned int sctphoff = skb_transport_offset(skb);
- err = make_writable(skb, sctphoff + sizeof(struct sctphdr));
+ err = skb_ensure_writable(skb, sctphoff + sizeof(struct sctphdr));
if (unlikely(err))
return err;
--
1.9.3
^ permalink raw reply related
* [patch net-next v2 1/4] openvswitch: actions: use skb_postpull_rcsum when possible
From: Jiri Pirko @ 2014-11-12 14:52 UTC (permalink / raw)
To: netdev
Cc: davem, jhs, pshelar, therbert, edumazet, willemb, dborkman, mst,
fw, Paul.Durrant, tgraf
Replace duplicated code by calling skb_postpull_rcsum
Suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
net/openvswitch/actions.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
index 394efa6..749a301 100644
--- a/net/openvswitch/actions.c
+++ b/net/openvswitch/actions.c
@@ -175,10 +175,7 @@ static int pop_mpls(struct sk_buff *skb, struct sw_flow_key *key,
if (unlikely(err))
return err;
- if (skb->ip_summed == CHECKSUM_COMPLETE)
- skb->csum = csum_sub(skb->csum,
- csum_partial(skb_mpls_header(skb),
- MPLS_HLEN, 0));
+ skb_postpull_rcsum(skb, skb_mpls_header(skb), MPLS_HLEN);
memmove(skb_mac_header(skb) + MPLS_HLEN, skb_mac_header(skb),
skb->mac_len);
@@ -230,9 +227,7 @@ static int __pop_vlan_tci(struct sk_buff *skb, __be16 *current_tci)
if (unlikely(err))
return err;
- if (skb->ip_summed == CHECKSUM_COMPLETE)
- skb->csum = csum_sub(skb->csum, csum_partial(skb->data
- + (2 * ETH_ALEN), VLAN_HLEN, 0));
+ skb_postpull_rcsum(skb, skb->data + (2 * ETH_ALEN), VLAN_HLEN);
vhdr = (struct vlan_hdr *)(skb->data + ETH_HLEN);
*current_tci = vhdr->h_vlan_TCI;
--
1.9.3
^ permalink raw reply related
* Re: [PATCH v2] VNIC: Adding support for Cavium ThunderX network controller
From: Andrey Panin @ 2014-11-12 14:52 UTC (permalink / raw)
To: Robert Richter
Cc: Robert Richter, netdev, linux-kernel, Stephen Hemminger,
Stefan Assmann, Sunil Goutham, David S. Miller, linux-arm-kernel
In-Reply-To: <1415596445-10061-1-git-send-email-rric@kernel.org>
On 313, 11 09, 2014 at 09:14:05PM -0800, Robert Richter wrote:
I apologize for possibly repeated mail, my mailsystem was misconfigured :(
Some comments from quick look are below.
> +static int nic_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
> +{
> + struct device *dev = &pdev->dev;
> + struct net_device *netdev;
> + struct nicpf *nic;
> + int err;
> +
> + netdev = alloc_etherdev(sizeof(struct nicpf));
> + if (!netdev)
> + return -ENOMEM;
> +
> + pci_set_drvdata(pdev, netdev);
> +
> + SET_NETDEV_DEV(netdev, &pdev->dev);
> +
> + nic = netdev_priv(netdev);
> + nic->netdev = netdev;
> + nic->pdev = pdev;
> +
> + err = pci_enable_device(pdev);
> + if (err) {
> + dev_err(dev, "Failed to enable PCI device\n");
> + goto exit;
Looks like you leaked netdev here.
> + }
> +
> + err = pci_request_regions(pdev, DRV_NAME);
> + if (err) {
> + dev_err(dev, "PCI request regions failed 0x%x\n", err);
> + goto err_disable_device;
> + }
> +
> + err = pci_set_dma_mask(pdev, DMA_BIT_MASK(48));
> + if (err) {
> + dev_err(dev, "Unable to get usable DMA configuration\n");
> + goto err_release_regions;
> + }
> +
> + err = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(48));
> + if (err) {
> + dev_err(dev, "unable to get 48-bit DMA for consistent allocations\n");
> + goto err_release_regions;
> + }
> +
> + /* MAP PF's configuration registers */
> + nic->reg_base = (uint64_t)pci_ioremap_bar(pdev, PCI_CFG_REG_BAR_NUM);
> + if (!nic->reg_base) {
> + dev_err(dev, "Cannot map config register space, aborting\n");
> + err = -ENOMEM;
> + goto err_release_regions;
> + }
> + nic->node = NIC_NODE_ID(pci_resource_start(pdev, PCI_CFG_REG_BAR_NUM));
> +
> + /* By default set NIC in TNS bypass mode */
> + nic->flags &= ~NIC_TNS_ENABLED;
> + nic_set_lmac_vf_mapping(nic);
> +
> + /* Initialize hardware */
> + nic_init_hw(nic);
> +
> + /* Set RSS TBL size for each VF */
> + nic->rss_ind_tbl_size = max((NIC_RSSI_COUNT / nic->num_vf_en),
> + NIC_MAX_RSS_IDR_TBL_SIZE);
> + nic->rss_ind_tbl_size = rounddown_pow_of_two(nic->rss_ind_tbl_size);
> +
> + /* Register interrupts */
> + if (nic_register_interrupts(nic))
> + goto err_unmap_resources;
> +
> + /* Configure SRIOV */
> + if (!nic_sriov_init(pdev, nic))
> + goto err_unmap_resources;
> +
> + goto exit;
Why not simply return 0; ?
> +
> +err_unmap_resources:
> + if (nic->reg_base)
This check looks unnecessary.
> + iounmap((void *)nic->reg_base);
> +err_release_regions:
> + pci_release_regions(pdev);
> +err_disable_device:
> + pci_disable_device(pdev);
> +exit:
> + return err;
> +}
> +static int bgx_register_interrupts(struct bgx *bgx, uint8_t lmac)
> +{
> + int irq, ret = 0;
> +
> + /* Register only link interrupts now */
> + irq = SPUX_INT + (lmac * BGX_LMAC_VEC_OFFSET);
> + sprintf(bgx->irq_name[irq], "LMAC%d", lmac);
> + ret = request_irq(bgx->msix_entries[irq].vector,
> + bgx_lmac_intr_handler, 0, bgx->irq_name[irq], bgx);
> + if (ret)
> + goto fail;
> + else
This else just hurts readability.
> + bgx->irq_allocated[irq] = 1;
> +
> + /* Enable link interrupt */
> + bgx_enable_link_intr(bgx, lmac);
> + return 0;
> +
> +fail:
The code below copypasted from bgx_unregister_interrupts()
Looks like good candidate for helper function.
> + dev_err(&bgx->pdev->dev, "Request irq failed\n");
> + for (irq = 0; irq < bgx->num_vec; irq++) {
> + if (bgx->irq_allocated[irq])
> + free_irq(bgx->msix_entries[irq].vector, bgx);
> + bgx->irq_allocated[irq] = 0;
> + }
> + return 1;
> +}
> +
> +static void bgx_unregister_interrupts(struct bgx *bgx)
> +{
> + int irq;
> + /* Free registered interrupts */
> + for (irq = 0; irq < bgx->num_vec; irq++) {
> + if (bgx->irq_allocated[irq])
> + free_irq(bgx->msix_entries[irq].vector, bgx);
> + bgx->irq_allocated[irq] = 0;
> + }
> + /* Disable MSI-X */
> + bgx_disable_msix(bgx);
> +}
> +
> +void bgx_lmac_enable(struct bgx *bgx, int8_t lmac)
> +{
> + uint64_t dmac_bcast = (1ULL << 48) - 1;
> +
> + bgx_reg_write(bgx, lmac, BGX_CMRX_CFG,
> + (1 << 15) | (1 << 14) | (1 << 13));
> +
> + /* Register interrupts */
> + bgx_register_interrupts(bgx, lmac);
bgx_register_interrupts() can fail (due to request_irq), but it's return
value is not checked.
> +
> + /* Add broadcast MAC into all LMAC's DMAC filters */
> + for (lmac = 0; lmac < bgx->lmac_count; lmac++)
> + bgx_add_dmac_addr(dmac_bcast, 0, bgx->bgx_id, lmac);
> +}
> +static int bgx_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
> +{
> + struct device *dev = &pdev->dev;
> + struct bgx *bgx;
> + int err;
> + uint8_t lmac = 0;
> +
> + bgx = kzalloc(sizeof(*bgx), GFP_KERNEL);
kzalloc() return value not checked
> + bgx->pdev = pdev;
> +
> + pci_set_drvdata(pdev, bgx);
> +
> + err = pci_enable_device(pdev);
> + if (err) {
> + dev_err(dev, "Failed to enable PCI device\n");
> + goto exit;
bgx is leaked here.
> + }
> +
> + err = pci_request_regions(pdev, DRV_NAME);
> + if (err) {
> + dev_err(dev, "PCI request regions failed 0x%x\n", err);
> + goto err_disable_device;
> + }
> +
> + /* MAP configuration registers */
> + bgx->reg_base = (uint64_t)pci_ioremap_bar(pdev, PCI_CFG_REG_BAR_NUM);
> + if (!bgx->reg_base) {
> + dev_err(dev, "BGX: Cannot map CSR memory space, aborting\n");
> + err = -ENOMEM;
> + goto err_release_regions;
> + }
> + bgx->bgx_id = (pci_resource_start(pdev, PCI_CFG_REG_BAR_NUM) >> 24) & 1;
> + bgx->bgx_id += NODE_ID(pci_resource_start(pdev, PCI_CFG_REG_BAR_NUM))
> + * MAX_BGX_PER_CN88XX;
> + bgx_vnic[bgx->bgx_id] = bgx;
> +
> + /* Initialize BGX hardware */
> + bgx_init_hw(bgx);
> + /* Enable MSI-X */
> + if (!bgx_enable_msix(bgx))
> + return 1;
Massive resource leak here.
> + /* Enable all LMACs */
> + for (lmac = 0; lmac < bgx->lmac_count; lmac++)
> + bgx_lmac_enable(bgx, lmac);
See comment about bgx_lmac_enable() above.
> + goto exit;
> +
Lines below are unreachable.
> + if (bgx->reg_base)
> + iounmap((void *)bgx->reg_base);
> +err_release_regions:
> + pci_release_regions(pdev);
> +err_disable_device:
> + pci_disable_device(pdev);
> +exit:
> + return err;
> +}
^ permalink raw reply
* [PATCH v5 6/8] net: can: c_can: Disable pins when CAN interface is down
From: Roger Quadros @ 2014-11-12 14:16 UTC (permalink / raw)
To: wg, mkl
Cc: wsa, tony, tglx, mugunthanvnm, george.cherian, balbi, nsekhar, nm,
sergei.shtylyov, linux-omap, linux-can, netdev, Roger Quadros
In-Reply-To: <1415371762-29885-7-git-send-email-rogerq@ti.com>
DRA7 CAN IP suffers from a problem which causes it to be prevented
from fully turning OFF (i.e. stuck in transition) if the module was
disabled while there was traffic on the CAN_RX line.
To work around this issue we select the SLEEP pin state by default
on probe and use the DEFAULT pin state on CAN up and back to the
SLEEP pin state on CAN down.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
drivers/net/can/c_can/c_can.c | 21 +++++++++++++++++++++
drivers/net/can/c_can/c_can.h | 1 +
drivers/net/can/c_can/c_can_platform.c | 20 ++++++++++++++++++++
3 files changed, 42 insertions(+)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index 8e78bb4..a950eea 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -35,6 +35,7 @@
#include <linux/list.h>
#include <linux/io.h>
#include <linux/pm_runtime.h>
+#include <linux/pinctrl/consumer.h>
#include <linux/can.h>
#include <linux/can/dev.h>
@@ -587,6 +588,21 @@ static int c_can_chip_config(struct net_device *dev)
return c_can_set_bittiming(dev);
}
+/*
+ * Selects the pinctrl state specified in the name.
+ */
+static void c_can_pinctrl_select_state(struct c_can_priv *priv,
+ const char *name)
+{
+ if (!IS_ERR(priv->pinctrl)) {
+ struct pinctrl_state *s;
+
+ s = pinctrl_lookup_state(priv->pinctrl, name);
+ if (!IS_ERR(s))
+ pinctrl_select_state(priv->pinctrl, s);
+ }
+}
+
static int c_can_start(struct net_device *dev)
{
struct c_can_priv *priv = netdev_priv(dev);
@@ -603,6 +619,8 @@ static int c_can_start(struct net_device *dev)
priv->can.state = CAN_STATE_ERROR_ACTIVE;
+ /* activate pins */
+ c_can_pinctrl_select_state(priv, PINCTRL_STATE_DEFAULT);
return 0;
}
@@ -611,6 +629,9 @@ static void c_can_stop(struct net_device *dev)
struct c_can_priv *priv = netdev_priv(dev);
c_can_irq_control(priv, false);
+
+ /* deactivate pins */
+ c_can_pinctrl_select_state(priv, PINCTRL_STATE_SLEEP);
priv->can.state = CAN_STATE_STOPPED;
}
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index c6715ca..3cedf48 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -210,6 +210,7 @@ struct c_can_priv {
u32 comm_rcv_high;
u32 rxmasked;
u32 dlc[C_CAN_MSG_OBJ_TX_NUM];
+ struct pinctrl *pinctrl;
};
struct net_device *alloc_c_can_dev(void);
diff --git a/drivers/net/can/c_can/c_can_platform.c b/drivers/net/can/c_can/c_can_platform.c
index b838c6b..71b9063 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -34,6 +34,7 @@
#include <linux/of_device.h>
#include <linux/mfd/syscon.h>
#include <linux/regmap.h>
+#include <linux/pinctrl/consumer.h>
#include <linux/can/dev.h>
@@ -230,6 +231,7 @@ static int c_can_plat_probe(struct platform_device *pdev)
struct clk *clk;
const struct c_can_driver_data *drvdata;
struct device_node *np = pdev->dev.of_node;
+ struct pinctrl *pinctrl;
match = of_match_device(c_can_of_table, &pdev->dev);
if (match) {
@@ -241,6 +243,23 @@ static int c_can_plat_probe(struct platform_device *pdev)
return -ENODEV;
}
+ pinctrl = devm_pinctrl_get(&pdev->dev);
+ if (!IS_ERR(pinctrl)) {
+ struct pinctrl_state *s;
+
+ /* Deactivate pins to prevent DRA7 DCAN IP from being
+ * stuck in transition when module is disabled.
+ * Pins are activated in c_can_start() and deactivated
+ * in c_can_stop()
+ */
+ s = pinctrl_lookup_state(pinctrl, PINCTRL_STATE_SLEEP);
+ if (!IS_ERR(s))
+ pinctrl_select_state(pinctrl, s);
+ } else {
+ dev_warn(&pdev->dev,
+ "failed to get pinctrl\n");
+ }
+
/* get the appropriate clk */
clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(clk)) {
@@ -270,6 +289,7 @@ static int c_can_plat_probe(struct platform_device *pdev)
}
priv = netdev_priv(dev);
+ priv->pinctrl = pinctrl;
switch (drvdata->id) {
case BOSCH_C_CAN:
--
1.8.3.2
^ permalink raw reply related
* Re: Understanding what's going on when using a Huawei E173 USB 3G web-stick (UMTS/HSPA)
From: Sedat Dilek @ 2014-11-12 13:49 UTC (permalink / raw)
To: Aleksander Morgado
Cc: Dan Williams, Greg KH, David S. Miller, netdev@vger.kernel.org,
linux-usb
In-Reply-To: <CAAP7ucKO2D8B1gG943aNcqWuLm2UWt3AsfZAh5bzeaA1gzSaHQ@mail.gmail.com>
On Wed, Nov 12, 2014 at 12:51 PM, Aleksander Morgado
<aleksander@aleksander.es> wrote:
>
[...}
> I saw the reporter talk about Ubuntu Precise (12.04) and Trusty (14.04), so
> only in the latter mmcli will be available (if I'm not mistaken). For
> Precise, this Ubuntu page shows how to enable debug logs:
> https://wiki.ubuntu.com/DebuggingModemmanager
>
That wiki needs to be pimped-up (-> clarify on testing tools aka
outdated "mm-test.py", -> Ubuntu releases w/ and w/o upstart, etc.).
- Sedat -
"test: remove testers of the old interface"
[1] http://cgit.freedesktop.org/ModemManager/ModemManager/commit/?id=f3f499fcec13e6ffa9a428972c1108e7c23065d2
^ permalink raw reply
* Re: [patch net-next v2 00/10] introduce rocker switch driver with hardware accelerated datapath api - phase 1: bridge fdb offload
From: Jiri Pirko @ 2014-11-12 13:44 UTC (permalink / raw)
To: netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl
In-Reply-To: <1415530280-9190-1-git-send-email-jiri@resnulli.us>
Going to post v3 with the suggested changes included next Tue/Wed.
Thank you all for review!
Sun, Nov 09, 2014 at 11:51:10AM CET, jiri@resnulli.us wrote:
>Hi all.
>
>This patchset is just the first phase of switch and switch-ish device
>support api in kernel. Note that the api will extend (our complete work
>can be pulled from https://github.com/jpirko/net-next-rocker).
>
>So what this patchset includes:
>- introduce switchdev api for implementing switch drivers (so far
> only linux bridge fdb offload is covered)
>- introduce rocker switch driver which implements switchdev api
>
>As to the discussion if there is need to have specific class of device
>representing the switch itself, so far we found no need to introduce that.
>But we are generally ok with the idea and when the time comes and it will
>be needed, it can be easily introduced without any disturbance.
>
>This patchset introduces switch id export through rtnetlink and sysfs,
>which is similar to what we have for port id in SR-IOV. I will send iproute2
>patchset for showing the switch id for port netdevs once this is applied.
>
>For detailed description, please see individual patches.
>
>v1->v2:
>- addressed all DaveM's comments
>
>Jiri Pirko (5):
> net: rename netdev_phys_port_id to more generic name
> net: introduce generic switch devices support
> rtnl: expose physical switch id for particular device
> net-sysfs: expose physical switch id for particular device
> rocker: introduce rocker switch driver
>
>Scott Feldman (5):
> bridge: introduce fdb offloading via switchdev
> bridge: call netdev_sw_port_stp_update when bridge port STP status
> changes
> bridge: add API to notify bridge driver of learned FBD on offloaded
> device
> rocker: implement rocker ofdpa flow table manipulation
> rocker: implement L2 bridge offloading
>
> Documentation/networking/switchdev.txt | 59 +
> MAINTAINERS | 14 +
> drivers/net/ethernet/Kconfig | 1 +
> drivers/net/ethernet/Makefile | 1 +
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 2 +-
> drivers/net/ethernet/intel/i40e/i40e_main.c | 2 +-
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2 +-
> drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 2 +-
> drivers/net/ethernet/rocker/Kconfig | 27 +
> drivers/net/ethernet/rocker/Makefile | 5 +
> drivers/net/ethernet/rocker/rocker.c | 4182 ++++++++++++++++++++++
> drivers/net/ethernet/rocker/rocker.h | 427 +++
> include/linux/if_bridge.h | 18 +
> include/linux/netdevice.h | 48 +-
> include/net/switchdev.h | 53 +
> include/uapi/linux/if_link.h | 1 +
> net/Kconfig | 1 +
> net/Makefile | 3 +
> net/bridge/br_fdb.c | 94 +-
> net/bridge/br_netlink.c | 2 +
> net/bridge/br_stp.c | 4 +
> net/bridge/br_stp_if.c | 3 +
> net/bridge/br_stp_timer.c | 2 +
> net/core/dev.c | 2 +-
> net/core/net-sysfs.c | 26 +-
> net/core/rtnetlink.c | 30 +-
> net/switchdev/Kconfig | 13 +
> net/switchdev/Makefile | 5 +
> net/switchdev/switchdev.c | 93 +
> 29 files changed, 5104 insertions(+), 18 deletions(-)
> create mode 100644 Documentation/networking/switchdev.txt
> create mode 100644 drivers/net/ethernet/rocker/Kconfig
> create mode 100644 drivers/net/ethernet/rocker/Makefile
> create mode 100644 drivers/net/ethernet/rocker/rocker.c
> create mode 100644 drivers/net/ethernet/rocker/rocker.h
> create mode 100644 include/net/switchdev.h
> create mode 100644 net/switchdev/Kconfig
> create mode 100644 net/switchdev/Makefile
> create mode 100644 net/switchdev/switchdev.c
>
>--
>1.9.3
>
^ permalink raw reply
* Re: [patch net-next v2 06/10] bridge: introduce fdb offloading via switchdev
From: Jiri Pirko @ 2014-11-12 13:43 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Andy Gospodarek, Thomas Graf, Jamal Hadi Salim, netdev, davem,
nhorman, andy, dborkman, ogerlitz, jesse, pshelar, azhou, ben,
stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, sfeldma, f.fainelli, linville,
jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh,
aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrij
In-Reply-To: <54610C0D.1050500@cumulusnetworks.com>
Mon, Nov 10, 2014 at 08:03:41PM CET, roopa@cumulusnetworks.com wrote:
>On 11/10/14, 9:30 AM, Andy Gospodarek wrote:
>>On Mon, Nov 10, 2014 at 01:51:00PM +0000, Thomas Graf wrote:
>>>On 11/10/14 at 09:15am, Jiri Pirko wrote:
>>>>There are few problems in re-using this. It is netlink based so for calling
>>>>it from bridge code, we would have to construct netlink message. But
>>>>that could be probably changed.
>>>>As you can see from the list of parameters, this is no longer about fdb (addr,
>>>>vlanid) but this has been extended to something else. See vxlan code for
>>>>what this is used for. I believe that fdb_add/del should be renamed to
>>>>something else, perhaps l2neigh_add/del or something like that.
>>>>The other problem is that fdb_add/del is currently used by various
>>>>drivers for different purpose (adding macs to unicast list).
>>>Can you elaborate a bit on the intended semantic differences between
>>>the existing ndo_fdb_add() and ndo_sw_port_fdb_add()? I'm not sure we
>>>need the sw_ prefix for this specific ndo.
>>>
>>>I completely agree that relying on Netlink is wrong because we'll have
>>>in-kernel users of the API but I believe that existing ndo_fdb_add()
>>>implementations in i40e, ixgbe, qlcnic and macvlan could use the new
>>>API you propose.
>>I also think the same API could be used quite easily on the current
>>drivers that use it.
>>
>>I was looking at this earlier today and there are only 5 drivers
>>(outside the bridge code) that support ndo_fdb_add. The 3 hardware
>>drivers and vxlan driver seem like they could use this new API. The
>>macvlan code appears to simply set the uc and mc lists, which seems like
>>it could be done other ways -- confirmation from John Fastabend, Roopa,
>>and mst would be good.
>yes, that is correct. The macvlan code, when not set for passthru mode, seems
>to just program the uc-mc lists,
If you look at how drivers implement this, they also only add addr into
uc/mc list. And if the ndo fdb add is not implemented by the driver, core
does it for you - see ndo_dflt_fdb_add.
> which again get synched to the lowerdev (and possibly from lowerdev to hw in
>some cases).
>
>I agree that it would be really nice if the existing api's can be made to
>work.
>>>How about we rename the existing ndo_fdb_add() to ndo_neigh_add() as
>>>you propose and convert vxlan over to it and have all others which don't
>>>even depend on the Netlink attributes being passed in (i40e, ixgbe,
>>>qlcnic, macvlan) use ndo_fdb_add() which would have the behaviour of your
>>>proposed ndo_sw_port_fdb_add()?
>>I would much rather see something like Thomas proposes here. I know you
>>would like to see these patches get included (I'm anxious to see better
>>in-kernel offload support too!), but separate, possibly unnecessary
>>APIs like this can get painful for driver maintainers (upstream and
>>distro maintainers).
>>
>Ack!.
I will think about this more and prepare something like Thomas proposes.
Stay tuned, I will be out undil Monday so I will post v3 Tue/Wed next
week.
In the meantime, feel free to study the fdb_add code and feel free to
give me some more thoughts/patches about this. 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
* Re: [PATCH] net: pxa168_eth: move SET_NETDEV_DEV a bit earlier
From: Antoine Tenart @ 2014-11-12 13:34 UTC (permalink / raw)
To: Jisheng Zhang
Cc: davem, antoine.tenart, arnd, sebastian.hesselbarth, netdev,
linux-kernel, linux-arm-kernel
In-Reply-To: <1415790527-6494-1-git-send-email-jszhang@marvell.com>
Hi Jisheng,
On Wed, Nov 12, 2014 at 07:08:47PM +0800, Jisheng Zhang wrote:
> This is to ensure the net_device's dev.parent is set before we used it
> in dma_zalloc_coherent() from init_hash_table().
Applies on top of net-next.
>
> Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
FWIW,
Acked-by: Antoine Tenart <antoine.tenart@free-electrons.com>
> ---
> drivers/net/ethernet/marvell/pxa168_eth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/marvell/pxa168_eth.c b/drivers/net/ethernet/marvell/pxa168_eth.c
> index 21ddece..38f7cee 100644
> --- a/drivers/net/ethernet/marvell/pxa168_eth.c
> +++ b/drivers/net/ethernet/marvell/pxa168_eth.c
> @@ -1540,8 +1540,8 @@ static int pxa168_eth_probe(struct platform_device *pdev)
> if (err)
> goto err_free_mdio;
>
> - pxa168_init_hw(pep);
> SET_NETDEV_DEV(dev, &pdev->dev);
> + pxa168_init_hw(pep);
> err = register_netdev(dev);
> if (err)
> goto err_mdiobus;
> --
> 2.1.3
>
--
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* Re: Understanding what's going on when using a Huawei E173 USB 3G web-stick (UMTS/HSPA)
From: Sedat Dilek @ 2014-11-12 13:34 UTC (permalink / raw)
To: Aleksander Morgado
Cc: Dan Williams, Greg KH, David S. Miller, netdev@vger.kernel.org,
linux-usb
In-Reply-To: <CAAP7ucKO2D8B1gG943aNcqWuLm2UWt3AsfZAh5bzeaA1gzSaHQ@mail.gmail.com>
On Wed, Nov 12, 2014 at 12:51 PM, Aleksander Morgado
<aleksander@aleksander.es> wrote:
>
> On Tue, Nov 4, 2014 at 5:55 PM, Dan Williams <dcbw@redhat.com> wrote:
>>
>> > The next mystery is what is network-manager doing in the background?
>> > I have seen that modem-manager is invoked, but as said I would like to
>> > understand the "internas" (means check the logs, turn on some
>> > debugging kernel-space/user-space, etc.).
>>
>> NetworkManager uses ModemManager for all WWAN control, NM only handles
>> the configuration storage and IP addressing parts of the setup.
>> ModemManager handles modem hardware detection, capability detection,
>> WWAN registration and setup, signal strength reporting, network
>> connection initiation, and bearer IP addressing method determination.
>>
>> If you want more information from ModemManager, you can run "mmcli
>> --help" or "mmcli --set-logging=debug".
>
>
> That (mmcli) will only be available in ModemManager >= 1.x, BTW. And beware
> of --set-logging=debug, as syslog may limit those if MM sends too many too
> fast. In general I usually prefer to ask for --debug output just in case:
> http://www.freedesktop.org/wiki/Software/ModemManager/Debugging/
>
> I saw the reporter talk about Ubuntu Precise (12.04) and Trusty (14.04), so
> only in the latter mmcli will be available (if I'm not mistaken). For
> Precise, this Ubuntu page shows how to enable debug logs:
> https://wiki.ubuntu.com/DebuggingModemmanager
>
Hi Aleksander,
thanks for the web-links.
IMHO both can be placed in the "usb-wwan-networking" documentation I
have in mind.
The fdo-weblink is distro-independant.
Regards,
- Sedat -
^ permalink raw reply
* Re: Understanding what's going on when using a Huawei E173 USB 3G web-stick (UMTS/HSPA)
From: Sedat Dilek @ 2014-11-12 13:21 UTC (permalink / raw)
To: Dan Williams
Cc: Greg KH, David S. Miller,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Aleksander Morgado
In-Reply-To: <1415120132.31049.11.camel-ZWpNTBV2bRGs1BDpvl8NfQ@public.gmane.org>
On Tue, Nov 4, 2014 at 5:55 PM, Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Tue, 2014-11-04 at 16:11 +0100, Sedat Dilek wrote:
>> Hi,
>>
>> I wanted to understand what is going on the kernel-side when
>> connecting to the Internet via a Huawei E173 USB web-stick (3rd
>> Generation: UMTS / HSPA).
>>
>> Especially the correlation between the diverse USB/NET kernel-drivers
>> and how the networking is setup.
>
[ Sitting in front of a foreign Windows machine ]
[ CC Aleksander ]
Hi Dan,
sorry for the late (and short) response.
AFAICS you have given a "skeleton" for a "usb-wwan-networking"
documentation :-).
Personally, I would like to take into account some kernel-config
options and some more things.
> General overview: there are many different types of WWAN devices and
> they fall into a couple groups:
>
> 1) PPP-only via serial ports; IP packets are transmitted via a PPP
> interface (eg, ppp0) created after sending some AT commands to the modem
> over that serial port. IP addressing happens via PPP's IPCP/IPV6CP
> protocols.
>
> 2) Net interface with AT commands over serial ports: the modem provides
> a 'net' interface that is activated with proprietary AT commands over a
> serial port. IP addressing happens via either DHCP on that net interface
> after the AT setup, or the IP/DNS details are queried via proprietary AT
> commands.
>
> 3) Net interface with proprietary protocols: the modem provides a 'net'
> interface that is activated via proprietary protocols (QMI, MBIM, CnS,
> etc). IP addressing happens either via DHCP on the net interface after
> proprietary protocol setup, or the IP/DNS details are queried via
> proprietary protocol commands.
>
> It's often possible to know what category a device fits into, but even
> devices from the same manufacturer with *the same model number* can fall
> into different categories, because the firmware is different, or because
> the firmware can switch between these categories using special commands.
>
As I have a ppp0 network-interface setup, I guess I have the example #1 here.
What about putting these examples into a section "General Overview:
WWAN devices".
>> I have tested a Ubuntu trusty kernel on my Ubuntu/precise system and
>> compared the configs to get the stuff run on 3.18-rc2+.
>> Beyond the "option" driver, I required usb_serial / usb_wwan to be
>> activated and some more ("cde-ether" or sth. sound similiar...).
>> ( Currently, I am not sitting (it's a Windows machine) in front of my
>> machine, so I cannot send you my latest kernel-config. )
>>
>> As usually I looked into Documentation directory.
>> So, my 1st question where do I get some informations in general on
>> this topic - usb [1] or net subdirectory (seen from kernel-side)?
>> I found a usb-serial kernel-doc [1].
>> ( I have no Linux Git source so I cannot grep for patterns. )
>
> None of those really have any information about WWAN specific setup, and
> I fear that if documentation was added, it would be quickly out-of-date
> because device manufacturers change things so frequently.
>
Anyway as said above a brief documentation would be nice.
Dunno placed below "networking" or "usb" - what is your POV?
>> The next mystery is what is network-manager doing in the background?
>> I have seen that modem-manager is invoked, but as said I would like to
>> understand the "internas" (means check the logs, turn on some
>> debugging kernel-space/user-space, etc.).
>
> NetworkManager uses ModemManager for all WWAN control, NM only handles
> the configuration storage and IP addressing parts of the setup.
> ModemManager handles modem hardware detection, capability detection,
> WWAN registration and setup, signal strength reporting, network
> connection initiation, and bearer IP addressing method determination.
>
Hmm, as I have a GUI hiding what's going on behind the scenes :-), I
wanted to have a step-by-step understanding - not only in words - also
understanding my logs.
What about putting this section in sth. like a "(General Overview:)
Userland software".
> If you want more information from ModemManager, you can run "mmcli
> --help" or "mmcli --set-logging=debug".
>
That sort of information could be placed in a "Debugging (userland)" section.
Or at least with some links to what Alexander pointed to.
What sort of debugging can I do from kernel-side (-> "Debugging kernel-side")?
>> I am not sure but syncing with 3G network seems to take a while since
>> I really can connect to the Internet.
>
> What do you mean by "syncing"?
>
"Syncing" means here setting up my Internet 3G (PPP) connection or
more precisely after I plugin my USB Internet-stick (usable in my
Linux OS) it takes some time to check for the next 2G/3G "attenna
tower" or "receiver/transmitter mast" (translation according to
<dict.leo.org>).
Checking my dmesg...
My eth0 is setup within 25secs and ready to receive/send from/to my
network-interface, whereas my PPP connection around 72secs.
As I have no automatic dialin selected in NM, I have to activate...
* 1st "mobile broadband"
* and then select the (provider) profile in a second step
So we are talking about 1 minute after login into my desktop, I can
live with that.
What I had in mind is... How can I accelerate/speedup (and establish)
an Internet 3G connection.
If you can give me your guidance, I am willing to write down a 1st
draft of a "usb-wwan-networking" documentation (currently I am really
busy with daily life and I hope I find some minutes).
I am looking for a "YES, I will." :-).
Regards.
- Sedat -
--
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
* Re: [PATCH net-next 0/3] dev_disable_lro() improvements for stacked devices
From: Michal Kubecek @ 2014-11-12 13:15 UTC (permalink / raw)
To: David Miller; +Cc: vfalico, netdev, linux-kernel, j.vosburgh, andy, jiri
In-Reply-To: <20141111.214752.266800170368088905.davem@davemloft.net>
On Tue, Nov 11, 2014 at 09:47:52PM -0500, David Miller wrote:
>
> Please do it generically.
>
> Having a special stanza for each layered device type in
> dev_disable_lro() is beyond stupid. Especially when it
> can in fact be done cleanly.
I gave it some thought and I would like ask one question first:
Does the upper-lower relationship always mean that upper device receives
packets through its lower device(s) so that LRO should always be
disabled for lower devices whenever there are some? Or should it be
limited only to an explicit list of device types (vlan, macvlan, bond,
team)?
Michal Kubecek
^ permalink raw reply
* Device Tree Binding for Marvell DSA Switch on imx28 board over Mdio Interface
From: Oliver Graute @ 2014-11-12 13:07 UTC (permalink / raw)
To: netdev
Hello,
how do I specify the DSA node and the MDIO node in the Device Tree
Binding to integrate a Marvell 88e6071 switch with a imx28 board?
On my board the Marvell switch 88e6071 is connected via phy1 (on a
imx28 PCB) to phy5 on the Marvell switch (on a Switch PCB). All phys
are connected via the same MDIO Bus.
I enabled the Marvell DSA Support Driver, Gianfar Ethernet Driver and
Freescale PQ MDIO Driver in the Kernel (I' am not sure if this is the
right choice for imx28 fec ethernet controller is it?)
I already know that I need to adapt the DSA driver for this new
switch. But currently I can't access the switch ports because my MDIO
Bus is not configured correctly. It always ends with:
dmesg | grep -E "mii|dsa|mdio"
[ 2.528900] libphy: fec_enet_mii_bus: probed
[ 3.028061] !!!!Enter dsa Probe!!!!!
[ 3.037640] !!!!!Enter dsa_of_probe!!!!!
[ 3.041736] !!!!before of_parse_phandle dsa,mii-bus!!!!!
[ 3.047123] !!!! mdio->name=ethernet-phy !!!!!
[ 3.051658] !!!!before of_mdio_find_bus!!!!!
[ 3.055950] !!!!!enter of_mdio_find_bus!!!!!
[ 3.074074] !!!!!enter of_mdio_bus_match!!!!!
[ 3.078451] !!!!!enter of_mdio_bus_match!!!!!
[ 3.088915] !!!!Leave of_mdio_find_bus !!!!!
[ 3.093268] !!!! return of_mdio_find_bus =22 !!!!!
[ 3.098166] dsa_of_probe returns=-22
[ 3.101858] dsa: probe of dsa.5 failed with error -22
[ 19.169423] fec 800f0000.ethernet eth0: Freescale FEC PHY driver
[Micrel KSZ8041] (mii_bus:phy_addr=800f0000.etherne:00, irq=-1)
[ 20.038786] fec 800f4000.ethernet eth1: Freescale FEC PHY driver
[Micrel KSZ8041] (mii_bus:phy_addr=800f0000.etherne:01, irq=-1)
because the method of_mdio_find_bus returns with EINVAL
I suspect that the problem is the fact that the Kernel is not getting
connected to the MDIO bus.
what is wrong here?
dsa@0 {
compatible = "marvell,dsa";
#address-cells = <2>;
#size-cells = <0>;
interrupts = <10>;
dsa,ethernet = <ð1>;
dsa,mii-bus = <ðphy1>;
switch@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <5 0>; /* MDIO address 5, switch 0 in tree */
port@0 {
reg = <0>;
label = "lan1";
phy-handle = <ðphy1>;
};
port@1 {
reg = <1>;
label = "lan2";
};
port@2 {
reg = <2>;
label = "lan3";
};
port@3 {
reg = <3>;
label = "lan4";
};
port@4 {
reg = <4>;
label = "lan5";
};
port@5 {
reg = <5>;
label = "cpu";
};
};
};
eth1: eth1 {
status = "okay";
ethernet1-port@1 {
phy-handle = <ðphy1>;
};
};
mdio_bus: mdio {
#address-cells = <1>;
#size-cells = <0>;
device_type = "mdio";
//compatible = "fsl,gianfar-mdio";
compatible = "fsl,mpc875-fec-mdio", "fsl,pq1-fec-mdio";
reg = <0xe00 0x188>;
status = "okay";
ethphy0: ethernet-phy@0 {
reg = <0>;
};
ethphy1: ethernet-phy@1 {
reg = <1>;
};
//reg = <0xff>; */ /* No PHY attached */
//speed = <1000>;
//duple = <1>;
};
Best regards,
Oliver Graute
^ permalink raw reply
* Re: [patch net-next 2/2] sched: introduce vlan action
From: Jamal Hadi Salim @ 2014-11-12 13:06 UTC (permalink / raw)
To: Jiri Pirko, Cong Wang
Cc: netdev, David Miller, Pravin B Shelar, Tom Herbert, Eric Dumazet,
willemb, Daniel Borkmann, mst, Florian Westphal, Paul.Durrant,
Thomas Graf
In-Reply-To: <54635AAC.3080600@mojatatu.com>
On 11/12/14 08:03, Jamal Hadi Salim wrote:
> On 11/12/14 07:34, Jiri Pirko wrote:
> It just happens that user space passes it to you in BE already.
> So this works out because skb_vlan_push expects that to be in BE
> as in:
> int skb_vlan_push(struct sk_buff *skb, __be16 vlan_proto, u16 vlan_tci)
>
Sorry, meant proto is in BE but vlan is in host order..
(grr.. need to test).
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next 2/2] sched: introduce vlan action
From: Jamal Hadi Salim @ 2014-11-12 13:03 UTC (permalink / raw)
To: Jiri Pirko, Cong Wang
Cc: netdev, David Miller, Pravin B Shelar, Tom Herbert, Eric Dumazet,
willemb, Daniel Borkmann, mst, Florian Westphal, Paul.Durrant,
Thomas Graf
In-Reply-To: <20141112123445.GE1882@nanopsycho.orion>
On 11/12/14 07:34, Jiri Pirko wrote:
> Tue, Nov 11, 2014 at 11:33:21PM CET, cwang@twopensource.com wrote:
>> On Tue, Nov 11, 2014 at 2:13 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>>> +static int tcf_vlan_init(struct net *net, struct nlattr *nla,
>>> + struct nlattr *est, struct tc_action *a,
>>> + int ovr, int bind)
>>> +{
>>> + struct nlattr *tb[TCA_VLAN_MAX + 1];
>>> + struct tc_vlan *parm;
>>> + struct tcf_vlan *v;
>>> + int action;
>>> + __be16 push_vid = 0;
>>> + __be16 push_proto = 0;
>>> + int ret = 0;
>>> + int err;
>>> +
>>> + if (!nla)
>>> + return -EINVAL;
>>> +
>>> + err = nla_parse_nested(tb, TCA_VLAN_MAX, nla, vlan_policy);
>>> + if (err < 0)
>>> + return err;
>>> +
>>> + if (!tb[TCA_VLAN_PARMS])
>>> + return -EINVAL;
>>> + parm = nla_data(tb[TCA_VLAN_PARMS]);
>>> + switch (parm->v_action) {
>>> + case TCA_VLAN_ACT_POP:
>>> + break;
>>> + case TCA_VLAN_ACT_PUSH:
>>> + if (!tb[TCA_VLAN_PUSH_VLAN_ID])
>>> + return -EINVAL;
>>> + push_vid = nla_get_u16(tb[TCA_VLAN_PUSH_VLAN_ID]);
>>
>> nla_get_be16() ?
>
> No. I made this the same as it is done in net/8021q/vlan_netlink.c
>
It just happens that user space passes it to you in BE already.
So this works out because skb_vlan_push expects that to be in BE
as in:
int skb_vlan_push(struct sk_buff *skb, __be16 vlan_proto, u16 vlan_tci)
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next 2/2] sched: introduce vlan action
From: Jiri Pirko @ 2014-11-12 12:34 UTC (permalink / raw)
To: Cong Wang
Cc: netdev, David Miller, Jamal Hadi Salim, Pravin B Shelar,
Tom Herbert, Eric Dumazet, willemb, Daniel Borkmann, mst,
Florian Westphal, Paul.Durrant, Thomas Graf
In-Reply-To: <CAHA+R7O=_h4HEF01wFacteawVX-2uvMiPjUAExKV6GphSJySzg@mail.gmail.com>
Tue, Nov 11, 2014 at 11:33:21PM CET, cwang@twopensource.com wrote:
>On Tue, Nov 11, 2014 at 2:13 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>> +static int tcf_vlan_init(struct net *net, struct nlattr *nla,
>> + struct nlattr *est, struct tc_action *a,
>> + int ovr, int bind)
>> +{
>> + struct nlattr *tb[TCA_VLAN_MAX + 1];
>> + struct tc_vlan *parm;
>> + struct tcf_vlan *v;
>> + int action;
>> + __be16 push_vid = 0;
>> + __be16 push_proto = 0;
>> + int ret = 0;
>> + int err;
>> +
>> + if (!nla)
>> + return -EINVAL;
>> +
>> + err = nla_parse_nested(tb, TCA_VLAN_MAX, nla, vlan_policy);
>> + if (err < 0)
>> + return err;
>> +
>> + if (!tb[TCA_VLAN_PARMS])
>> + return -EINVAL;
>> + parm = nla_data(tb[TCA_VLAN_PARMS]);
>> + switch (parm->v_action) {
>> + case TCA_VLAN_ACT_POP:
>> + break;
>> + case TCA_VLAN_ACT_PUSH:
>> + if (!tb[TCA_VLAN_PUSH_VLAN_ID])
>> + return -EINVAL;
>> + push_vid = nla_get_u16(tb[TCA_VLAN_PUSH_VLAN_ID]);
>
>nla_get_be16() ?
No. I made this the same as it is done in net/8021q/vlan_netlink.c
>
>
>> + if (push_vid >= VLAN_VID_MASK)
>> + return -ERANGE;
>> +
>
>htons() ?
>
>[...]
>
>> +static int tcf_vlan_dump(struct sk_buff *skb, struct tc_action *a,
>> + int bind, int ref)
>> +{
>> + unsigned char *b = skb_tail_pointer(skb);
>> + struct tcf_vlan *v = a->priv;
>> + struct tc_vlan opt = {
>> + .index = v->tcf_index,
>> + .refcnt = v->tcf_refcnt - ref,
>> + .bindcnt = v->tcf_bindcnt - bind,
>> + .action = v->tcf_action,
>> + .v_action = v->tcfv_action,
>> + };
>> + struct tcf_t t;
>> +
>> + if (nla_put(skb, TCA_VLAN_PARMS, sizeof(opt), &opt))
>> + goto nla_put_failure;
>> +
>> + if (v->tcfv_action == TCA_VLAN_ACT_PUSH &&
>> + nla_put_u16(skb, TCA_VLAN_PUSH_VLAN_ID, v->tcfv_push_vid) &&
>> + nla_put_u16(skb, TCA_VLAN_PUSH_VLAN_PROTOCOL, v->tcfv_push_proto))
>> + goto nla_put_failure;
>
>nla_put_be16() ?
^ permalink raw reply
* Re: [PATCH -next 2/2] seq_putc: Convert to return void and convert uses too.
From: Pablo Neira Ayuso @ 2014-11-12 12:29 UTC (permalink / raw)
To: Petr Mladek
Cc: Joe Perches, Steven Rostedt, Corey Minyard, Alexander Viro,
Patrick McHardy, Jozsef Kadlecsik, David S. Miller,
Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
openipmi-developer, linux-kernel, linux-fsdevel, netfilter-devel,
coreteam, netdev
In-Reply-To: <20141111134740.GB2567@pathway.suse.cz>
On Tue, Nov 11, 2014 at 02:47:40PM +0100, Petr Mladek wrote:
> On Mon 2014-11-10 10:58:57, Joe Perches wrote:
> > Using the return value of seq_putc is error-prone, so
> > make it return void instead.
> >
> > Reverse the logic in seq_putc to make it like seq_puts.
> >
> > Signed-off-by: Joe Perches <joe@perches.com>
>
> Reviewed-by: Petr Mladek <pmladek@suse.cz>
>
> The changes are correct. The show() functions should return 0
> even when there is an overflow. They are called by traverse()
> from seq_read() that might increase the buffer size and try again.
Just in case you need this for the netfilter chunks:
Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
Thanks.
^ permalink raw reply
* Re: [patch net-next 2/2] sched: introduce vlan action
From: Jamal Hadi Salim @ 2014-11-12 12:27 UTC (permalink / raw)
To: Jiri Pirko, Cong Wang
Cc: netdev, David Miller, Pravin B Shelar, Tom Herbert, Eric Dumazet,
willemb, Daniel Borkmann, mst, Florian Westphal, Paul.Durrant,
Thomas Graf
In-Reply-To: <20141112074755.GA1882@nanopsycho.orion>
On 11/12/14 02:47, Jiri Pirko wrote:
> Wed, Nov 12, 2014 at 12:18:47AM CET, cwang@twopensource.com wrote:
>> I know vlan tag is not exactly the skb metadata, but still seems
>> fits in skbedit for me.
>
> I was thinking about that as well. It seems much clearer to add a new
> action.
>
Cong,
I think it is better to have all these "tunneling" activities
as a separate action each. It is cleaner from a usability perspective.
[e.g. it is not hard to express nat action with pedit action or take
checksum out of nat since we have a csum action), but makes sense to
have it separate)].
cheers,
jamal
^ permalink raw reply
* RE: phy/micrel: KSZ8031RNL RMII clock reconfiguration bug
From: Bruno Thomsen @ 2014-11-12 12:17 UTC (permalink / raw)
To: Johan Hovold
Cc: netdev@vger.kernel.org, f.fainelli@gmail.com,
s.hauer@pengutronix.de, bruno.thomsen@gmail.com,
linux-kernel@vger.kernel.org
In-Reply-To: <20141111194101.GI29789@localhost>
Hi Johan,
> As you may have seen by now, I've been working on refactoring the micrel phy driver to be able to use common initialisation code.
>
> Specifically, I've added generic support for disabling the broadcast address, which is what the MII_KSZPHY_OMSO write above does.
>
> Generally you want this to be the first thing you do in order to avoid unnecessary reconfigurations. If we ever were to allow concurrent probing this would also be a requirement.
>
> Could you provide some detail about the setup were you find that the PHY becomes unresponsive without your patch? Do you have more than one PHY on the bus? Using what addresses? And using what clock modes (i.e. 25 MHz or 50 MHz)?
>
> Also, what exactly do you mean by "unresponsive"? Are you still able to read the PHY registers for example?
I think it sounds like a good idea to refactor the init code.
My setup:
iMX28 processor with dual Ethernet MAC; FEC0 (enabled) and FEC1 (disabled).
There is a single KSZ8031 PHY that receives 50MHz RMII clock from the MAC.
I am unable to read PHY registers from both user-land tools and extra debug PHY reads in driver code.
Boot trace:
[ 22.277785] fec 800f0000.ethernet eth0: Freescale FEC PHY driver [Micrel KSZ8031] (mii_bus:phy_addr=800f0000.etherne:00, irq=-1)
[ 22.292527] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 24.276217] libphy: 800f0000.etherne:00 - Link is Up - 100/Full
[ 24.285094] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Venlig hilsen / Best regards
Kamstrup A/S <http://www.kamstrup.dk>
Bruno Thomsen
Development engineer
Technology
Kamstrup A/S
Industrivej 28
DK-8660 Skanderborg
Tel: +45 89 93 10 00
Fax: +45 89 93 10 01
Dir: +45 89 93 13 94
E-mail: bth@kamstrup.dk
Web: www.kamstrup.dk
^ permalink raw reply
* Re: [patch net-next 1/2] net: move vlan pop/push functions into common code
From: Jiri Pirko @ 2014-11-12 11:59 UTC (permalink / raw)
To: Pravin Shelar
Cc: netdev, David Miller, Jamal Hadi Salim, Tom Herbert, Eric Dumazet,
willemb, Daniel Borkmann, mst, fw, Paul.Durrant, Thomas Graf
In-Reply-To: <CALnjE+qRASQx8pcaB7z9D3_x2ybA4h-Uh2Ppn9EJVG3YU8gSGg@mail.gmail.com>
Tue, Nov 11, 2014 at 06:24:15PM CET, pshelar@nicira.com wrote:
>On Tue, Nov 11, 2014 at 2:13 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>> So it can be used from out of openvswitch code.
>> Did couple of cosmetic changes on the way, namely variable naming and
>> adding support for 8021AD proto.
>>
>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>> ---
>> include/linux/skbuff.h | 2 ++
>> net/core/skbuff.c | 86 +++++++++++++++++++++++++++++++++++++++++++++++
>> net/openvswitch/actions.c | 76 ++---------------------------------------
>> 3 files changed, 90 insertions(+), 74 deletions(-)
>>
>> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
>> index 103fbe8..3b0445c 100644
>> --- a/include/linux/skbuff.h
>> +++ b/include/linux/skbuff.h
>> @@ -2673,6 +2673,8 @@ void skb_scrub_packet(struct sk_buff *skb, bool xnet);
>> unsigned int skb_gso_transport_seglen(const struct sk_buff *skb);
>> struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features);
>> struct sk_buff *skb_vlan_untag(struct sk_buff *skb);
>> +int skb_vlan_pop(struct sk_buff *skb);
>> +int skb_vlan_push(struct sk_buff *skb, __be16 vlan_proto, u16 vlan_tci);
>>
>> struct skb_checksum_ops {
>> __wsum (*update)(const void *mem, int len, __wsum wsum);
>> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
>> index 7001896..75e53d4 100644
>> --- a/net/core/skbuff.c
>> +++ b/net/core/skbuff.c
>> @@ -4151,6 +4151,92 @@ err_free:
>> }
>> EXPORT_SYMBOL(skb_vlan_untag);
>>
>> +/* remove VLAN header from packet and update csum accordingly. */
>> +static int __skb_vlan_pop(struct sk_buff *skb, u16 *vlan_tci)
>> +{
>> + struct vlan_hdr *vhdr;
>> + int err;
>> +
>> + if (!pskb_may_pull(skb, VLAN_ETH_HLEN))
>> + return -ENOMEM;
>> +
>> + if (!skb_cloned(skb) || skb_clone_writable(skb, VLAN_ETH_HLEN))
>> + return 0;
>> +
>> + err = pskb_expand_head(skb, 0, 0, GFP_ATOMIC);
>> + if (unlikely(err))
>> + return err;
>> +
>> + if (skb->ip_summed == CHECKSUM_COMPLETE)
>> + skb->csum = csum_sub(skb->csum, csum_partial(skb->data
>> + + (2 * ETH_ALEN), VLAN_HLEN, 0));
>> +
>> + vhdr = (struct vlan_hdr *)(skb->data + ETH_HLEN);
>> + *vlan_tci = ntohs(vhdr->h_vlan_TCI);
>> +
>> + memmove(skb->data + VLAN_HLEN, skb->data, 2 * ETH_ALEN);
>> + __skb_pull(skb, VLAN_HLEN);
>> +
>> + vlan_set_encap_proto(skb, vhdr);
>> + skb->mac_header += VLAN_HLEN;
>> + if (skb_network_offset(skb) < ETH_HLEN)
>> + skb_set_network_header(skb, ETH_HLEN);
>> + skb_reset_mac_len(skb);
>> +
>> + return 0;
>> +}
>> +
>> +int skb_vlan_pop(struct sk_buff *skb)
>> +{
>> + u16 vlan_tci;
>> + __be16 vlan_proto;
>> + int err;
>> +
>> + if (likely(vlan_tx_tag_present(skb))) {
>> + skb->vlan_tci = 0;
>> + } else {
>> + if (unlikely((skb->protocol != htons(ETH_P_8021Q) &&
>> + skb->protocol != htons(ETH_P_8021AD)) ||
>> + skb->len < VLAN_ETH_HLEN))
>> + return 0;
>> +
>> + err = __skb_vlan_pop(skb, &vlan_tci);
>> + if (err)
>> + return err;
>> + }
>> + /* move next vlan tag to hw accel tag */
>> + if (likely((skb->protocol != htons(ETH_P_8021Q) &&
>> + skb->protocol != htons(ETH_P_8021AD)) ||
>> + skb->len < VLAN_ETH_HLEN))
>> + return 0;
>> +
>> + vlan_proto = skb->protocol;
>> + err = __skb_vlan_pop(skb, &vlan_tci);
>> + if (unlikely(err))
>> + return err;
>> +
>> + __vlan_hwaccel_put_tag(skb, vlan_proto, vlan_tci);
>> + return 0;
>> +}
>> +EXPORT_SYMBOL(skb_vlan_pop);
>> +
>> +int skb_vlan_push(struct sk_buff *skb, __be16 vlan_proto, u16 vlan_tci)
>> +{
>> + if (vlan_tx_tag_present(skb)) {
>> + /* push down current VLAN tag */
>> + if (!__vlan_put_tag(skb, skb->vlan_proto,
>> + vlan_tx_tag_get(skb)))
>> + return -ENOMEM;
>> +
>Since you are restructuring this code, can you also change
>__vlan_put_tag() to not free skb on error. So that these two new
>functions can have common error handling code.
That is not directly related to this patchset. I believe that should be
changed in separate patch later on.
^ permalink raw reply
* Re: Understanding what's going on when using a Huawei E173 USB 3G web-stick (UMTS/HSPA)
From: Aleksander Morgado @ 2014-11-12 11:54 UTC (permalink / raw)
To: Dan Williams
Cc: sedat.dilek, Greg KH, David S. Miller, netdev@vger.kernel.org,
linux-usb
In-Reply-To: <1415120132.31049.11.camel@dcbw.local>
>
> NetworkManager uses ModemManager for all WWAN control, NM only handles
> the configuration storage and IP addressing parts of the setup.
> ModemManager handles modem hardware detection, capability detection,
> WWAN registration and setup, signal strength reporting, network
> connection initiation, and bearer IP addressing method determination.
>
> If you want more information from ModemManager, you can run "mmcli
> --help" or "mmcli --set-logging=debug".
>
That (mmcli) will only be available in ModemManager >= 1.x, BTW. And
beware of --set-logging=debug, as syslog may limit those if MM sends
too many too fast. In general I usually prefer to ask for --debug
output just in case:
http://www.freedesktop.org/wiki/Software/ModemManager/Debugging/
I saw the reporter talk about Ubuntu Precise (12.04) and Trusty
(14.04), so only in the latter mmcli will be available (if I'm not
mistaken). For Precise, this Ubuntu page shows how to enable debug
logs:
https://wiki.ubuntu.com/DebuggingModemmanager
--
Aleksander
https://aleksander.es
^ permalink raw reply
* Re: [PATCH] crypto: aesni-intel - avoid IPsec re-ordering
From: Steffen Klassert @ 2014-11-12 11:48 UTC (permalink / raw)
To: Ming Liu; +Cc: herbert, davem, ying.xue, linux-crypto, netdev
In-Reply-To: <54633958.2080705@windriver.com>
On Wed, Nov 12, 2014 at 06:41:28PM +0800, Ming Liu wrote:
> On 11/12/2014 04:41 PM, Steffen Klassert wrote:
> >On Wed, Nov 12, 2014 at 01:49:31PM +0800, Ming Liu wrote:
> >> }
> >>@@ -147,11 +149,9 @@ static void cryptd_queue_worker(struct work_struct *work)
> >> preempt_disable();
> >> backlog = crypto_get_backlog(&cpu_queue->queue);
> >> req = crypto_dequeue_request(&cpu_queue->queue);
> >>- preempt_enable();
> >>- local_bh_enable();
> >Everything below the local_bh_enable() should not run in atomic context
> >as the subsequent functions may set the CRYPTO_TFM_REQ_MAY_SLEEP flag.
> If I turn off all the CRYPTO_TFM_REQ_MAY_SLEEP in cryptd.c, is that
> going to work?
Well, this might make the cryptd function accessible in atomic context,
but it does not solve the other problems with this approach. Also,
cryptd can be used to move requests out of atomic context and I think
it should stay as it is.
^ permalink raw reply
* Re: [PATCH] crypto: aesni-intel - avoid IPsec re-ordering
From: Steffen Klassert @ 2014-11-12 11:43 UTC (permalink / raw)
To: Ming Liu; +Cc: Herbert Xu, davem, ying.xue, linux-crypto, netdev
In-Reply-To: <5463395A.5040200@windriver.com>
On Wed, Nov 12, 2014 at 06:41:30PM +0800, Ming Liu wrote:
> On 11/12/2014 04:51 PM, Herbert Xu wrote:
> >On Wed, Nov 12, 2014 at 09:41:38AM +0100, Steffen Klassert wrote:
> >>Can't we just use cryptd unconditionally to fix this reordering problem?
> >I think the idea is that most of the time cryptd isn't required
> >so we want to stick with direct processing to lower latency.
> >
> >I think the simplest fix would be to punt to cryptd as long as
> >there are cryptd requests queued.
> I've tried that method when I started to think about the fix, but it
> will cause 2 other issues per test while resolving the reordering
> one, as follows:
> 1 The work queue can not handle so many packets when the traffic is
> very high(over 200M/S), and it would drop most of them when the
> queue length is beyond CRYPTD_MAX_CPU_QLEN.
That's why I've proposed to adjust CRYPTD_MAX_CPU_QLEN in my other mail.
But anyway, it still does not fix the reorder problem completely.
We still have a problem if subsequent algorithms run asynchronously
or if we get interrupted while we are processing the last request
from the queue.
I think we have only two options, either processing all calls
directly or use cryptd unconditionally. Mixing direct and
asynchronous calls will lead to problems.
If we don't want to use cryptd unconditionally, we could use
direct calls for all requests. If the fpu is not usable, we
maybe could fallback to an algorithm that does not need the
fpu, such as aes-generic.
^ permalink raw reply
* Re: [PATCH v1 net-next 1/2] bonding: Expand speed type bits of the AD Port Key
From: Veaceslav Falico @ 2014-11-12 11:20 UTC (permalink / raw)
To: Jianhua Xie; +Cc: Jay Vosburgh, David Miller, netdev, andy
In-Reply-To: <54632E25.3000205@freescale.com>
On Wed, Nov 12, 2014 at 05:53:41PM +0800, Jianhua Xie wrote:
>Thanks you two for the valuable comments.
>
>If my understanding is right, it is encouraged to use a counter
>rather than a bitmask for the speed field, right?
>
>if yes, how many bits are better to use for current speed and
>future speed (like 100Gbps/400Gbps and etc.)? I am not sure
>that 5 bits are enough (2**5=32) or not. And I am clear to keep
>"the duplex bit in the key " in my mind.
>
>if not, what's your recommendation please?
As it's visible to bonding only, I guess a simple enum should do the trick.
No need to invent something special, and it'll fit nicely with other enums
from AD.
>
>Thanks & Best Regards,
>Jianhua
>
>在 2014年11月12日 03:47, Jay Vosburgh 写道:
>>David Miller <davem@davemloft.net> wrote:
>>
>>>From: Xie Jianhua <Jianhua.Xie@freescale.com>
>>>Date: Mon, 10 Nov 2014 15:16:40 +0800
>>>
>>>>From: Jianhua Xie <Jianhua.Xie@freescale.com>
>>>>
>>>>Port Key was determined as 16 bits according to the link speed,
>>>>duplex and user key (which is yet not supported), in which key
>>>>speed was 5 bits for 1Mbps/10Mbps/100Mbps/1Gbps/10Gbps as below:
>>>>--------------------------------------------------------------
>>>>Port key :| User key | Speed | Duplex|
>>>>--------------------------------------------------------------
>>>>16 6 1 0
>>>>This patch is expanding speed type from 5 bits to 9 bits for other
>>>>speed 2.5Gbps/20Gbps/40Gbps/56Gbps and shrinking user key from 10
>>>>bits to 6 bits. New Port Key looks like below:
>>>>--------------------------------------------------------------
>>>>Port key :| User key | Speed | Duplex|
>>>>--------------------------------------------------------------
>>>>16 10 1 0
>>>>
>>>Do we determine the layout of this value all ourselves?
>> Yes, we do. The precise format of the port key is not defined
>>by the standard; IEEE 802.1AX 5.3.5, "Capability identification":
>>
>>"A given Key value is meaningful only in the context of the System that
>>allocates it; there is no global significance to Key values."
>>
>> and
>>
>>"When a System assigns an operational Key value to a set of ports, it
>>signifies that, in the absence of other constraints, the current
>>operational state of the set of ports allows any subset of that set of
>>ports (including the entire set) to be aggregated together from the
>>perspective of the System making the assignment."
>>
>> So, basically, it's a magic cookie that indicates that all ports
>>on a particular system with the same key value are suitable to be
>>aggregated together.
>>
>>>If not, then is it exported to anything user-visible that we
>>>might be breaking?
>> The key values are not user-visible, and the "user" settable
>>portion of the key has never been implemented.
>>
>>>If it is private, it makes no sense to use a bitmask for the speed.
>>>We should instead change the field to be some numerically increasing
>>>value.
>>>
>>>Otherwise we'll run out of bits again and keep having to adjust the
>>>field layout more often than we really need to.
>> Agreed.
>>
>> Also note that there are some internal dependencies within
>>bonding on the format; in particular the duplex bit in the key is used
>>to determine if a port is LACP-capable, and that functionality needs to
>>be preserved.
>>
>> -J
>>
>>---
>> -Jay Vosburgh, jay.vosburgh@canonical.com
>
^ permalink raw reply
* [PATCH] net: pxa168_eth: move SET_NETDEV_DEV a bit earlier
From: Jisheng Zhang @ 2014-11-12 11:08 UTC (permalink / raw)
To: davem, antoine.tenart, arnd, sebastian.hesselbarth
Cc: netdev, linux-kernel, linux-arm-kernel, Jisheng Zhang
This is to ensure the net_device's dev.parent is set before we used it
in dma_zalloc_coherent() from init_hash_table().
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
---
drivers/net/ethernet/marvell/pxa168_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/pxa168_eth.c b/drivers/net/ethernet/marvell/pxa168_eth.c
index 21ddece..38f7cee 100644
--- a/drivers/net/ethernet/marvell/pxa168_eth.c
+++ b/drivers/net/ethernet/marvell/pxa168_eth.c
@@ -1540,8 +1540,8 @@ static int pxa168_eth_probe(struct platform_device *pdev)
if (err)
goto err_free_mdio;
- pxa168_init_hw(pep);
SET_NETDEV_DEV(dev, &pdev->dev);
+ pxa168_init_hw(pep);
err = register_netdev(dev);
if (err)
goto err_mdiobus;
--
2.1.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