Keep supporting proprietary "xlnx,phy-type" attribute and add support for
MII connectivity to the PHY.
Signed-off-by: Alvaro Gamez Machado
---
Changes since v1:
* Renamed phy_type to phy_mode. No other instances of this struct
member were found except for those we wanted to c
On 07/07/2017 07:30 AM, Andy Duan wrote:
From: Richard Leitner Sent: Thursday, July 06,
2017 9:06 PM
To: Andy Duan ; robh...@kernel.org;
mark.rutl...@arm.com
Cc: netdev@vger.kernel.org; devicet...@vger.kernel.org; linux-
ker...@vger.kernel.org; d...@g0hl1n.net; Richard Leitner
Subject: [PATC
From: Richard Leitner Sent: Thursday, July 06,
2017 9:06 PM
>To: Andy Duan ; robh...@kernel.org;
>mark.rutl...@arm.com
>Cc: netdev@vger.kernel.org; devicet...@vger.kernel.org; linux-
>ker...@vger.kernel.org; d...@g0hl1n.net; Richard Leitner
>
>Subject: [PATCH 2/2] net: ethernet: fsl: add phy rese
If this memory allocation fails, we should go through the error handling
path as done everywhere else in this function before returning.
Signed-off-by: Christophe JAILLET
---
drivers/net/arcnet/com20020-pci.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/a
Okay Kees. I will take a look at it.
Best,
Shubham Bansal
On Fri, Jul 7, 2017 at 10:12 AM, Kees Cook wrote:
> On Wed, Jul 5, 2017 at 8:49 PM, Shubham Bansal
> wrote:
>> Hi Kees,
>>
>> Problem is my ARM machine don't have clang and iproute2 which is
>> keeping me from testing the bpf tail calls.
On Wed, Jul 5, 2017 at 8:49 PM, Shubham Bansal
wrote:
> Hi Kees,
>
> Problem is my ARM machine don't have clang and iproute2 which is
> keeping me from testing the bpf tail calls.
>
> You should do the following to test it,.
>
> 1. tools/testing/selftests/bpf/
> 2. make
> 3. sudo ./test_progs
>
>
Andrew Lunn wrote:
> And when we are talking about SFP modules, we are not talking about
> somebody who can just about boiling an egg and put bread in the
> toaster.
>
> Anybody using these SFP modules knows a lot about networking, is a
> power user, and probably does not rely on plug and pray.
On 2017/7/7 1:17, Bjorn Helgaas wrote:
> On Thu, Jul 06, 2017 at 08:58:51PM +0800, Ding Tianhong wrote:
>> Hi Bjorn:
>>
>> Could you please give some feedback about this patchset, it looks like no
>> more comments for more than a week,
>> thanks. :)
>
> I was on vacation when you posted it, but
> If you choose to think of a cable unplug/plug event as "hot plug", then
> the "reset" is the model that feels right. But I'll note that this is also
> presupposing what the right model is for users. This is akin
> to trying to decide what to make for dinner and deciding that a
> hammer is the r
nfp_flower_metadata_cleanup() is defined but never invoked,
not calling it will cause us to leak mask and statistics
queue memory on the host.
Fixes: 43f84b72c50d ("nfp: add metadata to each flow offload")
Signed-off-by: Jakub Kicinski
---
drivers/net/ethernet/netronome/nfp/flower/main.c | 1 +
The original code didn't handle non-IPv4 packets very well, so the
offload advertising had to be scaled back down to just IP. Here we
add the bits needed to support TCP and UDP packets over IPv6 and
turn the offload advertising back on.
Orabug: 26289579
Signed-off-by: Shannon Nelson
---
driver
| From: Andrew Lunn
| Sent: Thursday, July 6, 2017 4:15 PM
|
| > Even this feels too extreme for me. I think users would hate it. They
| > did an ifup and swapped cables. They expect the OS/Driver/Firmware
| > to continue trying to honor their ifup request.
|
| Lets take a look around at
On Fri, 7 Jul 2017 01:15:50 +0200, Andrew Lunn wrote:
> > Even this feels too extreme for me. I think users would hate it. They
> > did an ifup and swapped cables. They expect the OS/Driver/Firmware
> > to continue trying to honor their ifup request.
>
> Lets take a look around at other subsy
> Even this feels too extreme for me. I think users would hate it. They
> did an ifup and swapped cables. They expect the OS/Driver/Firmware
> to continue trying to honor their ifup request.
Lets take a look around at other subsystems
What happens if you hot-unplug a SATA drive?
An MMC car
| From: Jakub Kicinski
| Sent: Thursday, July 6, 2017 3:43 PM
|
| On Thu, 6 Jul 2017 21:53:46 +, Casey Leedom wrote:
| >
| > But, and far more importantly, ideally _*ANY*_ such decision is made at an
| > architectural level to apply to all Link Parameters and Vendor Products.
| > The las
| From: Andrew Lunn
| Sent: Thursday, July 6, 2017 3:33 PM
|
| On Thu, Jul 06, 2017 at 09:53:46PM +, Casey Leedom wrote:
| >
| > But, and far more importantly, ideally _*ANY*_ such decision is made at an
| > architectural level to apply to all Link Parameters and Vendor Products.
| > The
On Thu, 6 Jul 2017 21:53:46 +, Casey Leedom wrote:
> | From: Jakub Kicinski
> | Sent: Thursday, July 6, 2017 12:02 PM
> |
> | IMHO if something gets replugged all the settings should be reset.
> | I feel that it's not entirely unlike replugging a USB adapter. Perhaps
> | we should introduce s
| From: Wyborny, Carolyn
| Sent: Thursday, July 6, 2017 3:16 PM
|
| Agree with your points generally, but other networking hw vendors have
| dealt with this since SFP variant and other modules arrived on the scene.
The only case of this of which I'm aware is the SFP+ RJ45 1Gb/s
Transceiver Modu
> Agree with your points generally, but other networking hw vendors
> have dealt with this since SFP variant and other modules arrived on
> the scene.
It seems like there is interest now in consolidating this, in the same
way that copper PHYs got consolidated. Yes, there are some MAC drivers
which
On Thu, Jul 06, 2017 at 09:53:46PM +, Casey Leedom wrote:
> | From: Jakub Kicinski
> | Sent: Thursday, July 6, 2017 12:02 PM
> |
> | IMHO if something gets replugged all the settings should be reset.
> | I feel that it's not entirely unlike replugging a USB adapter. Perhaps
> | we should intr
> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Casey Leedom
> Sent: Thursday, July 06, 2017 2:54 PM
> To: Jakub Kicinski
> Cc: Dustin Byford ; Andrew Lunn
> ; Roopa Prabhu ;
> da...@davemloft.net; linvi...@tuxdriver.com; netd
As Hongjun/Nicolas summarized in their original patch:
"
When a device changes from one netns to another, it's first unregistered,
then the netns reference is updated and the dev is registered in the new
netns. Thus, when a slave moves to another netns, it is first
unregistered. This triggers a NE
This fixes the following kernel warning:
[ 5668.771453] BUG: spinlock bad magic on CPU#0, kworker/u2:3/9745
[ 5668.771850] lock: 0xce63ef20, .magic: , .owner: /-1,
.owner_cpu: 0
[ 5668.772277] CPU: 0 PID: 9745 Comm: kworker/u2:3 Tainted: GW
4.12.0-03002-gec979a4-dirty #4
| From: Jakub Kicinski
| Sent: Thursday, July 6, 2017 12:02 PM
|
| IMHO if something gets replugged all the settings should be reset.
| I feel that it's not entirely unlike replugging a USB adapter. Perhaps
| we should introduce some (devlink) notifications for SFP module events
| so userspace ca
On 07/06/2017 04:00 AM, Arkadi Sharshevsky wrote:
>
>
> On 07/05/2017 10:45 PM, Florian Fainelli wrote:
>> On 07/05/2017 08:36 AM, Arkadi Sharshevsky wrote:
>>> The bridge port attributes/vlan for DSA devices should be set only
>>> from bridge code. Furthermore, The vlans are synced totally with
Edward Cree via iovisor-dev wrote:
> Tracks value alignment by means of tracking known & unknown bits.
> Tightens some min/max value checks and fixes a couple of bugs therein.
> If pointer leaks are allowed, and adjust_ptr_min_max_vals returns -EACCES,
> treat the pointer as an unknown scalar and
> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Jakub Kicinski
> Sent: Thursday, July 06, 2017 12:02 PM
> To: Casey Leedom
> Cc: Dustin Byford ; Andrew Lunn
> ; Roopa Prabhu ;
> da...@davemloft.net; linvi...@tuxdriver.com; net
On Thu, Jul 06, 2017 at 08:45:59PM +0200, Manfred Spraul wrote:
> Hi Paul,
>
> On 07/06/2017 01:31 AM, Paul E. McKenney wrote:
> >From: Manfred Spraul
> >
> >As we want to remove spin_unlock_wait() and replace it with explicit
> >spin_lock()/spin_unlock() calls, we can use this to simplify the
>
On 06/28/2017 10:13 AM, thor.tha...@linux.intel.com wrote:
From: Thor Thayer
The commit fbf68229ffe7 ("net: stmmac: unify registers dumps methods")
in the Linux kernel modified the register dump to store the DMA registers
at the DMA register offset (0x1000) but ethtool (stmmac.c) looks for the
With gcc 4.1.2:
drivers/net/wireless/ath/ath10k/sdio.c: In function
‘ath10k_sdio_mbox_rxmsg_pending_handler’:
drivers/net/wireless/ath/ath10k/sdio.c:676: warning: ‘ret’ may be used
uninitialized in this function
+
+ *done = true;
+
+ /* Copy the lookahead obtained from the HTC regis
On Thu, 6 Jul 2017, Peter Zijlstra wrote:
> On Thu, Jul 06, 2017 at 12:49:12PM -0400, Alan Stern wrote:
> > On Thu, 6 Jul 2017, Paul E. McKenney wrote:
> >
> > > On Thu, Jul 06, 2017 at 06:10:47PM +0200, Peter Zijlstra wrote:
> > > > On Thu, Jul 06, 2017 at 08:21:10AM -0700, Paul E. McKenney wrot
On Thu, 6 Jul 2017 18:53:42 +, Casey Leedom wrote:
> However, the first question which pops up is: what happens if a user
> explicitly selects a particular FEC for from the set offered by the
> current Transceiver Module, and then swap out Transceiver Modules to
> one which doesn't support that
| From: Jakub Kicinski
| Sent: Wednesday, June 28, 2017 6:00 PM
|
| On Wed, 28 Jun 2017 14:47:51 -0700, Dustin Byford wrote:
| >
| > You're not the first, or the second to ask that question. I agree it
| > could use clarification.
| >
| > I always read auto in this context as automatic rat
Hi Arkadi,
Florian Fainelli writes:
> On 07/05/2017 08:36 AM, Arkadi Sharshevsky wrote:
>> This workqueue will be used for FDB add/del processing. It should
>> be destroyed after all devices unregistered successfully.
>>
>> Signed-off-by: Arkadi Sharshevsky
>> ---
>> include/net/dsa.h | 1 +
Hi Paul,
On 07/06/2017 01:31 AM, Paul E. McKenney wrote:
From: Manfred Spraul
As we want to remove spin_unlock_wait() and replace it with explicit
spin_lock()/spin_unlock() calls, we can use this to simplify the
locking.
In addition:
- Reading nf_conntrack_locks_all needs ACQUIRE memory order
Arkadi Sharshevsky writes:
> Currently, the switchdev objects are embedded inside the DSA notifier
> info. This patch removes this dependency. This is done as a preparation
> stage before adding support for learning FDB through the switchdev
> notification chain.
>
> Signed-off-by: Arkadi Sharshe
Hi Alan,
On 07/03/2017 09:57 PM, Alan Stern wrote:
(Alternatively, you could make nf_conntrack_all_unlock() do a
lock+unlock on all the locks in the array, just like
nf_conntrack_all_lock(). But of course, that would be a lot less
efficient.)
H.
Someone with a weakly ordered system who c
On Wed, Jul 5, 2017 at 4:01 PM, Mahesh Bandewar (महेश बंडेवार)
wrote:
>
> Now that you have made me aware of some use cases that do want the
> loopback device to be DOWN, could we use a global sysctl to dictate
> the loopback behavior during init? e.g.
Yeah, it is never about which way is better,
On 04/07/17 23:28, Daniel Borkmann wrote:
> Have you tried with cilium's BPF code? The kernel selftests are quite small,
> so not really pushing processed insns too far. I can send you a BPF obj file
> if that's easier for testing.
Results from the next (in-progress) version of the patch series, wi
Arkadi Sharshevsky writes:
> The prepare phase for FDB add is unneeded because most of DSA devices
> can have failures during bus transactions (SPI, I2C, etc.), thus, the
> prepare phase cannot guarantee success of the commit stage.
>
> The support for learning FDB through notification chain, whi
On Thu, Jul 6, 2017 at 5:08 AM, Nicolas Dichtel
wrote:
> Le 06/07/2017 à 00:43, Cong Wang a écrit :
>> On Wed, Jul 5, 2017 at 8:57 AM, Nicolas Dichtel
>> wrote:
>>> When a device changes from one netns to another, it's first unregistered,
>>> then the netns reference is updated and the dev is reg
On Thu, Jul 6, 2017 at 10:43 AM, David Miller wrote:
> From: Willem de Bruijn
> Date: Wed, 5 Jul 2017 12:27:11 -0400
>
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -21,7 +21,7 @@ static struct sk_buff *__skb_udp_tunnel_segment(struct
sk_buff *skb,
On Thu, Jul 6, 2017 at 1:24 AM, Eric Dumazet wrote:
> On Wed, 2017-07-05 at 13:50 -0700, Cong Wang wrote:
>> We are not allowed to block on the RCU reader side, so can't
>> just hold the mutex as before. As a quick fix, convert it to
>> a spinlock.
>>
>> Fixes: d9f1f61c0801 ("tap: Extending tap de
On Thu, Jul 6, 2017 at 5:18 AM, Eric W. Biederman wrote:
> "Mahesh Bandewar (महेश बंडेवार)" writes:
>
>>> I wonder if it is too late to change this since this behavior is probably
>>> from the beginning of network namespace. A networkless netns is also
>>> useful at least for testing purpose, we
Add SoC specific compatibility strings to the Broadcom DTE
based PTP clock binding document.
Fixed the document heading and node name.
Fixes: 80d6076140b2 ("dt-binding: ptp: add bindings document for dte based ptp
clock")
Signed-off-by: Arun Parameswaran
---
Documentation/devicetree/bindings/p
On Thu, Jul 06, 2017 at 06:08:50PM +0100, Will Deacon wrote:
> On Thu, Jul 06, 2017 at 06:50:36PM +0200, Peter Zijlstra wrote:
> > On Thu, Jul 06, 2017 at 09:20:24AM -0700, Paul E. McKenney wrote:
> > > On Thu, Jul 06, 2017 at 06:05:55PM +0200, Peter Zijlstra wrote:
> > > > On Thu, Jul 06, 2017 at
On Thu, Jul 06, 2017 at 06:50:36PM +0200, Peter Zijlstra wrote:
> On Thu, Jul 06, 2017 at 09:20:24AM -0700, Paul E. McKenney wrote:
> > On Thu, Jul 06, 2017 at 06:05:55PM +0200, Peter Zijlstra wrote:
> > > On Thu, Jul 06, 2017 at 02:12:24PM +, David Laight wrote:
> > > > From: Paul E. McKenney
On Thu, Jul 06, 2017 at 08:58:51PM +0800, Ding Tianhong wrote:
> Hi Bjorn:
>
> Could you please give some feedback about this patchset, it looks like no
> more comments for more than a week,
> thanks. :)
I was on vacation when you posted it, but don't worry, it's still in
the queue:
https://p
On Thu, Jul 06, 2017 at 03:55:28PM +0800, Jeffy Chen wrote:
> We inited wakeup info at the beginning of mwifiex_add_card, so we need
> to uninit it in the error handling.
>
> It's much the same as what we did in:
> 36908c4 mwifiex: uninit wakeup info when removing device
>
> Signed-off-by: Jeffy
On Thu, Jul 06, 2017 at 03:50:33PM +0800, Shawn Lin wrote:
> We got a compile warning shows below:
>
> drivers/net/wireless/marvell/mwifiex/sdio.c: In function
> 'mwifiex_sdio_remove':
> drivers/net/wireless/marvell/mwifiex/sdio.c:377:6: warning: variable
> 'ret' set but not used [-Wunused-but-set
On Thu, Jul 06, 2017 at 06:50:36PM +0200, Peter Zijlstra wrote:
> On Thu, Jul 06, 2017 at 09:20:24AM -0700, Paul E. McKenney wrote:
> > On Thu, Jul 06, 2017 at 06:05:55PM +0200, Peter Zijlstra wrote:
> > > On Thu, Jul 06, 2017 at 02:12:24PM +, David Laight wrote:
> > > > From: Paul E. McKenney
On Thu, Jul 06, 2017 at 06:41:34PM +0200, Peter Zijlstra wrote:
> On Thu, Jul 06, 2017 at 09:24:12AM -0700, Paul E. McKenney wrote:
> > On Thu, Jul 06, 2017 at 06:10:47PM +0200, Peter Zijlstra wrote:
> > > On Thu, Jul 06, 2017 at 08:21:10AM -0700, Paul E. McKenney wrote:
> > > > And yes, there are
On Thu, Jul 06, 2017 at 12:49:12PM -0400, Alan Stern wrote:
> On Thu, 6 Jul 2017, Paul E. McKenney wrote:
>
> > On Thu, Jul 06, 2017 at 06:10:47PM +0200, Peter Zijlstra wrote:
> > > On Thu, Jul 06, 2017 at 08:21:10AM -0700, Paul E. McKenney wrote:
> > > > And yes, there are architecture-specific o
On Thu, Jul 06, 2017 at 09:20:24AM -0700, Paul E. McKenney wrote:
> On Thu, Jul 06, 2017 at 06:05:55PM +0200, Peter Zijlstra wrote:
> > On Thu, Jul 06, 2017 at 02:12:24PM +, David Laight wrote:
> > > From: Paul E. McKenney
>
> [ . . . ]
>
> > Now on the one hand I feel like Oleg that it would
On Thu, 6 Jul 2017, Paul E. McKenney wrote:
> On Thu, Jul 06, 2017 at 06:10:47PM +0200, Peter Zijlstra wrote:
> > On Thu, Jul 06, 2017 at 08:21:10AM -0700, Paul E. McKenney wrote:
> > > And yes, there are architecture-specific optimizations for an
> > > empty spin_lock()/spin_unlock() critical sec
On 7/6/2017 8:15 AM, Sowmini Varadhan wrote:
There are two problems with calling sock_create_kern() from
rds_tcp_accept_one()
1. it sets up a new_sock->sk that is wasteful, because this ->sk
is going to get replaced by inet_accept() in the subsequent ->accept()
2. The new_sock->sk is a leaked
On Thu, Jul 06, 2017 at 09:24:12AM -0700, Paul E. McKenney wrote:
> On Thu, Jul 06, 2017 at 06:10:47PM +0200, Peter Zijlstra wrote:
> > On Thu, Jul 06, 2017 at 08:21:10AM -0700, Paul E. McKenney wrote:
> > > And yes, there are architecture-specific optimizations for an
> > > empty spin_lock()/spin_
On Thu, Jul 06, 2017 at 06:10:47PM +0200, Peter Zijlstra wrote:
> On Thu, Jul 06, 2017 at 08:21:10AM -0700, Paul E. McKenney wrote:
> > And yes, there are architecture-specific optimizations for an
> > empty spin_lock()/spin_unlock() critical section, and the current
> > arch_spin_unlock_wait() imp
On Thu, Jul 06, 2017 at 06:05:55PM +0200, Peter Zijlstra wrote:
> On Thu, Jul 06, 2017 at 02:12:24PM +, David Laight wrote:
> > From: Paul E. McKenney
[ . . . ]
> Now on the one hand I feel like Oleg that it would be a shame to loose
> the optimization, OTOH this thing is really really tricky
On Thu, Jul 06, 2017 at 08:21:10AM -0700, Paul E. McKenney wrote:
> And yes, there are architecture-specific optimizations for an
> empty spin_lock()/spin_unlock() critical section, and the current
> arch_spin_unlock_wait() implementations show some of these optimizations.
> But I expect that perfo
On Thu, Jul 06, 2017 at 02:12:24PM +, David Laight wrote:
> From: Paul E. McKenney
> > Sent: 06 July 2017 00:30
> > There is no agreed-upon definition of spin_unlock_wait()'s semantics,
> > and it appears that all callers could do just as well with a lock/unlock
> > pair. This series therefore
From: Nikolay Aleksandrov
Date: Thu, 6 Jul 2017 15:24:40 +0300
> When destroying a VRF device we cleanup the slaves in its ndo_uninit()
> function, but that causes packets to be switched (skb->dev == vrf being
> destroyed) even though we're pass the point where the VRF should be
> receiving any
On 7/6/17 6:24 AM, Nikolay Aleksandrov wrote:
> When destroying a VRF device we cleanup the slaves in its ndo_uninit()
> function, but that causes packets to be switched (skb->dev == vrf being
> destroyed) even though we're pass the point where the VRF should be
> receiving any packets while it is
> -Original Message-
> From: Greg Rose [mailto:gvrose8...@gmail.com]
> Sent: Thursday, July 06, 2017 7:25 AM
> To: Wyborny, Carolyn
> Cc: Stefan Assmann ; intel-wired-...@lists.osuosl.org;
> netdev@vger.kernel.org; da...@davemloft.net
> Subject: Re: [Intel-wired-lan] [PATCH 1/2] i40e/i40ev
On Thu, Jul 06, 2017 at 02:12:24PM +, David Laight wrote:
> From: Paul E. McKenney
> > Sent: 06 July 2017 00:30
> > There is no agreed-upon definition of spin_unlock_wait()'s semantics,
> > and it appears that all callers could do just as well with a lock/unlock
> > pair. This series therefore
There are two problems with calling sock_create_kern() from
rds_tcp_accept_one()
1. it sets up a new_sock->sk that is wasteful, because this ->sk
is going to get replaced by inet_accept() in the subsequent ->accept()
2. The new_sock->sk is a leaked reference in sock_graft() which
expects to f
sock_graft() unilaterally sets up parent->sk based on the
assumption that the existing parent->sk is null. If this
condition is not true, then the existing parent->sk would
be leaked, so add a WARN_ON() to alert callers who may fall
in this category.
Signed-off-by: Sowmini Varadhan
---
include/n
Following up on the discussion at
https://www.spinics.net/lists/netdev/msg442859.html
- make rds_tcp_accept_one() call sock_create_lite()
- add a WARN_ON() to sock_graft()
Tested by running an infinite while() loop that does
(module-load; rds-stress; module-unload) and monitors
TCP slabinfo whi
Hi Richard,
On 07/06/17 04:30 PM, Richard Weinberger wrote:
> Dave,
>
> On Wed, Jun 14, 2017 at 8:36 PM, Dave Watson wrote:
> > Documentation/networking/tls.txt | 135 +++
> > MAINTAINERS| 10 +
> > include/linux/socket.h | 1 +
> > include/net/inet
From: Willem de Bruijn
Date: Wed, 5 Jul 2017 12:27:11 -0400
>>> --- a/net/ipv4/udp_offload.c
>>> +++ b/net/ipv4/udp_offload.c
>>> @@ -21,7 +21,7 @@ static struct sk_buff *__skb_udp_tunnel_segment(struct
>>> sk_buff *skb,
>>> __be16 new_protocol, bool is_ipv6)
>>
>> In this file, can now
On 07/06/2017 03:55 PM, Andrew Lunn wrote:
>> diff --git a/Documentation/devicetree/bindings/net/fsl-fec.txt
>> b/Documentation/devicetree/bindings/net/fsl-fec.txt
>> index 6f55bdd..1766579 100644
>> --- a/Documentation/devicetree/bindings/net/fsl-fec.txt
>> +++ b/Documentation/devicetree/binding
Dave,
On Wed, Jun 14, 2017 at 8:36 PM, Dave Watson wrote:
> Documentation/networking/tls.txt | 135 +++
> MAINTAINERS| 10 +
> include/linux/socket.h | 1 +
> include/net/inet_connection_sock.h | 4 +
> include/net/tcp.h | 27 ++
>
On Thu, Jul 6, 2017 at 4:24 PM, Jason A. Donenfeld wrote:
>
> if (!ret)
> pr_info("Yay it worked!\n");
>
> return 0;
This is supposed to be `return ret;`. See, even in psuedocode it's
hard to get right.
Hey guys,
I see why this priv_destructor patch is an acceptable bandaid for
certain drivers, but I'm not exactly sure on the cleanest way of using
it in new drivers. Check out the following psuedocode.
Here's how error handling in newlink used to work before this patch:
static void destruct(stru
On Wed, Jul 5, 2017 at 10:15 PM, Wyborny, Carolyn
wrote:
>
> > -Original Message-
> > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf
> > Of Stefan Assmann
> > Sent: Thursday, June 29, 2017 6:12 AM
> > To: intel-wired-...@lists.osuosl.org
> > Cc: netdev@vger.ker
From: Willem de Bruijn
Date: Wed, 5 Jul 2017 13:21:02 -0400
> On Wed, Jul 5, 2017 at 12:06 PM, Willem de Bruijn
> wrote:
>>> diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
>>> index 5209b5e..32fb046 100644
>>> --- a/include/linux/virtio_net.h
>>> +++ b/include/linux/virtio_
From: Paul E. McKenney
> Sent: 06 July 2017 00:30
> There is no agreed-upon definition of spin_unlock_wait()'s semantics,
> and it appears that all callers could do just as well with a lock/unlock
> pair. This series therefore removes spin_unlock_wait() and changes
> its users to instead use a loc
On 04/07/17 20:22, Edward Cree wrote:
> I don't know why test_l4lb has to process _fewer_ insns with my patches;
> if anything I'm worrying that I may be incorrectly pruning branches.
> (I've spotted a possible bug in that I'm not looking at 'id' which,
> although it doesn't have to match, if two
As I understand it, the patch will be available in the linux kernel or as a
separate application based on tap?
06.07.2017, 16:21, "Vincent JARDIN" :
> Le 06/07/2017 à 11:13, Алексей Болдырев a écrit :
>> Is there any plan for developing mpls pseudowire dliver for linux. And
>> also, is it possi
Hi Richard
> diff --git a/Documentation/devicetree/bindings/net/fsl-fec.txt
> b/Documentation/devicetree/bindings/net/fsl-fec.txt
> index 6f55bdd..1766579 100644
> --- a/Documentation/devicetree/bindings/net/fsl-fec.txt
> +++ b/Documentation/devicetree/bindings/net/fsl-fec.txt
> @@ -23,6 +23,9 @@
Andrei Vagin writes:
> I did a few experiments and found that the bug is reproduced for 6-12
> hours on the our test server. Then I reverted two patches and the server
> is working normally for more than 24 hours already, so the bug is
> probably in one of these patches.
>
> commit e3d0065ab8535c
On Thu, Jul 06, 2017 at 10:50:11AM +0200, Alvaro Gamez Machado wrote:
> Keep supporting proprietary "xlnx,phy-type" attribute and add support for
> MII connectivity to the PHY.
Hi Alvaro
Thanks for picking this up.
>
> Signed-off-by: Alvaro Gamez Machado
> ---
> drivers/net/ethernet/xilinx/xi
Le 06/07/2017 à 11:13, Алексей Болдырев a écrit :
Is there any plan for developing mpls pseudowire dliver for linux. And also, is
it possible to write a driver for MPLS pseudowire on the basis of tun / tap?
We are working on a RFC patch that should be available soon.
They'll be tested with FR
The fec_reset_phy function allowed only one execution during probeing.
As a preparation for future patches move the dt parsing and gpio
allocation to the probe function. The parameters of the phy reset are
added to the fec_enet_private struct. As a result the fec_reset_phy
function may be called an
Some PHYs (for example the LAN8710) doesn't allow turning the clocks off
and on again without reset (according to their datasheet). Exactly this
behaviour was introduced for power saving reasons by commit e8fcfcd5684a
("net: fec: optimize the clock management to save power")
Therefore add a devictr
On 07/05/2017 10:35 PM, Florian Fainelli wrote:
> On 07/05/2017 08:36 AM, Arkadi Sharshevsky wrote:
>> Add support for learning FDB through notification. The driver defers
>> the hardware update via ordered work queue. In case of a successful
>> FDB add a notification is sent back to bridge.
>>
>
From: Pablo Neira Ayuso
Date: Thu, 6 Jul 2017 14:54:23 +0200
> The following patchset contains two Netfilter fixes for your net tree,
> they are:
>
> 1) Fix memleak from netns release path of conntrack protocol trackers,
>patch from Liping Zhang.
>
> 2) Uninitialized flags field in ebt_log
Hi Bjorn:
Could you please give some feedback about this patchset, it looks like no more
comments for more than a week,
thanks. :)
Ding
On 2017/6/29 13:47, Ding Tianhong wrote:
> ping
>
> On 2017/6/22 20:15, Ding Tianhong wrote:
>> Some devices have problems with Transaction Layer Packets with
Hi David,
The following patchset contains two Netfilter fixes for your net tree,
they are:
1) Fix memleak from netns release path of conntrack protocol trackers,
patch from Liping Zhang.
2) Uninitialized flags field in ebt_log, that results in unpredictable
logging format in ebtables, also
From: Liping Zhang
After running the following commands for a while, kmemleak reported that
"1879 new suspected memory leaks" happened:
# while : ; do
ip netns add test
ip netns delete test
done
unreferenced object 0x88006342fa38 (size 1024):
comm "ip", pid 15477, jiffies 4295982
From: Liping Zhang
"struct nf_loginfo li;" is a local variable, so we should set the flags
to 0 explicitly, else, packets maybe truncated unexpectedly when copied
to the userspace.
Fixes: 7643507fe8b5 ("netfilter: xt_NFLOG: nflog-range does not truncate
packets")
Cc: Vishwanath Pai
Signed-off-
"Mahesh Bandewar (महेश बंडेवार)" writes:
>> I wonder if it is too late to change this since this behavior is probably
>> from the beginning of network namespace. A networkless netns is also
>> useful at least for testing purpose, we do use it as a sandbox.
>>
> Sandbox is my use case too but i'm
When destroying a VRF device we cleanup the slaves in its ndo_uninit()
function, but that causes packets to be switched (skb->dev == vrf being
destroyed) even though we're pass the point where the VRF should be
receiving any packets while it is being dismantled. This causes a BUG_ON
to trigger if w
Le 06/07/2017 à 00:43, Cong Wang a écrit :
> On Wed, Jul 5, 2017 at 8:57 AM, Nicolas Dichtel
> wrote:
>> When a device changes from one netns to another, it's first unregistered,
>> then the netns reference is updated and the dev is registered in the new
>> netns. Thus, when a slave moves to anoth
On 07/05/2017 10:45 PM, Florian Fainelli wrote:
> On 07/05/2017 08:36 AM, Arkadi Sharshevsky wrote:
>> The bridge port attributes/vlan for DSA devices should be set only
>> from bridge code. Furthermore, The vlans are synced totally with the
>> bridge so there is no need for special dump support.
From: Geert Uytterhoeven
Date: Thu, 6 Jul 2017 10:34:54 +0200
> With gcc 4.1.2:
>
> drivers/ptp/ptp_dte.c: In function ‘dte_write_nco_delta’:
> drivers/ptp/ptp_dte.c:105: warning: integer constant is too large for
> ‘long’ type
> drivers/ptp/ptp_dte.c:112: warning: integer constant
From: Zheng Li
Date: Thu, 6 Jul 2017 15:00:09 +0800
> From: Zheng Li
>
> if there are several same route entries with different outgoing net device,
> application's socket specifies the oif through setsockopt with
> SO_BINDTODEVICE, sctpv6 should choose the route entry whose outgoing net
> dev
Hi Corentin,
On Thu, Jul 6, 2017 at 5:45 PM, David Miller wrote:
> From: Corentin Labbe
> Date: Thu, 6 Jul 2017 10:51:47 +0200
>
>> On Sun, Jul 02, 2017 at 02:31:59PM +0200, Corentin Labbe wrote:
>>> Since internal phy-mode is reserved for non-xMII protocol we cannot use
>>> it with dwmac-sun8i
From: Matthias Rosenfelder
Date: Thu, 6 Jul 2017 00:56:36 -0400
> copy_to_user() copies the struct the pointer is pointing to, but the
> length check compares against sizeof(pointer) and not sizeof(struct).
> On 32-bit the size is probably the same, so it might have worked
> accidentally.
>
> Si
From: Stephen Rothwell
Date: Thu, 6 Jul 2017 10:27:12 +1000
> Hi,
>
> Not sure why you sent this to me ... it fixes a commit in the net-next
> tree (now in Linus' tree) ...
>
> On Thu, 6 Jul 2017 07:58:53 +0800 kbuild test robot
> wrote:
>>
>> Fixes: 0c5f0311f690 ("Add linux-next specific fil
1 - 100 of 143 matches
Mail list logo
