<feed xmlns='http://www.w3.org/2005/Atom'>
<title>litmus-rt.git/drivers/net, branch master</title>
<subtitle>The LITMUS^RT kernel.</subtitle>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/'/>
<entry>
<title>net: mvneta: disable IP checksum with jumbo frames for Armada 370</title>
<updated>2015-07-10T16:49:33+00:00</updated>
<author>
<name>Simon Guinot</name>
<email>simon.guinot@sequanux.org</email>
</author>
<published>2015-06-30T14:20:22+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=bfa06e6258be556d44aad030fe1babeed4f92240'/>
<id>bfa06e6258be556d44aad030fe1babeed4f92240</id>
<content type='text'>
[ Upstream commit b65657fc240ae6c1d2a1e62db9a0e61ac9631d7a ]

The Ethernet controller found in the Armada 370, 380 and 385 SoCs don't
support TCP/IP checksumming with frame sizes larger than 1600 bytes.

This patch fixes the issue by disabling the features NETIF_F_IP_CSUM and
NETIF_F_TSO for the Armada 370 and compatibles SoCs when the MTU is set
to a value greater than 1600 bytes.

Signed-off-by: Simon Guinot &lt;simon.guinot@sequanux.org&gt;
Fixes: c5aff18204da ("net: mvneta: driver for Marvell Armada 370/XP network unit")
Cc: &lt;stable@vger.kernel.org&gt; # v3.8+
Acked-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit b65657fc240ae6c1d2a1e62db9a0e61ac9631d7a ]

The Ethernet controller found in the Armada 370, 380 and 385 SoCs don't
support TCP/IP checksumming with frame sizes larger than 1600 bytes.

This patch fixes the issue by disabling the features NETIF_F_IP_CSUM and
NETIF_F_TSO for the Armada 370 and compatibles SoCs when the MTU is set
to a value greater than 1600 bytes.

Signed-off-by: Simon Guinot &lt;simon.guinot@sequanux.org&gt;
Fixes: c5aff18204da ("net: mvneta: driver for Marvell Armada 370/XP network unit")
Cc: &lt;stable@vger.kernel.org&gt; # v3.8+
Acked-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: mvneta: introduce compatible string "marvell, armada-xp-neta"</title>
<updated>2015-07-10T16:49:32+00:00</updated>
<author>
<name>Simon Guinot</name>
<email>simon.guinot@sequanux.org</email>
</author>
<published>2015-06-30T14:20:20+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=b5aded8311788994641bd1d04b4b922f9c202b8f'/>
<id>b5aded8311788994641bd1d04b4b922f9c202b8f</id>
<content type='text'>
[ Upstream commit f522a975a8101895a85354b9c143f41b8248e71a ]

The mvneta driver supports the Ethernet IP found in the Armada 370, XP,
380 and 385 SoCs. Since at least one more hardware feature is available
for the Armada XP SoCs then a way to identify them is needed.

This patch introduces a new compatible string "marvell,armada-xp-neta".

Signed-off-by: Simon Guinot &lt;simon.guinot@sequanux.org&gt;
Fixes: c5aff18204da ("net: mvneta: driver for Marvell Armada 370/XP network unit")
Cc: &lt;stable@vger.kernel.org&gt; # v3.8+
Acked-by: Gregory CLEMENT &lt;gregory.clement@free-electrons.com&gt;
Acked-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit f522a975a8101895a85354b9c143f41b8248e71a ]

The mvneta driver supports the Ethernet IP found in the Armada 370, XP,
380 and 385 SoCs. Since at least one more hardware feature is available
for the Armada XP SoCs then a way to identify them is needed.

This patch introduces a new compatible string "marvell,armada-xp-neta".

