* Re: eth_get_headlen() and unaligned accesses...
From: Tom Herbert @ 2014-10-10 18:41 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, Alexander Duyck
In-Reply-To: <20141009.201248.1210454965155680255.davem@davemloft.net>
On Thu, Oct 9, 2014 at 5:12 PM, David Miller <davem@davemloft.net> wrote:
>
> So, we have a bit of a problem, this is on sparc64:
>
> [423475.740836] Kernel unaligned access at TPC[81d330] __skb_flow_get_ports+0x70/0xe0
> [423475.755756] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.17.0+ #2
> [423475.767854] Call Trace:
> [423475.772877] [0000000000433288] kernel_unaligned_trap+0x368/0x5c0
> [423475.785203] [000000000042a824] sun4v_do_mna+0x84/0xa0
> [423475.795624] [0000000000406cd0] sun4v_mna+0x5c/0x68
> [423475.805521] [000000000081d330] __skb_flow_get_ports+0x70/0xe0
> [423475.817323] [000000000081d6ac] __skb_flow_dissect+0x1ac/0x460
> [423475.829128] [0000000000843c98] eth_get_headlen+0x38/0xa0
> [423475.840083] [0000000010064d54] igb_poll+0x8d4/0xf60 [igb]
> [423475.851184] [00000000008243c8] net_rx_action+0xa8/0x1c0
>
> The chip DMA's to the beginning of a frag page and (unless timestamps
> are enabled) that's where the ethernet header begins.
>
> So any larger than 16-bit access to the IP and later headers will be
> unaligned.
>
Will this also be a problem for GRE packet carrying Ethernet packet?
> We have various ways we can deal with this based upon the capabilities
> of the chips involved. Can we configure the IGB to put 2 "don't care"
> bytes at the beginning of the packet?
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH net-next] net: bcmgenet: enable driver to work without a device tree
From: Petri Gynther @ 2014-10-10 18:35 UTC (permalink / raw)
To: netdev; +Cc: davem, f.fainelli
Broadcom 7xxx MIPS-based STB platforms do not use device trees.
Modify bcmgenet driver so that it can be used on those platforms.
Signed-off-by: Petri Gynther <pgynther@google.com>
---
drivers/net/ethernet/broadcom/Kconfig | 1 -
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 30 +++--
drivers/net/ethernet/broadcom/genet/bcmgenet.h | 11 ++
drivers/net/ethernet/broadcom/genet/bcmmii.c | 169 +++++++++++++++++++++----
4 files changed, 179 insertions(+), 32 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/Kconfig b/drivers/net/ethernet/broadcom/Kconfig
index c3e260c..888247a 100644
--- a/drivers/net/ethernet/broadcom/Kconfig
+++ b/drivers/net/ethernet/broadcom/Kconfig
@@ -62,7 +62,6 @@ config BCM63XX_ENET
config BCMGENET
tristate "Broadcom GENET internal MAC support"
- depends on OF
select MII
select PHYLIB
select FIXED_PHY if BCMGENET=y
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index fff2634..1ec7a32 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -2475,6 +2475,7 @@ static const struct of_device_id bcmgenet_match[] = {
static int bcmgenet_probe(struct platform_device *pdev)
{
+ struct bcmgenet_platform_data *pd = pdev->dev.platform_data;
struct device_node *dn = pdev->dev.of_node;
const struct of_device_id *of_id;
struct bcmgenet_priv *priv;
@@ -2490,9 +2491,13 @@ static int bcmgenet_probe(struct platform_device *pdev)
return -ENOMEM;
}
- of_id = of_match_node(bcmgenet_match, dn);
- if (!of_id)
- return -EINVAL;
+ if (dn) {
+ of_id = of_match_node(bcmgenet_match, dn);
+ if (!of_id)
+ return -EINVAL;
+ } else {
+ of_id = NULL;
+ }
priv = netdev_priv(dev);
priv->irq0 = platform_get_irq(pdev, 0);
@@ -2504,11 +2509,15 @@ static int bcmgenet_probe(struct platform_device *pdev)
goto err;
}
- macaddr = of_get_mac_address(dn);
- if (!macaddr) {
- dev_err(&pdev->dev, "can't find MAC address\n");
- err = -EINVAL;
- goto err;
+ if (dn) {
+ macaddr = of_get_mac_address(dn);
+ if (!macaddr) {
+ dev_err(&pdev->dev, "can't find MAC address\n");
+ err = -EINVAL;
+ goto err;
+ }
+ } else {
+ macaddr = pd->macaddr;
}
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -2548,7 +2557,10 @@ static int bcmgenet_probe(struct platform_device *pdev)
priv->dev = dev;
priv->pdev = pdev;
- priv->version = (enum bcmgenet_version)of_id->data;
+ if (of_id)
+ priv->version = (enum bcmgenet_version)of_id->data;
+ else
+ priv->version = pd->genet_version;
priv->clk = devm_clk_get(&priv->pdev->dev, "enet");
if (IS_ERR(priv->clk))
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.h b/drivers/net/ethernet/broadcom/genet/bcmgenet.h
index dbf524e..5191e3f 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.h
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.h
@@ -17,6 +17,17 @@
#include <linux/if_vlan.h>
#include <linux/phy.h>
+struct bcmgenet_platform_data {
+ void __iomem *base_reg;
+ int irq0;
+ int irq1;
+ int phy_type;
+ int phy_addr;
+ int phy_speed;
+ u8 macaddr[ETH_ALEN];
+ int genet_version;
+};
+
/* total number of Buffer Descriptors, same for Rx/Tx */
#define TOTAL_DESC 256
diff --git a/drivers/net/ethernet/broadcom/genet/bcmmii.c b/drivers/net/ethernet/broadcom/genet/bcmmii.c
index 9ff799a..e5ff913 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmmii.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c
@@ -157,6 +157,21 @@ static void bcmgenet_mii_setup(struct net_device *dev)
phy_print_status(phydev);
}
+static int bcmgenet_moca_fphy_update(struct net_device *dev,
+ struct fixed_phy_status *status)
+{
+ struct bcmgenet_priv *priv = netdev_priv(dev);
+ struct phy_device *phydev = priv->phydev;
+
+ /*
+ * MoCA daemon updates phydev->autoneg to reflect the link status.
+ * Update MoCA fixed PHY status accordingly, so that the PHY state
+ * machine becomes aware of the real link status.
+ */
+ status->link = phydev->autoneg;
+ return 0;
+}
+
void bcmgenet_mii_reset(struct net_device *dev)
{
struct bcmgenet_priv *priv = netdev_priv(dev);
@@ -311,22 +326,6 @@ static int bcmgenet_mii_probe(struct net_device *dev)
u32 phy_flags;
int ret;
- if (priv->phydev) {
- pr_info("PHY already attached\n");
- return 0;
- }
-
- /* In the case of a fixed PHY, the DT node associated
- * to the PHY is the Ethernet MAC DT node.
- */
- if (!priv->phy_dn && of_phy_is_fixed_link(dn)) {
- ret = of_phy_register_fixed_link(dn);
- if (ret)
- return ret;
-
- priv->phy_dn = of_node_get(dn);
- }
-
/* Communicate the integrated PHY revision */
phy_flags = priv->gphy_rev;
@@ -336,11 +335,39 @@ static int bcmgenet_mii_probe(struct net_device *dev)
priv->old_duplex = -1;
priv->old_pause = -1;
- phydev = of_phy_connect(dev, priv->phy_dn, bcmgenet_mii_setup,
- phy_flags, priv->phy_interface);
- if (!phydev) {
- pr_err("could not attach to PHY\n");
- return -ENODEV;
+ if (dn) {
+ if (priv->phydev) {
+ pr_info("PHY already attached\n");
+ return 0;
+ }
+
+ /* In the case of a fixed PHY, the DT node associated
+ * to the PHY is the Ethernet MAC DT node.
+ */
+ if (!priv->phy_dn && of_phy_is_fixed_link(dn)) {
+ ret = of_phy_register_fixed_link(dn);
+ if (ret)
+ return ret;
+
+ priv->phy_dn = of_node_get(dn);
+ }
+
+ phydev = of_phy_connect(dev, priv->phy_dn, bcmgenet_mii_setup,
+ phy_flags, priv->phy_interface);
+ if (!phydev) {
+ pr_err("could not attach to PHY\n");
+ return -ENODEV;
+ }
+ } else {
+ phydev = priv->phydev;
+ phydev->dev_flags = phy_flags;
+
+ ret = phy_connect_direct(dev, phydev, bcmgenet_mii_setup,
+ priv->phy_interface);
+ if (ret) {
+ pr_err("could not attach to PHY\n");
+ return -ENODEV;
+ }
}
priv->phydev = phydev;
@@ -437,6 +464,104 @@ static int bcmgenet_mii_of_init(struct bcmgenet_priv *priv)
return 0;
}
+static int bcmgenet_mii_pd_init(struct bcmgenet_priv *priv)
+{
+ struct device *kdev = &priv->pdev->dev;
+ struct bcmgenet_platform_data *pd = kdev->platform_data;
+ struct mii_bus *mdio = priv->mii_bus;
+ int phy_addr = pd->phy_addr;
+ struct phy_device *phydev;
+ int ret;
+ int i;
+
+ /* Disable automatic MDIO bus scan */
+ mdio->phy_mask = ~0;
+
+ /* Clear all the IRQ properties */
+ if (mdio->irq)
+ for (i = 0; i < PHY_MAX_ADDR; i++)
+ mdio->irq[i] = PHY_POLL;
+
+ /* Register the MDIO bus */
+ ret = mdiobus_register(mdio);
+ if (ret) {
+ dev_err(kdev, "failed to register MDIO bus\n");
+ return ret;
+ }
+
+ /*
+ * bcmgenet_platform_data needs to pass a valid PHY address for
+ * internal/external PHY or -1 for MoCA PHY.
+ */
+ if (phy_addr >= 0 && phy_addr < PHY_MAX_ADDR) {
+ /*
+ * 10/100/1000 Ethernet port with external or internal PHY.
+ */
+ phydev = get_phy_device(mdio, phy_addr, false);
+ if (!phydev || IS_ERR(phydev)) {
+ dev_err(kdev, "failed to create PHY device\n");
+ mdiobus_unregister(mdio);
+ return 1;
+ }
+
+ phydev->irq = PHY_POLL;
+
+ ret = phy_device_register(phydev);
+ if (ret) {
+ dev_err(kdev, "failed to register PHY device\n");
+ phy_device_free(phydev);
+ mdiobus_unregister(mdio);
+ return 1;
+ }
+
+ priv->phydev = phydev;
+ priv->phy_interface = pd->phy_type;
+ } else {
+ /*
+ * MoCA port with no MDIO-accessible PHY.
+ * We need to use 1000/HD fixed PHY to represent the link layer.
+ * MoCA daemon interacts with this PHY via ethtool.
+ */
+ struct fixed_phy_status moca_fphy_status = {
+ .link = 0,
+ .duplex = 0,
+ .speed = 1000,
+ .pause = 0,
+ .asym_pause = 0,
+ };
+
+ phydev = fixed_phy_register(PHY_POLL, &moca_fphy_status, NULL);
+ if (!phydev || IS_ERR(phydev)) {
+ dev_err(kdev, "failed to register fixed PHY device\n");
+ mdiobus_unregister(mdio);
+ return 1;
+ }
+
+ phydev->autoneg = AUTONEG_DISABLE;
+
+ ret = fixed_phy_set_link_update(phydev,
+ bcmgenet_moca_fphy_update);
+ if (ret) {
+ dev_err(kdev, "failed to set fixed PHY link update\n");
+ }
+
+ priv->phydev = phydev;
+ priv->phy_interface = PHY_INTERFACE_MODE_MOCA;
+ }
+
+ return 0;
+}
+
+static int bcmgenet_mii_bus_init(struct bcmgenet_priv *priv)
+{
+ struct device_node *dn = priv->pdev->dev.of_node;
+
+ if (dn)
+ return bcmgenet_mii_of_init(priv);
+ else
+ return bcmgenet_mii_pd_init(priv);
+}
+
int bcmgenet_mii_init(struct net_device *dev)
{
struct bcmgenet_priv *priv = netdev_priv(dev);
@@ -446,7 +571,7 @@ int bcmgenet_mii_init(struct net_device *dev)
if (ret)
return ret;
- ret = bcmgenet_mii_of_init(priv);
+ ret = bcmgenet_mii_bus_init(priv);
if (ret)
goto out_free;
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* Re: [PATCH 1/1] Checkpatch: coding style errors in Nvidia ethernet driver
From: David Miller @ 2014-10-10 18:25 UTC (permalink / raw)
To: akshaysarode21; +Cc: john.stultz, netdev, linux-kernel
In-Reply-To: <1412928102-1696-1-git-send-email-akshaysarode21@gmail.com>
From: Akshay Sarode <akshaysarode21@gmail.com>
Date: Fri, 10 Oct 2014 13:31:42 +0530
> ERROR: "foo* bar" should be "foo *bar"
> ERROR: do not initialise statics to 0 or NULL
> CHECK: spinlock_t definition without comment
> Signed-off-by: Akshay Sarode <akshaysarode21@gmail.com>
The Subject "Subsystem: " prefix is meant to refer to what area of
the kernel you are changing.
You aren't making changes to "Checkpatch: " so that isn't an
appropriate prefix. Someone scanning the commit header lines
won't be able to tell what part of the kernel your change is
touching.
In this case you should use "nvidia: " as your subsystem
prefix.
^ permalink raw reply
* Re: [PATCH] flow-dissector: Fix alignment issue in __skb_flow_get_ports
From: David Miller @ 2014-10-10 18:22 UTC (permalink / raw)
To: alexander.duyck; +Cc: alexander.h.duyck, eric.dumazet, David.Laight, netdev
In-Reply-To: <20141010.141559.2024576018585843684.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Fri, 10 Oct 2014 14:15:59 -0400 (EDT)
> Your original code works because you do things like "byte[12] & 0xf0" to
> extract these fields.
Changing that th->doff sequence to instead be:
const u8 *bp;
u8 buf[13];
bp = __skb_header_pointer(skb, poff, sizeof(buf),
data, hlen, &buf);
if (!bp)
return poff;
poff += max_t(u32, sizeof(struct tcphdr), (bp[12] & 0xf0) >> 2);
break;
on top of your v3 patch works for me.
Please double-check my calculations.
^ permalink raw reply
* Re: [PATCH] flow-dissector: Fix alignment issue in __skb_flow_get_ports
From: David Miller @ 2014-10-10 18:15 UTC (permalink / raw)
To: alexander.duyck; +Cc: alexander.h.duyck, eric.dumazet, David.Laight, netdev
In-Reply-To: <54381F1C.2030800@gmail.com>
From: Alexander Duyck <alexander.duyck@gmail.com>
Date: Fri, 10 Oct 2014 11:02:04 -0700
> On 10/10/2014 10:58 AM, David Miller wrote:
>> From: Alexander Duyck <alexander.h.duyck@redhat.com>
>> Date: Fri, 10 Oct 2014 09:50:17 -0700
>>
>>> If I just use get_unaligned that is pretty easy in terms of cleanup
>>> for the ports and IPv4 addresses, the IPv6 will still be a significant
>>> hurdle to overcome though.
>> Actually, it's not that simple.
>>
>> When the compiler sees things like "th->doff" it will load the 32-bit
>> word that 4-bit field contains and extract the value using shifts and
>> masking.
>>
>> So we might need to sprinkle a "attribute((packed))" here and there
>> to make it work.
>
> I'll do some digging. I know I had this working in igb/ixgbe before so
> I probably just need to add a few small tweaks to resolve the remaining
> issues for v4 of the patch.
Your original code works because you do things like "byte[12] & 0xf0" to
extract these fields.
^ permalink raw reply
* Re: [PATCH net v2 1/3] net: bcmgenet: fix off-by-one in incrementing read pointer
From: Petri Gynther @ 2014-10-10 18:15 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, David Miller, Jaedon Shin
In-Reply-To: <1412963514-7718-2-git-send-email-f.fainelli@gmail.com>
Looks good to me.
On Fri, Oct 10, 2014 at 10:51 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> Commit b629be5c8399d7c423b92135eb43a86c924d1cbc ("net: bcmgenet: check
> harder for out of memory conditions") moved the increment of the local
> read pointer *before* reading from the hardware descriptor using
> dmadesc_get_length_status(), which creates an off-by-one situation.
>
> Fix this by moving again the read_ptr increment after we have read the
> hardware descriptor to get both the control block and the read pointer
> back in sync.
>
> Fixes: b629be5c8399 ("net: bcmgenet: check harder for out of memory conditions")
> Signed-off-by: Jaedon Shin <jaedon.shin@gmail.com>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Petri Gynther <pgynther@google.com>
> ---
> Changes in v2:
> - moved the rxpktprocessed and rx_read_ptr increment after refiling the control
> block
>
> drivers/net/ethernet/broadcom/genet/bcmgenet.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> index fff2634b6f34..fdc9ec09e453 100644
> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> @@ -1285,11 +1285,6 @@ static unsigned int bcmgenet_desc_rx(struct bcmgenet_priv *priv,
> cb = &priv->rx_cbs[priv->rx_read_ptr];
> skb = cb->skb;
>
> - rxpktprocessed++;
> -
> - priv->rx_read_ptr++;
> - priv->rx_read_ptr &= (priv->num_rx_bds - 1);
> -
> /* We do not have a backing SKB, so we do not have a
> * corresponding DMA mapping for this incoming packet since
> * bcmgenet_rx_refill always either has both skb and mapping or
> @@ -1404,6 +1399,10 @@ refill:
> err = bcmgenet_rx_refill(priv, cb);
> if (err)
> netif_err(priv, rx_err, dev, "Rx refill failed\n");
> +
> + rxpktprocessed++;
> + priv->rx_read_ptr++;
> + priv->rx_read_ptr &= (priv->num_rx_bds - 1);
> }
>
> return rxpktprocessed;
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH] flow-dissector: Fix alignment issue in __skb_flow_get_ports
From: David Miller @ 2014-10-10 18:14 UTC (permalink / raw)
To: alexander.duyck; +Cc: alexander.h.duyck, eric.dumazet, David.Laight, netdev
In-Reply-To: <54381F1C.2030800@gmail.com>
From: Alexander Duyck <alexander.duyck@gmail.com>
Date: Fri, 10 Oct 2014 11:02:04 -0700
> On 10/10/2014 10:58 AM, David Miller wrote:
>> From: Alexander Duyck <alexander.h.duyck@redhat.com>
>> Date: Fri, 10 Oct 2014 09:50:17 -0700
>>
>>> If I just use get_unaligned that is pretty easy in terms of cleanup
>>> for the ports and IPv4 addresses, the IPv6 will still be a significant
>>> hurdle to overcome though.
>> Actually, it's not that simple.
>>
>> When the compiler sees things like "th->doff" it will load the 32-bit
>> word that 4-bit field contains and extract the value using shifts and
>> masking.
>>
>> So we might need to sprinkle a "attribute((packed))" here and there
>> to make it work.
>
> I'll do some digging. I know I had this working in igb/ixgbe before so
> I probably just need to add a few small tweaks to resolve the remaining
> issues for v4 of the patch.
Ok, I think v3 + resolving the th->doff thing will get rid of everything.
^ permalink raw reply
* Re: [PATCH] flow-dissector: Fix alignment issue in __skb_flow_get_ports
From: Alexander Duyck @ 2014-10-10 18:02 UTC (permalink / raw)
To: David Miller, alexander.h.duyck; +Cc: eric.dumazet, David.Laight, netdev
In-Reply-To: <20141010.135851.1743803688676076555.davem@davemloft.net>
On 10/10/2014 10:58 AM, David Miller wrote:
> From: Alexander Duyck <alexander.h.duyck@redhat.com>
> Date: Fri, 10 Oct 2014 09:50:17 -0700
>
>> If I just use get_unaligned that is pretty easy in terms of cleanup
>> for the ports and IPv4 addresses, the IPv6 will still be a significant
>> hurdle to overcome though.
> Actually, it's not that simple.
>
> When the compiler sees things like "th->doff" it will load the 32-bit
> word that 4-bit field contains and extract the value using shifts and
> masking.
>
> So we might need to sprinkle a "attribute((packed))" here and there
> to make it work.
I'll do some digging. I know I had this working in igb/ixgbe before so
I probably just need to add a few small tweaks to resolve the remaining
issues for v4 of the patch.
Thanks,
Alex
^ permalink raw reply
* [PATCH v3] flow-dissector: Fix alignment issue in __skb_flow_get_ports
From: alexander.duyck @ 2014-10-10 18:00 UTC (permalink / raw)
To: netdev, davem; +Cc: eric.dumazet
From: Alexander Duyck <alexander.h.duyck@redhat.com>
This patch addresses a kernel unaligned access bug seen on a sparc64 system
with an igb adapter. Specifically the __skb_flow_get_ports was returning a
be32 pointer which was then having the value directly returned.
In order to prevent this it is actually easier to simply not populate the
ports or address values when an skb is not present. In this case the
assumption is that the data isn't needed and rather than slow down the
faster aligned accesses by making them have to assume the unaligned path on
architectures that don't support efficent unaligned access it makes more
sense to simply switch off the bits that were copying the source and
destination address/port for the case where we only care about the protocol
types and lengths which are normally 16 bit fields anyway.
Reported-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
---
v2: Fixed alignment to __be16 on ports
v3: Discarded previous approach and instead simplified things by
not populating ports, or src/dst addresses if skb is not present.
By doing this we avoid the unaligned access issue entirely and do not
populate fields that will not be used by the eth_get_headlen function.
net/core/flow_dissector.c | 24 +++++++++++++++++-------
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index 8560dea..80ca371 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -100,7 +100,15 @@ ip:
if (ip_is_fragment(iph))
ip_proto = 0;
+ /* skip the address processing if skb is NULL. The assumption
+ * here is that if there is no skb we are not looking for flow
+ * info but lengths and protocols.
+ */
+ if (!skb)
+ break;
+
iph_to_flow_copy_addrs(flow, iph);
+
break;
}
case htons(ETH_P_IPV6): {
@@ -114,17 +122,15 @@ ipv6:
return false;
ip_proto = iph->nexthdr;
- flow->src = (__force __be32)ipv6_addr_hash(&iph->saddr);
- flow->dst = (__force __be32)ipv6_addr_hash(&iph->daddr);
nhoff += sizeof(struct ipv6hdr);
- /* skip the flow label processing if skb is NULL. The
- * assumption here is that if there is no skb we are not
- * looking for flow info as much as we are length.
- */
+ /* see comment above in IPv4 section */
if (!skb)
break;
+ flow->src = (__force __be32)ipv6_addr_hash(&iph->saddr);
+ flow->dst = (__force __be32)ipv6_addr_hash(&iph->daddr);
+
flow_label = ip6_flowlabel(iph);
if (flow_label) {
/* Awesome, IPv6 packet has a flow label so we can
@@ -231,9 +237,13 @@ ipv6:
flow->n_proto = proto;
flow->ip_proto = ip_proto;
- flow->ports = __skb_flow_get_ports(skb, nhoff, ip_proto, data, hlen);
flow->thoff = (u16) nhoff;
+ /* unless skb is set we don't need to record port info */
+ if (skb)
+ flow->ports = __skb_flow_get_ports(skb, nhoff, ip_proto,
+ data, hlen);
+
return true;
}
EXPORT_SYMBOL(__skb_flow_dissect);
^ permalink raw reply related
* Re: [PATCH] flow-dissector: Fix alignment issue in __skb_flow_get_ports
From: David Miller @ 2014-10-10 17:58 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: eric.dumazet, David.Laight, alexander.duyck, netdev
In-Reply-To: <54380E49.5050504@redhat.com>
From: Alexander Duyck <alexander.h.duyck@redhat.com>
Date: Fri, 10 Oct 2014 09:50:17 -0700
> If I just use get_unaligned that is pretty easy in terms of cleanup
> for the ports and IPv4 addresses, the IPv6 will still be a significant
> hurdle to overcome though.
Actually, it's not that simple.
When the compiler sees things like "th->doff" it will load the 32-bit
word that 4-bit field contains and extract the value using shifts and
masking.
So we might need to sprinkle a "attribute((packed))" here and there
to make it work.
^ permalink raw reply
* Re: [PATCH v2] flow-dissector: Fix alignment issue in __skb_flow_get_ports
From: David Miller @ 2014-10-10 17:55 UTC (permalink / raw)
To: eric.dumazet; +Cc: alexander.duyck, netdev
In-Reply-To: <1412955376.9362.15.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 10 Oct 2014 08:36:16 -0700
> On Fri, 2014-10-10 at 07:59 -0700, alexander.duyck@gmail.com wrote:
>> From: Alexander Duyck <alexander.h.duyck@redhat.com>
>>
>> This patch addresses a kernel unaligned access bug seen on a sparc64 system
>> with an igb adapter. Specifically the __skb_flow_get_ports was returning a
>> be32 pointer which was then having the value directly returned.
>>
>> In order to keep the handling of the ports consistent with how we were
>> handling the IPv4 and IPv6 addresses I have instead replaced the assignment
>> with a memcpy to the flow key ports value. This way it should stay a
>> memcpy on systems that cannot handle unaligned access, and will likely be
>> converted to a 32b assignment on the systems that can support it.
>>
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
>> ---
>
> I believe you also need to take care of calls to ipv6_addr_hash()
>
> The IPv4 part also needs something in iph_to_flow_copy_addrs(),
> otherwise compiler might assume &iph->saddr is word aligned.
Right, I still get the unaligned accesses even with this patch:
[487667.804777] Kernel unaligned access at TPC[81de40] __skb_get_poff+0xa0/0x100
[487667.818767] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.17.0+ #3
[487667.830930] Call Trace:
[487667.835954] [0000000000433288] kernel_unaligned_trap+0x368/0x5c0
[487667.848276] [000000000042a824] sun4v_do_mna+0x84/0xa0
[487667.858698] [0000000000406cd0] sun4v_mna+0x5c/0x68
[487667.868592] [000000000081de40] __skb_get_poff+0xa0/0x100
[487667.879531] [0000000000843d2c] eth_get_headlen+0x6c/0xa0
[487667.890486] [000000001003ed54] igb_poll+0x8d4/0xf60 [igb]
[487667.901584] [0000000000824428] net_rx_action+0xa8/0x1c0
[487667.912348] [000000000046a1fc] __do_softirq+0xdc/0x2e0
[487667.922932] [000000000042b96c] do_softirq_own_stack+0x2c/0x40
[487667.934751] [000000000046a6b8] irq_exit+0x98/0xc0
[487667.944473] [000000000042b900] handler_irq+0xc0/0x100
[487667.954888] [00000000004208b4] tl0_irq5+0x14/0x20
[487667.964610] [000000000042c0d4] arch_cpu_idle+0x74/0xa0
[487667.975201] [0000000000499cdc] cpu_startup_entry+0x17c/0x2c0
[487667.986843] [0000000000ab69b8] start_kernel+0x408/0x418
[487667.997603] [00000000008c3628] tlb_fixup_done+0x98/0xb0
^ permalink raw reply
* [PATCH net v2 3/3] net: systemport: avoid unbalanced enable_irq_wake calls
From: Florian Fainelli @ 2014-10-10 17:51 UTC (permalink / raw)
To: netdev; +Cc: davem, pgynther, jaedon.shin, Florian Fainelli
In-Reply-To: <1412963514-7718-1-git-send-email-f.fainelli@gmail.com>
Multiple enable_irq_wake() calls will keep increasing the IRQ
wake_depth, which ultimately leads to the following types of
situation:
1) enable Wake-on-LAN interrupt w/o password
2) enable Wake-on-LAN interrupt w/ password
3) enable Wake-on-LAN interrupt w/o password
4) disable Wake-on-LAN interrupt
After step 4), SYSTEMPORT would always wake-up the system no matter what
wake-up device we use, which is not what we want. Fix this by making
sure there are no unbalanced enable_irq_wake() calls.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/broadcom/bcmsysport.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c b/drivers/net/ethernet/broadcom/bcmsysport.c
index 075688188644..9ae36979bdee 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -436,7 +436,8 @@ static int bcm_sysport_set_wol(struct net_device *dev,
/* Flag the device and relevant IRQ as wakeup capable */
if (wol->wolopts) {
device_set_wakeup_enable(kdev, 1);
- enable_irq_wake(priv->wol_irq);
+ if (priv->wol_irq_disabled)
+ enable_irq_wake(priv->wol_irq);
priv->wol_irq_disabled = 0;
} else {
device_set_wakeup_enable(kdev, 0);
--
1.9.1
^ permalink raw reply related
* [PATCH net v2 2/3] net: bcmgenet: avoid unbalanced enable_irq_wake calls
From: Florian Fainelli @ 2014-10-10 17:51 UTC (permalink / raw)
To: netdev; +Cc: davem, pgynther, jaedon.shin, Florian Fainelli
In-Reply-To: <1412963514-7718-1-git-send-email-f.fainelli@gmail.com>
Multiple enable_irq_wake() calls will keep increasing the IRQ
wake_depth, which ultimately leads to the following types of
situation:
1) enable Wake-on-LAN interrupt w/o password
2) enable Wake-on-LAN interrupt w/ password
3) enable Wake-on-LAN interrupt w/o password
4) disable Wake-on-LAN interrupt
After step 4), GENET would always wake-up the system no matter what
wake-up device we use, which is not what we want. Fix this by making
sure there are no unbalanced enable_irq_wake() calls.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/broadcom/genet/bcmgenet_wol.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet_wol.c b/drivers/net/ethernet/broadcom/genet/bcmgenet_wol.c
index b82b7e4e06b2..149a0d70c108 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet_wol.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet_wol.c
@@ -86,7 +86,9 @@ int bcmgenet_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
/* Flag the device and relevant IRQ as wakeup capable */
if (wol->wolopts) {
device_set_wakeup_enable(kdev, 1);
- enable_irq_wake(priv->wol_irq);
+ /* Avoid unbalanced enable_irq_wake calls */
+ if (priv->wol_irq_disabled)
+ enable_irq_wake(priv->wol_irq);
priv->wol_irq_disabled = false;
} else {
device_set_wakeup_enable(kdev, 0);
--
1.9.1
^ permalink raw reply related
* [PATCH net v2 1/3] net: bcmgenet: fix off-by-one in incrementing read pointer
From: Florian Fainelli @ 2014-10-10 17:51 UTC (permalink / raw)
To: netdev; +Cc: davem, pgynther, jaedon.shin, Florian Fainelli
In-Reply-To: <1412963514-7718-1-git-send-email-f.fainelli@gmail.com>
Commit b629be5c8399d7c423b92135eb43a86c924d1cbc ("net: bcmgenet: check
harder for out of memory conditions") moved the increment of the local
read pointer *before* reading from the hardware descriptor using
dmadesc_get_length_status(), which creates an off-by-one situation.
Fix this by moving again the read_ptr increment after we have read the
hardware descriptor to get both the control block and the read pointer
back in sync.
Fixes: b629be5c8399 ("net: bcmgenet: check harder for out of memory conditions")
Signed-off-by: Jaedon Shin <jaedon.shin@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Changes in v2:
- moved the rxpktprocessed and rx_read_ptr increment after refiling the control
block
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index fff2634b6f34..fdc9ec09e453 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -1285,11 +1285,6 @@ static unsigned int bcmgenet_desc_rx(struct bcmgenet_priv *priv,
cb = &priv->rx_cbs[priv->rx_read_ptr];
skb = cb->skb;
- rxpktprocessed++;
-
- priv->rx_read_ptr++;
- priv->rx_read_ptr &= (priv->num_rx_bds - 1);
-
/* We do not have a backing SKB, so we do not have a
* corresponding DMA mapping for this incoming packet since
* bcmgenet_rx_refill always either has both skb and mapping or
@@ -1404,6 +1399,10 @@ refill:
err = bcmgenet_rx_refill(priv, cb);
if (err)
netif_err(priv, rx_err, dev, "Rx refill failed\n");
+
+ rxpktprocessed++;
+ priv->rx_read_ptr++;
+ priv->rx_read_ptr &= (priv->num_rx_bds - 1);
}
return rxpktprocessed;
--
1.9.1
^ permalink raw reply related
* [PATCH net v2 0/3] net: bcmgenet & systemport fixes
From: Florian Fainelli @ 2014-10-10 17:51 UTC (permalink / raw)
To: netdev; +Cc: davem, pgynther, jaedon.shin, Florian Fainelli
Hi David,
This patch series fixes an off-by-one error introduced during a previous
change, and the two other fixes fix a wake depth imbalance situation for
the Wake-on-LAN interrupt line.
Thanks!
Florian Fainelli (3):
net: bcmgenet: fix off-by-one in incrementing read pointer
net: bcmgenet: avoid unbalanced enable_irq_wake calls
net: systemport: avoid unbalanced enable_irq_wake calls
drivers/net/ethernet/broadcom/bcmsysport.c | 3 ++-
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 9 ++++-----
drivers/net/ethernet/broadcom/genet/bcmgenet_wol.c | 4 +++-
3 files changed, 9 insertions(+), 7 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: [PATCH net 1/3] net: bcmgenet: fix off-by-one in incrementing read pointer
From: Florian Fainelli @ 2014-10-10 17:18 UTC (permalink / raw)
To: Petri Gynther; +Cc: netdev, David Miller, jaedon.shin
In-Reply-To: <CAGXr9JEm4Dmo5QYhsv7ydr8NBujtrJ=gJ9kxSFoiBQ-YVQkGBA@mail.gmail.com>
On 10/10/2014 10:17 AM, Petri Gynther wrote:
> On Fri, Oct 10, 2014 at 9:41 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>> On 10/09/2014 11:01 PM, Petri Gynther wrote:
>>> Hi Florian,
>>>
>>> On Thu, Oct 9, 2014 at 6:06 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>>> Commit b629be5c8399d7c423b92135eb43a86c924d1cbc ("net: bcmgenet: check
>>>> harder for out of memory conditions") moved the increment of the local
>>>> read pointer *before* reading from the hardware descriptor using
>>>> dmadesc_get_length_status(), which creates an off-by-one situation.
>>>>
>>>> Fix this by moving again the read_ptr increment after we have read the
>>>> hardware descriptor to get both the control block and the read pointer
>>>> back in sync.
>>>>
>>>> Fixes: b629be5c8399 ("net: bcmgenet: check harder for out of memory conditions")
>>>> Reported-by: Jaedon Shin <jaedon.shin@gmail.com>
>>>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>>>> ---
>>>> drivers/net/ethernet/broadcom/genet/bcmgenet.c | 6 +++---
>>>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>>>> index fff2634b6f34..f1bcebcbba80 100644
>>>> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>>>> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>>>> @@ -1287,9 +1287,6 @@ static unsigned int bcmgenet_desc_rx(struct bcmgenet_priv *priv,
>>>>
>>>> rxpktprocessed++;
>>>>
>>>> - priv->rx_read_ptr++;
>>>> - priv->rx_read_ptr &= (priv->num_rx_bds - 1);
>>>> -
>>>
>>> Wouldn't it be better to move the three lines:
>>> rxpktprocessed++;
>>> priv->rx_read_ptr++;
>>> priv->rx_read_ptr &= (priv->num_rx_bds - 1)
>>>
>>> as the last lines of the while-loop, after the CB refill?
>>
>> That's basically what Jaedon did in his first patch, I don't have strong
>> objections in doing that if you think that makes it look clearer.
>>
>
> I feel that this would be cleaner approach. First do the work (or skip
> to refill), then increment necessary variables, and go back to the
> while-loop.
Sounds good, I will re-submit shortly, thanks!
>
>>>
>>> -- Petri
>>>
>>>
>>>> /* We do not have a backing SKB, so we do not have a
>>>> * corresponding DMA mapping for this incoming packet since
>>>> * bcmgenet_rx_refill always either has both skb and mapping or
>>>> @@ -1332,6 +1329,9 @@ static unsigned int bcmgenet_desc_rx(struct bcmgenet_priv *priv,
>>>> __func__, p_index, priv->rx_c_index,
>>>> priv->rx_read_ptr, dma_length_status);
>>>>
>>>> + priv->rx_read_ptr++;
>>>> + priv->rx_read_ptr &= (priv->num_rx_bds - 1);
>>>> +
>>>> if (unlikely(!(dma_flag & DMA_EOP) || !(dma_flag & DMA_SOP))) {
>>>> netif_err(priv, rx_status, dev,
>>>> "dropping fragmented packet!\n");
>>>> --
>>>> 1.9.1
>>>>
>>
^ permalink raw reply
* Re: [PATCH net 1/3] net: bcmgenet: fix off-by-one in incrementing read pointer
From: Petri Gynther @ 2014-10-10 17:17 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, David Miller, jaedon.shin
In-Reply-To: <54380C29.9010704@gmail.com>
On Fri, Oct 10, 2014 at 9:41 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 10/09/2014 11:01 PM, Petri Gynther wrote:
>> Hi Florian,
>>
>> On Thu, Oct 9, 2014 at 6:06 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>> Commit b629be5c8399d7c423b92135eb43a86c924d1cbc ("net: bcmgenet: check
>>> harder for out of memory conditions") moved the increment of the local
>>> read pointer *before* reading from the hardware descriptor using
>>> dmadesc_get_length_status(), which creates an off-by-one situation.
>>>
>>> Fix this by moving again the read_ptr increment after we have read the
>>> hardware descriptor to get both the control block and the read pointer
>>> back in sync.
>>>
>>> Fixes: b629be5c8399 ("net: bcmgenet: check harder for out of memory conditions")
>>> Reported-by: Jaedon Shin <jaedon.shin@gmail.com>
>>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>>> ---
>>> drivers/net/ethernet/broadcom/genet/bcmgenet.c | 6 +++---
>>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>>> index fff2634b6f34..f1bcebcbba80 100644
>>> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>>> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>>> @@ -1287,9 +1287,6 @@ static unsigned int bcmgenet_desc_rx(struct bcmgenet_priv *priv,
>>>
>>> rxpktprocessed++;
>>>
>>> - priv->rx_read_ptr++;
>>> - priv->rx_read_ptr &= (priv->num_rx_bds - 1);
>>> -
>>
>> Wouldn't it be better to move the three lines:
>> rxpktprocessed++;
>> priv->rx_read_ptr++;
>> priv->rx_read_ptr &= (priv->num_rx_bds - 1)
>>
>> as the last lines of the while-loop, after the CB refill?
>
> That's basically what Jaedon did in his first patch, I don't have strong
> objections in doing that if you think that makes it look clearer.
>
I feel that this would be cleaner approach. First do the work (or skip
to refill), then increment necessary variables, and go back to the
while-loop.
>>
>> -- Petri
>>
>>
>>> /* We do not have a backing SKB, so we do not have a
>>> * corresponding DMA mapping for this incoming packet since
>>> * bcmgenet_rx_refill always either has both skb and mapping or
>>> @@ -1332,6 +1329,9 @@ static unsigned int bcmgenet_desc_rx(struct bcmgenet_priv *priv,
>>> __func__, p_index, priv->rx_c_index,
>>> priv->rx_read_ptr, dma_length_status);
>>>
>>> + priv->rx_read_ptr++;
>>> + priv->rx_read_ptr &= (priv->num_rx_bds - 1);
>>> +
>>> if (unlikely(!(dma_flag & DMA_EOP) || !(dma_flag & DMA_SOP))) {
>>> netif_err(priv, rx_status, dev,
>>> "dropping fragmented packet!\n");
>>> --
>>> 1.9.1
>>>
>
^ permalink raw reply
* Re: [PATCH 1/1] Checkpatch: coding style errors in Nvidia ethernet driver
From: Joe Perches @ 2014-10-10 17:04 UTC (permalink / raw)
To: Akshay Sarode; +Cc: netdev, linux-kernel
In-Reply-To: <20141010164515.GA3596@linux.akshay.com>
On Fri, 2014-10-10 at 22:15 +0530, Akshay Sarode wrote:
> On Fri, Oct 10, 2014 at 08:03:07AM -0700, Joe Perches wrote:
> > On Fri, 2014-10-10 at 13:31 +0530, Akshay Sarode wrote:
> > > ERROR: "foo* bar" should be "foo *bar"
> > > ERROR: do not initialise statics to 0 or NULL
> > > CHECK: spinlock_t definition without comment
> > > Signed-off-by: Akshay Sarode <akshaysarode21@gmail.com>
> > []
> > > diff --git a/drivers/net/ethernet/nvidia/forcedeth.c b/drivers/net/ethernet/nvidia/forcedeth.c
> > []
> > > @@ -911,12 +913,18 @@ enum {
> > []
> > > /*
> > > * Debug output control for tx_timeout
> > > */
> > > -static bool debug_tx_timeout = false;
> > > +enum {
> > > + NV_DEBUG_TX_TIMEOUT_DISABLED,
> > > + NV_DEBUG_TX_TIMEOUT_ENABLED
> > > +};
> > > +
> > > +static bool debug_tx_timeout = NV_DEBUG_TX_TIMEOUT_DISABLED;
> >
> > Adding this enum is not useful.
> >
> Sorry, If I may have not checked the code properly. I am a newbie here and I was hoping to start with checking coding styles.
No worries, welcome.
Starting with fixing a coding style defect or three is
just fine to learn how to compile and test the kernel.
But generally it's more useful to find things that make
the code better, more readable, smaller, faster, etc.
Also if you have some functional defect or enhancement
to implement, that's even better still.
> I'll check again.
Using an enum for a bool isn't very sensible.
true/false exist already.
> Also there are a whole lot of warnings for line over 80 characters.
I wouldn't bother with long line conversions unless
you're doing something else at the same time.
If you want to do them for the practice, please do
them on files in drivers/staging/.
^ permalink raw reply
* [PATCH iproute2] Changed action labels to [action ] format
From: Vadim Kochan @ 2014-10-10 16:51 UTC (permalink / raw)
To: netdev; +Cc: Vadim Kochan
The reasons for this change were:
- different ip utils uses different labels for action: Deleted/delete
- make an action labels to be easy found in logs
ip monitor:
[DELETED] 192.168.2.0/24 dev winbr0 proto kernel scope link src 192.168.2.100 metric 205
[DELETED] default via 192.168.2.1 dev winbr0 metric 205
[DELETED] 5: winbr0 inet 192.168.2.100/24 brd 192.168.2.255 scope global winbr0
valid_lft forever preferred_lft forever
[DELETED] broadcast 192.168.2.255 dev winbr0 table local proto kernel scope link src 192.168.2.100
[DELETED] broadcast 192.168.2.0 dev winbr0 table local proto kernel scope link src 192.168.2.100
[DELETED] local 192.168.2.100 dev winbr0 table local proto kernel scope host src 192.168.2.100
[DELETED] 224.0.0.251 dev winbr0 lladdr XX:XX:XX:XX:XX:XX NOARP
[DELETED] 224.0.0.22 dev winbr0 lladdr XX:XX:XX:XX:XX:XX NOARP
[DELETED] 192.168.2.1 dev winbr0 lladdr XX:XX:XX:XX:XX:XX REACHABLE
tc monitor:
[DELETED] qdisc dsmark 10: dev lo root indices 0x0040 default_index 0x0001 set_tc_index
qdisc cbq 10: dev lo root rate 100Mbit (bounded,isolated) prio no-transmit
class cbq 10:12 dev lo parent 10: rate 100Mbit (bounded) prio 3
[DELETED] qdisc cbq 10: dev lo root rate 100Mbit (bounded,isolated) prio no-transmit
qdisc htb 10: dev lo root r2q 10 default 0 direct_packets_stat 0 direct_qlen 2
class htb 10:12 dev lo root prio 0 rate 100Mbit ceil 100Mbit burst 1600b cburst 1600b
[DELETED] qdisc htb 10: dev lo root r2q 10 default 0 direct_packets_stat 0 direct_qlen 2
qdisc dsmark 20: dev lo root indices 0x0040 default_index 0x0001 set_tc_index
class dsmark 20:12 dev lo parent 20: mask 0xff value 0x02
[DELETED] qdisc pfifo 0: dev lo parent 20: limit 1p
qdisc prio 10: dev lo parent 20: bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
---
bridge/fdb.c | 2 +-
bridge/link.c | 2 +-
ip/ipaddress.c | 4 ++--
ip/ipaddrlabel.c | 2 +-
ip/ipmroute.c | 2 +-
ip/ipneigh.c | 4 ++--
ip/ipnetns.c | 4 ++--
ip/iproute.c | 2 +-
ip/iprule.c | 2 +-
ip/tcp_metrics.c | 2 +-
ip/xfrm_policy.c | 6 +++---
ip/xfrm_state.c | 6 +++---
tc/m_action.c | 6 +++---
tc/tc_class.c | 2 +-
tc/tc_filter.c | 2 +-
tc/tc_qdisc.c | 2 +-
16 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/bridge/fdb.c b/bridge/fdb.c
index a55fac1..26cff05 100644
--- a/bridge/fdb.c
+++ b/bridge/fdb.c
@@ -88,7 +88,7 @@ int print_fdb(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
n->nlmsg_len - NLMSG_LENGTH(sizeof(*r)));
if (n->nlmsg_type == RTM_DELNEIGH)
- fprintf(fp, "Deleted ");
+ fprintf(fp, "[DELETED] ");
if (tb[NDA_LLADDR]) {
SPRINT_BUF(b1);
diff --git a/bridge/link.c b/bridge/link.c
index 90d9e7f..6eb5887 100644
--- a/bridge/link.c
+++ b/bridge/link.c
@@ -125,7 +125,7 @@ int print_linkinfo(const struct sockaddr_nl *who,
}
if (n->nlmsg_type == RTM_DELLINK)
- fprintf(fp, "Deleted ");
+ fprintf(fp, "[DELETED] ");
fprintf(fp, "%d: %s ", ifi->ifi_index,
tb[IFLA_IFNAME] ? rta_getattr_str(tb[IFLA_IFNAME]) : "<nil>");
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 45729d8..5c3d5f1 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -481,7 +481,7 @@ int print_linkinfo(const struct sockaddr_nl *who,
}
if (n->nlmsg_type == RTM_DELLINK)
- fprintf(fp, "Deleted ");
+ fprintf(fp, "[DELETED] ");
fprintf(fp, "%d: %s", ifi->ifi_index,
tb[IFLA_IFNAME] ? rta_getattr_str(tb[IFLA_IFNAME]) : "<nil>");
@@ -694,7 +694,7 @@ int print_addrinfo(const struct sockaddr_nl *who, struct nlmsghdr *n,
}
if (n->nlmsg_type == RTM_DELADDR)
- fprintf(fp, "Deleted ");
+ fprintf(fp, "[DELETED] ");
if (filter.oneline || filter.flushb)
fprintf(fp, "%u: %s", ifa->ifa_index, ll_index_to_name(ifa->ifa_index));
diff --git a/ip/ipaddrlabel.c b/ip/ipaddrlabel.c
index b34dd8b..1386586 100644
--- a/ip/ipaddrlabel.c
+++ b/ip/ipaddrlabel.c
@@ -71,7 +71,7 @@ int print_addrlabel(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg
parse_rtattr(tb, IFAL_MAX, IFAL_RTA(ifal), len);
if (n->nlmsg_type == RTM_DELADDRLABEL)
- fprintf(fp, "Deleted ");
+ fprintf(fp, "[DELETED] ");
if (tb[IFAL_ADDRESS]) {
fprintf(fp, "prefix %s/%u ",
diff --git a/ip/ipmroute.c b/ip/ipmroute.c
index be93a98..6c6eb75 100644
--- a/ip/ipmroute.c
+++ b/ip/ipmroute.c
@@ -111,7 +111,7 @@ int print_mroute(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
family = r->rtm_family == RTNL_FAMILY_IPMR ? AF_INET : AF_INET6;
if (n->nlmsg_type == RTM_DELROUTE)
- fprintf(fp, "Deleted ");
+ fprintf(fp, "[DELETED] ");
if (tb[RTA_SRC])
len = snprintf(obuf, sizeof(obuf),
diff --git a/ip/ipneigh.c b/ip/ipneigh.c
index 71a4100..a15ae10 100644
--- a/ip/ipneigh.c
+++ b/ip/ipneigh.c
@@ -251,9 +251,9 @@ int print_neigh(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
}
if (n->nlmsg_type == RTM_DELNEIGH)
- fprintf(fp, "delete ");
+ fprintf(fp, "[DELETED] ");
else if (n->nlmsg_type == RTM_GETNEIGH)
- fprintf(fp, "miss ");
+ fprintf(fp, "[MISS] ");
if (tb[NDA_DST]) {
fprintf(fp, "%s ",
format_host(r->ndm_family,
diff --git a/ip/ipnetns.c b/ip/ipnetns.c
index 90a496f..d8f217f 100644
--- a/ip/ipnetns.c
+++ b/ip/ipnetns.c
@@ -504,9 +504,9 @@ static int netns_monitor(int argc, char **argv)
(char *)event < &buf[len];
event = (struct inotify_event *)((char *)event + sizeof(*event) + event->len)) {
if (event->mask & IN_CREATE)
- printf("add %s\n", event->name);
+ printf("[NEW] %s\n", event->name);
if (event->mask & IN_DELETE)
- printf("delete %s\n", event->name);
+ printf("[DELETED] %s\n", event->name);
}
}
return 0;
diff --git a/ip/iproute.c b/ip/iproute.c
index d77b1e3..5288a5d 100644
--- a/ip/iproute.c
+++ b/ip/iproute.c
@@ -331,7 +331,7 @@ int print_route(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
}
if (n->nlmsg_type == RTM_DELROUTE)
- fprintf(fp, "Deleted ");
+ fprintf(fp, "[DELETED] ");
if ((r->rtm_type != RTN_UNICAST || show_details > 0) && !filter.type)
fprintf(fp, "%s ", rtnl_rtntype_n2a(r->rtm_type, b1, sizeof(b1)));
diff --git a/ip/iprule.c b/ip/iprule.c
index 366878e..ff65f58 100644
--- a/ip/iprule.c
+++ b/ip/iprule.c
@@ -76,7 +76,7 @@ int print_rule(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
host_len = 80;
if (n->nlmsg_type == RTM_DELRULE)
- fprintf(fp, "Deleted ");
+ fprintf(fp, "[DELETED] ");
if (tb[FRA_PRIORITY])
fprintf(fp, "%u:\t", *(unsigned*)RTA_DATA(tb[FRA_PRIORITY]));
diff --git a/ip/tcp_metrics.c b/ip/tcp_metrics.c
index bbbb4cc..58d35fb 100644
--- a/ip/tcp_metrics.c
+++ b/ip/tcp_metrics.c
@@ -190,7 +190,7 @@ static int process_msg(const struct sockaddr_nl *who, struct nlmsghdr *n,
}
if (f.cmd & (CMD_DEL | CMD_FLUSH))
- fprintf(fp, "Deleted ");
+ fprintf(fp, "[DELETED] ");
fprintf(fp, "%s",
format_host(family, dlen, &daddr.data, abuf, sizeof(abuf)));
diff --git a/ip/xfrm_policy.c b/ip/xfrm_policy.c
index 2337d35..3547abe 100644
--- a/ip/xfrm_policy.c
+++ b/ip/xfrm_policy.c
@@ -519,11 +519,11 @@ int xfrm_policy_print(const struct sockaddr_nl *who, struct nlmsghdr *n,
return 0;
if (n->nlmsg_type == XFRM_MSG_DELPOLICY)
- fprintf(fp, "Deleted ");
+ fprintf(fp, "[DELETED] ");
else if (n->nlmsg_type == XFRM_MSG_UPDPOLICY)
- fprintf(fp, "Updated ");
+ fprintf(fp, "[UPDATED] ");
else if (n->nlmsg_type == XFRM_MSG_POLEXPIRE)
- fprintf(fp, "Expired ");
+ fprintf(fp, "[EXPIRED] ");
if (n->nlmsg_type == XFRM_MSG_DELPOLICY) {
//xfrm_policy_id_print();
diff --git a/ip/xfrm_state.c b/ip/xfrm_state.c
index fe7708e..4748292 100644
--- a/ip/xfrm_state.c
+++ b/ip/xfrm_state.c
@@ -864,11 +864,11 @@ int xfrm_state_print(const struct sockaddr_nl *who, struct nlmsghdr *n,
return 0;
if (n->nlmsg_type == XFRM_MSG_DELSA)
- fprintf(fp, "Deleted ");
+ fprintf(fp, "[DELETED] ");
else if (n->nlmsg_type == XFRM_MSG_UPDSA)
- fprintf(fp, "Updated ");
+ fprintf(fp, "[UPDATED] ");
else if (n->nlmsg_type == XFRM_MSG_EXPIRE)
- fprintf(fp, "Expired ");
+ fprintf(fp, "[EXPIRED] ");
if (n->nlmsg_type == XFRM_MSG_DELSA)
rta = XFRMSID_RTA(xsid);
diff --git a/tc/m_action.c b/tc/m_action.c
index 486123e..0e8cc74 100644
--- a/tc/m_action.c
+++ b/tc/m_action.c
@@ -362,15 +362,15 @@ int print_action(const struct sockaddr_nl *who,
if (n->nlmsg_type == RTM_DELACTION) {
if (n->nlmsg_flags & NLM_F_ROOT) {
- fprintf(fp, "Flushed table ");
+ fprintf(fp, "[FLUSHED] table ");
tab_flush = 1;
} else {
- fprintf(fp, "deleted action ");
+ fprintf(fp, "[DELETED] action ");
}
}
if (n->nlmsg_type == RTM_NEWACTION)
- fprintf(fp, "Added action ");
+ fprintf(fp, "[NEW] action ");
tc_print_action(fp, tb[TCA_ACT_TAB]);
return 0;
diff --git a/tc/tc_class.c b/tc/tc_class.c
index e56bf07..66c989b 100644
--- a/tc/tc_class.c
+++ b/tc/tc_class.c
@@ -182,7 +182,7 @@ int print_class(const struct sockaddr_nl *who,
}
if (n->nlmsg_type == RTM_DELTCLASS)
- fprintf(fp, "deleted ");
+ fprintf(fp, "[DELETED] ");
abuf[0] = 0;
if (t->tcm_handle) {
diff --git a/tc/tc_filter.c b/tc/tc_filter.c
index c3f2d5f..aee1f53 100644
--- a/tc/tc_filter.c
+++ b/tc/tc_filter.c
@@ -211,7 +211,7 @@ int print_filter(const struct sockaddr_nl *who,
}
if (n->nlmsg_type == RTM_DELTFILTER)
- fprintf(fp, "deleted ");
+ fprintf(fp, "[DELETED] ");
fprintf(fp, "filter ");
if (!filter_ifindex || filter_ifindex != t->tcm_ifindex)
diff --git a/tc/tc_qdisc.c b/tc/tc_qdisc.c
index e304858..193e720 100644
--- a/tc/tc_qdisc.c
+++ b/tc/tc_qdisc.c
@@ -228,7 +228,7 @@ int print_qdisc(const struct sockaddr_nl *who,
}
if (n->nlmsg_type == RTM_DELQDISC)
- fprintf(fp, "deleted ");
+ fprintf(fp, "[DELETED] ");
fprintf(fp, "qdisc %s %x: ", rta_getattr_str(tb[TCA_KIND]), t->tcm_handle>>16);
if (filter_ifindex == 0)
--
2.1.0
^ permalink raw reply related
* Re: [PATCH] flow-dissector: Fix alignment issue in __skb_flow_get_ports
From: Alexander Duyck @ 2014-10-10 16:50 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Laight, David Miller, alexander.duyck@gmail.com,
netdev@vger.kernel.org
In-Reply-To: <1412954973.9362.11.camel@edumazet-glaptop2.roam.corp.google.com>
On 10/10/2014 08:29 AM, Eric Dumazet wrote:
> On Fri, 2014-10-10 at 08:14 -0700, Alexander Duyck wrote:
>
>> I think you might be coming to this a little late. The igb and ixgbe
>> drivers had been working this way for a long time. We did a memcpy to
>> move the headers from the page and into the skb->data at an aligned
>> offset. In order to determine the length to memcpy we had a function
>> that could walk through the DMA aligned data to get the header length.
>> The function for that was replaced with the __skb_flow_dissect as it was
>> considered a duplication of code with the flow_dissection functions.
>> However that is obviously not the case now that we are hitting these
>> alignment issues.
>>
>> The question I have in all this is do I push forward and make
>> __skb_flow_dissect work with unaligned accesses, or do I back off and
>> put something equivilent to igb/ixgbe_get_headlen functions in the
>> kernel in order to deal with the unaligned accesses as they had no
>> issues with them since they were only concerned with getting the header
>> length and kept all accesses 16b aligned.
>>
> I see nothing wrong dealing with unaligned accesses, as these helpers
> are nop on x86 or CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y arches.
Still it means possibly hurting performance on those platforms that
don't have it defined.
If I just use get_unaligned that is pretty easy in terms of cleanup for
the ports and IPv4 addresses, the IPv6 will still be a significant
hurdle to overcome though.
Thanks,
Alex
^ permalink raw reply
* Re: [PATCH 1/1] Checkpatch: coding style errors in Nvidia ethernet driver
From: Akshay Sarode @ 2014-10-10 16:45 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev, linux-kernel
In-Reply-To: <1412953387.8770.23.camel@joe-AO725>
On Fri, Oct 10, 2014 at 08:03:07AM -0700, Joe Perches wrote:
> On Fri, 2014-10-10 at 13:31 +0530, Akshay Sarode wrote:
> > ERROR: "foo* bar" should be "foo *bar"
> > ERROR: do not initialise statics to 0 or NULL
> > CHECK: spinlock_t definition without comment
> > Signed-off-by: Akshay Sarode <akshaysarode21@gmail.com>
> []
> > diff --git a/drivers/net/ethernet/nvidia/forcedeth.c b/drivers/net/ethernet/nvidia/forcedeth.c
> []
> > @@ -911,12 +913,18 @@ enum {
> []
> > /*
> > * Debug output control for tx_timeout
> > */
> > -static bool debug_tx_timeout = false;
> > +enum {
> > + NV_DEBUG_TX_TIMEOUT_DISABLED,
> > + NV_DEBUG_TX_TIMEOUT_ENABLED
> > +};
> > +
> > +static bool debug_tx_timeout = NV_DEBUG_TX_TIMEOUT_DISABLED;
>
> Adding this enum is not useful.
>
Sorry, If I may have not checked the code properly. I am a newbie here and I was hoping to start with checking coding styles.
I'll check again. Also there are a whole lot of warnings for line over 80 characters.
Regards,
Akshay
^ permalink raw reply
* Re: [PATCH] flow-dissector: Fix alignment issue in __skb_flow_get_ports
From: David Miller @ 2014-10-10 16:41 UTC (permalink / raw)
To: eric.dumazet; +Cc: David.Laight, alexander.h.duyck, alexander.duyck, netdev
In-Reply-To: <1412955219.9362.13.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 10 Oct 2014 08:33:39 -0700
> On Fri, 2014-10-10 at 14:57 +0000, David Laight wrote:
>
>> I think there is code to copy the IP and TCP headers to aligned memory
>> before they are parsed.
>
> There is no such thing. You are here on netdev list, please read the
> code before doing such claims.
+1
^ permalink raw reply
* Re: [PATCH net 1/3] net: bcmgenet: fix off-by-one in incrementing read pointer
From: Florian Fainelli @ 2014-10-10 16:41 UTC (permalink / raw)
To: Petri Gynther; +Cc: netdev, David Miller, jaedon.shin
In-Reply-To: <CAGXr9JHBVW9rOiSUCCsVnYp73OPdyynP35xiAnKjRsVCf8fK9Q@mail.gmail.com>
On 10/09/2014 11:01 PM, Petri Gynther wrote:
> Hi Florian,
>
> On Thu, Oct 9, 2014 at 6:06 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>> Commit b629be5c8399d7c423b92135eb43a86c924d1cbc ("net: bcmgenet: check
>> harder for out of memory conditions") moved the increment of the local
>> read pointer *before* reading from the hardware descriptor using
>> dmadesc_get_length_status(), which creates an off-by-one situation.
>>
>> Fix this by moving again the read_ptr increment after we have read the
>> hardware descriptor to get both the control block and the read pointer
>> back in sync.
>>
>> Fixes: b629be5c8399 ("net: bcmgenet: check harder for out of memory conditions")
>> Reported-by: Jaedon Shin <jaedon.shin@gmail.com>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> drivers/net/ethernet/broadcom/genet/bcmgenet.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>> index fff2634b6f34..f1bcebcbba80 100644
>> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>> @@ -1287,9 +1287,6 @@ static unsigned int bcmgenet_desc_rx(struct bcmgenet_priv *priv,
>>
>> rxpktprocessed++;
>>
>> - priv->rx_read_ptr++;
>> - priv->rx_read_ptr &= (priv->num_rx_bds - 1);
>> -
>
> Wouldn't it be better to move the three lines:
> rxpktprocessed++;
> priv->rx_read_ptr++;
> priv->rx_read_ptr &= (priv->num_rx_bds - 1)
>
> as the last lines of the while-loop, after the CB refill?
That's basically what Jaedon did in his first patch, I don't have strong
objections in doing that if you think that makes it look clearer.
>
> -- Petri
>
>
>> /* We do not have a backing SKB, so we do not have a
>> * corresponding DMA mapping for this incoming packet since
>> * bcmgenet_rx_refill always either has both skb and mapping or
>> @@ -1332,6 +1329,9 @@ static unsigned int bcmgenet_desc_rx(struct bcmgenet_priv *priv,
>> __func__, p_index, priv->rx_c_index,
>> priv->rx_read_ptr, dma_length_status);
>>
>> + priv->rx_read_ptr++;
>> + priv->rx_read_ptr &= (priv->num_rx_bds - 1);
>> +
>> if (unlikely(!(dma_flag & DMA_EOP) || !(dma_flag & DMA_SOP))) {
>> netif_err(priv, rx_status, dev,
>> "dropping fragmented packet!\n");
>> --
>> 1.9.1
>>
^ permalink raw reply
* Re: [PATCH v2] net/phy: micrel: Add clock support for KSZ8021/KSZ8031
From: Florian Fainelli @ 2014-10-10 16:38 UTC (permalink / raw)
To: Sascha Hauer; +Cc: netdev, linux-kernel, kernel
In-Reply-To: <1412927285-6809-1-git-send-email-s.hauer@pengutronix.de>
On 10/10/2014 12:48 AM, Sascha Hauer wrote:
> The KSZ8021 and KSZ8031 support RMII reference input clocks of 25MHz
> and 50MHz. Both PHYs differ in the default frequency they expect
> after reset. If this differs from the actual input clock, then
> register 0x1f bit 7 must be changed.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
>
> Changes since v1:
>
> - Move clock handling to the probe callback
> - Bail out with an error for invalid clock rates
>
> Documentation/devicetree/bindings/net/micrel.txt | 6 +++++
> drivers/net/phy/micrel.c | 31 ++++++++++++++++++++++--
> include/linux/micrel_phy.h | 1 +
> 3 files changed, 36 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/micrel.txt b/Documentation/devicetree/bindings/net/micrel.txt
> index 98a3e61..e1d99b9 100644
> --- a/Documentation/devicetree/bindings/net/micrel.txt
> +++ b/Documentation/devicetree/bindings/net/micrel.txt
> @@ -16,3 +16,9 @@ Optional properties:
> KSZ8051: register 0x1f, bits 5..4
>
> See the respective PHY datasheet for the mode values.
> +
> + - clocks, clock-names: contains clocks according to the common clock bindings.
> +
> + supported clocks:
> + - KSZ8021, KSZ8031: "rmii-ref": The RMII refence input clock. Used
> + to determine the XI input clock.
> diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
> index 011dbda..492435f 100644
> --- a/drivers/net/phy/micrel.c
> +++ b/drivers/net/phy/micrel.c
> @@ -26,6 +26,7 @@
> #include <linux/phy.h>
> #include <linux/micrel_phy.h>
> #include <linux/of.h>
> +#include <linux/clk.h>
>
> /* Operation Mode Strap Override */
> #define MII_KSZPHY_OMSO 0x16
> @@ -72,9 +73,12 @@ static int ksz_config_flags(struct phy_device *phydev)
> {
> int regval;
>
> - if (phydev->dev_flags & MICREL_PHY_50MHZ_CLK) {
> + if (phydev->dev_flags & (MICREL_PHY_50MHZ_CLK | MICREL_PHY_25MHZ_CLK)) {
> regval = phy_read(phydev, MII_KSZPHY_CTRL);
> - regval |= KSZ8051_RMII_50MHZ_CLK;
> + if (phydev->dev_flags & MICREL_PHY_50MHZ_CLK)
> + regval |= KSZ8051_RMII_50MHZ_CLK;
> + else
> + regval &= ~KSZ8051_RMII_50MHZ_CLK;
> return phy_write(phydev, MII_KSZPHY_CTRL, regval);
> }
> return 0;
> @@ -440,6 +444,27 @@ ksz9021_wr_mmd_phyreg(struct phy_device *phydev, int ptrad, int devnum,
> {
> }
>
> +static int ksz8021_probe(struct phy_device *phydev)
> +{
> + struct clk *clk;
> +
> + clk = devm_clk_get(&phydev->dev, "rmii-ref");
> + if (!IS_ERR(clk)) {
> + unsigned long rate = clk_get_rate(clk);
> +
> + if (rate > 24500000 && rate < 25500000) {
> + phydev->dev_flags |= MICREL_PHY_25MHZ_CLK;
> + } else if (rate > 49500000 && rate < 50500000) {
> + phydev->dev_flags |= MICREL_PHY_50MHZ_CLK;
> + } else {
> + dev_err(&phydev->dev, "Clock rate out of range: %ld\n", rate);
> + return -EINVAL;
> + }
> + }
> +
> + return 0;
> +}
> +
> static struct phy_driver ksphy_driver[] = {
> {
> .phy_id = PHY_ID_KS8737,
> @@ -462,6 +487,7 @@ static struct phy_driver ksphy_driver[] = {
> .features = (PHY_BASIC_FEATURES | SUPPORTED_Pause |
> SUPPORTED_Asym_Pause),
> .flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
> + .probe = ksz8021_probe,
> .config_init = ksz8021_config_init,
> .config_aneg = genphy_config_aneg,
> .read_status = genphy_read_status,
> @@ -477,6 +503,7 @@ static struct phy_driver ksphy_driver[] = {
> .features = (PHY_BASIC_FEATURES | SUPPORTED_Pause |
> SUPPORTED_Asym_Pause),
> .flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
> + .probe = ksz8021_probe,
> .config_init = ksz8021_config_init,
> .config_aneg = genphy_config_aneg,
> .read_status = genphy_read_status,
> diff --git a/include/linux/micrel_phy.h b/include/linux/micrel_phy.h
> index 2e5b194..53d33de 100644
> --- a/include/linux/micrel_phy.h
> +++ b/include/linux/micrel_phy.h
> @@ -37,6 +37,7 @@
>
> /* struct phy_device dev_flags definitions */
> #define MICREL_PHY_50MHZ_CLK 0x00000001
> +#define MICREL_PHY_25MHZ_CLK 0x00000002
>
> #define MICREL_KSZ9021_EXTREG_CTRL 0xB
> #define MICREL_KSZ9021_EXTREG_DATA_WRITE 0xC
>
^ permalink raw reply
* RE: [PATCH] flow-dissector: Fix alignment issue in __skb_flow_get_ports
From: David Laight @ 2014-10-10 16:30 UTC (permalink / raw)
To: 'Eric Dumazet'
Cc: 'alexander.h.duyck@redhat.com', David Miller,
alexander.duyck@gmail.com, netdev@vger.kernel.org
In-Reply-To: <1412955219.9362.13.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> Sent: 10 October 2014 16:34
> To: David Laight
> Cc: 'alexander.h.duyck@redhat.com'; David Miller; alexander.duyck@gmail.com; netdev@vger.kernel.org
> Subject: Re: [PATCH] flow-dissector: Fix alignment issue in __skb_flow_get_ports
>
> On Fri, 2014-10-10 at 14:57 +0000, David Laight wrote:
>
> > I think there is code to copy the IP and TCP headers to aligned memory
> > before they are parsed.
>
> There is no such thing. You are here on netdev list, please read the
> code before doing such claims.
I did say 'I think'...
I must be thinking of some similar code somewhere else.
Possibly just the code that ensures the header isn't fragmented.
> > > The problem is the igb / ixgbe / fm10k hardware doesn't have a means of
> > > inserting padding from its side...
> >
> > Shoot the hardware engineers.
> >
> > You aren't going to get the performance you expect from a 10Ge card
> > unless the rx buffers are 'correctly' aligned.
>
> That is simply not true on current x86 cpus. They simply dont care at
> all.
I was referring to using them on sparc64, not x86.
I know that current intel x86 cpu have support for misaligned 'rep movsd',
but I thought there was still a small cost (maybe one clock) for
single word transfers.
So maybe they care 'just a little bit'.
> You cannot blame Intel for other arches.
True, but this does mean that you don't really want to use these adapters
on a system that can't to unaligned accesses.
David
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox