* Re: [PATCH v2 3/3] netdev/of/phy: Add MDIO bus multiplexer driven by GPIO lines.
From: Grant Likely @ 2011-09-29 22:01 UTC (permalink / raw)
To: David Daney
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <1317166015-20714-4-git-send-email-david.daney-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
On Tue, Sep 27, 2011 at 04:26:55PM -0700, David Daney wrote:
> The GPIO pins select which sub bus is connected to the master.
>
> Initially tested with an sn74cbtlv3253 switch device wired into the
> MDIO bus.
>
> Signed-off-by: David Daney <david.daney-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
> Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
> Cc: "David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> ---
> .../devicetree/bindings/net/mdio-mux-gpio.txt | 129 ++++++++++++++++++
> drivers/net/phy/Kconfig | 9 ++
> drivers/net/phy/Makefile | 1 +
> drivers/net/phy/mdio-mux-gpio.c | 143 ++++++++++++++++++++
> 4 files changed, 282 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/mdio-mux-gpio.txt
> create mode 100644 drivers/net/phy/mdio-mux-gpio.c
>
> diff --git a/Documentation/devicetree/bindings/net/mdio-mux-gpio.txt b/Documentation/devicetree/bindings/net/mdio-mux-gpio.txt
> new file mode 100644
> index 0000000..8d0f945
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/mdio-mux-gpio.txt
> @@ -0,0 +1,129 @@
> +Properties for an MDIO bus multiplexer/switch controlled by GPIO pins.
> +
> +This is a special case of a MDIO bus multiplexer. One or more GPIO
> +lines are used to control which child bus is connected.
> +
> +Required properties in addition to the generic multiplexer properties:
> +
> +- compatible : Should define the compatible device type for the
> + multiplexer. Currently "cavium,mdio-mux-sn74cbtlv3253"
> + is defined, others are possible.
> +- gpios : GPIO specifiers for each GPIO line. One or more must be specified.
> +
> +
> +Example :
> +
> + /* The parent MDIO bus. */
> + smi1: mdio@1180000001900 {
> + compatible = "cavium,octeon-3860-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x11800 0x00001900 0x0 0x40>;
> + };
> +
> + /*
> + An NXP sn74cbtlv3253 dual 1-of-4 switch controlled by a
> + pair of GPIO lines. Child busses 2 and 3 populated with 4
> + PHYs each.
> + */
> + mdio-mux {
> + compatible = "cavium,mdio-mux-sn74cbtlv3253", "cavium,mdio-mux";
> + gpios = <&gpio1 3 0>, <&gpio1 4 0>;
> + mdio-parent-bus = <&smi1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + mdio@2 {
> + reg = <2>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + phy11: ethernet-phy@1 {
> + reg = <1>;
> + compatible = "marvell,88e1149r";
> + marvell,reg-init = <3 0x10 0 0x5777>,
> + <3 0x11 0 0x00aa>,
> + <3 0x12 0 0x4105>,
> + <3 0x13 0 0x0a60>;
> + interrupt-parent = <&gpio>;
> + interrupts = <10 8>; /* Pin 10, active low */
> + };
> + phy12: ethernet-phy@2 {
> + reg = <2>;
> + compatible = "marvell,88e1149r";
> + marvell,reg-init = <3 0x10 0 0x5777>,
> + <3 0x11 0 0x00aa>,
> + <3 0x12 0 0x4105>,
> + <3 0x13 0 0x0a60>;
> + interrupt-parent = <&gpio>;
> + interrupts = <10 8>; /* Pin 10, active low */
> + };
> + phy13: ethernet-phy@3 {
> + reg = <3>;
> + compatible = "marvell,88e1149r";
> + marvell,reg-init = <3 0x10 0 0x5777>,
> + <3 0x11 0 0x00aa>,
> + <3 0x12 0 0x4105>,
> + <3 0x13 0 0x0a60>;
> + interrupt-parent = <&gpio>;
> + interrupts = <10 8>; /* Pin 10, active low */
> + };
> + phy14: ethernet-phy@4 {
> + reg = <4>;
> + compatible = "marvell,88e1149r";
> + marvell,reg-init = <3 0x10 0 0x5777>,
> + <3 0x11 0 0x00aa>,
> + <3 0x12 0 0x4105>,
> + <3 0x13 0 0x0a60>;
> + interrupt-parent = <&gpio>;
> + interrupts = <10 8>; /* Pin 10, active low */
> + };
> + };
> +
> + mdio@3 {
> + reg = <3>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + phy21: ethernet-phy@1 {
> + reg = <1>;
> + compatible = "marvell,88e1149r";
> + marvell,reg-init = <3 0x10 0 0x5777>,
> + <3 0x11 0 0x00aa>,
> + <3 0x12 0 0x4105>,
> + <3 0x13 0 0x0a60>;
> + interrupt-parent = <&gpio>;
> + interrupts = <12 8>; /* Pin 12, active low */
> + };
> + phy22: ethernet-phy@2 {
> + reg = <2>;
> + compatible = "marvell,88e1149r";
> + marvell,reg-init = <3 0x10 0 0x5777>,
> + <3 0x11 0 0x00aa>,
> + <3 0x12 0 0x4105>,
> + <3 0x13 0 0x0a60>;
> + interrupt-parent = <&gpio>;
> + interrupts = <12 8>; /* Pin 12, active low */
> + };
> + phy23: ethernet-phy@3 {
> + reg = <3>;
> + compatible = "marvell,88e1149r";
> + marvell,reg-init = <3 0x10 0 0x5777>,
> + <3 0x11 0 0x00aa>,
> + <3 0x12 0 0x4105>,
> + <3 0x13 0 0x0a60>;
> + interrupt-parent = <&gpio>;
> + interrupts = <12 8>; /* Pin 12, active low */
> + };
> + phy24: ethernet-phy@4 {
> + reg = <4>;
> + compatible = "marvell,88e1149r";
> + marvell,reg-init = <3 0x10 0 0x5777>,
> + <3 0x11 0 0x00aa>,
> + <3 0x12 0 0x4105>,
> + <3 0x13 0 0x0a60>;
> + interrupt-parent = <&gpio>;
> + interrupts = <12 8>; /* Pin 12, active low */
> + };
> + };
> + };
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index 59848bc..59b3b17 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -127,6 +127,15 @@ config MDIO_BUS_MUX
> to a parent bus. Switching between child busses is done by
> device specific drivers.
>
> +config MDIO_BUS_MUX_GPIO
> + tristate "Support for GPIO controlled MDIO bus multiplexers"
> + depends on MDIO_BUS_MUX && GENERIC_GPIO
> + help
> + This module provides a driver for MDIO bus multiplexers that
> + are controlled via GPIO lines. The multiplexer connects one of
> + several child MDIO busses to a parent bus. Child bus
> + selection is under the control of GPIO lines.
> +
> config MDIO_OCTEON
> tristate "Support for MDIO buses on Octeon SOCs"
> depends on CPU_CAVIUM_OCTEON
> diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
> index 0c081d5..d1a1927 100644
> --- a/drivers/net/phy/Makefile
> +++ b/drivers/net/phy/Makefile
> @@ -24,3 +24,4 @@ obj-$(CONFIG_STE10XP) += ste10Xp.o
> obj-$(CONFIG_MICREL_PHY) += micrel.o
> obj-$(CONFIG_MDIO_OCTEON) += mdio-octeon.o
> obj-$(CONFIG_MDIO_BUS_MUX) += mdio-mux.o
> +obj-$(CONFIG_MDIO_BUS_MUX_GPIO) += mdio-mux-gpio.o
> diff --git a/drivers/net/phy/mdio-mux-gpio.c b/drivers/net/phy/mdio-mux-gpio.c
> new file mode 100644
> index 0000000..3cdad35
> --- /dev/null
> +++ b/drivers/net/phy/mdio-mux-gpio.c
> @@ -0,0 +1,143 @@
> +/*
> + * This file is subject to the terms and conditions of the GNU General Public
> + * License. See the file "COPYING" in the main directory of this archive
> + * for more details.
> + *
> + * Copyright (C) 2011 Cavium Networks
> + */
> +
> +#include <linux/platform_device.h>
> +#include <linux/of_mdio.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/gfp.h>
> +#include <linux/phy.h>
> +#include <linux/mdio-mux.h>
> +#include <linux/of_gpio.h>
> +
> +#define DRV_VERSION "1.0"
> +#define DRV_DESCRIPTION "GPIO controlled MDIO bus multiplexer driver"
> +
> +#define MDIO_MUX_GPIO_MAX_BITS 8
> +
> +struct mdio_mux_gpio_state {
> + int gpio[MDIO_MUX_GPIO_MAX_BITS];
> + unsigned int num_gpios;
> +};
> +
> +static int mdio_mux_gpio_switch_fn(int current_child, int desired_child,
> + void *data)
> +{
> + int change;
> + unsigned int n;
> + struct mdio_mux_gpio_state *s = data;
> +
> + if (current_child == desired_child)
> + return 0;
> +
> + change = current_child == -1 ? -1 : current_child ^ desired_child;
> +
> + for (n = 0; n < s->num_gpios; n++) {
> + if (change & 1)
> + gpio_set_value_cansleep(s->gpio[n],
> + (desired_child & 1) != 0);
> + change >>= 1;
> + desired_child >>= 1;
> + }
> +
> + return 0;
> +}
> +
> +static int __devinit mdio_mux_gpio_probe(struct platform_device *pdev)
> +{
> + enum of_gpio_flags f;
> + struct mdio_mux_gpio_state *s;
> + unsigned int num_gpios;
> + unsigned int n;
> + int r;
> +
> + if (!pdev->dev.of_node)
> + return -ENODEV;
> +
> + num_gpios = of_gpio_count(pdev->dev.of_node);
> + if (num_gpios == 0 || num_gpios > MDIO_MUX_GPIO_MAX_BITS)
> + return -ENODEV;
> +
> + s = devm_kzalloc(&pdev->dev, sizeof(*s), GFP_KERNEL);
> + if (!s)
> + return -ENOMEM;
> +
> + s->num_gpios = num_gpios;
> +
> + for (n = 0; n < num_gpios; ) {
> + int gpio = of_get_named_gpio_flags(pdev->dev.of_node,
> + "gpios", n, &f);
> + s->gpio[n] = gpio;
> + if (gpio < 0) {
> + r = -ENODEV;
> + goto err;
> + }
> +
> + n++;
> +
> + r = gpio_request(gpio, "mdio_mux_gpio");
> + if (r)
> + goto err;
> +
> + r = gpio_direction_output(gpio, 0);
> + if (r)
> + goto err;
> + }
> +
> + r = mdio_mux_probe(pdev, mdio_mux_gpio_switch_fn, s);
> +
> + if (r == 0)
> + return 0;
> +err:
> + while (n) {
> + n--;
> + gpio_free(s->gpio[n]);
> + }
> + devm_kfree(&pdev->dev, s);
Don't need to do this. The probe failed, so the free will automatically happen because devm_kzalloc was used.
> + return r;
> +}
> +
> +static int __devexit mdio_mux_gpio_remove(struct platform_device *pdev)
> +{
> + return 0;
> +}
Don't do empty remove functions.
This driver looks okay, but it needs the unwind stuff for removal, or
it needs to be explicit that it cannot be removed (which also means
that the mdio parent driver becomes unremovable too).
g.
^ permalink raw reply
* Re: Network problem with bridge and virtualbox
From: Nicolas de Pesloüan @ 2011-09-29 21:56 UTC (permalink / raw)
To: William Thompson; +Cc: netdev
In-Reply-To: <20110929124941.GA16567@electro-mechanical.com>
Le 29/09/2011 14:49, William Thompson a écrit :
> Please keep me in the CC as I am not subscribed.
>
> I'm using a 64-bit kernel 3.0.0 and virtualbox 4.1.2.
>
> My problem is that I cannot ping the host from a virtual machine.
>
> My bridge is configured as follows:
> # brctl addbr br0
> # brctl setfd br0 0
> # brctl stp br0 off
> # ifconfig br0 10.2.3.1 netmask 255.255.255.0
>
> In the virtual machine, it is set to use br0 as it's interface (bridge mode)
> and it's IP is 10.2.3.10.
Why do you use bridge with VirtualBox?
VirtualBox provide several network modes, which remove the need for bridge on the host.
One of Bridged Network mode (using eth0), Internal Networking mode or Host-only Networking mode may
suit your need well, without having to use a bridge.
Nicolas.
^ permalink raw reply
* Re: [PATCH v2 2/3] netdev/of/phy: Add MDIO bus multiplexer support.
From: Grant Likely @ 2011-09-29 21:56 UTC (permalink / raw)
To: David Daney; +Cc: devicetree-discuss, linux-kernel, netdev, davem
In-Reply-To: <1317166015-20714-3-git-send-email-david.daney@cavium.com>
On Tue, Sep 27, 2011 at 04:26:54PM -0700, David Daney wrote:
> This patch adds a somewhat generic framework for MDIO bus
> multiplexers. It is modeled on the I2C multiplexer.
>
> The multiplexer is needed if there are multiple PHYs with the same
> address connected to the same MDIO bus adepter, or if there is
> insufficient electrical drive capability for all the connected PHY
> devices.
>
> Conceptually it could look something like this:
>
> ------------------
> | Control Signal |
> --------+---------
> |
> --------------- --------+------
> | MDIO MASTER |---| Multiplexer |
> --------------- --+-------+----
> | |
> C C
> h h
> i i
> l l
> d d
> | |
> --------- A B ---------
> | | | | | |
> | PHY@1 +-------+ +---+ PHY@1 |
> | | | | | |
> --------- | | ---------
> --------- | | ---------
> | | | | | |
> | PHY@2 +-------+ +---+ PHY@2 |
> | | | |
> --------- ---------
>
> This framework configures the bus topology from device tree data. The
> mechanics of switching the multiplexer is left to device specific
> drivers.
>
> The follow-on patch contains a multiplexer driven by GPIO lines.
>
> Signed-off-by: David Daney <david.daney@cavium.com>
> Acked-by: Andy Fleming <afleming@freescale.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: "David S. Miller" <davem@davemloft.net>
> ---
> Documentation/devicetree/bindings/net/mdio-mux.txt | 136 +++++++++++++++
> drivers/net/phy/Kconfig | 8 +
> drivers/net/phy/Makefile | 1 +
> drivers/net/phy/mdio-mux.c | 182 ++++++++++++++++++++
> include/linux/mdio-mux.h | 18 ++
> 5 files changed, 345 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/mdio-mux.txt
> create mode 100644 drivers/net/phy/mdio-mux.c
> create mode 100644 include/linux/mdio-mux.h
>
> diff --git a/Documentation/devicetree/bindings/net/mdio-mux.txt b/Documentation/devicetree/bindings/net/mdio-mux.txt
> new file mode 100644
> index 0000000..5acba65
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/mdio-mux.txt
> @@ -0,0 +1,136 @@
> +Common MDIO bus multiplexer/switch properties.
> +
> +An MDIO bus multiplexer/switch will have several child busses that are
> +numbered uniquely in a device dependent manner. The nodes for an MDIO
> +bus multiplexer/switch will have one child node for each child bus.
> +
> +Required properties:
> +- mdio-parent-bus : phandle to the parent MDIO bus.
> +- #address-cells = <1>;
> +- #size-cells = <0>;
> +
> +Optional properties:
> +- Other properties specific to the multiplexer/switch hardware.
> +
> +Required properties for child nodes:
> +- #address-cells = <1>;
> +- #size-cells = <0>;
> +- reg : The sub-bus number.
> +
> +
> +Example :
> +
> + /* The parent MDIO bus. */
> + smi1: mdio@1180000001900 {
> + compatible = "cavium,octeon-3860-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x11800 0x00001900 0x0 0x40>;
> + };
> +
> + /*
> + An NXP sn74cbtlv3253 dual 1-of-4 switch controlled by a
> + pair of GPIO lines. Child busses 2 and 3 populated with 4
> + PHYs each.
> + */
> + mdio-mux {
> + compatible = "cavium,mdio-mux-sn74cbtlv3253", "cavium,mdio-mux";
> + gpios = <&gpio1 3 0>, <&gpio1 4 0>;
> + mdio-parent-bus = <&smi1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + mdio@2 {
> + reg = <2>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + phy11: ethernet-phy@1 {
> + reg = <1>;
> + compatible = "marvell,88e1149r";
> + marvell,reg-init = <3 0x10 0 0x5777>,
> + <3 0x11 0 0x00aa>,
> + <3 0x12 0 0x4105>,
> + <3 0x13 0 0x0a60>;
> + interrupt-parent = <&gpio>;
> + interrupts = <10 8>; /* Pin 10, active low */
> + };
> + phy12: ethernet-phy@2 {
> + reg = <2>;
> + compatible = "marvell,88e1149r";
> + marvell,reg-init = <3 0x10 0 0x5777>,
> + <3 0x11 0 0x00aa>,
> + <3 0x12 0 0x4105>,
> + <3 0x13 0 0x0a60>;
> + interrupt-parent = <&gpio>;
> + interrupts = <10 8>; /* Pin 10, active low */
> + };
> + phy13: ethernet-phy@3 {
> + reg = <3>;
> + compatible = "marvell,88e1149r";
> + marvell,reg-init = <3 0x10 0 0x5777>,
> + <3 0x11 0 0x00aa>,
> + <3 0x12 0 0x4105>,
> + <3 0x13 0 0x0a60>;
> + interrupt-parent = <&gpio>;
> + interrupts = <10 8>; /* Pin 10, active low */
> + };
> + phy14: ethernet-phy@4 {
> + reg = <4>;
> + compatible = "marvell,88e1149r";
> + marvell,reg-init = <3 0x10 0 0x5777>,
> + <3 0x11 0 0x00aa>,
> + <3 0x12 0 0x4105>,
> + <3 0x13 0 0x0a60>;
> + interrupt-parent = <&gpio>;
> + interrupts = <10 8>; /* Pin 10, active low */
> + };
> + };
> +
> + mdio@3 {
> + reg = <3>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + phy21: ethernet-phy@1 {
> + reg = <1>;
> + compatible = "marvell,88e1149r";
> + marvell,reg-init = <3 0x10 0 0x5777>,
> + <3 0x11 0 0x00aa>,
> + <3 0x12 0 0x4105>,
> + <3 0x13 0 0x0a60>;
> + interrupt-parent = <&gpio>;
> + interrupts = <12 8>; /* Pin 12, active low */
> + };
> + phy22: ethernet-phy@2 {
> + reg = <2>;
> + compatible = "marvell,88e1149r";
> + marvell,reg-init = <3 0x10 0 0x5777>,
> + <3 0x11 0 0x00aa>,
> + <3 0x12 0 0x4105>,
> + <3 0x13 0 0x0a60>;
> + interrupt-parent = <&gpio>;
> + interrupts = <12 8>; /* Pin 12, active low */
> + };
> + phy23: ethernet-phy@3 {
> + reg = <3>;
> + compatible = "marvell,88e1149r";
> + marvell,reg-init = <3 0x10 0 0x5777>,
> + <3 0x11 0 0x00aa>,
> + <3 0x12 0 0x4105>,
> + <3 0x13 0 0x0a60>;
> + interrupt-parent = <&gpio>;
> + interrupts = <12 8>; /* Pin 12, active low */
> + };
> + phy24: ethernet-phy@4 {
> + reg = <4>;
> + compatible = "marvell,88e1149r";
> + marvell,reg-init = <3 0x10 0 0x5777>,
> + <3 0x11 0 0x00aa>,
> + <3 0x12 0 0x4105>,
> + <3 0x13 0 0x0a60>;
> + interrupt-parent = <&gpio>;
> + interrupts = <12 8>; /* Pin 12, active low */
> + };
> + };
> + };
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index a702443..59848bc 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -119,6 +119,14 @@ config MDIO_GPIO
> To compile this driver as a module, choose M here: the module
> will be called mdio-gpio.
>
> +config MDIO_BUS_MUX
> + tristate "Support for MDIO bus multiplexers"
> + help
> + This module provides a driver framework for MDIO bus
> + multiplexers which connect one of several child MDIO busses
> + to a parent bus. Switching between child busses is done by
> + device specific drivers.
> +
Don't make this a user visible option. Make the bus driver select it.
> config MDIO_OCTEON
> tristate "Support for MDIO buses on Octeon SOCs"
> depends on CPU_CAVIUM_OCTEON
> diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
> index 2333215..0c081d5 100644
> --- a/drivers/net/phy/Makefile
> +++ b/drivers/net/phy/Makefile
> @@ -23,3 +23,4 @@ obj-$(CONFIG_DP83640_PHY) += dp83640.o
> obj-$(CONFIG_STE10XP) += ste10Xp.o
> obj-$(CONFIG_MICREL_PHY) += micrel.o
> obj-$(CONFIG_MDIO_OCTEON) += mdio-octeon.o
> +obj-$(CONFIG_MDIO_BUS_MUX) += mdio-mux.o
> diff --git a/drivers/net/phy/mdio-mux.c b/drivers/net/phy/mdio-mux.c
> new file mode 100644
> index 0000000..a940296
> --- /dev/null
> +++ b/drivers/net/phy/mdio-mux.c
> @@ -0,0 +1,182 @@
> +/*
> + * This file is subject to the terms and conditions of the GNU General Public
> + * License. See the file "COPYING" in the main directory of this archive
> + * for more details.
> + *
> + * Copyright (C) 2011 Cavium Networks
> + */
> +
> +#include <linux/platform_device.h>
> +#include <linux/of_mdio.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/gfp.h>
> +#include <linux/phy.h>
> +#include <linux/mdio-mux.h>
> +
> +#define DRV_VERSION "1.0"
> +#define DRV_DESCRIPTION "MDIO bus multiplexer driver"
> +
> +struct mdio_mux_parent_bus {
> + struct mii_bus *mii_bus;
> + int current_child;
> + int parent_id;
> + void *switch_data;
> + int (*switch_fn)(int current_child, int desired_child, void *data);
> +};
> +
> +struct mdio_mux_child_bus {
> + struct mii_bus *mii_bus;
> + struct mdio_mux_parent_bus *parent;
> + int bus_number;
> + int phy_irq[PHY_MAX_ADDR];
> +};
> +
> +/*
> + * The parent bus' lock is used to order access to the switch_fn.
> + */
> +static int mdio_mux_read(struct mii_bus *bus, int phy_id, int regnum)
> +{
> + struct mdio_mux_child_bus *cb = bus->priv;
> + struct mdio_mux_parent_bus *pb = cb->parent;
> + int r;
> +
> + mutex_lock(&pb->mii_bus->mdio_lock);
> + r = pb->switch_fn(pb->current_child, cb->bus_number, pb->switch_data);
> + if (r)
> + goto out;
> +
> + pb->current_child = cb->bus_number;
> +
> + r = pb->mii_bus->read(pb->mii_bus, phy_id, regnum);
> +out:
> + mutex_unlock(&pb->mii_bus->mdio_lock);
> +
> + return r;
> +}
> +
> +/*
> + * The parent bus' lock is used to order access to the switch_fn.
> + */
> +static int mdio_mux_write(struct mii_bus *bus, int phy_id,
> + int regnum, u16 val)
> +{
> + struct mdio_mux_child_bus *cb = bus->priv;
> + struct mdio_mux_parent_bus *pb = cb->parent;
> +
> + int r;
> +
> + mutex_lock(&pb->mii_bus->mdio_lock);
> + r = pb->switch_fn(pb->current_child, cb->bus_number, pb->switch_data);
> + if (r)
> + goto out;
> +
> + pb->current_child = cb->bus_number;
> +
> + r = pb->mii_bus->write(pb->mii_bus, phy_id, regnum, val);
> +out:
> + mutex_unlock(&pb->mii_bus->mdio_lock);
> +
> + return r;
> +}
> +
> +static int parent_count;
> +
> +int mdio_mux_probe(struct platform_device *pdev,
> + int (*switch_fn)(int cur, int desired, void *data),
> + void *data)
> +{
Don't call this probe. Probe typically means top level driver, but
this module is a library used by MDIO mux drivers. Call this
functions something like init. Also, passing it a platform_device
looks wrong since it might be a platform_device, but it might be an
i2c_client or an spi_device. Pass in struct device instead.
Also, this function should return the pointer to the allocated
mdio_mux_parent_bus so that the calling driver has a reference to it.
> + struct device_node *parent_bus_node;
> + struct device_node *child_bus_node;
> + int r, n, ret_val;
> + struct mii_bus *parent_bus;
> + struct mdio_mux_parent_bus *pb;
> + struct mdio_mux_child_bus *cb;
> +
> + if (!pdev->dev.of_node)
> + return -ENODEV;
> +
> + parent_bus_node = of_parse_phandle(pdev->dev.of_node, "mdio-parent-bus", 0);
> +
> + if (!parent_bus_node)
> + return -ENODEV;
> +
> + parent_bus = of_mdio_find_bus(parent_bus_node);
What if of_mdio_find_bus() fails?
> +
> + pb = devm_kzalloc(&pdev->dev, sizeof(*pb), GFP_KERNEL);
> + if (pb == NULL) {
> + ret_val = -ENOMEM;
> + goto err_parent_bus;
> + }
> +
> + pb->switch_data = data;
> + pb->switch_fn = switch_fn;
> + pb->current_child = -1;
> + pb->parent_id = parent_count++;
> + pb->mii_bus = parent_bus;
> +
> + n = 0;
> + for_each_child_of_node(pdev->dev.of_node, child_bus_node) {
> + u32 v;
> +
> + r = of_property_read_u32(child_bus_node, "reg", &v);
> + if (r == 0) {
> + cb = devm_kzalloc(&pdev->dev, sizeof(*cb), GFP_KERNEL);
> + if (cb == NULL)
> + break;
> + cb->bus_number = v;
> + cb->parent = pb;
> + cb->mii_bus = mdiobus_alloc();
> + cb->mii_bus->priv = cb;
> +
> + cb->mii_bus->irq = cb->phy_irq;
> + cb->mii_bus->name = "mdio_mux";
> + snprintf(cb->mii_bus->id, MII_BUS_ID_SIZE, "%x.%x",
> + pb->parent_id, v);
> + cb->mii_bus->parent = &pdev->dev;
> + cb->mii_bus->read = mdio_mux_read;
> + cb->mii_bus->write = mdio_mux_write;
The parent bus should probably maintain a list of all child busses so
that a shutdown function can tear it all down again.
> + r = of_mdiobus_register(cb->mii_bus, child_bus_node);
> + if (r) {
> + of_node_put(child_bus_node);
> + devm_kfree(&pdev->dev, cb);
> + } else {
> + n++;
> + }
> +
> + } else {
> + of_node_put(child_bus_node);
> + }
> + }
> + if (n) {
> + dev_info(&pdev->dev, "Version " DRV_VERSION "\n");
> + return 0;
> + }
> + ret_val = -ENOMEM;
> + devm_kfree(&pdev->dev, pb);
> +err_parent_bus:
> + of_node_put(parent_bus_node);
> + return ret_val;
> +}
> +EXPORT_SYMBOL(mdio_mux_probe);
> +
> +static int __devexit mdio_mux_remove(struct platform_device *pdev)
> +{
> + return 0;
> +}
> +
> +static int __init mdio_mux_mod_init(void)
> +{
> + return 0;
> +}
> +module_init(mdio_mux_mod_init);
> +
> +static void __exit mdio_mux_mod_exit(void)
> +{
> +}
> +module_exit(mdio_mux_mod_exit);
I don't believe that you need module empty module init/exit/remove
routines. Just drop them.
> +
> +MODULE_DESCRIPTION(DRV_DESCRIPTION);
> +MODULE_VERSION(DRV_VERSION);
> +MODULE_AUTHOR("David Daney");
> +MODULE_LICENSE("GPL");
> diff --git a/include/linux/mdio-mux.h b/include/linux/mdio-mux.h
> new file mode 100644
> index 0000000..522992a
> --- /dev/null
> +++ b/include/linux/mdio-mux.h
> @@ -0,0 +1,18 @@
> +/*
> + * MDIO bus multiplexer framwork.
> + *
> + * This file is subject to the terms and conditions of the GNU General Public
> + * License. See the file "COPYING" in the main directory of this archive
> + * for more details.
> + *
> + * Copyright (C) 2011 Cavium Networks
> + */
> +#ifndef __LINUX_MDIO_MUX_H
> +#define __LINUX_MDIO_MUX_H
> +#include <linux/platform_device.h>
> +
> +int mdio_mux_probe(struct platform_device *pdev,
> + int (*switch_fn) (int cur, int desired, void *data),
> + void *data);
> +
> +#endif /* __LINUX_MDIO_MUX_H */
> --
> 1.7.2.3
>
^ permalink raw reply
* Re: Problem with ARP-replies on Kernels 2.6 (possibly 3.0, but not 2.4!)
From: Nicolas de Pesloüan @ 2011-09-29 21:43 UTC (permalink / raw)
To: skandranon, netdev@vger.kernel.org
In-Reply-To: <4E8390E4.7080104@gmx.at>
Le 28/09/2011 23:25, skandranon a écrit :
>>> So: Is this a bug or a feature?
>>
>> It is a feature.
>>
>> You should have a look at the file Documentation/networking/ip-sysctl in the kernel source tree,
>> in particular the entry about arp_ignore.
>>
>> Nicolas.
> Many thanks for your quick reply and the pointer to that document.
Please, keep netdev in copy.
> Seems this feature has been there a long time already, but this has been the first time in all of
> the 15 years or so I'm working with Linux that It's bitten my ass.
>
> May I ask you for an additional pointer explaining in layman's terms what the use cases for values 2
> and 3 would be? - I plain don't understand.
2 seems obvious and is one more level of strictness. If the ARP seems to come from a different
subnet, ignore it, even if it enters the host on the "right" interface.
I don't know for 3.
> And maybe even an explanation what the initial reasoning might have been to select the approach of
> assigning IP addresses to the host instead of an interface?
I think it is expected to enhance connectivity, by being liberal at what the host accept, which is
the base principle of interoperability : Be liberal in what you accept, and conservative in what you
send [Jon Postel]. Others may explain this with more history in mind.
> The mailing list archive mentioned in e.g. "Understanding Linux Network Internals" I found after
> having your hint as a starting point doesn't seem to contain this discussion, which has obviously
> been old even back in 2003.
> And how come that the 2.4.21 kernel did behave differently? The basics seem to be the same?
Unfortunately, I'm not an archaeologist, so I'm totally unable to answer about 2.4.21. Maybe someone
else in the list will be.
Nicolas.
^ permalink raw reply
* Re: [PATCH v2 1/3] netdev/of/phy: New function: of_mdio_find_bus().
From: Grant Likely @ 2011-09-29 21:41 UTC (permalink / raw)
To: David Daney; +Cc: devicetree-discuss, linux-kernel, netdev, davem
In-Reply-To: <1317166015-20714-2-git-send-email-david.daney@cavium.com>
On Tue, Sep 27, 2011 at 04:26:53PM -0700, David Daney wrote:
> Add of_mdio_find_bus() which allows an mii_bus to be located given its
> associated the device tree node.
>
> This is needed by the follow-on patch to add a driver for MDIO bus
> multiplexers.
>
> The of_mdiobus_register() function is modified so that the device tree
> node is recorded in the mii_bus. Then we can find it again by
> iterating over all mdio_bus_class devices.
>
> Signed-off-by: David Daney <david.daney@cavium.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: "David S. Miller" <davem@davemloft.net>
> ---
> drivers/net/phy/mdio_bus.c | 3 ++-
> drivers/of/of_mdio.c | 26 ++++++++++++++++++++++++++
> include/linux/of_mdio.h | 2 ++
> include/linux/phy.h | 1 +
> 4 files changed, 31 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
> index 6c58da2..227a060 100644
> --- a/drivers/net/phy/mdio_bus.c
> +++ b/drivers/net/phy/mdio_bus.c
> @@ -70,10 +70,11 @@ static void mdiobus_release(struct device *d)
> kfree(bus);
> }
>
> -static struct class mdio_bus_class = {
> +struct class mdio_bus_class = {
> .name = "mdio_bus",
> .dev_release = mdiobus_release,
> };
> +EXPORT_SYMBOL(mdio_bus_class);
Instead of exporting this, move the iterator into this file. Assuming
Andy and David are okay with it, I don't see any reason to continue to
keep the MDIO DT support outside of drivers/net/phy.
Bonus points if you craft a patch to move the existing MDIO DT
support code.
Otherwise, the patch looks good.
g.
>
> /**
> * mdiobus_register - bring up all the PHYs on a given bus and attach them to bus
> diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
> index d35e300..7c28e8c 100644
> --- a/drivers/of/of_mdio.c
> +++ b/drivers/of/of_mdio.c
> @@ -45,6 +45,8 @@ int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
> for (i=0; i<PHY_MAX_ADDR; i++)
> mdio->irq[i] = PHY_POLL;
>
> + mdio->dev.of_node = np;
> +
> /* Register the MDIO bus */
> rc = mdiobus_register(mdio);
> if (rc)
> @@ -189,3 +191,27 @@ struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
> return IS_ERR(phy) ? NULL : phy;
> }
> EXPORT_SYMBOL(of_phy_connect_fixed_link);
> +
> +/**
> + * of_mdio_find_bus - Given an mii_bus node, find the mii_bus.
> + * @mdio_np: Pointer to the mii_bus.
> + *
> + * Returns a pointer to the mii_bus, or NULL if none found.
> + *
> + * Because the association of a device_node and mii_bus is made via
> + * of_mdiobus_register(), the mii_bus cannot be found before it is
> + * registered with of_mdiobus_register().
> + *
> + */
> +struct mii_bus *of_mdio_find_bus(struct device_node *mdio_np)
> +{
> + struct device *d;
> +
> + if (!mdio_np)
> + return NULL;
> +
> + d = class_find_device(&mdio_bus_class, NULL, mdio_np, of_phy_match);
> +
> + return d ? to_mii_bus(d) : NULL;
> +}
> +EXPORT_SYMBOL(of_mdio_find_bus);
> diff --git a/include/linux/of_mdio.h b/include/linux/of_mdio.h
> index 53b94e0..912c27a 100644
> --- a/include/linux/of_mdio.h
> +++ b/include/linux/of_mdio.h
> @@ -22,4 +22,6 @@ extern struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
> void (*hndlr)(struct net_device *),
> phy_interface_t iface);
>
> +extern struct mii_bus *of_mdio_find_bus(struct device_node *mdio_np);
> +
> #endif /* __LINUX_OF_MDIO_H */
> diff --git a/include/linux/phy.h b/include/linux/phy.h
> index 54fc413..e4c3844 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -528,4 +528,5 @@ int __init mdio_bus_init(void);
> void mdio_bus_exit(void);
>
> extern struct bus_type mdio_bus_type;
> +extern struct class mdio_bus_class;
> #endif /* __PHY_H */
> --
> 1.7.2.3
>
^ permalink raw reply
* Re: [net-next 1/9] igb: Update RXDCTL/TXDCTL configurations
From: Alexander Duyck @ 2011-09-29 21:29 UTC (permalink / raw)
To: Arnaud Lacombe; +Cc: Jeff Kirsher, davem, netdev, gospo
In-Reply-To: <CACqU3MV64hahK0s7nDqNaRemZiygq33BgaY6_v9hh0iKX42Mfw@mail.gmail.com>
This is due to a HW errata. Specifically HW errata 26 in the spec
update at
http://download.intel.com/design/network/specupdt/82576_SPECUPDATE.pdf.
It essentially states that write back does not occur on MSI-X interrupt
events so we need to keep WTHRESH at 1 in order to avoid any false hangs.
Thanks,
Alex
On 09/29/2011 10:41 AM, Arnaud Lacombe wrote:
> Hi,
>
> On Tue, Sep 20, 2011 at 3:11 AM, Jeff Kirsher
> <jeffrey.t.kirsher@intel.com> wrote:
>> From: Alexander Duyck<alexander.h.duyck@intel.com>
>>
>> This change cleans up the RXDCTL and TXDCTL configurations and optimizes RX
>> performance by allowing back write-backs on all hardware other than 82576.
>>
> Where does this limitation comes from ? The "Intel 82576EB GbE
> Controller - Programming Interface" from May 2011 advertises that both
> the RXDCTL and TXDCTL register have a 5bit wide WTHRESH field.
>
> Thanks,
> - Arnaud
>
>> Signed-off-by: Alexander Duyck<alexander.h.duyck@intel.com>
>> Tested-by: Aaron Brown<aaron.f.brown@intel.com>
>> Signed-off-by: Jeff Kirsher<jeffrey.t.kirsher@intel.com>
>> ---
>> drivers/net/ethernet/intel/igb/igb.h | 5 +++--
>> drivers/net/ethernet/intel/igb/igb_main.c | 23 +++++++++--------------
>> 2 files changed, 12 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/intel/igb/igb.h b/drivers/net/ethernet/intel/igb/igb.h
>> index 265e151..577fd3e 100644
>> --- a/drivers/net/ethernet/intel/igb/igb.h
>> +++ b/drivers/net/ethernet/intel/igb/igb.h
>> @@ -100,11 +100,12 @@ struct vf_data_storage {
>> */
>> #define IGB_RX_PTHRESH 8
>> #define IGB_RX_HTHRESH 8
>> -#define IGB_RX_WTHRESH 1
>> #define IGB_TX_PTHRESH 8
>> #define IGB_TX_HTHRESH 1
>> +#define IGB_RX_WTHRESH ((hw->mac.type == e1000_82576&& \
>> + adapter->msix_entries) ? 1 : 4)
>> #define IGB_TX_WTHRESH ((hw->mac.type == e1000_82576&& \
>> - adapter->msix_entries) ? 1 : 16)
>> + adapter->msix_entries) ? 1 : 16)
>>
>> /* this is the size past which hardware will drop packets when setting LPE=0 */
>> #define MAXIMUM_ETHERNET_VLAN_SIZE 1522
>> diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
>> index 3cb1bc9..aa78c10 100644
>> --- a/drivers/net/ethernet/intel/igb/igb_main.c
>> +++ b/drivers/net/ethernet/intel/igb/igb_main.c
>> @@ -2666,14 +2666,12 @@ void igb_configure_tx_ring(struct igb_adapter *adapter,
>> struct igb_ring *ring)
>> {
>> struct e1000_hw *hw =&adapter->hw;
>> - u32 txdctl;
>> + u32 txdctl = 0;
>> u64 tdba = ring->dma;
>> int reg_idx = ring->reg_idx;
>>
>> /* disable the queue */
>> - txdctl = rd32(E1000_TXDCTL(reg_idx));
>> - wr32(E1000_TXDCTL(reg_idx),
>> - txdctl& ~E1000_TXDCTL_QUEUE_ENABLE);
>> + wr32(E1000_TXDCTL(reg_idx), 0);
>> wrfl();
>> mdelay(10);
>>
>> @@ -2685,7 +2683,7 @@ void igb_configure_tx_ring(struct igb_adapter *adapter,
>>
>> ring->head = hw->hw_addr + E1000_TDH(reg_idx);
>> ring->tail = hw->hw_addr + E1000_TDT(reg_idx);
>> - writel(0, ring->head);
>> + wr32(E1000_TDH(reg_idx), 0);
>> writel(0, ring->tail);
>>
>> txdctl |= IGB_TX_PTHRESH;
>> @@ -3028,12 +3026,10 @@ void igb_configure_rx_ring(struct igb_adapter *adapter,
>> struct e1000_hw *hw =&adapter->hw;
>> u64 rdba = ring->dma;
>> int reg_idx = ring->reg_idx;
>> - u32 srrctl, rxdctl;
>> + u32 srrctl = 0, rxdctl = 0;
>>
>> /* disable the queue */
>> - rxdctl = rd32(E1000_RXDCTL(reg_idx));
>> - wr32(E1000_RXDCTL(reg_idx),
>> - rxdctl& ~E1000_RXDCTL_QUEUE_ENABLE);
>> + wr32(E1000_RXDCTL(reg_idx), 0);
>>
>> /* Set DMA base address registers */
>> wr32(E1000_RDBAL(reg_idx),
>> @@ -3045,7 +3041,7 @@ void igb_configure_rx_ring(struct igb_adapter *adapter,
>> /* initialize head and tail */
>> ring->head = hw->hw_addr + E1000_RDH(reg_idx);
>> ring->tail = hw->hw_addr + E1000_RDT(reg_idx);
>> - writel(0, ring->head);
>> + wr32(E1000_RDH(reg_idx), 0);
>> writel(0, ring->tail);
>>
>> /* set descriptor configuration */
>> @@ -3076,13 +3072,12 @@ void igb_configure_rx_ring(struct igb_adapter *adapter,
>> /* set filtering for VMDQ pools */
>> igb_set_vmolr(adapter, reg_idx& 0x7, true);
>>
>> - /* enable receive descriptor fetching */
>> - rxdctl = rd32(E1000_RXDCTL(reg_idx));
>> - rxdctl |= E1000_RXDCTL_QUEUE_ENABLE;
>> - rxdctl&= 0xFFF00000;
>> rxdctl |= IGB_RX_PTHRESH;
>> rxdctl |= IGB_RX_HTHRESH<< 8;
>> rxdctl |= IGB_RX_WTHRESH<< 16;
>> +
>> + /* enable receive descriptor fetching */
>> + rxdctl |= E1000_RXDCTL_QUEUE_ENABLE;
>> wr32(E1000_RXDCTL(reg_idx), rxdctl);
>> }
>>
>> --
>> 1.7.6.2
>>
>> --
>> 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
>>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: linux-next: manual merge of the moduleh tree with the net tree
From: Paul Gortmaker @ 2011-09-29 20:47 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Pavel Roskin, John W. Linville,
David Miller, netdev
In-Reply-To: <20110928163406.843e4be56b42dca280d85489@canb.auug.org.au>
[linux-next: manual merge of the moduleh tree with the net tree] On 28/09/2011 (Wed 16:34) Stephen Rothwell wrote:
> Hi Paul,
>
> Today's linux-next merge of the moduleh tree got a conflict in
> drivers/net/wireless/ath/ath5k/debug.c between commit 931be260ed54
> ("ath5k: clean up base.h and its use") from the net tree and commits
> 9ec3f961e31a ("drivers/net: Add export.h to files using
> EXPORT_SYMBOL/THIS_MODULE") and 0cccb17382f1 ("drivers/net: Add
> moduleparam.h to drivers as required") from the moduleh tree.
>
> I fixed it up (see below) and can carry the fix as necessary. (I am
> pretty sure that this file doesn't need module.h, but not completely).
The conflict is gone, but you were correct in your original assessment
that the module.h was no longer needed. I've added this to the
post-merge queue of patches.
Thanks,
Paul.
>From 13a6768b382b3d2f96b9caa9fa6df1f2f7f3aeb6 Mon Sep 17 00:00:00 2001
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Thu, 29 Sep 2011 16:37:30 -0400
Subject: [PATCH] drivers/net: wireless/ath/ath5k/debug.c does not need
module.h
It only has module_param and EXPORT_SYMBOL, so now that export.h
is in scope at the same time as the recent ath5k update, we can
delete this module.h include.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
diff --git a/drivers/net/wireless/ath/ath5k/debug.c b/drivers/net/wireless/ath/ath5k/debug.c
index d2bdd90..f542b41 100644
--- a/drivers/net/wireless/ath/ath5k/debug.c
+++ b/drivers/net/wireless/ath/ath5k/debug.c
@@ -59,8 +59,6 @@
*/
#include <linux/export.h>
#include <linux/moduleparam.h>
-
-#include <linux/module.h>
#include <linux/seq_file.h>
#include <linux/list.h>
#include "debug.h"
--
1.7.6
^ permalink raw reply related
* Re: [PATCH v2 0/3] netdev/of/phy: MDIO bus multiplexer support.
From: David Miller @ 2011-09-29 20:31 UTC (permalink / raw)
To: david.daney; +Cc: devicetree-discuss, grant.likely, linux-kernel, netdev
In-Reply-To: <1317166015-20714-1-git-send-email-david.daney@cavium.com>
From: David Daney <david.daney@cavium.com>
Date: Tue, 27 Sep 2011 16:26:52 -0700
> v2: Update bindings to use "reg" and "mdio-parent-bus" insutead of
> "cell-index" and "parent-bus"
Grant, when the final version of this patch set is ready how do
you want to handle merging it in?
I think it would be safe to merge this via your tree, since the
changes made to existing network driver files are rather trivial and
thus merge conflict friendly.
Actually, I feel like we've discussed this before :-)
^ permalink raw reply
* Re: [net-next 0/8][pull request] Intel Wired LAN Drivers Update
From: David Miller @ 2011-09-29 19:48 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo
In-Reply-To: <1317277816-6024-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 28 Sep 2011 23:30:08 -0700
> The following series contains updates to e1000, ixgbe and ixgbevf. This
> series is missing the if_link and ixgbe patches for the additional
> parameter for spoof checking, since Greg is re-working those patches
> currently.
>
> The following are changes since commit 2e1143742789463c00ed5e7f9bf471f2b707b493:
> candev: allow SJW user setting for bittiming calculation
> and are available in the git repository at:
> git://github.com/Jkirsher/net-next.git
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH net/stable] can bcm: fix incomplete tx_setup fix
From: David Miller @ 2011-09-29 19:38 UTC (permalink / raw)
To: socketcan; +Cc: netdev, stable, nautsch
In-Reply-To: <4E84C4B9.7020706@hartkopp.net>
From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Thu, 29 Sep 2011 21:19:21 +0200
> The commit aabdcb0b553b9c9547b1a506b34d55a764745870 ("can bcm: fix tx_setup
> off-by-one errors") fixed only a part of the original problem reported by
> Andre Naujoks. It turned out that the original code needed to be re-ordered
> to reduce complexity and to finally fix the reported frame counting issues.
>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net-proc: expose the tos values in /proc/net/[tcp|udp]
From: David Miller @ 2011-09-29 19:32 UTC (permalink / raw)
To: muralira; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <1317324162-21621-1-git-send-email-muralira@google.com>
From: Muraliraja Muniraju <muralira@google.com>
Date: Thu, 29 Sep 2011 12:22:42 -0700
> From: Murali Raja <muralira@google.com>
>
> This patch exports the tos values from the inet_sock struct
> for tcp and udp into the /proc/net/tcp or /proc/net/udp respectively.
> This will not pickup per packet tos changes but it will address most
> of the cases. This is mainly useful as it would decrease reliance on
> tcpdump and also people without root access will be able to read
> the values.
>
> Signed-off-by: Murali Raja <muralira@google.com>
You cannot change the layout of these files, they are parsed by userland
problems and therefore have a fixed API.
Netlink based socket dumping provides a proper, backwards compatible,
way to extend what is reported, so please consider adding your changes
there.
^ permalink raw reply
* [PATCH net/stable] can bcm: fix incomplete tx_setup fix
From: Oliver Hartkopp @ 2011-09-29 19:19 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, stable, Andre Naujoks
The commit aabdcb0b553b9c9547b1a506b34d55a764745870 ("can bcm: fix tx_setup
off-by-one errors") fixed only a part of the original problem reported by
Andre Naujoks. It turned out that the original code needed to be re-ordered
to reduce complexity and to finally fix the reported frame counting issues.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
---
@Andre: I checked the changes (which make the code much clearer now) against
your test program and some of mine i modified to test all flags like
STARTTIMER, SETTIMER, TX_ANNOUNCE in different configurations. Please double
check with your setup and send a Tested-by: if it is ok for you.
@Dave: Again sorry for this second patch. The first patch looked sane and
fixed the reported issue - but obviously not the whole problem :-(
bcm.c | 48 +++++++++++++++++++++---------------------------
1 file changed, 21 insertions(+), 27 deletions(-)
diff --git a/net/can/bcm.c b/net/can/bcm.c
index c9cdb8d..c84963d 100644
--- a/net/can/bcm.c
+++ b/net/can/bcm.c
@@ -344,6 +344,18 @@ static void bcm_send_to_user(struct bcm_op *op, struct bcm_msg_head *head,
}
}
+static void bcm_tx_start_timer(struct bcm_op *op)
+{
+ if (op->kt_ival1.tv64 && op->count)
+ hrtimer_start(&op->timer,
+ ktime_add(ktime_get(), op->kt_ival1),
+ HRTIMER_MODE_ABS);
+ else if (op->kt_ival2.tv64)
+ hrtimer_start(&op->timer,
+ ktime_add(ktime_get(), op->kt_ival2),
+ HRTIMER_MODE_ABS);
+}
+
static void bcm_tx_timeout_tsklet(unsigned long data)
{
struct bcm_op *op = (struct bcm_op *)data;
@@ -365,23 +377,12 @@ static void bcm_tx_timeout_tsklet(unsigned long data)
bcm_send_to_user(op, &msg_head, NULL, 0);
}
-
- /* send (next) frame */
bcm_can_tx(op);
- hrtimer_start(&op->timer,
- ktime_add(ktime_get(), op->kt_ival1),
- HRTIMER_MODE_ABS);
- } else {
- if (op->kt_ival2.tv64) {
+ } else if (op->kt_ival2.tv64)
+ bcm_can_tx(op);
- /* send (next) frame */
- bcm_can_tx(op);
- hrtimer_start(&op->timer,
- ktime_add(ktime_get(), op->kt_ival2),
- HRTIMER_MODE_ABS);
- }
- }
+ bcm_tx_start_timer(op);
}
/*
@@ -961,28 +962,21 @@ static int bcm_tx_setup(struct bcm_msg_head *msg_head, struct msghdr *msg,
hrtimer_cancel(&op->timer);
}
- if ((op->flags & STARTTIMER) &&
- ((op->kt_ival1.tv64 && op->count) || op->kt_ival2.tv64)) {
-
+ if (op->flags & STARTTIMER) {
+ hrtimer_cancel(&op->timer);
/* spec: send can_frame when starting timer */
op->flags |= TX_ANNOUNCE;
-
- /* only start timer when having more frames than sent below */
- if (op->kt_ival1.tv64 && (op->count > 1)) {
- /* op->count-- is done in bcm_tx_timeout_tsklet */
- hrtimer_start(&op->timer, op->kt_ival1,
- HRTIMER_MODE_REL);
- } else
- hrtimer_start(&op->timer, op->kt_ival2,
- HRTIMER_MODE_REL);
}
if (op->flags & TX_ANNOUNCE) {
bcm_can_tx(op);
- if (op->kt_ival1.tv64 && (op->count > 0))
+ if (op->count)
op->count--;
}
+ if (op->flags & STARTTIMER)
+ bcm_tx_start_timer(op);
+
return msg_head->nframes * CFSIZ + MHSIZ;
}
^ permalink raw reply related
* [PATCH] net-proc: expose the tos values in /proc/net/[tcp|udp]
From: Muraliraja Muniraju @ 2011-09-29 19:22 UTC (permalink / raw)
To: David S. Miller", Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy <ka
Cc: netdev, linux-kernel, Murali Raja
From: Murali Raja <muralira@google.com>
This patch exports the tos values from the inet_sock struct
for tcp and udp into the /proc/net/tcp or /proc/net/udp respectively.
This will not pickup per packet tos changes but it will address most
of the cases. This is mainly useful as it would decrease reliance on
tcpdump and also people without root access will be able to read
the values.
Signed-off-by: Murali Raja <muralira@google.com>
---
net/ipv4/tcp_ipv4.c | 7 +++++--
net/ipv4/udp.c | 5 +++--
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index dd3fad9..b036184 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -2416,6 +2416,7 @@ static void get_tcp4_sock(struct sock *sk, struct seq_file *f, int i, int *len)
__u16 destp = ntohs(inet->inet_dport);
__u16 srcp = ntohs(inet->inet_sport);
int rx_queue;
+ unsigned int tos;
if (icsk->icsk_pending == ICSK_TIME_RETRANS) {
timer_active = 1;
@@ -2439,8 +2440,10 @@ static void get_tcp4_sock(struct sock *sk, struct seq_file *f, int i, int *len)
*/
rx_queue = max_t(int, tp->rcv_nxt - tp->copied_seq, 0);
+ tos = inet->tos;
+
seq_printf(f, "%4d: %08X:%04X %08X:%04X %02X %08X:%08X %02X:%08lX "
- "%08X %5d %8d %lu %d %pK %lu %lu %u %u %d%n",
+ "%08X %5d %8d %lu %d %pK %lu %lu %u %u %d %u%n",
i, src, srcp, dest, destp, sk->sk_state,
tp->write_seq - tp->snd_una,
rx_queue,
@@ -2455,7 +2458,7 @@ static void get_tcp4_sock(struct sock *sk, struct seq_file *f, int i, int *len)
jiffies_to_clock_t(icsk->icsk_ack.ato),
(icsk->icsk_ack.quick << 1) | icsk->icsk_ack.pingpong,
tp->snd_cwnd,
- tcp_in_initial_slowstart(tp) ? -1 : tp->snd_ssthresh,
+ tcp_in_initial_slowstart(tp) ? -1 : tp->snd_ssthresh, tos,
len);
}
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index ebaa96b..588786e 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -2092,15 +2092,16 @@ static void udp4_format_sock(struct sock *sp, struct seq_file *f,
__be32 src = inet->inet_rcv_saddr;
__u16 destp = ntohs(inet->inet_dport);
__u16 srcp = ntohs(inet->inet_sport);
+ unsigned int tos = inet->tos;
seq_printf(f, "%5d: %08X:%04X %08X:%04X"
- " %02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %pK %d%n",
+ " %02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %pK %d %d%n",
bucket, src, srcp, dest, destp, sp->sk_state,
sk_wmem_alloc_get(sp),
sk_rmem_alloc_get(sp),
0, 0L, 0, sock_i_uid(sp), 0, sock_i_ino(sp),
atomic_read(&sp->sk_refcnt), sp,
- atomic_read(&sp->sk_drops), len);
+ atomic_read(&sp->sk_drops), tos, len);
}
int udp4_seq_show(struct seq_file *seq, void *v)
--
1.7.3.1
^ permalink raw reply related
* Re: Question about memory leak detector giving false positive report for net/core/flow.c
From: Tejun Heo @ 2011-09-29 19:07 UTC (permalink / raw)
To: Catalin Marinas
Cc: Christoph Lameter, Eric Dumazet, Huajun Li, linux-mm@kvack.org,
netdev, linux-kernel
In-Reply-To: <20110929141809.GD32023@e102109-lin.cambridge.arm.com>
On Thu, Sep 29, 2011 at 03:18:10PM +0100, Catalin Marinas wrote:
> On Thu, Sep 29, 2011 at 03:08:47PM +0100, Christoph Lameter wrote:
> > On Wed, 28 Sep 2011, Catalin Marinas wrote:
> >
> > > I tried this but it's tricky. The problem is that the percpu pointer
> > > returned by alloc_percpu() does not directly point to the per-cpu chunks
> > > and kmemleak would report most percpu allocations as leaks. So far the
> > > workaround is to simply mark the alloc_percpu() objects as never leaking
> > > and at least we avoid false positives in other areas. See the patch
> > > below (note that you have to increase the CONFIG_KMEMLEAK_EARLY_LOG_SIZE
> > > as there are many alloc_percpu() calls before kmemleak is fully
> > > initialised):
> >
> > Seems that kernel.org is out and so tejon wont be seeing these.
>
> That's ok, I don't aim this at the upcoming merging window. I don't have
> an alternative email address for him.
That's htejun@gmail.com but as long as lkml is cc'd I can read the
emails. Lack of replies is more due to the month long vacation which
just ended. ;)
Thank you.
--
tejun
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] RDSRDMA: Fix cleanup of rds_iw_mr_pool
From: David Miller @ 2011-09-29 18:57 UTC (permalink / raw)
To: jonathan; +Cc: venkat.x.venkatsubra, netdev
In-Reply-To: <20110929175841.17682.27846.stgit@build.ogc.int>
From: Jonathan Lallinger <jonathan@ogc.us>
Date: Thu, 29 Sep 2011 12:58:41 -0500
> In the rds_iw_mr_pool struct the free_pinned field keeps track of
> memory pinned by free MRs. While this field is incremented properly
> upon allocation, it is never decremented upon unmapping. This would
> cause the rds_rdma module to crash the kernel upon unloading, by
> triggering the BUG_ON in the rds_iw_destroy_mr_pool function.
>
> This change keeps track of the MRs that become unpinned, so that
> free_pinned can be decremented appropriately.
>
> Signed-off-by: Jonathan Lallinger <jonathan@ogc.us>
> Signed-off-by: Steve Wise <swise@ogc.us>
Applied.
^ permalink raw reply
* Re: [PATCH] net: Documentation: Fix type of variables
From: David Miller @ 2011-09-29 18:57 UTC (permalink / raw)
To: rongqing.li; +Cc: netdev
In-Reply-To: <1317275514-12620-1-git-send-email-rongqing.li@windriver.com>
From: <rongqing.li@windriver.com>
Date: Thu, 29 Sep 2011 13:51:54 +0800
> From: Roy.Li <rongqing.li@windriver.com>
>
>
> Signed-off-by: Roy.Li <rongqing.li@windriver.com>
Applied.
^ permalink raw reply
* Re: [patch] usbnet: add timestamping support
From: David Miller @ 2011-09-29 18:55 UTC (permalink / raw)
To: michael; +Cc: netdev, oneukum
In-Reply-To: <1317305186-32700-1-git-send-email-michael@riesch.at>
From: Michael Riesch <michael@riesch.at>
Date: Thu, 29 Sep 2011 16:06:26 +0200
> In order to make USB-to-Ethernet-adapters (depending on usbnet) support
> timestamping, the "skb_defer_rx_timestamp" and "skb_tx_timestamp" function
> calls are added.
>
> Signed-off-by: Michael Riesch <michael@riesch.at>
Applied.
^ permalink raw reply
* Re: [PATCH v2 2/2] net/fec: add poll controller function for fec nic
From: David Miller @ 2011-09-29 18:54 UTC (permalink / raw)
To: jgq516; +Cc: netdev, linux-kernel
In-Reply-To: <1317298557-2878-2-git-send-email-jgq516@gmail.com>
From: jgq516@gmail.com
Date: Thu, 29 Sep 2011 20:15:57 +0800
> From: Xiao Jiang <jgq516@gmail.com>
>
> Add poll controller function for fec nic.
>
> Signed-off-by: Xiao Jiang <jgq516@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 1/2] net/fec: replace hardcoded irq num with macro
From: David Miller @ 2011-09-29 18:54 UTC (permalink / raw)
To: jgq516; +Cc: netdev, linux-kernel
In-Reply-To: <1317298557-2878-1-git-send-email-jgq516@gmail.com>
From: jgq516@gmail.com
Date: Thu, 29 Sep 2011 20:15:56 +0800
> From: Xiao Jiang <jgq516@gmail.com>
>
> Don't use hardcoded irq num and replace it with
> FEC_IRQ_NUM macro.
>
> Signed-off-by: Xiao Jiang <jgq516@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] RDSRDMA: Fix cleanup of rds_iw_mr_pool
From: Venkat Venkatsubra @ 2011-09-29 18:51 UTC (permalink / raw)
To: jonathan; +Cc: netdev, davem
In the rds_iw_mr_pool struct the free_pinned field keeps track of
memory pinned by free MRs. While this field is incremented properly
upon allocation, it is never decremented upon unmapping. This would
cause the rds_rdma module to crash the kernel upon unloading, by
triggering the BUG_ON in the rds_iw_destroy_mr_pool function.
This change keeps track of the MRs that become unpinned, so that
free_pinned can be decremented appropriately.
Signed-off-by: Jonathan Lallinger <jonathan@ogc.us>
Signed-off-by: Steve Wise <swise@ogc.us>
---
Signed-off-by: Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com>
Venkat
^ permalink raw reply
* [PATCH] RDSRDMA: Fix cleanup of rds_iw_mr_pool
From: Jonathan Lallinger @ 2011-09-29 17:58 UTC (permalink / raw)
To: davem, venkat.x.venkatsubra; +Cc: netdev
In the rds_iw_mr_pool struct the free_pinned field keeps track of
memory pinned by free MRs. While this field is incremented properly
upon allocation, it is never decremented upon unmapping. This would
cause the rds_rdma module to crash the kernel upon unloading, by
triggering the BUG_ON in the rds_iw_destroy_mr_pool function.
This change keeps track of the MRs that become unpinned, so that
free_pinned can be decremented appropriately.
Signed-off-by: Jonathan Lallinger <jonathan@ogc.us>
Signed-off-by: Steve Wise <swise@ogc.us>
---
net/rds/iw_rdma.c | 13 +++++++++----
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/net/rds/iw_rdma.c b/net/rds/iw_rdma.c
index 7c1c873..81d3167 100644
--- a/net/rds/iw_rdma.c
+++ b/net/rds/iw_rdma.c
@@ -84,7 +84,8 @@ static int rds_iw_map_fastreg(struct rds_iw_mr_pool *pool,
static void rds_iw_free_fastreg(struct rds_iw_mr_pool *pool, struct rds_iw_mr *ibmr);
static unsigned int rds_iw_unmap_fastreg_list(struct rds_iw_mr_pool *pool,
struct list_head *unmap_list,
- struct list_head *kill_list);
+ struct list_head *kill_list,
+ int *unpinned);
static void rds_iw_destroy_fastreg(struct rds_iw_mr_pool *pool, struct rds_iw_mr *ibmr);
static int rds_iw_get_device(struct rds_sock *rs, struct rds_iw_device **rds_iwdev, struct rdma_cm_id **cm_id)
@@ -499,7 +500,7 @@ static int rds_iw_flush_mr_pool(struct rds_iw_mr_pool *pool, int free_all)
LIST_HEAD(unmap_list);
LIST_HEAD(kill_list);
unsigned long flags;
- unsigned int nfreed = 0, ncleaned = 0, free_goal;
+ unsigned int nfreed = 0, ncleaned = 0, unpinned = 0, free_goal;
int ret = 0;
rds_iw_stats_inc(s_iw_rdma_mr_pool_flush);
@@ -524,7 +525,8 @@ static int rds_iw_flush_mr_pool(struct rds_iw_mr_pool *pool, int free_all)
* will be destroyed by the unmap function.
*/
if (!list_empty(&unmap_list)) {
- ncleaned = rds_iw_unmap_fastreg_list(pool, &unmap_list, &kill_list);
+ ncleaned = rds_iw_unmap_fastreg_list(pool, &unmap_list,
+ &kill_list, &unpinned);
/* If we've been asked to destroy all MRs, move those
* that were simply cleaned to the kill list */
if (free_all)
@@ -548,6 +550,7 @@ static int rds_iw_flush_mr_pool(struct rds_iw_mr_pool *pool, int free_all)
spin_unlock_irqrestore(&pool->list_lock, flags);
}
+ atomic_sub(unpinned, &pool->free_pinned);
atomic_sub(ncleaned, &pool->dirty_count);
atomic_sub(nfreed, &pool->item_count);
@@ -828,7 +831,8 @@ static void rds_iw_free_fastreg(struct rds_iw_mr_pool *pool,
static unsigned int rds_iw_unmap_fastreg_list(struct rds_iw_mr_pool *pool,
struct list_head *unmap_list,
- struct list_head *kill_list)
+ struct list_head *kill_list,
+ int *unpinned)
{
struct rds_iw_mapping *mapping, *next;
unsigned int ncleaned = 0;
@@ -855,6 +859,7 @@ static unsigned int rds_iw_unmap_fastreg_list(struct rds_iw_mr_pool *pool,
spin_lock_irqsave(&pool->list_lock, flags);
list_for_each_entry_safe(mapping, next, unmap_list, m_list) {
+ *unpinned += mapping->m_sg.len;
list_move(&mapping->m_list, &laundered);
ncleaned++;
}
^ permalink raw reply related
* Re: [net-next 1/9] igb: Update RXDCTL/TXDCTL configurations
From: Arnaud Lacombe @ 2011-09-29 17:41 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Alexander Duyck, netdev, gospo
In-Reply-To: <1316502690-25488-2-git-send-email-jeffrey.t.kirsher@intel.com>
Hi,
On Tue, Sep 20, 2011 at 3:11 AM, Jeff Kirsher
<jeffrey.t.kirsher@intel.com> wrote:
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> This change cleans up the RXDCTL and TXDCTL configurations and optimizes RX
> performance by allowing back write-backs on all hardware other than 82576.
>
Where does this limitation comes from ? The "Intel 82576EB GbE
Controller - Programming Interface" from May 2011 advertises that both
the RXDCTL and TXDCTL register have a 5bit wide WTHRESH field.
Thanks,
- Arnaud
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> drivers/net/ethernet/intel/igb/igb.h | 5 +++--
> drivers/net/ethernet/intel/igb/igb_main.c | 23 +++++++++--------------
> 2 files changed, 12 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/igb/igb.h b/drivers/net/ethernet/intel/igb/igb.h
> index 265e151..577fd3e 100644
> --- a/drivers/net/ethernet/intel/igb/igb.h
> +++ b/drivers/net/ethernet/intel/igb/igb.h
> @@ -100,11 +100,12 @@ struct vf_data_storage {
> */
> #define IGB_RX_PTHRESH 8
> #define IGB_RX_HTHRESH 8
> -#define IGB_RX_WTHRESH 1
> #define IGB_TX_PTHRESH 8
> #define IGB_TX_HTHRESH 1
> +#define IGB_RX_WTHRESH ((hw->mac.type == e1000_82576 && \
> + adapter->msix_entries) ? 1 : 4)
> #define IGB_TX_WTHRESH ((hw->mac.type == e1000_82576 && \
> - adapter->msix_entries) ? 1 : 16)
> + adapter->msix_entries) ? 1 : 16)
>
> /* this is the size past which hardware will drop packets when setting LPE=0 */
> #define MAXIMUM_ETHERNET_VLAN_SIZE 1522
> diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
> index 3cb1bc9..aa78c10 100644
> --- a/drivers/net/ethernet/intel/igb/igb_main.c
> +++ b/drivers/net/ethernet/intel/igb/igb_main.c
> @@ -2666,14 +2666,12 @@ void igb_configure_tx_ring(struct igb_adapter *adapter,
> struct igb_ring *ring)
> {
> struct e1000_hw *hw = &adapter->hw;
> - u32 txdctl;
> + u32 txdctl = 0;
> u64 tdba = ring->dma;
> int reg_idx = ring->reg_idx;
>
> /* disable the queue */
> - txdctl = rd32(E1000_TXDCTL(reg_idx));
> - wr32(E1000_TXDCTL(reg_idx),
> - txdctl & ~E1000_TXDCTL_QUEUE_ENABLE);
> + wr32(E1000_TXDCTL(reg_idx), 0);
> wrfl();
> mdelay(10);
>
> @@ -2685,7 +2683,7 @@ void igb_configure_tx_ring(struct igb_adapter *adapter,
>
> ring->head = hw->hw_addr + E1000_TDH(reg_idx);
> ring->tail = hw->hw_addr + E1000_TDT(reg_idx);
> - writel(0, ring->head);
> + wr32(E1000_TDH(reg_idx), 0);
> writel(0, ring->tail);
>
> txdctl |= IGB_TX_PTHRESH;
> @@ -3028,12 +3026,10 @@ void igb_configure_rx_ring(struct igb_adapter *adapter,
> struct e1000_hw *hw = &adapter->hw;
> u64 rdba = ring->dma;
> int reg_idx = ring->reg_idx;
> - u32 srrctl, rxdctl;
> + u32 srrctl = 0, rxdctl = 0;
>
> /* disable the queue */
> - rxdctl = rd32(E1000_RXDCTL(reg_idx));
> - wr32(E1000_RXDCTL(reg_idx),
> - rxdctl & ~E1000_RXDCTL_QUEUE_ENABLE);
> + wr32(E1000_RXDCTL(reg_idx), 0);
>
> /* Set DMA base address registers */
> wr32(E1000_RDBAL(reg_idx),
> @@ -3045,7 +3041,7 @@ void igb_configure_rx_ring(struct igb_adapter *adapter,
> /* initialize head and tail */
> ring->head = hw->hw_addr + E1000_RDH(reg_idx);
> ring->tail = hw->hw_addr + E1000_RDT(reg_idx);
> - writel(0, ring->head);
> + wr32(E1000_RDH(reg_idx), 0);
> writel(0, ring->tail);
>
> /* set descriptor configuration */
> @@ -3076,13 +3072,12 @@ void igb_configure_rx_ring(struct igb_adapter *adapter,
> /* set filtering for VMDQ pools */
> igb_set_vmolr(adapter, reg_idx & 0x7, true);
>
> - /* enable receive descriptor fetching */
> - rxdctl = rd32(E1000_RXDCTL(reg_idx));
> - rxdctl |= E1000_RXDCTL_QUEUE_ENABLE;
> - rxdctl &= 0xFFF00000;
> rxdctl |= IGB_RX_PTHRESH;
> rxdctl |= IGB_RX_HTHRESH << 8;
> rxdctl |= IGB_RX_WTHRESH << 16;
> +
> + /* enable receive descriptor fetching */
> + rxdctl |= E1000_RXDCTL_QUEUE_ENABLE;
> wr32(E1000_RXDCTL(reg_idx), rxdctl);
> }
>
> --
> 1.7.6.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Question about memory leak detector giving false positive report for net/core/flow.c
From: Catalin Marinas @ 2011-09-29 14:18 UTC (permalink / raw)
To: Christoph Lameter
Cc: Eric Dumazet, Huajun Li, linux-mm@kvack.org, netdev, linux-kernel,
Tejun Heo
In-Reply-To: <alpine.DEB.2.00.1109290907450.9382@router.home>
On Thu, Sep 29, 2011 at 03:08:47PM +0100, Christoph Lameter wrote:
> On Wed, 28 Sep 2011, Catalin Marinas wrote:
>
> > I tried this but it's tricky. The problem is that the percpu pointer
> > returned by alloc_percpu() does not directly point to the per-cpu chunks
> > and kmemleak would report most percpu allocations as leaks. So far the
> > workaround is to simply mark the alloc_percpu() objects as never leaking
> > and at least we avoid false positives in other areas. See the patch
> > below (note that you have to increase the CONFIG_KMEMLEAK_EARLY_LOG_SIZE
> > as there are many alloc_percpu() calls before kmemleak is fully
> > initialised):
>
> Seems that kernel.org is out and so tejon wont be seeing these.
That's ok, I don't aim this at the upcoming merging window. I don't have
an alternative email address for him.
--
Catalin
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: Question about memory leak detector giving false positive report for net/core/flow.c
From: Christoph Lameter @ 2011-09-29 14:08 UTC (permalink / raw)
To: Catalin Marinas
Cc: Eric Dumazet, Huajun Li, linux-mm@kvack.org, netdev, linux-kernel,
Tejun Heo
In-Reply-To: <20110928172342.GH23559@e102109-lin.cambridge.arm.com>
On Wed, 28 Sep 2011, Catalin Marinas wrote:
> I tried this but it's tricky. The problem is that the percpu pointer
> returned by alloc_percpu() does not directly point to the per-cpu chunks
> and kmemleak would report most percpu allocations as leaks. So far the
> workaround is to simply mark the alloc_percpu() objects as never leaking
> and at least we avoid false positives in other areas. See the patch
> below (note that you have to increase the CONFIG_KMEMLEAK_EARLY_LOG_SIZE
> as there are many alloc_percpu() calls before kmemleak is fully
> initialised):
Seems that kernel.org is out and so tejon wont be seeing these.
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [patch] usbnet: add timestamping support
From: Michael Riesch @ 2011-09-29 14:08 UTC (permalink / raw)
To: David Miller; +Cc: netdev, oneukum
In-Reply-To: <20110928.032057.938343201578831873.davem@davemloft.net>
On Wed, 2011-09-28 at 03:20 -0400, David Miller wrote:
> Patch is severly corrupted by your email client.
>
> Correct this (see Documentation/email-clients.txt), send a test patch
> to yourself, and only resubmit this change when you can successfully
> apply a patch you send to youself.
Sorry about that. I switched to git-send-email and tested it. I hope it
works now.
Regards, Michael
^ 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