Signed-off-by: Simon Guinot &lt;simon.guinot@sequanux.org&gt;
Fixes: c5aff18204da ("net: mvneta: driver for Marvell Armada 370/XP network unit")
Cc: &lt;stable@vger.kernel.org&gt; # v3.8+
Acked-by: Gregory CLEMENT &lt;gregory.clement@free-electrons.com&gt;
Acked-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>amd-xgbe: Add the __GFP_NOWARN flag to Rx buffer allocation</title>
<updated>2015-07-10T16:49:32+00:00</updated>
<author>
<name>Tom Lendacky</name>
<email>thomas.lendacky@amd.com</email>
</author>
<published>2015-06-29T16:22:12+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=8c6e5415f83cb5ba0da1321ec743b650c8a16764'/>
<id>8c6e5415f83cb5ba0da1321ec743b650c8a16764</id>
<content type='text'>
[ Upstream commit 472cfe7127760d68b819cf35a26e5a1b44b30f4e ]

When allocating Rx related buffers, alloc_pages is called using an order
number that is decreased until successful. A system under stress can
experience failures during this allocation process resulting in a warning
being issued. This message can be of concern to end users even though the
failure is not fatal. Since the failure is not fatal and can occur
multiple times, the driver should include the __GFP_NOWARN flag to
suppress the warning message from being issued.

Signed-off-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 472cfe7127760d68b819cf35a26e5a1b44b30f4e ]

When allocating Rx related buffers, alloc_pages is called using an order
number that is decreased until successful. A system under stress can
experience failures during this allocation process resulting in a warning
being issued. This message can be of concern to end users even though the
failure is not fatal. Since the failure is not fatal and can occur
multiple times, the driver should include the __GFP_NOWARN flag to
suppress the warning message from being issued.

Signed-off-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bnx2x: fix lockdep splat</title>
<updated>2015-07-10T16:49:31+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2015-06-26T05:32:29+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=7e2a3d667c4c9ca494c73f5930365240a31c4eb0'/>
<id>7e2a3d667c4c9ca494c73f5930365240a31c4eb0</id>
<content type='text'>
[ Upstream commit d53c66a5b80698620f7c9ba2372fff4017e987b8 ]

Michel reported following lockdep splat

