* [net-next 8/8] ixgbe: remove global reset to the MAC
From: Jeff Kirsher @ 2011-09-21 10:12 UTC (permalink / raw)
To: davem; +Cc: Emil Tantilov, netdev, gospo, Jeff Kirsher
In-Reply-To: <1316599974-23205-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Emil Tantilov <emil.s.tantilov@intel.com>
Reloading FW during resets can cause issues. Remove the full reset
as it is not needed.
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c | 19 ++-----------------
1 files changed, 2 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c
index 84bb51d..96e0b20 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c
@@ -93,10 +93,8 @@ static s32 ixgbe_setup_mac_link_X540(struct ixgbe_hw *hw,
**/
static s32 ixgbe_reset_hw_X540(struct ixgbe_hw *hw)
{
- ixgbe_link_speed link_speed;
s32 status;
u32 ctrl, i;
- bool link_up = false;
/* Call adapter stop to disable tx/rx and clear interrupts */
status = hw->mac.ops.stop_adapter(hw);
@@ -107,19 +105,7 @@ static s32 ixgbe_reset_hw_X540(struct ixgbe_hw *hw)
ixgbe_clear_tx_pending(hw);
mac_reset_top:
- /*
- * Issue global reset to the MAC. Needs to be SW reset if link is up.
- * If link reset is used when link is up, it might reset the PHY when
- * mng is using it. If link is down or the flag to force full link
- * reset is set, then perform link reset.
- */
- ctrl = IXGBE_CTRL_LNK_RST;
- if (!hw->force_full_reset) {
- hw->mac.ops.check_link(hw, &link_speed, &link_up, false);
- if (link_up)
- ctrl = IXGBE_CTRL_RST;
- }
-
+ ctrl = IXGBE_CTRL_RST;
ctrl |= IXGBE_READ_REG(hw, IXGBE_CTRL);
IXGBE_WRITE_REG(hw, IXGBE_CTRL, ctrl);
IXGBE_WRITE_FLUSH(hw);
@@ -136,8 +122,7 @@ mac_reset_top:
status = IXGBE_ERR_RESET_FAILED;
hw_dbg(hw, "Reset polling failed to complete.\n");
}
-
- msleep(50);
+ msleep(100);
/*
* Double resets are required for recovery from certain error
--
1.7.6.2
^ permalink raw reply related
* [patch] usbnet: add timestamping support
From: Michael Riesch @ 2011-09-21 10:11 UTC (permalink / raw)
To: netdev; +Cc: davem, Oliver Neukum
In order to make USB-to-Ethernet-adapters (depending on usbnet) support
time stamping, the "skb_defer_rx_timestamp" and "skb_tx_timestamp"
function calls are added.
I considered to put these calls between #ifdef's to make them dependent
on CONFIG_NETWORK_PHY_TIMESTAMPING. I decided not to do so because except
the check whether the current packet is a PTP packet (and this check
should be fast) no overhead occurs. But let me know your opinion about
that one.
Looking forward to your comments,
Michael
Signed-off-by: Michael Riesch <michael@riesch.at>
---
drivers/net/usb/usbnet.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index ce395fe..cdb9588 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -238,6 +238,10 @@ void usbnet_skb_return (struct usbnet *dev,
struct sk_buff *skb)
netif_dbg(dev, rx_status, dev->net, "< rx, len %zu, type 0x%x\n",
skb->len + sizeof (struct ethhdr), skb->protocol);
memset (skb->cb, 0, sizeof (struct skb_data));
+
+ if (skb_defer_rx_timestamp(skb))
+ return;
+
status = netif_rx (skb);
if (status != NET_RX_SUCCESS)
netif_dbg(dev, rx_err, dev->net,
@@ -1053,6 +1057,8 @@ netdev_tx_t usbnet_start_xmit (struct sk_buff *skb,
unsigned long flags;
int retval;
+ skb_tx_timestamp(skb);
+
// some devices want funky USB-level framing, for
// win32 driver (usually) and/or hardware quirks
if (info->tx_fixup) {
--
1.7.0.4
^ permalink raw reply related
* [PATCH v2 0/3] add fec support for imx6q
From: Shawn Guo @ 2011-09-21 11:10 UTC (permalink / raw)
To: David S. Miller
Cc: Francois Romieu, Lothar Waßmann, Troy Kisky, netdev,
linux-arm-kernel, patches
This series adds imx6q enet support. The imx6q enet is a derivative of
imx28 enet controller. It fixed the frame endian issue found on imx28,
and added 1 Gbps support.
Changes since v1:
* Fix typo pointed out by Francois Romieu
* Drop patch #3 in the v1
* Rebase on net-next tree
Thanks.
Shawn Guo (3):
net/fec: change phy-reset-gpio request warning to debug message
net/fec: fix fec1 check in fec_enet_mii_init()
net/fec: add imx6q enet support
drivers/net/ethernet/freescale/Kconfig | 9 ++--
drivers/net/ethernet/freescale/fec.c | 65 +++++++++++++++++++++++++-------
2 files changed, 55 insertions(+), 19 deletions(-)
^ permalink raw reply
* [PATCH v2 3/3] net/fec: add imx6q enet support
From: Shawn Guo @ 2011-09-21 11:10 UTC (permalink / raw)
To: David S. Miller
Cc: Francois Romieu, Lothar Waßmann, Troy Kisky, netdev,
linux-arm-kernel, patches, Shawn Guo
In-Reply-To: <1316603432-20032-1-git-send-email-shawn.guo@linaro.org>
The imx6q enet is a derivative of imx28 enet controller. It fixed
the frame endian issue found on imx28, and added 1 Gbps support.
It also fixes a typo on vendor name in Kconfig.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
drivers/net/ethernet/freescale/Kconfig | 9 ++---
drivers/net/ethernet/freescale/fec.c | 61 +++++++++++++++++++++++++------
2 files changed, 53 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/freescale/Kconfig b/drivers/net/ethernet/freescale/Kconfig
index 4dbe41f..1cf6716 100644
--- a/drivers/net/ethernet/freescale/Kconfig
+++ b/drivers/net/ethernet/freescale/Kconfig
@@ -7,7 +7,7 @@ config NET_VENDOR_FREESCALE
default y
depends on FSL_SOC || QUICC_ENGINE || CPM1 || CPM2 || PPC_MPC512x || \
M523x || M527x || M5272 || M528x || M520x || M532x || \
- IMX_HAVE_PLATFORM_FEC || MXS_HAVE_PLATFORM_FEC || \
+ ARCH_MXC || ARCH_MXS || \
(PPC_MPC52xx && PPC_BESTCOMM)
---help---
If you have a network (Ethernet) card belonging to this class, say Y
@@ -16,16 +16,15 @@ config NET_VENDOR_FREESCALE
Note that the answer to this question doesn't directly affect the
kernel: saying N will just cause the configurator to skip all
- the questions about IBM devices. If you say Y, you will be asked for
- your specific card in the following questions.
+ the questions about Freescale devices. If you say Y, you will be
+ asked for your specific card in the following questions.
if NET_VENDOR_FREESCALE
config FEC
bool "FEC ethernet controller (of ColdFire and some i.MX CPUs)"
depends on (M523x || M527x || M5272 || M528x || M520x || M532x || \
- IMX_HAVE_PLATFORM_FEC || MXS_HAVE_PLATFORM_FEC)
- default IMX_HAVE_PLATFORM_FEC || MXS_HAVE_PLATFORM_FEC if ARM
+ ARCH_MXC || ARCH_MXS)
select PHYLIB
---help---
Say Y here if you want to use the built-in 10/100 Fast ethernet
diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
index ca6f551..9a64ce8 100644
--- a/drivers/net/ethernet/freescale/fec.c
+++ b/drivers/net/ethernet/freescale/fec.c
@@ -18,7 +18,7 @@
* Bug fixes and cleanup by Philippe De Muyter (phdm@macqel.be)
* Copyright (c) 2004-2006 Macq Electronique SA.
*
- * Copyright (C) 2010 Freescale Semiconductor, Inc.
+ * Copyright (C) 2010-2011 Freescale Semiconductor, Inc.
*/
#include <linux/module.h>
@@ -72,6 +72,10 @@
#define FEC_QUIRK_SWAP_FRAME (1 << 1)
/* Controller uses gasket */
#define FEC_QUIRK_USE_GASKET (1 << 2)
+/* Controller has GBIT support */
+#define FEC_QUIRK_HAS_GBIT (1 << 3)
+/* Controller's phy_speed bit field need to minus one */
+#define FEC_QUIRK_PHY_SPEED_MINUS_ONE (1 << 4)
static struct platform_device_id fec_devtype[] = {
{
@@ -88,6 +92,10 @@ static struct platform_device_id fec_devtype[] = {
.name = "imx28-fec",
.driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_SWAP_FRAME,
}, {
+ .name = "imx6q-fec",
+ .driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT |
+ FEC_QUIRK_PHY_SPEED_MINUS_ONE,
+ }, {
/* sentinel */
}
};
@@ -97,12 +105,14 @@ enum imx_fec_type {
IMX25_FEC = 1, /* runs on i.mx25/50/53 */
IMX27_FEC, /* runs on i.mx27/35/51 */
IMX28_FEC,
+ IMX6Q_FEC,
};
static const struct of_device_id fec_dt_ids[] = {
{ .compatible = "fsl,imx25-fec", .data = &fec_devtype[IMX25_FEC], },
{ .compatible = "fsl,imx27-fec", .data = &fec_devtype[IMX27_FEC], },
{ .compatible = "fsl,imx28-fec", .data = &fec_devtype[IMX28_FEC], },
+ { .compatible = "fsl,imx6q-fec", .data = &fec_devtype[IMX6Q_FEC], },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, fec_dt_ids);
@@ -373,6 +383,7 @@ fec_restart(struct net_device *ndev, int duplex)
int i;
u32 temp_mac[2];
u32 rcntl = OPT_FRAME_SIZE | 0x04;
+ u32 ecntl = 0x2; /* ETHEREN */
/* Whack a reset. We should wait for this. */
writel(1, fep->hwp + FEC_ECNTRL);
@@ -442,18 +453,23 @@ fec_restart(struct net_device *ndev, int duplex)
/* Enable flow control and length check */
rcntl |= 0x40000000 | 0x00000020;
- /* MII or RMII */
- if (fep->phy_interface == PHY_INTERFACE_MODE_RMII)
+ /* RGMII, RMII or MII */
+ if (fep->phy_interface == PHY_INTERFACE_MODE_RGMII)
+ rcntl |= (1 << 6);
+ else if (fep->phy_interface == PHY_INTERFACE_MODE_RMII)
rcntl |= (1 << 8);
else
rcntl &= ~(1 << 8);
- /* 10M or 100M */
- if (fep->phy_dev && fep->phy_dev->speed == SPEED_100)
- rcntl &= ~(1 << 9);
- else
- rcntl |= (1 << 9);
-
+ /* 1G, 100M or 10M */
+ if (fep->phy_dev) {
+ if (fep->phy_dev->speed == SPEED_1000)
+ ecntl |= (1 << 5);
+ else if (fep->phy_dev->speed == SPEED_100)
+ rcntl &= ~(1 << 9);
+ else
+ rcntl |= (1 << 9);
+ }
} else {
#ifdef FEC_MIIGSK_ENR
if (id_entry->driver_data & FEC_QUIRK_USE_GASKET) {
@@ -478,8 +494,15 @@ fec_restart(struct net_device *ndev, int duplex)
}
writel(rcntl, fep->hwp + FEC_R_CNTRL);
+ if (id_entry->driver_data & FEC_QUIRK_ENET_MAC) {
+ /* enable ENET endian swap */
+ ecntl |= (1 << 8);
+ /* enable ENET store and forward mode */
+ writel(1 << 8, fep->hwp + FEC_X_WMRK);
+ }
+
/* And last, enable the transmit and receive processing */
- writel(2, fep->hwp + FEC_ECNTRL);
+ writel(ecntl, fep->hwp + FEC_ECNTRL);
writel(0, fep->hwp + FEC_R_DES_ACTIVE);
/* Enable interrupts we wish to service */
@@ -490,6 +513,8 @@ static void
fec_stop(struct net_device *ndev)
{
struct fec_enet_private *fep = netdev_priv(ndev);
+ const struct platform_device_id *id_entry =
+ platform_get_device_id(fep->pdev);
/* We cannot expect a graceful transmit stop without link !!! */
if (fep->link) {
@@ -504,6 +529,10 @@ fec_stop(struct net_device *ndev)
udelay(10);
writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);
writel(FEC_DEFAULT_IMASK, fep->hwp + FEC_IMASK);
+
+ /* We have to keep ENET enabled to have MII interrupt stay working */
+ if (id_entry->driver_data & FEC_QUIRK_ENET_MAC)
+ writel(2, fep->hwp + FEC_ECNTRL);
}
@@ -918,6 +947,8 @@ static int fec_enet_mdio_reset(struct mii_bus *bus)
static int fec_enet_mii_probe(struct net_device *ndev)
{
struct fec_enet_private *fep = netdev_priv(ndev);
+ const struct platform_device_id *id_entry =
+ platform_get_device_id(fep->pdev);
struct phy_device *phy_dev = NULL;
char mdio_bus_id[MII_BUS_ID_SIZE];
char phy_name[MII_BUS_ID_SIZE + 3];
@@ -949,14 +980,18 @@ static int fec_enet_mii_probe(struct net_device *ndev)
snprintf(phy_name, MII_BUS_ID_SIZE, PHY_ID_FMT, mdio_bus_id, phy_id);
phy_dev = phy_connect(ndev, phy_name, &fec_enet_adjust_link, 0,
- PHY_INTERFACE_MODE_MII);
+ fep->phy_interface);
if (IS_ERR(phy_dev)) {
printk(KERN_ERR "%s: could not attach to PHY\n", ndev->name);
return PTR_ERR(phy_dev);
}
/* mask with MAC supported features */
- phy_dev->supported &= PHY_BASIC_FEATURES;
+ if (id_entry->driver_data & FEC_QUIRK_HAS_GBIT)
+ phy_dev->supported &= PHY_GBIT_FEATURES;
+ else
+ phy_dev->supported &= PHY_BASIC_FEATURES;
+
phy_dev->advertising = phy_dev->supported;
fep->phy_dev = phy_dev;
@@ -1008,6 +1043,8 @@ static int fec_enet_mii_init(struct platform_device *pdev)
* Set MII speed to 2.5 MHz (= clk_get_rate() / 2 * phy_speed)
*/
fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 5000000) << 1;
+ if (id_entry->driver_data & FEC_QUIRK_PHY_SPEED_MINUS_ONE)
+ fep->phy_speed--;
writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);
fep->mii_bus = mdiobus_alloc();
--
1.7.4.1
^ permalink raw reply related
* [PATCH v2 1/3] net/fec: change phy-reset-gpio request warning to debug message
From: Shawn Guo @ 2011-09-21 11:10 UTC (permalink / raw)
To: David S. Miller
Cc: Francois Romieu, Lothar Waßmann, Troy Kisky, netdev,
linux-arm-kernel, patches, Shawn Guo
In-Reply-To: <1316603432-20032-1-git-send-email-shawn.guo@linaro.org>
FEC can work without a phy reset on some platforms, which means not
very platform necessarily have a phy-reset gpio encoded in device tree.
So it makes more sense to have the phy-reset-gpio request failure as
a debug message rather than a warning.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
drivers/net/ethernet/freescale/fec.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
index 158b82e..a057abf 100644
--- a/drivers/net/ethernet/freescale/fec.c
+++ b/drivers/net/ethernet/freescale/fec.c
@@ -1422,7 +1422,7 @@ static int __devinit fec_reset_phy(struct platform_device *pdev)
phy_reset = of_get_named_gpio(np, "phy-reset-gpios", 0);
err = gpio_request_one(phy_reset, GPIOF_OUT_INIT_LOW, "phy-reset");
if (err) {
- pr_warn("FEC: failed to get gpio phy-reset: %d\n", err);
+ pr_debug("FEC: failed to get gpio phy-reset: %d\n", err);
return err;
}
msleep(1);
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH v2 3/3] net/fec: add imx6q enet support
From: Fabio Estevam @ 2011-09-21 11:07 UTC (permalink / raw)
To: Shawn Guo
Cc: David S. Miller, patches, netdev, Troy Kisky, Francois Romieu,
linux-arm-kernel, Lothar Waßmann
In-Reply-To: <1316603432-20032-4-git-send-email-shawn.guo@linaro.org>
On Wed, Sep 21, 2011 at 8:10 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
...
> diff --git a/drivers/net/ethernet/freescale/Kconfig b/drivers/net/ethernet/freescale/Kconfig
> index 4dbe41f..1cf6716 100644
> --- a/drivers/net/ethernet/freescale/Kconfig
> +++ b/drivers/net/ethernet/freescale/Kconfig
> @@ -7,7 +7,7 @@ config NET_VENDOR_FREESCALE
> default y
> depends on FSL_SOC || QUICC_ENGINE || CPM1 || CPM2 || PPC_MPC512x || \
> M523x || M527x || M5272 || M528x || M520x || M532x || \
> - IMX_HAVE_PLATFORM_FEC || MXS_HAVE_PLATFORM_FEC || \
> + ARCH_MXC || ARCH_MXS || \
Do you need to get rid of IMX_HAVE_PLATFORM_FEC and MXS_HAVE_PLATFORM_FEC?
By doing that you are selecting FEC for SoCs that don´t have this
module such as MX1/MX21/MX31.
Regards,
Fabio Estevan
^ permalink raw reply
* Re: [patch] usbnet: add timestamping support
From: Michael Riesch @ 2011-09-21 11:09 UTC (permalink / raw)
To: netdev; +Cc: davem, Oliver Neukum
In-Reply-To: <20110921121151.Horde.2_LlPML8999Oebhn0-QlTpA@webmail.df.eu>
Quoting Michael Riesch <michael@riesch.at>:
> I considered to put these calls between #ifdef's to make them dependent
> on CONFIG_NETWORK_PHY_TIMESTAMPING. I decided not to do so because except
> the check whether the current packet is a PTP packet (and this check
> should be fast) no overhead occurs. But let me know your opinion about
> that one.
Come to think of it the #ifdef's are definitely unnecessary because these
functions are no-ops with CONFIG_NETWORK_PHY_TIMESTAMPING not set.
Regards,
Michael
^ permalink raw reply
* [PATCH v2 2/3] net/fec: fix fec1 check in fec_enet_mii_init()
From: Shawn Guo @ 2011-09-21 11:10 UTC (permalink / raw)
To: David S. Miller
Cc: patches, netdev, Troy Kisky, Francois Romieu, Shawn Guo,
linux-arm-kernel, Lothar Waßmann
In-Reply-To: <1316603432-20032-1-git-send-email-shawn.guo@linaro.org>
In function fec_enet_mii_init(), it uses non-zero pdev->id as part
of the condition to check the second fec instance (fec1). This works
before the driver supports device tree probe. But in case of device
tree probe, pdev->id is -1 which is also non-zero, so the logic becomes
broken when device tree probe gets supported.
The patch change the logic to check "pdev->id > 0" as the part of the
condition for identifying fec1.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
drivers/net/ethernet/freescale/fec.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
index a057abf..ca6f551 100644
--- a/drivers/net/ethernet/freescale/fec.c
+++ b/drivers/net/ethernet/freescale/fec.c
@@ -996,7 +996,7 @@ static int fec_enet_mii_init(struct platform_device *pdev)
* mdio interface in board design, and need to be configured by
* fec0 mii_bus.
*/
- if ((id_entry->driver_data & FEC_QUIRK_ENET_MAC) && pdev->id) {
+ if ((id_entry->driver_data & FEC_QUIRK_ENET_MAC) && pdev->id > 0) {
/* fec1 uses fec0 mii_bus */
fep->mii_bus = fec0_mii_bus;
return 0;
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH v2 3/3] net/fec: add imx6q enet support
From: Shawn Guo @ 2011-09-21 11:28 UTC (permalink / raw)
To: Fabio Estevam
Cc: Shawn Guo, David S. Miller, patches, netdev, Troy Kisky,
Francois Romieu, linux-arm-kernel, Lothar Waßmann
In-Reply-To: <CAOMZO5CzVj=sMhD24H0OQKqp2Z0XtHhkTX=kEp5oshKqTAJ4oA@mail.gmail.com>
On Wed, Sep 21, 2011 at 08:07:42AM -0300, Fabio Estevam wrote:
> On Wed, Sep 21, 2011 at 8:10 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
> ...
> > diff --git a/drivers/net/ethernet/freescale/Kconfig b/drivers/net/ethernet/freescale/Kconfig
> > index 4dbe41f..1cf6716 100644
> > --- a/drivers/net/ethernet/freescale/Kconfig
> > +++ b/drivers/net/ethernet/freescale/Kconfig
> > @@ -7,7 +7,7 @@ config NET_VENDOR_FREESCALE
> > default y
> > depends on FSL_SOC || QUICC_ENGINE || CPM1 || CPM2 || PPC_MPC512x || \
> > M523x || M527x || M5272 || M528x || M520x || M532x || \
> > - IMX_HAVE_PLATFORM_FEC || MXS_HAVE_PLATFORM_FEC || \
> > + ARCH_MXC || ARCH_MXS || \
>
> Do you need to get rid of IMX_HAVE_PLATFORM_FEC and MXS_HAVE_PLATFORM_FEC?
>
Yes, I do. We are moving to device tree, so the Kconfig symbol
IMX_HAVE_PLATFORM_FEC makes no sense any more, as the platform device
registration will be done by DT core according whether there is a FEC
node in device tree or not.
> By doing that you are selecting FEC for SoCs that don´t have this
> module such as MX1/MX21/MX31.
>
No. By doing that, FEC will not be selected for any SoCs by default.
You need to select it explicitly if you are building a platform with
FEC support.
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH] xfrm: Perform a replay check after return from async codepaths
From: Herbert Xu @ 2011-09-21 11:21 UTC (permalink / raw)
To: Steffen Klassert; +Cc: David Miller, netdev
In-Reply-To: <20110921093858.GW1808@secunet.com>
On Wed, Sep 21, 2011 at 11:38:58AM +0200, Steffen Klassert wrote:
> When asyncronous crypto algorithms are used, there might be many
> packets that passed the xfrm replay check, but the replay advance
> function is not called yet for these packets. So the replay check
> function would accept a replay of all of these packets. Also the
> system might crash if there are more packets in async processing
> than the size of the anti replay window, because the replay advance
> function would try to update the replay window beyond the bounds.
>
> This pach adds a second replay check after resuming from the async
> processing to fix these issues.
>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Actually why does this matter? For a single SA, the processing
in xfrm_input should be completely synchronous, even when you're
using asynchronous algorithms.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2 1/3] net/fec: change phy-reset-gpio request warning to debug message
From: Wolfram Sang @ 2011-09-21 11:25 UTC (permalink / raw)
To: Shawn Guo
Cc: David S. Miller, patches, netdev, Troy Kisky, Francois Romieu,
linux-arm-kernel, Lothar Waßmann
In-Reply-To: <1316603432-20032-2-git-send-email-shawn.guo@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1772 bytes --]
Hi Shawn,
On Wed, Sep 21, 2011 at 07:10:30PM +0800, Shawn Guo wrote:
> FEC can work without a phy reset on some platforms, which means not
> very platform necessarily have a phy-reset gpio encoded in device tree.
> So it makes more sense to have the phy-reset-gpio request failure as
> a debug message rather than a warning.
Or remove it entirely?
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
> drivers/net/ethernet/freescale/fec.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
> index 158b82e..a057abf 100644
> --- a/drivers/net/ethernet/freescale/fec.c
> +++ b/drivers/net/ethernet/freescale/fec.c
> @@ -1422,7 +1422,7 @@ static int __devinit fec_reset_phy(struct platform_device *pdev)
> phy_reset = of_get_named_gpio(np, "phy-reset-gpios", 0);
> err = gpio_request_one(phy_reset, GPIOF_OUT_INIT_LOW, "phy-reset");
> if (err) {
> - pr_warn("FEC: failed to get gpio phy-reset: %d\n", err);
> + pr_debug("FEC: failed to get gpio phy-reset: %d\n", err);
> return err;
I also wanted to suggested to drop returning the error code, since it is
not an error anymore, strictly speaking. Then I noticed that the caller
does not check the error code. So, this could be added or turn the
function to void?
> }
> msleep(1);
> --
> 1.7.4.1
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/3] net/fec: add imx6q enet support
From: Wolfram Sang @ 2011-09-21 11:32 UTC (permalink / raw)
To: Shawn Guo
Cc: David S. Miller, patches, netdev, Troy Kisky, Francois Romieu,
linux-arm-kernel, Lothar Waßmann
In-Reply-To: <1316603432-20032-4-git-send-email-shawn.guo@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 763 bytes --]
> +/* Controller has GBIT support */
> +#define FEC_QUIRK_HAS_GBIT (1 << 3)
Heh, this is not really a quirk, but a nice feature :) I think we can
drop QUIRK if we see driver_data more as "flags" instead of "quirks"?
Minor, though.
> MODULE_DEVICE_TABLE(of, fec_dt_ids);
> @@ -373,6 +383,7 @@ fec_restart(struct net_device *ndev, int duplex)
> int i;
> u32 temp_mac[2];
> u32 rcntl = OPT_FRAME_SIZE | 0x04;
> + u32 ecntl = 0x2; /* ETHEREN */
Also minor, but the patch looks like a good oportunity to start
replacing magic values with proper defines?
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/3] net/fec: add imx6q enet support
From: Shawn Guo @ 2011-09-21 11:58 UTC (permalink / raw)
To: Wolfram Sang
Cc: Shawn Guo, David S. Miller, patches, netdev, Troy Kisky,
Francois Romieu, linux-arm-kernel, Lothar Waßmann
In-Reply-To: <20110921113239.GF1966@pengutronix.de>
On Wed, Sep 21, 2011 at 01:32:39PM +0200, Wolfram Sang wrote:
>
> > +/* Controller has GBIT support */
> > +#define FEC_QUIRK_HAS_GBIT (1 << 3)
>
> Heh, this is not really a quirk, but a nice feature :) I think we can
> drop QUIRK if we see driver_data more as "flags" instead of "quirks"?
> Minor, though.
>
As you have told, all these FEC_QUIRK_* are just flags actually. The
name was pick to keep the consistency, as they are all used for the
same purpose.
> > MODULE_DEVICE_TABLE(of, fec_dt_ids);
> > @@ -373,6 +383,7 @@ fec_restart(struct net_device *ndev, int duplex)
> > int i;
> > u32 temp_mac[2];
> > u32 rcntl = OPT_FRAME_SIZE | 0x04;
> > + u32 ecntl = 0x2; /* ETHEREN */
>
> Also minor, but the patch looks like a good oportunity to start
> replacing magic values with proper defines?
>
There are already so many magic numbers. It really deserves a separated
patch.
I heard that Uwe had a plan to do that some time ago. He gives up
now? :)
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH v2 1/3] net/fec: change phy-reset-gpio request warning to debug message
From: Shawn Guo @ 2011-09-21 12:03 UTC (permalink / raw)
To: Wolfram Sang
Cc: Shawn Guo, David S. Miller, patches, netdev, Troy Kisky,
Francois Romieu, linux-arm-kernel, Lothar Waßmann
In-Reply-To: <20110921112555.GE1966@pengutronix.de>
On Wed, Sep 21, 2011 at 01:25:55PM +0200, Wolfram Sang wrote:
> Hi Shawn,
>
> On Wed, Sep 21, 2011 at 07:10:30PM +0800, Shawn Guo wrote:
> > FEC can work without a phy reset on some platforms, which means not
> > very platform necessarily have a phy-reset gpio encoded in device tree.
> > So it makes more sense to have the phy-reset-gpio request failure as
> > a debug message rather than a warning.
>
> Or remove it entirely?
>
I would like to keep it. When people want to debug at this point, they
do not need to type the debug message.
> >
> > Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> > ---
> > drivers/net/ethernet/freescale/fec.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
> > index 158b82e..a057abf 100644
> > --- a/drivers/net/ethernet/freescale/fec.c
> > +++ b/drivers/net/ethernet/freescale/fec.c
> > @@ -1422,7 +1422,7 @@ static int __devinit fec_reset_phy(struct platform_device *pdev)
> > phy_reset = of_get_named_gpio(np, "phy-reset-gpios", 0);
> > err = gpio_request_one(phy_reset, GPIOF_OUT_INIT_LOW, "phy-reset");
> > if (err) {
> > - pr_warn("FEC: failed to get gpio phy-reset: %d\n", err);
> > + pr_debug("FEC: failed to get gpio phy-reset: %d\n", err);
> > return err;
>
> I also wanted to suggested to drop returning the error code, since it is
> not an error anymore, strictly speaking. Then I noticed that the caller
> does not check the error code. So, this could be added or turn the
> function to void?
>
To me, keep the return value as integer is more scalable. Someday,
someone need to add more stuff in the function, or want to improve
the caller to check return value, it plays.
Regards,
Shawn
> > }
> > msleep(1);
> > --
^ permalink raw reply
* Re: [PATCH] xfrm: Perform a replay check after return from async codepaths
From: Steffen Klassert @ 2011-09-21 11:57 UTC (permalink / raw)
To: Herbert Xu; +Cc: David Miller, netdev
In-Reply-To: <20110921112158.GB18648@gondor.apana.org.au>
On Wed, Sep 21, 2011 at 09:21:58PM +1000, Herbert Xu wrote:
> On Wed, Sep 21, 2011 at 11:38:58AM +0200, Steffen Klassert wrote:
> > When asyncronous crypto algorithms are used, there might be many
> > packets that passed the xfrm replay check, but the replay advance
> > function is not called yet for these packets. So the replay check
> > function would accept a replay of all of these packets. Also the
> > system might crash if there are more packets in async processing
> > than the size of the anti replay window, because the replay advance
> > function would try to update the replay window beyond the bounds.
> >
> > This pach adds a second replay check after resuming from the async
> > processing to fix these issues.
> >
> > Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
>
> Actually why does this matter? For a single SA, the processing
> in xfrm_input should be completely synchronous, even when you're
> using asynchronous algorithms.
>
Well, I've got pretty reproduceable crashes when the sender of
the IPsec packets introduces reorder, that's why I noticed this.
The problem is, that the replay check function is called before
the asynchronous crypto processing and the replay advance function
is called after resume from the asynchronous processing. So
we can submit multiple packets to the crypto layer without
updating the replay window. This means that the replay check
function accepts packets that should have been dropped, because
they are reordered and more than 'replay window size' packets
to late. This leads to a crash as we try to update the replay
window beyond the allocated bounds.
^ permalink raw reply
* Re: [PATCH v2 1/3] net/fec: change phy-reset-gpio request warning to debug message
From: Wolfram Sang @ 2011-09-21 12:11 UTC (permalink / raw)
To: Shawn Guo
Cc: Shawn Guo, David S. Miller, patches, netdev, Troy Kisky,
Francois Romieu, linux-arm-kernel, Lothar Waßmann
In-Reply-To: <20110921120341.GG28907@S2100-06.ap.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 1890 bytes --]
On Wed, Sep 21, 2011 at 08:03:42PM +0800, Shawn Guo wrote:
> On Wed, Sep 21, 2011 at 01:25:55PM +0200, Wolfram Sang wrote:
> > Hi Shawn,
> >
> > On Wed, Sep 21, 2011 at 07:10:30PM +0800, Shawn Guo wrote:
> > > FEC can work without a phy reset on some platforms, which means not
> > > very platform necessarily have a phy-reset gpio encoded in device tree.
> > > So it makes more sense to have the phy-reset-gpio request failure as
> > > a debug message rather than a warning.
> >
> > Or remove it entirely?
> >
> I would like to keep it. When people want to debug at this point, they
> do not need to type the debug message.
I just think the message might be confusing in case you don't need the
gpio, because then failing is expected behaviour. For those platforms,
it is not even an error then, so you must drop returning the error. To
be very precise, you should check of_get_named_gpio() and return if no
gpio is specified. Then, you can distinguish that case from problems
when getting the GPIO.
> > I also wanted to suggested to drop returning the error code, since it is
> > not an error anymore, strictly speaking. Then I noticed that the caller
> > does not check the error code. So, this could be added or turn the
> > function to void?
> >
> To me, keep the return value as integer is more scalable. Someday,
> someone need to add more stuff in the function, or want to improve
> the caller to check return value, it plays.
I agree that keeping it int is way better. But why not add it now to
keep things proper and tested? If this patch gets accepted as it is and
later someone else will add error checking to the caller, your platform
will lose FEC support as a regression.
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] xfrm: Perform a replay check after return from async codepaths
From: Herbert Xu @ 2011-09-21 12:24 UTC (permalink / raw)
To: Steffen Klassert; +Cc: David Miller, netdev
In-Reply-To: <20110921115727.GX1808@secunet.com>
On Wed, Sep 21, 2011 at 01:57:27PM +0200, Steffen Klassert wrote:
>
> Well, I've got pretty reproduceable crashes when the sender of
> the IPsec packets introduces reorder, that's why I noticed this.
>
> The problem is, that the replay check function is called before
> the asynchronous crypto processing and the replay advance function
> is called after resume from the asynchronous processing. So
> we can submit multiple packets to the crypto layer without
> updating the replay window. This means that the replay check
> function accepts packets that should have been dropped, because
> they are reordered and more than 'replay window size' packets
> to late. This leads to a crash as we try to update the replay
> window beyond the allocated bounds.
OK I see what you mean now.
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Thanks!
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2 3/3] net/fec: add imx6q enet support
From: Wolfram Sang @ 2011-09-21 12:26 UTC (permalink / raw)
To: Shawn Guo
Cc: Shawn Guo, David S. Miller, patches, netdev, Troy Kisky,
Francois Romieu, linux-arm-kernel, Lothar Waßmann
In-Reply-To: <20110921115821.GF28907@S2100-06.ap.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 1449 bytes --]
On Wed, Sep 21, 2011 at 07:58:22PM +0800, Shawn Guo wrote:
> On Wed, Sep 21, 2011 at 01:32:39PM +0200, Wolfram Sang wrote:
> >
> > > +/* Controller has GBIT support */
> > > +#define FEC_QUIRK_HAS_GBIT (1 << 3)
> >
> > Heh, this is not really a quirk, but a nice feature :) I think we can
> > drop QUIRK if we see driver_data more as "flags" instead of "quirks"?
> > Minor, though.
> >
> As you have told, all these FEC_QUIRK_* are just flags actually. The
> name was pick to keep the consistency, as they are all used for the
> same purpose.
I think introducing FEC_FEATURE_HAS_GBIT would be consistent enough, but
as I said, I don't mind much.
> > Also minor, but the patch looks like a good oportunity to start
> > replacing magic values with proper defines?
> >
> There are already so many magic numbers. It really deserves a separated
> patch.
That is the other possibility, yes. Which sadly never happened.
> I heard that Uwe had a plan to do that some time ago. He gives up
> now? :)
I don't know about this case. Also, it is not about blaming here. It is
totally okay for you to say that you don't want to change your patch to
start replacing the magic values. I mainly wanted to point out the
oportunity here.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Hello my love, My name is jane ferguson,i come across and read through your profile today and i became interested in you,i will also like to know you the more,and i want you to send an e-mail to my e-mail address so i can give you my picture for you to know whom i am and for the both of us to know each other very well and better in life,and we can achieve it in future because ture love and feeling means alot in future.Here is my private e-mail address you can contact me with it.(jane.ferguson@gala.net )I am waiting for your mail to my e-mail address above and aslo, Remember the distance or colour does not matter but love,feeling,e-motions and sympathetic love matters alot in life. Thanks,and i promise to be honest and to keep a very good relationship with you. jane. ja ne.ferguson@gala.net
From: jane ferguson @ 2011-09-21 12:24 UTC (permalink / raw)
^ permalink raw reply
* Re: [PATCH v2 1/3] net/fec: change phy-reset-gpio request warning to debug message
From: Shawn Guo @ 2011-09-21 12:44 UTC (permalink / raw)
To: Wolfram Sang
Cc: Shawn Guo, David S. Miller, patches, netdev, Troy Kisky,
Francois Romieu, linux-arm-kernel, Lothar Waßmann
In-Reply-To: <20110921121159.GG1966@pengutronix.de>
On Wed, Sep 21, 2011 at 02:11:59PM +0200, Wolfram Sang wrote:
> On Wed, Sep 21, 2011 at 08:03:42PM +0800, Shawn Guo wrote:
> > On Wed, Sep 21, 2011 at 01:25:55PM +0200, Wolfram Sang wrote:
> > > Hi Shawn,
> > >
> > > On Wed, Sep 21, 2011 at 07:10:30PM +0800, Shawn Guo wrote:
> > > > FEC can work without a phy reset on some platforms, which means not
> > > > very platform necessarily have a phy-reset gpio encoded in device tree.
> > > > So it makes more sense to have the phy-reset-gpio request failure as
> > > > a debug message rather than a warning.
> > >
> > > Or remove it entirely?
> > >
> > I would like to keep it. When people want to debug at this point, they
> > do not need to type the debug message.
>
> I just think the message might be confusing in case you don't need the
> gpio, because then failing is expected behaviour. For those platforms,
> it is not even an error then, so you must drop returning the error. To
> be very precise, you should check of_get_named_gpio() and return if no
> gpio is specified. Then, you can distinguish that case from problems
> when getting the GPIO.
>
The whole fec_reset_phy() should not be a show-stopper failure. Even
on platforms that have the gpio, FEC can work without resetting the
phy in FEC driver for some cases, for example, boot loader has done it.
It might be good enough to give a warning message rather than getting
the probe fail.
> > > I also wanted to suggested to drop returning the error code, since it is
> > > not an error anymore, strictly speaking. Then I noticed that the caller
> > > does not check the error code. So, this could be added or turn the
> > > function to void?
> > >
> > To me, keep the return value as integer is more scalable. Someday,
> > someone need to add more stuff in the function, or want to improve
> > the caller to check return value, it plays.
>
> I agree that keeping it int is way better. But why not add it now to
> keep things proper and tested? If this patch gets accepted as it is and
> later someone else will add error checking to the caller, your platform
> will lose FEC support as a regression.
>
Again, fec_reset_phy() failure is not a show-stopper. We might not
want to make the probe fail because of that.
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH v2 1/3] net/fec: change phy-reset-gpio request warning to debug message
From: Wolfram Sang @ 2011-09-21 12:59 UTC (permalink / raw)
To: Shawn Guo
Cc: Shawn Guo, David S. Miller, patches, netdev, Troy Kisky,
Francois Romieu, linux-arm-kernel, Lothar Waßmann
In-Reply-To: <20110921124423.GI28907@S2100-06.ap.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 861 bytes --]
> > I agree that keeping it int is way better. But why not add it now to
> > keep things proper and tested? If this patch gets accepted as it is and
> > later someone else will add error checking to the caller, your platform
> > will lose FEC support as a regression.
> >
> Again, fec_reset_phy() failure is not a show-stopper. We might not
> want to make the probe fail because of that.
That would be an argument to make the function returning void?
Well, I still think something like
/* No phy reset configured */
if (phy_reset == -ENODEV)
return 0;
might be cleaner, yet I don't have the setup to test such an approach.
So, I'll be quiet now and hope for no problems.
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* TCP_DELACK_MIN vs TCP_ATO_MIN
From: Daniel Baluta @ 2011-09-21 12:59 UTC (permalink / raw)
To: netdev, kernelnewbies
Hello,
RFC2582, Section 4.2 says:
"... an ACK SHOULD be generated for at least every second
full-sized segment, and MUST be generated within 500 ms
of the arrival of the first unacknowledged packet. ".
I guess that the delayed ACK timeout is computed in tcp_send_delayed_ack:
===
void tcp_send_delayed_ack(struct sock *sk)
{
struct inet_connection_sock *icsk = inet_csk(sk);
int ato = icsk->icsk_ack.ato;
unsigned long timeout;
/* .... */
/* Stay within the limit we were given */
timeout = jiffies + ato;
====
Can one explain what is the difference between TCP_DELACK_MIN and
TCP_ATO_MIN, specifically if the timeout (ato) is always in the interval
[TCP_DELACK_MIN, TCP_DELACK_MAX] ?
I want to make the delayed ack timeout configurable as some guys tried
here [1],
so for this reason I plan to make TCP_DELACK_MIN and TCP_DELACK_MAX
tunable via proc entries.
thanks,
Daniel.
[1] http://kerneltrap.org/mailarchive/linux-netdev/2008/9/9/3245554
^ permalink raw reply
* Re: [PATCH v2 1/3] net/fec: change phy-reset-gpio request warning to debug message
From: Shawn Guo @ 2011-09-21 13:18 UTC (permalink / raw)
To: Wolfram Sang
Cc: patches, netdev, Troy Kisky, Francois Romieu, Shawn Guo,
David S. Miller, linux-arm-kernel, Lothar Waßmann
In-Reply-To: <20110921125905.GI1966@pengutronix.de>
On Wed, Sep 21, 2011 at 02:59:05PM +0200, Wolfram Sang wrote:
> > > I agree that keeping it int is way better. But why not add it now to
> > > keep things proper and tested? If this patch gets accepted as it is and
> > > later someone else will add error checking to the caller, your platform
> > > will lose FEC support as a regression.
> > >
> > Again, fec_reset_phy() failure is not a show-stopper. We might not
> > want to make the probe fail because of that.
>
> That would be an argument to make the function returning void?
>
Hmm, it seems to be. Ok, will send v3 to return void.
Regards,
Shawn
> Well, I still think something like
>
> /* No phy reset configured */
> if (phy_reset == -ENODEV)
> return 0;
>
> might be cleaner, yet I don't have the setup to test such an approach.
>
> So, I'll be quiet now and hope for no problems.
>
> --
> Pengutronix e.K. | Wolfram Sang |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* FYI
From: Christele.Moussu @ 2011-09-21 12:51 UTC (permalink / raw)
After much attempts to reach you on phone, I deemed it necessary and urgent to contact you via your e-mail address and to notify you finally about your outstanding compensation payment.
During our last annual calculation of your banking activities we have realized that you are eligible to receive a compensation payment of $2,811,041.00 USD.
This compensation is being made to all of you who have suffered loss as a result of fraud, accident or illness.
For more info, contact the assigned UPS agent for the delivery of your cashier check.
Name: Ford Hamilton
Tel: +2348072178475
E-mail: ups-cs1@helixnet.cn
Please take note that you will pay a shipping/handling fee of $95.00 USD to UPS.
Thank you for your patience.
Moussu Christele
United Nation Human Settlement Programme
^ permalink raw reply
* Hello my love, My name is jane ferguson,i come across and read through your profile today and i became interested in you,i will also like to know you the more,and i want you to send an e-mail to my e-mail address so i can give you my picture for you to know whom i am and for the both of us to know each other very well and better in life,and we can achieve it in future because ture love and feeling means alot in future.Here is my private e-mail address you can contact me with it.(jane.ferguson@gala.net )I am waiting for your mail to my e-mail address above and aslo, Remember the distance or colour does not matter but love,feeling,e-motions and sympathetic love matters alot in life. Thanks,and i promise to be honest and to keep a very good relationship with you. jane. ja ne.ferguson@gala.net
From: jane ferguson @ 2011-09-21 14:08 UTC (permalink / raw)
^ 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