On 11/24/2016 05:11 PM, Chris Paterson wrote:
> This series adds support for r8a7796 to rcar_can and rcar_canfd.
>
> Original series: [PATCH 0/3] arm64: dts: r8a7796: Add CAN/CAN FD support.
>
> Changes since v1:
> - Split bindings documentation changes from device tree changes.
> - Rebased on re
Mr. Steve Bhatti,
Drift / regionsjef
Santander Bank Plc,
47-48 Piccadilly
PICCADILLY
W1J0DT
London, Storbritannia
Good Day Kjære,
Hvordan har du og familien det? Jeg håper mitt brev møter deg i ditt beste
humør i dag. Jeg er Dr. Steve Bhatti, fra Harlesden North West London, leder
for regnskap
1) Fix a refcount leak in vti6.
From Nicolas Dichtel.
2) Fix a wrong if statement in xfrm_sk_policy_lookup.
From Florian Westphal.
3) The flowcache watermarks are per cpu. Take this into
account when comparing to the threshold where we
refusing new allocations. From Miroslav Urbanek.
From: Miroslav Urbanek
The threshold for OOM protection is too small for systems with large
number of CPUs. Applications report ENOBUFs on connect() every 10
minutes.
The problem is that the variable net->xfrm.flow_cache_gc_count is a
global counter while the variable fc->high_watermark is a per
From: Nicolas Dichtel
This is the same fix than commit a5d0dc810abf ("vti: flush x-netns xfrm
cache when vti interface is removed")
This patch fixes a refcnt problem when a x-netns vti6 interface is removed:
unregister_netdevice: waiting for vti6_test to become free. Usage count = 1
Here is a s
From: Florian Westphal
if we succeed grabbing the refcount, then
if (err && !xfrm_pol_hold_rcu)
will evaluate to false so this hits last else branch which then
sets policy to ERR_PTR(0).
Fixes: ae33786f73a7ce ("xfrm: policy: only use rcu in xfrm_sk_policy_lookup")
Reported-by: Nicolas Dichtel
> Mark Lord [mailto:ml...@pobox.com]
> > Sent: Friday, November 25, 2016 12:44 AM
> [...]
> > The bad data in this case is ASCII:
> >
> > "SRC=m3400:/ TARGET=/m340"
> >
> > This data is what is seen in /run/mount/utab, a file that is read/written
> > over NFS
> on
> > each boot.
> >
> >
Mark Lord [mailto:ml...@pobox.com]
> Sent: Friday, November 25, 2016 12:44 AM
[...]
> The bad data in this case is ASCII:
>
> "SRC=m3400:/ TARGET=/m340"
>
> This data is what is seen in /run/mount/utab, a file that is read/written
> over NFS on
> each boot.
>
> "SRC=m3400:/ TA
On Thu, Nov 24, 2016 at 4:17 PM, Daniel Borkmann wrote:
>
>
> I'm not sure if setting a dummy object for each affected classifier is
> making things better. Are you having this in mind as a target for -net?
>
> We do kfree_rcu() the head (tp->root) and likewise do we kfree_rcu() the
> tp immediate
Hi Eric,
On Thu, 24 Nov 2016 19:54:04 -0800 Eric Dumazet wrote:
>
> Could you now report :
>
> ethtool -k eth0
Features for eth0:
rx-checksumming: on
tx-checksumming: on
tx-checksum-ipv4: off [fixed]
tx-checksum-ip-generic: on
tx-checksum-ipv6: off [fixed]
tx-c
Mark Lord [mailto:ml...@pobox.com]
> Sent: Thursday, November 24, 2016 11:25 PM
[...]
> x86 has near fully-coherent memory, so it is the "easy" platform
> to get things working on. But Linux supports a very diverse number
> of platforms, with varying degrees of cache/memory coherency,
> and it can
Hi Stephen,
On 2016/11/25 10:45, Stephen Rothwell wrote:
> Hi Eli,
>
> On Fri, 25 Nov 2016 10:18:12 +0800 Eli Cooper wrote:
>> Sounds like TSO/GSO packets are not properly segmented and therefore
>> dropped.
>>
>> Could you first try turning off segmentation offloading for the tunnel
>> interface
Similar to commit ae148b085876
("ip6_tunnel: Update skb->protocol to ETH_P_IPV6 in ip6_tnl_xmit()"),
sit tunnels also need to update skb->protocol; otherwise, TSO/GSO packets
might not be properly segmented, which causes the packets being dropped.
Reported-by: Stephen Rothwell
Tested-by: Eli Coop
>Bug is in the RFC for not describing how both ends would magically
>synchronize, with a sequence protocol which is unidirectional, with no ACK
>packets or whatever going back.
>With no description, it means that RFC author(s) never considered one side of
>the tunnel could die and restart.
>Cont
Yeah you got it. Great!!!
On Thu, Nov 24, 2016 at 9:11 PM, Liyang Yu (于立洋1) wrote:
>> Please test my patch since you can reproduce it.
>
> Thanks cong, but Eric had said: "Really, this is not something that
> can be solved by using 'a different initial sequence number'"
> So I do
On Thu, Nov 24, 2016 at 9:11 PM, Liyang Yu (于立洋1) wrote:
>> Please test my patch since you can reproduce it.
>
> Thanks cong, but Eric had said: "Really, this is not something that
> can be solved by using 'a different initial sequence number'"
> So I don't think it's nessary to t
On 2016年11月25日 12:43, Michael S. Tsirkin wrote:
On Fri, Nov 25, 2016 at 12:37:26PM +0800, Jason Wang wrote:
>We use single queue even if multiqueue is enabled and let admin to
>enable it through ethtool later. This is used to avoid possible
>regression (small packet TCP stream transmission). B
On Fri, Nov 25, 2016 at 12:37:26PM +0800, Jason Wang wrote:
> We use single queue even if multiqueue is enabled and let admin to
> enable it through ethtool later. This is used to avoid possible
> regression (small packet TCP stream transmission). But looks like an
> overkill since:
>
> - single q
We use single queue even if multiqueue is enabled and let admin to
enable it through ethtool later. This is used to avoid possible
regression (small packet TCP stream transmission). But looks like an
overkill since:
- single queue user can disable multiqueue when launching qemu
- brings extra trou
On Fri, 25 Nov 2016, Stephen Rothwell wrote:
> On Fri, 25 Nov 2016 10:18:12 +0800 Eli Cooper wrote:
> >
> > Sounds like TSO/GSO packets are not properly segmented and therefore
> > dropped.
> >
> > Could you first try turning off segmentation offloading for the tunnel
> > interface?
> > etht
On Thu, Nov 24, 2016 at 7:52 PM, Liyang Yu (于立洋1) wrote:
> I accept that the issue is not a CVE candidate. But it's a bug isn't it
Bug is in the RFC for not describing how both ends would magically synchronize,
with a sequence protocol which is unidirectional, with no ACK packets
or whatever go
On Thu, Nov 24, 2016 at 5:39 PM, Liyang Yu (于立洋1) wrote:
> BTW:
>
>Which RFC suggests UINT_MAX as GRE sequence number? Can you show me?
https://tools.ietf.org/html/rfc2890
"The receiver maintains the sequence number value of the last successfully
decapsulated packet. Upon establishment of
On Fri, 2016-11-25 at 14:09 +1100, Stephen Rothwell wrote:
> Hi Eric,
>
> On Thu, 24 Nov 2016 19:01:28 -0800 Eric Dumazet
> wrote:
> >
> > Since I do not have this problem at all on my hosts, it could be a buggy
> > ethernet driver.
> >
> > Could you share what NIC card and driver you are using
I accept that the issue is not a CVE candidate. But it's a bug isn't it
Thank you for your suggestions, about the format of mail, and not next time.
Everything has its meaning. If sequence number is a joke, why the guys put it
into RFC , even implemented the feature.
And if you means that
On 16-11-24 07:27 PM, Francois Romieu wrote:
>
> Through aliasing the URB was given a page that contains said (previously)
> received file. The ethernet chip/usb host does not write anything in it.
I don't see how that could be possible. Please elaborate.
The URB buffers are statically allocated
Hi Eric,
On Thu, 24 Nov 2016 19:01:28 -0800 Eric Dumazet wrote:
>
> Since I do not have this problem at all on my hosts, it could be a buggy
> ethernet driver.
>
> Could you share what NIC card and driver you are using ?
# uname -a
Linux bilbo 4.7.0-1-amd64 #1 SMP Debian 4.7.8-1 (2016-10-19) x
On Fri, 2016-11-25 at 13:45 +1100, Stephen Rothwell wrote:
> So turning off tso brings performance up to IPv4 levels ...
ok.
>
> Thanks for that, it solves my immediate problem.
Since I do not have this problem at all on my hosts, it could be a buggy
ethernet driver.
Could you share what NIC
On 2016年11月25日 10:05, f...@48lvckh6395k16k5.yundunddos.com wrote:
From: Gao Feng
The macvtap_newlink registers the netdev rx_handler firstly, but it
does not unregister the handler if macvlan_common_newlink failed.
Signed-off-by: Gao Feng
---
drivers/net/macvtap.c | 8 +++-
1 file ch
Hi Eli,
On Fri, 25 Nov 2016 10:18:12 +0800 Eli Cooper wrote:
>
> Sounds like TSO/GSO packets are not properly segmented and therefore
> dropped.
>
> Could you first try turning off segmentation offloading for the tunnel
> interface?
> ethtool -K sit0 tso off gso off
On Thu, 24 Nov 2016 18:3
On 2016年11月24日 18:25, Mark Rutland wrote:
As a step towards killing off ACCESS_ONCE, use {READ,WRITE}_ONCE() for the
virtio tools uaccess primitives, pulling these in from .
With this done, we can kill off the now-unused ACCESS_ONCE() definition.
Signed-off-by: Mark Rutland
Cc: Jason Wang
C
On 2016年11月24日 18:25, Mark Rutland wrote:
Despite living under drivers/ vringh.c is also used as part of the userspace
virtio tools. Before we can kill off the ACCESS_ONCE()definition in the tools,
we must convert vringh.c to use {READ,WRITE}_ONCE().
This patch does so, along with the required
On 2016年11月24日 18:25, Mark Rutland wrote:
The virtio tools implementation of READ_ONCE() has a single parameter called
'var', but erroneously refers to 'val' for its cast, and thus won't work unless
there's a variable of the correct type that happens to be called 'var'.
Fix this with s/var/val
On Fri, 2016-11-25 at 12:09 +1100, Stephen Rothwell wrote:
> Hi all,
>
> This is a typical user error report i.e. a net well specified one :-)
>
> I am using a 6in4 tunnel from my Linux server at home (since my ISP
> does not provide native IPv6) to another hosted Linus server (that has
> native
On Thu, Nov 24, 2016 at 5:39 PM, Liyang Yu (于立洋1) wrote:
>
>
>
>
>
>
>
> BTW:
>
>Which RFC suggests UINT_MAX as GRE sequence number? Can you show me?
>
>
>
>
>
>
RFC 2890
In any cases, this is absolutely not a security issue nor a CVE candidate.
Please remove secur...@kernel.org from CC, n
Hi Stephen,
On 2016/11/25 9:09, Stephen Rothwell wrote:
> Hi all,
>
> This is a typical user error report i.e. a net well specified one :-)
>
> I am using a 6in4 tunnel from my Linux server at home (since my ISP
> does not provide native IPv6) to another hosted Linus server (that has
> native IPv6
On Thu, Nov 24, 2016 at 09:15:45AM -0700, Jason Gunthorpe wrote:
On Wed, Nov 23, 2016 at 04:08:25PM -0800, Vishwanathapura, Niranjana wrote:
In order to pass the hfi function pointers to the hfi_vnic ULP, I can,
a) Have hfi_vnic ULP define an interface API for hfi1 driver to call to
register it
From: Gao Feng
The macvtap_newlink registers the netdev rx_handler firstly, but it
does not unregister the handler if macvlan_common_newlink failed.
Signed-off-by: Gao Feng
---
drivers/net/macvtap.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/macvtap.
On Thu, Nov 24, 2016 at 10:14:49PM +0100, Stefan Eichenberger wrote:
> Hi David
>
> On Thu, Nov 24, 2016 at 03:29:21PM -0500, David Miller wrote:
> > From: Stefan Eichenberger
> > Date: Tue, 22 Nov 2016 17:47:21 +0100
> >
> > > Add support for the MV88E6097 switch. The change was tested on an Ar
--
Dear Friend,
Good Day, I am Mr. Piyush Gupta as a (DBSHK) banker, I have funds worth
of $25.500,000.00 to secretly secure and transfer in to your account of
my late client who dead with next of kin, which i will like to invest in
profitable business in your country.
Please if you are i
Hi all,
This is a typical user error report i.e. a net well specified one :-)
I am using a 6in4 tunnel from my Linux server at home (since my ISP
does not provide native IPv6) to another hosted Linus server (that has
native IPv6 connectivity). The throughput for IPv6 connections has
dropped from
On Thu, Nov 24, 2016 at 7:55 PM, Florian Fainelli wrote:
> Le 24/11/2016 à 09:05, Martin Blumenstingl a écrit :
>> On Thu, Nov 24, 2016 at 4:56 PM, Jerome Brunet wrote:
>>> On Thu, 2016-11-24 at 15:34 +0100, Martin Blumenstingl wrote:
Currently the dwmac-meson8b stmmac glue driver uses a har
Mark Lord :
[...]
> >From tracing through the powerpc arch code, this is the buffer that
> is being directly DMA'd into. And the USB layer does an invalidate_dcache
> on that entire buffer before initiating the DMA (confirmed via printk).
>
> The driver itself NEVER writes anything to that buffe
On 11/24/2016 09:25 PM, David Miller wrote:
From: Cong Wang
Date: Tue, 22 Nov 2016 11:28:37 -0800
On Tue, Nov 22, 2016 at 8:11 AM, Jiri Pirko wrote:
Tue, Nov 22, 2016 at 05:04:11PM CET, dan...@iogearbox.net wrote:
Hmm, I don't think we want to have such an additional test in fast
path for e
In commit 10724cc7bb78 ("tipc: redesign connection-level flow control")
we replaced the previous message based flow control with one based on
1k blocks. In order to ensure backwards compatibility the mechanism
falls back to using message as base unit when it senses that the peer
doesn't support the
Hi,
this is the second version of the slicoss gigabit ethernet driver (which is a
rework of the driver from Alacritech which can currently be found under
drivers/staging/slicoss). The driver is supposed to support Mojave, Oasis and
Kalahari cards, for both copper and fiber.
If this code is accept
Add driver for Alacritech gigabit ethernet cards with SLIC (session-layer
interface control) technology. The driver provides basic support without
SLIC for the following devices:
- Mojave cards (single port PCI Gigabit) both copper and fiber
- Oasis cards (single and dual port PCI-x Gigabit) coppe
Add myself as maintainer for the slicoss ethernet driver.
Signed-off-by: Lino Sanfilippo
---
MAINTAINERS | 5 +
1 file changed, 5 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6781a3f..bb9af28 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -562,6 +562,11 @@ T: git git://linuxtv.
I just wanna be your friend if you can reply me back, Call me Monica.
On Thu, 2016-11-24 at 22:44 +0100, Pavel Machek wrote:
> On Thu 2016-11-24 12:05:25, Joe Perches wrote:
> > On Thu, 2016-11-24 at 12:05 +0100, Pavel Machek wrote:
> > > Remove duplicate code from _tx routines.
> >
> > trivia:
> >
> > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.
On Thu 2016-11-24 12:05:25, Joe Perches wrote:
> On Thu, 2016-11-24 at 12:05 +0100, Pavel Machek wrote:
> > Remove duplicate code from _tx routines.
>
> trivia:
>
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> > b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> []
> > @
On Thu, 2016-11-24 at 15:42 -0500, David Miller wrote:
> From: Eric Dumazet
> Date: Tue, 22 Nov 2016 10:57:33 -0800
>
> > David, patch is marked 'Superseded' in
> > https://patchwork.ozlabs.org/patch/695264/
> >
> > Not sure what this means exactly ?
> > Did I miss a mail/feedback/something ?
>
Hi!
> >> I'm debugging strange delays during transmit in stmmac driver. They
> >> seem to be present in 4.4 kernel (and older kernels, too). Workload is
> >> burst of udp packets being sent, pause, burst of udp packets, ...
...
> > 4.9-rc6 still has the delays. With the
> >
> > #define STMMAC_COA
From: Johan Hedberg
Date: Wed, 23 Nov 2016 09:29:12 +0200
> Sorry about the late pull request for 4.9, but we have one more
> important Bluetooth patch that should make it to the release. It fixes
> connection creation for Bluetooth LE controllers that do not have a
> public address (only a rando
Hi David
On Thu, Nov 24, 2016 at 03:29:21PM -0500, David Miller wrote:
> From: Stefan Eichenberger
> Date: Tue, 22 Nov 2016 17:47:21 +0100
>
> > Add support for the MV88E6097 switch. The change was tested on an Armada
> > based platform with a MV88E6097 switch.
> >
> > Signed-off-by: Stefan Eic
From: Roman Mashak
Date: Tue, 22 Nov 2016 20:57:04 -0500
> Should pass valid filter handle, not the netlink flags.
>
> Fixes: 30a391a13ab92 ("net sched filters: pass netlink message flags in event
> notification")
> Signed-off-by: Roman Mashak
> Signed-off-by: Jamal Hadi Salim
Applied.
From: Alexei Starovoitov
Date: Tue, 22 Nov 2016 16:52:09 -0800
> llvm can emit relocations into sections other than program code
> (like debug info sections). Ignore them during parsing of elf file
>
> Signed-off-by: Alexei Starovoitov
Applied.
From: Alexei Starovoitov
Date: Tue, 22 Nov 2016 16:52:08 -0800
> since llvm commit "Do not expand UNDEF SDNode during insn selection lowering"
> llvm will generate code that uses uninitialized registers for cases
> where C code is actually uses uninitialized data.
> So this sockex2 example is tec
From: Jason Wang
Date: Wed, 23 Nov 2016 10:26:49 +0800
> After commit 1576d9860599 ("tun: switch to use skb array for tx"),
> sk_receive_queue was not used any more. So remove the uncessary
> sk_receive_queue length check during xmit.
>
> Signed-off-by: Jason Wang
Good catch, applied, thanks J
From: Florian Fainelli
Date: Tue, 22 Nov 2016 13:55:31 -0800
> PHY drivers should be able to rely on the caller of {get,set}_tunable to
> have acquired the PHY device mutex, in order to both serialize against
> concurrent calls of these functions, but also against PHY state machine
> changes. All
From: Eric Dumazet
Date: Tue, 22 Nov 2016 15:56:10 -0800
> From: Eric Dumazet
>
> Goal is to reorganize this critical structure to increase performance.
>
> ndo_start_xmit() should only dirty one cache line, and access as few
> cache lines as possible.
>
> Add sp_ (Slow Path) prefix to fields
From: Saeed Mahameed
Date: Tue, 22 Nov 2016 23:09:53 +0200
> This series from Roi and Or further enhances the new SRIOV switchdev
> mode.
Series applied, thanks.
From: Florian Fainelli
Date: Tue, 22 Nov 2016 11:40:53 -0800
> This patch series adds support for the Broadcom Wirespeed, aka downsfhit
> feature
> utilizing the recently added ethtool PHY tunables.
>
> Tested with two Gigabit link partners with a 4-wire cable having only 2 pairs
> connected.
>
From: Eric Dumazet
Date: Tue, 22 Nov 2016 10:57:33 -0800
> David, patch is marked 'Superseded' in
> https://patchwork.ozlabs.org/patch/695264/
>
> Not sure what this means exactly ?
> Did I miss a mail/feedback/something ?
I must have mistakenly marked it that way, sorry.
Applied to net-next,
From: Andy Gospodarek
Date: Tue, 22 Nov 2016 13:14:08 -0500
> When busy polling while a link is down (during a link-flap test), TX
> timeouts were observed as well as the following messages in the ring
> buffer:
>
> bnxt_en 0008:01:00.2 enP8p1s0f2d2: Resp cmpl intr err msg: 0x51
> bnxt_en 0008:0
On Thu, Nov 24, 2016 at 10:25:11AM +, Mark Rutland wrote:
> For several reasons, it would be beneficial to kill off ACCESS_ONCE()
> tree-wide, in favour of {READ,WRITE}_ONCE(). These work with aggregate types,
> more obviously document their intended behaviour, and are necessary for tools
> lik
On Tue, Nov 22 2016, 07:28 PM, Simon Guinot wrote:
> Hi Amir,
>
> I tested the thunderbolt-icm driver (v9 series) on an Gigabyte
> motherboard
> (Z170X-UD5 TH-CF) with a Thunderbolt 3 controller (Alpine Ridge 4C).
>
> I can see that the network interface is well created when the
> motherboard i
From: Eric Dumazet
Date: Tue, 22 Nov 2016 09:06:45 -0800
> From: Eric Dumazet
>
> In commits 93821778def10 ("udp: Fix rcv socket locking") and
> f7ad74fef3af ("net/ipv6/udp: UDP encapsulation: break backlog_rcv into
> __udpv6_queue_rcv_skb") UDP backlog handlers were renamed, but UDPlite
> was
From: Stefan Eichenberger
Date: Tue, 22 Nov 2016 17:47:21 +0100
> Add support for the MV88E6097 switch. The change was tested on an Armada
> based platform with a MV88E6097 switch.
>
> Signed-off-by: Stefan Eichenberger
Applied to net-next, thanks.
From: Cong Wang
Date: Tue, 22 Nov 2016 11:28:37 -0800
> On Tue, Nov 22, 2016 at 8:11 AM, Jiri Pirko wrote:
>> Tue, Nov 22, 2016 at 05:04:11PM CET, dan...@iogearbox.net wrote:
>>>Hmm, I don't think we want to have such an additional test in fast
>>>path for each and every classifier. Can we think
When multiple nexthops are available for a given route, the routing engine
chooses a nexthop by computing the flow hash through get_hash_from_flowi6
and by taking that value modulo the number of nexthops. The resulting value
indexes the nexthop to select. This method causes issues when a new nextho
On Thu, 2016-11-24 at 12:05 +0100, Pavel Machek wrote:
> Remove duplicate code from _tx routines.
trivia:
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
[]
> @@ -1960,6 +1960,38 @@ static void stmmac_tso_allocator(struct stm
On Thu, Nov 24, 2016 at 02:10:36PM -0500, Mark Lord wrote:
> On 16-11-24 02:00 PM, Greg KH wrote:
> > On Thu, Nov 24, 2016 at 01:34:08PM -0500, Mark Lord wrote:
> >> One thought: bulk data streams are byte streams, not packets.
> >> Scheduling on the USB bus can break up larger transfers across
>
On top of Arnd's overly long udelay patch because I noticed a
misindented block.
Even though I haven't turned on the netwinder in a box in in the
garage in who knows how long, if this device is still used somewhere,
might as well neaten the code too.
Joe Perches (8):
irda: w83977af_ir: whitespa
On 16-11-24 02:00 PM, Greg KH wrote:
> On Thu, Nov 24, 2016 at 01:34:08PM -0500, Mark Lord wrote:
>> One thought: bulk data streams are byte streams, not packets.
>> Scheduling on the USB bus can break up larger transfers across
>> multiple in-kernel buffers. A "real" URB buffer on USB2 is max 51
These just add unnecessary vertical whitespace.
Signed-off-by: Joe Perches
---
drivers/net/irda/w83977af_ir.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/irda/w83977af_ir.c b/drivers/net/irda/w83977af_ir.c
index 4ad91f4f867f..5aa61413aea8 100644
--- a/driv
Convert pointer comparisons to NULL.
Signed-off-by: Joe Perches
---
drivers/net/irda/w83977af_ir.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/net/irda/w83977af_ir.c b/drivers/net/irda/w83977af_ir.c
index 5aa61413aea8..ac481303e3ab 1
Remove leading and trailing whitespace.
git diff -w shows no differences.
Signed-off-by: Joe Perches
---
drivers/net/irda/w83977af_ir.c | 392 -
1 file changed, 196 insertions(+), 196 deletions(-)
diff --git a/drivers/net/irda/w83977af_ir.c b/drivers/net/
One indent level too many is too many.
Signed-off-by: Joe Perches
---
drivers/net/irda/w83977af_ir.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/irda/w83977af_ir.c b/drivers/net/irda/w83977af_ir.c
index 19b171af0e81..b865e93f01a0 100644
--- a/
Use more common logging style, standardize function output logging use.
Miscellanea:
o Add and use pr_fmt
o Convert printks to pr_
Signed-off-by: Joe Perches
---
drivers/net/irda/w83977af_ir.c | 48 --
1 file changed, 23 insertions(+), 25 deletions(-)
d
Neaten function declaration and definition arguments.
Signed-off-by: Joe Perches
---
drivers/net/irda/w83977af_ir.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/irda/w83977af_ir.c b/drivers/net/irda/w83977af_ir.c
index 5d776fb716f4..9c5b780b1d39 100644
---
Add braces where appropriate and remove an unnecessary else.
Signed-off-by: Joe Perches
---
drivers/net/irda/w83977af_ir.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/net/irda/w83977af_ir.c b/drivers/net/irda/w83977af_ir.c
index ac481303e3ab.
Add spaces around operators.
git diff -w shows no differences.
Signed-off-by: Joe Perches
---
drivers/net/irda/w83977af_ir.c | 232 -
1 file changed, 116 insertions(+), 116 deletions(-)
diff --git a/drivers/net/irda/w83977af_ir.c b/drivers/net/irda/w83977
Le 24/11/2016 à 07:01, Gregory CLEMENT a écrit :
> Hi Arnd,
>
> On jeu., nov. 24 2016, Arnd Bergmann wrote:
>
>> On Thursday, November 24, 2016 4:37:36 PM CET Jisheng Zhang wrote:
>>> solB (a SW shadow cookie) perhaps gives a better performance: in hot path,
>>> such as mvneta_rx(), the driver
Hi,
On Thu, Nov 24, 2016 at 04:20:45PM +0100, Pali Rohár wrote:
> Proprietary, signed and closed bootloader NOLO does not support DT. So
> for booting you need to append DTS file to kernel image.
>
> U-Boot is optional and can be used as intermediate bootloader between
> NOLO and kernel. But stil
On Thu, Nov 24, 2016 at 01:34:08PM -0500, Mark Lord wrote:
> One thought: bulk data streams are byte streams, not packets.
> Scheduling on the USB bus can break up larger transfers across
> multiple in-kernel buffers. A "real" URB buffer on USB2 is max 512 bytes.
> The driver is providing 16384-b
On 16-11-24 01:42 PM, Greg KH wrote:
>
> Have you tried using usbmon?
This system is running rootfs over NFS, so usbmon
isn't realistically going to be usable in that scenario
without a lot of reconfiguration of the setup (which in itself
might obscure the original problem).
There is a hardware U
Johan Hovold wrote:
Make sure to drop the reference taken by of_phy_find_device() during
probe on probe errors and on driver unbind.
Also drop the of_node reference taken by of_parse_phandle() in the same
path.
Fixes: b9b17debc69d ("net: emac: emac gigabit ethernet controller driver")
Signed-of
Le 24/11/2016 à 09:05, Martin Blumenstingl a écrit :
> On Thu, Nov 24, 2016 at 4:56 PM, Jerome Brunet wrote:
>> On Thu, 2016-11-24 at 15:34 +0100, Martin Blumenstingl wrote:
>>> Currently the dwmac-meson8b stmmac glue driver uses a hardcoded 1/4
>>> cycle TX clock delay. This seems to work fine fo
On 16-11-24 01:34 PM, Mark Lord wrote:
>From tracing through the powerpc arch code, this is the buffer that
> is being directly DMA'd into. And the USB layer does an invalidate_dcache
> on that entire buffer before initiating the DMA (confirmed via printk).
Slight correction: the invalidate_dcac
On Thu, Nov 24, 2016 at 11:43:53AM -0500, Mark Lord wrote:
> On 16-11-24 11:21 AM, David Miller wrote:
> > From: Hayes Wang
> > Date: Thu, 24 Nov 2016 13:26:55 +
> >
> > > I don't think the garbage results from our driver or device.
> > This is my impression with what has been presented so fa
On Thursday 24 November 2016 19:11:39 Sebastian Reichel wrote:
> Hi,
>
> On Thu, Nov 24, 2016 at 05:49:33PM +0100, Pali Rohár wrote:
> > On Thursday 24 November 2016 17:08:30 Sebastian Reichel wrote:
> > > On Thu, Nov 24, 2016 at 04:20:45PM +0100, Pali Rohár wrote:
> > > > On Thursday 24 November
On 16-11-24 12:11 PM, David Miller wrote:
> From: Mark Lord
> Date: Thu, 24 Nov 2016 11:43:53 -0500
>
>> So even if this were a platform memory coherency issue, one should
>> still never see ASCII data at the beginning of an rx buffer.
>
> I'm not so convinced, since this is the kind of random c
Make sure to drop the reference taken by of_phy_find_device() during
probe on probe errors and on driver unbind.
Also drop the of_node reference taken by of_parse_phandle() in the same
path.
Fixes: b9b17debc69d ("net: emac: emac gigabit ethernet controller driver")
Signed-off-by: Johan Hovold
--
Make sure to drop the reference taken by of_phy_find_device() when
registering and deregistering the fixed-link PHY-device.
Fixes: 39b0c705195e ("net: dsa: Allow configuration of CPU & DSA port
speeds/duplex")
Signed-off-by: Johan Hovold
---
net/dsa/dsa.c | 5 -
1 file changed, 4 insertions(
Make sure to drop the reference taken by of_phy_find_device() during
initialisation when later freeing the struct fman_mac.
Fixes: 57ba4c9b56d8 ("fsl/fman: Add FMan MAC support")
Signed-off-by: Johan Hovold
---
drivers/net/ethernet/freescale/fman/fman_memac.c | 3 +++
1 file changed, 3 insertion
This series fixes a number of phydev reference leaks (and one of_node
leak) due to failure to put the reference taken by of_phy_find_device().
Note that I did not try to fix drivers/net/phy/xilinx_gmii2rgmii.c which
still leaks a reference.
Against net but should apply just as fine to net-next.
Make sure to drop the reference taken by of_phy_find_device() when
looking up a fixed-link phydev during probe.
Fixes: 57ba4c9b56d8 ("fsl/fman: Add FMan MAC support")
Signed-off-by: Johan Hovold
---
drivers/net/ethernet/freescale/fman/mac.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/d
+Peppe,
Le 24/11/2016 à 07:38, Andrew Lunn a écrit :
>> As for enabling advertising and correct working of cpsw do you mean it
>> would be better to disable EEE in any PHY on cpsw initialization as
>> long as cpsw doesn't provide support for EEE?
>>
>> We observe some strange behavior with our gig
Make sure to drop the reference taken by of_phy_find_device() when
initialising MOCA PHYs.
Fixes: 6ac9de5f6563 ("net: bcmgenet: Register link_update callback for
all MoCA PHYs")
Signed-off-by: Johan Hovold
---
drivers/net/ethernet/broadcom/genet/bcmmii.c | 4 +++-
1 file changed, 3 insertions(+)
Hi,
On Thu, Nov 24, 2016 at 05:49:33PM +0100, Pali Rohár wrote:
> On Thursday 24 November 2016 17:08:30 Sebastian Reichel wrote:
> > On Thu, Nov 24, 2016 at 04:20:45PM +0100, Pali Rohár wrote:
> > > On Thursday 24 November 2016 16:13:17 Sebastian Reichel wrote:
> > > > On Thu, Nov 24, 2016 at 09:3
1 - 100 of 247 matches
Mail list logo