[   44.718117] INFO: trying to register non-static key.
[   44.723081] the code is fine but needs lockdep annotation.
[   44.728559] turning off the locking correctness validator.
[   44.734036] CPU: 8 PID: 5483 Comm: ethtool Not tainted 4.1.0
[   44.770289] Call Trace:
[   44.772741]  [&lt;ffffffff816eb1cd&gt;] dump_stack+0x4c/0x65
[   44.777879]  [&lt;ffffffff8111d921&gt;] ? console_unlock+0x1f1/0x510
[   44.783708]  [&lt;ffffffff811121f5&gt;] __lock_acquire+0x1d05/0x1f10
[   44.789538]  [&lt;ffffffff8111370a&gt;] ? mark_held_locks+0x6a/0x90
[   44.795276]  [&lt;ffffffff81113835&gt;] ? trace_hardirqs_on_caller+0x105/0x1d0
[   44.801967]  [&lt;ffffffff8111390d&gt;] ? trace_hardirqs_on+0xd/0x10
[   44.807793]  [&lt;ffffffff811330fa&gt;] ? hrtimer_try_to_cancel+0x4a/0x250
[   44.814142]  [&lt;ffffffff81112ba6&gt;] lock_acquire+0xb6/0x290
[   44.819537]  [&lt;ffffffff810d6675&gt;] ? flush_work+0x5/0x280
[   44.824844]  [&lt;ffffffff810d66ad&gt;] flush_work+0x3d/0x280
[   44.830061]  [&lt;ffffffff810d6675&gt;] ? flush_work+0x5/0x280
[   44.835366]  [&lt;ffffffff816f3c43&gt;] ? schedule_hrtimeout_range+0x13/0x20
[   44.841889]  [&lt;ffffffff8112ec9b&gt;] ? usleep_range+0x4b/0x50
[   44.847365]  [&lt;ffffffff8111370a&gt;] ? mark_held_locks+0x6a/0x90
[   44.853102]  [&lt;ffffffff810d8585&gt;] ? __cancel_work_timer+0x105/0x1c0
[   44.859359]  [&lt;ffffffff81113835&gt;] ? trace_hardirqs_on_caller+0x105/0x1d0
[   44.866045]  [&lt;ffffffff810d851f&gt;] __cancel_work_timer+0x9f/0x1c0
[   44.872048]  [&lt;ffffffffa0010982&gt;] ? bnx2x_func_stop+0x42/0x90 [bnx2x]
[   44.878481]  [&lt;ffffffff810d8670&gt;] cancel_work_sync+0x10/0x20
[   44.884134]  [&lt;ffffffffa00259e5&gt;] bnx2x_chip_cleanup+0x245/0x730 [bnx2x]
[   44.890829]  [&lt;ffffffff8110ce02&gt;] ? up+0x32/0x50
[   44.895439]  [&lt;ffffffff811306b5&gt;] ? del_timer_sync+0x5/0xd0
[   44.901005]  [&lt;ffffffffa005596d&gt;] bnx2x_nic_unload+0x20d/0x8e0 [bnx2x]
[   44.907527]  [&lt;ffffffff811f1aef&gt;] ? might_fault+0x5f/0xb0
[   44.912921]  [&lt;ffffffffa005851c&gt;] bnx2x_reload_if_running+0x2c/0x50 [bnx2x]
[   44.919879]  [&lt;ffffffffa005a3c5&gt;] bnx2x_set_ringparam+0x2b5/0x460 [bnx2x]
[   44.926664]  [&lt;ffffffff815d498b&gt;] dev_ethtool+0x55b/0x1c40
[   44.932148]  [&lt;ffffffff815dfdc7&gt;] ? rtnl_lock+0x17/0x20
[   44.937364]  [&lt;ffffffff815e7f8b&gt;] dev_ioctl+0x17b/0x630
[   44.942582]  [&lt;ffffffff815abf8d&gt;] sock_do_ioctl+0x5d/0x70
[   44.947972]  [&lt;ffffffff815ac013&gt;] sock_ioctl+0x73/0x280
[   44.953192]  [&lt;ffffffff8124c1c8&gt;] do_vfs_ioctl+0x88/0x5b0
[   44.958587]  [&lt;ffffffff8110d0b3&gt;] ? up_read+0x23/0x40
[   44.963631]  [&lt;ffffffff812584cc&gt;] ? __fget_light+0x6c/0xa0
[   44.969105]  [&lt;ffffffff8124c781&gt;] SyS_ioctl+0x91/0xb0
[   44.974149]  [&lt;ffffffff816f4dd7&gt;] system_call_fastpath+0x12/0x6f

As bnx2x_init_ptp() is only called if bp-&gt;flags contains PTP_SUPPORTED,
we also need to guard bnx2x_stop_ptp() with same condition, otherwise
ptp_task workqueue is not initialized and kernel barfs on
cancel_work_sync()

Fixes: eeed018cbfa30 ("bnx2x: Add timestamping and PTP hardware clock support")
Reported-by: Michel Lespinasse &lt;walken@google.com&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Michal Kalderon &lt;Michal.Kalderon@qlogic.com&gt;
Cc: Ariel Elior &lt;Ariel.Elior@qlogic.com&gt;
Cc: Yuval Mintz &lt;Yuval.Mintz@qlogic.com&gt;
Cc: David Decotigny &lt;decot@google.com&gt;
Acked-by: Sony Chacko &lt;sony.chacko@qlogic.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit d53c66a5b80698620f7c9ba2372fff4017e987b8 ]

Michel reported following lockdep splat

