* [PATCH v6 04/21] dt-bindings: syscon: Add DT bindings documentation for Allwinner syscon
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
In-Reply-To: <20170531071852.12422-1-clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
This patch adds documentation for Device-Tree bindings for the
syscon present in allwinner devices.
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
.../devicetree/bindings/misc/allwinner,syscon.txt | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/allwinner,syscon.txt
diff --git a/Documentation/devicetree/bindings/misc/allwinner,syscon.txt b/Documentation/devicetree/bindings/misc/allwinner,syscon.txt
new file mode 100644
index 000000000000..cb5769137c6c
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/allwinner,syscon.txt
@@ -0,0 +1,19 @@
+* Allwinner sun8i system controller
+
+This file describes the bindings for the system controller present in
+Allwinner SoC H3, A83T and A64.
+The principal function of this syscon is to control EMAC PHY choice and
+config.
+
+Required properties for the system controller:
+- reg: address and length of the register for the device.
+- compatible: should be "syscon" and one of the following string:
+ "allwinner,sun8i-h3-system-controller"
+ "allwinner,sun50i-a64-system-controller"
+ "allwinner,sun8i-a83t-system-controller"
+
+Example:
+syscon: syscon@1c00000 {
+ compatible = "allwinner,sun8i-h3-system-controller", "syscon";
+ reg = <0x01c00000 0x1000>;
+};
--
2.13.0
^ permalink raw reply related
* [PATCH v6 03/21] dt-bindings: net-next: Add DT bindings documentation for Allwinner dwmac-sun8i
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
In-Reply-To: <20170531071852.12422-1-clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
This patch adds documentation for Device-Tree bindings for the
Allwinner dwmac-sun8i driver.
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
.../devicetree/bindings/net/dwmac-sun8i.txt | 78 ++++++++++++++++++++++
1 file changed, 78 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/dwmac-sun8i.txt
diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
new file mode 100644
index 000000000000..08e708c73193
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
@@ -0,0 +1,78 @@
+* Allwinner sun8i GMAC ethernet controller
+
+This device is a platform glue layer for stmmac.
+Please see stmmac.txt for the other unchanged properties.
+
+Required properties:
+- compatible: should be one of the following string:
+ "allwinner,sun8i-a83t-emac"
+ "allwinner,sun8i-h3-emac"
+ "allwinner,sun50i-a64-emac"
+- reg: address and length of the register for the device.
+- interrupts: interrupt for the device
+- interrupt-names: should be "macirq"
+- clocks: A phandle to the reference clock for this device
+- clock-names: should be "stmmaceth"
+- resets: A phandle to the reset control for this device
+- reset-names: should be "stmmaceth"
+- phy-mode: See ethernet.txt
+- phy-handle: See ethernet.txt
+- #address-cells: shall be 1
+- #size-cells: shall be 0
+- syscon: A phandle to the syscon of the SoC with one of the following
+ compatible string:
+ - allwinner,sun8i-h3-system-controller
+ - allwinner,sun50i-a64-system-controller
+ - allwinner,sun8i-a83t-system-controller
+
+Optional properties:
+- allwinner,tx-delay-ps: TX clock delay chain value in ps. Range value is 0-700. Default is 0)
+- allwinner,rx-delay-ps: RX clock delay chain value in ps. Range value is 0-3100. Default is 0)
+Both delay properties need to be a multiple of 100. They control the delay for
+external PHY.
+
+Optional properties for "allwinner,sun8i-h3-emac":
+- allwinner,leds-active-low: EPHY LEDs are active low
+
+Required child node of emac:
+- mdio bus node: should be named mdio
+
+Required properties of the mdio node:
+- #address-cells: shall be 1
+- #size-cells: shall be 0
+
+The device node referenced by "phy" or "phy-handle" should be a child node
+of the mdio node. See phy.txt for the generic PHY bindings.
+
+Required properties of the phy node with "allwinner,sun8i-h3-emac":
+- clocks: a phandle to the reference clock for the EPHY
+- resets: a phandle to the reset control for the EPHY
+
+Example:
+
+emac: ethernet@1c0b000 {
+ compatible = "allwinner,sun8i-h3-emac";
+ syscon = <&syscon>;
+ reg = <0x01c0b000 0x104>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+ resets = <&ccu RST_BUS_EMAC>;
+ reset-names = "stmmaceth";
+ clocks = <&ccu CLK_BUS_EMAC>;
+ clock-names = "stmmaceth";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ int_mii_phy: ethernet-phy@1 {
+ reg = <1>;
+ clocks = <&ccu CLK_BUS_EPHY>;
+ resets = <&ccu RST_BUS_EPHY>;
+ };
+ };
+};
--
2.13.0
^ permalink raw reply related
* [PATCH v6 02/21] net-next: stmmac: add optional setup function
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
In-Reply-To: <20170531071852.12422-1-clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Instead of adding more ifthen logic for adding a new mac_device_info
setup function, it is easier to add a function pointer to the function
needed.
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +++-
include/linux/stmmac.h | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index f158273eab9b..c80c9c3b67db 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3933,7 +3933,9 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
struct mac_device_info *mac;
/* Identify the MAC HW device */
- if (priv->plat->has_gmac) {
+ if (priv->plat->setup) {
+ mac = priv->plat->setup(priv);
+ } else if (priv->plat->has_gmac) {
priv->dev->priv_flags |= IFF_UNICAST_FLT;
mac = dwmac1000_setup(priv->ioaddr,
priv->plat->multicast_filter_bins,
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 3921cb9dfadb..8bb550bca96d 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -177,6 +177,7 @@ struct plat_stmmacenet_data {
void (*fix_mac_speed)(void *priv, unsigned int speed);
int (*init)(struct platform_device *pdev, void *priv);
void (*exit)(struct platform_device *pdev, void *priv);
+ struct mac_device_info *(*setup)(void *priv);
void *bsp_priv;
struct clk *stmmac_clk;
struct clk *pclk;
--
2.13.0
^ permalink raw reply related
* [PATCH v6 01/21] net-next: stmmac: export stmmac_set_mac_addr/stmmac_get_mac_addr
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
In-Reply-To: <20170531071852.12422-1-clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Thoses symbol will be needed for the dwmac-sun8i ethernet driver.
For letting it to be build as module, they need to be exported.
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c b/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
index 38f94305aab5..67af0bdd7f10 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
@@ -248,6 +248,7 @@ void stmmac_set_mac_addr(void __iomem *ioaddr, u8 addr[6],
data = (addr[3] << 24) | (addr[2] << 16) | (addr[1] << 8) | addr[0];
writel(data, ioaddr + low);
}
+EXPORT_SYMBOL_GPL(stmmac_set_mac_addr);
/* Enable disable MAC RX/TX */
void stmmac_set_mac(void __iomem *ioaddr, bool enable)
@@ -279,4 +280,4 @@ void stmmac_get_mac_addr(void __iomem *ioaddr, unsigned char *addr,
addr[4] = hi_addr & 0xff;
addr[5] = (hi_addr >> 8) & 0xff;
}
-
+EXPORT_SYMBOL_GPL(stmmac_get_mac_addr);
--
2.13.0
^ permalink raw reply related
* [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
Hello
This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
present on Allwinner H3/H5/A83T/A64 SoCs.
This driver is the continuation of the sun8i-emac driver.
During the development, it appeared that in fact the hardware was a modified
version of some dwmac.
So the driver is now written as a glue driver for stmmac.
It supports 10/100/1000 Mbit/s speed with half/full duplex.
It can use an internal PHY (MII 10/100) or an external PHY
via RGMII/RMII.
This patch series enable the driver only for the H3/A64/H5 SoC since A83T
doesn't have the necessary clocks present in mainline.
The driver have been tested on the following boards:
- H3 Orange PI PC, BananaPI-M2+
- A64 Pine64, BananaPi-M64
- A83T BananaPI-M3
The first two patchs are some mandatory changes for letting dwmac-sun8i be used.
The following three patchs add the driver and its documentation.
The remaining are DT patch enabling it.
Regards
Corentin Labbe
Changes since v5:
- Added DT patch for NanoPi neo
- Use the new adjust_link variables (speedxxx/speedmask)
- Made the timeout of readl_poll_timeout from 10 to 100ms
- Fix sun8i_unpower_phy that could be called twice
- Replace phy by phy-handle in doc/dwmac-sun8i.txt
Changes since v4:
- Re-ordered by alphabetical order some DT nodes
- Simplified power/unpower_phy functions by testing the use of internal_phy
- Added a patch for adding dwmac-sun8i to arm64 defconfig
- Fix a typo in sun50i-a64-system-controller (wrongly used sun8i)
- Reworked uc/mc filter address setting
Changes since v3:
- Renamed tx-delay/rx-delay to tx-delay-ps/rx-delay-ps
- fix syscon compatible example
- Changed parameter type for setup() function
- Dropped some DT patchs for boards which I could not test further
Changes since v2:
- corrected order of syscon compatible
- added compatible = "ethernet-phy-ieee802.3-c22 to PHY
- added set_mac function
Changes since v1:
- added TX/RX delay units
- splitted syscon documentation in its own patch
- regulator is now disabled after clk_prepare_enable(gmac->tx_clk) error
- Fixed a memory leak on mac_device_info
- Use now generic pin config for all DT stuff
- CONFIG_DWMAC_SUN8I is now set to y in defconfigs
Corentin Labbe (21):
net-next: stmmac: export stmmac_set_mac_addr/stmmac_get_mac_addr
net-next: stmmac: add optional setup function
dt-bindings: net-next: Add DT bindings documentation for Allwinner
dwmac-sun8i
dt-bindings: syscon: Add DT bindings documentation for Allwinner
syscon
net-next: stmmac: Add dwmac-sun8i
arm: sun8i: sunxi-h3-h5: Add dt node for the syscon control module
arm: sun8i: sunxi-h3-h5: add dwmac-sun8i ethernet driver
arm: sun8i: orangepi-pc: Enable dwmac-sun8i
arm: sun8i: orangepi-zero: Enable dwmac-sun8i
arm: sun8i: orangepi-one: Enable dwmac-sun8i
arm: sun8i: orangepi-2: Enable dwmac-sun8i
arm: sun8i: orangepi-pc-plus: Set EMAC activity LEDs to active high
arm: sun8i: nanopi-neo: Enable dwmac-sun8i
arm64: allwinner: sun50i-a64: Add dt node for the syscon control
module
arm64: allwinner: sun50i-a64: add dwmac-sun8i Ethernet driver
arm64: allwinner: pine64: Enable dwmac-sun8i
arm64: allwinner: pine64-plus: Enable dwmac-sun8i
arm64: allwinner: bananapi-m64: Enable dwmac-sun8i
arm: sunxi: Enable dwmac-sun8i driver on sunxi_defconfig
arm: multi_v7: Enable dwmac-sun8i driver on multi_v7_defconfig
arm64: defconfig: Enable dwmac-sun8i driver on defconfig
.../devicetree/bindings/misc/allwinner,syscon.txt | 19 +
.../devicetree/bindings/net/dwmac-sun8i.txt | 78 ++
arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts | 8 +
arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts | 7 +
arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 8 +
arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 8 +
arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts | 5 +
arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 8 +
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 40 +
arch/arm/configs/multi_v7_defconfig | 1 +
arch/arm/configs/sunxi_defconfig | 1 +
.../boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 15 +
.../boot/dts/allwinner/sun50i-a64-pine64-plus.dts | 17 +-
.../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 16 +
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 41 +
arch/arm64/configs/defconfig | 1 +
drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 +
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 990 +++++++++++++++++++++
drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c | 3 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 19 +-
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 9 +-
include/linux/stmmac.h | 2 +
23 files changed, 1303 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/misc/allwinner,syscon.txt
create mode 100644 Documentation/devicetree/bindings/net/dwmac-sun8i.txt
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
--
2.13.0
^ permalink raw reply
* [PATCH] mISDN: Fix a sleep-in-atomic bug
From: Jia-Ju Bai @ 2017-05-31 7:08 UTC (permalink / raw)
To: isdn, mingo, fweisbec, geliangtang, akpm, davem, yamada.masahiro
Cc: netdev, linux-kernel, Jia-Ju Bai
The driver may sleep under a read spin lock, and the function call path is:
send_socklist (acquire the lock by read_lock)
skb_copy(GFP_KERNEL) --> may sleep
To fix it, the "GFP_KERNEL" is replaced with "GFP_ATOMIC".
Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
---
drivers/isdn/mISDN/stack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/isdn/mISDN/stack.c b/drivers/isdn/mISDN/stack.c
index 8b7faea..422dced 100644
--- a/drivers/isdn/mISDN/stack.c
+++ b/drivers/isdn/mISDN/stack.c
@@ -75,7 +75,7 @@
if (sk->sk_state != MISDN_BOUND)
continue;
if (!cskb)
- cskb = skb_copy(skb, GFP_KERNEL);
+ cskb = skb_copy(skb, GFP_ATOMIC);
if (!cskb) {
printk(KERN_WARNING "%s no skb\n", __func__);
break;
--
1.7.9.5
^ permalink raw reply related
* [PATCH net] mpls: fix clearing of dead nh_flags on link up
From: Roopa Prabhu @ 2017-05-31 6:50 UTC (permalink / raw)
To: davem; +Cc: netdev, dsahern
From: Roopa Prabhu <roopa@cumulusnetworks.com>
recent fixes to use WRITE_ONCE for nh_flags on link up,
accidently ended up leaving the deadflags on a nh. This patch
fixes the WRITE_ONCE to use freshly evaluated nh_flags.
Fixes: 39eb8cd17588 ("net: mpls: rt_nhn_alive and nh_flags should be accessed using READ_ONCE")
Reported-by: Satish Ashok <sashok@cumulusnetworks.com>
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
net/mpls/af_mpls.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mpls/af_mpls.c b/net/mpls/af_mpls.c
index 94b3317..b51582d 100644
--- a/net/mpls/af_mpls.c
+++ b/net/mpls/af_mpls.c
@@ -1483,7 +1483,7 @@ static void mpls_ifup(struct net_device *dev, unsigned int flags)
continue;
alive++;
nh_flags &= ~flags;
- WRITE_ONCE(nh->nh_flags, flags);
+ WRITE_ONCE(nh->nh_flags, nh_flags);
} endfor_nexthops(rt);
WRITE_ONCE(rt->rt_nhn_alive, alive);
--
1.9.1
^ permalink raw reply related
* Re: [PULL] topic/e1000e-fix
From: Daniel Vetter @ 2017-05-31 6:10 UTC (permalink / raw)
To: Dave Airlie
Cc: netdev, intel-gfx@lists.freedesktop.org,
Linux Kernel Mailing List, intel-wired-lan, dri-devel,
David Miller, Jeff Kirsher
In-Reply-To: <CAKMK7uF-b1U7qipgEoYnAjDtrNdvKYT4KkoV2=krikkdGERkCw@mail.gmail.com>
On Wed, May 31, 2017 at 7:54 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> On Wed, May 31, 2017 at 1:06 AM, Dave Airlie <airlied@gmail.com> wrote:
>> On 31 May 2017 at 08:10, David Miller <davem@davemloft.net> wrote:
>>> From: Daniel Vetter <daniel.vetter@ffwll.ch>
>>> Date: Tue, 30 May 2017 22:15:42 +0200
>>>
>>>> If the e1000e maintainer wants to coalesce or not return statements
>>>> this simple way, that's imo on him to change the color as needed.
>>>
>>> That's not how things work.
>>>
>>> If the maintainer wants you to style things a certain way, either you
>>> do it that way or your patch isn't accepted.
>
> Consider this pull a regression report, pls handle it.
And I guess I pile of more cc, to make this regression report
complete. I mean you got the backtrace, bisect and a proposed fix, and
the almost-whitespace change demanded is something gcc does in its
sleep. I'd understand a request to retest if it would be a real
functional change, but in this situation I have no idea why this
regression just can't be fixed already.
Not sure if it's really preferred if regression reports come
incomplete, without bugfix and bisect attached.
-Daniel
>> I'm not really sure why Chris just couldn't respin already.
>>
>> Though really I think Chris should have just asked for a revert of the
>> original patch that broke stuff, instead of trying to patch a driver
>> if he doesn't have time to get the patch right for the maintainer.
>
> Ok, can we pls revert 2800209994f8 ("e1000e: Refactor PM flows") then?
>
> Thanks, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH net-next] powerpc: use asm-generic/socket.h as much as possible
From: Stephen Rothwell @ 2017-05-31 5:43 UTC (permalink / raw)
To: David Miller, Networking
Cc: Michael Ellerman, Benjamin Herrenschmidt, PowerPC, Arnd Bergmann
asm-generic/socket.h already has an exception for the differences that
powerpc needs, so just include it after defining the differences.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/include/uapi/asm/socket.h | 92 +---------------------------------
1 file changed, 1 insertion(+), 91 deletions(-)
Build tested using powerpc allyesconfig, pseries_le_defconfig, 32 bit
and 64 bit allnoconfig and ppc44x_defconfig builds.
Dave, this is on top of the net-next tree and I am sending it to you
since it would produce a conflict if it was merged via the powerpc tree.
diff --git a/arch/powerpc/include/uapi/asm/socket.h b/arch/powerpc/include/uapi/asm/socket.h
index bc4ca72faf99..3c590c7c42c0 100644
--- a/arch/powerpc/include/uapi/asm/socket.h
+++ b/arch/powerpc/include/uapi/asm/socket.h
@@ -8,28 +8,6 @@
* 2 of the License, or (at your option) any later version.
*/
-#include <asm/sockios.h>
-
-/* For setsockopt(2) */
-#define SOL_SOCKET 1
-
-#define SO_DEBUG 1
-#define SO_REUSEADDR 2
-#define SO_TYPE 3
-#define SO_ERROR 4
-#define SO_DONTROUTE 5
-#define SO_BROADCAST 6
-#define SO_SNDBUF 7
-#define SO_RCVBUF 8
-#define SO_SNDBUFFORCE 32
-#define SO_RCVBUFFORCE 33
-#define SO_KEEPALIVE 9
-#define SO_OOBINLINE 10
-#define SO_NO_CHECK 11
-#define SO_PRIORITY 12
-#define SO_LINGER 13
-#define SO_BSDCOMPAT 14
-#define SO_REUSEPORT 15
#define SO_RCVLOWAT 16
#define SO_SNDLOWAT 17
#define SO_RCVTIMEO 18
@@ -37,74 +15,6 @@
#define SO_PASSCRED 20
#define SO_PEERCRED 21
-/* Security levels - as per NRL IPv6 - don't actually do anything */
-#define SO_SECURITY_AUTHENTICATION 22
-#define SO_SECURITY_ENCRYPTION_TRANSPORT 23
-#define SO_SECURITY_ENCRYPTION_NETWORK 24
-
-#define SO_BINDTODEVICE 25
-
-/* Socket filtering */
-#define SO_ATTACH_FILTER 26
-#define SO_DETACH_FILTER 27
-#define SO_GET_FILTER SO_ATTACH_FILTER
-
-#define SO_PEERNAME 28
-#define SO_TIMESTAMP 29
-#define SCM_TIMESTAMP SO_TIMESTAMP
-
-#define SO_ACCEPTCONN 30
-
-#define SO_PEERSEC 31
-#define SO_PASSSEC 34
-#define SO_TIMESTAMPNS 35
-#define SCM_TIMESTAMPNS SO_TIMESTAMPNS
-
-#define SO_MARK 36
-
-#define SO_TIMESTAMPING 37
-#define SCM_TIMESTAMPING SO_TIMESTAMPING
-
-#define SO_PROTOCOL 38
-#define SO_DOMAIN 39
-
-#define SO_RXQ_OVFL 40
-
-#define SO_WIFI_STATUS 41
-#define SCM_WIFI_STATUS SO_WIFI_STATUS
-#define SO_PEEK_OFF 42
-
-/* Instruct lower device to use last 4-bytes of skb data as FCS */
-#define SO_NOFCS 43
-
-#define SO_LOCK_FILTER 44
-
-#define SO_SELECT_ERR_QUEUE 45
-
-#define SO_BUSY_POLL 46
-
-#define SO_MAX_PACING_RATE 47
-
-#define SO_BPF_EXTENSIONS 48
-
-#define SO_INCOMING_CPU 49
-
-#define SO_ATTACH_BPF 50
-#define SO_DETACH_BPF SO_DETACH_FILTER
-
-#define SO_ATTACH_REUSEPORT_CBPF 51
-#define SO_ATTACH_REUSEPORT_EBPF 52
-
-#define SO_CNX_ADVICE 53
-
-#define SCM_TIMESTAMPING_OPT_STATS 54
-
-#define SO_MEMINFO 55
-
-#define SO_INCOMING_NAPI_ID 56
-
-#define SO_COOKIE 57
-
-#define SCM_TIMESTAMPING_PKTINFO 58
+#include <asm-generic/socket.h>
#endif /* _ASM_POWERPC_SOCKET_H */
--
2.11.0
--
Cheers,
Stephen Rothwell
^ permalink raw reply related
* Re: [PATCH net-next 0/8] Introduce bpf ID
From: Martin KaFai Lau @ 2017-05-31 4:30 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, Alexei Starovoitov, Daniel Borkmann, kernel-team
In-Reply-To: <19cd3d0a-12eb-b8ca-a054-62d86ba2a509@gmail.com>
On Tue, May 30, 2017 at 06:35:37PM -0600, David Ahern wrote:
> On 5/30/17 6:08 PM, Martin KaFai Lau wrote:
> > This patch series:
> > 1) Introduce ID for both bpf_prog and bpf_map.
> > 2) Add bpf commands to iterate the prog IDs and map
> > IDs of the system.
> > 3) Add bpf commands to get a prog/map fd from an ID
> > 4) Add bpf command to get prog/map info from a fd.
> > The prog/map info is a jump start in this patchset
> > and it is not meant to be a complete list. They can
> > be extended in the future patches.
>
> Interesting. This really simplifies the bpf retrieval I have been
> working on:
> https://github.com/dsahern/linux/commits/bpf/retrieve-bpf-wip
>
> Having the net device, filter, route, socket, cgroup, etc return the ids
> for attached programs solves the problem of getting a reference to all
> of the places BPF programs can be placed.
Right, it is the idea.
I am also baking some follow-up patches for returning xdp-prog's id
through netlink.
>
> This patch set turns an id into a fd, and my patches allow the fd to be
> used to get the bpf code.
^ permalink raw reply
* Re: [PATCH 1/2] ARM: dts: imx6ul-14x14-evk: Add ksz8081 phy properties
From: Fabio Estevam @ 2017-05-31 4:08 UTC (permalink / raw)
To: Leonard Crestez
Cc: Shawn Guo, Florian Fainelli, Andrew Lunn, Andy Duan,
netdev@vger.kernel.org, Johan Hovold, linux-kernel,
Alexandre Belloni, Philipp Zabel, Fabio Estevam,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <d31aab90fbdecaf4c5f240becb2d0b0efb23f5c3.1496164448.git.leonard.crestez@nxp.com>
On Tue, May 30, 2017 at 2:34 PM, Leonard Crestez
<leonard.crestez@nxp.com> wrote:
> Right now mach-imx6ul registers a fixup for the ksz8081 phy. The same
> register values can be set through the micrel phy driver by using dts
> properties.
>
> This seems preferable and allows cleanly fixing suspend/resume.
>
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* Re: [net-bluetooth] question about potential null pointer dereference
From: Gustavo A. R. Silva @ 2017-05-31 3:36 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Gustavo F. Padovan, Johan Hedberg, David S. Miller,
open list:BLUETOOTH DRIVERS, netdev, linux-kernel
In-Reply-To: <20170530222953.Horde.lmsiZcFwJeJ7pN4QQZ_Fyk7@gator4166.hostgator.com>
Hi Marcel,
Quoting "Gustavo A. R. Silva" <garsilva@embeddedor.com>:
> Hi Marcel,
>
> Quoting Marcel Holtmann <marcel@holtmann.org>:
>
>> Hi Gustavo,
>>
>>> While looking into Coverity ID 1357456 I ran into the following
>>> piece of code at net/bluetooth/smp.c:166
>>>
>>> 166/* The following functions map to the LE SC SMP crypto functions
>>> 167 * AES-CMAC, f4, f5, f6, g2 and h6.
>>> 168 */
>>> 169
>>> 170static int aes_cmac(struct crypto_shash *tfm, const u8 k[16],
>>> const u8 *m,
>>> 171 size_t len, u8 mac[16])
>>> 172{
>>> 173 uint8_t tmp[16], mac_msb[16], msg_msb[CMAC_MSG_MAX];
>>> 174 SHASH_DESC_ON_STACK(desc, tfm);
>>> 175 int err;
>>> 176
>>> 177 if (len > CMAC_MSG_MAX)
>>> 178 return -EFBIG;
>>> 179
>>> 180 if (!tfm) {
>>> 181 BT_ERR("tfm %p", tfm);
>>> 182 return -EINVAL;
>>> 183 }
>>> 184
BTW, what do you think about removing the IF block above?
>>> 185 desc->tfm = tfm;
>>> 186 desc->flags = 0;
>>> 187
>>> 188 /* Swap key and message from LSB to MSB */
>>> 189 swap_buf(k, tmp, 16);
>>> 190 swap_buf(m, msg_msb, len);
>>> 191
>>> 192 SMP_DBG("msg (len %zu) %*phN", len, (int) len, m);
>>> 193 SMP_DBG("key %16phN", k);
>>> 194
>>> 195 err = crypto_shash_setkey(tfm, tmp, 16);
>>> 196 if (err) {
>>> 197 BT_ERR("cipher setkey failed: %d", err);
>>> 198 return err;
>>> 199 }
>>> 200
>>> 201 err = crypto_shash_digest(desc, msg_msb, len, mac_msb);
>>> 202 shash_desc_zero(desc);
>>> 203 if (err) {
>>> 204 BT_ERR("Hash computation error %d", err);
>>> 205 return err;
>>> 206 }
>>> 207
>>> 208 swap_buf(mac_msb, mac, 16);
>>> 209
>>> 210 SMP_DBG("mac %16phN", mac);
>>> 211
>>> 212 return 0;
>>> 213}
>>>
>>> The issue here is that line 180 implies that pointer tfm might be
>>> NULL. If this is the case, there is a potential NULL pointer
>>> dereference at line 174 once pointer tfm is indirectly
>>> dereferenced inside macro SHASH_DESC_ON_STACK().
>>>
>>> My question is if there is any chance that pointer tfm maybe be
>>> NULL when calling macro SHASH_DESC_ON_STACK()?
>>
>> I think the part you are after is this:
>>
>> smp->tfm_cmac = crypto_alloc_shash("cmac(aes)", 0, 0);
>> if (IS_ERR(smp->tfm_cmac)) {
>> BT_ERR("Unable to create CMAC crypto context");
>> crypto_free_cipher(smp->tfm_aes);
>> kzfree(smp);
>> return NULL;
>> }
>>
>
> Yeah, this makes it all clear.
>
>> So the tfm_cmac is part of the smp structure. However if there is
>> no cipher, we destroy the smp structure and essentially run without
>> SMP support. So it can not really be called anyway.
>>
>
> What I take from this is that as a general rule, I should first try
> to identify whether the code I'm debugging is reachable or not,
> depending on the specific structures and variables I'm interested in.
>
>> Maybe commenting this might be a good idea.
>>
>
> Yep, it wouldn't hurt.
>
> In the meantime I will triage and document this as a false positive.
>
> Thank you very much for the clarification, Marcel,
> I really appreciate it.
> --
> Gustavo A. R. Silva
Thanks
--
Gustavo A. R. Silva
^ permalink raw reply
* Re: [net-bluetooth] question about potential null pointer dereference
From: Gustavo A. R. Silva @ 2017-05-31 3:29 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Gustavo F. Padovan, Johan Hedberg, David S. Miller,
open list:BLUETOOTH DRIVERS, netdev, linux-kernel
In-Reply-To: <62DD828F-D88E-4916-BD0B-347E433ACCE6@holtmann.org>
Hi Marcel,
Quoting Marcel Holtmann <marcel@holtmann.org>:
> Hi Gustavo,
>
>> While looking into Coverity ID 1357456 I ran into the following
>> piece of code at net/bluetooth/smp.c:166
>>
>> 166/* The following functions map to the LE SC SMP crypto functions
>> 167 * AES-CMAC, f4, f5, f6, g2 and h6.
>> 168 */
>> 169
>> 170static int aes_cmac(struct crypto_shash *tfm, const u8 k[16],
>> const u8 *m,
>> 171 size_t len, u8 mac[16])
>> 172{
>> 173 uint8_t tmp[16], mac_msb[16], msg_msb[CMAC_MSG_MAX];
>> 174 SHASH_DESC_ON_STACK(desc, tfm);
>> 175 int err;
>> 176
>> 177 if (len > CMAC_MSG_MAX)
>> 178 return -EFBIG;
>> 179
>> 180 if (!tfm) {
>> 181 BT_ERR("tfm %p", tfm);
>> 182 return -EINVAL;
>> 183 }
>> 184
>> 185 desc->tfm = tfm;
>> 186 desc->flags = 0;
>> 187
>> 188 /* Swap key and message from LSB to MSB */
>> 189 swap_buf(k, tmp, 16);
>> 190 swap_buf(m, msg_msb, len);
>> 191
>> 192 SMP_DBG("msg (len %zu) %*phN", len, (int) len, m);
>> 193 SMP_DBG("key %16phN", k);
>> 194
>> 195 err = crypto_shash_setkey(tfm, tmp, 16);
>> 196 if (err) {
>> 197 BT_ERR("cipher setkey failed: %d", err);
>> 198 return err;
>> 199 }
>> 200
>> 201 err = crypto_shash_digest(desc, msg_msb, len, mac_msb);
>> 202 shash_desc_zero(desc);
>> 203 if (err) {
>> 204 BT_ERR("Hash computation error %d", err);
>> 205 return err;
>> 206 }
>> 207
>> 208 swap_buf(mac_msb, mac, 16);
>> 209
>> 210 SMP_DBG("mac %16phN", mac);
>> 211
>> 212 return 0;
>> 213}
>>
>> The issue here is that line 180 implies that pointer tfm might be
>> NULL. If this is the case, there is a potential NULL pointer
>> dereference at line 174 once pointer tfm is indirectly dereferenced
>> inside macro SHASH_DESC_ON_STACK().
>>
>> My question is if there is any chance that pointer tfm maybe be
>> NULL when calling macro SHASH_DESC_ON_STACK()?
>
> I think the part you are after is this:
>
> smp->tfm_cmac = crypto_alloc_shash("cmac(aes)", 0, 0);
> if (IS_ERR(smp->tfm_cmac)) {
> BT_ERR("Unable to create CMAC crypto context");
> crypto_free_cipher(smp->tfm_aes);
> kzfree(smp);
> return NULL;
> }
>
Yeah, this makes it all clear.
> So the tfm_cmac is part of the smp structure. However if there is no
> cipher, we destroy the smp structure and essentially run without SMP
> support. So it can not really be called anyway.
>
What I take from this is that as a general rule, I should first try to
identify whether the code I'm debugging is reachable or not, depending
on the specific structures and variables I'm interested in.
> Maybe commenting this might be a good idea.
>
Yep, it wouldn't hurt.
In the meantime I will triage and document this as a false positive.
Thank you very much for the clarification, Marcel,
I really appreciate it.
--
Gustavo A. R. Silva
^ permalink raw reply
* Re: [PATCH net-next 4/8] bpf: Add BPF_PROG_GET_FD_BY_ID
From: kbuild test robot @ 2017-05-31 3:21 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: kbuild-all, netdev, Alexei Starovoitov, Daniel Borkmann,
kernel-team
In-Reply-To: <f149f2b1d90960adbfac2ea6546d6f7014e49494.1496189155.git.kafai@fb.com>
[-- Attachment #1: Type: text/plain, Size: 2104 bytes --]
Hi Martin,
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Martin-KaFai-Lau/bpf-Introduce-bpf_prog-ID/20170531-110650
config: x86_64-randconfig-x015-201722 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
In file included from arch/x86/include/asm/bug.h:81:0,
from include/linux/bug.h:4,
from include/linux/thread_info.h:11,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:80,
from include/linux/spinlock.h:50,
from include/linux/seqlock.h:35,
from include/linux/time.h:5,
from include/linux/ktime.h:24,
from include/linux/timer.h:5,
from include/linux/workqueue.h:8,
from include/linux/bpf.h:12,
from kernel/bpf/syscall.c:12:
kernel/bpf/syscall.c: In function 'bpf_prog_inc_not_zero':
>> kernel/bpf/syscall.c:834:16: error: implicit declaration of function 'lockdep_is_held' [-Werror=implicit-function-declaration]
WARN_ON_ONCE(!lockdep_is_held(&prog_idr_lock));
^
include/asm-generic/bug.h:65:25: note: in definition of macro 'WARN_ON_ONCE'
int __ret_warn_on = !!(condition); \
^~~~~~~~~
cc1: some warnings being treated as errors
vim +/lockdep_is_held +834 kernel/bpf/syscall.c
828 EXPORT_SYMBOL_GPL(bpf_prog_inc);
829
830 static struct bpf_prog *bpf_prog_inc_not_zero(struct bpf_prog *prog)
831 {
832 int refold;
833
> 834 WARN_ON_ONCE(!lockdep_is_held(&prog_idr_lock));
835 refold = __atomic_add_unless(&prog->aux->refcnt, 1, 0);
836
837 if (refold >= BPF_MAX_REFCNT) {
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 28833 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] bnxt_en: Fix xmit_more with BQL.
From: David Miller @ 2017-05-31 2:38 UTC (permalink / raw)
To: michael.chan; +Cc: netdev
In-Reply-To: <1496188980-13392-1-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Tue, 30 May 2017 20:03:00 -0400
> We need to write the doorbell if BQL has stopped the queue and
> skb->xmit_more is set. Otherwise it is possible for the tx queue to
> rot and cause tx timeout.
>
> Fixes: 4d172f21cefe ("bnxt_en: Implement xmit_more.")
> Suggested-by: Yuval Mintz <yuval.mintz@cavium.com>
> Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Applied, thanks.
^ permalink raw reply
* [PATCH] enic: Fix another sleep-in-atomic bug
From: Jia-Ju Bai @ 2017-05-31 2:43 UTC (permalink / raw)
To: benve, _govind, neepatel; +Cc: netdev, linux-kernel, Jia-Ju Bai
The driver may sleep under a spin lock in some function call paths.
The 1st function call path is:
enic_tx_hang_reset (acquire the lock by spin_lock)
enic_stop
enic_synchronize_irqs
synchronize_irq --> may sleep
The 2nd function call path is:
enic_tx_hang_reset (acquire the lock by spin_lock)
enic_dev_wait
schedule_timeout_uninterruptible --> may sleep
The 3rd function call path is:
enic_tx_hang_reset (acquire the lock by spin_lock)
enic_open
enic_request_intr
enic_set_rx_cpu_rmap
enic_free_rx_cpu_rmap
free_irq_cpu_rmap --> may sleep
To fix it, the "spin_lock" and "spin_unlock" are removed
in enic_tx_hang_reset.
Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
---
drivers/net/ethernet/cisco/enic/enic_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c b/drivers/net/ethernet/cisco/enic/enic_main.c
index 4b87bee..d6523e2 100644
--- a/drivers/net/ethernet/cisco/enic/enic_main.c
+++ b/drivers/net/ethernet/cisco/enic/enic_main.c
@@ -2330,7 +2330,6 @@ static void enic_tx_hang_reset(struct work_struct *work)
rtnl_lock();
- spin_lock(&enic->enic_api_lock);
enic_dev_hang_notify(enic);
enic_stop(enic->netdev);
enic_dev_hang_reset(enic);
@@ -2339,7 +2338,6 @@ static void enic_tx_hang_reset(struct work_struct *work)
enic_set_rss_nic_cfg(enic);
enic_dev_set_ig_vlan_rewrite_mode(enic);
enic_open(enic->netdev);
- spin_unlock(&enic->enic_api_lock);
call_netdevice_notifiers(NETDEV_REBOOT, enic->netdev);
rtnl_unlock();
--
1.7.9.5
^ permalink raw reply related
* [PATCH] enic: Fix a sleep-in-atomic bug
From: Jia-Ju Bai @ 2017-05-31 2:34 UTC (permalink / raw)
To: benve, _govind, neepatel; +Cc: netdev, linux-kernel, Jia-Ju Bai
The driver may sleep under a spin lock in some function call paths.
The 1st function call path is:
enic_reset (acquire the lock by spin_lock)
enic_stop
enic_synchronize_irqs
synchronize_irq --> may sleep
The 2nd function call path is:
enic_reset (acquire the lock by spin_lock)
enic_dev_soft_reset
enic_dev_wait
schedule_timeout_uninterruptible --> may sleep
The 3rd function call path is:
enic_reset (acquire the lock by spin_lock)
enic_open
enic_request_intr
enic_set_rx_cpu_rmap
enic_free_rx_cpu_rmap
free_irq_cpu_rmap --> may sleep
To fix it, the "spin_lock" and "spin_unlock" are removed in enic_reset.
Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
---
drivers/net/ethernet/cisco/enic/enic_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c b/drivers/net/ethernet/cisco/enic/enic_main.c
index 4b87bee..2a9bef8 100644
--- a/drivers/net/ethernet/cisco/enic/enic_main.c
+++ b/drivers/net/ethernet/cisco/enic/enic_main.c
@@ -2310,7 +2310,6 @@ static void enic_reset(struct work_struct *work)
rtnl_lock();
- spin_lock(&enic->enic_api_lock);
enic_stop(enic->netdev);
enic_dev_soft_reset(enic);
enic_reset_addr_lists(enic);
@@ -2318,7 +2317,6 @@ static void enic_reset(struct work_struct *work)
enic_set_rss_nic_cfg(enic);
enic_dev_set_ig_vlan_rewrite_mode(enic);
enic_open(enic->netdev);
- spin_unlock(&enic->enic_api_lock);
call_netdevice_notifiers(NETDEV_REBOOT, enic->netdev);
rtnl_unlock();
--
1.7.9.5
^ permalink raw reply related
* [PATCH] i40e: Fix a sleep-in-atomic bug
From: Jia-Ju Bai @ 2017-05-31 2:12 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: intel-wired-lan, netdev, linux-kernel, Jia-Ju Bai
The driver may sleep under a spin lock, and the function call path is:
i40e_ndo_set_vf_port_vlan (acquire the lock by spin_lock_bh)
i40e_vsi_remove_pvid
i40e_vlan_stripping_disable
i40e_aq_update_vsi_params
i40e_asq_send_command
mutex_lock --> may sleep
To fixed it, the spin lock is released before "i40e_vsi_remove_pvid", and
the lock is acquired again after this function.
Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
---
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index 95c23fb..0fb38ca 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -3017,10 +3017,12 @@ int i40e_ndo_set_vf_port_vlan(struct net_device *netdev, int vf_id,
VLAN_VID_MASK));
}
+ spin_unlock_bh(&vsi->mac_filter_hash_lock);
if (vlan_id || qos)
ret = i40e_vsi_add_pvid(vsi, vlanprio);
else
i40e_vsi_remove_pvid(vsi);
+ spin_lock_bh(&vsi->mac_filter_hash_lock);
if (vlan_id) {
dev_info(&pf->pdev->dev, "Setting VLAN %d, QOS 0x%x on VF %d\n",
--
1.7.9.5
^ permalink raw reply related
* Re: Deleting a dynamic mac entry..
From: Manohar Kumar @ 2017-05-31 1:50 UTC (permalink / raw)
To: Toshiaki Makita; +Cc: netdev, bridge
In-Reply-To: <45967005-7501-6c96-eb95-f83c5f631277@lab.ntt.co.jp>
Please see inline..
On Fri, May 26, 2017 at 1:15 AM, Toshiaki Makita
<makita.toshiaki@lab.ntt.co.jp> wrote:
> On 2017/05/26 14:08, Manohar Kumar wrote:
>> On Wed, May 24, 2017 at 6:11 PM, Toshiaki Makita
>> <makita.toshiaki@lab.ntt.co.jp> wrote:
>>> On 2017/05/25 3:05, Manohar Kumar wrote:
>>>> Thanks, Toshiaki.
>>>>
>>>> What is the right way to set the default_pvid using the bridge command
>>>> ? I tried this, which fails..
>>>>
>>>> root@net-3:~# ip link set dev vxlan0 name untagged type vlan id 0
>>>> RTNETLINK answers: Operation not supported
>>>> root@net-3:~#
>>>>
>>>> All the interfaces in the bridge are untagged.
>>>
>>> # ip link set br0 down
>>> # echo 0 > /sys/class/net/br0/bridge/default_pvid
>>>
>>
>> I have the bridge inside a network namespace. There is no
>> /sys/class/net entry for the bridge interface inside the namespace.
>>
>> I see online references to this concept of 'tagged' sysfs directories
>> to support namespaces. But its not clear how to access the sysfs
>> entries for a particular namespace.
>
> Did you remount /sys after entering netns?
No, that was the problem. Mounting /sys did the trick. Appreciate your help.
Trying to understanding this better. How is the sysfs tree maintained
per network namespace ? I assume only the /sys/class/net is per
network namespace and the rest of the /sys is shared with the host
namespace ? Also, how does mounting /sys in the network namespace make
the new /sys/class/net tree visible ?
thanks,
Manohar.
> If not, remount /sys or use "ip netns" which automatically do it.
>
>> Is there any other way to set the default_pvid for the bridge
>> interface inside namespace ?
>
> No, as of 3.19.
>
>
> Toshiaki Makita
>
^ permalink raw reply
* [PATCH] isdn: Fix a sleep-in-atomic bug
From: Jia-Ju Bai @ 2017-05-31 1:40 UTC (permalink / raw)
To: isdn, davem, geliangtang, keescook; +Cc: netdev, linux-kernel, Jia-Ju Bai
The driver may sleep under a spin lock, the function call path is:
isdn_ppp_mp_receive (acquire the lock)
isdn_ppp_mp_reassembly
isdn_ppp_push_higher
isdn_ppp_decompress
isdn_ppp_ccp_reset_trans
isdn_ppp_ccp_reset_alloc_state
kzalloc(GFP_KERNEL) --> may sleep
To fixed it, the "GFP_KERNEL" is replaced with "GFP_ATOMIC".
Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
---
drivers/isdn/i4l/isdn_ppp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/isdn/i4l/isdn_ppp.c b/drivers/isdn/i4l/isdn_ppp.c
index d07dd519..8aa158a 100644
--- a/drivers/isdn/i4l/isdn_ppp.c
+++ b/drivers/isdn/i4l/isdn_ppp.c
@@ -2364,7 +2364,7 @@ static struct ippp_ccp_reset_state *isdn_ppp_ccp_reset_alloc_state(struct ippp_s
id);
return NULL;
} else {
- rs = kzalloc(sizeof(struct ippp_ccp_reset_state), GFP_KERNEL);
+ rs = kzalloc(sizeof(struct ippp_ccp_reset_state), GFP_ATOMIC);
if (!rs)
return NULL;
rs->state = CCPResetIdle;
--
1.7.9.5
^ permalink raw reply related
* Re: [i40e] regression on TCP stream and TCP maerts, kernel-4.12.0-0.rc2
From: Alexander Duyck @ 2017-05-31 1:27 UTC (permalink / raw)
To: Adam Okuliar, Mitch Williams, intel-wired-lan
Cc: Netdev, Adrian Tomasov, Jeff Kirsher, Otto Sabart, Jirka Hladky
In-Reply-To: <CAKgT0UcdJQWqr_zxxi36a6_3iMwBNow-YS723i7t6xsKvAqvCA@mail.gmail.com>
On Tue, May 30, 2017 at 8:41 AM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> On Tue, May 30, 2017 at 6:43 AM, Adam Okuliar <aokuliar@redhat.com> wrote:
>> Hello,
>>
>> we found regression on intel card(XL710) with i40e driver. Regression is
>> about ~45%
>> on TCP_STREAM and TCP_MAERTS test for IPv4 and IPv6. Regression was first
>> visible in kernel-4.12.0-0.rc1.
>>
>> More details about results you can see in uploaded images in bugzilla. [0]
>>
>>
>> [0] https://bugzilla.kernel.org/show_bug.cgi?id=195923
>>
>>
>> Best regards, / S pozdravom,
>>
>> Adrián Tomašov
>> Kernel Performance QE
>> atomasov@redhat.com
>
> I have added the i40e driver maintainer and the intel-wired-lan
> mailing list so that we can make are developers aware of the issue.
>
> Thanks.
>
> - Alex
Adam,
We are having some issues trying to reproduce what you reported.
Can you provide some additional data. Specifically we would be looking
for an "ethtool -i", and an "ethtool -S" for the port before and after
the test. If you can attach it to the bugzilla that would be
appreciated.
Thanks.
- Alex
^ permalink raw reply
* RE: [PATCH net-next] net: ndisc.c: reduce size of __ndisc_fill_addr_option()
From: YUAN Linyu @ 2017-05-31 1:00 UTC (permalink / raw)
To: David Ahern, Joe Perches, David Miller, cugyly@163.com
Cc: netdev@vger.kernel.org
In-Reply-To: <fe3573ad-90d1-6673-1e09-f6f1b47527bb@gmail.com>
Ok, I will send v2 later
> -----Original Message-----
> From: David Ahern [mailto:dsahern@gmail.com]
> Sent: Wednesday, May 31, 2017 8:40 AM
> To: YUAN Linyu; David Ahern; Joe Perches; David Miller; cugyly@163.com
> Cc: netdev@vger.kernel.org
> Subject: Re: [PATCH net-next] net: ndisc.c: reduce size of
> __ndisc_fill_addr_option()
>
> On 5/30/17 6:29 PM, YUAN Linyu wrote:
> >>> that function should be converted to skb_put_zero once it hits net-next.
> >> I will check it
> > I can't find skb_put_zero
>
> I believe the decision was to put it in Johannes' tree and it will make
> its way to DaveM's tree. Give some time.
^ permalink raw reply
* Re: [PATCH iproute2 0/4] ip: Add vrf show commmand
From: Stephen Hemminger @ 2017-05-31 0:56 UTC (permalink / raw)
To: David Ahern; +Cc: netdev
In-Reply-To: <20170527233450.58015-1-dsahern@gmail.com>
On Sat, 27 May 2017 17:34:46 -0600
David Ahern <dsahern@gmail.com> wrote:
> Refactor ip address to export its capability to save a list of nlmsg's
> for links and its link filter. Use both to add an 'ip vrf show' command
> to list all configured VRF with table id.
>
> David Ahern (4):
> ip address: Export ip_linkaddr_list
> ip address: Move filter struct to ip_common.h
> ip address: Change print_linkinfo_brief to take filter as an input
> ip vrf: Add show command
>
> include/libnetlink.h | 10 ++++
> ip/ip_common.h | 27 ++++++++-
> ip/ipaddress.c | 144 +++++++++++++++++++++++-------------------------
> ip/iplink.c | 2 +-
> ip/ipvrf.c | 153 +++++++++++++++++++++++++++++++++++++++++++++++++--
> man/man8/ip-vrf.8 | 11 ++++
> 6 files changed, 266 insertions(+), 81 deletions(-)
>
Looks good, series applied to master.
^ permalink raw reply
* Re: [PATCH V2 2/3] net-next: dsa: add multi cpu port support
From: Andrew Lunn @ 2017-05-31 0:52 UTC (permalink / raw)
To: Florian Fainelli
Cc: John Crispin, Vivien Didelot, David S . Miller, Sean Wang, jiri,
idosch, netdev, linux-kernel
In-Reply-To: <881bf3fe-1ffb-b9fd-c844-da265f71370d@gmail.com>
On Tue, May 30, 2017 at 05:16:27PM -0700, Florian Fainelli wrote:
> On 05/30/2017 05:06 PM, Andrew Lunn wrote:
> >> - past the initial setup, if we start creating bridge devices and so on,
> >> we have no way to tell: group Ports 0-3 together and send traffic to CPU
> >> port 0, then let Port 5 alone and send traffic to CPU port 1, that's a
> >> DSA-only problem though, because we still have the CPU port(s) as
> >> independent network interfaces.
> >
> > What is the problem here? Frames come out the master interface, get
> > untagged and passed to the slave interface and go upto the bridge. It
> > should all just work. Same in the reverse direction.
>
> The problem is really that is you have multiple CPU ports, how do you
> define which one gets all the traffic by default? Ascending order of
> port number? Descending order?
I would probably default to round robin when allocating user ports to
CPU ports. That probably gives you the best default.
> I actually tend to think that most use cases our there are in the order
> of dedicating one CPU port to one corresponding switch port (user
> facing, or internal) in order to provided guaranteed bandwidth for that
> port.
Which is generally a waste of bandwidth. Best case, i get 40Mbps
Internet access. Meaning 960Mbps of a dedicated cpu port would be
wasted.
> But as an user, I want to choose how the grouping is going to
> work, and right now, I cannot, unless this is hardcoded in Device Tree,
> which sounds both wrong and inadequate.
So how about round-robin default, and then devlink to move a user port
to a specific cpu port?
We also need to watch out for asymmetry. I think newer marvell chips
don't support egress to multiple CPU ports. Ingress to the switch i
think is unlimited. The older chips are more flexible in this
respect. So we need some degree of flexibility here.
Andrew
^ permalink raw reply
* Re: [net-bluetooth] question about potential null pointer dereference
From: Marcel Holtmann @ 2017-05-31 0:52 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Gustavo F. Padovan, Johan Hedberg, David S. Miller,
open list:BLUETOOTH DRIVERS, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170530112328.Horde.PY1jf3InPf-6SU3kH9l7mtw-fU+oOHjIBR1LoJgMfuPDHBfZZeVsHd8q@public.gmane.org>
Hi Gustavo,
> While looking into Coverity ID 1357456 I ran into the following piece of code at net/bluetooth/smp.c:166
>
> 166/* The following functions map to the LE SC SMP crypto functions
> 167 * AES-CMAC, f4, f5, f6, g2 and h6.
> 168 */
> 169
> 170static int aes_cmac(struct crypto_shash *tfm, const u8 k[16], const u8 *m,
> 171 size_t len, u8 mac[16])
> 172{
> 173 uint8_t tmp[16], mac_msb[16], msg_msb[CMAC_MSG_MAX];
> 174 SHASH_DESC_ON_STACK(desc, tfm);
> 175 int err;
> 176
> 177 if (len > CMAC_MSG_MAX)
> 178 return -EFBIG;
> 179
> 180 if (!tfm) {
> 181 BT_ERR("tfm %p", tfm);
> 182 return -EINVAL;
> 183 }
> 184
> 185 desc->tfm = tfm;
> 186 desc->flags = 0;
> 187
> 188 /* Swap key and message from LSB to MSB */
> 189 swap_buf(k, tmp, 16);
> 190 swap_buf(m, msg_msb, len);
> 191
> 192 SMP_DBG("msg (len %zu) %*phN", len, (int) len, m);
> 193 SMP_DBG("key %16phN", k);
> 194
> 195 err = crypto_shash_setkey(tfm, tmp, 16);
> 196 if (err) {
> 197 BT_ERR("cipher setkey failed: %d", err);
> 198 return err;
> 199 }
> 200
> 201 err = crypto_shash_digest(desc, msg_msb, len, mac_msb);
> 202 shash_desc_zero(desc);
> 203 if (err) {
> 204 BT_ERR("Hash computation error %d", err);
> 205 return err;
> 206 }
> 207
> 208 swap_buf(mac_msb, mac, 16);
> 209
> 210 SMP_DBG("mac %16phN", mac);
> 211
> 212 return 0;
> 213}
>
> The issue here is that line 180 implies that pointer tfm might be NULL. If this is the case, there is a potential NULL pointer dereference at line 174 once pointer tfm is indirectly dereferenced inside macro SHASH_DESC_ON_STACK().
>
> My question is if there is any chance that pointer tfm maybe be NULL when calling macro SHASH_DESC_ON_STACK()?
I think the part you are after is this:
smp->tfm_cmac = crypto_alloc_shash("cmac(aes)", 0, 0);
if (IS_ERR(smp->tfm_cmac)) {
BT_ERR("Unable to create CMAC crypto context");
crypto_free_cipher(smp->tfm_aes);
kzfree(smp);
return NULL;
}
So the tfm_cmac is part of the smp structure. However if there is no cipher, we destroy the smp structure and essentially run without SMP support. So it can not really be called anyway.
Maybe commenting this might be a good idea.
Regards
Marcel
^ 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