* Re: [net-next PATCH 2/3] qdisc: bulk dequeue support for qdiscs with TCQ_F_ONETXQUEUE
From: Florian Westphal @ 2014-09-03 10:23 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Eric Dumazet, David S. Miller, netdev, Florian Westphal,
Hannes Frederic Sowa, Daniel Borkmann
In-Reply-To: <20140903113119.245b4746@redhat.com>
Jesper Dangaard Brouer <brouer@redhat.com> wrote:
> On Tue, 02 Sep 2014 08:22:42 -0700
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > On Tue, 2014-09-02 at 16:35 +0200, Jesper Dangaard Brouer wrote:
> >
> > > This is crazy fast. This measurement is actually "too-high" as
> > > 10Gbit/s wirespeed is 14,880,952 (11049 pps too fast).
> > >
> > > Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> > > ---
> >
> > This looks buggy, you forgot about GSO.
>
> The GSO check is (!skb->next), right(?)
No, you'd want to use skb_is_gso() helper.
> > Also, our idea was to use a byte count limit (aka BQL)
>
> It makes sense. I will look into using the BQL limits.
Thanks Jesper.
> > If we dequeue 8 64KB packets, this patch adds head of line blocking,
> > which we fought hard.
Just to make sure: Using bql limits would resolve your HOL blocking
concerns, right?
^ permalink raw reply
* Re: [PATCH 1/3] virtio_net: pass well-formed sgs to virtqueue_add_*()
From: Jesper Dangaard Brouer @ 2014-09-03 10:23 UTC (permalink / raw)
To: Rusty Russell
Cc: brouer, netdev, Andy Lutomirski, Michael S. Tsirkin,
virtualization
In-Reply-To: <1409718556-3041-2-git-send-email-rusty@rustcorp.com.au>
On Wed, 3 Sep 2014 13:59:14 +0930
Rusty Russell <rusty@rustcorp.com.au> wrote:
> pktgen results:
> modprobe pktgen
> echo 'add_device eth0' > /proc/net/pktgen/kpktgend_0
> echo nowait 1 > /proc/net/pktgen/eth0
Maybe your pktgen "nowait" (patch) should be a flag instead?
echo "flag EXIT_NO_WAIT" > /proc/net/pktgen/eth0
> echo count 1000000 > /proc/net/pktgen/eth0
> echo clone_skb 100000 > /proc/net/pktgen/eth0
> echo dst_mac 4e:14:25:a9:30:ac > /proc/net/pktgen/eth0
> echo dst 192.168.1.2 > /proc/net/pktgen/eth0
> for i in `seq 20`; do echo start > /proc/net/pktgen/pgctrl; tail -n1 /proc/net/pktgen/eth0; done
>
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [PATCH v4 1/4] ethernet: arc: Add support for Rockchip SoC layer device tree bindings
From: Romain Perier @ 2014-09-03 10:27 UTC (permalink / raw)
To: heiko; +Cc: linux-rockchip, linux-arm-kernel, netdev, devicetree, arnd
This patch defines a platform glue layer for Rockchip SoCs which
support arc-emac driver. It ensures that regulator for the rmii is on
before trying to connect to the ethernet controller. It applies right
speed and mode changes to the grf when ethernet settings change.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
---
drivers/net/ethernet/arc/Kconfig | 10 ++
drivers/net/ethernet/arc/Makefile | 1 +
drivers/net/ethernet/arc/emac.h | 4 +-
drivers/net/ethernet/arc/emac_main.c | 2 +
drivers/net/ethernet/arc/emac_rockchip.c | 228 +++++++++++++++++++++++++++++++
5 files changed, 244 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/ethernet/arc/emac_rockchip.c
diff --git a/drivers/net/ethernet/arc/Kconfig b/drivers/net/ethernet/arc/Kconfig
index 89e04fd..8e262e2 100644
--- a/drivers/net/ethernet/arc/Kconfig
+++ b/drivers/net/ethernet/arc/Kconfig
@@ -32,4 +32,14 @@ config ARC_EMAC
non-standard on-chip ethernet device ARC EMAC 10/100 is used.
Say Y here if you have such a board. If unsure, say N.
+config EMAC_ROCKCHIP
+ tristate "Rockchip EMAC support"
+ select ARC_EMAC_CORE
+ depends on OF_IRQ && OF_NET && REGULATOR
+ ---help---
+ Support for Rockchip RK3066/RK3188 EMAC ethernet controllers.
+ This selects Rockchip SoC glue layer support for the
+ emac device driver. This driver is used for RK3066/RK3188
+ EMAC ethernet controller.
+
endif # NET_VENDOR_ARC
diff --git a/drivers/net/ethernet/arc/Makefile b/drivers/net/ethernet/arc/Makefile
index 241bb80..79108af 100644
--- a/drivers/net/ethernet/arc/Makefile
+++ b/drivers/net/ethernet/arc/Makefile
@@ -5,3 +5,4 @@
arc_emac-objs := emac_main.o emac_mdio.o
obj-$(CONFIG_ARC_EMAC_CORE) += arc_emac.o
obj-$(CONFIG_ARC_EMAC) += emac_arc.o
+obj-$(CONFIG_EMAC_ROCKCHIP) += emac_rockchip.o
diff --git a/drivers/net/ethernet/arc/emac.h b/drivers/net/ethernet/arc/emac.h
index eb2ba67..dae1ac3 100644
--- a/drivers/net/ethernet/arc/emac.h
+++ b/drivers/net/ethernet/arc/emac.h
@@ -123,9 +123,11 @@ struct buffer_state {
* @speed: PHY's last set speed.
*/
struct arc_emac_priv {
- /* Devices */
const char *drv_name;
const char *drv_version;
+ void (*set_mac_speed)(void *priv, unsigned int speed);
+
+ /* Devices */
struct device *dev;
struct phy_device *phy_dev;
struct mii_bus *bus;
diff --git a/drivers/net/ethernet/arc/emac_main.c b/drivers/net/ethernet/arc/emac_main.c
index b35c69e..a08f343 100644
--- a/drivers/net/ethernet/arc/emac_main.c
+++ b/drivers/net/ethernet/arc/emac_main.c
@@ -48,6 +48,8 @@ static void arc_emac_adjust_link(struct net_device *ndev)
if (priv->speed != phy_dev->speed) {
priv->speed = phy_dev->speed;
state_changed = 1;
+ if (priv->set_mac_speed)
+ priv->set_mac_speed(priv, priv->speed);
}
if (priv->duplex != phy_dev->duplex) {
diff --git a/drivers/net/ethernet/arc/emac_rockchip.c b/drivers/net/ethernet/arc/emac_rockchip.c
new file mode 100644
index 0000000..97dffbc
--- /dev/null
+++ b/drivers/net/ethernet/arc/emac_rockchip.c
@@ -0,0 +1,228 @@
+/**
+ * emac-rockchip.c - Rockchip EMAC specific glue layer
+ *
+ * Copyright (C) 2014 Romain Perier <romain.perier@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/etherdevice.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of_net.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+
+#include "emac.h"
+
+#define DRV_NAME "rockchip_emac"
+#define DRV_VERSION "1.0"
+
+#define GRF_MODE_MII (1UL << 0)
+#define GRF_MODE_RMII (0UL << 0)
+#define GRF_SPEED_10M (0UL << 1)
+#define GRF_SPEED_100M (1UL << 1)
+#define GRF_SPEED_ENABLE_BIT (1UL << 17)
+#define GRF_MODE_ENABLE_BIT (1UL << 16)
+
+struct emac_rockchip_soc_data {
+ int grf_offset;
+};
+
+struct rockchip_priv_data {
+ struct arc_emac_priv emac;
+ struct regmap *grf;
+ const struct emac_rockchip_soc_data *soc_data;
+ struct regulator *regulator;
+ struct clk *refclk;
+};
+
+static const struct emac_rockchip_soc_data emac_rockchip_dt_data[] = {
+ { .grf_offset = 0x154 }, /* rk3066 */
+ { .grf_offset = 0x0a4 }, /* rk3188 */
+};
+
+static const struct of_device_id emac_rockchip_dt_ids[] = {
+ { .compatible = "rockchip,rk3066-emac", .data = &emac_rockchip_dt_data[0] },
+ { .compatible = "rockchip,rk3188-emac", .data = &emac_rockchip_dt_data[1] },
+ { /* Sentinel */ }
+};
+
+static void emac_rockchip_set_mac_speed(void *priv, unsigned int speed)
+{
+ struct rockchip_priv_data *emac = priv;
+ u32 data;
+ int err = 0;
+
+ /* write-enable bits */
+ data = GRF_SPEED_ENABLE_BIT;
+
+ switch(speed) {
+ case 10:
+ data |= GRF_SPEED_10M;
+ break;
+ case 100:
+ data |= GRF_SPEED_100M;
+ break;
+ default:
+ pr_err("speed %u not supported\n", speed);
+ return;
+ }
+
+ err = regmap_write(emac->grf, emac->soc_data->grf_offset, data);
+ if (err)
+ pr_err("unable to apply speed %u to grf (%d)\n", speed, err);
+}
+
+static int emac_rockchip_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct net_device *ndev;
+ struct rockchip_priv_data *priv;
+ const struct of_device_id *match;
+ u32 data;
+ int err, interface;
+
+ if (!pdev->dev.of_node)
+ return -ENODEV;
+
+ ndev = alloc_etherdev(sizeof(struct rockchip_priv_data));
+ if (!ndev)
+ return -ENOMEM;
+ platform_set_drvdata(pdev, ndev);
+ SET_NETDEV_DEV(ndev, dev);
+
+ priv = netdev_priv(ndev);
+ priv->emac.drv_name = DRV_NAME;
+ priv->emac.drv_version = DRV_VERSION;
+ priv->emac.set_mac_speed = emac_rockchip_set_mac_speed;
+
+ interface = of_get_phy_mode(dev->of_node);
+
+ /* RK3066 and RK3188 SoCs only support RMII */
+ if (interface != PHY_INTERFACE_MODE_RMII) {
+ dev_err(dev, "unsupported phy interface mode %d\n", interface);
+ err = -ENOTSUPP;
+ goto out_netdev;
+ }
+
+ priv->grf = syscon_regmap_lookup_by_phandle(dev->of_node, "rockchip,grf");
+ if (IS_ERR(priv->grf)) {
+ dev_err(dev, "failed to retrieve global register file from the device tree (%ld)\n", PTR_ERR(priv->grf));
+ err = PTR_ERR(priv->grf);
+ goto out_netdev;
+ }
+
+ match = of_match_node(emac_rockchip_dt_ids, dev->of_node);
+ priv->soc_data = match->data;
+
+ priv->emac.clk = devm_clk_get(dev, "hclk");
+ if (IS_ERR(priv->emac.clk)) {
+ dev_err(dev, "failed to retrieve host clock from device tree (%ld)\n", PTR_ERR(priv->emac.clk));
+ err = PTR_ERR(priv->emac.clk);
+ goto out_netdev;
+ }
+
+ priv->refclk = devm_clk_get(dev, "macref");
+ if (IS_ERR(priv->refclk)) {
+ dev_err(dev, "failed to retrieve reference clock from device tree (%ld)\n", PTR_ERR(priv->refclk));
+ err = PTR_ERR(priv->refclk);
+ goto out_netdev;
+ }
+
+ err = clk_prepare_enable(priv->refclk);
+ if (err) {
+ dev_err(dev, "failed to enable reference clock (%d)\n", err);
+ goto out_netdev;
+ }
+
+ /* Optional regulator for PHY */
+ priv->regulator = devm_regulator_get_optional(dev, "phy");
+ if (IS_ERR(priv->regulator)) {
+ if (PTR_ERR(priv->regulator) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ dev_err(dev, "no regulator found\n");
+ priv->regulator = NULL;
+ }
+
+ if (priv->regulator) {
+ err = regulator_enable(priv->regulator);
+ if (err) {
+ dev_err(dev, "failed to enable phy-supply (%d)\n", err);
+ goto out_clk_disable;
+ }
+ }
+
+ err = arc_emac_probe(ndev, interface);
+ if (err)
+ goto out_regulator_disable;
+
+ /* write-enable bits */
+ data = GRF_MODE_ENABLE_BIT | GRF_SPEED_ENABLE_BIT;
+
+ data |= GRF_SPEED_100M;
+ data |= GRF_MODE_RMII;
+
+ err = regmap_write(priv->grf, priv->soc_data->grf_offset, data);
+ if (err) {
+ dev_err(dev, "unable to apply initial settings to grf (%d)\n", err);
+ goto out_regulator_disable;
+ }
+
+ /* RMII interface needs always a rate of 50MHz */
+ err = clk_set_rate(priv->refclk, 50000000);
+ if (err)
+ dev_err(dev, "failed to change reference clock rate (%d)\n", err);
+ return 0;
+
+out_regulator_disable:
+ if (priv->regulator)
+ regulator_disable(priv->regulator);
+out_clk_disable:
+ clk_unprepare_disable(priv->refclk);
+out_netdev:
+ free_netdev(ndev);
+ return err;
+}
+
+static int emac_rockchip_remove(struct platform_device *pdev)
+{
+ struct net_device *ndev = platform_get_drvdata(pdev);
+ struct rockchip_priv_data *priv = netdev_priv(ndev);
+ int err;
+
+ clk_disable_unprepare(priv->refclk);
+
+ if (priv->regulator)
+ regulator_disable(priv->regulator);
+
+ err = arc_emac_remove(ndev);
+ free_netdev(ndev);
+ return err;
+}
+
+MODULE_DEVICE_TABLE(of, emac_rockchip_dt_ids);
+
+static struct platform_driver emac_rockchip_driver = {
+ .probe = emac_rockchip_probe,
+ .remove = emac_rockchip_remove,
+ .driver = {
+ .name = DRV_NAME,
+ .of_match_table = emac_rockchip_dt_ids,
+ },
+};
+
+module_platform_driver(emac_rockchip_driver);
+
+MODULE_AUTHOR("Romain Perier <romain.perier@gmail.com>");
+MODULE_DESCRIPTION("Rockchip EMAC platform driver");
+MODULE_LICENSE("GPL");
--
1.9.1
^ permalink raw reply related
* [PATCH 2/4] dt-bindings: Document EMAC Rockchip
From: Romain Perier @ 2014-09-03 10:27 UTC (permalink / raw)
To: heiko; +Cc: linux-rockchip, linux-arm-kernel, netdev, devicetree, arnd
In-Reply-To: <1409740036-8117-1-git-send-email-romain.perier@gmail.com>
This adds the necessary binding documentation for the EMAC Rockchip platform
driver found in RK3066 and RK3188 SoCs.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
---
.../devicetree/bindings/net/emac_rockchip.txt | 53 ++++++++++++++++++++++
1 file changed, 53 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/emac_rockchip.txt
diff --git a/Documentation/devicetree/bindings/net/emac_rockchip.txt b/Documentation/devicetree/bindings/net/emac_rockchip.txt
new file mode 100644
index 0000000..d3242e4
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/emac_rockchip.txt
@@ -0,0 +1,53 @@
+* ARC EMAC 10/100 Ethernet platform driver for Rockchip Rk3066/RK3188 SoCs
+
+Required properties:
+- compatible: Should be "rockchip,rk3066-emac" or "rockchip,rk3188-emac"
+ according to the target SoC.
+- reg: Address and length of the register set for the device
+- interrupts: Should contain the EMAC interrupts
+- pinctrl-names: pin control state name ("default").
+- pinctrl-0: pin control group list of phandle. It must contain
+ pin control groups for communication with the phy and for the mii bus.
+- rockchip,grf: phandle to the syscon grf used to control speed and mode
+ for emac.
+- phy: see ethernet.txt file in the same directory.
+- phy-mode: see ethernet.txt file in the same directory.
+
+Optional properties:
+- phy-supply: phandle to a regulator if the PHY needs one
+
+Clock handling:
+- The host clock is needed to calculate and set polling period of EMAC.
+ It must be provided by the clock "hclk".
+- The reference clock is needed to get/set data from phy at the right frequency,
+ according to its "phy-mode". It must be provided by the clock "macref".
+
+Child nodes of the driver are the individual PHY devices connected to the
+MDIO bus. They must have a "reg" property given the PHY address on the MDIO bus.
+
+Examples:
+
+ethernet@10204000 {
+ compatible = "rockchip,rk3188-emac";
+ reg = <0xc0fc2000 0x3c>;
+ interrupts = <6>;
+ mac-address = [ 00 11 22 33 44 55 ];
+
+ clocks = <&cru HCLK_EMAC>, <&cru SCLK_MAC>;
+ clock-names = "hclk", "macref";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&emac_xfer>, <&emac_mdio>, <&phy_int>;
+
+ rockchip,grf = <&grf>;
+
+ phy = <&phy0>;
+ phy-mode = "rmii";
+ phy-supply = <&vcc_rmii>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy0: ethernet-phy@0 {
+ reg = <1>;
+ };
+};
--
1.9.1
^ permalink raw reply related
* [PATCH 3/4] ARM: dts: Add emac nodes to the rk3188 device tree
From: Romain Perier @ 2014-09-03 10:27 UTC (permalink / raw)
To: heiko; +Cc: linux-rockchip, linux-arm-kernel, netdev, devicetree, arnd
In-Reply-To: <1409740036-8117-1-git-send-email-romain.perier@gmail.com>
This adds support for EMAC Rockchip driver on RK3188 SoCs.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
---
arch/arm/boot/dts/rk3188.dtsi | 18 ++++++++++++++++++
arch/arm/boot/dts/rk3xxx.dtsi | 17 +++++++++++++++++
2 files changed, 35 insertions(+)
diff --git a/arch/arm/boot/dts/rk3188.dtsi b/arch/arm/boot/dts/rk3188.dtsi
index ee801a9..a182713 100644
--- a/arch/arm/boot/dts/rk3188.dtsi
+++ b/arch/arm/boot/dts/rk3188.dtsi
@@ -147,6 +147,24 @@
bias-disable;
};
+ emac {
+ emac_xfer: emac-xfer {
+ rockchip,pins = <RK_GPIO3 16 RK_FUNC_2 &pcfg_pull_none>, //tx_en
+ <RK_GPIO3 17 RK_FUNC_2 &pcfg_pull_none>, //txd1
+ <RK_GPIO3 18 RK_FUNC_2 &pcfg_pull_none>, //txd0
+ <RK_GPIO3 19 RK_FUNC_2 &pcfg_pull_none>, //rxd0
+ <RK_GPIO3 20 RK_FUNC_2 &pcfg_pull_none>, //rxd1
+ <RK_GPIO3 21 RK_FUNC_2 &pcfg_pull_none>, //mac_clk
+ <RK_GPIO3 22 RK_FUNC_2 &pcfg_pull_none>, //rx_err
+ <RK_GPIO3 23 RK_FUNC_2 &pcfg_pull_none>; //crs_dvalid
+ };
+
+ emac_mdio: emac-mdio {
+ rockchip,pins = <RK_GPIO3 24 RK_FUNC_2 &pcfg_pull_none>,
+ <RK_GPIO3 25 RK_FUNC_2 &pcfg_pull_none>;
+ };
+ };
+
i2c0 {
i2c0_xfer: i2c0-xfer {
rockchip,pins = <RK_GPIO1 24 RK_FUNC_1 &pcfg_pull_none>,
diff --git a/arch/arm/boot/dts/rk3xxx.dtsi b/arch/arm/boot/dts/rk3xxx.dtsi
index 8caf85d..208b1df 100644
--- a/arch/arm/boot/dts/rk3xxx.dtsi
+++ b/arch/arm/boot/dts/rk3xxx.dtsi
@@ -91,6 +91,23 @@
status = "disabled";
};
+ emac: ethernet@10204000 {
+ compatible = "snps,arc-emac";
+ reg = <0x10204000 0x3c>;
+ interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rockchip,grf = <&grf>;
+
+ clocks = <&cru HCLK_EMAC>, <&cru SCLK_MAC>;
+ clock-names = "hclk", "macref";
+ max-speed = <100>;
+ phy-mode = "rmii";
+
+ status = "disabled";
+ };
+
mmc0: dwmmc@10214000 {
compatible = "rockchip,rk2928-dw-mshc";
reg = <0x10214000 0x1000>;
--
1.9.1
^ permalink raw reply related
* [PATCH 4/4] ARM: dts: Enable emac node on the rk3188-radxarock boards
From: Romain Perier @ 2014-09-03 10:27 UTC (permalink / raw)
To: heiko; +Cc: linux-rockchip, linux-arm-kernel, netdev, devicetree, arnd
In-Reply-To: <1409740036-8117-1-git-send-email-romain.perier@gmail.com>
This enables EMAC Rockchip support on radxa rock boards.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
---
arch/arm/boot/dts/rk3188-radxarock.dts | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/rk3188-radxarock.dts b/arch/arm/boot/dts/rk3188-radxarock.dts
index 5e4e3c23..e1358d3 100644
--- a/arch/arm/boot/dts/rk3188-radxarock.dts
+++ b/arch/arm/boot/dts/rk3188-radxarock.dts
@@ -76,6 +76,24 @@
};
};
+&emac {
+ status = "okay";
+ compatible = "rockchip,rk3188-emac";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&emac_xfer>, <&emac_mdio>, <&phy_int>;
+
+ mac-address = [ c6 ef 91 8e 60 4b ];
+ phy = <&phy0>;
+ phy-supply = <&vcc_rmii>;
+
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <26 IRQ_TYPE_LEVEL_LOW>;
+ };
+};
+
&i2c1 {
status = "okay";
clock-frequency = <400000>;
@@ -201,6 +219,12 @@
};
};
+ lan8720a {
+ phy_int: phy-int {
+ rockchip,pins = <RK_GPIO3 26 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
ir-receiver {
ir_recv_pin: ir-recv-pin {
rockchip,pins = <RK_GPIO0 10 RK_FUNC_GPIO &pcfg_pull_none>;
--
1.9.1
^ permalink raw reply related
* hej business anmodning
From: lamirada @ 2014-09-03 9:59 UTC (permalink / raw)
hej business anmodning
Det er forståeligt, at du kan være en smule betænkelig, fordi du ikke
kender mig , tilgiv venligst denne usædvanlige måde at kontakte dig, men
denne særlige brev / e-mail er af usædvanlig og meget privat karakter ,
som i kraft af mit udsigtspunkt position i min land Libyen , jeg har en
lukrativ forretning forslag af fælles interesse til at dele med dig .
Der er ingen måde for mig at vide, om jeg vil blive forstået rigtigt ,
men det er min pligt at skrive og nå ud til dig , stole på, at du vil
give dette forslag en positiv overvejelse.
Jeg er Rod Thompson en af direktørerne i en bank her i Libya.I bliver du
nødt til at hjælpe mig i at udføre en virksomhed projekt fra vores bank
værd US $ 21,1 mio . Disse midler blev deponeret hos vores bank af en
kunde i vores bank , der er statsborger { borger } af dit land / område
, som desværre døde for 10 år siden . Jeg skal give dig mere information
handler om denne operation , da jeg modtager dit svar.
send dit svar til denne e-mail -adresse: rodthompson50@aol.com
Dr.Rod Thompson
^ permalink raw reply
* Re: [PATCH net-next] net: gso_skb is now a list, needs a proper destructor
From: Jesper Dangaard Brouer @ 2014-09-03 10:33 UTC (permalink / raw)
To: David Miller; +Cc: brouer, eric.dumazet, netdev
In-Reply-To: <20140902.150604.267268114901700475.davem@davemloft.net>
On Tue, 02 Sep 2014 15:06:04 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
> Applied, thanks Eric.
I didn't see this patch the git tree, when I posted a similar fix.
So, just ignore my similar patch.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH v4 1/4] ethernet: arc: Add support for Rockchip SoC layer device tree bindings
From: Varka Bhadram @ 2014-09-03 10:42 UTC (permalink / raw)
To: Romain Perier, heiko
Cc: linux-rockchip, linux-arm-kernel, netdev, devicetree, arnd
In-Reply-To: <1409740036-8117-1-git-send-email-romain.perier@gmail.com>
On 09/03/2014 03:57 PM, Romain Perier wrote:
> This patch defines a platform glue layer for Rockchip SoCs which
> support arc-emac driver. It ensures that regulator for the rmii is on
> before trying to connect to the ethernet controller. It applies right
> speed and mode changes to the grf when ethernet settings change.
>
> Signed-off-by: Romain Perier <romain.perier@gmail.com>
> ---
> drivers/net/ethernet/arc/Kconfig | 10 ++
> drivers/net/ethernet/arc/Makefile | 1 +
> drivers/net/ethernet/arc/emac.h | 4 +-
> drivers/net/ethernet/arc/emac_main.c | 2 +
> drivers/net/ethernet/arc/emac_rockchip.c | 228 +++++++++++++++++++++++++++++++
> 5 files changed, 244 insertions(+), 1 deletion(-)
> create mode 100644 drivers/net/ethernet/arc/emac_rockchip.c
>
> diff --git a/drivers/net/ethernet/arc/Kconfig b/drivers/net/ethernet/arc/Kconfig
> index 89e04fd..8e262e2 100644
> --- a/drivers/net/ethernet/arc/Kconfig
> +++ b/drivers/net/ethernet/arc/Kconfig
> @@ -32,4 +32,14 @@ config ARC_EMAC
> non-standard on-chip ethernet device ARC EMAC 10/100 is used.
> Say Y here if you have such a board. If unsure, say N.
>
> +config EMAC_ROCKCHIP
> + tristate "Rockchip EMAC support"
> + select ARC_EMAC_CORE
> + depends on OF_IRQ && OF_NET && REGULATOR
> + ---help---
> + Support for Rockchip RK3066/RK3188 EMAC ethernet controllers.
> + This selects Rockchip SoC glue layer support for the
> + emac device driver. This driver is used for RK3066/RK3188
> + EMAC ethernet controller.
> +
> endif # NET_VENDOR_ARC
> diff --git a/drivers/net/ethernet/arc/Makefile b/drivers/net/ethernet/arc/Makefile
> index 241bb80..79108af 100644
> --- a/drivers/net/ethernet/arc/Makefile
> +++ b/drivers/net/ethernet/arc/Makefile
> @@ -5,3 +5,4 @@
> arc_emac-objs := emac_main.o emac_mdio.o
> obj-$(CONFIG_ARC_EMAC_CORE) += arc_emac.o
> obj-$(CONFIG_ARC_EMAC) += emac_arc.o
> +obj-$(CONFIG_EMAC_ROCKCHIP) += emac_rockchip.o
> diff --git a/drivers/net/ethernet/arc/emac.h b/drivers/net/ethernet/arc/emac.h
> index eb2ba67..dae1ac3 100644
> --- a/drivers/net/ethernet/arc/emac.h
> +++ b/drivers/net/ethernet/arc/emac.h
> @@ -123,9 +123,11 @@ struct buffer_state {
> * @speed: PHY's last set speed.
> */
> struct arc_emac_priv {
> - /* Devices */
> const char *drv_name;
> const char *drv_version;
> + void (*set_mac_speed)(void *priv, unsigned int speed);
> +
> + /* Devices */
> struct device *dev;
> struct phy_device *phy_dev;
> struct mii_bus *bus;
> diff --git a/drivers/net/ethernet/arc/emac_main.c b/drivers/net/ethernet/arc/emac_main.c
> index b35c69e..a08f343 100644
> --- a/drivers/net/ethernet/arc/emac_main.c
> +++ b/drivers/net/ethernet/arc/emac_main.c
> @@ -48,6 +48,8 @@ static void arc_emac_adjust_link(struct net_device *ndev)
> if (priv->speed != phy_dev->speed) {
> priv->speed = phy_dev->speed;
> state_changed = 1;
> + if (priv->set_mac_speed)
> + priv->set_mac_speed(priv, priv->speed);
> }
>
> if (priv->duplex != phy_dev->duplex) {
> diff --git a/drivers/net/ethernet/arc/emac_rockchip.c b/drivers/net/ethernet/arc/emac_rockchip.c
> new file mode 100644
> index 0000000..97dffbc
> --- /dev/null
> +++ b/drivers/net/ethernet/arc/emac_rockchip.c
> @@ -0,0 +1,228 @@
> +/**
> + * emac-rockchip.c - Rockchip EMAC specific glue layer
> + *
> + * Copyright (C) 2014 Romain Perier <romain.perier@gmail.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/etherdevice.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/module.h>
> +#include <linux/of_net.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/regulator/consumer.h>
> +
> +#include "emac.h"
> +
> +#define DRV_NAME "rockchip_emac"
> +#define DRV_VERSION "1.0"
> +
> +#define GRF_MODE_MII (1UL << 0)
> +#define GRF_MODE_RMII (0UL << 0)
> +#define GRF_SPEED_10M (0UL << 1)
> +#define GRF_SPEED_100M (1UL << 1)
> +#define GRF_SPEED_ENABLE_BIT (1UL << 17)
> +#define GRF_MODE_ENABLE_BIT (1UL << 16)
> +
> +struct emac_rockchip_soc_data {
> + int grf_offset;
> +};
> +
> +struct rockchip_priv_data {
> + struct arc_emac_priv emac;
> + struct regmap *grf;
> + const struct emac_rockchip_soc_data *soc_data;
> + struct regulator *regulator;
> + struct clk *refclk;
> +};
> +
> +static const struct emac_rockchip_soc_data emac_rockchip_dt_data[] = {
> + { .grf_offset = 0x154 }, /* rk3066 */
> + { .grf_offset = 0x0a4 }, /* rk3188 */
> +};
> +
> +static const struct of_device_id emac_rockchip_dt_ids[] = {
> + { .compatible = "rockchip,rk3066-emac", .data = &emac_rockchip_dt_data[0] },
> + { .compatible = "rockchip,rk3188-emac", .data = &emac_rockchip_dt_data[1] },
> + { /* Sentinel */ }
> +};
> +
of_device_id 's should be above probe/remove functionalities of the driver because we are
using *emac_rockchip_dt_ids* in probe function.
MODULE_DEVICE_TABLE(of, ...) should immediately follows the *of_device_id*
> +static void emac_rockchip_set_mac_speed(void *priv, unsigned int speed)
> +{
> + struct rockchip_priv_data *emac = priv;
> + u32 data;
> + int err = 0;
> +
> + /* write-enable bits */
> + data = GRF_SPEED_ENABLE_BIT;
> +
> + switch(speed) {
> + case 10:
> + data |= GRF_SPEED_10M;
> + break;
> + case 100:
> + data |= GRF_SPEED_100M;
> + break;
> + default:
> + pr_err("speed %u not supported\n", speed);
> + return;
> + }
> +
> + err = regmap_write(emac->grf, emac->soc_data->grf_offset, data);
> + if (err)
> + pr_err("unable to apply speed %u to grf (%d)\n", speed, err);
> +}
> +
> +static int emac_rockchip_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct net_device *ndev;
> + struct rockchip_priv_data *priv;
> + const struct of_device_id *match;
> + u32 data;
> + int err, interface;
> +
> + if (!pdev->dev.of_node)
> + return -ENODEV;
> +
> + ndev = alloc_etherdev(sizeof(struct rockchip_priv_data));
> + if (!ndev)
> + return -ENOMEM;
> + platform_set_drvdata(pdev, ndev);
> + SET_NETDEV_DEV(ndev, dev);
> +
> + priv = netdev_priv(ndev);
> + priv->emac.drv_name = DRV_NAME;
> + priv->emac.drv_version = DRV_VERSION;
> + priv->emac.set_mac_speed = emac_rockchip_set_mac_speed;
> +
> + interface = of_get_phy_mode(dev->of_node);
> +
> + /* RK3066 and RK3188 SoCs only support RMII */
> + if (interface != PHY_INTERFACE_MODE_RMII) {
> + dev_err(dev, "unsupported phy interface mode %d\n", interface);
> + err = -ENOTSUPP;
> + goto out_netdev;
> + }
> +
> + priv->grf = syscon_regmap_lookup_by_phandle(dev->of_node, "rockchip,grf");
> + if (IS_ERR(priv->grf)) {
> + dev_err(dev, "failed to retrieve global register file from the device tree (%ld)\n", PTR_ERR(priv->grf));
debug message is so lengthy ...?
we can omit *from device tree*
dev_err(dev, "failed to get global register file");
> + err = PTR_ERR(priv->grf);
> + goto out_netdev;
> + }
> +
> + match = of_match_node(emac_rockchip_dt_ids, dev->of_node);
> + priv->soc_data = match->data;
> +
> + priv->emac.clk = devm_clk_get(dev, "hclk");
> + if (IS_ERR(priv->emac.clk)) {
> + dev_err(dev, "failed to retrieve host clock from device tree (%ld)\n", PTR_ERR(priv->emac.clk));
> +
dto...
> err = PTR_ERR(priv->emac.clk);
> + goto out_netdev;
> + }
> +
> + priv->refclk = devm_clk_get(dev, "macref");
> + if (IS_ERR(priv->refclk)) {
> + dev_err(dev, "failed to retrieve reference clock from device tree (%ld)\n", PTR_ERR(priv->refclk));
dto...
> + err = PTR_ERR(priv->refclk);
> + goto out_netdev;
> + }
> +
> + err = clk_prepare_enable(priv->refclk);
> + if (err) {
> + dev_err(dev, "failed to enable reference clock (%d)\n", err);
> + goto out_netdev;
> + }
> +
> + /* Optional regulator for PHY */
> + priv->regulator = devm_regulator_get_optional(dev, "phy");
> + if (IS_ERR(priv->regulator)) {
> + if (PTR_ERR(priv->regulator) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + dev_err(dev, "no regulator found\n");
> + priv->regulator = NULL;
> + }
> +
> + if (priv->regulator) {
> + err = regulator_enable(priv->regulator);
> + if (err) {
> + dev_err(dev, "failed to enable phy-supply (%d)\n", err);
> + goto out_clk_disable;
> + }
> + }
> +
> + err = arc_emac_probe(ndev, interface);
> + if (err)
> + goto out_regulator_disable;
> +
> + /* write-enable bits */
> + data = GRF_MODE_ENABLE_BIT | GRF_SPEED_ENABLE_BIT;
> +
> + data |= GRF_SPEED_100M;
> + data |= GRF_MODE_RMII;
> +
> + err = regmap_write(priv->grf, priv->soc_data->grf_offset, data);
> + if (err) {
> + dev_err(dev, "unable to apply initial settings to grf (%d)\n", err);
> + goto out_regulator_disable;
> + }
> +
> + /* RMII interface needs always a rate of 50MHz */
> + err = clk_set_rate(priv->refclk, 50000000);
> + if (err)
> + dev_err(dev, "failed to change reference clock rate (%d)\n", err);
> + return 0;
> +
> +out_regulator_disable:
> + if (priv->regulator)
> + regulator_disable(priv->regulator);
> +out_clk_disable:
> + clk_unprepare_disable(priv->refclk);
> +out_netdev:
> + free_netdev(ndev);
> + return err;
> +}
> +
> +static int emac_rockchip_remove(struct platform_device *pdev)
> +{
> + struct net_device *ndev = platform_get_drvdata(pdev);
> + struct rockchip_priv_data *priv = netdev_priv(ndev);
> + int err;
> +
> + clk_disable_unprepare(priv->refclk);
> +
> + if (priv->regulator)
> + regulator_disable(priv->regulator);
> +
> + err = arc_emac_remove(ndev);
> + free_netdev(ndev);
> + return err;
> +}
> +
> +MODULE_DEVICE_TABLE(of, emac_rockchip_dt_ids);
> +
should be after *struct of_device_id*
> +static struct platform_driver emac_rockchip_driver = {
> + .probe = emac_rockchip_probe,
> + .remove = emac_rockchip_remove,
> + .driver = {
> + .name = DRV_NAME,
> + .of_match_table = emac_rockchip_dt_ids,
> + },
> +};
> +
> +module_platform_driver(emac_rockchip_driver);
> +
> +MODULE_AUTHOR("Romain Perier <romain.perier@gmail.com>");
> +MODULE_DESCRIPTION("Rockchip EMAC platform driver");
> +MODULE_LICENSE("GPL");
Thanks....
--
Regards,
Varka Bhadram.
^ permalink raw reply
* Re: [PATCH v4 1/4] ethernet: arc: Add support for Rockchip SoC layer device tree bindings
From: Arnd Bergmann @ 2014-09-03 11:14 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Romain Perier, heiko, linux-rockchip, devicetree, netdev
In-Reply-To: <1409740036-8117-1-git-send-email-romain.perier@gmail.com>
On Wednesday 03 September 2014 10:27:13 Romain Perier wrote:
> +static const struct emac_rockchip_soc_data emac_rockchip_dt_data[] = {
> + { .grf_offset = 0x154 }, /* rk3066 */
> + { .grf_offset = 0x0a4 }, /* rk3188 */
> +};
> +
> +static const struct of_device_id emac_rockchip_dt_ids[] = {
> + { .compatible = "rockchip,rk3066-emac", .data = &emac_rockchip_dt_data[0] },
> + { .compatible = "rockchip,rk3188-emac", .data = &emac_rockchip_dt_data[1] },
> + { /* Sentinel */ }
> +};
> +
>
One last question: is this the location given as .grf_offset the
only thing in grf that is potentially of concern to this driver?
If it is, you can change the binding to include the register number
in the syscon reference, like
rockchip,grf = <&grf 0x154>;
and then read it from there, to simplify the code needed to get the
number from the device id.
Arnd
^ permalink raw reply
* [net-next PATCH] qdisc: validate frames going through the direct_xmit path
From: Jesper Dangaard Brouer @ 2014-09-03 11:48 UTC (permalink / raw)
To: Jesper Dangaard Brouer, David S. Miller, Alexander Duyck, netdev
Cc: Eric Dumazet
In-Reply-To: <20140902225548.885.79277.stgit@ahduyck-bv4.jf.intel.com>
In commit 50cbe9ab5f8d ("net: Validate xmit SKBs right when we pull them
out of the qdisc") the validation code was moved out of dev_hard_start_xmit
and into dequeue_skb. However this overlooked the fact that we do not
always enqueue the skb onto a qdisc, if qdisc have flag TCQ_F_CAN_BYPASS.
As a result Alex was seeing issues trying to connect to a vhost_net interface
after this patch was applied.
Added a call to validate_xmit_skb in __dev_xmit_skb(), in the code path
for qdiscs with TCQ_F_CAN_BYPASS flag.
Fixes: 50cbe9ab5f8d ("net: Validate xmit SKBs right when we pull them out of the qdisc")
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
net/core/dev.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 3774afc..5bbac90 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2739,7 +2739,8 @@ static inline int __dev_xmit_skb(struct sk_buff *skb, struct Qdisc *q,
qdisc_bstats_update(q, skb);
- if (sch_direct_xmit(skb, q, dev, txq, root_lock)) {
+ skb = validate_xmit_skb(skb, dev);
+ if (skb && sch_direct_xmit(skb, q, dev, txq, root_lock)) {
if (unlikely(contended)) {
spin_unlock(&q->busylock);
contended = false;
^ permalink raw reply related
* Re: [PATCH] net: Validate frames going through the direct_xmit path
From: Jesper Dangaard Brouer @ 2014-09-03 11:57 UTC (permalink / raw)
To: Alexander Duyck; +Cc: brouer, Eric Dumazet, Alexander Duyck, netdev, davem
In-Reply-To: <5406810A.9070900@gmail.com>
On Tue, 02 Sep 2014 19:46:34 -0700
Alexander Duyck <alexander.duyck@gmail.com> wrote:
> Alternative patches always welcome. :-) My goal at this point is to
> just have my vhost_net interface work so I can get back to my other
> development work. I will submit a v2 in the morning if I don't see
> anything.
I've posted a followup, and gave you the SoB.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [ipsec-next v4 0/2] xfrm: scalability enhancements for policy database
From: Steffen Klassert @ 2014-09-03 11:59 UTC (permalink / raw)
To: Christophe Gouault; +Cc: David S. Miller, netdev
In-Reply-To: <1409321765-2012-1-git-send-email-christophe.gouault@6wind.com>
On Fri, Aug 29, 2014 at 04:16:03PM +0200, Christophe Gouault wrote:
> This patchset enables to hash more policies than just non-prefixed
> ones: hash policies whose prefix lengths are greater or equal to
> configurable thresholds.
>
> These thresholds are configured via netlink message
> XFRM_MSG_NEWSPDINFO, attributes XFRMA_SPD_IPV4_HTHRESH and
> XFRMA_SPD_IPV6_HTHRESH.
>
> The related iproute2 patch for configuring the thresholds is available
> on demand.
>
> Best Regards,
> Christophe
> ----
> v2:
> - change configuration API from proc to netlink
> v3:
> - initialize xfrm_policy_hthresh lock
> - remove "rebuilding SPD hash table" log
> - replace deprecated hlist_add_after by hlist_add_behind
> - remove netlink reply to XFRM_MSG_NEWSPDINFO request
> v4:
> - remove unused variables in xfrm_set_spdinfo
Looks good. All applied to ipsec-next, thanks a lot Christophe!
^ permalink raw reply
* Re: [RFC] net: ipv4: drop unicast encapsulated in L2 multicast
From: Hannes Frederic Sowa @ 2014-09-03 12:01 UTC (permalink / raw)
To: David Miller
Cc: hideaki.yoshifuji-GmhWrQMWH5w7YuNMryXyOw,
johannes-cdvu00un1VgdHxzADdlk8Q,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, yoshfuji-VfPWfsRibaP+Ru+s062T9g
In-Reply-To: <20140902.150326.1420682815750767731.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Di, 2014-09-02 at 15:03 -0700, David Miller wrote:
> From: YOSHIFUJI Hideaki <hideaki.yoshifuji-GmhWrQMWH5w7YuNMryXyOw@public.gmane.org>
> Date: Wed, 03 Sep 2014 10:59:14 +0900
>
> > Upper-layer needs to cope eith situation of seeing packets with
> > "incorrect" L2 header anyway (e.g., in promiscous mode).
> > I do not see much advantage to drop them here.
>
> It's required to prevent wireless nodes from using the shared wireless
> group keys (used for multicast transmission) to inject unicast frames.
>
> The RFCs really do specify this at least on the ipv4 side.
I have to agree with YOSHIFUJI Hideaki here. I looked at a lot of RFCs
and haven't found anything were it states to use L2 address type for
checks in L3 ipv6 addresses. For IPv4 addresses the situation is clear
though...
There was an RFC update (6085) which specifically allows one to send
ipv6 multicast frames with unicast L2 addresses. In the dicussion that
lead to this RFC it was stated that checking L2 and L3 addresses seems
to be a layering violation, but I can just use this as a hint.
Bye,
Hannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next] sock: consistent errqueue errors and signals
From: Hannes Frederic Sowa @ 2014-09-03 12:14 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: netdev, davem
In-Reply-To: <1409534896-372-1-git-send-email-willemb@google.com>
On So, 2014-08-31 at 21:28 -0400, Willem de Bruijn wrote:
> When a socket error is pending, send()/recv() must abort their normal
> operation and return the error. An error means having non-zero
> sk->sk_err or having non-empty sk->sk_error_queue.
>
> Currently, the behavior for the second is inconsistent depending on
> whether an error has previously been dequeued. In all cases,
> recv()/send() test sk->sk_err. This is not modified on enqueue onto
> the error queue, so may be 0. It is modified on dequeue, however, to
> match the queued skb's errno. I observed the following when two errors
> were queued:
>
> ret = poll(pollfd, 1, -1);
> assert(ret == 1);
> assert(pollfd.revents == POLLERR);
>
> ret = recv(fd, buf, size, MSG_NONBLOCK);
> assert(ret == -1 && errno == EAGAIN); /* <-- A */
>
> ret = recv(fd, buf, size, MSG_ERRQUEUE);
> assert(ret > 0);
>
> ret = recv(fd, buf, size, MSG_NONBLOCK);
> assert(ret == -1 && errno == ENOMSG); /* <-- B */
>
> ret = recv(fd, buf, size, MSG_ERRQUEUE);
> assert(ret > 0);
>
> The recv call in B returns the error code embedded in
> SKB_EXT_ERR(skb), in this case ENOMSG, because I am working with
> timestamps. The recv call in A should have returned the
> same.
>
> Implement this behavior. This may surprise existing applications.
>
> Also make the wake-up signal when data is ready on the error queue
> consistent between enqueue and dequeue: use sk_error_report in both
> cases.
>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
>
> ---
>
> This approach leaves one issue:
> The states of sk->sk_err and sk->sk_error_queue are related, but only
> loosely. Error queue enqueue, dequeue and other code may overwrite
> sk->sk_err unconditionally. For one, sock_error will reset
> sk->sk_err to 0 even if sk->sk_error_queue is not empty. If socket
> calls should abort on all errors, then should be change to test
> sk_error_queue.qlen. But, doing so requires taking a lock in a busy
> data path.
> ---
> net/core/skbuff.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 163b673..f7a280b 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -3485,8 +3485,11 @@ int sock_queue_err_skb(struct sock *sk, struct sk_buff *skb)
> skb_dst_force(skb);
>
> skb_queue_tail(&sk->sk_error_queue, skb);
> + sk->sk_err = SKB_EXT_ERR(skb)->ee.ee_errno;
> +
> if (!sock_flag(sk, SOCK_DEAD))
> - sk->sk_data_ready(sk);
> + sk->sk_error_report(sk);
> +
> return 0;
> }
> EXPORT_SYMBOL(sock_queue_err_skb);
I just noticed another problem with this approach why I think we cannot
use it.
In case we generate an error back to the socket locally because
something (e.g. the packet was too big) in output path, we must not
update sk->sk_err because we return it immediately to the sender but
nonetheless must update the error queue.
It seems to me that this patch would report the same error two times to
the program then.
I'll check your other patch later today, thanks!
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH v4 1/4] ethernet: arc: Add support for Rockchip SoC layer device tree bindings
From: Heiko Stübner @ 2014-09-03 12:20 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Romain Perier, linux-rockchip, devicetree,
netdev
In-Reply-To: <3774938.44qiV4hEoE@wuerfel>
Am Mittwoch, 3. September 2014, 13:14:54 schrieb Arnd Bergmann:
> On Wednesday 03 September 2014 10:27:13 Romain Perier wrote:
> > +static const struct emac_rockchip_soc_data emac_rockchip_dt_data[] = {
> > + { .grf_offset = 0x154 }, /* rk3066 */
> > + { .grf_offset = 0x0a4 }, /* rk3188 */
> > +};
> > +
> > +static const struct of_device_id emac_rockchip_dt_ids[] = {
> > + { .compatible = "rockchip,rk3066-emac", .data =
> > &emac_rockchip_dt_data[0] }, + { .compatible =
> > "rockchip,rk3188-emac", .data = &emac_rockchip_dt_data[1] }, + { /*
> > Sentinel */ }
> > +};
> > +
>
> One last question: is this the location given as .grf_offset the
> only thing in grf that is potentially of concern to this driver?
>
> If it is, you can change the binding to include the register number
> in the syscon reference, like
>
> rockchip,grf = <&grf 0x154>;
>
> and then read it from there, to simplify the code needed to get the
> number from the device id.
I would disagree here :-)
Specific to the emac, there also exists a second register in the grf (0xa8 for
the rk3188) that contains a field
----
emac_newrcv_en - the selection of RMII receive selection
0: don't support the data package without header
1: support the data package without header
----
which we don't handle currently but somebody might want to in the future.
[There also is no documentation of this at all]
The dt maintainers also generally suggest to define compatibles for the
individual socs anyway, even if only one is matched, so I don't see the
necessity to encode this 2 times
compatible = "rockchip,rk3188-emac", "rockchip,rk3066-emac";
rockchip,grf = <&grf 0xa4>;
instead of the more flexible
compatible = "rockchip,rk3188-emac";
rockchip,grf = <&grf>;
which other rockchip drivers already use in this form.
Heiko
^ permalink raw reply
* [PATCH net] l2tp: fix race while getting PMTU on PPP pseudo-wire
From: Guillaume Nault @ 2014-09-03 12:12 UTC (permalink / raw)
To: netdev; +Cc: James Chapman, David S. Miller
Use dst_entry held by sk_dst_get() to retrieve tunnel's PMTU.
The dst_mtu(__sk_dst_get(tunnel->sock)) call was racy. __sk_dst_get()
could return NULL if tunnel->sock->sk_dst_cache was reset just before the
call, thus making dst_mtu() dereference a NULL pointer:
[ 1937.661598] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
[ 1937.664005] IP: [<ffffffffa049db88>] pppol2tp_connect+0x33d/0x41e [l2tp_ppp]
[ 1937.664005] PGD daf0c067 PUD d9f93067 PMD 0
[ 1937.664005] Oops: 0000 [#1] SMP
[ 1937.664005] Modules linked in: l2tp_ppp l2tp_netlink l2tp_core ip6table_filter ip6_tables iptable_filter ip_tables ebtable_nat ebtables x_tables udp_tunnel pppoe pppox ppp_generic slhc deflate ctr twofish_generic twofish_x86_64_3way xts lrw gf128mul glue_helper twofish_x86_64 twofish_common blowfish_generic blowfish_x86_64 blowfish_common des_generic cbc xcbc rmd160 sha512_generic hmac crypto_null af_key xfrm_algo 8021q garp bridge stp llc tun atmtcp clip atm ext3 mbcache jbd iTCO_wdt coretemp kvm_intel iTCO_vendor_support kvm pcspkr evdev ehci_pci lpc_ich mfd_core i5400_edac edac_core i5k_amb shpchp button processor thermal_sys xfs crc32c_generic libcrc32c dm_mod usbhid sg hid sr_mod sd_mod cdrom crc_t10dif crct10dif_common ata_generic ahci ata_piix tg3 libahci libata uhci_hcd ptp ehci
_hcd pps_core usbcore scsi_mod libphy usb_common [last unloaded: l2tp_core]
[ 1937.664005] CPU: 0 PID: 10022 Comm: l2tpstress Tainted: G O 3.17.0-rc1 #1
[ 1937.664005] Hardware name: HP ProLiant DL160 G5, BIOS O12 08/22/2008
[ 1937.664005] task: ffff8800d8fda790 ti: ffff8800c43c4000 task.ti: ffff8800c43c4000
[ 1937.664005] RIP: 0010:[<ffffffffa049db88>] [<ffffffffa049db88>] pppol2tp_connect+0x33d/0x41e [l2tp_ppp]
[ 1937.664005] RSP: 0018:ffff8800c43c7de8 EFLAGS: 00010282
[ 1937.664005] RAX: ffff8800da8a7240 RBX: ffff8800d8c64600 RCX: 000001c325a137b5
[ 1937.664005] RDX: 8c6318c6318c6320 RSI: 000000000000010c RDI: 0000000000000000
[ 1937.664005] RBP: ffff8800c43c7ea8 R08: 0000000000000000 R09: 0000000000000000
[ 1937.664005] R10: ffffffffa048e2c0 R11: ffff8800d8c64600 R12: ffff8800ca7a5000
[ 1937.664005] R13: ffff8800c439bf40 R14: 000000000000000c R15: 0000000000000009
[ 1937.664005] FS: 00007fd7f610f700(0000) GS:ffff88011a600000(0000) knlGS:0000000000000000
[ 1937.664005] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 1937.664005] CR2: 0000000000000020 CR3: 00000000d9d75000 CR4: 00000000000027e0
[ 1937.664005] Stack:
[ 1937.664005] ffffffffa049da80 ffff8800d8fda790 000000000000005b ffff880000000009
[ 1937.664005] ffff8800daf3f200 0000000000000003 ffff8800c43c7e48 ffffffff81109b57
[ 1937.664005] ffffffff81109b0e ffffffff8114c566 0000000000000000 0000000000000000
[ 1937.664005] Call Trace:
[ 1937.664005] [<ffffffffa049da80>] ? pppol2tp_connect+0x235/0x41e [l2tp_ppp]
[ 1937.664005] [<ffffffff81109b57>] ? might_fault+0x9e/0xa5
[ 1937.664005] [<ffffffff81109b0e>] ? might_fault+0x55/0xa5
[ 1937.664005] [<ffffffff8114c566>] ? rcu_read_unlock+0x1c/0x26
[ 1937.664005] [<ffffffff81309196>] SYSC_connect+0x87/0xb1
[ 1937.664005] [<ffffffff813e56f7>] ? sysret_check+0x1b/0x56
[ 1937.664005] [<ffffffff8107590d>] ? trace_hardirqs_on_caller+0x145/0x1a1
[ 1937.664005] [<ffffffff81213dee>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 1937.664005] [<ffffffff8114c262>] ? spin_lock+0x9/0xb
[ 1937.664005] [<ffffffff813092b4>] SyS_connect+0x9/0xb
[ 1937.664005] [<ffffffff813e56d2>] system_call_fastpath+0x16/0x1b
[ 1937.664005] Code: 10 2a 84 81 e8 65 76 bd e0 65 ff 0c 25 10 bb 00 00 4d 85 ed 74 37 48 8b 85 60 ff ff ff 48 8b 80 88 01 00 00 48 8b b8 10 02 00 00 <48> 8b 47 20 ff 50 20 85 c0 74 0f 83 e8 28 89 83 10 01 00 00 89
[ 1937.664005] RIP [<ffffffffa049db88>] pppol2tp_connect+0x33d/0x41e [l2tp_ppp]
[ 1937.664005] RSP <ffff8800c43c7de8>
[ 1937.664005] CR2: 0000000000000020
[ 1939.559375] ---[ end trace 82d44500f28f8708 ]---
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
---
net/l2tp/l2tp_ppp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/l2tp/l2tp_ppp.c b/net/l2tp/l2tp_ppp.c
index 13752d9..b704a93 100644
--- a/net/l2tp/l2tp_ppp.c
+++ b/net/l2tp/l2tp_ppp.c
@@ -755,7 +755,8 @@ static int pppol2tp_connect(struct socket *sock, struct sockaddr *uservaddr,
/* If PMTU discovery was enabled, use the MTU that was discovered */
dst = sk_dst_get(tunnel->sock);
if (dst != NULL) {
- u32 pmtu = dst_mtu(__sk_dst_get(tunnel->sock));
+ u32 pmtu = dst_mtu(dst);
+
if (pmtu != 0)
session->mtu = session->mru = pmtu -
PPPOL2TP_HEADER_OVERHEAD;
--
2.1.0
^ permalink raw reply related
* Re: [net-next PATCH 2/3] qdisc: bulk dequeue support for qdiscs with TCQ_F_ONETXQUEUE
From: Jesper Dangaard Brouer @ 2014-09-03 12:27 UTC (permalink / raw)
To: Daniel Borkmann
Cc: David S. Miller, netdev, Florian Westphal, Hannes Frederic Sowa,
brouer
In-Reply-To: <5405ECEC.601@redhat.com>
On Tue, 02 Sep 2014 18:14:36 +0200
Daniel Borkmann <dborkman@redhat.com> wrote:
> On 09/02/2014 04:35 PM, Jesper Dangaard Brouer wrote:
>
> > This patch implements qdisc bulk dequeue, by allowing multiple packets
> > to be dequeued in dequeue_skb().
> >
[...]
> This check should better be an inline for sch_generic.h, e.g. ...
>
> static inline bool qdisc_may_bulk(const struct Qdisc *qdisc,
> const struct sk_buff *skb)
> {
> return (qdisc->flags & TCQ_F_ONETXQUEUE) && !skb->next;
> }
Good ideas of inlining these functions, it should help readability of
the code, thanks.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [net-next PATCH 0/3] qdisc bulk dequeuing and utilizing delayed tailptr updates
From: Jesper Dangaard Brouer @ 2014-09-03 12:47 UTC (permalink / raw)
To: Tom Herbert
Cc: David S. Miller, Linux Netdev List, Florian Westphal,
Hannes Frederic Sowa, Daniel Borkmann, brouer
In-Reply-To: <CA+mtBx8JVqb0TXEOLimAv0hh_g5pfTRg08uNp2idcy=nWhk0_A@mail.gmail.com>
On Tue, 2 Sep 2014 11:04:06 -0700
Tom Herbert <therbert@google.com> wrote:
> On Tue, Sep 2, 2014 at 7:35 AM, Jesper Dangaard Brouer
> <brouer@redhat.com> wrote:
> > This patchset uses DaveM's recent API changes to dev_hard_start_xmit(),
> > from the qdisc layer, to implement dequeue bulking.
> >
> > Open questions:
> >
> > - For now set bulk limit to 8 packets, don't want to stress the driver
> > avail ring_buffer space.
> >
> Please get limit from BQL also, see:
> [PATCH net-next] net: Functions to report space available in device TX queues
Thank you Tom. I will include that patch in my stack (keeping you as
author), and use the functions you are proposing.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH v4 1/4] ethernet: arc: Add support for Rockchip SoC layer device tree bindings
From: Arnd Bergmann @ 2014-09-03 12:50 UTC (permalink / raw)
To: Heiko Stübner
Cc: linux-arm-kernel, Romain Perier, linux-rockchip, devicetree,
netdev
In-Reply-To: <12261801.xhz3LcucGs@diego>
On Wednesday 03 September 2014 14:20:50 Heiko Stübner wrote:
> >
> > One last question: is this the location given as .grf_offset the
> > only thing in grf that is potentially of concern to this driver?
> >
> > If it is, you can change the binding to include the register number
> > in the syscon reference, like
> >
> > rockchip,grf = <&grf 0x154>;
> >
> > and then read it from there, to simplify the code needed to get the
> > number from the device id.
>
> I would disagree here
>
> Specific to the emac, there also exists a second register in the grf (0xa8 for
> the rk3188) that contains a field
>
> ----
> emac_newrcv_en - the selection of RMII receive selection
> 0: don't support the data package without header
> 1: support the data package without header
> ----
>
> which we don't handle currently but somebody might want to in the future.
> [There also is no documentation of this at all]
Ok, fair enough. If there is a chance that there would be more of these
fields that we may want to support in the future, the table approach
seems reasonable.
The main advantage of putting the register number into the syscon
reference is to support future models without driver changes, but
it's not clear if that's worth it.
Arnd
^ permalink raw reply
* Re: [ipsec-next v4 0/2] xfrm: scalability enhancements for policy database
From: Christophe Gouault @ 2014-09-03 12:53 UTC (permalink / raw)
To: Steffen Klassert; +Cc: David S. Miller, netdev@vger.kernel.org
In-Reply-To: <20140903115913.GH6390@secunet.com>
2014-09-03 13:59 GMT+02:00 Steffen Klassert <steffen.klassert@secunet.com>:
> On Fri, Aug 29, 2014 at 04:16:03PM +0200, Christophe Gouault wrote:
>> This patchset enables to hash more policies than just non-prefixed
>> ones: hash policies whose prefix lengths are greater or equal to
>> configurable thresholds.
> Looks good. All applied to ipsec-next, thanks a lot Christophe!
You're welcome.
Thanks for reviewing.
Christophe
^ permalink raw reply
* Re: [PATCH v2 net-next] net: Functions to report space available in device TX queues
From: Jesper Dangaard Brouer @ 2014-09-03 13:20 UTC (permalink / raw)
To: Tom Herbert; +Cc: brouer, davem, netdev, Eric Dumazet
In-Reply-To: <alpine.DEB.2.02.1408250823440.31745@tomh.mtv.corp.google.com>
On Mon, 25 Aug 2014 08:27:56 -0700 (PDT)
Tom Herbert <therbert@google.com> wrote:
> This patch adds netdev_tx_avail_queue and netdev_avail_queue which are
> used to report number of bytes available in transmit queues per BQL. The
> functions call dql_avail which returns BQL limit minus number of
> inflight bytes. These functions can be called without txlock, for
> instance to ascertain how much data should be dequeued from a qdisc in
> a batch. When called without the tx_lock, the result is technically a
> hint, subsequently when the tx_lock is done for a transmit it is
> possible the availability has changed (for example a transmit
> completion may have freed up more space in the queue or changed the
> limit).
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
> include/linux/netdevice.h | 28 ++++++++++++++++++++++++++--
> 1 file changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 0fac884..bdf6c85 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -2544,6 +2544,30 @@ static inline void netdev_completed_queue(struct net_device *dev,
> netdev_tx_completed_queue(netdev_get_tx_queue(dev, 0), pkts, bytes);
> }
>
> +static inline int netdev_tx_avail_queue(struct netdev_queue *dev_queue)
> +{
> +#ifdef CONFIG_BQL
> + return dql_avail(&dev_queue->dql);
> +#else
> + return DQL_MAX_LIMIT;
> +#endif
> +}
> +
> +/**
> + * netdev_avail_queue - report how much space is availble for xmit
> + * @dev: network device
> + *
> + * Report the amount of space available in the TX queue in terms of
> + * number of bytes. This returns the number of bytes avaiable per
> + * DQL. This function may be called without taking the txlock on
> + * the device, however in that case the result should be taken as
> + * a (strong) hint.
> + */
> +static inline int netdev_avail_queue(struct net_device *dev)
> +{
> + return netdev_tx_avail_queue(netdev_get_tx_queue(dev, 0));
> +}
> +
How can this work, when you are always passing 0 to: netdev_get_tx_queue(dev, 0)
???
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH] v2 fec_main iMX6Q DMA-API: device driver tries to free DMA memory it has not allocated
From: Russell King - ARM Linux @ 2014-09-03 13:38 UTC (permalink / raw)
To: Anand Moon
Cc: David S. Miller, Nimrod Andy, Frank Li, Fabio Estevam,
Uwe Kleine-König, fugang.duan, netdev, linux-kernel
In-Reply-To: <1409746850-30850-1-git-send-email-moon.linux@yahoo.com>
On Wed, Sep 03, 2014 at 05:50:50PM +0530, Anand Moon wrote:
> Check was added to check dma address should not be 0x0000000000000000
> before unmap the dma.
> v1: remove unnecessary of bdp->cbd_bufaddr as suggested
> by Andy <fugang.duan@freescale.com>
I still have a whole pile of commits, one of them cleans up the handling
of this stuff. Please hold off on this for the time being until I can
dig out the appropriate commit.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCH v2 net-next] net: Functions to report space available in device TX queues
From: Eric Dumazet @ 2014-09-03 13:41 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: Tom Herbert, davem, netdev
In-Reply-To: <20140903152046.3c07a052@redhat.com>
On Wed, 2014-09-03 at 15:20 +0200, Jesper Dangaard Brouer wrote:
> On Mon, 25 Aug 2014 08:27:56 -0700 (PDT)
> Tom Herbert <therbert@google.com> wrote:
>
> > This patch adds netdev_tx_avail_queue and netdev_avail_queue which are
> > used to report number of bytes available in transmit queues per BQL. The
> > functions call dql_avail which returns BQL limit minus number of
> > inflight bytes. These functions can be called without txlock, for
> > instance to ascertain how much data should be dequeued from a qdisc in
> > a batch. When called without the tx_lock, the result is technically a
> > hint, subsequently when the tx_lock is done for a transmit it is
> > possible the availability has changed (for example a transmit
> > completion may have freed up more space in the queue or changed the
> > limit).
> >
> > Signed-off-by: Tom Herbert <therbert@google.com>
> > ---
> > include/linux/netdevice.h | 28 ++++++++++++++++++++++++++--
> > 1 file changed, 26 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> > index 0fac884..bdf6c85 100644
> > --- a/include/linux/netdevice.h
> > +++ b/include/linux/netdevice.h
> > @@ -2544,6 +2544,30 @@ static inline void netdev_completed_queue(struct net_device *dev,
> > netdev_tx_completed_queue(netdev_get_tx_queue(dev, 0), pkts, bytes);
> > }
> >
> > +static inline int netdev_tx_avail_queue(struct netdev_queue *dev_queue)
> > +{
> > +#ifdef CONFIG_BQL
> > + return dql_avail(&dev_queue->dql);
> > +#else
> > + return DQL_MAX_LIMIT;
> > +#endif
> > +}
> > +
> > +/**
> > + * netdev_avail_queue - report how much space is availble for xmit
> > + * @dev: network device
> > + *
> > + * Report the amount of space available in the TX queue in terms of
> > + * number of bytes. This returns the number of bytes avaiable per
> > + * DQL. This function may be called without taking the txlock on
> > + * the device, however in that case the result should be taken as
> > + * a (strong) hint.
> > + */
> > +static inline int netdev_avail_queue(struct net_device *dev)
> > +{
> > + return netdev_tx_avail_queue(netdev_get_tx_queue(dev, 0));
> > +}
> > +
>
> How can this work, when you are always passing 0 to: netdev_get_tx_queue(dev, 0)
> ???
>
This is the helper for drivers having a single TX queue.
^ permalink raw reply
* Re: [net-next PATCH] qdisc: validate frames going through the direct_xmit path
From: Eric Dumazet @ 2014-09-03 13:43 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: David S. Miller, Alexander Duyck, netdev
In-Reply-To: <20140903114841.19969.22671.stgit@dragon>
On Wed, 2014-09-03 at 13:48 +0200, Jesper Dangaard Brouer wrote:
> In commit 50cbe9ab5f8d ("net: Validate xmit SKBs right when we pull them
> out of the qdisc") the validation code was moved out of dev_hard_start_xmit
> and into dequeue_skb. However this overlooked the fact that we do not
> always enqueue the skb onto a qdisc, if qdisc have flag TCQ_F_CAN_BYPASS.
>
> As a result Alex was seeing issues trying to connect to a vhost_net interface
> after this patch was applied.
>
> Added a call to validate_xmit_skb in __dev_xmit_skb(), in the code path
> for qdiscs with TCQ_F_CAN_BYPASS flag.
>
> Fixes: 50cbe9ab5f8d ("net: Validate xmit SKBs right when we pull them out of the qdisc")
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> ---
Jesper, you missed another spot, when there is no qdisc on the device.
__dev_queue_xmit() calls dev_hard_start_xmit() around line 2886
Could we try to not add a myriad of small patches ?
Some of us will need to backport all of them.
Thanks.
^ 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