[   44.718117] INFO: trying to register non-static key.
[   44.723081] the code is fine but needs lockdep annotation.
[   44.728559] turning off the locking correctness validator.
[   44.734036] CPU: 8 PID: 5483 Comm: ethtool Not tainted 4.1.0
[   44.770289] Call Trace:
[   44.772741]  [&lt;ffffffff816eb1cd&gt;] dump_stack+0x4c/0x65
[   44.777879]  [&lt;ffffffff8111d921&gt;] ? console_unlock+0x1f1/0x510
[   44.783708]  [&lt;ffffffff811121f5&gt;] __lock_acquire+0x1d05/0x1f10
[   44.789538]  [&lt;ffffffff8111370a&gt;] ? mark_held_locks+0x6a/0x90
[   44.795276]  [&lt;ffffffff81113835&gt;] ? trace_hardirqs_on_caller+0x105/0x1d0
[   44.801967]  [&lt;ffffffff8111390d&gt;] ? trace_hardirqs_on+0xd/0x10
[   44.807793]  [&lt;ffffffff811330fa&gt;] ? hrtimer_try_to_cancel+0x4a/0x250
[   44.814142]  [&lt;ffffffff81112ba6&gt;] lock_acquire+0xb6/0x290
[   44.819537]  [&lt;ffffffff810d6675&gt;] ? flush_work+0x5/0x280
[   44.824844]  [&lt;ffffffff810d66ad&gt;] flush_work+0x3d/0x280
[   44.830061]  [&lt;ffffffff810d6675&gt;] ? flush_work+0x5/0x280
[   44.835366]  [&lt;ffffffff816f3c43&gt;] ? schedule_hrtimeout_range+0x13/0x20
[   44.841889]  [&lt;ffffffff8112ec9b&gt;] ? usleep_range+0x4b/0x50
[   44.847365]  [&lt;ffffffff8111370a&gt;] ? mark_held_locks+0x6a/0x90
[   44.853102]  [&lt;ffffffff810d8585&gt;] ? __cancel_work_timer+0x105/0x1c0
[   44.859359]  [&lt;ffffffff81113835&gt;] ? trace_hardirqs_on_caller+0x105/0x1d0
[   44.866045]  [&lt;ffffffff810d851f&gt;] __cancel_work_timer+0x9f/0x1c0
[   44.872048]  [&lt;ffffffffa0010982&gt;] ? bnx2x_func_stop+0x42/0x90 [bnx2x]
[   44.878481]  [&lt;ffffffff810d8670&gt;] cancel_work_sync+0x10/0x20
[   44.884134]  [&lt;ffffffffa00259e5&gt;] bnx2x_chip_cleanup+0x245/0x730 [bnx2x]
[   44.890829]  [&lt;ffffffff8110ce02&gt;] ? up+0x32/0x50
[   44.895439]  [&lt;ffffffff811306b5&gt;] ? del_timer_sync+0x5/0xd0
[   44.901005]  [&lt;ffffffffa005596d&gt;] bnx2x_nic_unload+0x20d/0x8e0 [bnx2x]
[   44.907527]  [&lt;ffffffff811f1aef&gt;] ? might_fault+0x5f/0xb0
[   44.912921]  [&lt;ffffffffa005851c&gt;] bnx2x_reload_if_running+0x2c/0x50 [bnx2x]
[   44.919879]  [&lt;ffffffffa005a3c5&gt;] bnx2x_set_ringparam+0x2b5/0x460 [bnx2x]
[   44.926664]  [&lt;ffffffff815d498b&gt;] dev_ethtool+0x55b/0x1c40
[   44.932148]  [&lt;ffffffff815dfdc7&gt;] ? rtnl_lock+0x17/0x20
[   44.937364]  [&lt;ffffffff815e7f8b&gt;] dev_ioctl+0x17b/0x630
[   44.942582]  [&lt;ffffffff815abf8d&gt;] sock_do_ioctl+0x5d/0x70
[   44.947972]  [&lt;ffffffff815ac013&gt;] sock_ioctl+0x73/0x280
[   44.953192]  [&lt;ffffffff8124c1c8&gt;] do_vfs_ioctl+0x88/0x5b0
[   44.958587]  [&lt;ffffffff8110d0b3&gt;] ? up_read+0x23/0x40
[   44.963631]  [&lt;ffffffff812584cc&gt;] ? __fget_light+0x6c/0xa0
[   44.969105]  [&lt;ffffffff8124c781&gt;] SyS_ioctl+0x91/0xb0
[   44.974149]  [&lt;ffffffff816f4dd7&gt;] system_call_fastpath+0x12/0x6f

