Hi!
In kernel based on edadd0e, I get plenty of errors such as:
net/netfilter/core.c:96:3: note: in expansion of macro ‘rcu_assign_pointer’
rcu_assign_pointer(reg->dev->nf_hooks_ingress, entry);
^
In file included from ./include/linux/linkage.h:4:0,
from ./include/linux/ker
Robert Jarzmik writes:
> Mark Rutland writes:
>
>> On Mon, Oct 03, 2016 at 06:11:23PM +0200, Robert Jarzmik wrote:
>>> Mark Rutland writes:
>>>
>>> reg-u16-align4 tells that a specific hardware doesn't support 16 bit writes
>>> not
>>> being 32 bits aligned, or said differently that a "store"
On Wed, Oct 05, 2016 at 11:01:38AM -0700, Cong Wang wrote:
> On Tue, Oct 4, 2016 at 11:52 PM, Krister Johansen
> wrote:
> > On Mon, Oct 03, 2016 at 11:22:33AM -0700, Cong Wang wrote:
> >> Please try the attached patch. I also convert the read path to RCU
> >> to avoid a possible deadlock. A quick
Here are the build and merge fixups for the networking
stuff.
Please pull, thanks a lot!
The following changes since commit 41844e36206be90cd4d962ea49b0abc3612a99d0:
Merge tag 'staging-4.9-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging (2016-10-05
14:50:51 -0700)
are
On Wed, Oct 5, 2016 at 6:07 AM, Jiri Benc wrote:
> Now when the first vlan tag is always in skb->vlan_tci, drop code that
> assumed it might not be the case.
>
User can turn off TX vlan offload for OVS internal device that would
allow vlan tagged packet with vlan header on the skb-data. This case
From: Alex Sidorenko
Date: Wed, 05 Oct 2016 09:06:04 -0400
> Roundrobin runner of team driver uses 'unsigned int' variable to count the
> number of sent_packets.
> Later it is passed to a subroutine team_num_to_port_index(struct team *team,
> int num) as
> 'num' and when we reach MAXINT (2**31-
Add documention of ti,impedance-control which can be used to
correct MAC impedance mismatch using phy extended registers.
Signed-off-by: Mugunthan V N
---
Documentation/devicetree/bindings/net/ti,dp83867.txt | 12
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetr
Add support for configurable impedance control for TI dp83867
phy via devicetree. More documentation in [1].
CPSW second ethernet is not working, fix it by enabling
impedance configuration on the phy.
Verified the patch on DRA72 Rev C evm, logs at [2]. Also pushed
a branch [3] for others to test.
Add support for programmable MAC impedance configuration
Signed-off-by: Mugunthan V N
---
drivers/net/phy/dp83867.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index 91177a4..1b63924 100644
--- a/drivers/
The current delay settings of the phy are not the optimal value,
fix it with correct values.
Signed-off-by: Mugunthan V N
---
arch/arm/boot/dts/dra72-evm-revc.dts | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts
b/arch/arm/boot/dts
The default impedance settings of the phy is not the optimal
value, due to this the second ethernet is not working. Fix it
with correct values which makes the second ethernet port to work.
Signed-off-by: Mugunthan V N
---
arch/arm/boot/dts/dra72-evm-revc.dts | 2 ++
1 file changed, 2 insertions(
Hi Dave,
On Wed, 05 Oct 2016 22:56:12 -0400 (EDT) David Miller
wrote:
>
> Yes, this is where the change got lost.
No worries.
> I have all of the fixups queued up in my net tree and will send in a pull
> request later.
Thanks.
--
Cheers,
Stephen Rothwell
ATENCIÓN;
Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por
el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser
capaz de enviar o recibir correo nuevo hasta que
vuelva a validar su buzón de correo electrónico. Para revalidar su buzón de
corre
On (10/06/16 06:11), Eric Dumazet wrote:
> On Wed, 2016-10-05 at 22:56 +0200, Michal Sojka wrote:
>
> > this commit is now in mainline as
> > e3b37f11e6e4e6b6f02cc762f182ce233d2c1c9d and it breaks my build:
> >
> > net/netfilter/core.c: In function 'nf_set_hooks_head':
> > net/netfilter/c
From: Stephen Rothwell
Date: Thu, 6 Oct 2016 13:51:52 +1100
> On Wed, 5 Oct 2016 19:14:21 -0700 Linus Torvalds
> wrote:
>>
>> On Wed, Oct 5, 2016 at 5:52 PM, Stephen Rothwell
>> wrote:
>> >
>> > Except that commit effectively moved that function from
>> > net/netfilter/nf_tables_netdev.c to
>
Hi Linus,
On Wed, 5 Oct 2016 19:14:21 -0700 Linus Torvalds
wrote:
>
> On Wed, Oct 5, 2016 at 5:52 PM, Stephen Rothwell
> wrote:
> >
> > Except that commit effectively moved that function from
> > net/netfilter/nf_tables_netdev.c to
> > include/net/netfilter/nf_tables_ipv4.h while commit c73c24
On Wed, Oct 5, 2016 at 5:52 PM, Stephen Rothwell wrote:
>
> Except that commit effectively moved that function from
> net/netfilter/nf_tables_netdev.c to
> include/net/netfilter/nf_tables_ipv4.h while commit c73c24849011
> ("netfilter: nf_tables_netdev: remove redundant ip_hdr assignment")
> remov
From: Mike Looijmans
Date: Tue, 4 Oct 2016 07:52:04 +0200
> Set bit 0 in register 1C.23 to enable the EDPD feature of the
> KSZ9031 PHY. This reduces power consumption when the link is
> down.
>
> Signed-off-by: Mike Looijmans
> ---
> v2: Unconditionally enable EDPD mode
Applied.
Hi Linus,
On Wed, 5 Oct 2016 15:37:17 -0700 Linus Torvalds
wrote:
>
> On Wed, Oct 5, 2016 at 3:29 PM, Stephen Rothwell
> wrote:
> >
> > I have been carrying the following merge fix patch (for the merge of
> > the net-next tree with Linus' tree) for a while now which seems to have
> > got misse
From: Pablo Neira Ayuso
Date: Thu, 6 Oct 2016 02:09:45 +0200
> On Wed, Oct 05, 2016 at 03:37:17PM -0700, Linus Torvalds wrote:
>> On Wed, Oct 5, 2016 at 3:29 PM, Stephen Rothwell
>> wrote:
>> >
>> > I have been carrying the following merge fix patch (for the merge of
>> > the net-next tree with
From: Pablo Neira Ayuso
Date: Thu, 6 Oct 2016 02:07:44 +0200
> This is a pull request to address fallout from previous nf-next pull
> request, only fixes going on here:
>
> 1) Address a potential null dereference in nf_unregister_net_hook()
>when becomes nf_hook_entry_head is NULL, from Aar
On Wed, Oct 05, 2016 at 03:37:17PM -0700, Linus Torvalds wrote:
> On Wed, Oct 5, 2016 at 3:29 PM, Stephen Rothwell
> wrote:
> >
> > I have been carrying the following merge fix patch (for the merge of
> > the net-next tree with Linus' tree) for a while now which seems to have
> > got missed:
>
>
From: Aaron Conole
When CONFIG_NETFILTER_INGRESS is unset (or no), we need to handle
the request for registration properly by dropping the hook. This
releases the entry during the set.
Fixes: e3b37f11e6e4 ("netfilter: replace list_head with single linked list")
Signed-off-by: Aaron Conole
Sign
From: Vishwanath Pai
Division of 64bit integers will cause linker error undefined reference
to `__udivdi3'. Fix this by replacing divisions with div64_64
Fixes: 11d5f15723c9 ("netfilter: xt_hashlimit: Create revision 2 to ...")
Signed-off-by: Vishwanath Pai
Acked-by: Maciej Żenczykowski
Signed
Hi David,
This is a pull request to address fallout from previous nf-next pull
request, only fixes going on here:
1) Address a potential null dereference in nf_unregister_net_hook()
when becomes nf_hook_entry_head is NULL, from Aaron Conole.
2) Missing ifdef for CONFIG_NETFILTER_INGRESS, also
From: Liping Zhang
After I input the following nftables rule, a panic happened on my system:
# nft add rule filter OUTPUT limit rate 0xf bytes/second
divide error: [#1] SMP
[ ... ]
RIP: 0010:[] []
nft_limit_pkt_bytes_eval+0x2e/0xa0 [nft_limit]
Call Trace:
[] nft_do_ch
From: Jann Horn
nf_log_proc_dostring() used current's network namespace instead of the one
corresponding to the sysctl file the write was performed on. Because the
permission check happens at open time and the nf_log files in namespaces
are accessible for the namespace owner, this can be abused b
From: Aaron Conole
It's possible for nf_hook_entry_head to return NULL. If two
nf_unregister_net_hook calls happen simultaneously with a single hook
entry in the list, both will enter the nf_hook_mutex critical section.
The first will successfully delete the head, but the second will see
this NU
On Thu, Oct 06, 2016 at 08:30:11AM +0900, Eric Dumazet wrote:
> On Wed, 2016-10-05 at 15:24 -0700, Alexei Starovoitov wrote:
> > On Thu, Oct 06, 2016 at 04:13:18AM +0900, Eric Dumazet wrote:
> > >
> > > While we are at it, since we do an order-3 allocation, allow to use
> > > all the allocated byt
On Thu, Oct 06, 2016 at 08:35:21AM +0900, Eric Dumazet wrote:
> On Wed, 2016-10-05 at 15:24 -0700, Alexei Starovoitov wrote:
> > On Thu, Oct 06, 2016 at 04:13:18AM +0900, Eric Dumazet wrote:
> > >
> > > While we are at it, since we do an order-3 allocation, allow to use
> > > all the allocated byt
On Wed, 2016-10-05 at 15:24 -0700, Alexei Starovoitov wrote:
> On Thu, Oct 06, 2016 at 04:13:18AM +0900, Eric Dumazet wrote:
> >
> > While we are at it, since we do an order-3 allocation, allow to use
> > all the allocated bytes instead of 16384 to reduce syscalls during
> > large dumps.
> >
> >
On Wed, 2016-10-05 at 15:24 -0700, Alexei Starovoitov wrote:
> On Thu, Oct 06, 2016 at 04:13:18AM +0900, Eric Dumazet wrote:
> >
> > While we are at it, since we do an order-3 allocation, allow to use
> > all the allocated bytes instead of 16384 to reduce syscalls during
> > large dumps.
> >
> >
On Wed, Oct 5, 2016 at 3:29 PM, Stephen Rothwell wrote:
>
> I have been carrying the following merge fix patch (for the merge of
> the net-next tree with Linus' tree) for a while now which seems to have
> got missed:
Ugh. It doesn't seem to be a merge error, because that double iph
assignment cam
Hi Linus, Dave,
On Wed, 05 Oct 2016 01:44:37 -0400 (EDT) David Miller
wrote:
>
I have been carrying the following merge fix patch (for the merge of
the net-next tree with Linus' tree) for a while now which seems to have
got missed:
From: Stephen Rothwell
Date: Tue, 13 Sep 2016 10:08:58 +1000
On Thu, 2016-10-06 at 00:13 +0200, Pavel Machek wrote:
> On Wed 2016-10-05 12:15:34, Joe Perches wrote:
> > On Wed, 2016-10-05 at 21:11 +0200, Pavel Machek wrote:
> > > On Wed 2016-10-05 10:53:16, Joe Perches wrote:
[]
> > > > trivia:
> > > > It's generally faster to use bool instead of u8 foo:1;
>
On Thu, Oct 06, 2016 at 04:13:18AM +0900, Eric Dumazet wrote:
>
> While we are at it, since we do an order-3 allocation, allow to use
> all the allocated bytes instead of 16384 to reduce syscalls during
> large dumps.
>
> iproute2 already uses 32KB recvmsg() buffer sizes.
> diff --git a/net/
On 04/10/2016 01:53, Kees Cook wrote:
> On Wed, Sep 14, 2016 at 12:23 AM, Mickaël Salaün wrote:
>> This new arraymap looks like a set and brings new properties:
>> * strong typing of entries: the eBPF functions get the array type of
>> elements instead of CONST_PTR_TO_MAP (e.g.
>> CONST_PTR_T
On Wed 2016-10-05 12:15:34, Joe Perches wrote:
> On Wed, 2016-10-05 at 21:11 +0200, Pavel Machek wrote:
> > On Wed 2016-10-05 10:53:16, Joe Perches wrote:
> > > On Wed, 2016-10-05 at 13:14 +0200, Marcel Holtmann wrote:
> > > > Hi Pavel,
> > > >
> > > > > bluetooth.h is not part of user API, so __
Hi Pavel,
> bluetooth.h is not part of user API, so __ variants are not neccessary
> here.
>
> Signed-off-by: Pavel Machek
>
> ---
> v2: not touching stuff that Marcel does not want touched, as it will
> become API later.
patch has been applied to bluetooth-next tree.
Regards
Marcel
On Wed, Oct 5, 2016 at 1:58 PM, Mickaël Salaün wrote:
>
>
> On 04/10/2016 01:43, Kees Cook wrote:
>> On Wed, Sep 14, 2016 at 12:24 AM, Mickaël Salaün wrote:
>>> This allows to add new eBPF programs to Landlock hooks dedicated to a
>>> cgroup thanks to the BPF_PROG_ATTACH command. Like for socket
On Wed, 2016-10-05 at 22:56 +0200, Michal Sojka wrote:
> this commit is now in mainline as
> e3b37f11e6e4e6b6f02cc762f182ce233d2c1c9d and it breaks my build:
>
> net/netfilter/core.c: In function 'nf_set_hooks_head':
> net/netfilter/core.c:96:3: error: 'struct net_device' has no member na
On Wed, 5 Oct 2016 15:21:32 -0400, Eric Garver wrote:
> How about this incremental change?
Feel free to submit it as a standalone patch. It has nothing to do with
this patchset. In this particular regard, the code is identical before
and after the patchset and is in no way altered by this patch.
On 04/10/2016 01:52, Kees Cook wrote:
> On Wed, Sep 14, 2016 at 3:34 PM, Mickaël Salaün wrote:
>>
>> On 14/09/2016 20:43, Andy Lutomirski wrote:
>>> On Wed, Sep 14, 2016 at 12:24 AM, Mickaël Salaün wrote:
A Landlock program will be triggered according to its subtype/origin
bitfield. T
Hi,
On Tue, Oct 04 2016, Sergey Senozhatsky wrote:
> On (09/27/16 19:03), Sergey Senozhatsky wrote:
>> Hello,
>>
>> On (09/27/16 16:40), Stephen Rothwell wrote:
>> >
>> > Changes since 20160923:
>> >
>>
>> seems that commit e3b37f11e6e4e6b6 ("netfilter: replace list_head with
>> single linked
On 04/10/2016 01:46, Kees Cook wrote:
> On Wed, Sep 14, 2016 at 6:19 PM, Andy Lutomirski wrote:
>> On Wed, Sep 14, 2016 at 3:14 PM, Mickaël Salaün wrote:
>>>
>>> On 14/09/2016 20:29, Andy Lutomirski wrote:
On Wed, Sep 14, 2016 at 12:24 AM, Mickaël Salaün wrote:
> This third origin of h
On 04/10/2016 01:43, Kees Cook wrote:
> On Wed, Sep 14, 2016 at 12:24 AM, Mickaël Salaün wrote:
>> This allows to add new eBPF programs to Landlock hooks dedicated to a
>> cgroup thanks to the BPF_PROG_ATTACH command. Like for socket eBPF
>> programs, the Landlock hooks attached to a cgroup are
bluetooth.h is not part of user API, so __ variants are not neccessary
here.
Signed-off-by: Pavel Machek
---
v2: not touching stuff that Marcel does not want touched, as it will
become API later.
diff --git a/include/net/bluetooth/bluetooth.h
b/include/net/bluetooth/bluetooth.h
index bfd1590.
On 04/10/2016 00:56, Kees Cook wrote:
> On Tue, Sep 20, 2016 at 10:08 AM, Mickaël Salaün wrote:
>>
>> On 15/09/2016 11:19, Pavel Machek wrote:
>>> Hi!
>>>
This series is a proof of concept to fill some missing part of seccomp as
the
ability to check syscall argument pointers or cr
On Thu, 2016-10-06 at 04:13 +0900, Eric Dumazet wrote:
> From: Eric Dumazet
>
> Since linux-3.15, netlink_dump() can use up to 16384 bytes skb
> allocations.
>
> Due to struct skb_shared_info ~320 bytes overhead, we end up using
> order-3 (on x86) page allocations, that might trigger direct recl
> -Original Message-
> From: David Laight [mailto:david.lai...@aculab.com]
> Sent: Tuesday, October 04, 2016 5:44 PM
> To: Madalin-Cristian Bucur ;
> netdev@vger.kernel.org
> Cc: linuxdev.baldr...@gmail.com; linuxppc-...@lists.ozlabs.org;
> da...@davemloft.net; linux-ker...@vger.kernel.org
On Wed, 2016-10-05 at 09:06 -0400, Alex Sidorenko wrote:
> Roundrobin runner of team driver uses 'unsigned int' variable to count the
> number of sent_packets.
> Later it is passed to a subroutine team_num_to_port_index(struct team *team,
> int num) as
> 'num' and when we reach MAXINT (2**31-1),
During the conversion to the feature flags, a check against
ci->id != BCMA_CHIP_ID_BCM47162
became
bgmac->feature_flags & BGMAC_FEAT_CLKCTLS
instead of
!(bgmac->feature_flags & BGMAC_FEAT_CLKCTLS)
Reported-by: Rafał Miłecki
Signed-off-by: Jon Mason
---
drivers/net/ethernet/broadcom/bgmac.c | 2
On Wed, Oct 05, 2016 at 09:07:09PM +0200, Jiri Benc wrote:
> On Wed, 5 Oct 2016 14:44:26 -0400, Eric Garver wrote:
> > On Wed, Oct 05, 2016 at 08:31:52PM +0300, Eyal Birger wrote:
> > > Just seemed less future safe to keep a pointer to an old packet lying
> > > around.
> >
> > I agree. Alternativ
On Wed, 2016-10-05 at 21:11 +0200, Pavel Machek wrote:
> On Wed 2016-10-05 10:53:16, Joe Perches wrote:
> > On Wed, 2016-10-05 at 13:14 +0200, Marcel Holtmann wrote:
> > > Hi Pavel,
> > >
> > > > bluetooth.h is not part of user API, so __ variants are not neccessary
> > > > here.
> > > >
> > > >
From: Eric Dumazet
Since linux-3.15, netlink_dump() can use up to 16384 bytes skb
allocations.
Due to struct skb_shared_info ~320 bytes overhead, we end up using
order-3 (on x86) page allocations, that might trigger direct reclaim and
add stress.
The intent was really to attempt a large allocat
On Wed 2016-10-05 10:53:16, Joe Perches wrote:
> On Wed, 2016-10-05 at 13:14 +0200, Marcel Holtmann wrote:
> > Hi Pavel,
> >
> > > bluetooth.h is not part of user API, so __ variants are not neccessary
> > > here.
> > >
> > > Signed-off-by: Pavel Machek
> > >
> > > diff --git a/include/net/blue
On Wed, 5 Oct 2016 14:44:26 -0400, Eric Garver wrote:
> On Wed, Oct 05, 2016 at 08:31:52PM +0300, Eyal Birger wrote:
> > Just seemed less future safe to keep a pointer to an old packet lying
> > around.
>
> I agree. Alternatively refresh the eth pointer.
Sorry guys, that just doesn't make sense.
On Wed, Oct 05, 2016 at 08:31:52PM +0300, Eyal Birger wrote:
> On Wed, Oct 5, 2016 at 8:23 PM, Jiri Benc wrote:
> > On Wed, 5 Oct 2016 17:18:08 +0300, Eyal Birger wrote:
> >> I think at this point, 'eth' may point to a freed packet.
> >
> > It may but how does that matter? eth is not used beyond t
On Wed, Oct 5, 2016 at 11:01 AM, Cong Wang wrote:
> On Tue, Oct 4, 2016 at 11:52 PM, Krister Johansen
> wrote:
>> On Mon, Oct 03, 2016 at 11:22:33AM -0700, Cong Wang wrote:
>>> Please try the attached patch. I also convert the read path to RCU
>>> to avoid a possible deadlock. A quick test shows
On Tue, Oct 4, 2016 at 11:52 PM, Krister Johansen
wrote:
> On Mon, Oct 03, 2016 at 11:22:33AM -0700, Cong Wang wrote:
>> Please try the attached patch. I also convert the read path to RCU
>> to avoid a possible deadlock. A quick test shows no lockdep splat.
>
> I tried this patch, but it doesn't s
On Wed, 2016-10-05 at 13:14 +0200, Marcel Holtmann wrote:
> Hi Pavel,
>
> > bluetooth.h is not part of user API, so __ variants are not neccessary
> > here.
> >
> > Signed-off-by: Pavel Machek
> >
> > diff --git a/include/net/bluetooth/bluetooth.h
> > b/include/net/bluetooth/bluetooth.h
[]
> >
On Wed, Oct 5, 2016 at 8:23 PM, Jiri Benc wrote:
> On Wed, 5 Oct 2016 17:18:08 +0300, Eyal Birger wrote:
>> I think at this point, 'eth' may point to a freed packet.
>
> It may but how does that matter? eth is not used beyond that point.
Definitely a nit. For sure not critical.
Just seemed less
On Wed, 5 Oct 2016 17:18:08 +0300, Eyal Birger wrote:
> I think at this point, 'eth' may point to a freed packet.
It may but how does that matter? eth is not used beyond that point.
Jiri
On Wed, Oct 05, 2016 at 07:02:21AM +, Koehrer Mathias (ETAS/ESW5) wrote:
> Hi Julia,
>
> > > In the meanwhile I have detected another finding which might be relevant:
> > >
> > > With the 3.18 kernel the igb driver comes with two interrupts per
> > > NIC (e.g. eth2 and eth2-TxRx0) with the 4.6
On Wed, Oct 05, 2016 at 05:30:26PM +0200, Roger Pau Monné wrote:
> [...]
> Also, IIRC NetBSD doesn't have a Xen GSO implementation [1], but I would let
> Manuel answer that one.
I confirm, we don't support GSO at this time.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la d
On Tue, Oct 04, 2016 at 10:24:04AM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 04, 2016 at 01:35:41PM +, Paul Durrant wrote:
> > > -Original Message-
> > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > > Sent: 04 October 2016 13:52
> > > To: Paul Durrant ; annie.
Hi,
On Wed, Oct 5, 2016 at 4:07 PM, Jiri Benc wrote:
> diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
> index 4d67ea856067..c47b3da8ecf2 100644
> --- a/net/openvswitch/datapath.c
> +++ b/net/openvswitch/datapath.c
> @@ -594,6 +594,16 @@ static int ovs_packet_cmd_execute(stru
If a socket has FANOUT sockopt set, a new proto_hook is registered
as part of fanout_add(). When processing a NETDEV_UNREGISTER event in
af_packet, __fanout_unlink is called for all sockets, but prot_hook which was
registered as part of fanout_add is not removed. Call fanout_release, on a
NETDEV_UN
On Wed, 2016-10-05 at 08:29 +, Koehrer Mathias (ETAS/ESW5) wrote:
> Hi all,
>
> I noticed that with fairly new versions of the Linux kernel, the igb driver
> causes huge latencies with the cyclictest in a RT_PREEMPT environment.
> The root cause seems to be the number of interrupts that are us
The KSZ9031 skew registers contain an offset, the chip's default value
is "neutral" which does not add any skew. Programming a 0 into a skew
property will actually set it the maximal negative adjustment and not
to a neutral position as one would expect.
Explain this situation in the devicetree bin
On 10/03/2016 08:19 PM, David Miller wrote:
> From: "Baron, Jason"
> Date: Mon, 3 Oct 2016 20:24:32 +
>
>> Or should I just send the incremental at this point?
> Incremental is required at this point.
Hi David,
Ok. The above question was sent out erroneously. I have already posted
the incr
Hi Sergei, David,
I think modifying that as below is clear and scalable. Agree?
static bool mtk_is_hwlro_supported(struct mtk_eth *eth)
{
switch (eth->chip_id) {
case MT7623_ETH:
return true;
}
return false;
}
Thanks.
Nelson
-Original Messag
From: Nelson Chang
> Sent: 05 October 2016 13:46
> > +static bool mtk_is_hwlro_supported(struct mtk_eth *eth) {
> > + if (eth->chip_id == MT7623_ETH)
> > + return true;
> > + else
> > + return false;
>
> return eth->chip_id == MT7623_ETH;
>
> => Since there
When the packet has its vlan tag in skb->vlan_tci, the length of the VLAN
header is not counted in skb->len. It doesn't make sense to subtract it.
In addition, to honor the comment below the code, the VLAN header length
should not be subtracted if there's a vlan tag in skb->vlan_tci. This leads
to
Always keep the first vlan tag "accelerated", i.e. in skb->vlan_tci. This
simplifies things considerably.
v2: added the first patch
Jiri Benc (3):
openvswitch: normalize vlan rx path
openvswitch: remove unreachable code in vlan parsing
openvswitch: fix vlan subtraction from packet length
Now when the first vlan tag is always in skb->vlan_tci, drop code that
assumed it might not be the case.
This patch also removes the wrong likely() statement around
skb_vlan_tag_present introduced by 018c1dda5ff1 ("openvswitch: 802.1AD Flow
handling, actions, vlan parsing, netlink attributes"). Th
Roundrobin runner of team driver uses 'unsigned int' variable to count the
number of sent_packets.
Later it is passed to a subroutine team_num_to_port_index(struct team *team,
int num) as
'num' and when we reach MAXINT (2**31-1), 'num' becomes negative.
This leads to using incorrect hash-bucket
Similarly to how the core networking stack behaves, let the first vlan tag
be always stored in skb->vlan_tci. This is already ensured in
__netif_receive_skb_core for packets that were received from the kernel and
honored by skb_vlan_push and skb_vlan_pop. The only remaining place are
packets receiv
If mpls headers were pushed to a defragmented packet, the refragmentation no
longer works correctly after 48d2ab609b6b ("net: mpls: Fixups for GSO"). The
network header has to be shifted after the mpls headers for the
fragmentation and restored afterwards.
Fixes: 48d2ab609b6b ("net: mpls: Fixups f
On 10/05/2016 03:46 PM, Nelson Chang wrote:
+static bool mtk_is_hwlro_supported(struct mtk_eth *eth) {
+ if (eth->chip_id == MT7623_ETH)
+ return true;
+ else
+ return false;
return eth->chip_id == MT7623_ETH;
=> Since there will be more chips support h
On Tue, 4 Oct 2016 20:06:18 -0400, Eric Garver wrote:
> This code is also called for packets passed back down from userspace
> (after the flow key miss and upcall). So it does happen that we have a
> skb without skb->vlan_tci set.
That sucks. The vlan handling should be really consistent, Jiri Pir
On Tue, 4 Oct 2016 19:03:46 -0700, Pravin Shelar wrote:
> We could have encapsulated packet defragmented in physical bridge.
> that mean the packet is entering OVS after egressing tunnel device.
> That use case would break due to this patch.
Okay, thanks for explanation. I missed this use case and
Hi Sergei,
Sorry, miss that.
> +static bool mtk_is_hwlro_supported(struct mtk_eth *eth) {
> + if (eth->chip_id == MT7623_ETH)
> + return true;
> + else
> + return false;
return eth->chip_id == MT7623_ETH;
=> Since there will be more chips support hw lro i
Hi Sergei,
Thanks for your comments.
Modified.
Nelson
-Original Message-
From: Sergei Shtylyov [mailto:sergei.shtyl...@cogentembedded.com]
Sent: Wednesday, October 05, 2016 8:18 PM
To: Nelson Chang (張家祥); j...@phrozen.org; da...@davemloft.net
Cc: n...@openwrt.org; netdev@vger.kernel.or
The driver gets the chip id by ETHSYS_CHIPID0_3/ETHSYS_CHIPID4_7 registers
in mtk_probe().
Signed-off-by: Nelson Chang
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 29 +
drivers/net/ethernet/mediatek/mtk_eth_soc.h | 5 +
2 files changed, 34 insertions(+)
di
Because hw lro started to be supported from MT7623, the proper way to check if
the feature is capable is to judge by the chip id instead of by the dtsi.
Signed-off-by: Nelson Chang
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 12 ++--
drivers/net/ethernet/mediatek/mtk_eth_soc.h | 1
The series modify to check if hw lro is supported by the chip id.
changes since v2:
- Refine mtk_get_chip_id() function
changes since v1:
- Because hw lro started to be supported from MT7623, the proper way to check
if the feature is capable is to judge by the chip id instead of by the dtsi.
Ne
Since the proper way to check the hw lro capability is by the chip id,
hwlro property in the device tree should be removed.
Signed-off-by: Nelson Chang
---
Documentation/devicetree/bindings/net/mediatek-net.txt | 2 --
1 file changed, 2 deletions(-)
diff --git a/Documentation/devicetree/binding
Hello.
On 10/05/2016 03:12 PM, Nelson Chang wrote:
Because hw lro started to be supported from MT7623, the proper way to check if
the feature is capable is to judge by the chip id instead of by the dtsi.
Signed-off-by: Nelson Chang
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 12 +++
The series modify to check if hw lro is supported by the chip id.
changes since v2:
- Refine mtk_get_chip_id() function
changes since v1:
- Because hw lro started to be supported from MT7623, the proper way to check
if the feature is capable is to judge by the chip id instead of by the dtsi.
Ne
Since the proper way to check the hw lro capability is by the chip id,
hwlro property in the device tree should be removed.
Signed-off-by: Nelson Chang
---
Documentation/devicetree/bindings/net/mediatek-net.txt | 2 --
1 file changed, 2 deletions(-)
diff --git a/Documentation/devicetree/binding
The driver gets the chip id by ETHSYS_CHIPID0_3/ETHSYS_CHIPID4_7 registers
in mtk_probe().
Signed-off-by: Nelson Chang
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 29 +
drivers/net/ethernet/mediatek/mtk_eth_soc.h | 5 +
2 files changed, 34 insertions(+)
di
Because hw lro started to be supported from MT7623, the proper way to check if
the feature is capable is to judge by the chip id instead of by the dtsi.
Signed-off-by: Nelson Chang
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 12 ++--
drivers/net/ethernet/mediatek/mtk_eth_soc.h | 1
> - As per review comment, Added DT vddmac, slowdown value error check.
So i said an exact match, which this is not.
How about something like:
static u8 vsc85xx_edge_rate_magic_get(u16 vddmac, u8 slowdown)
{
u8 vdd;
u8 sd;
for (vdd = 0; vdd < ARRAY_SIZE(edge_table); vdd
On Wed, 2016-10-05 at 13:40 +0200, michael-dev wrote:
> Am 05.10.2016 12:19, schrieb Johannes Berg:
> >
> > >
> > > on both ends. Furthermore, I've seen a few mobile phone stations
> > > locally that indicate qos support but won't complete DHCP if
> > > their broadcasts are encapsulated as A-MSDU
Am 05.10.2016 12:19, schrieb Johannes Berg:
on both ends. Furthermore, I've seen a few mobile phone stations
locally that indicate qos support but won't complete DHCP if their
broadcasts are encapsulated as A-MSDU. Though they work fine with
this series approach.
Presumably those phones also do
From: Raju Lakkaraju
Edge-rate:
As system and networking speeds increase, a signal's output transition,
also know as the edge rate or slew rate (V/ns), takes on greater importance
because high-speed signals come with a price. That price is an assortment of
interference problems like ringing on th
Hi Pavel,
> bluetooth.h is not part of user API, so __ variants are not neccessary
> here.
>
> Signed-off-by: Pavel Machek
>
> diff --git a/include/net/bluetooth/bluetooth.h
> b/include/net/bluetooth/bluetooth.h
> index bfd1590..aea0371 100644
> --- a/include/net/bluetooth/bluetooth.h
> +++ b/
Wed, Oct 05, 2016 at 02:29:27AM CEST, da...@davemloft.net wrote:
>From: Jiri Pirko
>Date: Tue, 4 Oct 2016 09:46:03 +0200
>
>> Couple of fixes from Yotam.
>
>Series applied, thanks.
>
>Note that needed_headroom is a request, rather than a guarantee, so you
>may in some rare cases need to realloc y
I am testing 4.8 on my sparcs and got this on Sun V210 (sparc64). This
is reproducible. 4.8.0-rc3-00013 did not have this problem, will bisect
when I get some time.
[ 74.123859] tg3.c:v3.137 (May 11, 2014)
[ 74.123880] PCI: Enabling device: (:00:02.0), cmd 2
[ 74.315794] tg3 :00:02
1 - 100 of 110 matches
Mail list logo
