[PATCH] dp83640: Ensure against premature access to PHY registers after reset

From: Esben Haabendal Signed-off-by: Esben Haabendal --- drivers/net/phy/dp83640.c | 17 + 1 file changed, 17 insertions(+) diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c index 654f42d00092..48403170096a 100644 ---

Re: [PATCH net 3/3] lan78xx: Lan7801 Support for Fixed PHY

On Fri, Apr 06, 2018 at 11:42:04AM +0530, Raghuram Chary J wrote: > Adding Fixed PHY support to the lan78xx driver. Hi Raghuram What do you expect is connected to the MAC if there is no PHY? Andrew

Re: [PATCH net 2/3] lan78xx: Add support to dump lan78xx registers

> +static int lan78xx_get_regs_len(struct net_device *netdev) > +{ > + return (sizeof(lan78xx_regs) + PHY_REG_SIZE); If there is no PHY attached, you probably should not include PHY_REG_SIZE here. Andrew

Re: TCP one-by-one acking - RFC interpretation question

Cc Neal and Yuchung if they missed this thread. On 04/06/2018 08:03 AM, Michal Kubecek wrote: > On Fri, Apr 06, 2018 at 05:01:29AM -0700, Eric Dumazet wrote: >> >> >> On 04/06/2018 03:05 AM, Michal Kubecek wrote: >>> Hello >>> >>> I encountered a strange behaviour of some (non-linux) TCP stack

Re: [PATCH net-next] netns: filter uevents correctly

Christian Brauner writes: >> At a practical level there should be no receivers. Plus performance >> issues. At least my memory is that any unprivileged user on the system >> is allowed to listen to those events. > > Any unprivileged user is allowed to listen to

Re: [PATCH 3/9] kbuild: Do not pass arguments to link-vmlinux.sh

On Fri, Apr 06, 2018 at 09:59:59AM +0900, Masahiro Yamada wrote: > 2018-04-06 3:59 GMT+09:00 Jiri Olsa : > > On Fri, Apr 06, 2018 at 12:50:00AM +0900, Masahiro Yamada wrote: > >> 2018-04-06 0:16 GMT+09:00 Jiri Olsa : > >> > There's no need to pass LD* arguments

Re: [PATCH] dp83640: Ensure against premature access to PHY registers after reset

David Miller writes: > From: Andrew Lunn > Date: Fri, 6 Apr 2018 16:14:10 +0200 > >> On Fri, Apr 06, 2018 at 04:05:40PM +0200, Esben Haabendal wrote: >>> From: Esben Haabendal >>> >>> Signed-off-by: Esben Haabendal >>> ---

[PATCH v2] dp83640: Ensure against premature access to PHY registers after reset

From: Esben Haabendal Signed-off-by: Esben Haabendal --- drivers/net/phy/dp83640.c | 18 ++ 1 file changed, 18 insertions(+) diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c index 654f42d00092..a6c87793d899 100644 ---

Re: [PATCH] net: phy: marvell: Enable interrupt function on LED2 pin

Andrew Lunn writes: >> diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c index >> 0e0978d8a0eb..f03a510f1247 100644 >> --- a/drivers/net/phy/marvell.c >> +++ b/drivers/net/phy/marvell.c >> @@ -457,6 +457,21 @@ static int marvell_of_reg_init(struct phy_device >>

[RFC PATCH v3 bpf-next 0/5] bpf/verifier: subprog/func_call simplifications

By storing subprog boundaries as a subprogno mark on each insn, rather than a start (and implicit end) for each subprog, the code handling subprogs can in various places be made simpler, more explicit, and more efficient (i.e. better asymptotic complexity). This also lays the ground for

[RFC PATCH v3 bpf-next 3/5] bpf/verifier: update selftests

Error messages for some bad programs have changed. Also added a test ("calls: interleaved functions") to ensure that subprogs are required to be contiguous. It wasn't entirely clear to me what "calls: wrong recursive calls" was meant to test for, since all of the JMP|CALL insns are unreachable.

[RFC PATCH v3 bpf-next 2/5] bpf/verifier: rewrite subprog boundary detection

By storing a subprogno in each insn's aux data, we avoid the need to keep the list of subprog starts sorted or bsearch() it in find_subprog(). Also, get rid of the weird one-based indexing of subprog numbers. Signed-off-by: Edward Cree --- include/linux/bpf_verifier.h |

[RFC PATCH v3 bpf-next 1/5] bpf/verifier: store subprog info in struct bpf_subprog_info

Per-subprog info is stored in env->subprog_info, an array of structs, rather than multiple arrays with a common index. Signed-off-by: Edward Cree --- include/linux/bpf_verifier.h | 9 +--- kernel/bpf/verifier.c| 49 +++-

[RFC PATCH v3 bpf-next 5/5] bpf/verifier: per-register parent pointers

By giving each register its own liveness chain, we elide the skip_callee() logic. Instead, each register's parent is the state it inherits from; both check_func_call() and prepare_func_exit() automatically connect reg states to the correct chain since when they copy the reg state across

[RFC PATCH v3 bpf-next 4/5] bpf/verifier: use call graph to efficiently check max stack depth

Instead of recursively walking every possible call chain, check_max_stack_depth() now uses an explicit call graph (recorded in subprog_info.callees) which it topologically sorts, allowing it to find for each subprog the maximum stack depth of all call chains, and then use that depth in

Re: [PATCH net-next] netns: filter uevents correctly

On Fri, Apr 06, 2018 at 09:45:41AM -0500, Eric W. Biederman wrote: > Christian Brauner writes: > > > On Thu, Apr 05, 2018 at 10:59:49PM -0500, Eric W. Biederman wrote: > >> Christian Brauner writes: > >> > >> > On Thu, Apr 05,

Re: [PATCH v2] dp83640: Ensure against premature access to PHY registers after reset

On Fri, Apr 06, 2018 at 07:08:44PM +0200, Esben Haabendal wrote: > From: Esben Haabendal Hi Esben It it good to have some form of commit message. Something like: The datasheet specifies a 3uS pause after performing a software reset. The default implementation of

Fw: [Bug 199307] New: kernel panic,call trace,sched_clock,tcp_write_timer_handler

Forwarding to netdev mailing list, it might be a real problem Ugh. Glaring backtrace screenshots. Begin forwarded message: Date: Fri, 06 Apr 2018 16:43:46 + From: bugzilla-dae...@bugzilla.kernel.org To: step...@networkplumber.org Subject: [Bug 199307] New: kernel panic,call

Re: [PATCH v2] net: phy: marvell: Enable interrupt function on LED2 pin

On Thu, Apr 05, 2018 at 10:40:29PM +0200, Esben Haabendal wrote: > From: Esben Haabendal > > The LED2[2]/INTn pin on Marvell 88E1318S as well as 88E1510/12/14/18 needs > to be configured to be usable as interrupt not only when WOL is enabled, > but whenever we rely on interrupts

Re: [PATCH v2] net: phy: marvell: Enable interrupt function on LED2 pin

From: Andrew Lunn Date: Fri, 6 Apr 2018 19:29:28 +0200 > On Thu, Apr 05, 2018 at 10:40:29PM +0200, Esben Haabendal wrote: >> From: Esben Haabendal >> >> The LED2[2]/INTn pin on Marvell 88E1318S as well as 88E1510/12/14/18 needs >> to be configured to be usable as

<    1   2