* Re: [PATCH net] ipv4: Fix ip-header identification for gso packets.
From: David Miller @ 2013-03-24 21:13 UTC (permalink / raw)
To: pshelar; +Cc: amwang, netdev
In-Reply-To: <1364098248-1766-1-git-send-email-pshelar@nicira.com>
From: Pravin B Shelar <pshelar@nicira.com>
Date: Sat, 23 Mar 2013 21:10:48 -0700
> For TCP protocol ip-header id needs to be incremented even if
> IP_DF flag is set. This behaviour was changed in commit
> 490ab08127cebc25e3a26 (IP_GRE: Fix IP-Identification).
>
> Following patch fixes it so that identification is always
> incremented for TCP.
>
> Reported-by: Cong Wang <amwang@redhat.com>
> Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
We should do this increment for all protocols when DF is set,
not just TCP.
^ permalink raw reply
* Re: [PATCH 3/3] net/macb: make clk_enable atomic
From: David Miller @ 2013-03-24 21:08 UTC (permalink / raw)
To: festevam; +Cc: s.trumtrar, netdev, nicolas.ferre
In-Reply-To: <CAOMZO5BRDU_-fvv4PZQcLe-4OdZ4bDQ8m+nNHEFcC1Y2+zdh9g@mail.gmail.com>
From: Fabio Estevam <festevam@gmail.com>
Date: Fri, 22 Mar 2013 14:38:39 -0300
> On Fri, Mar 22, 2013 at 2:33 PM, Steffen Trumtrar
> <s.trumtrar@pengutronix.de> wrote:
>> Use clk_prepare_enable to be safe on SMP systems.
>
> Wouldn't you have to use clk_disable_unprepare() now?
Indeed I think he does.
^ permalink raw reply
* Re: [PATCH 0/2] Fix for mv643xx_eth built as module
From: David Miller @ 2013-03-24 21:07 UTC (permalink / raw)
To: florian
Cc: gmbnomis, linux-arm-kernel, netdev, linuxppc-dev,
thomas.petazzoni, jason, andrew
In-Reply-To: <201303242148.33842.florian@openwrt.org>
From: Florian Fainelli <florian@openwrt.org>
Date: Sun, 24 Mar 2013 21:48:33 +0100
> Hello Simon,
>
> Le dimanche 24 mars 2013 21:33:58, Simon Baatz a écrit :
>> Recently [1], mv643xx_eth was changed to make use of mvmdio. However,
>> this change introduces two problems when mvmdio and mv643xx_eth are
>> built as modules:
>>
>> - mvmdio is not loaded automatically by udev
>> - mv643xx_eth oopses when it can't find its PHY, i.e. when mvmdio is
>> not yet loaded
>>
>> The first problem can be fixed easily by adding a module alias for the
>> respective platform device. The proposed fix for the second problem
>> uses EPROBE_DEFER as suggested by Thomas Petazzoni when the driver
>> can't find its PHY.
>>
>> These patches apply on top of Florian Fainelli's patchset. They have
>> been tested on Marvel Kirkwood non-DT.
>
> Both fixes look good to me, thanks for fixing this!
>
> Acked-by: Florian Fainelli <florian@openwrt.org>
All applied, thanks.
^ permalink raw reply
* Re: [PATCH] tcp: undo spurious timeout after SACK reneging
From: Neal Cardwell @ 2013-03-24 20:50 UTC (permalink / raw)
To: Yuchung Cheng; +Cc: David Miller, Eric Dumazet, Nandita Dukkipati, Netdev
In-Reply-To: <1364157745-24866-1-git-send-email-ycheng@google.com>
On Sun, Mar 24, 2013 at 4:42 PM, Yuchung Cheng <ycheng@google.com> wrote:
> On SACK reneging the sender immediately retransmits and forces a
> timeout but disables Eifel (undo). If the (buggy) receiver does not
> drop any packet this can trigger a false slow-start retransmit storm
> driven by the ACKs of the original packets. This can be detected with
> undo and TCP timestamps.
>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> ---
> net/ipv4/tcp_input.c | 7 ++-----
> 1 file changed, 2 insertions(+), 5 deletions(-)
Acked-by: Neal Cardwell <ncardwell@google.com>
neal
^ permalink raw reply
* Re: [PATCH 0/2] Fix for mv643xx_eth built as module
From: Florian Fainelli @ 2013-03-24 20:48 UTC (permalink / raw)
To: Simon Baatz
Cc: linux-arm-kernel, netdev, linuxppc-dev, thomas.petazzoni, jason,
andrew, davem
In-Reply-To: <1364157240-28883-1-git-send-email-gmbnomis@gmail.com>
Hello Simon,
Le dimanche 24 mars 2013 21:33:58, Simon Baatz a écrit :
> Recently [1], mv643xx_eth was changed to make use of mvmdio. However,
> this change introduces two problems when mvmdio and mv643xx_eth are
> built as modules:
>
> - mvmdio is not loaded automatically by udev
> - mv643xx_eth oopses when it can't find its PHY, i.e. when mvmdio is
> not yet loaded
>
> The first problem can be fixed easily by adding a module alias for the
> respective platform device. The proposed fix for the second problem
> uses EPROBE_DEFER as suggested by Thomas Petazzoni when the driver
> can't find its PHY.
>
> These patches apply on top of Florian Fainelli's patchset. They have
> been tested on Marvel Kirkwood non-DT.
Both fixes look good to me, thanks for fixing this!
Acked-by: Florian Fainelli <florian@openwrt.org>
--
Florian
^ permalink raw reply
* [PATCH] tcp: undo spurious timeout after SACK reneging
From: Yuchung Cheng @ 2013-03-24 20:42 UTC (permalink / raw)
To: davem, ncardwell, edumazet, nanditad; +Cc: netdev, Yuchung Cheng
On SACK reneging the sender immediately retransmits and forces a
timeout but disables Eifel (undo). If the (buggy) receiver does not
drop any packet this can trigger a false slow-start retransmit storm
driven by the ACKs of the original packets. This can be detected with
undo and TCP timestamps.
Signed-off-by: Yuchung Cheng <ycheng@google.com>
---
net/ipv4/tcp_input.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index b2b3619..6d9ca35 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -1858,11 +1858,8 @@ void tcp_enter_loss(struct sock *sk, int how)
if (tcp_is_reno(tp))
tcp_reset_reno_sack(tp);
- if (!how) {
- /* Push undo marker, if it was plain RTO and nothing
- * was retransmitted. */
- tp->undo_marker = tp->snd_una;
- } else {
+ tp->undo_marker = tp->snd_una;
+ if (how) {
tp->sacked_out = 0;
tp->fackets_out = 0;
}
--
1.8.1.3
^ permalink raw reply related
* [PATCH 2/2] mv643xx_eth: defer probing if Marvell Orion MDIO driver not loaded
From: Simon Baatz @ 2013-03-24 20:34 UTC (permalink / raw)
To: linux-arm-kernel, netdev, linuxppc-dev, florian, thomas.petazzoni
Cc: jason, andrew, davem, Simon Baatz
In-Reply-To: <1364157240-28883-1-git-send-email-gmbnomis@gmail.com>
When both the Marvell MV643XX ethernet driver and the Orion MDIO driver
are compiled as modules, the ethernet driver may be probed before the
MDIO driver. Let mv643xx_eth_probe() return EPROBE_DEFER in this case,
i.e. when it cannot find the PHY.
Signed-off-by: Simon Baatz <gmbnomis@gmail.com>
---
drivers/net/ethernet/marvell/mv643xx_eth.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
index a65a92e..aedbd82 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -2681,7 +2681,7 @@ static struct phy_device *phy_scan(struct mv643xx_eth_private *mp,
}
/* Attempt to connect to the PHY using orion-mdio */
- phydev = NULL;
+ phydev = ERR_PTR(-ENODEV);
for (i = 0; i < num; i++) {
int addr = (start + i) & 0x1f;
@@ -2812,11 +2812,17 @@ static int mv643xx_eth_probe(struct platform_device *pdev)
netif_set_real_num_tx_queues(dev, mp->txq_count);
netif_set_real_num_rx_queues(dev, mp->rxq_count);
- if (pd->phy_addr != MV643XX_ETH_PHY_NONE)
+ if (pd->phy_addr != MV643XX_ETH_PHY_NONE) {
mp->phy = phy_scan(mp, pd->phy_addr);
- if (mp->phy != NULL)
+ if (IS_ERR(mp->phy)) {
+ err = PTR_ERR(mp->phy);
+ if (err == -ENODEV)
+ err = -EPROBE_DEFER;
+ goto out;
+ }
phy_init(mp, pd->speed, pd->duplex);
+ }
SET_ETHTOOL_OPS(dev, &mv643xx_eth_ethtool_ops);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] net: mvmdio: define module alias for platform device
From: Simon Baatz @ 2013-03-24 20:33 UTC (permalink / raw)
To: linux-arm-kernel, netdev, linuxppc-dev, florian, thomas.petazzoni
Cc: jason, andrew, davem, Simon Baatz
In-Reply-To: <1364157240-28883-1-git-send-email-gmbnomis@gmail.com>
The mvmdio driver can be instantiated using device tree or as a classic
platform device. In order to load the driver automatically by udev in
the latter case, the driver needs to define a module alias for the
platform device.
Signed-off-by: Simon Baatz <gmbnomis@gmail.com>
---
drivers/net/ethernet/marvell/mvmdio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/marvell/mvmdio.c b/drivers/net/ethernet/marvell/mvmdio.c
index 3472574..7b5158f 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -295,3 +295,4 @@ module_platform_driver(orion_mdio_driver);
MODULE_DESCRIPTION("Marvell MDIO interface driver");
MODULE_AUTHOR("Thomas Petazzoni <thomas.petazzoni@free-electrons.com>");
MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:orion-mdio");
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/2] Fix for mv643xx_eth built as module
From: Simon Baatz @ 2013-03-24 20:33 UTC (permalink / raw)
To: linux-arm-kernel, netdev, linuxppc-dev, florian, thomas.petazzoni
Cc: jason, andrew, davem, Simon Baatz
Recently [1], mv643xx_eth was changed to make use of mvmdio. However,
this change introduces two problems when mvmdio and mv643xx_eth are
built as modules:
- mvmdio is not loaded automatically by udev
- mv643xx_eth oopses when it can't find its PHY, i.e. when mvmdio is
not yet loaded
The first problem can be fixed easily by adding a module alias for the
respective platform device. The proposed fix for the second problem
uses EPROBE_DEFER as suggested by Thomas Petazzoni when the driver
can't find its PHY.
These patches apply on top of Florian Fainelli's patchset. They have
been tested on Marvel Kirkwood non-DT.
- Simon
[1] https://lkml.org/lkml/2013/3/22/247
Simon Baatz (2):
net: mvmdio: define module alias for platform device
mv643xx_eth: defer probing if Marvell Orion MDIO driver not loaded
drivers/net/ethernet/marvell/mv643xx_eth.c | 12 +++++++++---
drivers/net/ethernet/marvell/mvmdio.c | 1 +
2 files changed, 10 insertions(+), 3 deletions(-)
--
1.7.9.5
^ permalink raw reply
* Re: [PATCH] Fix IXP4xx coherent allocations
From: Ben Hutchings @ 2013-03-24 19:11 UTC (permalink / raw)
To: David Miller; +Cc: khc, netdev, linux-arm-kernel, linux-kernel, c.aeschlimann
In-Reply-To: <20130323.195740.2108147521543354261.davem@davemloft.net>
On Sat, 2013-03-23 at 19:57 -0400, David Miller wrote:
> From: Krzysztof Halasa <khc@pm.waw.pl>
> Date: Sat, 23 Mar 2013 20:35:46 +0100
>
> > ARM core code currently requires coherent DMA mask to be set. Make sure
> > we limit PCI devices to 64 MiB while allowing on-chip devices to access
> > the whole 4 GiB address space.
> >
> > This fixes a v3.7+ regression which broke IXP4xx built-in network devices.
> >
> > Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl>
>
> This requirement is not reasonable.
>
> The DMA API documentation clearly states what the default must be,
> and what drivers are guarenteed will be the default.
I'm failing to see where it says the default can't be narrower than 32
bits due to platform limits. And how do you think DMA mapping is
supposed to work for PCI devices on these platforms, anyway?
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] net: Add support for handling queueing in hardware
From: Guenter Roeck @ 2013-03-24 19:06 UTC (permalink / raw)
To: Ben Collins; +Cc: David Miller, afleming, linux-kernel, netdev
In-Reply-To: <20130323190221.GA22005@roeck-us.net>
On Sat, Mar 23, 2013 at 12:02:21PM -0700, Guenter Roeck wrote:
> On Fri, Mar 22, 2013 at 10:43:44AM -0400, Ben Collins wrote:
> > On Mar 22, 2013, at 10:33 AM, David Miller <davem@davemloft.net> wrote:
> >
> > > From: Fleming Andy-AFLEMING <afleming@freescale.com>
> > > Date: Fri, 22 Mar 2013 14:31:50 +0000
> > >
> > >> It would appear one of our customers is attempting to upstream our
> > >> code for us. We are aware that this current solution is unacceptable
> > >> (which is why we have not submitted it), and we are currently trying
> > >> to develop a less hacky solution that integrates with qdisc.
> > >
> > > Ben, can can you coordinate with people instead of doing crap like
> > > this?
> >
> >
> > "For us" is a loose term, when it's more that we are attempting to upstream code so our system is supported by a mainline kernel instead of having one-off kernels.
> >
> > And we have been talking with Freescale about this for quite some time (couple years?). They have a roadmap that doesn't include getting this driver supported in mainline any time soon, so I'm taking time to get this done for our own system. I'm not meaning to step on any toes.
> >
> How true. You are not the only one with thatt problem.
>
> Ben, can you possibly send me your complete patch set on top of 3.8, or point me
> to a git tree ?
>
Never mind, I found your tree on github.
I'll clone it next week and start playing with it. That is going to save me a
lot of time. Thanks a lot for the work!
Our system is based on P5040, and I might be able to do some testing on P5020
as well. I'll let you know how it goes.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH 1/5] net: Add EMAC ethernet driver found on Allwinner A10 SoC's
From: Florian Fainelli @ 2013-03-24 19:03 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Maxime Ripard, linux-doc, Alejandro Mery, netdev,
devicetree-discuss, linux-kernel, Rob Herring, Grant Likely,
Rob Landley, sunny, shuge, Stefan Roese, kevin
In-Reply-To: <1364077814-2233-2-git-send-email-maxime.ripard@free-electrons.com>
Hello,
Your phylib implementation looks good now, just some minor comments below:
Le samedi 23 mars 2013 23:30:10, Maxime Ripard a écrit :
> From: Stefan Roese <sr@denx.de>
>
> The Allwinner A10 has an ethernet controller that seem to be developped
> internally by them.
>
> The exact feature set of this controller is unknown, since there is no
> public documentation for this IP, and this driver is mostly the one
> published by Allwinner that has been heavily cleaned up.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> .../bindings/net/allwinner,sun4i-emac.txt | 19 +
> drivers/net/ethernet/Kconfig | 1 +
> drivers/net/ethernet/Makefile | 1 +
> drivers/net/ethernet/allwinner/Kconfig | 36 +
> drivers/net/ethernet/allwinner/Makefile | 5 +
> drivers/net/ethernet/allwinner/sun4i-emac.c | 1033
> ++++++++++++++++++++ drivers/net/ethernet/allwinner/sun4i-emac.h |
> 114 +++
> 7 files changed, 1209 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt create mode
> 100644 drivers/net/ethernet/allwinner/Kconfig
> create mode 100644 drivers/net/ethernet/allwinner/Makefile
> create mode 100644 drivers/net/ethernet/allwinner/sun4i-emac.c
> create mode 100644 drivers/net/ethernet/allwinner/sun4i-emac.h
>
> diff --git a/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt
> b/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt new file
> mode 100644
> index 0000000..aaf5013
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt
> @@ -0,0 +1,19 @@
> +* Allwinner EMAC ethernet controller
> +
> +Required properties:
> +- compatible: should be "allwinner,sun4i-emac".
> +- reg: address and length of the register set for the device.
> +- interrupts: interrupt for the device
> +
> +Optional properties:
> +- phy-supply: phandle to a regulator if the PHY needs one
> +- (local-)mac-address: mac address to be used by this driver
> +
> +Example:
> +
> +emac: ethernet@01c0b000 {
> + compatible = "allwinner,sun4i-emac";
> + reg = <0x01c0b000 0x1000>;
> + phy-supply = <®_emac_3v3>;
> + interrupts = <55>;
Also include a standard PHY device tree binding and use the device tree
helpers to find and connect to your PHY device.
[snip]
> +if NET_VENDOR_ALLWINNER
> +
> +config SUN4I_EMAC
> + tristate "Allwinner A10 EMAC support"
> + depends on ARCH_SUNXI
> + depends on OF
> + select CRC32
> + select NET_CORE
> + select MII
You should select PHYLIB now that you implement it.
[snip]
> +static int emac_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
> +{
> + struct emac_board_info *db = bus->priv;
> + int value;
> +
> + /* issue the phy address and reg */
> + writel((mii_id << 8) | regnum, db->membase + EMAC_MAC_MADR_REG);
> + /* pull up the phy io line */
> + writel(0x1, db->membase + EMAC_MAC_MCMD_REG);
> +
> + /* Wait read complete */
> + while (readl(db->membase + EMAC_MAC_MIND_REG) & 0x1)
> + cpu_relax();
This needs proper timeout handling.
> +
> + /* push down the phy io line */
> + writel(0x0, db->membase + EMAC_MAC_MCMD_REG);
> + /* and read data */
> + value = readl(db->membase + EMAC_MAC_MRDD_REG);
> +
> + return value;
> +}
> +
> +static int emac_mdio_write(struct mii_bus *bus, int mii_id, int regnum,
> + u16 value)
> +{
> + struct emac_board_info *db = bus->priv;
> +
> + /* issue the phy address and reg */
> + writel((mii_id << 8) | regnum, db->membase + EMAC_MAC_MADR_REG);
> + /* pull up the phy io line */
> + writel(0x1, db->membase + EMAC_MAC_MCMD_REG);
> +
> + /* Wait read complete */
> + while (readl(db->membase + EMAC_MAC_MIND_REG) & 0x1)
> + cpu_relax();
Same here.
[snip]
> +static void emac_init_emac(struct net_device *dev);
> +static void emac_handle_link_change(struct net_device *dev)
> +{
> + struct emac_board_info *db = netdev_priv(dev);
> + struct phy_device *phydev = db->phy_dev;
> + unsigned long flags;
> + int status_change = 0;
> +
> + spin_lock_irqsave(&db->lock, flags);
a phylib adjust_link callback is already called with a mutex hold, so your
spinlock could be moved down to emac_init_emac() where the RMW sequence is
performed.
> +
> + if (phydev->link) {
> + if ((db->speed != phydev->speed) ||
> + (db->duplex != phydev->duplex)) {
> + /* Re-init EMAC with new settings */
> + emac_init_emac(dev);
emac_init_emac() (the name could be change BTW) is not just changing the
duplex setting of the MAC but also touches the transmitter/receiver enable
bits, is that what you want as well?
[snip]
> +static int emac_mii_probe(struct net_device *dev)
> +{
> + struct emac_board_info *db = netdev_priv(dev);
> + struct phy_device *phydev;
> + int ret;
> +
> + phydev = phy_find_first(db->mii_bus);
> + if (!phydev) {
> + netdev_err(dev, "no PHY found\n");
> + return -1;
> + }
> +
> + /* to-do: PHY interrupts are currently not supported */
> +
> + /* attach the mac to the phy */
> + ret = phy_connect_direct(dev, phydev, &emac_handle_link_change,
> + db->phy_interface);
> + if (ret) {
> + netdev_err(dev, "Could not attach to PHY\n");
> + return ret;
> + }
You could use of_phy_connect() here to eliminate some boilerplate code.
[snip]
> +unsigned int emac_powerup(struct net_device *ndev)
> +{
> + struct emac_board_info *db = netdev_priv(ndev);
> + unsigned int reg_val;
> +
> + /* initial EMAC */
> + /* flush RX FIFO */
> + reg_val = readl(db->membase + EMAC_RX_CTL_REG);
> + reg_val |= 0x8;
> + writel(reg_val, db->membase + EMAC_RX_CTL_REG);
> + udelay(1);
> +
> + /* initial MAC */
> + /* soft reset MAC */
> + reg_val = readl(db->membase + EMAC_MAC_CTL0_REG);
> + reg_val &= ~EMAC_MAC_CTL0_SOFT_RESET;
> + writel(reg_val, db->membase + EMAC_MAC_CTL0_REG);
> +
> + /* set MII clock */
> + reg_val = readl(db->membase + EMAC_MAC_MCFG_REG);
> + reg_val &= (~(0xf << 2));
> + reg_val |= (0xD << 2);
> + writel(reg_val, db->membase + EMAC_MAC_MCFG_REG);
> +
> + /* clear RX counter */
> + writel(0x0, db->membase + EMAC_RX_FBC_REG);
> +
> + /* disable all interrupt and clear interrupt status */
> + writel(0, db->membase + EMAC_INT_CTL_REG);
> + reg_val = readl(db->membase + EMAC_INT_STA_REG);
> + writel(reg_val, db->membase + EMAC_INT_STA_REG);
> +
> + udelay(1);
> +
> + /* set up EMAC */
> + emac_setup(ndev);
> +
> + /* set mac_address to chip */
> + writel(ndev->dev_addr[0] << 16 | ndev->dev_addr[1] << 8 | ndev->
> + dev_addr[2], db->membase + EMAC_MAC_A1_REG);
> + writel(ndev->dev_addr[3] << 16 | ndev->dev_addr[4] << 8 | ndev->
> + dev_addr[5], db->membase + EMAC_MAC_A0_REG);
> +
> + mdelay(1);
> +
> + return 1;
Either return 0 to be consistent, or do not return anything
[snip]
> +static int emac_start_xmit(struct sk_buff *skb, struct net_device *dev)
> +{
> + struct emac_board_info *db = netdev_priv(dev);
> + unsigned long channel;
> + unsigned long flags;
> +
> + channel = db->tx_fifo_stat & 3;
> + if (channel == 3)
> + return NETDEV_TX_BUSY;
NETDEV_TX_BUSY really is a hard condition, your initial submission had
something like netif_stop_queue(dev) and return 1 and this was actually
better.
[snip]
> +
> +/* Received a packet and pass to upper layer
> + */
> +static void emac_rx(struct net_device *dev)
> +{
> + struct emac_board_info *db = netdev_priv(dev);
> + struct sk_buff *skb;
> + u8 *rdptr;
> + bool good_packet;
> + static int rxlen_last;
> + unsigned int reg_val;
> + u32 rxhdr, rxstatus, rxcount, rxlen;
> +
> + /* Check packet ready or not */
> + while (1) {
> + /* race warning: the first packet might arrive with
> + * the interrupts disabled, but the second will fix
> + * it
> + */
> + rxcount = readl(db->membase + EMAC_RX_FBC_REG);
> +
> + if (netif_msg_rx_status(db))
> + dev_dbg(db->dev, "RXCount: %x\n", rxcount);
> +
> + if ((db->skb_last != NULL) && (rxlen_last > 0)) {
> + dev->stats.rx_bytes += rxlen_last;
> +
> + /* Pass to upper layer */
> + db->skb_last->protocol = eth_type_trans(db->skb_last,
> + dev);
> + netif_rx(db->skb_last);
> + dev->stats.rx_packets++;
> + db->skb_last = NULL;
> + rxlen_last = 0;
> +
> + reg_val = readl(db->membase + EMAC_RX_CTL_REG);
> + reg_val &= ~EMAC_RX_CTL_DMA_EN;
> + writel(reg_val, db->membase + EMAC_RX_CTL_REG);
> + }
> +
> + if (!rxcount) {
> + db->emacrx_completed_flag = 1;
> + reg_val = readl(db->membase + EMAC_INT_CTL_REG);
> + reg_val |= (0xf << 0) | (0x01 << 8);
> + writel(reg_val, db->membase + EMAC_INT_CTL_REG);
> +
> + /* had one stuck? */
> + rxcount = readl(db->membase + EMAC_RX_FBC_REG);
> + if (!rxcount)
> + return;
> + }
> +
> + reg_val = readl(db->membase + EMAC_RX_IO_DATA_REG);
> + if (netif_msg_rx_status(db))
> + dev_dbg(db->dev, "receive header: %x\n", reg_val);
> + if (reg_val != EMAC_UNDOCUMENTED_MAGIC) {
> + /* disable RX */
> + reg_val = readl(db->membase + EMAC_CTL_REG);
> + writel(reg_val & ~EMAC_CTL_RX_EN,
> + db->membase + EMAC_CTL_REG);
> +
> + /* Flush RX FIFO */
> + reg_val = readl(db->membase + EMAC_RX_CTL_REG);
> + writel(reg_val | (1 << 3),
> + db->membase + EMAC_RX_CTL_REG);
> +
> + do {
> + reg_val = readl(db->membase + EMAC_RX_CTL_REG);
> + } while (reg_val & (1 << 3));
> +
> + /* enable RX */
> + reg_val = readl(db->membase + EMAC_CTL_REG);
> + writel(reg_val | EMAC_CTL_RX_EN,
> + db->membase + EMAC_CTL_REG);
> + reg_val = readl(db->membase + EMAC_INT_CTL_REG);
> + reg_val |= (0xf << 0) | (0x01 << 8);
> + writel(reg_val, db->membase + EMAC_INT_CTL_REG);
> +
> + db->emacrx_completed_flag = 1;
> +
> + return;
> + }
> +
> + /* A packet ready now & Get status/length */
> + good_packet = true;
> +
> + emac_inblk_32bit(db->membase + EMAC_RX_IO_DATA_REG,
> + &rxhdr, sizeof(rxhdr));
> +
> + if (netif_msg_rx_status(db))
> + dev_dbg(db->dev, "rxhdr: %x\n", *((int *)(&rxhdr)));
> +
> + rxlen = EMAC_RX_IO_DATA_LEN(rxhdr);
> + rxstatus = EMAC_RX_IO_DATA_STATUS(rxhdr);
> +
> + if (netif_msg_rx_status(db))
> + dev_dbg(db->dev, "RX: status %02x, length %04x\n",
> + rxstatus, rxlen);
> +
> + /* Packet Status check */
> + if (rxlen < 0x40) {
> + good_packet = false;
> + if (netif_msg_rx_err(db))
> + dev_dbg(db->dev, "RX: Bad Packet (runt)\n");
> + }
> +
> + if (unlikely(!(rxstatus & EMAC_RX_IO_DATA_STATUS_OK))) {
> + good_packet = false;
> +
> + if (rxstatus & EMAC_RX_IO_DATA_STATUS_CRC_ERR) {
> + if (netif_msg_rx_err(db))
> + dev_dbg(db->dev, "crc error\n");
> + dev->stats.rx_crc_errors++;
> + }
> +
> + if (rxstatus & EMAC_RX_IO_DATA_STATUS_LEN_ERR) {
> + if (netif_msg_rx_err(db))
> + dev_dbg(db->dev, "length error\n");
> + dev->stats.rx_length_errors++;
> + }
> + }
> +
> + /* Move data from EMAC */
> + skb = dev_alloc_skb(rxlen + 4);
> + if (good_packet && skb) {
> + skb_reserve(skb, 2);
> + rdptr = (u8 *) skb_put(skb, rxlen - 4);
> +
> + /* Read received packet from RX SRAM */
> + if (netif_msg_rx_status(db))
> + dev_dbg(db->dev, "RxLen %x\n", rxlen);
> +
> + emac_inblk_32bit(db->membase + EMAC_RX_IO_DATA_REG,
> + rdptr, rxlen);
> + dev->stats.rx_bytes += rxlen;
> +
> + /* Pass to upper layer */
> + skb->protocol = eth_type_trans(skb, dev);
> + netif_rx(skb);
> + dev->stats.rx_packets++;
> + }
> + }
> +}
> +
> +static irqreturn_t emac_interrupt(int irq, void *dev_id)
> +{
You should implement NAPI, you do not have much to change to actually be able
to do it.
> + netif_stop_queue(ndev);
> + netif_carrier_off(ndev);
phy_stop() is missing here.
--
Florian
^ permalink raw reply
* Re: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba (updated) Version 2
From: Hannes Frederic Sowa @ 2013-03-24 17:38 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Huang, Xiong, Sven Hartge, netdev@vger.kernel.org
In-Reply-To: <1364145768.29473.9.camel@edumazet-glaptop>
On Sun, Mar 24, 2013 at 10:22:48AM -0700, Eric Dumazet wrote:
> What could be tried is to remove the possibility of page spanning.
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 441f5bf..d0f4dd1 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -1849,7 +1849,7 @@ static inline void __skb_queue_purge(struct sk_buff_head *list)
> kfree_skb(skb);
> }
>
> -#define NETDEV_FRAG_PAGE_MAX_ORDER get_order(32768)
> +#define NETDEV_FRAG_PAGE_MAX_ORDER 0
> #define NETDEV_FRAG_PAGE_MAX_SIZE (PAGE_SIZE << NETDEV_FRAG_PAGE_MAX_ORDER)
> #define NETDEV_PAGECNT_MAX_BIAS NETDEV_FRAG_PAGE_MAX_SIZE
Doesn't change anything. :(
We tested it on a v3.8 kernel so I changed the definition in
net/core/skbuff.c. I hope this doesn't change the outcome.
Btw, reports about this bug are dating back to 2008 so I don't think
that a recent change in the kernel broke it.
Thanks,
Hannes
^ permalink raw reply
* Re: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba (updated) Version 2
From: Hannes Frederic Sowa @ 2013-03-24 17:24 UTC (permalink / raw)
To: Huang, Xiong; +Cc: Sven Hartge, netdev@vger.kernel.org
In-Reply-To: <157393863283F442885425D2C4542856489E7D3C@nasanexd02f.na.qualcomm.com>
On Sun, Mar 24, 2013 at 06:12:08AM +0000, Huang, Xiong wrote:
> And try to use following code to replace atl1c_configure_dma
>
> static inline void atl1e_configure_dma(struct atl1e_adapter *adapter)
> {
> struct atl1e_hw *hw = &adapter->hw;
> u32 dma_ctrl_data;
>
> dma_ctrl_data = DMA_CTRL_RXCMB_EN | 0x400000;
> dma_ctrl_data |= (((u32)hw->dmar_block) & DMA_CTRL_DMAR_BURST_LEN_MASK)
> << DMA_CTRL_DMAR_BURST_LEN_SHIFT;
> dma_ctrl_data |= (((u32)hw->dmaw_block) & DMA_CTRL_DMAW_BURST_LEN_MASK)
> << DMA_CTRL_DMAW_BURST_LEN_SHIFT;
> dma_ctrl_data |= DMA_CTRL_DMAR_REQ_PRI | DMA_CTRL_DMAR_OUT_ORDER;
> dma_ctrl_data |= (((u32)hw->dmar_dly_cnt) & DMA_CTRL_DMAR_DLY_CNT_MASK)
> << DMA_CTRL_DMAR_DLY_CNT_SHIFT;
> dma_ctrl_data |= (((u32)hw->dmaw_dly_cnt) & DMA_CTRL_DMAW_DLY_CNT_MASK)
> << DMA_CTRL_DMAW_DLY_CNT_SHIFT;
>
> AT_WRITE_REG(hw, REG_DMA_CTRL, dma_ctrl_data);
> return;
> }
Also no change. Corrupted frames still occur.
Thanks,
Hannes
^ permalink raw reply
* Re: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba (updated) Version 2
From: Hannes Frederic Sowa @ 2013-03-24 17:23 UTC (permalink / raw)
To: Huang, Xiong; +Cc: Sven Hartge, netdev@vger.kernel.org
In-Reply-To: <157393863283F442885425D2C4542856489E7D1E@nasanexd02f.na.qualcomm.com>
On Sun, Mar 24, 2013 at 05:42:41AM +0000, Huang, Xiong wrote:
> > > >
> > > > The caputered packets show that a 16 byte segment overwrites later
> > > > data in the same packet, sometimes even multiple contiguous 16 byte
> > segments.
> > > >
> > > > The corrupted packets look like this:
> > > >
> > > > ...ABC....DBBEF..
> > > >
> > > > Each character represents a 16 byte region, the dots are dont-care
> > > > placeholders. The BB-region is overwritten by the data of the first B-
> > region.
> > > >
> > >
> > > It looks like a DMA issue. Not checksum related. :(
> >
> > Yes, I think so, too. Until this is resolved I would propose to not set
> > CHECKSUM_UNNECESSARY because it could corrupt data (like for the original
> > poster).
> >
> > Do you have any idea where how these errors could be resolved? I e.g. could
> > not reproduce it with FreeBSD and the driver seems to be related to the linux
> > driver.
>
> 1. pages cross 4GB bouandary ? or overlap with each other ?
This should not be the case.
> 2. try to set hw->dmaw_block = atl1e_dma_req_128
Sorry, we can still reproduce corrupted frames with this change.
> 3. can you print reg15C0 content when the NIC is in normal tx/rx status ?
Yes, dma register is reg15C0 == 0x247c24 all the time (vanilla kernel without
any of your proposed changes).
Couldn't this also be because of a timing issue? It does take much more time
on slower machines(eeepc) to reproduce this issue. On a normal desktop machine it
does nearly occur instantaneous.
Thanks,
Hannes
^ permalink raw reply
* RE: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba (updated) Version 2
From: Eric Dumazet @ 2013-03-24 17:22 UTC (permalink / raw)
To: Huang, Xiong; +Cc: Hannes Frederic Sowa, Sven Hartge, netdev@vger.kernel.org
In-Reply-To: <157393863283F442885425D2C4542856489E7D1E@nasanexd02f.na.qualcomm.com>
On Sun, 2013-03-24 at 05:42 +0000, Huang, Xiong wrote:
> 1. pages cross 4GB bouandary ? or overlap with each other ?
Normally this should not happen.
However the frame could span two 4K pages.
(physically contigous, and not spanning a 32K boundary)
> 2. try to set hw->dmaw_block = atl1e_dma_req_128
> 3. can you print reg15C0 content when the NIC is in normal tx/rx status ?
> 4. other possible may be related the diff register configuration, but it's very difficult to compare with Windows driver :(
>
What could be tried is to remove the possibility of page spanning.
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 441f5bf..d0f4dd1 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1849,7 +1849,7 @@ static inline void __skb_queue_purge(struct sk_buff_head *list)
kfree_skb(skb);
}
-#define NETDEV_FRAG_PAGE_MAX_ORDER get_order(32768)
+#define NETDEV_FRAG_PAGE_MAX_ORDER 0
#define NETDEV_FRAG_PAGE_MAX_SIZE (PAGE_SIZE << NETDEV_FRAG_PAGE_MAX_ORDER)
#define NETDEV_PAGECNT_MAX_BIAS NETDEV_FRAG_PAGE_MAX_SIZE
^ permalink raw reply related
* Re: [PATCH] ath9k : Fix ieee80211 work while going to suspend
From: Parag Warudkar @ 2013-03-24 16:16 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Stanislaw Gruszka, John W. Linville, Jouni Malinen,
Vasanthakumar Thiagarajan, linux-wireless, ath9k-devel, netdev,
LKML, senthilb
In-Reply-To: <20130322150847.GH32416@pogo>
On Fri, Mar 22, 2013 at 11:08 AM, Luis R. Rodriguez
<rodrigue@qca.qualcomm.com> wrote:
> On Fri, Mar 22, 2013 at 10:13:42AM +0100, Stanislaw Gruszka wrote:
>> On Thu, Mar 21, 2013 at 12:33:31PM -0700, Luis R. Rodriguez wrote:
>> > OK how about this for stable for now:
>> >
>> > diff --git a/drivers/net/wireless/ath/ath9k/link.c b/drivers/net/wireless/ath/ath9k/link.c
>> > index 39c84ec..7fdac6c 100644
>> > --- a/drivers/net/wireless/ath/ath9k/link.c
>> > +++ b/drivers/net/wireless/ath/ath9k/link.c
>> > @@ -170,7 +170,8 @@ void ath_rx_poll(unsigned long data)
>> > {
>> > struct ath_softc *sc = (struct ath_softc *)data;
>> >
>> > - ieee80211_queue_work(sc->hw, &sc->hw_check_work);
>> > + if (!test_bit(SC_OP_INVALID, &sc->sc_flags))
>> > + ieee80211_queue_work(sc->hw, &sc->hw_check_work);
>> > }
>>
>> That looks ok for me as -stable fix
>>
>> Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
>
> Parag, can you test the above to ensure it fixes your issue ?
Seems to be working ok so far.
Reported-and-tested-by: Parag Warudkar <parag.lkml@gmail.com>
^ permalink raw reply
* Re: [PATCH v3 1/1 net-next] net: fec: put tx to napi poll function to fix dead lock
From: Shawn Guo @ 2013-03-24 14:35 UTC (permalink / raw)
To: Fabio Estevam
Cc: Frank Li, B38611, netdev, s.hauer, lznuaa, davem,
linux-arm-kernel
In-Reply-To: <CAOMZO5B-ipzyb2uiLW12fFd3PD3JfLS8R0YLM5vtLgFNz8abUw@mail.gmail.com>
On Fri, Mar 22, 2013 at 04:00:26PM -0300, Fabio Estevam wrote:
> On Wed, Mar 20, 2013 at 8:48 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
> > Frank,
> >
> > I'm running v3.9-rc3 image with NFS on imx6q, and seeing system fail
> > to resume back. The resume seems being stopped by fec driver. If you
> > wait long enough, you might see the repeated "eth0: tx queue full!."
> > error message.
>
> On mx28, only reverting this patch does not solve the suspend/resume issue.
Are you sure? After reverting the patch on next-20130322, I can get
imx28 resume back to console as below.
Shawn
root@freescale ~$ echo mem > /sys/power/state
[ 20.943170] PM: Syncing filesystems ... done.
[ 20.976303] Freezing user space processes ... (elapsed 0.01 seconds) done.
[ 20.998050] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
[ 21.025647] PM: suspend of devices complete after 6.283 msecs
[ 21.032543] PM: late suspend of devices complete after 1.092 msecs
[ 21.040489] PM: noirq suspend of devices complete after 1.603 msecs
[ 21.048045] PM: noirq resume of devices complete after 0.794 msecs
[ 21.055891] PM: early resume of devices complete after 1.088 msecs
[ 21.167790] PM: resume of devices complete after 105.641 msecs
[ 21.174939] Restarting tasks ... done.
root@freescale ~$
^ permalink raw reply
* Re: [PATCH net-next] bridge: avoid br_ifinfo_notify when nothing changed
From: Sergei Shtylyov @ 2013-03-24 14:34 UTC (permalink / raw)
To: Hong Zhiguo; +Cc: netdev, bridge, davem, stephen, herbert, zhiguo.hong
In-Reply-To: <1364131607-11698-1-git-send-email-honkiko@gmail.com>
Hello.
On 03/24/2013 04:26 PM, Hong Zhiguo wrote:
> When neither IFF_BRIDGE nor IFF_BRIDGE_PORT is set,
> and afspec == NULL but protinfo != NULL, we run into
> "if (err == 0) br_ifinfo_notify(RTM_NEWLINK, p);" with
> random value in ret.
>
> Thanks to Sergei for pointing out the error in commit comments.
>
> Signed-off-by: Hong Zhiguo <honkiko@gmail.com>
For the future, if you post the revised version of the patch, you
should indicate in the subject it like this: [PATCH v2].
WBR, Sergei
^ permalink raw reply
* [PATCH net-next] bridge: avoid br_ifinfo_notify when nothing changed
From: Hong Zhiguo @ 2013-03-24 13:26 UTC (permalink / raw)
To: netdev
Cc: bridge, davem, stephen, herbert, sergei.shtylyov, zhiguo.hong,
Hong Zhiguo
In-Reply-To: <1364015653-7322-1-git-send-email-honkiko@gmail.com>
When neither IFF_BRIDGE nor IFF_BRIDGE_PORT is set,
and afspec == NULL but protinfo != NULL, we run into
"if (err == 0) br_ifinfo_notify(RTM_NEWLINK, p);" with
random value in ret.
Thanks to Sergei for pointing out the error in commit comments.
Signed-off-by: Hong Zhiguo <honkiko@gmail.com>
---
net/bridge/br_netlink.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
index 84c3b7d..b96e02e 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -357,7 +357,7 @@ int br_setlink(struct net_device *dev, struct nlmsghdr *nlh)
struct nlattr *afspec;
struct net_bridge_port *p;
struct nlattr *tb[IFLA_BRPORT_MAX + 1];
- int err;
+ int err = 0;
ifm = nlmsg_data(nlh);
@@ -370,7 +370,7 @@ int br_setlink(struct net_device *dev, struct nlmsghdr *nlh)
/* We want to accept dev as bridge itself if the AF_SPEC
* is set to see if someone is setting vlan info on the brigde
*/
- if (!p && ((dev->priv_flags & IFF_EBRIDGE) && !afspec))
+ if (!p && !afspec)
return -EINVAL;
if (p && protinfo) {
--
1.7.10.4
^ permalink raw reply related
* Re: [RFC PATCH v2, part4 37/39] mm: use totalram_pages instead of num_physpages at runtime
From: Sergei Shtylyov @ 2013-03-24 12:27 UTC (permalink / raw)
To: Jiang Liu
Cc: Andrew Morton, David Rientjes, Jiang Liu, Wen Congyang,
Mel Gorman, Minchan Kim, KAMEZAWA Hiroyuki, Michal Hocko,
Jianguo Wu, linux-mm, linux-kernel, Miklos Szeredi,
David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, fuse-devel, netdev
In-Reply-To: <1364109934-7851-66-git-send-email-jiang.liu@huawei.com>
Hello.
On 24-03-2013 11:25, Jiang Liu wrote:
> The global variable num_physpages is scheduled to be removed, so use
> totalram_pages instead of num_physpages at runtime.
> Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
> Cc: Miklos Szeredi <miklos@szeredi.hu>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
> Cc: James Morris <jmorris@namei.org>
> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
> Cc: Patrick McHardy <kaber@trash.net>
> Cc: fuse-devel@lists.sourceforge.net
> Cc: linux-kernel@vger.kernel.org
> Cc: netdev@vger.kernel.org
> ---
> fs/fuse/inode.c | 2 +-
> kernel/power/snapshot.c | 4 ++--
> net/ipv4/inet_fragment.c | 2 +-
> 3 files changed, 4 insertions(+), 4 deletions(-)
> diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
> index b730fda..4c2a420 100644
> --- a/fs/fuse/inode.c
> +++ b/fs/fuse/inode.c
> @@ -781,7 +781,7 @@ static const struct super_operations fuse_super_operations = {
> static void sanitize_global_limit(unsigned *limit)
> {
> if (*limit == 0)
> - *limit = ((num_physpages << PAGE_SHIFT) >> 13) /
> + *limit = ((totalram_pages << PAGE_SHIFT) >> 13) /
> sizeof(struct fuse_req);
>
> if (*limit >= 1 << 16)
> diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
> index 0de2857..8b5d1cd 100644
> --- a/kernel/power/snapshot.c
> +++ b/kernel/power/snapshot.c
> @@ -1651,7 +1651,7 @@ unsigned long snapshot_get_image_size(void)
> static int init_header(struct swsusp_info *info)
> {
> memset(info, 0, sizeof(struct swsusp_info));
> - info->num_physpages = num_physpages;
> + info->num_physpages = get_num_physpages();
> info->image_pages = nr_copy_pages;
> info->pages = snapshot_get_image_size();
> info->size = info->pages;
> @@ -1795,7 +1795,7 @@ static int check_header(struct swsusp_info *info)
> char *reason;
>
> reason = check_image_kernel(info);
> - if (!reason && info->num_physpages != num_physpages)
> + if (!reason && info->num_physpages != get_num_physpages())
> reason = "memory size";
> if (reason) {
> printk(KERN_ERR "PM: Image mismatch: %s\n", reason);
> diff --git a/net/ipv4/inet_fragment.c b/net/ipv4/inet_fragment.c
> index 4750d2b..94a99a1 100644
> --- a/net/ipv4/inet_fragment.c
> +++ b/net/ipv4/inet_fragment.c
> @@ -60,7 +60,7 @@ void inet_frags_init(struct inet_frags *f)
>
> rwlock_init(&f->lock);
>
> - f->rnd = (u32) ((num_physpages ^ (num_physpages>>7)) ^
> + f->rnd = (u32) ((totalram_pages ^ (totalram_pages>>7)) ^
> (jiffies ^ (jiffies >> 6)));
>
> setup_timer(&f->secret_timer, inet_frag_secret_rebuild,
Isn't patch 37 the same as patch 9?
WBR, Sergei
^ permalink raw reply
* Re: [PATCH net-next 2/2] ipv6: implement RFC3168 5.3 (ecn protection) for ipv6 fragmentation handling
From: YOSHIFUJI Hideaki @ 2013-03-24 12:28 UTC (permalink / raw)
To: netdev, David Miller
Cc: eric.dumazet, jbrouer, Hannes Frederic Sowa, YOSHIFUJI Hideaki
In-Reply-To: <20130322182444.GA939@order.stressinduktion.org>
Hannes Frederic Sowa wrote:
> [PATCH 2/2] ipv6: implement RFC3168 5.3 (ecn protection) for ipv6 fragmentation handling
>
> This patch also ensures that INET_ECN_CE is propagated if one fragment
> had the codepoint set.
>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Jesper Dangaard Brouer <jbrouer@redhat.com>
> Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
--yoshfuji
^ permalink raw reply
* Re: [RFC PATCH v2, part4 09/39] mm: use totalram_pages instead of num_physpages at runtime
From: Sergei Shtylyov @ 2013-03-24 12:26 UTC (permalink / raw)
To: Jiang Liu
Cc: Andrew Morton, David Rientjes, Jiang Liu, Wen Congyang,
Mel Gorman, Minchan Kim, KAMEZAWA Hiroyuki, Michal Hocko,
Jianguo Wu, linux-mm, linux-kernel, Miklos Szeredi,
David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, fuse-devel, netdev
In-Reply-To: <1364109934-7851-11-git-send-email-jiang.liu@huawei.com>
Hello.
On 24-03-2013 11:24, Jiang Liu wrote:
> The global variable num_physpages is scheduled to be removed, so use
> totalram_pages instead of num_physpages at runtime.
> Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
> Cc: Miklos Szeredi <miklos@szeredi.hu>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
> Cc: James Morris <jmorris@namei.org>
> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
> Cc: Patrick McHardy <kaber@trash.net>
> Cc: fuse-devel@lists.sourceforge.net
> Cc: linux-kernel@vger.kernel.org
> Cc: netdev@vger.kernel.org
[...]
> diff --git a/net/ipv4/inet_fragment.c b/net/ipv4/inet_fragment.c
> index 4750d2b..94a99a1 100644
> --- a/net/ipv4/inet_fragment.c
> +++ b/net/ipv4/inet_fragment.c
> @@ -60,7 +60,7 @@ void inet_frags_init(struct inet_frags *f)
>
> rwlock_init(&f->lock);
>
> - f->rnd = (u32) ((num_physpages ^ (num_physpages>>7)) ^
> + f->rnd = (u32) ((totalram_pages ^ (totalram_pages>>7)) ^
Wouldn't hurt to add spaces around >> for consistency's sake.
> (jiffies ^ (jiffies >> 6)));
>
> setup_timer(&f->secret_timer, inet_frag_secret_rebuild,
WBR, Sergei
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH net-next 1/2] inet: generalize ipv4-only RFC3168 5.3 ecn fragmentation handling for future use by ipv6
From: YOSHIFUJI Hideaki @ 2013-03-24 12:23 UTC (permalink / raw)
To: netdev, David Miller; +Cc: jbrouer, Hannes Frederic Sowa
In-Reply-To: <20130322182437.GC19365@order.stressinduktion.org>
Hannes Frederic Sowa wrote:
> This patch just moves some code arround to make the ip4_frag_ecn_table
> and IPFRAG_ECN_* constants accessible from the other reassembly engines. I
> also renamed ip4_frag_ecn_table to ip_frag_ecn_table.
>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Jesper Dangaard Brouer <jbrouer@redhat.com>
> Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
--yoshfuji
^ permalink raw reply
* Re: [PATCH] net: Add support for handling queueing in hardware
From: Guenter Roeck @ 2013-03-23 19:10 UTC (permalink / raw)
To: Theodore Ts'o, Ben Collins, David Miller, afleming,
linux-kernel, netdev
In-Reply-To: <20130322220840.GA6647@thunk.org>
On Fri, Mar 22, 2013 at 06:08:40PM -0400, Theodore Ts'o wrote:
> On Fri, Mar 22, 2013 at 11:39:20AM -0400, Ben Collins wrote:
> >
> > If your company had hardware going to production, you'd want it supported in mainline too, I suspect.
>
> And if companies told their hardware partners that they will drop use
> of their hardware in future products unless they get their !@#@S
> drivers upstream, I'd bet they'd change their engineering priorities
> so they would work on it, instead of foisting this work on their
> customers.
>
I would love to be in that position. However, the decision to choose
a specific chip is not always coordinated with those who have to provide
the software to run on those chips.
> I've seen this work in enterprise computing, where the RFP had
> requirements for upstream drivers (i.e., if you want your 10gig
> ethernet NIC to be used in HP or IBM's servers, get the darned thing
> upstream!). The trick is making it clear that selection of components
> depends not just on an OSS driver, but an OSS driver which has been
> accepted upstream (which also helps from a quality-of-code
> requirement).
>
> I've been waiting for this to start happening in the consumer
> electronics/embedded world, but it's been slow coming,
> unfortunately....
>
The same applies to vendors of non-consumer network devices, unfortunately.
Guenter
^ 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