As bnx2x_init_ptp() is only called if bp-&gt;flags contains PTP_SUPPORTED,
we also need to guard bnx2x_stop_ptp() with same condition, otherwise
ptp_task workqueue is not initialized and kernel barfs on
cancel_work_sync()

Fixes: eeed018cbfa30 ("bnx2x: Add timestamping and PTP hardware clock support")
Reported-by: Michel Lespinasse &lt;walken@google.com&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Michal Kalderon &lt;Michal.Kalderon@qlogic.com&gt;
Cc: Ariel Elior &lt;Ariel.Elior@qlogic.com&gt;
Cc: Yuval Mintz &lt;Yuval.Mintz@qlogic.com&gt;
Cc: David Decotigny &lt;decot@google.com&gt;
Acked-by: Sony Chacko &lt;sony.chacko@qlogic.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: phy: fix phy link up when limiting speed via device tree</title>
<updated>2015-07-10T16:49:31+00:00</updated>
<author>
<name>Mugunthan V N</name>
<email>mugunthanvnm@ti.com</email>
</author>
<published>2015-06-25T16:51:02+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=6c10c84170c40bf3d4a9953ae5a2ffe59ad736d4'/>
<id>6c10c84170c40bf3d4a9953ae5a2ffe59ad736d4</id>
<content type='text'>
[ Upstream commit eb686231fce3770299760f24fdcf5ad041f44153 ]

When limiting phy link speed using "max-speed" to 100mbps or less on a
giga bit phy, phy never completes auto negotiation and phy state
machine is held in PHY_AN. Fixing this issue by comparing the giga
bit advertise though phydev-&gt;supported doesn't have it but phy has
BMSR_ESTATEN set. So that auto negotiation is restarted as old and
new advertise are different and link comes up fine.

Signed-off-by: Mugunthan V N &lt;mugunthanvnm@ti.com&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit eb686231fce3770299760f24fdcf5ad041f44153 ]

When limiting phy link speed using "max-speed" to 100mbps or less on a
giga bit phy, phy never completes auto negotiation and phy state
machine is held in PHY_AN. Fixing this issue by comparing the giga
bit advertise though phydev-&gt;supported doesn't have it but phy has
BMSR_ESTATEN set. So that auto negotiation is restarted as old and
new advertise are different and link comes up fine.

Signed-off-by: Mugunthan V N &lt;mugunthanvnm@ti.com&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mlx4: Disable HA for SRIOV PF RoCE devices</title>
<updated>2015-07-10T16:49:30+00:00</updated>
<author>
<name>Or Gerlitz</name>
<email>ogerlitz@mellanox.com</email>
</author>
<published>2015-06-25T08:29:44+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=62a9ad17a245002cc611fc4667c2919ef422d8ee'/>
<id>62a9ad17a245002cc611fc4667c2919ef422d8ee</id>
<content type='text'>
[ Upstream commit 7254acffeeec3c0a75b9c5364c29a6eb00014930 ]

When in HA mode, the driver exposes an IB (RoCE) device instance with only
one port. Under SRIOV, the existing implementation doesn't go well with
the PF RoCE driver's role of Special QPs Para-Virtualization, etc.

As such, disable HA for the mlx4 PF RoCE device in SRIOV mode.

Fixes: a57500903093 ('IB/mlx4: Add port aggregation support')
Signed-off-by: Or Gerlitz &lt;ogerlitz@mellanox.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 7254acffeeec3c0a75b9c5364c29a6eb00014930 ]

When in HA mode, the driver exposes an IB (RoCE) device instance with only
one port. Under SRIOV, the existing implementation doesn't go well with
the PF RoCE driver's role of Special QPs Para-Virtualization, etc.

As such, disable HA for the mlx4 PF RoCE device in SRIOV mode.

