* [PATCH net-next 3/3] Add LAN743X to MAINTAINER list
From: Bryan.Whitehead @ 2017-08-11 19:48 UTC (permalink / raw)
To: netdev, davem; +Cc: UNGLinuxDriver
From: Bryan Whitehead <Bryan.Whitehead@microchip.com>
Add LAN743X to MAINTAINER list
Signed-off-by: Bryan Whitehead <Bryan.Whitehead@microchip.com>
---
MAINTAINERS | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2db0f8c..3216348 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8749,6 +8749,13 @@ F: drivers/net/dsa/microchip/*
F: include/linux/platform_data/microchip-ksz.h
F: Documentation/devicetree/bindings/net/dsa/ksz.txt
+MICROCHIP LAN743X ETHERNET DRIVER
+M: Bryan Whitehead <bryan.whitehead@microchip.com>
+M: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
+L: netdev@vger.kernel.org
+S: Maintained
+F: drivers/net/ethernet/microchip/lan743x.*
+
MICROCHIP USB251XB DRIVER
M: Richard Leitner <richard.leitner@skidata.com>
L: linux-usb@vger.kernel.org
--
2.7.4
^ permalink raw reply related
* Re: After a while of system running no incoming UDP any more?
From: Marc Haber @ 2017-08-11 20:07 UTC (permalink / raw)
To: Paolo Abeni, netdev
In-Reply-To: <20170811143453.6vrf2us2jev2ys3d@torres.zugschlus.de>
On Fri, Aug 11, 2017 at 04:34:53PM +0200, Marc Haber wrote:
> On Fri, Jul 28, 2017 at 02:14:34PM +0200, Marc Haber wrote:
> > I can confirm that these two changes make a system in bad state work
> > again immediately. Will try the patch on 4.12.4 later today.
>
> After upgrading my test systems to 4.12.5, the issue reappeared. This
> shows me that the patch indeed helped (my patched 4.12.4 kernels didn't
> show the bad behavior), and that the patch didn't make its way into
> 4.12.5. The patch applied to 4.12.5, kernels are building.
It seems to be in the freshly released 4.12.6.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply
* Re: [PATCH] net/sched: reset block pointer in tcf_block_put()
From: Cong Wang @ 2017-08-11 20:18 UTC (permalink / raw)
To: Konstantin Khlebnikov
Cc: Linux Kernel Network Developers, Jiri Pirko, David S. Miller,
Jamal Hadi Salim
In-Reply-To: <150235751251.493255.14955523507789154918.stgit@buzz>
On Thu, Aug 10, 2017 at 2:31 AM, Konstantin Khlebnikov
<khlebnikov@yandex-team.ru> wrote:
> In previous API tcf_destroy_chain() could be called several times and
> some schedulers like hfsc and atm use that. In new API tcf_block_put()
> frees block but leaves stale pointer, second call will free it once again.
Which call path do we call tcf_block_put() for multiple times on
the same block? Please be specific, it is not obvious.
^ permalink raw reply
* Re: [PATCH] net/sched/hfsc: allocate tcf block for hfsc root class
From: Cong Wang @ 2017-08-11 20:29 UTC (permalink / raw)
To: Konstantin Khlebnikov
Cc: Linux Kernel Network Developers, Jiri Pirko, David S. Miller,
Jamal Hadi Salim
In-Reply-To: <150235750037.493227.16245118631720190134.stgit@buzz>
On Thu, Aug 10, 2017 at 2:31 AM, Konstantin Khlebnikov
<khlebnikov@yandex-team.ru> wrote:
> Without this filters cannot be attached.
>
> Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
> Fixes: 6529eaba33f0 ("net: sched: introduce tcf block infractructure")
Looks good.
Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
^ permalink raw reply
* Re: [PATCH] net/sched: reset block pointer in tcf_block_put()
From: Florian Westphal @ 2017-08-11 20:32 UTC (permalink / raw)
To: Cong Wang
Cc: Konstantin Khlebnikov, Linux Kernel Network Developers,
Jiri Pirko, David S. Miller, Jamal Hadi Salim
In-Reply-To: <CAM_iQpX=XLheuuBk_kAa+jHO-e16hnzavHhzHJ4EYWwpjGFzMg@mail.gmail.com>
Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Thu, Aug 10, 2017 at 2:31 AM, Konstantin Khlebnikov
> <khlebnikov@yandex-team.ru> wrote:
> > In previous API tcf_destroy_chain() could be called several times and
> > some schedulers like hfsc and atm use that. In new API tcf_block_put()
> > frees block but leaves stale pointer, second call will free it once again.
>
> Which call path do we call tcf_block_put() for multiple times on
> the same block? Please be specific, it is not obvious.
you can use tools/testing/selftests/net/rtnetlink.sh to reproduce this
(kernel panics on delete of root qdisc).
^ permalink raw reply
* Re: [PATCH] net/sched: reset block pointer in tcf_block_put()
From: Konstantin Khlebnikov @ 2017-08-11 20:36 UTC (permalink / raw)
To: Cong Wang
Cc: Linux Kernel Network Developers, Jiri Pirko, David S. Miller,
Jamal Hadi Salim
In-Reply-To: <CAM_iQpX=XLheuuBk_kAa+jHO-e16hnzavHhzHJ4EYWwpjGFzMg@mail.gmail.com>
On 11.08.2017 23:18, Cong Wang wrote:
> On Thu, Aug 10, 2017 at 2:31 AM, Konstantin Khlebnikov
> <khlebnikov@yandex-team.ru> wrote:
>> In previous API tcf_destroy_chain() could be called several times and
>> some schedulers like hfsc and atm use that. In new API tcf_block_put()
>> frees block but leaves stale pointer, second call will free it once again.
>
> Which call path do we call tcf_block_put() for multiple times on
> the same block? Please be specific, it is not obvious.
>
For example in hfsc_destroy_qdisc() since a4aebb83cf0da0363684f1c339f7e6149a3e74c1
second time in hfsc_destroy_class() called from it.
Actually, I see the same pattern in all classy qdiscs.
^ permalink raw reply
* Re: [PATCH net-next] geneve: use netlink_ext_ack for error reporting in rtnl operations
From: David Miller @ 2017-08-11 20:45 UTC (permalink / raw)
To: girish.moodalbail; +Cc: pshelar, netdev
In-Reply-To: <1502266168-12107-1-git-send-email-girish.moodalbail@oracle.com>
From: Girish Moodalbail <girish.moodalbail@oracle.com>
Date: Wed, 9 Aug 2017 01:09:28 -0700
> Add extack error messages for failure paths while creating/modifying
> geneve devices. Once extack support is added to iproute2, more
> meaningful and helpful error messages will be displayed making it easy
> for users to discern what went wrong.
>
> Before:
> =======
> $ ip link add gen1 address 0:1:2:3:4:5:6 type geneve id 200 \
> remote 192.168.13.2
> RTNETLINK answers: Invalid argument
>
> After:
> ======
> $ ip link add gen1 address 0:1:2:3:4:5:6 type geneve id 200 \
> remote 192.168.13.2
> Error: Provided link layer address is not Ethernet
>
> Also, netdev_dbg() calls used to log errors associated with Netlink
> request have been removed.
>
> Signed-off-by: Girish Moodalbail <girish.moodalbail@oracle.com>
Applied, thanks.
^ permalink raw reply
* Re: [patch net-next 0/5] net: sched: let the offloader decide what to offload
From: David Miller @ 2017-08-11 20:47 UTC (permalink / raw)
To: jiri
Cc: netdev, jhs, xiyou.wangcong, daniel, mlxsw, andrew,
vivien.didelot, f.fainelli, jakub.kicinski, simon.horman,
pieter.jansenvanvuuren, oss-drivers, ganeshgr, jeffrey.t.kirsher,
saeedm, matanb, leonro
In-Reply-To: <20170809123035.7663-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Wed, 9 Aug 2017 14:30:30 +0200
> From: Jiri Pirko <jiri@mellanox.com>
>
> Currently there is a Qdisc_class_ops->tcf_cl_offload callback
> that is called to find out if cls would offload rule or not.
> This is only supported by sch_ingress and sch_clsact.
> So the Qdisc are to decide. However, the driver knows what is he
> able to offload, so move the decision making to drivers completely.
> Just pass classid there and provide set of helpers to allow
> identification of qdisc.
>
> As a side effect, this actually allows clsact egress rules
> offload in mlxsw.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] liquidio: rx/tx queue cleanup
From: David Miller @ 2017-08-11 20:55 UTC (permalink / raw)
To: felix.manlunas
Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla,
intiyaz.basha
In-Reply-To: <20170809190708.GA1122@felix-thinkpad.cavium.com>
From: Felix Manlunas <felix.manlunas@cavium.com>
Date: Wed, 9 Aug 2017 12:07:08 -0700
> From: Intiyaz Basha <intiyaz.basha@cavium.com>
>
> When deleting a queue, clear its corresponding bit in the qmask, vfree its
> memory, clear out the pointer that's pointing to it, and decrement the
> queue count.
>
> Signed-off-by: Intiyaz Basha <intiyaz.basha@cavium.com>
> Signed-off-by: Felix Manlunas <fmanlunas@cavium.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] liquidio: removed check for queue size alignment
From: David Miller @ 2017-08-11 20:56 UTC (permalink / raw)
To: felix.manlunas
Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla,
intiyaz.basha
In-Reply-To: <20170809202804.GA1238@felix-thinkpad.cavium.com>
From: Felix Manlunas <felix.manlunas@cavium.com>
Date: Wed, 9 Aug 2017 13:28:04 -0700
> From: Intiyaz Basha <intiyaz.basha@cavium.com>
>
> There is no restriction on queue size alignment. Hence removing check for
> valid queue size.
>
> Signed-off-by: Intiyaz Basha <intiyaz.basha@cavium.com>
> Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
Applied.
^ permalink raw reply
* [PATCH 0/4] MIPS: syscall tracing fixes
From: James Hogan @ 2017-08-11 20:56 UTC (permalink / raw)
To: linux-mips
Cc: linux-kernel, James Hogan, Ralf Baechle, David Daney, Kees Cook,
Andy Lutomirski, Will Drewry, Oleg Nesterov, Alexei Starovoitov,
Daniel Borkmann, Lars Persson, netdev
These patches fix some system call tracing issues around seccomp and
ptrace on MIPS.
Patch 1 fixes an issue introduced in v4.13-rc1, where o32 indirect
syscall arguments aren't shifted when filling out seccomp_data struct.
Arguably the samples/bpf/tracex5 case that was being fixed in -rc1 is
flawed, or else other arches are broken too. thoughts welcome on that,
but either way this fix should be okay. It'd be good to get this fix
in particular into v4.13.
Patches 2 and 3 fix changing of system calls by ptrace and
SECCOMP_RET_TRACE so that seccomp & syscall trace don't use the stale
system call number, which appears to have been conceptually broken since
v3.19 when thread_info::syscall was introduced, but also prevented the
change in v4.8 to re-run the seccomp filter against a changed syscall
from being effective on MIPS.
First (patch 2) syscall_trace_enter() is fixed to re-read the syscall
number from thread_info:syscall, then (patch 3) ptrace is fixed to
update thread_info::syscall when the relevant registers are altered.
Finally patch 4 fixes an API gap for MIPS which prevents a
SECCOMP_RET_TRACE tracer from being able to cancel a system call, since
you can't set both the system call number (v0) to -1 and the return
value (v0) to the chosen error code. A PTRACE_SET_SYSCALL is added which
allows thread_info::syscall to be set to -1 after the return value has
already been set in the v0 register to some other value.
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: David Daney <david.daney@cavium.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Will Drewry <wad@chromium.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Lars Persson <lars.persson@axis.com>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
James Hogan (4):
MIPS/seccomp: Fix indirect syscall args
MIPS/ptrace: Pick up ptrace/seccomp changed syscalls
MIPS/ptrace: Update syscall nr on register changes
MIPS/ptrace: Add PTRACE_SET_SYSCALL operation
arch/mips/include/asm/syscall.h | 29 ++++++++++++++++++++----
arch/mips/include/uapi/asm/ptrace.h | 1 +
arch/mips/kernel/ptrace.c | 45 +++++++++++++++++++++++++++++--------
arch/mips/kernel/ptrace32.c | 18 +++++++++++++++
4 files changed, 80 insertions(+), 13 deletions(-)
--
2.13.2
^ permalink raw reply
* [PATCH 1/4] MIPS/seccomp: Fix indirect syscall args
From: James Hogan @ 2017-08-11 20:56 UTC (permalink / raw)
To: linux-mips
Cc: linux-kernel, James Hogan, Ralf Baechle, David Daney, Kees Cook,
Andy Lutomirski, Will Drewry, Oleg Nesterov, Alexei Starovoitov,
Daniel Borkmann, netdev
In-Reply-To: <20170811205653.21873-1-james.hogan@imgtec.com>
Since commit 669c4092225f ("MIPS: Give __secure_computing() access to
syscall arguments."), upon syscall entry when seccomp is enabled,
syscall_trace_enter() passes a carefully prepared struct seccomp_data
containing syscall arguments to __secure_computing(). Unfortunately it
directly uses mips_get_syscall_arg() and fails to take into account the
indirect O32 system calls (i.e. syscall(2)) which put the system call
number in a0 and have the arguments shifted up by one entry.
We can't just revert that commit as samples/bpf/tracex5 would break
again, so use syscall_get_arguments() which already takes indirect
syscalls into account instead of directly using mips_get_syscall_arg(),
similar to what populate_seccomp_data() does.
This also removes the redundant error checking of the
mips_get_syscall_arg() return value (get_user() already zeroes the
result if an argument from the stack can't be loaded).
Reported-by: James Cowgill <James.Cowgill@imgtec.com>
Fixes: 669c4092225f ("MIPS: Give __secure_computing() access to syscall arguments.")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: David Daney <david.daney@cavium.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Will Drewry <wad@chromium.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
---
It would have been much simpler for MIPS arch code to just pass a NULL
seccomp_data to secure_computing() so populate_seccomp_data() would take
care of fetching arguments, as it did for MIPS prior to commit
669c4092225f ("MIPS: Give __secure_computing() access to syscall
arguments."), but as that commit mentions it breaks samples/bpf/tracex5,
which relies on sd being non-NULL at entry to __seccomp_filter().
Arguably the samples/bpf/tracex5 test is flawed, at least for every arch
except x86 (and now MIPS).
---
arch/mips/kernel/ptrace.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/mips/kernel/ptrace.c b/arch/mips/kernel/ptrace.c
index 6dd13641a418..1395654cfc8d 100644
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -872,15 +872,13 @@ asmlinkage long syscall_trace_enter(struct pt_regs *regs, long syscall)
if (unlikely(test_thread_flag(TIF_SECCOMP))) {
int ret, i;
struct seccomp_data sd;
+ unsigned long args[6];
sd.nr = syscall;
sd.arch = syscall_get_arch();
- for (i = 0; i < 6; i++) {
- unsigned long v, r;
-
- r = mips_get_syscall_arg(&v, current, regs, i);
- sd.args[i] = r ? 0 : v;
- }
+ syscall_get_arguments(current, regs, 0, 6, args);
+ for (i = 0; i < 6; i++)
+ sd.args[i] = args[i];
sd.instruction_pointer = KSTK_EIP(current);
ret = __secure_computing(&sd);
--
2.13.2
^ permalink raw reply related
* Re: [PATCH net] net: dsa: ksz: fix skb freeing
From: David Miller @ 2017-08-11 20:57 UTC (permalink / raw)
To: vivien.didelot; +Cc: netdev, linux-kernel, kernel, f.fainelli, andrew
In-Reply-To: <20170809204609.8114-1-vivien.didelot@savoirfairelinux.com>
From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Date: Wed, 9 Aug 2017 16:46:09 -0400
> The DSA layer frees the original skb when an xmit function returns NULL,
> meaning an error occurred. But if the tagging code copied the original
> skb, it is responsible of freeing the copy if an error occurs.
>
> The ksz tagging code currently has two issues: if skb_put_padto fails,
> the skb copy is not freed, and the original skb will be freed twice.
>
> To fix that, move skb_put_padto inside both branches of the skb_tailroom
> condition, before freeing the original skb, and free the copy on error.
>
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] phylink: Fix an uninitialized variable bug
From: David Miller @ 2017-08-11 20:58 UTC (permalink / raw)
To: dan.carpenter; +Cc: andrew, rmk+kernel, f.fainelli, netdev, kernel-janitors
In-Reply-To: <20170809213550.rga6tlohagu2pm2y@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu, 10 Aug 2017 00:35:50 +0300
> "ret" isn't necessarily initialized here.
>
> Fixes: 9525ae83959b ("phylink: add phylink infrastructure")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied, thanks Dan.
^ permalink raw reply
* Re: [PATCH net-next 00/10] netvsc: minor fixes and improvements
From: David Miller @ 2017-08-11 21:00 UTC (permalink / raw)
To: stephen; +Cc: devel, haiyangz, sthemmin, netdev
In-Reply-To: <20170810004612.22163-1-sthemmin@microsoft.com>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Wed, 9 Aug 2017 17:46:02 -0700
> These are non-critical bug fixes, related to functionality now in net-next.
> 1. delaying the automatic bring up of VF device to allow udev to change name.
> 2. performance improvement
> 3. handle MAC address change with VF; mostly propogate the error that VF gives.
> 4. minor cleanups
> 5. allow setting send/receive buffer size with ethtool.
Series applied, thanks Stephen.
^ permalink raw reply
* Re: [PATCH] net/sched: reset block pointer in tcf_block_put()
From: Cong Wang @ 2017-08-11 21:06 UTC (permalink / raw)
To: Florian Westphal
Cc: Konstantin Khlebnikov, Linux Kernel Network Developers,
Jiri Pirko, David S. Miller, Jamal Hadi Salim
In-Reply-To: <20170811203246.GA32076@breakpoint.cc>
On Fri, Aug 11, 2017 at 1:32 PM, Florian Westphal <fw@strlen.de> wrote:
> Cong Wang <xiyou.wangcong@gmail.com> wrote:
>> On Thu, Aug 10, 2017 at 2:31 AM, Konstantin Khlebnikov
>> <khlebnikov@yandex-team.ru> wrote:
>> > In previous API tcf_destroy_chain() could be called several times and
>> > some schedulers like hfsc and atm use that. In new API tcf_block_put()
>> > frees block but leaves stale pointer, second call will free it once again.
>>
>> Which call path do we call tcf_block_put() for multiple times on
>> the same block? Please be specific, it is not obvious.
>
> you can use tools/testing/selftests/net/rtnetlink.sh to reproduce this
> (kernel panics on delete of root qdisc).
I am sure this is not how changelog works. We have enough space
in changelog to describe a bug, don't have to leave details in a
following-up email which will almost surely be lost in history.
^ permalink raw reply
* Re: [PATCH] net/sched: reset block pointer in tcf_block_put()
From: David Miller @ 2017-08-11 21:21 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: fw, khlebnikov, netdev, jiri, jhs
In-Reply-To: <CAM_iQpUoa5vWfQGpqCJ7dXx542uC-5JyNpRK-zukVbq=EfAAEA@mail.gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Fri, 11 Aug 2017 14:06:31 -0700
> On Fri, Aug 11, 2017 at 1:32 PM, Florian Westphal <fw@strlen.de> wrote:
>> Cong Wang <xiyou.wangcong@gmail.com> wrote:
>>> On Thu, Aug 10, 2017 at 2:31 AM, Konstantin Khlebnikov
>>> <khlebnikov@yandex-team.ru> wrote:
>>> > In previous API tcf_destroy_chain() could be called several times and
>>> > some schedulers like hfsc and atm use that. In new API tcf_block_put()
>>> > frees block but leaves stale pointer, second call will free it once again.
>>>
>>> Which call path do we call tcf_block_put() for multiple times on
>>> the same block? Please be specific, it is not obvious.
>>
>> you can use tools/testing/selftests/net/rtnetlink.sh to reproduce this
>> (kernel panics on delete of root qdisc).
>
> I am sure this is not how changelog works. We have enough space
> in changelog to describe a bug, don't have to leave details in a
> following-up email which will almost surely be lost in history.
Yeah, the more information in the commit log message the better.
^ permalink raw reply
* Re: [PATCH] bonding: require speed/duplex only for 802.3ad, alb and tlb
From: David Miller @ 2017-08-11 21:22 UTC (permalink / raw)
To: futur.andy; +Cc: netdev, maheshb
In-Reply-To: <20170810044144.17398-1-futur.andy@googlemail.com>
From: Andreas Born <futur.andy@googlemail.com>
Date: Thu, 10 Aug 2017 06:41:44 +0200
> The patch c4adfc822bf5 ("bonding: make speed, duplex setting consistent
> with link state") puts the link state to down if
> bond_update_speed_duplex() cannot retrieve speed and duplex settings.
> Assumably the patch was written with 802.3ad mode in mind which relies
> on link speed/duplex settings. For other modes like active-backup these
> settings are not required. Thus, only for these other modes, this patch
> reintroduces support for slaves that do not support reporting speed or
> duplex such as wireless devices. This fixes the regression reported in
> bug 196547 (https://bugzilla.kernel.org/show_bug.cgi?id=196547).
>
> Fixes: c4adfc822bf5 ("bonding: make speed, duplex setting consistent
> with link state")
> Signed-off-by: Andreas Born <futur.andy@googlemail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCHv2 1/2] drivers: net: davinci_mdio: remove busy loop on wait user access
From: David Miller @ 2017-08-11 21:24 UTC (permalink / raw)
To: muvarov; +Cc: netdev, linux-omap, grygorii.strashko
In-Reply-To: <1502351267-23841-1-git-send-email-muvarov@gmail.com>
From: Max Uvarov <muvarov@gmail.com>
Date: Thu, 10 Aug 2017 10:47:46 +0300
> Polling 14 mdio devices on single mdio bus eats 30% of 1Ghz cpu time
> due to busy loop in wait(). Add small delay to relax cpu.
>
> Signed-off-by: Max Uvarov <muvarov@gmail.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCHv2 2/2] drivers: net: davinci_mdio: print bus frequency
From: David Miller @ 2017-08-11 21:24 UTC (permalink / raw)
To: muvarov; +Cc: netdev, linux-omap, grygorii.strashko
In-Reply-To: <1502351267-23841-2-git-send-email-muvarov@gmail.com>
From: Max Uvarov <muvarov@gmail.com>
Date: Thu, 10 Aug 2017 10:47:47 +0300
> Frequency can be adjusted in DT it make sense to
> print current used value on driver init.
>
> Signed-off-by: Max Uvarov <muvarov@gmail.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH 1/1] forcedeth: replace init_timer_deferrable with setup_deferrable_timer
From: David Miller @ 2017-08-11 21:27 UTC (permalink / raw)
To: yanjun.zhu; +Cc: netdev
In-Reply-To: <1502352792-6930-1-git-send-email-yanjun.zhu@oracle.com>
From: Zhu Yanjun <yanjun.zhu@oracle.com>
Date: Thu, 10 Aug 2017 04:13:12 -0400
> Replace init_timer_deferrable with setup_deferrable_timer to simplify
> the source code.
>
> Signed-off-by: Zhu Yanjun <yanjun.zhu@oracle.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH v5 00/11] Add the integrated PHY support
From: David Miller @ 2017-08-11 21:29 UTC (permalink / raw)
To: david.wu
Cc: heiko, andrew, f.fainelli, robh+dt, mark.rutland, catalin.marinas,
will.deacon, olof, linux, arnd, peppe.cavallaro, alexandre.torgue,
huangtao, hwg, netdev, linux-arm-kernel, linux-rockchip,
devicetree, linux-kernel
In-Reply-To: <1502373410-2423-1-git-send-email-david.wu@rock-chips.com>
From: David Wu <david.wu@rock-chips.com>
Date: Thu, 10 Aug 2017 21:56:39 +0800
> The rk3228 and rk3328 support integrated PHY inside, let's enable
> it to work. And the integrated PHY need to do some special setting,
> so register the rockchip integrated PHY driver.
Series applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] net/sched/hfsc: allocate tcf block for hfsc root class
From: David Miller @ 2017-08-11 21:31 UTC (permalink / raw)
To: khlebnikov; +Cc: netdev, jiri, jhs
In-Reply-To: <150235750037.493227.16245118631720190134.stgit@buzz>
From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Date: Thu, 10 Aug 2017 12:31:40 +0300
> Without this filters cannot be attached.
>
> Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
> Fixes: 6529eaba33f0 ("net: sched: introduce tcf block infractructure")
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/2 net-next] hns3pf: fix hns3_del_tunnel_port()
From: David Miller @ 2017-08-11 21:32 UTC (permalink / raw)
To: dan.carpenter
Cc: yisen.zhuang, salil.mehta, jiri, jhs, lipeng321, netdev,
linux-kernel, kernel-janitors
In-Reply-To: <20170810090720.eh4l6gxsubmwqxo6@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu, 10 Aug 2017 12:54:59 +0300
> This function has a copy and paste bug so it accidentally calls the add
> function instead of the delete function.
>
> Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2 net-next] hns3pf: Fix some harmless copy and paste bugs
From: David Miller @ 2017-08-11 21:32 UTC (permalink / raw)
To: dan.carpenter
Cc: yisen.zhuang, salil.mehta, jiri, jhs, huangdaode, xavier.huwei,
netdev, kernel-janitors
In-Reply-To: <20170810095549.jxkthoyym5gn5oh3@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu, 10 Aug 2017 12:56:14 +0300
> These were copy and paste bugs, but I believe they are harmless.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ 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