* [net-next PATCH V2 5/5] samples/bpf: like LLC also verify and allow redefining CLANG command
From: Jesper Dangaard Brouer @ 2016-04-26 16:27 UTC (permalink / raw)
To: netdev
Cc: linux-kbuild, bblanco, Jesper Dangaard Brouer, naveen.n.rao,
borkmann, alexei.starovoitov
In-Reply-To: <20160426162650.22962.20516.stgit@firesoul>
Users are likely to manually compile both LLVM 'llc' and 'clang'
tools. Thus, also allow redefining CLANG and verify command exist.
Makefile implementation wise, the target that verify the command have
been generalized.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
samples/bpf/Makefile | 23 +++++++++++++----------
samples/bpf/README.rst | 6 +++---
2 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index dd63521832d8..c02ea9d2a248 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -81,9 +81,10 @@ HOSTLOADLIBES_spintest += -lelf
HOSTLOADLIBES_map_perf_test += -lelf -lrt
HOSTLOADLIBES_test_overhead += -lelf -lrt
-# Allows pointing LLC to a LLVM backend with bpf support, redefine on cmdline:
-# make samples/bpf/ LLC=~/git/llvm/build/bin/llc
+# Allows pointing LLC/CLANG to a LLVM backend with bpf support, redefine on cmdline:
+# make samples/bpf/ LLC=~/git/llvm/build/bin/llc CLANG=~/git/llvm/build/bin/clang
LLC ?= llc
+CLANG ?= clang
# Trick to allow make to be run from this directory
all:
@@ -94,15 +95,17 @@ clean:
@rm -f *~
# Verify LLVM compiler is available and bpf target is supported
-.PHONY: verify_cmd_llc verify_target_bpf
+.PHONY: verify_cmd_llc verify_target_bpf $(CLANG) $(LLC)
-verify_cmd_llc:
- @if ! (which "${LLC}" > /dev/null 2>&1); then \
- echo "*** ERROR: Cannot find LLVM tool 'llc' (${LLC})" ;\
- exit 1; \
- else true; fi
+verify_cmds: $(CLANG) $(LLC)
+ @for TOOL in $^ ; do \
+ if ! (which "$${TOOL}" > /dev/null 2>&1); then \
+ echo "*** ERROR: Cannot find LLVM tool $${TOOL}" ;\
+ exit 1; \
+ else true; fi; \
+ done
-verify_target_bpf: verify_cmd_llc
+verify_target_bpf: verify_cmds
@if ! (${LLC} -march=bpf -mattr=help > /dev/null 2>&1); then \
echo "*** ERROR: LLVM (${LLC}) does not support 'bpf' target" ;\
echo " NOTICE: LLVM version >= 3.7.1 required" ;\
@@ -115,6 +118,6 @@ $(src)/*.c: verify_target_bpf
# But, there is no easy way to fix it, so just exclude it since it is
# useless for BPF samples.
$(obj)/%.o: $(src)/%.c
- clang $(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS) \
+ $(CLANG) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS) \
-D__KERNEL__ -D__ASM_SYSREG_H -Wno-unused-value -Wno-pointer-sign \
-O2 -emit-llvm -c $< -o -| $(LLC) -march=bpf -filetype=obj -o $@
diff --git a/samples/bpf/README.rst b/samples/bpf/README.rst
index 1ec4b08a7b40..74897dbe6458 100644
--- a/samples/bpf/README.rst
+++ b/samples/bpf/README.rst
@@ -73,8 +73,8 @@ Quick sniplet for manually compiling LLVM and clang
$ cmake .. -DLLVM_TARGETS_TO_BUILD="BPF;X86"
$ make -j $(getconf _NPROCESSORS_ONLN)
-It is also possible to point make to the newly compile 'llc' command
-via redefining LLC on the make command line::
+It is also possible to point make to the newly compile 'llc' or
+'clang' command via redefining LLC or CLANG on the make command line::
- make samples/bpf/ LLC=~/git/llvm/build/bin/llc
+ make samples/bpf/ LLC=~/git/llvm/build/bin/llc CLANG=~/git/llvm/build/bin/clang
^ permalink raw reply related
* Re: pull request: bluetooth-next 2016-04-26
From: David Miller @ 2016-04-26 17:17 UTC (permalink / raw)
To: johan.hedberg-Re5JQEeQqe8AvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20160426095435.GA8699@t440s>
From: Johan Hedberg <johan.hedberg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Tue, 26 Apr 2016 12:54:35 +0300
> Here's another set of Bluetooth & 802.15.4 patches for the 4.7 kernel:
>
> - Cleanups & refactoring of ieee802154 & 6lowpan code
> - Security related additions to ieee802154 and mrf24j40 driver
> - Memory corruption fix to Bluetooth 6lowpan code
> - Race condition fix in vhci driver
> - Enhancements to the atusb 802.15.4 driver
>
> Please let me know if there are any issues pulling. Thanks.
Pulled, thanks Johan.
^ permalink raw reply
* Re: [PATCH] ARM: dts: at91: VInCo: fix phy reset gpio flag
From: David Miller @ 2016-04-26 17:17 UTC (permalink / raw)
To: nicolas.ferre
Cc: sergei.shtylyov, linux-kernel, linux-arm-kernel, gregory.clement,
alexandre.belloni, netdev, andrew
In-Reply-To: <1461666272-10107-1-git-send-email-nicolas.ferre@atmel.com>
From: Nicolas Ferre <nicolas.ferre@atmel.com>
Date: Tue, 26 Apr 2016 12:24:32 +0200
> I plan to queue this patch through arm-soc for 4.7.
Ok.
^ permalink raw reply
* Re: [PATCH net-next 0/8] cxgb4: minor fixes, decode msgs and code refactor for few functions
From: David Miller @ 2016-04-26 17:24 UTC (permalink / raw)
To: hariprasad; +Cc: netdev, leedom, swise, nirranjan, santosh
In-Reply-To: <1461681629-28275-1-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Tue, 26 Apr 2016 20:10:21 +0530
> This patch series adds new routine to get adapter information and removes
> some redundant messages logged in dmesg. Fixes race while freeing tx
> descriptors. Decodes module type and link down reason codes obtained from
> firmware. Refactor port initialization and FW_PORT_CMD handling. Pass
> correct port id in DCB message handler to obtain netdev associated.
>
> This patch series has been created against net-next tree and includes
> patches on cxgb4 driver.
>
> We have included all the maintainers of respective drivers. Kindly review
> the change and let us know in case of any review comments.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/6] bus: Add shared MDIO bus framework
From: Florian Fainelli @ 2016-04-26 17:23 UTC (permalink / raw)
To: Andrew Lunn, Pramod Kumar
Cc: Rob Herring, Catalin Marinas, Will Deacon, Masahiro Yamada,
Chen-Yu Tsai, Mark Rutland, devicetree, Pawel Moll, Arnd Bergmann,
Suzuki K Poulose, netdev, Punit Agrawal, linux-kernel,
BCM Kernel Feedback, linux-arm-kernel, Anup Patel
In-Reply-To: <20160426121335.GC11668@lunn.ch>
On 26/04/16 05:13, Andrew Lunn wrote:
>> 4. Apart from these, by using MDIO mux framework we are making our
>> non-ethernet PHYs dependent on Linux network drivers which is not
>> acceptable. What if some product line does not need network subsystem at
>> all?
>
> This is your only valid point. However, does Broadcom have a product
> line which does not include networking? Is not Broadcom a network SoC
> vendor?
But even with that, there is no reason why we could not decouple the
PHYLIB MDIO framework from PHYLIB and make it available as a more
standalone subsystem which can be utilized when you have a mix of MDIO
devices like here.
I am not clear on how common a shared MDIO bus is on other SoCs, but the
other Broadcom SoCs I am familiar with have dedicated MDIO buses
instances per type of PHY (PCIe, BUSB, Ethernet), thus making the split
a ton easier.
--
Florian
^ permalink raw reply
* Re: [net-next PATCH V2 1/5] samples/bpf: add back functionality to redefine LLC command
From: Alexei Starovoitov @ 2016-04-26 17:28 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: netdev, linux-kbuild, bblanco, naveen.n.rao, borkmann
In-Reply-To: <20160426162711.22962.13821.stgit@firesoul>
On Tue, Apr 26, 2016 at 06:27:11PM +0200, Jesper Dangaard Brouer wrote:
> It is practical to be-able-to redefine the location of the LLVM
> command 'llc', because not all distros have a LLVM version with bpf
> target support. Thus, it is sometimes required to compile LLVM from
> source, and sometimes it is not desired to overwrite the distros
> default LLVM version.
>
> This feature was removed with 128d1514be35 ("samples/bpf: Use llc in
> PATH, rather than a hardcoded value").
>
> Add this features back. Note that it is possible to redefine the LLC
> on the make command like:
>
> make samples/bpf/ LLC=~/git/llvm/build/bin/llc
>
> Fixes: 128d1514be35 ("samples/bpf: Use llc in PATH, rather than a hardcoded value")
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* Re: [net-next PATCH V2 2/5] samples/bpf: Makefile verify LLVM compiler avail and bpf target is supported
From: Alexei Starovoitov @ 2016-04-26 17:28 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: netdev, linux-kbuild, bblanco, naveen.n.rao, borkmann
In-Reply-To: <20160426162716.22962.36473.stgit@firesoul>
On Tue, Apr 26, 2016 at 06:27:16PM +0200, Jesper Dangaard Brouer wrote:
> Make compiling samples/bpf more user friendly, by detecting if LLVM
> compiler tool 'llc' is available, and also detect if the 'bpf' target
> is available in this version of LLVM.
>
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* Re: [net-next PATCH V2 3/5] samples/bpf: add a README file to get users started
From: Alexei Starovoitov @ 2016-04-26 17:31 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: netdev, linux-kbuild, bblanco, naveen.n.rao, borkmann
In-Reply-To: <20160426162721.22962.25054.stgit@firesoul>
On Tue, Apr 26, 2016 at 06:27:22PM +0200, Jesper Dangaard Brouer wrote:
> +
> +Manually compiling LLVM with 'bpf' support
> +------------------------------------------
> +
> +In some LLVM versions the BPF target were marked experimental. They
> +needed the 'cmake .. -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=BPF'. Since
> +version 3.7.1, LLVM adds a proper LLVM backend target for the BPF
> +bytecode architecture.
it's actually non-experimental since 3.7.0.
It was experimental after 3.6 was released during development of 3.7.
I doubt you can find this anywhere, so I suggest to just drop this paragraph.
^ permalink raw reply
* Re: [net-next PATCH V2 4/5] samples/bpf: allow make to be run from samples/bpf/ directory
From: Alexei Starovoitov @ 2016-04-26 17:31 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: netdev, linux-kbuild, bblanco, naveen.n.rao, borkmann
In-Reply-To: <20160426162727.22962.51631.stgit@firesoul>
On Tue, Apr 26, 2016 at 06:27:27PM +0200, Jesper Dangaard Brouer wrote:
> It is not intuitive that 'make' must be run from the top level
> directory with argument "samples/bpf/" to compile these eBPF samples.
>
> Introduce a kbuild make file trick that allow make to be run from the
> "samples/bpf/" directory itself. It basically change to the top level
> directory and call "make samples/bpf/" with the "/" slash after the
> directory name.
>
> Also add a clean target that only cleans this directory, by taking
> advantage of the kbuild external module setting M=$PWD.
>
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* Re: [net-next PATCH V2 5/5] samples/bpf: like LLC also verify and allow redefining CLANG command
From: Alexei Starovoitov @ 2016-04-26 17:36 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: netdev, linux-kbuild, bblanco, naveen.n.rao, borkmann
In-Reply-To: <20160426162732.22962.73140.stgit@firesoul>
On Tue, Apr 26, 2016 at 06:27:32PM +0200, Jesper Dangaard Brouer wrote:
> Users are likely to manually compile both LLVM 'llc' and 'clang'
> tools. Thus, also allow redefining CLANG and verify command exist.
>
> Makefile implementation wise, the target that verify the command have
> been generalized.
>
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> ---
> samples/bpf/Makefile | 23 +++++++++++++----------
> samples/bpf/README.rst | 6 +++---
> 2 files changed, 16 insertions(+), 13 deletions(-)
>
> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
> index dd63521832d8..c02ea9d2a248 100644
> --- a/samples/bpf/Makefile
> +++ b/samples/bpf/Makefile
> @@ -81,9 +81,10 @@ HOSTLOADLIBES_spintest += -lelf
> HOSTLOADLIBES_map_perf_test += -lelf -lrt
> HOSTLOADLIBES_test_overhead += -lelf -lrt
>
> -# Allows pointing LLC to a LLVM backend with bpf support, redefine on cmdline:
> -# make samples/bpf/ LLC=~/git/llvm/build/bin/llc
> +# Allows pointing LLC/CLANG to a LLVM backend with bpf support, redefine on cmdline:
> +# make samples/bpf/ LLC=~/git/llvm/build/bin/llc CLANG=~/git/llvm/build/bin/clang
> LLC ?= llc
> +CLANG ?= clang
>
> # Trick to allow make to be run from this directory
> all:
> @@ -94,15 +95,17 @@ clean:
> @rm -f *~
>
> # Verify LLVM compiler is available and bpf target is supported
> -.PHONY: verify_cmd_llc verify_target_bpf
> +.PHONY: verify_cmd_llc verify_target_bpf $(CLANG) $(LLC)
>
> -verify_cmd_llc:
> - @if ! (which "${LLC}" > /dev/null 2>&1); then \
> - echo "*** ERROR: Cannot find LLVM tool 'llc' (${LLC})" ;\
> - exit 1; \
> - else true; fi
> +verify_cmds: $(CLANG) $(LLC)
> + @for TOOL in $^ ; do \
> + if ! (which "$${TOOL}" > /dev/null 2>&1); then \
> + echo "*** ERROR: Cannot find LLVM tool $${TOOL}" ;\
> + exit 1; \
> + else true; fi; \
> + done
>
> -verify_target_bpf: verify_cmd_llc
> +verify_target_bpf: verify_cmds
> @if ! (${LLC} -march=bpf -mattr=help > /dev/null 2>&1); then \
> echo "*** ERROR: LLVM (${LLC}) does not support 'bpf' target" ;\
> echo " NOTICE: LLVM version >= 3.7.1 required" ;\
If I read the patch correctly, it only checks that any version
of clang is available and llc supports -march=bpf.
That's correct.
There is no need to build the latest clang most of the time.
clang 3.4 and 3.5 are fine to compile samples/bpf/
since llvm ir is mostly compatible with llc from 3.7 or 3.8
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* [PATCH] netem: Segment GSO packets on enqueue.
From: Neil Horman @ 2016-04-26 17:43 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, Jamal Hadi Salim, David S. Miller, netem
This was recently reported to me, and reproduced on the latest net kernel, when
attempting to run netperf from a host that had a netem qdisc attached to the
egress interface:
[ 788.073771] ------------[ cut here ]------------
[ 788.096716] WARNING: at net/core/dev.c:2253 skb_warn_bad_offload+0xcd/0xda()
[ 788.129521] bnx2: caps=(0x00000001801949b3, 0x0000000000000000) len=2962
data_len=0 gso_size=1448 gso_type=1 ip_summed=3
[ 788.182150] Modules linked in: sch_netem kvm_amd kvm crc32_pclmul ipmi_ssif
ghash_clmulni_intel sp5100_tco amd64_edac_mod aesni_intel lrw gf128mul
glue_helper ablk_helper edac_mce_amd cryptd pcspkr sg edac_core hpilo ipmi_si
i2c_piix4 k10temp fam15h_power hpwdt ipmi_msghandler shpchp acpi_power_meter
pcc_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c
sd_mod crc_t10dif crct10dif_generic mgag200 syscopyarea sysfillrect sysimgblt
i2c_algo_bit drm_kms_helper ahci ata_generic pata_acpi ttm libahci
crct10dif_pclmul pata_atiixp tg3 libata crct10dif_common drm crc32c_intel ptp
serio_raw bnx2 r8169 hpsa pps_core i2c_core mii dm_mirror dm_region_hash dm_log
dm_mod
[ 788.465294] CPU: 16 PID: 0 Comm: swapper/16 Tainted: G W
------------ 3.10.0-327.el7.x86_64 #1
[ 788.511521] Hardware name: HP ProLiant DL385p Gen8, BIOS A28 12/17/2012
[ 788.542260] ffff880437c036b8 f7afc56532a53db9 ffff880437c03670
ffffffff816351f1
[ 788.576332] ffff880437c036a8 ffffffff8107b200 ffff880633e74200
ffff880231674000
[ 788.611943] 0000000000000001 0000000000000003 0000000000000000
ffff880437c03710
[ 788.647241] Call Trace:
[ 788.658817] <IRQ> [<ffffffff816351f1>] dump_stack+0x19/0x1b
[ 788.686193] [<ffffffff8107b200>] warn_slowpath_common+0x70/0xb0
[ 788.713803] [<ffffffff8107b29c>] warn_slowpath_fmt+0x5c/0x80
[ 788.741314] [<ffffffff812f92f3>] ? ___ratelimit+0x93/0x100
[ 788.767018] [<ffffffff81637f49>] skb_warn_bad_offload+0xcd/0xda
[ 788.796117] [<ffffffff8152950c>] skb_checksum_help+0x17c/0x190
[ 788.823392] [<ffffffffa01463a1>] netem_enqueue+0x741/0x7c0 [sch_netem]
[ 788.854487] [<ffffffff8152cb58>] dev_queue_xmit+0x2a8/0x570
[ 788.880870] [<ffffffff8156ae1d>] ip_finish_output+0x53d/0x7d0
...
The problem occurs because netem is not prepared to handle GSO packets (as it
uses skb_checksum_help in its enqueue path, which cannot manipulate these
frames).
The solution I think is to simply segment the skb in a simmilar fashion to the
way we do in __dev_queue_xmit (via validate_xmit_skb), except here we always
segment, instead of only when the interface needs us to do it. This allows
netem to properly drop/mangle/pass/etc the correct percentages of frames as per
its qdisc configuration, and avoid failing its checksum operations
tested successfully by myself on the latest net kernel, to whcih this applies
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Jamal Hadi Salim <jhs@mojatatu.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: netem@lists.linux-foundation.org
---
net/sched/sch_netem.c | 34 +++++++++++++++++++++++++++++++++-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/net/sched/sch_netem.c b/net/sched/sch_netem.c
index 9640bb3..c9feecb 100644
--- a/net/sched/sch_netem.c
+++ b/net/sched/sch_netem.c
@@ -401,7 +401,7 @@ static void tfifo_enqueue(struct sk_buff *nskb, struct Qdisc *sch)
* NET_XMIT_DROP: queue length didn't change.
* NET_XMIT_SUCCESS: one skb was queued.
*/
-static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch)
+static int __netem_enqueue(struct sk_buff *skb, struct Qdisc *sch)
{
struct netem_sched_data *q = qdisc_priv(sch);
/* We don't fill cb now as skb_unshare() may invalidate it */
@@ -519,6 +519,38 @@ static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch)
return NET_XMIT_SUCCESS;
}
+static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch)
+{
+ struct sk_buff *segs;
+ struct sk_buff *next;
+ int rc = NET_XMIT_SUCCESS;
+
+ if (skb_is_gso(skb)) {
+ segs = skb_gso_segment(skb, 0);
+ kfree_skb(skb);
+ if (IS_ERR(segs)) {
+ qdisc_qstats_drop(sch);
+ return NET_XMIT_SUCCESS | __NET_XMIT_BYPASS;
+ }
+ skb = segs;
+ }
+
+ while (skb) {
+ next = skb->next;
+ skb->next = NULL;
+ if (rc == NET_XMIT_SUCCESS)
+ rc = __netem_enqueue(skb, sch);
+ else {
+ qdisc_qstats_drop(sch);
+ kfree_skb(skb);
+ }
+
+ skb = next;
+ }
+
+ return rc;
+}
+
static unsigned int netem_drop(struct Qdisc *sch)
{
struct netem_sched_data *q = qdisc_priv(sch);
--
2.5.5
^ permalink raw reply related
* [PATCH] net: phy: at803x: only the AT8030 needs a hardware reset on link change
From: Timur Tabi @ 2016-04-26 17:44 UTC (permalink / raw)
To: netdev, Florian Fainelli, davem, marek.belisko, ujhelyi.m, zonque
Commit 13a56b44 ("at803x: Add support for hardware reset") added a
work-around for a hardware bug on the AT8030. However, the work-around
was being called for all 803x PHYs, even those that don't need it.
Function at803x_link_change_notify() checks to make sure that it only
resets the PHY on the 8030, but it makes more sense to not call that
function at all if it isn't needed.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
drivers/net/phy/at803x.c | 40 ++++++++++++++++++----------------------
1 file changed, 18 insertions(+), 22 deletions(-)
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index b3ffaee..f279a89 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -359,27 +359,25 @@ static void at803x_link_change_notify(struct phy_device *phydev)
* in the FIFO. In such cases, the FIFO enters an error mode it
* cannot recover from by software.
*/
- if (phydev->drv->phy_id == ATH8030_PHY_ID) {
- if (phydev->state == PHY_NOLINK) {
- if (priv->gpiod_reset && !priv->phy_reset) {
- struct at803x_context context;
-
- at803x_context_save(phydev, &context);
-
- gpiod_set_value(priv->gpiod_reset, 1);
- msleep(1);
- gpiod_set_value(priv->gpiod_reset, 0);
- msleep(1);
-
- at803x_context_restore(phydev, &context);
-
- phydev_dbg(phydev, "%s(): phy was reset\n",
- __func__);
- priv->phy_reset = true;
- }
- } else {
- priv->phy_reset = false;
+ if (phydev->state == PHY_NOLINK) {
+ if (priv->gpiod_reset && !priv->phy_reset) {
+ struct at803x_context context;
+
+ at803x_context_save(phydev, &context);
+
+ gpiod_set_value(priv->gpiod_reset, 1);
+ msleep(1);
+ gpiod_set_value(priv->gpiod_reset, 0);
+ msleep(1);
+
+ at803x_context_restore(phydev, &context);
+
+ phydev_dbg(phydev, "%s(): phy was reset\n",
+ __func__);
+ priv->phy_reset = true;
}
+ } else {
+ priv->phy_reset = false;
}
}
@@ -391,7 +389,6 @@ static struct phy_driver at803x_driver[] = {
.phy_id_mask = 0xffffffef,
.probe = at803x_probe,
.config_init = at803x_config_init,
- .link_change_notify = at803x_link_change_notify,
.set_wol = at803x_set_wol,
.get_wol = at803x_get_wol,
.suspend = at803x_suspend,
@@ -427,7 +424,6 @@ static struct phy_driver at803x_driver[] = {
.phy_id_mask = 0xffffffef,
.probe = at803x_probe,
.config_init = at803x_config_init,
- .link_change_notify = at803x_link_change_notify,
.set_wol = at803x_set_wol,
.get_wol = at803x_get_wol,
.suspend = at803x_suspend,
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply related
* Re: [PATCH 1/6] bus: Add shared MDIO bus framework
From: Andrew Lunn @ 2016-04-26 17:45 UTC (permalink / raw)
To: Florian Fainelli
Cc: Pramod Kumar, Mark Rutland, devicetree, Arnd Bergmann, Pawel Moll,
Suzuki K Poulose, Catalin Marinas, Punit Agrawal, Will Deacon,
linux-kernel, Masahiro Yamada, Chen-Yu Tsai, Rob Herring,
BCM Kernel Feedback, netdev, linux-arm-kernel, Anup Patel
In-Reply-To: <571FA3F6.7000903@gmail.com>
> I am not clear on how common a shared MDIO bus is on other SoCs, but the
> other Broadcom SoCs I am familiar with have dedicated MDIO buses
> instances per type of PHY (PCIe, BUSB, Ethernet), thus making the split
> a ton easier.
I don't actually see this shared bus being an issue, once the mux it
implemented. With the mux, you see N MDIO busses, each acting like a
normal MDIO bus. I've used the GPIO variety and had no issues:
http://marc.info/?l=linux-arm-kernel&m=145910090401796&w=2
Andrew
^ permalink raw reply
* Re: [PATCH 1/6] bus: Add shared MDIO bus framework
From: Arnd Bergmann @ 2016-04-26 17:53 UTC (permalink / raw)
To: Florian Fainelli
Cc: Mark Rutland, Andrew Lunn, Punit Agrawal, Anup Patel, Pawel Moll,
devicetree, Catalin Marinas, Suzuki K Poulose, Will Deacon,
Chen-Yu Tsai, linux-kernel, Masahiro Yamada, Pramod Kumar,
Rob Herring, BCM Kernel Feedback, netdev, Kishon Vijay Abraham I,
linux-arm-kernel
In-Reply-To: <571FA3F6.7000903@gmail.com>
On Tuesday 26 April 2016 10:23:02 Florian Fainelli wrote:
> On 26/04/16 05:13, Andrew Lunn wrote:
> >> 4. Apart from these, by using MDIO mux framework we are making our
> >> non-ethernet PHYs dependent on Linux network drivers which is not
> >> acceptable. What if some product line does not need network subsystem at
> >> all?
> >
> > This is your only valid point. However, does Broadcom have a product
> > line which does not include networking? Is not Broadcom a network SoC
> > vendor?
>
> But even with that, there is no reason why we could not decouple the
> PHYLIB MDIO framework from PHYLIB and make it available as a more
> standalone subsystem which can be utilized when you have a mix of MDIO
> devices like here.
[adding Kishon Vijay Abraham]
We should also consider how this fits in with drivers/phy/, which is
the generic framework for all PHY devices that are not for ethernet.
The most straightforward way that you mention would be to allow
generic PHY devices to be probed on an MIO bus or mux. This should
just work using mdio_module_driver(), as Andrew already explained.
A more complex problem would be having a PHY driver for a device
that can be either an ethernet phy or some other phy. With today's
frameworks that would require two separate drivers, one in drivers/phy
and one in drivers/net/phy/. If that turns out to be a common problem,
we might want to come up with a way to nest one on top of the other,
or merge two two device structures (struct phy_device and struct phy).
> I am not clear on how common a shared MDIO bus is on other SoCs, but the
> other Broadcom SoCs I am familiar with have dedicated MDIO buses
> instances per type of PHY (PCIe, BUSB, Ethernet), thus making the split
> a ton easier.
I think most commonly, the other PHYs are not on MDIO at all, but are
integrated inside of the SoC as an MMIO based device.
Arnd
^ permalink raw reply
* Re: [PATCH net-next 0/3] qed: Bandwidth configuration support
From: David Miller @ 2016-04-26 17:56 UTC (permalink / raw)
To: manish.chopra; +Cc: netdev, Ariel.Elior, Yuval.Mintz
In-Reply-To: <1461682570-745-1-git-send-email-manish.chopra@qlogic.com>
From: Manish Chopra <manish.chopra@qlogic.com>
Date: Tue, 26 Apr 2016 10:56:07 -0400
> This series adds support in driver for min/max bandwidth configuration
> for the PF on the link change notification or on explicit request of
> bandwidth update from the MFW [management firmware].
>
> The same infrastructure would later be used by user based flows
> [for example, rate shaping for the VFs]
>
> Please consider applying this series to "net-next"
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/6] bus: Add shared MDIO bus framework
From: Andrew Lunn @ 2016-04-26 18:23 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Florian Fainelli, Pramod Kumar, Rob Herring, Catalin Marinas,
Will Deacon, Masahiro Yamada, Chen-Yu Tsai, Mark Rutland,
devicetree, Pawel Moll, Suzuki K Poulose, netdev, Punit Agrawal,
linux-kernel, BCM Kernel Feedback, linux-arm-kernel, Anup Patel,
Kishon Vijay Abraham I
In-Reply-To: <5167289.0a4LBoWhyX@wuerfel>
> A more complex problem would be having a PHY driver for a device
> that can be either an ethernet phy or some other phy.
I doubt that ever happens. You can have up to 32 different devices on
an MDIO bus. Since an Ethernet PHY and a "some other sort of PHY" are
completely different things, why would a hardware engineer place them
on the same address? It is like saying your ATA controller and VGA
controller share the same slot on the PCI bus...
Andrew
^ permalink raw reply
* Re: [PATCH] ARM: dts: at91: VInCo: fix phy reset gpio flag
From: Sergei Shtylyov @ 2016-04-26 18:25 UTC (permalink / raw)
To: Nicolas Ferre
Cc: linux-kernel, linux-arm-kernel, Gregory Clement,
Alexandre Belloni, netdev, Andrew Lunn, David Miller
In-Reply-To: <1461666272-10107-1-git-send-email-nicolas.ferre@atmel.com>
Hello.
On 04/26/2016 01:24 PM, Nicolas Ferre wrote:
> Fix gpio active flag for the phy reset-gpios property. The line is
> active low instead of active high.
> Actually, this flags was never used by the macb driver.
>
> Reported-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: David Miller <davem@davemloft.net>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> Hi,
>
> Thanks for having reported this bug to me.
And thank you for beating me to it and doing the patch. I'm still busy
with other stuff. :-(
> I hope that we will be able to move forward for changing the phy
> reset code in the macb driver.
I meant to delete it entirely.
> I plan to queue this patch through arm-soc for 4.7.
Hm, that way we get that board broken if my phylib/macb patches get merged
before your patch. Perhaps it would be better to merge this patch thru DaveM's
tree (before my patches) to keep the kernel bisectable?
> Thanks, best regards,
> Nicolas
MBR, Sergei
^ permalink raw reply
* Re: [PATCH] ARM: dts: at91: VInCo: fix phy reset gpio flag
From: Sergei Shtylyov @ 2016-04-26 18:27 UTC (permalink / raw)
To: David Miller, nicolas.ferre
Cc: linux-kernel, linux-arm-kernel, gregory.clement,
alexandre.belloni, netdev, andrew
In-Reply-To: <20160426.131750.433048061726795876.davem@davemloft.net>
On 04/26/2016 08:17 PM, David Miller wrote:
>> I plan to queue this patch through arm-soc for 4.7.
>
> Ok.
How about this patch going thru your net-next repo instead?
I'd like to keep the kernel bisectable... if my phylib/macb patches get merged
earlier than this one, that board would be broken...
MBR, Sergei
^ permalink raw reply
* Re: [PATCH] netem: Segment GSO packets on enqueue.
From: Eric Dumazet @ 2016-04-26 18:49 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, Jamal Hadi Salim, David S. Miller, netem
In-Reply-To: <1461692618-21333-1-git-send-email-nhorman@tuxdriver.com>
On Tue, 2016-04-26 at 13:43 -0400, Neil Horman wrote:
> This was recently reported to me, and reproduced on the latest net kernel, when
> attempting to run netperf from a host that had a netem qdisc attached to the
> egress interface:
..
> The problem occurs because netem is not prepared to handle GSO packets (as it
> uses skb_checksum_help in its enqueue path, which cannot manipulate these
> frames).
>
> The solution I think is to simply segment the skb in a simmilar fashion to the
> way we do in __dev_queue_xmit (via validate_xmit_skb), except here we always
> segment, instead of only when the interface needs us to do it. This allows
> netem to properly drop/mangle/pass/etc the correct percentages of frames as per
> its qdisc configuration, and avoid failing its checksum operations
>
> tested successfully by myself on the latest net kernel, to whcih this applies
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> CC: Jamal Hadi Salim <jhs@mojatatu.com>
> CC: "David S. Miller" <davem@davemloft.net>
> CC: netem@lists.linux-foundation.org
> ---
> net/sched/sch_netem.c | 34 +++++++++++++++++++++++++++++++++-
> 1 file changed, 33 insertions(+), 1 deletion(-)
This is not correct.
I want my TSO packets being still TSO after netem traversal.
Some of us use netem at 40Gbit speed ;)
^ permalink raw reply
* [PATCH] Fixes buffer allocation size and the actual packet length;
From: Petko Manolov @ 2016-04-26 18:50 UTC (permalink / raw)
To: netdev; +Cc: davem, petkan
As noticed by Lincoln Ramsay <a1291762@gmail.com> some old (usb 1.1) Pegasus
based devices may actually return more bytes than the specified in the datasheet
amount. That would not be a problem if the allocated space for the SKB was
equal to the parameter passed to usb_fill_bulk_urb(). Some poor bugger (i
really hope it was not me, but 'git blame' is useless in this case, so anyway)
decided to add '+ 8' to the buffer length parameter. Sometimes the usb transfer
overflows and corrupts the socket structure, leading to kernel panic.
The above doesn't seem to happen for newer (Pegasus2 based) devices which did
help this bug to hide for so long.
Nearly all Pegasus devices may append the RX status to the end of the received
packet. It is the default setup for the driver. The actual ethernet packet is
4 bytes shorter. Why and when 'pkt_len -= 4' became 'pkt_len -= 8' is again
hidden in the mists of time. There might have been a good reason to do so, but
multiple reads of the datasheet did not point me to any.
The patch is against v4.6-rc5 and was tested on ADM8515 device by transferring
multiple gigabytes of data over a couple of days without any complains from the
kernel.
Petko Manolov (1):
Fixes buffer allocation size and the actual packet length;
drivers/net/usb/pegasus.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--
2.8.0.rc3
^ permalink raw reply
* [PATCH] Fixes buffer allocation size and the actual packet length;
From: Petko Manolov @ 2016-04-26 18:50 UTC (permalink / raw)
To: netdev; +Cc: davem, petkan
In-Reply-To: <1461696624-5373-1-git-send-email-petkan@mip-labs.com>
usb_fill_bulk_urb() receives buffer length parameter 8 bytes larger
than what's allocated by alloc_skb(); This seems to be a problem with
older (pegasus usb-1.1) devices, which may silently return more data
than the maximal packet length.
Going through the chip's documentation i figured out the ethernet
packet is appended with 4 bytes of status data. That's why we now
subtract 4 instead of 8 bytes from the reported packet length.
Reported-by: Lincoln Ramsay <a1291762@gmail.com>
Signed-off-by: Petko Manolov <petkan@mip-labs.com>
---
drivers/net/usb/pegasus.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/usb/pegasus.c b/drivers/net/usb/pegasus.c
index f840802..780c217 100644
--- a/drivers/net/usb/pegasus.c
+++ b/drivers/net/usb/pegasus.c
@@ -497,7 +497,7 @@ static void read_bulk_callback(struct urb *urb)
pkt_len = buf[count - 3] << 8;
pkt_len += buf[count - 4];
pkt_len &= 0xfff;
- pkt_len -= 8;
+ pkt_len -= 4;
}
/*
@@ -528,7 +528,7 @@ static void read_bulk_callback(struct urb *urb)
goon:
usb_fill_bulk_urb(pegasus->rx_urb, pegasus->usb,
usb_rcvbulkpipe(pegasus->usb, 1),
- pegasus->rx_skb->data, PEGASUS_MTU + 8,
+ pegasus->rx_skb->data, PEGASUS_MTU,
read_bulk_callback, pegasus);
rx_status = usb_submit_urb(pegasus->rx_urb, GFP_ATOMIC);
if (rx_status == -ENODEV)
@@ -569,7 +569,7 @@ static void rx_fixup(unsigned long data)
}
usb_fill_bulk_urb(pegasus->rx_urb, pegasus->usb,
usb_rcvbulkpipe(pegasus->usb, 1),
- pegasus->rx_skb->data, PEGASUS_MTU + 8,
+ pegasus->rx_skb->data, PEGASUS_MTU,
read_bulk_callback, pegasus);
try_again:
status = usb_submit_urb(pegasus->rx_urb, GFP_ATOMIC);
@@ -823,7 +823,7 @@ static int pegasus_open(struct net_device *net)
usb_fill_bulk_urb(pegasus->rx_urb, pegasus->usb,
usb_rcvbulkpipe(pegasus->usb, 1),
- pegasus->rx_skb->data, PEGASUS_MTU + 8,
+ pegasus->rx_skb->data, PEGASUS_MTU,
read_bulk_callback, pegasus);
if ((res = usb_submit_urb(pegasus->rx_urb, GFP_KERNEL))) {
if (res == -ENODEV)
--
2.8.0.rc3
^ permalink raw reply related
* Re: [PATCH] net/mlx5e: avoid stack overflow in mlx5e_open_channels
From: Saeed Mahameed @ 2016-04-26 18:50 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Saeed Mahameed, Matan Barak, Leon Romanovsky, David S. Miller,
Achiad Shochat, Or Gerlitz, Amir Vadai, Tariq Toukan,
Linux Netdev List, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <23978128.X7F5UHGaYZ@wuerfel>
On Tue, Apr 26, 2016 at 6:49 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Tuesday 26 April 2016 17:41:45 Saeed Mahameed wrote:
>> On Tue, Apr 26, 2016 at 4:53 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>> >
>> > Sure, do you want to just edit this when you forward the patch, or
>> > do you need me to do it?
>> >
>>
>> Well, I won't say no if you want to do it
>>
>
> All I want is to get rid of the patch in my queue. I guess it's
> worth the 10 minute of work ;-)
>
> v2 coming
>
> Arnd
Thank you Arnd, Appreciated.
Saeed.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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 v2] net/mlx5e: avoid stack overflow in mlx5e_open_channels
From: Saeed Mahameed @ 2016-04-26 18:52 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Saeed Mahameed, Matan Barak, Leon Romanovsky, David S. Miller,
Achiad Shochat, Or Gerlitz, Amir Vadai, Tariq Toukan,
Linux Netdev List, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1461685993-1049370-1-git-send-email-arnd-r2nGTMty4D4@public.gmane.org>
On Tue, Apr 26, 2016 at 6:52 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> struct mlx5e_channel_param is a large structure that is allocated
> on the stack of mlx5e_open_channels, and with a recent change
> it has grown beyond the warning size for the maximum stack
> that a single function should use:
>
> mellanox/mlx5/core/en_main.c: In function 'mlx5e_open_channels':
> mellanox/mlx5/core/en_main.c:1325:1: error: the frame size of 1072 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
>
> The function is already using dynamic allocation and is not in
> a fast path, so the easiest workaround is to use another kzalloc
> for allocating the channel parameters.
>
> Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> Fixes: d3c9bc2743dc ("net/mlx5e: Added ICO SQs")
Acked-by: Saeed Mahameed <saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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] macvlan: fix failure during registration v3
From: Mahesh Bandewar @ 2016-04-26 18:54 UTC (permalink / raw)
To: Francesco Ruggeri; +Cc: linux-netdev, Eric W. Biederman, David S. Miller
In-Reply-To: <1461449012-7401-1-git-send-email-fruggeri@arista.com>
On Sat, Apr 23, 2016 at 3:03 PM, Francesco Ruggeri <fruggeri@arista.com> wrote:
> If macvlan_common_newlink fails in register_netdevice after macvlan_init
> then it decrements port->count twice, first in macvlan_uninit (from
> register_netdevice or rollback_registered) and then again in
> macvlan_common_newlink.
> A similar problem may exist in the ipvlan driver.
That is correct! The problem exists in ipvlan driver also. I'll cook a
patch to fix this in ipvlan driver.
> This patch consolidates modifications to port->count into macvlan_init
> and macvlan_uninit (thanks to Eric Biederman for suggesting this approach).
>
> v3: remove macvtap specific bits.
>
> Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
> ---
> drivers/net/macvlan.c | 10 ++++------
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
> index 2bcf1f3..cb01023 100644
> --- a/drivers/net/macvlan.c
> +++ b/drivers/net/macvlan.c
> @@ -795,6 +795,7 @@ static int macvlan_init(struct net_device *dev)
> {
> struct macvlan_dev *vlan = netdev_priv(dev);
> const struct net_device *lowerdev = vlan->lowerdev;
> + struct macvlan_port *port = vlan->port;
>
> dev->state = (dev->state & ~MACVLAN_STATE_MASK) |
> (lowerdev->state & MACVLAN_STATE_MASK);
> @@ -812,6 +813,8 @@ static int macvlan_init(struct net_device *dev)
> if (!vlan->pcpu_stats)
> return -ENOMEM;
>
> + port->count += 1;
> +
> return 0;
> }
>
> @@ -1312,10 +1315,9 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
> return err;
> }
>
> - port->count += 1;
> err = register_netdevice(dev);
> if (err < 0)
> - goto destroy_port;
> + return err;
>
> dev->priv_flags |= IFF_MACVLAN;
> err = netdev_upper_dev_link(lowerdev, dev);
> @@ -1330,10 +1332,6 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
>
> unregister_netdev:
> unregister_netdevice(dev);
> -destroy_port:
> - port->count -= 1;
> - if (!port->count)
> - macvlan_port_destroy(lowerdev);
I think you still need this when it fails netdev_upper_dev_link(). The
only thing you should remove is the label.
>
> return err;
> }
> --
> 1.8.1.4
>
^ permalink raw reply
* Re: [PATCH] netem: Segment GSO packets on enqueue.
From: Neil Horman @ 2016-04-26 19:00 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Jamal Hadi Salim, David S. Miller, netem
In-Reply-To: <1461696598.5535.35.camel@edumazet-glaptop3.roam.corp.google.com>
On Tue, Apr 26, 2016 at 11:49:58AM -0700, Eric Dumazet wrote:
> On Tue, 2016-04-26 at 13:43 -0400, Neil Horman wrote:
> > This was recently reported to me, and reproduced on the latest net kernel, when
> > attempting to run netperf from a host that had a netem qdisc attached to the
> > egress interface:
>
> ..
>
> > The problem occurs because netem is not prepared to handle GSO packets (as it
> > uses skb_checksum_help in its enqueue path, which cannot manipulate these
> > frames).
> >
> > The solution I think is to simply segment the skb in a simmilar fashion to the
> > way we do in __dev_queue_xmit (via validate_xmit_skb), except here we always
> > segment, instead of only when the interface needs us to do it. This allows
> > netem to properly drop/mangle/pass/etc the correct percentages of frames as per
> > its qdisc configuration, and avoid failing its checksum operations
> >
> > tested successfully by myself on the latest net kernel, to whcih this applies
> >
> > Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> > CC: Jamal Hadi Salim <jhs@mojatatu.com>
> > CC: "David S. Miller" <davem@davemloft.net>
> > CC: netem@lists.linux-foundation.org
> > ---
> > net/sched/sch_netem.c | 34 +++++++++++++++++++++++++++++++++-
> > 1 file changed, 33 insertions(+), 1 deletion(-)
>
>
> This is not correct.
>
> I want my TSO packets being still TSO after netem traversal.
>
> Some of us use netem at 40Gbit speed ;)
>
I can understand that, but that raises two questions in my mind:
1) Doesn't that make all the statistical manipulation for netem wrong? That is
to say, if netem drops 5% of packets, and it happens to drop a GSO packet, its
actually dropping several, instead of the single one required.
2) How are you getting netem to work with GSO at all? The warning is triggered
for me on every GSO packet, which I think would impact throughput :)
Neil
^ 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