Fixes: a57500903093 ('IB/mlx4: Add port aggregation support')
Signed-off-by: Or Gerlitz &lt;ogerlitz@mellanox.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net/mlx4_en: Fix wrong csum complete report when rxvlan offload is disabled</title>
<updated>2015-07-10T16:49:30+00:00</updated>
<author>
<name>Ido Shamay</name>
<email>idos@mellanox.com</email>
</author>
<published>2015-06-25T08:29:43+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=1b74080050336e29a82abc2a9b2e1f901485a362'/>
<id>1b74080050336e29a82abc2a9b2e1f901485a362</id>
<content type='text'>
[ Upstream commit 79a258526ce1051cb9684018c25a89d51ac21be8 ]

The check_csum() function relied on hwtstamp_rx_filter to know if rxvlan
offload is disabled. This is wrong since rxvlan offload can be switched
on/off regardless of hwtstamp_rx_filter.

Also moved check_csum to query CQE information to identify VLAN packets
and removed the check of IP packets, since it has been validated before.

Fixes: f8c6455bb04b ('net/mlx4_en: Extend checksum offloading by CHECKSUM COMPLETE')
Signed-off-by: Ido Shamay &lt;idos@mellanox.com&gt;
Signed-off-by: Or Gerlitz &lt;ogerlitz@mellanox.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 79a258526ce1051cb9684018c25a89d51ac21be8 ]

The check_csum() function relied on hwtstamp_rx_filter to know if rxvlan
offload is disabled. This is wrong since rxvlan offload can be switched
on/off regardless of hwtstamp_rx_filter.

Also moved check_csum to query CQE information to identify VLAN packets
and removed the check of IP packets, since it has been validated before.

Fixes: f8c6455bb04b ('net/mlx4_en: Extend checksum offloading by CHECKSUM COMPLETE')
Signed-off-by: Ido Shamay &lt;idos@mellanox.com&gt;
Signed-off-by: Or Gerlitz &lt;ogerlitz@mellanox.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net/mlx4_en: Wake TX queues only when there's enough room</title>
<updated>2015-07-10T16:49:30+00:00</updated>
<author>
<name>Ido Shamay</name>
<email>idos@mellanox.com</email>
</author>
<published>2015-06-25T08:29:42+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=7a9aa8ab0c706b3d2770a3996c9e63f08074c855'/>
<id>7a9aa8ab0c706b3d2770a3996c9e63f08074c855</id>
<content type='text'>
[ Upstream commit 488a9b48e398b157703766e2cd91ea45ac6997c5 ]

Indication of a single completed packet, marked by txbbs_skipped
being bigger then zero, in not enough in order to wake up a
stopped TX queue. The completed packet may contain a single TXBB,
while next packet to be sent (after the wake up) may have multiple
TXBBs (LSO/TSO packets for example), causing overflow in queue followed
by WQE corruption and TX queue timeout.
Instead, wake the stopped queue only when there's enough room for the
worst case (maximum sized WQE) packet that we should need to handle after
the queue is opened again.

Also created an helper routine - mlx4_en_is_tx_ring_full, which checks
if the current TX ring is full or not. It provides better code readability
and removes code duplication.

Signed-off-by: Ido Shamay &lt;idos@mellanox.com&gt;
Signed-off-by: Or Gerlitz &lt;ogerlitz@mellanox.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 488a9b48e398b157703766e2cd91ea45ac6997c5 ]

Indication of a single completed packet, marked by txbbs_skipped
being bigger then zero, in not enough in order to wake up a
stopped TX queue. The completed packet may contain a single TXBB,
while next packet to be sent (after the wake up) may have multiple
TXBBs (LSO/TSO packets for example), causing overflow in queue followed
by WQE corruption and TX queue timeout.
Instead, wake the stopped queue only when there's enough room for the
worst case (maximum sized WQE) packet that we should need to handle after
the queue is opened again.

Also created an helper routine - mlx4_en_is_tx_ring_full, which checks
if the current TX ring is full or not. It provides better code readability
and removes code duplication.

