On 03/03/2016 04:38 PM, Ramesh Shanmugasundaram wrote:
> This patch adds support for the CAN FD controller found in Renesas R-Car
> SoCs. The controller operates in CAN FD mode by default.
>
> CAN FD mode supports both Classical CAN & CAN FD frame formats. The
> controller supports ISO 11898-1:201
Hello Dear
How are you doing today? I read your profile today at hotdog and found you
worthy to be mine as someone whom i can lay on his arms as long as love is
concern, caring and teasing you all the night long, If you are interested in
knowing more about me and for me to send you some photos o
On 04/01/2016 10:55 AM, Eric Dumazet wrote:
> On Fri, 2016-04-01 at 10:13 +0800, Jason Wang wrote:
>
>
>> The problem is we want to support busy polling for tun. This needs
>> napi_id to be passed to tun socket by sk_mark_napi_id() during
>> tun_net_xmit(). But before reaching this, XPS will set
On 01.04.2016 06:26, Alexei Starovoitov wrote:
On Fri, Apr 01, 2016 at 06:12:49AM +0200, Hannes Frederic Sowa wrote:
On 01.04.2016 06:04, Alexei Starovoitov wrote:
On Thu, Mar 31, 2016 at 08:03:38PM -0700, Eric Dumazet wrote:
On Thu, 2016-03-31 at 18:45 -0700, Alexei Starovoitov wrote:
Eric,
On Fri, Apr 01, 2016 at 06:12:49AM +0200, Hannes Frederic Sowa wrote:
> On 01.04.2016 06:04, Alexei Starovoitov wrote:
> >On Thu, Mar 31, 2016 at 08:03:38PM -0700, Eric Dumazet wrote:
> >>On Thu, 2016-03-31 at 18:45 -0700, Alexei Starovoitov wrote:
> >>
> >>>Eric, what's your take on Hannes's patch
On 01.04.2016 06:04, Alexei Starovoitov wrote:
On Thu, Mar 31, 2016 at 08:03:38PM -0700, Eric Dumazet wrote:
On Thu, 2016-03-31 at 18:45 -0700, Alexei Starovoitov wrote:
Eric, what's your take on Hannes's patch 2 ?
Is it more accurate to ask lockdep to check for actual lock
or lockdep can rely
On Thu, Mar 31, 2016 at 08:03:38PM -0700, Eric Dumazet wrote:
> On Thu, 2016-03-31 at 18:45 -0700, Alexei Starovoitov wrote:
>
> > Eric, what's your take on Hannes's patch 2 ?
> > Is it more accurate to ask lockdep to check for actual lock
> > or lockdep can rely on owned flag?
> > Potentially the
Hi Shamir,
Nice to see this one soon on the list,
Just to make $subject more relevant. How about below?
RDS: fix congestion map corruption for PAGE_SIZE > 8k
On 3/30/16 5:50 PM, shamir rabinovitch wrote:
Issue can be seen on platforms that use 8K and above page size
while rds fragment size is
On 16-03-30 11:30 AM, Saeed Mahameed wrote:
> On Wed, Mar 30, 2016 at 8:04 PM, John Fastabend
> wrote:
>>
>> OK, so let me see if I get this right now. This was the precedence
>> before the patch in the normal no select queue case,
>>
>> (1) socket mapping sk_tx_queue_mapping iff !ooo_okay
On 16-03-31 04:48 PM, Michael Ma wrote:
> I didn't really know that multiple qdiscs can be isolated using MQ so
> that each txq can be associated with a particular qdisc. Also we don't
> really have multiple interfaces...
MQ will assign a default qdisc to each txq and the default qdisc can
be chan
Add the dts node for device configuration unit that provides
general purpose configuration and status for the device.
Signed-off-by: Yangbo Lu
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- Added this patch
Changes for v6
Move mpc85xx.h to include/linux/fsl and rename it to svr.h as
a common header file. It has been used for mpc85xx and it will
be used for ARM-based SoC as well.
Signed-off-by: Yangbo Lu
Acked-by: Wolfram Sang
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
The global utilities block controls power management, I/O device
enabling, power-onreset(POR) configuration monitoring, alternate
function selection for multiplexed signals,and clock control.
This patch adds GUTS driver to manage and access global utilities
block.
Signed-off-by: Yangbo Lu
---
Ch
On Fri, Apr 1, 2016, at 05:13, Eric Dumazet wrote:
> On Fri, 2016-04-01 at 04:01 +0200, Hannes Frederic Sowa wrote:
>
> > I thought so first, as well. But given the double check for the
> > spin_lock and the "mutex" we end up with the same result for the
> > lockdep_sock_is_held check.
> >
>
Move guts devicetree doc to Documentation/devicetree/bindings/soc/fsl/
since it's used by not only PowerPC but also ARM. And add a specification
for 'little-endian' property.
Signed-off-by: Yangbo Lu
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- Added
The eSDHC of T4240-R1.0-R2.0 has incorrect vender version and spec version.
Acturally the right version numbers should be VVN=0x13 and SVN = 0x1.
This patch adds the GUTS driver support for eSDHC driver to get SVR(System
version register). And fix host version to avoid that incorrect version
number
This patchset is used to fix a host version register bug in the T4240-R1.0-R2.0
eSDHC controller. To get the SoC version and revision, it's needed to add the
GUTS driver to access the global utilities registers.
So, the first three patches are to add the GUTS driver.
The following two patches are
On Fri, 2016-04-01 at 04:01 +0200, Hannes Frederic Sowa wrote:
> I thought so first, as well. But given the double check for the
> spin_lock and the "mutex" we end up with the same result for the
> lockdep_sock_is_held check.
>
> Do you see other consequences?
Well, we release the spinlock in
On Fri, Apr 1, 2016, at 05:03, Eric Dumazet wrote:
> On Thu, 2016-03-31 at 18:45 -0700, Alexei Starovoitov wrote:
>
> > Eric, what's your take on Hannes's patch 2 ?
> > Is it more accurate to ask lockdep to check for actual lock
> > or lockdep can rely on owned flag?
> > Potentially there could be
On Thu, Mar 31, 2016 at 10:18:47PM -0400, David Miller wrote:
> From: Leon Romanovsky
> Date: Fri, 1 Apr 2016 02:38:28 +0300
>
> > On Wed, Mar 23, 2016 at 09:37:54AM -0400, Doug Ledford wrote:
> >> On 03/23/2016 06:57 AM, Leon Romanovsky wrote:
> >> > On Sat, Mar 19, 2016 at 02:37:08PM -0700, Lin
On Thu, 2016-03-31 at 18:45 -0700, Alexei Starovoitov wrote:
> Eric, what's your take on Hannes's patch 2 ?
> Is it more accurate to ask lockdep to check for actual lock
> or lockdep can rely on owned flag?
> Potentially there could be races between setting the flag and
> actual lock... but that c
On Fri, 2016-04-01 at 10:13 +0800, Jason Wang wrote:
>
> The problem is we want to support busy polling for tun. This needs
> napi_id to be passed to tun socket by sk_mark_napi_id() during
> tun_net_xmit(). But before reaching this, XPS will set sender_cpu will
> make us can't see correct napi_i
On 04/01/2016 04:01 AM, David Miller wrote:
> From: Eric Dumazet
> Date: Thu, 31 Mar 2016 03:32:21 -0700
>
>> On Thu, 2016-03-31 at 13:50 +0800, Jason Wang wrote:
>>> We use a union for napi_id and send_cpu, this is ok for most of the
>>> cases except when we want to support busy polling for tun
On 2016年03月31日 16:09, Yuki Machida wrote:
> Hi all,
>
> Reboot Failed was occurred at Linux Kernel after v4.4-rc1 during IPv6 Ready
> Logo Conformance Test.
> Not Fix a bug in v4.5-rc7 yet.
> I will conform that it fix a bug in v4.6-rc1.
I conform that it was not occurred in v4.6-rc1.
I will fi
From: Michael Ma
Date: Thu, 31 Mar 2016 16:48:43 -0700
> I didn't really know that multiple qdiscs can be isolated using MQ so
...
Please stop top-posting.
From: Leon Romanovsky
Date: Fri, 1 Apr 2016 02:38:28 +0300
> On Wed, Mar 23, 2016 at 09:37:54AM -0400, Doug Ledford wrote:
>> On 03/23/2016 06:57 AM, Leon Romanovsky wrote:
>> > On Sat, Mar 19, 2016 at 02:37:08PM -0700, Linus Torvalds wrote:
>> >> So the *best* situation would be:
>> >>
>> >> -
On 03/31/2016 06:32 PM, Eric Dumazet wrote:
> On Thu, 2016-03-31 at 13:50 +0800, Jason Wang wrote:
>> We use a union for napi_id and send_cpu, this is ok for most of the
>> cases except when we want to support busy polling for tun which needs
>> napi_id to be stored and passed to socket during tu
On 01.04.2016 03:45, Eric Dumazet wrote:
On Thu, 2016-03-31 at 18:39 -0700, Eric Dumazet wrote:
On Fri, 2016-04-01 at 03:36 +0200, Hannes Frederic Sowa wrote:
On Fri, Apr 1, 2016, at 03:19, Eric Dumazet wrote:
Thanks.
As you can see, release_sock() messes badly lockdep (once your other
patche
On 01.04.2016 03:39, Eric Dumazet wrote:
On Fri, 2016-04-01 at 03:36 +0200, Hannes Frederic Sowa wrote:
On Fri, Apr 1, 2016, at 03:19, Eric Dumazet wrote:
Thanks.
As you can see, release_sock() messes badly lockdep (once your other
patches are in )
Once we properly fix release_sock() and/or _
From: Fabio Estevam Sent: Thursday, March 31, 2016 11:05 PM
> To: da...@davemloft.net
> Cc: Fugang Duan ; troy.ki...@boundarydevices.com;
> g...@uclinux.org; netdev@vger.kernel.org; Fabio Estevam
>
> Subject: [PATCH] fec: Do not access unexisting register in Coldfire
>
> From: Fabio Estevam
>
On Thu, 2016-03-31 at 18:39 -0700, Eric Dumazet wrote:
> On Fri, 2016-04-01 at 03:36 +0200, Hannes Frederic Sowa wrote:
> > On Fri, Apr 1, 2016, at 03:19, Eric Dumazet wrote:
> > > Thanks.
> > >
> > > As you can see, release_sock() messes badly lockdep (once your other
> > > patches are in )
> > >
On Thu, Mar 31, 2016 at 06:19:52PM -0700, Eric Dumazet wrote:
> On Fri, 2016-04-01 at 02:21 +0200, Hannes Frederic Sowa wrote:
>
> >
> > [ 31.064029] ===
> > [ 31.064030] [ INFO: suspicious RCU usage. ]
> > [ 31.064032] 4.5.0+ #13 Not tainted
> > [ 31.064033] -
On Fri, 2016-04-01 at 03:36 +0200, Hannes Frederic Sowa wrote:
> On Fri, Apr 1, 2016, at 03:19, Eric Dumazet wrote:
> > Thanks.
> >
> > As you can see, release_sock() messes badly lockdep (once your other
> > patches are in )
> >
> > Once we properly fix release_sock() and/or __release_sock(), al
On Fri, Apr 1, 2016, at 03:23, Eric Dumazet wrote:
> On Fri, 2016-04-01 at 02:30 +0200, Hannes Frederic Sowa wrote:
>
> > I fixed this one, I wait with review a bit and collapse some of the
> > newer fixes into one and check and repost again tomorrow.
>
> No change should be needed in TCP, onc
From: Fabio Estevam Sent: Thursday, March 31, 2016 6:57 PM
> To: Fugang Duan
> Cc: Greg Ungerer ; Troy Kisky
> ; netdev@vger.kernel.org
> Subject: Re: [PATCH] net: fec: stop the "rcv is not +last, " error messages
>
> Hi Andy,
>
> On Wed, Mar 30, 2016 at 10:41 PM, Fugang Duan
> wrote:
> >
> >
On Fri, Apr 1, 2016, at 03:19, Eric Dumazet wrote:
> Thanks.
>
> As you can see, release_sock() messes badly lockdep (once your other
> patches are in )
>
> Once we properly fix release_sock() and/or __release_sock(), all these
> false positives disappear.
This was a loopback connection. I need
On Fri, 2016-04-01 at 02:30 +0200, Hannes Frederic Sowa wrote:
> I fixed this one, I wait with review a bit and collapse some of the
> newer fixes into one and check and repost again tomorrow.
No change should be needed in TCP, once net/core/sock.c is fixed.
When someone fixes a lockdep issue,
On Fri, 2016-04-01 at 02:21 +0200, Hannes Frederic Sowa wrote:
>
> [ 31.064029] ===
> [ 31.064030] [ INFO: suspicious RCU usage. ]
> [ 31.064032] 4.5.0+ #13 Not tainted
> [ 31.064033] ---
> [ 31.064034] include/net/sock.h:1594 susp
On Thu, Mar 31, 2016 at 05:29:59PM +0200, Johannes Berg wrote:
>
> Does removing this completely disable the "-EEXIST" error? I can't say
> I fully understand the elasticity stuff in __rhashtable_insert_fast().
What EEXIST error are you talking about? The only one that can be
returned on insertio
On 01.04.2016 02:12, Eric Dumazet wrote:
Since this function does not take a reference on the dst, how could it
be safe ?
As soon as you exit the function, dst would possibly point to something
obsolete/freed.
This works because the caller owns the socket.
If you believe one path needs to be f
On Thu, Mar 31, 2016 at 06:25:12PM -0300, 'Marcelo Ricardo Leitner' wrote:
> On Thu, Mar 31, 2016 at 11:16:52AM +, David Laight wrote:
> > From: Marcelo Ricardo Leitner
> > > Sent: 30 March 2016 13:13
> > > Em 30-03-2016 06:37, David Laight escreveu:
> > > > From: Marcelo Ricardo Leitner
> > >
On 01.04.2016 02:12, Eric Dumazet wrote:
On Fri, 2016-04-01 at 02:01 +0200, Hannes Frederic Sowa wrote:
Hi Eric,
On 01.04.2016 01:39, Eric Dumazet wrote:
On Fri, 2016-04-01 at 01:29 +0200, Hannes Frederic Sowa wrote:
Various fixes which were discovered by this changeset. More probably
to come
On Fri, 2016-04-01 at 02:01 +0200, Hannes Frederic Sowa wrote:
> Hi Eric,
>
> On 01.04.2016 01:39, Eric Dumazet wrote:
> > On Fri, 2016-04-01 at 01:29 +0200, Hannes Frederic Sowa wrote:
> >> Various fixes which were discovered by this changeset. More probably
> >> to come...
> >
> >
> > Really ?
>
Hi Eric,
On 01.04.2016 01:39, Eric Dumazet wrote:
On Fri, 2016-04-01 at 01:29 +0200, Hannes Frederic Sowa wrote:
Various fixes which were discovered by this changeset. More probably
to come...
Really ?
Again, TCP stack locks the socket most of the time.
The fact that lockdep does not under
Signed-off-by: Hannes Frederic Sowa
---
net/ipv4/tcp_output.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index ba3621834e7bfa..3f70582578ada0 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1426,21 +14
Already another one fix I overlooked.
Signed-off-by: Hannes Frederic Sowa
---
net/ipv4/tcp_metrics.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/tcp_metrics.c b/net/ipv4/tcp_metrics.c
index 33a36648423e8b..196de79902819a 100644
--- a/net/ipv4/tcp_metrics.c
I didn't really know that multiple qdiscs can be isolated using MQ so
that each txq can be associated with a particular qdisc. Also we don't
really have multiple interfaces...
With this MQ solution we'll still need to assign transmit queues to
different classes by doing some math on the bandwidth
On Wed, Mar 30, 2016 at 8:35 PM, Willem de Bruijn
wrote:
> On Wed, Mar 30, 2016 at 6:37 PM, Soheil Hassas Yeganeh
> wrote:
>> From: Soheil Hassas Yeganeh
>>
>> SOF_TIMESTAMPING_OPT_ID is set to get data-independent IDs
>> to associate timestamps with send calls. For TCP connections,
>> tp->snd_u
Thanks for taking care of that Fabio.
Regards
Greg
On 01/04/16 01:05, Fabio Estevam wrote:
> From: Fabio Estevam
>
> Commit 55cd48c821de ("net: fec: stop the "rcv is not +last, " error
> messages") introduces a write to a register that does not exist in
> Coldfire.
>
> Move the FEC_FTRL regis
On Wed, Mar 23, 2016 at 09:37:54AM -0400, Doug Ledford wrote:
> On 03/23/2016 06:57 AM, Leon Romanovsky wrote:
> > On Sat, Mar 19, 2016 at 02:37:08PM -0700, Linus Torvalds wrote:
> >> So the *best* situation would be:
> >>
> >> - your two groups talk it over, and figure out what the common commits
On Fri, 2016-04-01 at 01:29 +0200, Hannes Frederic Sowa wrote:
> Various fixes which were discovered by this changeset. More probably
> to come...
Really ?
Again, TCP stack locks the socket most of the time.
The fact that lockdep does not understand this is not a reason to add
this overhead.
Thanks for the suggestion - I'll try the MQ solution out. It seems to
be able to solve the problem well with the assumption that bandwidth
can be statically partitioned.
2016-03-31 12:18 GMT-07:00 Jesper Dangaard Brouer :
>
> On Wed, 30 Mar 2016 00:20:03 -0700 Michael Ma wrote:
>
>> I know this m
On Fri, 1 Apr 2016 00:28:57 +0200
Guus Sliepen wrote:
> On Thu, Mar 31, 2016 at 05:20:50PM -0400, David Miller wrote:
>
> > >> I'm trying to reduce system call overhead when reading/writing to/from a
> > >> tun device in userspace. [...] What would be the right way to do this?
> > >>
> > > Perso
Hi Daniel,
On 31.03.2016 23:52, Daniel Borkmann wrote:
On 03/31/2016 09:48 PM, Hannes Frederic Sowa wrote:
[...]
Tightest solution would probably be to combine both patches.
bool called_by_tuntap;
old_fp = rcu_dereference_protected(sk->sk_filter, called_by_tuntap ?
lockdep_rtnl_is_held() : lo
Various fixes which were discovered by this changeset. More probably
to come...
Signed-off-by: Hannes Frederic Sowa
---
include/net/tcp.h | 5 -
net/core/sock.c| 7 +--
net/ipv4/tcp_input.c | 18 ++
net/ipv4/tcp_metrics.c | 12 +---
net/ipv4/tcp_o
Also make lockdep_sock_is_held accept const arguments, so we don't need to
modify too many callers.
Reported-by: Sasha Levin
Cc: Daniel Borkmann
Cc: Alexei Starovoitov
Cc: Michal Kubecek
Signed-off-by: Hannes Frederic Sowa
---
include/net/sock.h | 7 ---
net/dccp/ipv4.c |
[Changelog stolen from Daniel Borkmann:]
Sasha Levin reported a suspicious rcu_dereference_protected() warning
found while fuzzing with trinity that is similar to this one:
[ 52.765684] net/core/filter.c:2262 suspicious rcu_dereference_protected()
usage!
[ 52.765688] other info that migh
Only the first patch is really applicable for stable. It adds appropriate
socket locks so lockdep doesn't complain if tuntap's ioctls modify the
filters on the socket.
Rest of the patches tighten the rcu dereference socket lock checks.
Last patch fixes missing rcu_read_locks which were discovered
lockdep_sock_is_held makes sure that we currently own the
lock. sock_owned_by_user simply checks if a user holds the socket. This
could lead to non deterministic lock checks.
Reported-by: Sasha Levin
Cc: Daniel Borkmann
Cc: Alexei Starovoitov
Cc: Michal Kubecek
Signed-off-by: Hannes Frederic S
Urgent Founds!!
We wish to inform you that your over due Inheritance funds which we agreed to
pay you in cash is already sealed and package with a security proof box. The
funds worth of $7.5 millions US Dollar,in the package will be conveyed to you
by an Int'l diplomatic agent, Mr. Ton
On Wed, Mar 30, 2016 at 2:05 PM, Light, John J wrote:
>
> Maybe the problem is that the default shouldn't be to a TCP value, but should
> be a 'transport' value.
>
The code is fine because net->ipv4 is always there, it doesn't
depend on any CONFIG, so it is safe for dccp to use too, although
I a
On Thu, Mar 31, 2016 at 05:20:50PM -0400, David Miller wrote:
> >> I'm trying to reduce system call overhead when reading/writing to/from a
> >> tun device in userspace. [...] What would be the right way to do this?
> >>
> > Personally I think tun could benefit greatly if it were implemented as
>
Multipath route lookups should consider knowledge about next hops and not
select a hop that is known to be failed.
Example:
[h2] [h3] 15.0.0.5
| |
3| 3|
On Wed, Mar 30, 2016 at 12:20 AM, Michael Ma wrote:
> As far as I understand the design of TC is to simplify locking schema
> and minimize the work in __qdisc_run so that throughput won’t be
> affected, especially with large packets. However if the scenario is
> that multiple classes in the queuei
On Thu, Mar 31, 2016 at 3:04 PM, Jesse Brandeburg
wrote:
> On Wed, 30 Mar 2016 16:15:37 -0700
> Alexander Duyck wrote:
>
>> This patch addresses a bug introduced based on my interpretation of the
>> XL710 datasheet. Specifically section 8.4.1 states that "A single transmit
>> packet may span up
On Wed, 30 Mar 2016 16:15:37 -0700
Alexander Duyck wrote:
> This patch addresses a bug introduced based on my interpretation of the
> XL710 datasheet. Specifically section 8.4.1 states that "A single transmit
> packet may span up to 8 buffers (up to 8 data descriptors per packet
> including both
On Wed, Mar 30, 2016 at 11:50:31PM -0400, Willem de Bruijn wrote:
> >> Nice patches!
>
> This does not yet solve the append issue that your MSG_EOR patch
> addresses, of course.
Yes. I have been thinking about both approaches.
>
> The straightforward jump to new_segment that I proposed as
> simpl
On 03/31/2016 09:48 PM, Hannes Frederic Sowa wrote:
[...]
Tightest solution would probably be to combine both patches.
bool called_by_tuntap;
old_fp = rcu_dereference_protected(sk->sk_filter, called_by_tuntap ?
lockdep_rtnl_is_held() : lockdep_sock_is_held());
If I understand you correctly w
On Thu, Mar 31, 2016 at 11:16:52AM +, David Laight wrote:
> From: Marcelo Ricardo Leitner
> > Sent: 30 March 2016 13:13
> > Em 30-03-2016 06:37, David Laight escreveu:
> > > From: Marcelo Ricardo Leitner
> > >> Sent: 29 March 2016 14:42
> > >>
> > >> Currently on high rate SCTP streams the hear
From: Tom Herbert
Date: Thu, 31 Mar 2016 17:18:48 -0400
> On Tue, Mar 29, 2016 at 6:40 PM, Guus Sliepen wrote:
>> I'm trying to reduce system call overhead when reading/writing to/from a
>> tun device in userspace. For sockets, one can use sendmmsg()/recvmmsg(),
>> but a tun fd is not a socket f
From: Bjørn Mork
Date: Thu, 31 Mar 2016 23:07:30 +0200
> David Miller writes:
>> From: Daniele Palmas
>> Date: Thu, 31 Mar 2016 15:16:47 +0200
>>
>>> Telit LE910 V2 is a mobile broadband card with no ARP capabilities:
>>> the patch makes this device to use wwan_noarp_info struct
>>>
>>> Signed
On Tue, Mar 29, 2016 at 6:40 PM, Guus Sliepen wrote:
> I'm trying to reduce system call overhead when reading/writing to/from a
> tun device in userspace. For sockets, one can use sendmmsg()/recvmmsg(),
> but a tun fd is not a socket fd, so this doesn't work. I'm see several
> options to allow use
David Miller writes:
> From: Daniele Palmas
> Date: Thu, 31 Mar 2016 15:16:47 +0200
>
>> Telit LE910 V2 is a mobile broadband card with no ARP capabilities:
>> the patch makes this device to use wwan_noarp_info struct
>>
>> Signed-off-by: Daniele Palmas
>
> Bjorn, can you take a quick look at t
Only switch families with 4096 address databases have dedicated FID
registers for ATU and VTU operations.
Factorize the access to the GLOBAL_ATU_FID register and introduce a
mv88e6xxx_has_fid_reg() helper function to protect the access to
GLOBAL_ATU_FID and GLOBAL_VTU_FID.
Signed-off-by: Vivien D
Introduce a mv88e6xxx_has_stu() helper to protect the access to the
GLOBAL_VTU_SID register, instead of checking switch families.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dsa/mv8
The 6185 family of devices has only 256 address databases. Their 8-bit
FID for ATU and VTU operations are split into ATU Control and ATU/VTU
Operation registers.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx.c | 36 +++-
1 file changed, 35 insertions
All packets passing through a switch of the 6185 family are currently all
directed to the CPU port. This means that port bridging is software driven.
To enable hardware bridging for this switch family, we need to implement the
port mapping operations, the FDB operations, and optionally the VLAN op
Marvell switch chips have different number of address databases.
The code currently only supports models with 4096 databases. Such switch
has dedicated FID registers for ATU and VTU operations. Models with
fewer databases have their FID split in several registers.
List them all but only support m
By adding support for bridge operations, FDB operations, and optionally
VLAN operations (for 802.1Q and VLAN filtering aware systems), the
switch bridges ports correctly, the CPU is able to populate the hardware
address databases, and thus hardware bridging becomes functional within
the 88E6185 fam
The 88E6185 switch also has a MapDA bit in its Port Control 2 register.
When this bit is cleared, all frames are sent out to the CPU port.
Set this bit to rely on address databases (ATU) hits and direct frames
out of the correct ports, and thus allow hardware bridging.
Signed-off-by: Vivien Didel
From: Daniele Palmas
Date: Thu, 31 Mar 2016 15:16:47 +0200
> Telit LE910 V2 is a mobile broadband card with no ARP capabilities:
> the patch makes this device to use wwan_noarp_info struct
>
> Signed-off-by: Daniele Palmas
Bjorn, can you take a quick look at this?
Thank you.
From: Nicolas Dichtel
Date: Thu, 31 Mar 2016 18:10:31 +0200
> Size of the attribute IFLA_PHYS_PORT_NAME was missing.
>
> Fixes: db24a9044ee1 ("net: add support for phys_port_name")
> CC: David Ahern
> Signed-off-by: Nicolas Dichtel
Applied, and queued up for -stable, thanks Nicolas.
Man... t
From: Thomas Petazzoni
Date: Thu, 31 Mar 2016 22:37:35 +0200
> Hello,
>
> On Thu, 31 Mar 2016 15:15:47 -0400 (EDT), David Miller wrote:
>> From: Jisheng Zhang
>> Date: Wed, 30 Mar 2016 19:55:21 +0800
>>
>> > The mvneta is also used in some Marvell berlin family SoCs which may
>> > have 64bytes
From: Fabio Estevam
Date: Thu, 31 Mar 2016 12:05:17 -0300
> From: Fabio Estevam
>
> Commit 55cd48c821de ("net: fec: stop the "rcv is not +last, " error
> messages") introduces a write to a register that does not exist in
> Coldfire.
>
> Move the FEC_FTRL register access inside the FEC_QUIRK_HA
Hello,
On Thu, 31 Mar 2016 15:15:47 -0400 (EDT), David Miller wrote:
> From: Jisheng Zhang
> Date: Wed, 30 Mar 2016 19:55:21 +0800
>
> > The mvneta is also used in some Marvell berlin family SoCs which may
> > have 64bytes cacheline size. Replace the MVNETA_CPU_D_CACHE_LINE_SIZE
> > usage with L
From: shamir rabinovitch
Date: Thu, 31 Mar 2016 02:29:22 -0400
> Issue can be seen on platforms that use 8K and above page size
> while rds fragment size is 4K. On those platforms single page is
> shared between 2 or more rds fragments. Each fragment has its own
> offset and rds congestion map co
From: Eric Dumazet
Date: Thu, 31 Mar 2016 03:32:21 -0700
> On Thu, 2016-03-31 at 13:50 +0800, Jason Wang wrote:
>> We use a union for napi_id and send_cpu, this is ok for most of the
>> cases except when we want to support busy polling for tun which needs
>> napi_id to be stored and passed to soc
From: Hannes Frederic Sowa
Date: Thu, 31 Mar 2016 21:48:27 +0200
> Tightest solution would probably be to combine both patches.
>
> bool called_by_tuntap;
>
> old_fp = rcu_dereference_protected(sk->sk_filter, called_by_tuntap ?
> lockdep_rtnl_is_held() : lockdep_sock_is_held());
Ok, I see what
From: Alexei Starovoitov
Date: Thu, 31 Mar 2016 12:31:56 -0700
> On Thu, Mar 31, 2016 at 09:24:12PM +0200, Hannes Frederic Sowa wrote:
>> Hello,
>>
>> On 31.03.2016 21:21, David Miller wrote:
>> >From: Daniel Borkmann
>> >Date: Thu, 31 Mar 2016 14:16:18 +0200
>> >
>> >Alexei, do you really mind
On 31.03.2016 21:36, David Miller wrote:
From: Hannes Frederic Sowa
Date: Thu, 31 Mar 2016 21:24:12 +0200
diff --git a/net/core/filter.c b/net/core/filter.c
index 4b81b71171b4ce..8ab270d5ce5507 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -1166,7 +1166,8 @@ static int __sk_attach_
From: Hannes Frederic Sowa
Date: Thu, 31 Mar 2016 21:24:12 +0200
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 4b81b71171b4ce..8ab270d5ce5507 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -1166,7 +1166,8 @@ static int __sk_attach_prog(struct bpf_prog
> *prog, stru
On Thu, Mar 31, 2016 at 09:24:12PM +0200, Hannes Frederic Sowa wrote:
> Hello,
>
> On 31.03.2016 21:21, David Miller wrote:
> >From: Daniel Borkmann
> >Date: Thu, 31 Mar 2016 14:16:18 +0200
> >
> >>On 03/31/2016 01:59 PM, Eric Dumazet wrote:
> >>>On Thu, 2016-03-31 at 13:35 +0200, Daniel Borkmann
From: Akinobu Mita
Date: Thu, 31 Mar 2016 01:38:39 +0900
> + struct sk_buff_head tx_queue;
The way the queueing works in this driver is that it is only possible
to have one SKB being transmitted at one time.
This is evident by how the driver immediately stops the TX queue when
it is given a
Hello,
On 31.03.2016 21:21, David Miller wrote:
From: Daniel Borkmann
Date: Thu, 31 Mar 2016 14:16:18 +0200
On 03/31/2016 01:59 PM, Eric Dumazet wrote:
On Thu, 2016-03-31 at 13:35 +0200, Daniel Borkmann wrote:
+static inline bool sock_owned_externally(const struct sock *sk)
+{
+ retu
On 3/31/16 11:46 AM, Naveen N. Rao wrote:
It's failing this way on powerpc? Odd.
This fails for me on x86_64 too -- RHEL 7.1.
indeed. fails on centos 7.1, whereas centos 6.7 is fine.
From: Daniel Borkmann
Date: Thu, 31 Mar 2016 14:16:18 +0200
> On 03/31/2016 01:59 PM, Eric Dumazet wrote:
>> On Thu, 2016-03-31 at 13:35 +0200, Daniel Borkmann wrote:
>>
>>> +static inline bool sock_owned_externally(const struct sock *sk)
>>> +{
>>> + return sk->sk_flags & (1UL << SOCK_EXTERNAL
On 3/31/16 11:51 AM, Naveen N. Rao wrote:
On 2016/03/31 10:49AM, Alexei Starovoitov wrote:
On 3/31/16 4:25 AM, Naveen N. Rao wrote:
Make BPF samples build depend on CONFIG_SAMPLE_BPF. We still don't add a
Kconfig option since that will add a dependency on llvm for allyesconfig
builds which may
On Wed, 30 Mar 2016 00:20:03 -0700 Michael Ma wrote:
> I know this might be an old topic so bare with me – what we are facing
> is that applications are sending small packets using hundreds of
> threads so the contention on spin lock in __dev_xmit_skb increases the
> latency of dev_queue_xmit si
From: Jisheng Zhang
Date: Wed, 30 Mar 2016 19:53:41 +0800
> The mvpp2 ip maybe used in SoCs which may have have 64bytes cacheline
> size. Replace the MVPP2_CPU_D_CACHE_LINE_SIZE with L1_CACHE_BYTES.
>
> And since dma_alloc_coherent() is always cacheline size aligned, so
> remove the align checks
From: Jisheng Zhang
Date: Wed, 30 Mar 2016 19:55:21 +0800
> The mvneta is also used in some Marvell berlin family SoCs which may
> have 64bytes cacheline size. Replace the MVNETA_CPU_D_CACHE_LINE_SIZE
> usage with L1_CACHE_BYTES.
>
> And since dma_alloc_coherent() is always cacheline size aligne
1 - 100 of 159 matches
Mail list logo
