* Re: [PATCH net-next v7 0/8] openvswitch: VXLAN tunneling.
From: David Miller @ 2013-08-20 7:17 UTC (permalink / raw)
To: pshelar; +Cc: netdev, stephen
In-Reply-To: <1376936559-25427-1-git-send-email-pshelar@nicira.com>
From: Pravin B Shelar <pshelar@nicira.com>
Date: Mon, 19 Aug 2013 11:22:39 -0700
> First four vxlan patches extends vxlan so that openvswitch
> can share vxlan recv code. Rest of patches refactors vxlan
> data plane so that ovs can share that code with vxlan module.
> Last patch adds vxlan-vport to openvswitch.
>
> v7 fixed first patch as suggested by Stephen Hemminger.
> v6 series splits second patch into two and has few style fixes.
> v5 series disallow any udp port sharing between
> kernel-vxlan and ovs-vxlan as suggested by Stephen Hemminger.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net 0/6] bnx2x: Bug fixes patch series
From: David Miller @ 2013-08-20 7:22 UTC (permalink / raw)
To: yuvalmin; +Cc: netdev, ariele, eilong
In-Reply-To: <1376892721-10410-1-git-send-email-yuvalmin@broadcom.com>
From: "Yuval Mintz" <yuvalmin@broadcom.com>
Date: Mon, 19 Aug 2013 09:11:55 +0300
> This patch series contains bug fixes, mostly for either DCBX
> or VF configuration.
>
> Please consider applying these patches to `net'.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/5] qlcnic: Enable support for 84xx Series adapter
From: David Miller @ 2013-08-20 7:32 UTC (permalink / raw)
To: himanshu.madhani; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <cover.1376720973.git.himanshu.madhani@qlogic.com>
From: Himanshu Madhani <himanshu.madhani@qlogic.com>
Date: Fri, 16 Aug 2013 19:07:12 -0400
> From: Himanshu Madhani <himanshu.madhani@qlogic.com>
>
> This patch series enables support for 84xx series adapters.
>
> Please apply to net-next
>
Series applied, thanks.
^ permalink raw reply
* Re: [RFC 0/2] Account for duplicate ACKs with invalid SACK-blocks
From: Christoph Paasch @ 2013-08-20 7:36 UTC (permalink / raw)
To: Corey Hickey; +Cc: Eric Dumazet, netdev, Phil Oester, Benjamin Hesmans
In-Reply-To: <52128CA6.6090001@fatooh.org>
On 19/08/13 - 14:22:46, Corey Hickey wrote:
> On 2013-08-19 12:29, Christoph Paasch wrote:
> > There exist sequence-number rewriting middleboxes, who do not modify the
> > sequence-number in the SACK-blocks.
> > Duplicate acknowledgments with these (invalid) SACK-blocks will not be
> > accounted in sacked_out, and thus no fast-retransmit will trigger.
> > So, the only way to recover from a packet-loss is through an RTO,
> > effectively killing the performance of TCP in this case.
> >
> > Performance-results can be seen here:
> > http://tools.ietf.org/agenda/87/slides/slides-87-tcpm-11.pdf
> >
> > Another solution might be to simply disable SACK, as soon as an invalid
> > SACK-block has been received (as suggested by Phil Oester). This however
> > might be too aggressive.
> >
> > Christoph Paasch (2):
> > Use acked_out for reno-style ack acounting instead of sacked_out
> > Account acked_out in sack, if the sack is invalid
> >
> > include/linux/tcp.h | 1 +
> > include/net/tcp.h | 17 +++++---
> > net/ipv4/tcp_input.c | 103 ++++++++++++++++++++++++++++++++---------------
> > net/ipv4/tcp_minisocks.c | 1 +
> > net/ipv4/tcp_output.c | 6 +--
> > net/ipv4/tcp_timer.c | 2 +-
> > 6 files changed, 89 insertions(+), 41 deletions(-)
>
> I tested this patchset, and, unfortunately, the behavior seems to be the
> same.
Yes, because the problem is still on conntrack's side too.
As soon as conntrack will let pass the invalid SACK-blocks, you will
experience bad performance because every packet-loss can only be recovered
by an RTO.
My patchset tries to fix this last issue.
Cheers,
Christoph
>
> I'm still planning on working with the Cisco device, when I can get some
> of the network admin's time, but that won't happen immediately.
>
> Thanks,
> Corey
^ permalink raw reply
* Re: [PATCH net-next 2/3] net/mlx4_en: Notify user when TX ring in error state
From: Amir Vadai @ 2013-08-20 7:55 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: David S. Miller, netdev
In-Reply-To: <521268CE.7040508@cogentembedded.com>
On 19/08/2013 21:49, Sergei Shtylyov wrote:
> Hello.
>
> On 08/19/2013 10:42 AM, Amir Vadai wrote:
>
>> When hardware gets into error state, must notify user about it.
>> When QP in error state no traffic will be tx'ed from the attached
>> tx_ring.
>
>> Driver should know how to recover from this unexpected state. I will
>> send later
>> on the recovery flow, but having the print shouldn't be delayed.
>
>> Signed-off-by: Amir Vadai <amirv@mellanox.com>
>> ---
>> drivers/net/ethernet/mellanox/mlx4/en_tx.c | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>
>> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
>> b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
>> index 6dcca98..157bcd1 100644
>> --- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
>> +++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
>> @@ -362,6 +362,14 @@ static void mlx4_en_process_tx_cq(struct
>> net_device *dev, struct mlx4_en_cq *cq)
>> */
>> rmb();
>>
>> + if (unlikely((cqe->owner_sr_opcode & MLX4_CQE_OPCODE_MASK) ==
>> + MLX4_CQE_OPCODE_ERROR)) {
>> + struct mlx4_err_cqe *cqe_err = (struct mlx4_err_cqe *)cqe;
>
> Empty line wouldn't hurt here, after declaration.
>
>> + en_err(priv, "CQE error - vendor syndrom: 0x%x syndrom:
>> 0x%x\n",
>
> s/syndrom/syndrome/ as below?
>
>> + cqe_err->vendor_err_syndrome,
>> + cqe_err->syndrome);
>> + }
>> +
>
> WBR, Sergei
>
>
Thanks - will be fixed for V1
Amir
^ permalink raw reply
* Re: bonding + arp monitoring fails if interface is a vlan
From: Santiago Garcia Mantinan @ 2013-08-20 8:05 UTC (permalink / raw)
To: Nikolay Aleksandrov; +Cc: netdev
In-Reply-To: <CAJk_L2FuxrZrgg6_95Ww_0nVaE8Ff=1fmsUk+ghxCQ=LPyVzaQ@mail.gmail.com>
Hi!
Sorry it took me so long to reply back. I've been doing more tests on
xor mode and I see that arp monitoring is not working at all. I
haven't found any doc that says which modes should be compatible with
arp monitoring, maybe xor mode shouldn't be used at all.
My last setup is a Linux with a couple of vlans both interfaces
(eth2.1001 and eth2.1002) with IP 192.168.1.1 (no bonding at all) and
another Linux machine with a 3.11-rc3 with Nicolay's arp fix for
bonding and a bond configured like this:
iface bond0 inet static
address 192.168.1.2
netmask 255.255.255.0
bond-slaves eth0.1001 eth0.1002 eth1.1001 eth1.1002
bond-mode balance-xor
bond-arp_validate 0
bond-arp_interval 2000
bond-arp_ip_target 192.168.1.1
A silly switch connects the couple of ethernets of the machine with
the bond to the interface of the not bonded machine.
What I saw was that the bonded machine didn't detect the ifconfig down
of the interfaces of the not bonded machine at all. That drove me to
the hypothesis that the bonded machine was considering its own traffic
(there was no traffic but the arp requests of the bonding) as
indication that the link was ok.
To test the hypothesis, when the not bonded machine (192.168.1.1)
which is the target for arp requests was unplugged and the bonding was
seeing all interfaces up (not detecting that the other machine was not
responding) I unplugged one of the bonded interfaces and all 4 slaves
went to down, then if I replugged it all 4 would go up.
Maybe this is something to be expected due to arp monitoring not
working with balance-xor, but I haven't found any doc saying this.
If you need the debug info for this I can send it, but the events show
nothing, as there are no event saying that link is lost or anything
:-(
Regards.
--
Manty/BestiaTester -> http://manty.net
^ permalink raw reply
* Bridge vlan malfunctions for vid greater than 63
From: Toshiaki Makita @ 2013-08-20 8:07 UTC (permalink / raw)
To: David S. Miller, Vlad Yasevich, netdev; +Cc: Toshiaki Makita
Hello.
Bridge vlan behaves unexpectedly for certain vids.
These are examples on Fedora 19 x86_64:
- "bridge vlan show" command cannot retrieve vids greater than 63,
even if patch 3e805ad (using ifinfomsg instead of rtgenmsg) is
applied.
- When we delete a vid, if no configured vid less than 64 remains,
vlan_info will be freed prematurely, which could delete other
configured vids.
- Parmanent fdb entries could not be deleted even if corresponding vid
is deleted.
I'm afraid that some bitmap functions are given the number of elements
in a bitmap array (BR_VLAN_BITMAP_LEN), which is less than the bit
length.
Example:
static int br_fill_ifinfo(struct sk_buff *skb,
...
if (!pv || bitmap_empty(pv->vlan_bitmap, BR_VLAN_BITMAP_LEN))
As BR_VLAN_BITMAP_LEN is "BITS_TO_LONGS(VLAN_N_VID)", I tested after
changing BR_VLAN_BITMAP_LEN to VLAN_N_VID, and confirmed that this
resolves that malfunctions.
The following mail contains the patch described above.
Please comment if I misunderstood something.
Thanks,
Toshiaki Makita
^ permalink raw reply
* Re: [PATCH net-next 3/3] net/mlx4_en: Fix handling of dma_map failure
From: Amir Vadai @ 2013-08-20 8:17 UTC (permalink / raw)
To: Francois Romieu; +Cc: Amir Vadai, David S. Miller, netdev
In-Reply-To: <20130819204200.GA30818@electric-eye.fr.zoreil.com>
On 19/08/2013 23:42, Francois Romieu wrote:
> Amir Vadai <amirv@mellanox.com> :
> [...]
>> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
>> index 157bcd1..92d7097 100644
>> --- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
>> +++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
>> @@ -673,6 +673,64 @@ netdev_tx_t mlx4_en_xmit(struct sk_buff *skb, struct net_device *dev)
>> tx_info->skb = skb;
>> tx_info->nr_txbb = nr_txbb;
>>
>> + if (lso_header_size)
>> + data = ((void *)&tx_desc->lso + ALIGN(lso_header_size + 4,
>> + DS_SIZE));
>> + else
>> + data = &tx_desc->data;
>> +
>> + /* valid only for none inline segments */
>> + tx_info->data_offset = (void *)data - (void *)tx_desc;
>> +
>> + tx_info->linear = (lso_header_size < skb_headlen(skb) &&
>> + !is_inline(skb, NULL)) ? 1 : 0;
>> +
>> + data += skb_shinfo(skb)->nr_frags + tx_info->linear - 1;
>> +
>> + if (is_inline(skb, &fragptr)) {
>> + tx_info->inl = 1;
>> + } else {
>> + /* Map fragments */
>> + for (i = skb_shinfo(skb)->nr_frags - 1; i >= 0; i--) {
>> + frag = &skb_shinfo(skb)->frags[i];
>> + dma = skb_frag_dma_map(priv->ddev, frag,
>> + 0, skb_frag_size(frag),
>> + DMA_TO_DEVICE);
>> + if (dma_mapping_error(priv->ddev, dma)) {
>
> goto err_unmap_frags;
>
> You have a lot of huge scope variables. At least use these to hide
> the 80 cols problems.
Will try to re-arrange a bit this code - I think I will add another patch.
Split this one into:
1. Code re-arrange
2. Move and handle dma_map_failure
>
>> + for (i++; i < skb_shinfo(skb)->nr_frags; i++) {
>> + frag = &skb_shinfo(skb)->frags[i];
>> + en_err(priv, "DMA mapping error\n");
>> + dma_unmap_page(priv->ddev,
>> + (dma_addr_t) be64_to_cpu(data[i].addr),
>> + skb_frag_size(frag), PCI_DMA_TODEVICE);
>> + }
>> + goto tx_drop;
>> + }
>> +
>> + data->addr = cpu_to_be64(dma);
>> + data->lkey = cpu_to_be32(mdev->mr.key);
>> + wmb();
>> + data->byte_count = cpu_to_be32(skb_frag_size(frag));
>> + --data;
>> + }
>> +
>> + /* Map linear part */
>> + if (tx_info->linear) {
>> + u32 byte_count = skb_headlen(skb) - lso_header_size;
>> + dma = dma_map_single(priv->ddev, skb->data +
>> + lso_header_size, byte_count,
>> + PCI_DMA_TODEVICE);
>> + if (dma_mapping_error(priv->ddev, dma))
>> + goto tx_drop;
>
> (frags dma leak)
Thanks for the catch.
> goto err_unmap_frags;
>
> You may consider a local variable for 'priv->ddev' btw.
Will do
>
Amir.
^ permalink raw reply
* Re: 3.11-rc6 genetlink locking fix offends lockdep
From: Johannes Berg @ 2013-08-20 8:28 UTC (permalink / raw)
To: Hugh Dickins
Cc: Ding Tianhong, Linus Torvalds, Greg KH, David S. Miller,
Otcheretianski, Andrei, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, stable@vger.kernel.org, Pravin B Shelar,
Thomas Graf
In-Reply-To: <alpine.LNX.2.00.1308191147350.1505@eggly.anvils>
On Mon, 2013-08-19 at 11:52 -0700, Hugh Dickins wrote:
> > > > We could use the semaphore instead, I believe, but I don't really
> > > > understand the mutex vs. semaphore well enough to be sure that's
> > > > correct.
> > I don't believe so, the semaphore and cb_mutex don't have a dependency
> > yet, afaict.
>
> The down_read(&cb_lock) patch you suggested gives the lockdep trace below.
Clearly I was wrong then, not sure what I missed in the code though.
>From the lockdep trace it looks like the dependency comes via the
genl_lock, I didn't consider that.
David, can you please just revert it for now and tag the revert for
stable as well, in case Greg already took it somewhere? I think that
some stable trees may need a different fix anyway since they don't have
parallel_ops.
We never saw a problem due to this, and though it's probably fairly easy
to trigger by hand-rolling the dump loop in userspace, one does need to
be able to rmmod to crash the kernel with it.
The only way to fix this that I see right now (that doesn't rewrite the
locking completely) would be to make genetlink use parallel_ops itself,
thereby removing the genl_lock() in genl_rcv_msg() and breaking all
those lock chains that lockdep reported. After that, it should be safe
to use genl_lock() inside all the operations. Something like the patch
below, perhaps? Completely untested so far.
johannes
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index f85f8a2..dea9586 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -665,6 +665,7 @@ static struct genl_family genl_ctrl = {
.version = 0x2,
.maxattr = CTRL_ATTR_MAX,
.netnsok = true,
+ .parallel_ops = true,
};
static int ctrl_fill_info(struct genl_family *family, u32 portid, u32 seq,
@@ -789,10 +790,8 @@ static int ctrl_dumpfamily(struct sk_buff *skb, struct netlink_callback *cb)
struct net *net = sock_net(skb->sk);
int chains_to_skip = cb->args[0];
int fams_to_skip = cb->args[1];
- bool need_locking = chains_to_skip || fams_to_skip;
- if (need_locking)
- genl_lock();
+ genl_lock();
for (i = chains_to_skip; i < GENL_FAM_TAB_SIZE; i++) {
n = 0;
@@ -814,8 +813,7 @@ errout:
cb->args[0] = i;
cb->args[1] = n;
- if (need_locking)
- genl_unlock();
+ genl_unlock();
return skb->len;
}
@@ -870,6 +868,8 @@ static int ctrl_getfamily(struct sk_buff *skb, struct genl_info *info)
struct genl_family *res = NULL;
int err = -EINVAL;
+ genl_lock();
+
if (info->attrs[CTRL_ATTR_FAMILY_ID]) {
u16 id = nla_get_u16(info->attrs[CTRL_ATTR_FAMILY_ID]);
res = genl_family_find_byid(id);
@@ -896,19 +896,25 @@ static int ctrl_getfamily(struct sk_buff *skb, struct genl_info *info)
}
if (res == NULL)
- return err;
+ goto out_unlock;
if (!res->netnsok && !net_eq(genl_info_net(info), &init_net)) {
/* family doesn't exist here */
- return -ENOENT;
+ err = -ENOENT;
+ goto out_unlock;
}
msg = ctrl_build_family_msg(res, info->snd_portid, info->snd_seq,
CTRL_CMD_NEWFAMILY);
- if (IS_ERR(msg))
- return PTR_ERR(msg);
+ if (IS_ERR(msg)) {
+ err = PTR_ERR(msg);
+ goto out_unlock;
+ }
- return genlmsg_reply(msg, info);
+ err = genlmsg_reply(msg, info);
+out_unlock:
+ genl_unlock();
+ return err;
}
static int genl_ctrl_event(int event, void *data)
^ permalink raw reply related
* Re: [PATCH v5] net/phy: micrel: Add OF configuration support for ksz9021
From: Sean Cross @ 2013-08-20 8:34 UTC (permalink / raw)
To: Sascha Hauer
Cc: Duan Fugang-B38611, netdev@vger.kernel.org,
devicetree@vger.kernel.org, David Miller,
stephen@networkplumber.org, Steven Rostedt
In-Reply-To: <544FF35DE7D643DEB9E792FE766A6B69@kosagi.com>
On Monday, August 5, 2013 at 4:12 PM, Sean Cross wrote:
>
> On Monday, August 5, 2013 at 3:58 PM, Sascha Hauer wrote:
>
> > On Mon, Aug 05, 2013 at 07:04:08AM +0000, Sean Cross wrote:
> > > Some boards require custom PHY configuration, for example due to trace
> > > length differences. Add the ability to configure these registers in
> > > order to get the PHY to function on boards that need it.
> > >
> > > Because PHYs are auto-detected based on MDIO device IDs, allow PHY
> > > configuration to be specified in the parent Ethernet device node if no
> > > PHY device node is present.
> > >
> > > Signed-off-by: Sean Cross <xobs@kosagi.com (mailto:xobs@kosagi.com)>
> > > ---
> > > .../devicetree/bindings/net/micrel-ksz9021.txt | 49 ++++++++++
> > > drivers/net/phy/micrel.c | 101 +++++++++++++++++++-
> > > 2 files changed, 149 insertions(+), 1 deletion(-)
> > > create mode 100644 Documentation/devicetree/bindings/net/micrel-ksz9021.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/net/micrel-ksz9021.txt b/Documentation/devicetree/bindings/net/micrel-ksz9021.txt
> > > new file mode 100644
> > > index 0000000..338a7e2
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/net/micrel-ksz9021.txt
> > > @@ -0,0 +1,49 @@
> > > +Micrel KSZ9021 Gigabit Ethernet PHY
> > > +
> > > +Some boards require special tuning values, particularly when it comes to
> > > +clock delays. You can specify clock delay values by adding
> > > +micrel-specific properties to an Ethernet OF device node.
> > > +
> > > +All skew control options are specified in picoseconds. The minimum
> > > +value is 0, and the maximum value is 3000.
> > > +
> > > +Optional properties:
> > > + - rxc-skew : Skew control of RXC pad
> > > + - rxdv-skew : Skew control of RX CTL pad
> > > + - txc-skew : Skew control of TXC pad
> > > + - txen-skew : Skew control of TX_CTL pad
> > > + - rxd0-skew : Skew control of RX data 0 pad
> > > + - rxd1-skew : Skew control of RX data 1 pad
> > > + - rxd2-skew : Skew control of RX data 2 pad
> > > + - rxd3-skew : Skew control of RX data 3 pad
> > > + - txd0-skew : Skew control of TX data 0 pad
> > > + - txd1-skew : Skew control of TX data 1 pad
> > > + - txd2-skew : Skew control of TX data 2 pad
> > > + - txd3-skew : Skew control of TX data 3 pad
> > > +
> > > +Examples:
> > > +
> > > + /* Attach to an Ethernet device with autodetected PHY */
> > > + &enet {
> > > + rxc-skew = <3000>; // picoseconds
> > > + rxdv-skew = <0>; // picoseconds
> > > + txc-skew = <3000>; // picoseconds
> > > + txen-skew = <0>; // picoseconds
> > > + status = "okay";
> > > + };
> > > +
> > > + /* Attach to an explicitly-specified PHY */
> > > + mdio {
> > > + phy0: ethernet-phy@0 {
> > > + rxc-skew = <3000>; // picoseconds
> > > + rxdv-skew = <0>; // picoseconds
> > > + txc-skew = <3000>; // picoseconds
> > > + txen-skew = <0>; // picoseconds
> > > + reg = <0>;
> > > + };
> > > + };
> > > + ethernet@70000 {
> > > + status = "okay";
> > > + phy = <&phy0>;
> > > + phy-mode = "rgmii-id";
> > > + };
> > > diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
> > > index 2510435..3e60ed0 100644
> > > --- a/drivers/net/phy/micrel.c
> > > +++ b/drivers/net/phy/micrel.c
> > > @@ -25,6 +25,7 @@
> > > #include <linux/module.h>
> > > #include <linux/phy.h>
> > > #include <linux/micrel_phy.h>
> > > +#include <linux/of.h>
> > >
> > > /* Operation Mode Strap Override */
> > > #define MII_KSZPHY_OMSO 0x16
> > > @@ -53,6 +54,18 @@
> > > #define KS8737_CTRL_INT_ACTIVE_HIGH (1 << 14)
> > > #define KSZ8051_RMII_50MHZ_CLK (1 << 7)
> > >
> > > +/* Write/read to/from extended registers */
> > > +#define MII_KSZPHY_EXTREG 0x0b
> > > +#define KSZPHY_EXTREG_WRITE 0x8000
> > > +
> > > +#define MII_KSZPHY_EXTREG_WRITE 0x0c
> > > +#define MII_KSZPHY_EXTREG_READ 0x0d
> > > +
> > > +/* Extended registers */
> > > +#define MII_KSZPHY_CLK_CONTROL_PAD_SKEW 0x104
> > > +#define MII_KSZPHY_RX_DATA_PAD_SKEW 0x105
> > > +#define MII_KSZPHY_TX_DATA_PAD_SKEW 0x106
> > > +
> > > static int ksz_config_flags(struct phy_device *phydev)
> > > {
> > > int regval;
> > > @@ -65,6 +78,20 @@ static int ksz_config_flags(struct phy_device *phydev)
> > > return 0;
> > > }
> > >
> > > +static int kszphy_extended_write(struct phy_device *phydev,
> > > + u32 regnum, u16 val)
> > > +{
> > > + phy_write(phydev, MII_KSZPHY_EXTREG, KSZPHY_EXTREG_WRITE | regnum);
> > > + return phy_write(phydev, MII_KSZPHY_EXTREG_WRITE, val);
> > > +}
> > > +
> > > +static int kszphy_extended_read(struct phy_device *phydev,
> > > + u32 regnum)
> > > +{
> > > + phy_write(phydev, MII_KSZPHY_EXTREG, regnum);
> > > + return phy_read(phydev, MII_KSZPHY_EXTREG_READ);
> > > +}
> > > +
> > > static int kszphy_ack_interrupt(struct phy_device *phydev)
> > > {
> > > /* bit[7..0] int status, which is a read and clear register. */
> > > @@ -141,6 +168,78 @@ static int ks8051_config_init(struct phy_device *phydev)
> > > return rc < 0 ? rc : 0;
> > > }
> > >
> > > +static int ksz9021_load_values_from_of(struct phy_device *phydev,
> > > + struct device_node *of_node, u16 reg,
> > > + char *field1, char *field2,
> > > + char *field3, char *field4)
> > > +{
> > > + int val1 = -1;
> > > + int val2 = -2;
> > > + int val3 = -3;
> > > + int val4 = -4;
> > > + int newval;
> > > + int matches = 0;
> > > +
> > > + if (!of_property_read_u32(of_node, field1, &val1))
> > > + matches++;
> > > +
> > > + if (!of_property_read_u32(of_node, field2, &val2))
> > > + matches++;
> > > +
> > > + if (!of_property_read_u32(of_node, field3, &val3))
> > > + matches++;
> > > +
> > > + if (!of_property_read_u32(of_node, field4, &val4))
> > > + matches++;
> > > +
> > > + if (!matches)
> > > + return 0;
> > > +
> > > + if (matches < 4)
> > > + newval = kszphy_extended_read(phydev, reg);
> > > + else
> > > + newval = 0;
> >
> >
> >
> >
> >
> > Just initialize newval with the reset default of this register. It will
> > make this function easier. Also this two step read from dt and evaluate
> > afterwards seems unnecessary.
>
>
>
> The documentation seems inaccurate here. My datasheet says it defaults to 0x0111, but when I check it for myself it comes out 0x7777. Which value do you think I should take?
> > > +
> > > + if (val1 != -1)
> > > + newval = ((newval & 0xfff0) | ((val1/200)&0xf) << 0);
> > > +
> > > + if (val2 != -1)
> > > + newval = ((newval & 0xff0f) | ((val2/200)&0xf) << 4);
> > > +
> > > + if (val3 != -1)
> > > + newval = ((newval & 0xf0ff) | ((val3/200)&0xf) << 8);
> > > +
> > > + if (val4 != -1)
> > > + newval = ((newval & 0x0fff) | ((val4/200)&0xf) << 12);
> > > +
> > > + return kszphy_extended_write(phydev, reg, newval);
> > > +}
> > > +
> > > +static int ksz9021_config_init(struct phy_device *phydev)
> > > +{
> > > + struct device *dev = &phydev->dev;
> > > + struct device_node *of_node = dev->of_node;
> > > +
> > > + if (!of_node && dev->parent->of_node)
> > > + of_node = dev->parent->of_node;
> > > +
> > > + if (of_node) {
> > > + ksz9021_load_values_from_of(phydev, of_node,
> > > + MII_KSZPHY_CLK_CONTROL_PAD_SKEW,
> > > + "txen-skew", "txc-skew",
> > > + "rxdv-skew", "rxc-skew");
> > > + ksz9021_load_values_from_of(phydev, of_node,
> > > + MII_KSZPHY_RX_DATA_PAD_SKEW,
> > > + "rxd0-skew", "rxd1-skew",
> > > + "rxd2-skew", "rxd3-skew");
> > > + ksz9021_load_values_from_of(phydev, of_node,
> > > + MII_KSZPHY_TX_DATA_PAD_SKEW,
> > > + "txd0-skew", "txd1-skew",
> > > + "txd2-skew", "txd3-skew");
> >
> >
> >
> >
> >
> > Are you sure this register exists? It's not mentioned in my datasheet,
> > only the first two are.
>
>
>
> I'm very sure the register exists. There's a hole in the documentation where the TX control register should exist. Furthermore, we measured that changing values in this register adjusted the TX skew on the RG-MII wires, and on our board at least, adjusting these values yields increased performance.
There hasn't been any response to this patch in two weeks. Can someone please merge this patch or indicate what's wrong with it?
^ permalink raw reply
* Re: [PATCH RESEND] can: mcp251x: Replace power callbacks with regulator API
From: Marc Kleine-Budde @ 2013-08-20 8:46 UTC (permalink / raw)
To: Haojian Zhuang
Cc: Alexander Shiyan, Eric Miao, netdev, linux-can,
Wolfgang Grandegger, Russell King,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAN1soZz68ymkj4x5bWTP-6Qc7zVuVotLoT8nYLrdTd3DQHyFbQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1907 bytes --]
On 08/17/2013 06:37 AM, Haojian Zhuang wrote:
> On Sat, Aug 17, 2013 at 12:30 PM, Alexander Shiyan <shc_work@mail.ru> wrote:
>> On Sat, 17 Aug 2013 10:19:20 +0800
>> Haojian Zhuang <haojian.zhuang@gmail.com> wrote:
>>
>>> On 08/09/2013 03:37 PM, Marc Kleine-Budde wrote:
>>>> On 08/08/2013 02:00 PM, Alexander Shiyan wrote:
>>>>> Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
>>>>> ---
>>>>> arch/arm/mach-pxa/icontrol.c | 3 --
>>>>> arch/arm/mach-pxa/zeus.c | 46 ++++++++++----------
>>>>
>>>> What's pxa's status of DT conversion? Do you (still) accept patches to
>>>> board files?
>>>>
>>>> Marc
>>>>
>>>
>>> Since DT conversion isn't finished, I still accept the board files.
>>> But this patch should be split into two parts. One is for pxa, and the
>>> other one is for net.
>>
>> Patch cannot be splitted because this can create hole which break git-bisect.
>>
>> In any case, I want to create a v2 with a more detailed description, and I
>> have a supplementary question for the CAN subsystem maintainers.
>> "Transciever power" is not used by any of the boards, can we remove it
>> completely? This will greatly simplify driver.
>> Thanks.
>>
>> --
>> Alexander Shiyan <shc_work@mail.ru>
>
> If you want to make the patch go through pxa tree, you need to get the Ack
> from CAN maintainer.
The current series consists of 3 patches, only the first one touches
"arch/arm/mach-pxa", so I'd like the patches to go via linux-can. Can I
have your Acked-by for the first patch "[PATCH v2 1/3] can: mcp251x:
Replace power callbacks with regulator AP"
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* RE: [PATCH v5] net/phy: micrel: Add OF configuration support for ksz9021
From: Duan Fugang-B38611 @ 2013-08-20 8:50 UTC (permalink / raw)
To: Sean Cross, Sascha Hauer
Cc: netdev@vger.kernel.org, devicetree@vger.kernel.org, David Miller,
stephen@networkplumber.org, Steven Rostedt
In-Reply-To: <70ADD478D3594155ABF740001DBCB674@kosagi.com>
From: Sean Cross [mailto:xobs@kosagi.com]
Data: Tuesday, August 20, 2013 4:35 PM
> To: Sascha Hauer
> Cc: Duan Fugang-B38611; netdev@vger.kernel.org; devicetree@vger.kernel.org;
> David Miller; stephen@networkplumber.org; Steven Rostedt
> Subject: Re: [PATCH v5] net/phy: micrel: Add OF configuration support for
> ksz9021
>
>
>
>
> On Monday, August 5, 2013 at 4:12 PM, Sean Cross wrote:
>
> >
> > On Monday, August 5, 2013 at 3:58 PM, Sascha Hauer wrote:
> >
> > > On Mon, Aug 05, 2013 at 07:04:08AM +0000, Sean Cross wrote:
> > > > Some boards require custom PHY configuration, for example due to
> > > > trace length differences. Add the ability to configure these
> > > > registers in order to get the PHY to function on boards that need it.
> > > >
> > > > Because PHYs are auto-detected based on MDIO device IDs, allow PHY
> > > > configuration to be specified in the parent Ethernet device node
> > > > if no PHY device node is present.
> > > >
> > > > Signed-off-by: Sean Cross <xobs@kosagi.com
> > > > (mailto:xobs@kosagi.com)
Reviewed-by: Fugang Duan <B38611@freescale.com>
Do somebody have other suggestion for the patch ?
> > > > ---
> > > > .../devicetree/bindings/net/micrel-ksz9021.txt | 49 ++++++++++
> > > > drivers/net/phy/micrel.c | 101 +++++++++++++++++++-
> > > > 2 files changed, 149 insertions(+), 1 deletion(-) create mode
> > > > 100644 Documentation/devicetree/bindings/net/micrel-ksz9021.txt
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/net/micrel-ksz9021.txt
> > > > b/Documentation/devicetree/bindings/net/micrel-ksz9021.txt
> > > > new file mode 100644
> > > > index 0000000..338a7e2
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/net/micrel-ksz9021.txt
> > > > @@ -0,0 +1,49 @@
> > > > +Micrel KSZ9021 Gigabit Ethernet PHY
> > > > +
> > > > +Some boards require special tuning values, particularly when it
> > > > +comes to clock delays. You can specify clock delay values by
> > > > +adding micrel-specific properties to an Ethernet OF device node.
> > > > +
> > > > +All skew control options are specified in picoseconds. The
> > > > +minimum value is 0, and the maximum value is 3000.
> > > > +
> > > > +Optional properties:
> > > > + - rxc-skew : Skew control of RXC pad
> > > > + - rxdv-skew : Skew control of RX CTL pad
> > > > + - txc-skew : Skew control of TXC pad
> > > > + - txen-skew : Skew control of TX_CTL pad
> > > > + - rxd0-skew : Skew control of RX data 0 pad
> > > > + - rxd1-skew : Skew control of RX data 1 pad
> > > > + - rxd2-skew : Skew control of RX data 2 pad
> > > > + - rxd3-skew : Skew control of RX data 3 pad
> > > > + - txd0-skew : Skew control of TX data 0 pad
> > > > + - txd1-skew : Skew control of TX data 1 pad
> > > > + - txd2-skew : Skew control of TX data 2 pad
> > > > + - txd3-skew : Skew control of TX data 3 pad
> > > > +
> > > > +Examples:
> > > > +
> > > > + /* Attach to an Ethernet device with autodetected PHY */ &enet {
> > > > + rxc-skew = <3000>; // picoseconds rxdv-skew = <0>; //
> > > > + picoseconds txc-skew = <3000>; // picoseconds txen-skew = <0>;
> > > > + // picoseconds status = "okay"; };
> > > > +
> > > > + /* Attach to an explicitly-specified PHY */ mdio {
> > > > + phy0: ethernet-phy@0 {
> > > > + rxc-skew = <3000>; // picoseconds rxdv-skew = <0>; //
> > > > + picoseconds txc-skew = <3000>; // picoseconds txen-skew = <0>;
> > > > + // picoseconds reg = <0>; }; };
> > > > + ethernet@70000 {
> > > > + status = "okay";
> > > > + phy = <&phy0>;
> > > > + phy-mode = "rgmii-id";
> > > > + };
> > > > diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
> > > > index 2510435..3e60ed0 100644
> > > > --- a/drivers/net/phy/micrel.c
> > > > +++ b/drivers/net/phy/micrel.c
> > > > @@ -25,6 +25,7 @@
> > > > #include <linux/module.h>
> > > > #include <linux/phy.h>
> > > > #include <linux/micrel_phy.h>
> > > > +#include <linux/of.h>
> > > >
> > > > /* Operation Mode Strap Override */ #define MII_KSZPHY_OMSO 0x16
> > > > @@ -53,6 +54,18 @@ #define KS8737_CTRL_INT_ACTIVE_HIGH (1 << 14)
> > > > #define KSZ8051_RMII_50MHZ_CLK (1 << 7)
> > > >
> > > > +/* Write/read to/from extended registers */ #define
> > > > +MII_KSZPHY_EXTREG 0x0b #define KSZPHY_EXTREG_WRITE 0x8000
> > > > +
> > > > +#define MII_KSZPHY_EXTREG_WRITE 0x0c #define
> > > > +MII_KSZPHY_EXTREG_READ 0x0d
> > > > +
> > > > +/* Extended registers */
> > > > +#define MII_KSZPHY_CLK_CONTROL_PAD_SKEW 0x104 #define
> > > > +MII_KSZPHY_RX_DATA_PAD_SKEW 0x105 #define
> > > > +MII_KSZPHY_TX_DATA_PAD_SKEW 0x106
> > > > +
> > > > static int ksz_config_flags(struct phy_device *phydev) { int
> > > > regval; @@ -65,6 +78,20 @@ static int ksz_config_flags(struct
> > > > phy_device *phydev) return 0; }
> > > >
> > > > +static int kszphy_extended_write(struct phy_device *phydev,
> > > > + u32 regnum, u16 val)
> > > > +{
> > > > + phy_write(phydev, MII_KSZPHY_EXTREG, KSZPHY_EXTREG_WRITE |
> > > > +regnum); return phy_write(phydev, MII_KSZPHY_EXTREG_WRITE, val);
> > > > +}
> > > > +
> > > > +static int kszphy_extended_read(struct phy_device *phydev,
> > > > + u32 regnum)
> > > > +{
> > > > + phy_write(phydev, MII_KSZPHY_EXTREG, regnum); return
> > > > +phy_read(phydev, MII_KSZPHY_EXTREG_READ); }
> > > > +
> > > > static int kszphy_ack_interrupt(struct phy_device *phydev) {
> > > > /* bit[7..0] int status, which is a read and clear register. */ @@
> > > > -141,6 +168,78 @@ static int ks8051_config_init(struct phy_device
> > > > *phydev) return rc < 0 ? rc : 0; }
> > > >
> > > > +static int ksz9021_load_values_from_of(struct phy_device *phydev,
> > > > +struct device_node *of_node, u16 reg, char *field1, char
> > > > +*field2, char *field3, char *field4) { int val1 = -1; int val2
> > > > += -2; int val3 = -3; int val4 = -4; int newval; int matches =
> > > > +0;
> > > > +
> > > > + if (!of_property_read_u32(of_node, field1, &val1))
> > > > + matches++;
> > > > +
> > > > + if (!of_property_read_u32(of_node, field2, &val2))
> > > > + matches++;
> > > > +
> > > > + if (!of_property_read_u32(of_node, field3, &val3))
> > > > + matches++;
> > > > +
> > > > + if (!of_property_read_u32(of_node, field4, &val4))
> > > > + matches++;
> > > > +
> > > > + if (!matches)
> > > > + return 0;
> > > > +
> > > > + if (matches < 4)
> > > > + newval = kszphy_extended_read(phydev, reg); else newval = 0;
> > >
> > >
> > >
> > >
> > >
> > > Just initialize newval with the reset default of this register. It
> > > will make this function easier. Also this two step read from dt and
> > > evaluate afterwards seems unnecessary.
> >
> >
> >
> > The documentation seems inaccurate here. My datasheet says it defaults
> to 0x0111, but when I check it for myself it comes out 0x7777. Which value
> do you think I should take?
> > > > +
> > > > + if (val1 != -1)
> > > > + newval = ((newval & 0xfff0) | ((val1/200)&0xf) << 0);
> > > > +
> > > > + if (val2 != -1)
> > > > + newval = ((newval & 0xff0f) | ((val2/200)&0xf) << 4);
> > > > +
> > > > + if (val3 != -1)
> > > > + newval = ((newval & 0xf0ff) | ((val3/200)&0xf) << 8);
> > > > +
> > > > + if (val4 != -1)
> > > > + newval = ((newval & 0x0fff) | ((val4/200)&0xf) << 12);
> > > > +
> > > > + return kszphy_extended_write(phydev, reg, newval); }
> > > > +
> > > > +static int ksz9021_config_init(struct phy_device *phydev) {
> > > > +struct device *dev = &phydev->dev; struct device_node *of_node =
> > > > +dev->of_node;
> > > > +
> > > > + if (!of_node && dev->parent->of_node) of_node =
> > > > + dev->parent->of_node;
> > > > +
> > > > + if (of_node) {
> > > > + ksz9021_load_values_from_of(phydev, of_node,
> > > > + MII_KSZPHY_CLK_CONTROL_PAD_SKEW, "txen-skew", "txc-skew",
> > > > + "rxdv-skew", "rxc-skew"); ksz9021_load_values_from_of(phydev,
> > > > + of_node, MII_KSZPHY_RX_DATA_PAD_SKEW, "rxd0-skew", "rxd1-skew",
> > > > + "rxd2-skew", "rxd3-skew"); ksz9021_load_values_from_of(phydev,
> > > > + of_node, MII_KSZPHY_TX_DATA_PAD_SKEW, "txd0-skew", "txd1-skew",
> > > > + "txd2-skew", "txd3-skew");
> > >
> > >
> > >
> > >
> > >
> > > Are you sure this register exists? It's not mentioned in my
> > > datasheet, only the first two are.
> >
> >
> >
> > I'm very sure the register exists. There's a hole in the documentation
> where the TX control register should exist. Furthermore, we measured that
> changing values in this register adjusted the TX skew on the RG-MII wires,
> and on our board at least, adjusting these values yields increased
> performance.
> There hasn't been any response to this patch in two weeks. Can someone
> please merge this patch or indicate what's wrong with it?
>
^ permalink raw reply
* Re: 3.11-rc6 genetlink locking fix offends lockdep
From: Borislav Petkov @ 2013-08-20 9:04 UTC (permalink / raw)
To: Johannes Berg
Cc: Hugh Dickins, Ding Tianhong, Linus Torvalds, Greg KH,
David S. Miller, Otcheretianski, Andrei,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
stable@vger.kernel.org, Pravin B Shelar, Thomas Graf
In-Reply-To: <1376987338.13829.7.camel@jlt4.sipsolutions.net>
On Tue, Aug 20, 2013 at 10:28:58AM +0200, Johannes Berg wrote:
> Something like the patch below, perhaps? Completely untested so far.
Yeah, this one seems to fix it here (I was seeing the same lockdep splat
as Hugh).
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply
* [net PATCH] bridge: Use the correct bit length for bitmap functions in the VLAN code
From: Toshiaki Makita @ 2013-08-20 8:10 UTC (permalink / raw)
To: David S. Miller, Vlad Yasevich, netdev; +Cc: Toshiaki Makita
In-Reply-To: <1376986060.5740.7.camel@ubuntu-vm-makita>
The VLAN code needs to know the length of the per-port VLAN bitmap to
perform its most basic operations (retrieving VLAN informations, removing
VLANs, forwarding database manipulation, etc). Unfortunately, in the
current implementation we are using a macro that indicates the bitmap
size in longs in places where the size in bits is expected, which in
some cases can cause what appear to be random failures.
Use the correct macro.
Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
---
net/bridge/br_fdb.c | 10 +++++-----
net/bridge/br_netlink.c | 4 ++--
net/bridge/br_vlan.c | 4 ++--
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index 60aca91..ffd5874 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -161,7 +161,7 @@ void br_fdb_change_mac_address(struct net_bridge *br, const u8 *newaddr)
if (!pv)
return;
- for_each_set_bit_from(vid, pv->vlan_bitmap, BR_VLAN_BITMAP_LEN) {
+ for_each_set_bit_from(vid, pv->vlan_bitmap, VLAN_N_VID) {
f = __br_fdb_get(br, br->dev->dev_addr, vid);
if (f && f->is_local && !f->dst)
fdb_delete(br, f);
@@ -730,7 +730,7 @@ int br_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
/* VID was specified, so use it. */
err = __br_fdb_add(ndm, p, addr, nlh_flags, vid);
} else {
- if (!pv || bitmap_empty(pv->vlan_bitmap, BR_VLAN_BITMAP_LEN)) {
+ if (!pv || bitmap_empty(pv->vlan_bitmap, VLAN_N_VID)) {
err = __br_fdb_add(ndm, p, addr, nlh_flags, 0);
goto out;
}
@@ -739,7 +739,7 @@ int br_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
* specify a VLAN. To be nice, add/update entry for every
* vlan on this port.
*/
- for_each_set_bit(vid, pv->vlan_bitmap, BR_VLAN_BITMAP_LEN) {
+ for_each_set_bit(vid, pv->vlan_bitmap, VLAN_N_VID) {
err = __br_fdb_add(ndm, p, addr, nlh_flags, vid);
if (err)
goto out;
@@ -817,7 +817,7 @@ int br_fdb_delete(struct ndmsg *ndm, struct nlattr *tb[],
err = __br_fdb_delete(p, addr, vid);
} else {
- if (!pv || bitmap_empty(pv->vlan_bitmap, BR_VLAN_BITMAP_LEN)) {
+ if (!pv || bitmap_empty(pv->vlan_bitmap, VLAN_N_VID)) {
err = __br_fdb_delete(p, addr, 0);
goto out;
}
@@ -827,7 +827,7 @@ int br_fdb_delete(struct ndmsg *ndm, struct nlattr *tb[],
* vlan on this port.
*/
err = -ENOENT;
- for_each_set_bit(vid, pv->vlan_bitmap, BR_VLAN_BITMAP_LEN) {
+ for_each_set_bit(vid, pv->vlan_bitmap, VLAN_N_VID) {
err &= __br_fdb_delete(p, addr, vid);
}
}
diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
index 1fc30ab..b9259ef 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -132,7 +132,7 @@ static int br_fill_ifinfo(struct sk_buff *skb,
else
pv = br_get_vlan_info(br);
- if (!pv || bitmap_empty(pv->vlan_bitmap, BR_VLAN_BITMAP_LEN))
+ if (!pv || bitmap_empty(pv->vlan_bitmap, VLAN_N_VID))
goto done;
af = nla_nest_start(skb, IFLA_AF_SPEC);
@@ -140,7 +140,7 @@ static int br_fill_ifinfo(struct sk_buff *skb,
goto nla_put_failure;
pvid = br_get_pvid(pv);
- for_each_set_bit(vid, pv->vlan_bitmap, BR_VLAN_BITMAP_LEN) {
+ for_each_set_bit(vid, pv->vlan_bitmap, VLAN_N_VID) {
vinfo.vid = vid;
vinfo.flags = 0;
if (vid == pvid)
diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
index bd58b45..9a9ffe7 100644
--- a/net/bridge/br_vlan.c
+++ b/net/bridge/br_vlan.c
@@ -108,7 +108,7 @@ static int __vlan_del(struct net_port_vlans *v, u16 vid)
clear_bit(vid, v->vlan_bitmap);
v->num_vlans--;
- if (bitmap_empty(v->vlan_bitmap, BR_VLAN_BITMAP_LEN)) {
+ if (bitmap_empty(v->vlan_bitmap, VLAN_N_VID)) {
if (v->port_idx)
rcu_assign_pointer(v->parent.port->vlan_info, NULL);
else
@@ -122,7 +122,7 @@ static void __vlan_flush(struct net_port_vlans *v)
{
smp_wmb();
v->pvid = 0;
- bitmap_zero(v->vlan_bitmap, BR_VLAN_BITMAP_LEN);
+ bitmap_zero(v->vlan_bitmap, VLAN_N_VID);
if (v->port_idx)
rcu_assign_pointer(v->parent.port->vlan_info, NULL);
else
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH v5] net/phy: micrel: Add OF configuration support for ksz9021
From: Sascha Hauer @ 2013-08-20 9:17 UTC (permalink / raw)
To: Sean Cross
Cc: Duan Fugang-B38611, netdev@vger.kernel.org,
devicetree@vger.kernel.org, David Miller,
stephen@networkplumber.org, Steven Rostedt
In-Reply-To: <1375686248-17995-2-git-send-email-xobs@kosagi.com>
On Mon, Aug 05, 2013 at 07:04:08AM +0000, Sean Cross wrote:
> Some boards require custom PHY configuration, for example due to trace
> length differences. Add the ability to configure these registers in
> order to get the PHY to function on boards that need it.
>
> Because PHYs are auto-detected based on MDIO device IDs, allow PHY
> configuration to be specified in the parent Ethernet device node if no
> PHY device node is present.
>
> Signed-off-by: Sean Cross <xobs@kosagi.com>
> ---
> .../devicetree/bindings/net/micrel-ksz9021.txt | 49 ++++++++++
> drivers/net/phy/micrel.c | 101 +++++++++++++++++++-
> 2 files changed, 149 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/net/micrel-ksz9021.txt
>
> diff --git a/Documentation/devicetree/bindings/net/micrel-ksz9021.txt b/Documentation/devicetree/bindings/net/micrel-ksz9021.txt
> new file mode 100644
> index 0000000..338a7e2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/micrel-ksz9021.txt
> @@ -0,0 +1,49 @@
> +Micrel KSZ9021 Gigabit Ethernet PHY
> +
> +Some boards require special tuning values, particularly when it comes to
> +clock delays. You can specify clock delay values by adding
> +micrel-specific properties to an Ethernet OF device node.
> +
> +All skew control options are specified in picoseconds. The minimum
> +value is 0, and the maximum value is 3000.
> +
> +Optional properties:
> + - rxc-skew : Skew control of RXC pad
> + - rxdv-skew : Skew control of RX CTL pad
> + - txc-skew : Skew control of TXC pad
> + - txen-skew : Skew control of TX_CTL pad
> + - rxd0-skew : Skew control of RX data 0 pad
> + - rxd1-skew : Skew control of RX data 1 pad
> + - rxd2-skew : Skew control of RX data 2 pad
> + - rxd3-skew : Skew control of RX data 3 pad
> + - txd0-skew : Skew control of TX data 0 pad
> + - txd1-skew : Skew control of TX data 1 pad
> + - txd2-skew : Skew control of TX data 2 pad
> + - txd3-skew : Skew control of TX data 3 pad
> +
> +Examples:
> +
> + /* Attach to an Ethernet device with autodetected PHY */
> + &enet {
> + rxc-skew = <3000>; // picoseconds
> + rxdv-skew = <0>; // picoseconds
> + txc-skew = <3000>; // picoseconds
> + txen-skew = <0>; // picoseconds
I prefer to add a -ps suffix to the property names. This makes the
comments unnecessary and provides the unit information automatically
where it is needed.
> + if (val1 != -1)
> + newval = ((newval & 0xfff0) | ((val1/200)&0xf) << 0);
Please add whitespaces at both sides os operators as required in
Documentation/CodingStyle.
Otherwise:
Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [Patch net-next] openvswitch: check CONFIG_OPENVSWITCH_GRE in makefile
From: Cong Wang @ 2013-08-20 9:20 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Jesse Gross, Pravin B Shelar, Cong Wang
From: Cong Wang <amwang@redhat.com>
Cc: Jesse Gross <jesse@nicira.com>
Cc: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: Cong Wang <amwang@redhat.com>
---
diff --git a/net/openvswitch/Makefile b/net/openvswitch/Makefile
index 82e4ee5..4de6dcc 100644
--- a/net/openvswitch/Makefile
+++ b/net/openvswitch/Makefile
@@ -10,10 +10,12 @@ openvswitch-y := \
dp_notify.o \
flow.o \
vport.o \
- vport-gre.o \
vport-internal_dev.o \
vport-netdev.o
ifneq ($(CONFIG_OPENVSWITCH_VXLAN),)
openvswitch-y += vport-vxlan.o
endif
+ifneq ($(CONFIG_OPENVSWITCH_GRE),)
+openvswitch-y += vport-gre.o
+endif
diff --git a/net/openvswitch/vport-gre.c b/net/openvswitch/vport-gre.c
index 493e977..21d5073 100644
--- a/net/openvswitch/vport-gre.c
+++ b/net/openvswitch/vport-gre.c
@@ -16,7 +16,6 @@
* 02110-1301, USA
*/
-#ifdef CONFIG_OPENVSWITCH_GRE
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/if.h>
@@ -271,5 +270,3 @@ const struct vport_ops ovs_gre_vport_ops = {
.get_name = gre_get_name,
.send = gre_tnl_send,
};
-
-#endif /* OPENVSWITCH_GRE */
^ permalink raw reply related
* [RFC PATCH] bridge: inherit slave devices needed_headroom
From: Florian Fainelli @ 2013-08-20 9:21 UTC (permalink / raw)
To: netdev; +Cc: stephen, eric.dumazet, vyasevic, davem, Florian Fainelli
Some slave devices may have set a dev->needed_headroom value which is
different than the default one, most likely in order to prepend a
hardware descriptor in front of the Ethernet frame to send. Whenever a
new slave is added to a bridge, ensure that we update the
needed_headroom value accordingly to account for the slave
needed_headroom value.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
net/bridge/br_if.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index aa6c9a8..c41d5fb 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c
@@ -383,6 +383,9 @@ int br_add_if(struct net_bridge *br, struct net_device *dev)
netdev_update_features(br->dev);
+ if (br->dev->needed_headroom < dev->needed_headroom)
+ br->dev->needed_headroom = dev->needed_headroom;
+
spin_lock_bh(&br->lock);
changed_addr = br_stp_recalculate_bridge_id(br);
--
1.8.1.2
^ permalink raw reply related
* Re:
From: EMIRATES AIRLINE @ 2013-08-20 9:21 UTC (permalink / raw)
To: info
Update On Last Notification?
^ permalink raw reply
* Re: changing dev->needed_headroom/needed_tailroom?
From: Florian Fainelli @ 2013-08-20 10:00 UTC (permalink / raw)
To: Johannes Berg
Cc: Eric Dumazet, Ben Hutchings, netdev,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1375711240.8120.11.camel-8Nb76shvtaUJvtFkdXX2HixXY32XiHfO@public.gmane.org>
2013/8/5 Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>:
> On Fri, 2013-08-02 at 06:11 -0700, Eric Dumazet wrote:
>> On Fri, 2013-08-02 at 10:55 +0200, Ben Hutchings wrote:
>>
>> > I don't think this is safe when the interface is running (even if
>> > carrier is off). Some functions may read dev->needed_headroom twice and
>> > rely on getting the same value each time.
>>
>> It should be no problem. Remaining unsafe places should be fixed.
>
> Most interesting would be stack devs, which I hadn't even considered. In
> any case, since I can't completely _rely_ on it, it's an optimisation,
> the only bugs would be around the double-access and then running
> over/under the SKB or so?
As far as I could test this with an Ethernet driver which adjusted its
needed_headroom by 64 bytes whenever some hardware feature was
enabled/disabled, this expectedly broke bridge and vlans at least.
Bridge code does not use the slave ports needed_headroom values, and
VLAN devices get the parent device needed_headroom only when creating
the vlan device. The good thing is since the needed_headroom space you
need is most likely fixed for a given configuration type, you should
see a pretty "stable" corruption of your SKB head.
>
>> We already had this discussion in the past, and some patches were
>> issued. Check commit ae641949df01b85117845bec45328eab6d6fada1
>> ("net: Remove all uses of LL_ALLOCATED_SPACE")
>
> That would have addressed some of that, I guess.
>
>
> I'm asking because some of the crypto stuff we do has fairly large
> head/tailroom requirements and it seems I may need to add more. But if
> you don't have crypto, it would be much smaller, so I figured we could
> switch it.
We could probably do it via a pair of new NETDEV_* notify event to
signal new needed_headroom/tailroom values to stacked devices. Would
that be acceptable?
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: bonding + arp monitoring fails if interface is a vlan
From: Nikolay Aleksandrov @ 2013-08-20 10:11 UTC (permalink / raw)
To: Santiago Garcia Mantinan; +Cc: netdev
In-Reply-To: <CAJk_L2Ep-HoROtyThk26t8x3HQFy9+5-7k-e4G15Nm_F0KxV-A@mail.gmail.com>
On 08/20/2013 10:05 AM, Santiago Garcia Mantinan wrote:
> Hi!
>
> Sorry it took me so long to reply back. I've been doing more tests on
> xor mode and I see that arp monitoring is not working at all. I
> haven't found any doc that says which modes should be compatible with
> arp monitoring, maybe xor mode shouldn't be used at all.
>
> My last setup is a Linux with a couple of vlans both interfaces
> (eth2.1001 and eth2.1002) with IP 192.168.1.1 (no bonding at all) and
> another Linux machine with a 3.11-rc3 with Nicolay's arp fix for
> bonding and a bond configured like this:
>
> iface bond0 inet static
> address 192.168.1.2
> netmask 255.255.255.0
> bond-slaves eth0.1001 eth0.1002 eth1.1001 eth1.1002
> bond-mode balance-xor
> bond-arp_validate 0
> bond-arp_interval 2000
> bond-arp_ip_target 192.168.1.1
>
> A silly switch connects the couple of ethernets of the machine with
> the bond to the interface of the not bonded machine.
>
> What I saw was that the bonded machine didn't detect the ifconfig down
> of the interfaces of the not bonded machine at all. That drove me to
> the hypothesis that the bonded machine was considering its own traffic
> (there was no traffic but the arp requests of the bonding) as
> indication that the link was ok.
>
> To test the hypothesis, when the not bonded machine (192.168.1.1)
> which is the target for arp requests was unplugged and the bonding was
> seeing all interfaces up (not detecting that the other machine was not
> responding) I unplugged one of the bonded interfaces and all 4 slaves
> went to down, then if I replugged it all 4 would go up.
>
> Maybe this is something to be expected due to arp monitoring not
> working with balance-xor, but I haven't found any doc saying this.
>
> If you need the debug info for this I can send it, but the events show
> nothing, as there are no event saying that link is lost or anything
> :-(
>
> Regards.
>
Hi,
This setup works for me, what might be wrong with your setup is that you connect
all 4 ports to a "dumb" switch, and you have the same vlans over the real
devices that are connected so they see each other's packets and the port's
last_rx gets updated so they stay up.
I tried your setup with a "smart" switch so the ports couldn't see each other
and only the one that saw 192.168.1.1 was up, and the moment 192.168.1.1 went
down - the port went down in the bonding.
Cheers,
Nik
^ permalink raw reply
* [PATCH net-next] ip6_tunnel: ensure to always have a link local address
From: Nicolas Dichtel @ 2013-08-20 10:16 UTC (permalink / raw)
To: netdev; +Cc: davem, yoshfuji, Nicolas Dichtel
When an Xin6 tunnel is set up, we check other netdevices to inherit the link-
local address. If none is available, the interface will not have any link-local
address. RFC4862 expects that each interface has a link local address.
Now than this kind of tunnels supports x-netns, it's easy to fall in this case
(by creating the tunnel in a netns where ethernet interfaces stand and then
moving it to a other netns where no ethernet interface is available).
RFC4291, Appendix A suggests two methods: the first is the one currently
implemented, the second is to generate a unique identifier, so that we can
always generate the link-local address. Let's use eth_random_addr() to generate
this interface indentifier.
I remove completly the previous method, hence for the whole life of the
interface, the link-local address remains the same (previously, it depends on
which ethernet interfaces were up when the tunnel interface was set up).
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
net/ipv6/addrconf.c | 56 +++++++++++++--------------------------------------
net/ipv6/ip6_tunnel.c | 4 ++++
2 files changed, 18 insertions(+), 42 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index ad12f7c43f25..5125436ca67e 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1814,6 +1814,16 @@ static int addrconf_ifid_gre(u8 *eui, struct net_device *dev)
return __ipv6_isatap_ifid(eui, *(__be32 *)dev->dev_addr);
}
+static int addrconf_ifid_ip6tnl(u8 *eui, struct net_device *dev)
+{
+ memcpy(eui, dev->perm_addr, 3);
+ memcpy(eui + 5, dev->perm_addr + 3, 3);
+ eui[3] = 0xFF;
+ eui[4] = 0xFE;
+ eui[0] ^= 2;
+ return 0;
+}
+
static int ipv6_generate_eui64(u8 *eui, struct net_device *dev)
{
switch (dev->type) {
@@ -1832,6 +1842,8 @@ static int ipv6_generate_eui64(u8 *eui, struct net_device *dev)
return addrconf_ifid_eui64(eui, dev);
case ARPHRD_IEEE1394:
return addrconf_ifid_ieee1394(eui, dev);
+ case ARPHRD_TUNNEL6:
+ return addrconf_ifid_ip6tnl(eui, dev);
}
return -1;
}
@@ -2709,7 +2721,8 @@ static void addrconf_dev_config(struct net_device *dev)
(dev->type != ARPHRD_ARCNET) &&
(dev->type != ARPHRD_INFINIBAND) &&
(dev->type != ARPHRD_IEEE802154) &&
- (dev->type != ARPHRD_IEEE1394)) {
+ (dev->type != ARPHRD_IEEE1394) &&
+ (dev->type != ARPHRD_TUNNEL6)) {
/* Alas, we support only Ethernet autoconfiguration. */
return;
}
@@ -2795,44 +2808,6 @@ ipv6_inherit_linklocal(struct inet6_dev *idev, struct net_device *link_dev)
return -1;
}
-static void ip6_tnl_add_linklocal(struct inet6_dev *idev)
-{
- struct net_device *link_dev;
- struct net *net = dev_net(idev->dev);
-
- /* first try to inherit the link-local address from the link device */
- if (idev->dev->iflink &&
- (link_dev = __dev_get_by_index(net, idev->dev->iflink))) {
- if (!ipv6_inherit_linklocal(idev, link_dev))
- return;
- }
- /* then try to inherit it from any device */
- for_each_netdev(net, link_dev) {
- if (!ipv6_inherit_linklocal(idev, link_dev))
- return;
- }
- pr_debug("init ip6-ip6: add_linklocal failed\n");
-}
-
-/*
- * Autoconfigure tunnel with a link-local address so routing protocols,
- * DHCPv6, MLD etc. can be run over the virtual link
- */
-
-static void addrconf_ip6_tnl_config(struct net_device *dev)
-{
- struct inet6_dev *idev;
-
- ASSERT_RTNL();
-
- idev = addrconf_add_dev(dev);
- if (IS_ERR(idev)) {
- pr_debug("init ip6-ip6: add_dev failed\n");
- return;
- }
- ip6_tnl_add_linklocal(idev);
-}
-
static int addrconf_notify(struct notifier_block *this, unsigned long event,
void *ptr)
{
@@ -2900,9 +2875,6 @@ static int addrconf_notify(struct notifier_block *this, unsigned long event,
addrconf_gre_config(dev);
break;
#endif
- case ARPHRD_TUNNEL6:
- addrconf_ip6_tnl_config(dev);
- break;
case ARPHRD_LOOPBACK:
init_loopback(dev);
break;
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index cc3bb201b8b0..d6e00a39274c 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -41,6 +41,7 @@
#include <linux/netfilter_ipv6.h>
#include <linux/slab.h>
#include <linux/hash.h>
+#include <linux/etherdevice.h>
#include <asm/uaccess.h>
#include <linux/atomic.h>
@@ -1471,6 +1472,9 @@ static void ip6_tnl_dev_setup(struct net_device *dev)
dev->flags |= IFF_NOARP;
dev->addr_len = sizeof(struct in6_addr);
dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
+ /* This perm addr will be used as interface identifier by IPv6 */
+ dev->addr_assign_type = NET_ADDR_RANDOM;
+ eth_random_addr(dev->perm_addr);
}
--
1.8.2.1
^ permalink raw reply related
* [PATCH net-next 0/3] Minor ipv6 mcast cleanups
From: Daniel Borkmann @ 2013-08-20 10:21 UTC (permalink / raw)
To: davem; +Cc: netdev, hannes
Daniel Borkmann (3):
net: ipv6: igmp6_event_query: use msecs_to_jiffies
net: ipv6: minor: *_start_timer: rather use unsigned long
net: ipv6: mcast: minor: use defines for rfc3810/8.1 lengths
net/ipv6/mcast.c | 30 ++++++++++++++++--------------
1 file changed, 16 insertions(+), 14 deletions(-)
--
1.7.11.7
^ permalink raw reply
* [PATCH net-next 1/3] net: ipv6: igmp6_event_query: use msecs_to_jiffies
From: Daniel Borkmann @ 2013-08-20 10:22 UTC (permalink / raw)
To: davem; +Cc: netdev, hannes
In-Reply-To: <1376994122-3022-1-git-send-email-dborkman@redhat.com>
Use proper API functions to calculate jiffies from milliseconds and
not the crude method of dividing HZ by a value. This ensures more
accurate values even in the case of strange HZ values. While at it,
also simplify code in the mlh2 case by using max().
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
---
net/ipv6/mcast.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index 6c76df9..57863e2 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -1150,9 +1150,7 @@ int igmp6_event_query(struct sk_buff *skb)
int switchback;
/* MLDv1 router present */
- /* Translate milliseconds to jiffies */
- max_delay = (ntohs(mld->mld_maxdelay)*HZ)/1000;
-
+ max_delay = msecs_to_jiffies(ntohs(mld->mld_maxdelay));
switchback = (idev->mc_qrv + 1) * max_delay;
idev->mc_v1_seen = jiffies + switchback;
@@ -1169,10 +1167,11 @@ int igmp6_event_query(struct sk_buff *skb)
return -EINVAL;
mlh2 = (struct mld2_query *)skb_transport_header(skb);
- max_delay = (MLDV2_MRC(ntohs(mlh2->mld2q_mrc))*HZ)/1000;
- if (!max_delay)
- max_delay = 1;
+
+ max_delay = max(msecs_to_jiffies(MLDV2_MRC(ntohs(mlh2->mld2q_mrc))), 1UL);
+
idev->mc_maxdelay = max_delay;
+
if (mlh2->mld2q_qrv)
idev->mc_qrv = mlh2->mld2q_qrv;
if (group_type == IPV6_ADDR_ANY) { /* general query */
--
1.7.11.7
^ permalink raw reply related
* [PATCH net-next 2/3] net: ipv6: minor: *_start_timer: rather use unsigned long
From: Daniel Borkmann @ 2013-08-20 10:22 UTC (permalink / raw)
To: davem; +Cc: netdev, hannes
In-Reply-To: <1376994122-3022-1-git-send-email-dborkman@redhat.com>
For the functions mld_gq_start_timer(), mld_ifc_start_timer(),
and mld_dad_start_timer(), rather use unsigned long than int
as we operate only on unsigned values anyway. This seems more
appropriate as there is no good reason to do type conversions
to int, that could lead to future errors.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
---
net/ipv6/mcast.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index 57863e2..33f98d9 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -996,24 +996,24 @@ bool ipv6_chk_mcast_addr(struct net_device *dev, const struct in6_addr *group,
static void mld_gq_start_timer(struct inet6_dev *idev)
{
- int tv = net_random() % idev->mc_maxdelay;
+ unsigned long tv = net_random() % idev->mc_maxdelay;
idev->mc_gq_running = 1;
if (!mod_timer(&idev->mc_gq_timer, jiffies+tv+2))
in6_dev_hold(idev);
}
-static void mld_ifc_start_timer(struct inet6_dev *idev, int delay)
+static void mld_ifc_start_timer(struct inet6_dev *idev, unsigned long delay)
{
- int tv = net_random() % delay;
+ unsigned long tv = net_random() % delay;
if (!mod_timer(&idev->mc_ifc_timer, jiffies+tv+2))
in6_dev_hold(idev);
}
-static void mld_dad_start_timer(struct inet6_dev *idev, int delay)
+static void mld_dad_start_timer(struct inet6_dev *idev, unsigned long delay)
{
- int tv = net_random() % delay;
+ unsigned long tv = net_random() % delay;
if (!mod_timer(&idev->mc_dad_timer, jiffies+tv+2))
in6_dev_hold(idev);
--
1.7.11.7
^ permalink raw reply related
* [PATCH net-next 3/3] net: ipv6: mcast: minor: use defines for rfc3810/8.1 lengths
From: Daniel Borkmann @ 2013-08-20 10:22 UTC (permalink / raw)
To: davem; +Cc: netdev, hannes
In-Reply-To: <1376994122-3022-1-git-send-email-dborkman@redhat.com>
Instead of hard-coding length values, use a define to make it clear
where those lengths come from.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
---
net/ipv6/mcast.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index 33f98d9..98ead2b 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -107,9 +107,12 @@ static int ip6_mc_add_src(struct inet6_dev *idev, const struct in6_addr *pmca,
static int ip6_mc_leave_src(struct sock *sk, struct ipv6_mc_socklist *iml,
struct inet6_dev *idev);
-
#define MLD_QRV_DEFAULT 2
+/* RFC3810, 8.1 Query Version Distinctions */
+#define MLD_V1_QUERY_LEN 24
+#define MLD_V2_QUERY_LEN_MIN 28
+
#define MLD_V1_SEEN(idev) (dev_net((idev)->dev)->ipv6.devconf_all->force_mld_version == 1 || \
(idev)->cnf.force_mld_version == 1 || \
((idev)->mc_v1_seen && \
@@ -1146,7 +1149,7 @@ int igmp6_event_query(struct sk_buff *skb)
!(group_type&IPV6_ADDR_MULTICAST))
return -EINVAL;
- if (len == 24) {
+ if (len == MLD_V1_QUERY_LEN) {
int switchback;
/* MLDv1 router present */
@@ -1160,7 +1163,7 @@ int igmp6_event_query(struct sk_buff *skb)
__in6_dev_put(idev);
/* clear deleted report items */
mld_clear_delrec(idev);
- } else if (len >= 28) {
+ } else if (len >= MLD_V2_QUERY_LEN_MIN) {
int srcs_offset = sizeof(struct mld2_query) -
sizeof(struct icmp6hdr);
if (!pskb_may_pull(skb, srcs_offset))
--
1.7.11.7
^ 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