Signed-off-by: Ido Shamay &lt;idos@mellanox.com&gt;
Signed-off-by: Or Gerlitz &lt;ogerlitz@mellanox.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net/mlx4_en: Release TX QP when destroying TX ring</title>
<updated>2015-07-10T16:49:30+00:00</updated>
<author>
<name>Eran Ben Elisha</name>
<email>eranbe@mellanox.com</email>
</author>
<published>2015-06-25T08:29:41+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=f3f6617f6b90f2e27ee7362f8a2f4063c7eac6a7'/>
<id>f3f6617f6b90f2e27ee7362f8a2f4063c7eac6a7</id>
<content type='text'>
[ Upstream commit 0eb08514fdbdcd16fd6870680cd638f203662e9d ]

TX ring QP wasn't released at mlx4_en_destroy_tx_ring. Instead, the code
used the deprecated base_tx_qpn field. Move TX QP release to
mlx4_en_destroy_tx_ring and remove the base_tx_qpn field.

Fixes: ddae0349fdb7 ('net/mlx4: Change QP allocation scheme')
Signed-off-by: Eran Ben Elisha &lt;eranbe@mellanox.com&gt;
Signed-off-by: Or Gerlitz &lt;ogerlitz@mellanox.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 0eb08514fdbdcd16fd6870680cd638f203662e9d ]

TX ring QP wasn't released at mlx4_en_destroy_tx_ring. Instead, the code
used the deprecated base_tx_qpn field. Move TX QP release to
mlx4_en_destroy_tx_ring and remove the base_tx_qpn field.

Fixes: ddae0349fdb7 ('net/mlx4: Change QP allocation scheme')
Signed-off-by: Eran Ben Elisha &lt;eranbe@mellanox.com&gt;
Signed-off-by: Or Gerlitz &lt;ogerlitz@mellanox.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>xen-netback: fix a BUG() during initialization</title>
<updated>2015-07-10T16:49:30+00:00</updated>
<author>
<name>Palik, Imre</name>
<email>imrep@amazon.de</email>
</author>
<published>2015-06-19T12:21:51+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=6fc8b947b364ceb6d91e5b6f3e3d22cd9a013ac0'/>
<id>6fc8b947b364ceb6d91e5b6f3e3d22cd9a013ac0</id>
<content type='text'>
[ Upstream commit 12b322ac85208de564ecf23aa754d796a91de21f ]

Commit edafc132baac ("xen-netback: making the bandwidth limiter runtime settable")
introduced the capability to change the bandwidth rate limit at runtime.
But it also introduced a possible crashing bug.

If netback receives two XenbusStateConnected without getting the
hotplug-status watch firing in between, then it will try to register the
watches for the rate limiter again.  But this triggers a BUG() in the watch
registration code.

The fix modifies connect() to remove the possibly existing packet-rate
watches before trying to install those watches.  This behaviour is in line
with how connect() deals with the hotplug-status watch.

Signed-off-by: Imre Palik &lt;imrep@amazon.de&gt;
Cc: Matt Wilson &lt;msw@amazon.com&gt;
Acked-by: Wei Liu &lt;wei.liu2@citrix.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 12b322ac85208de564ecf23aa754d796a91de21f ]

Commit edafc132baac ("xen-netback: making the bandwidth limiter runtime settable")
introduced the capability to change the bandwidth rate limit at runtime.
But it also introduced a possible crashing bug.

If netback receives two XenbusStateConnected without getting the
hotplug-status watch firing in between, then it will try to register the
watches for the rate limiter again.  But this triggers a BUG() in the watch
registration code.

The fix modifies connect() to remove the possibly existing packet-rate
watches before trying to install those watches.  This behaviour is in line
with how connect() deals with the hotplug-status watch.

Signed-off-by: Imre Palik &lt;imrep@amazon.de&gt;
Cc: Matt Wilson &lt;msw@amazon.com&gt;
Acked-by: Wei Liu &lt;wei.liu2@citrix.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
