<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux.git/drivers/net/ethernet, branch linux-3.15.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<id>https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-3.15.y</id>
<link rel='self' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-3.15.y'/>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/'/>
<updated>2014-08-14T01:51:48+00:00</updated>
<entry>
<title>bna: fix performance regression</title>
<updated>2014-08-14T01:51:48+00:00</updated>
<author>
<name>Ivan Vecera</name>
<email>ivecera@redhat.com</email>
</author>
<published>2014-07-29T14:29:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6980baed350d2e32647595fd06f5281d708fbee0'/>
<id>urn:sha1:6980baed350d2e32647595fd06f5281d708fbee0</id>
<content type='text'>
[ Upstream commit c36c9d50cc6af5c5bfcc195f21b73f55520c15f9 ]

The recent commit "e29aa33 bna: Enable Multi Buffer RX" is causing
a performance regression. It does not properly update 'cmpl' pointer
at the end of the loop in NAPI handler bnad_cq_process(). The result is
only one packet / per NAPI-schedule is processed.

Signed-off-by: Ivan Vecera &lt;ivecera@redhat.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>
</entry>
<entry>
<title>bnx2x: fix crash during TSO tunneling</title>
<updated>2014-08-14T01:51:48+00:00</updated>
<author>
<name>Dmitry Kravkov</name>
<email>Dmitry.Kravkov@qlogic.com</email>
</author>
<published>2014-07-24T15:54:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e0d1b89416a6a32461fb110ebc6e0f4cf01fb411'/>
<id>urn:sha1:e0d1b89416a6a32461fb110ebc6e0f4cf01fb411</id>
<content type='text'>
[ Upstream commit fe26566d8a05151ba1dce75081f6270f73ec4ae1 ]

When TSO packet is transmitted additional BD w/o mapping is used
to describe the packed. The BD needs special handling in tx
completion.

kernel: Call Trace:
kernel: &lt;IRQ&gt;  [&lt;ffffffff815e19ba&gt;] dump_stack+0x19/0x1b
kernel: [&lt;ffffffff8105dee1&gt;] warn_slowpath_common+0x61/0x80
kernel: [&lt;ffffffff8105df5c&gt;] warn_slowpath_fmt+0x5c/0x80
kernel: [&lt;ffffffff814a8c0d&gt;] ? find_iova+0x4d/0x90
kernel: [&lt;ffffffff814ab0e2&gt;] intel_unmap_page.part.36+0x142/0x160
kernel: [&lt;ffffffff814ad0e6&gt;] intel_unmap_page+0x26/0x30
kernel: [&lt;ffffffffa01f55d7&gt;] bnx2x_free_tx_pkt+0x157/0x2b0 [bnx2x]
kernel: [&lt;ffffffffa01f8dac&gt;] bnx2x_tx_int+0xac/0x220 [bnx2x]
kernel: [&lt;ffffffff8101a0d9&gt;] ? read_tsc+0x9/0x20
kernel: [&lt;ffffffffa01f8fdb&gt;] bnx2x_poll+0xbb/0x3c0 [bnx2x]
kernel: [&lt;ffffffff814d041a&gt;] net_rx_action+0x15a/0x250
kernel: [&lt;ffffffff81067047&gt;] __do_softirq+0xf7/0x290
kernel: [&lt;ffffffff815f3a5c&gt;] call_softirq+0x1c/0x30
kernel: [&lt;ffffffff81014d25&gt;] do_softirq+0x55/0x90
kernel: [&lt;ffffffff810673e5&gt;] irq_exit+0x115/0x120
kernel: [&lt;ffffffff815f4358&gt;] do_IRQ+0x58/0xf0
kernel: [&lt;ffffffff815e94ad&gt;] common_interrupt+0x6d/0x6d
kernel: &lt;EOI&gt;  [&lt;ffffffff810bbff7&gt;] ? clockevents_notify+0x127/0x140
kernel: [&lt;ffffffff814834df&gt;] ? cpuidle_enter_state+0x4f/0xc0
kernel: [&lt;ffffffff81483615&gt;] cpuidle_idle_call+0xc5/0x200
kernel: [&lt;ffffffff8101bc7e&gt;] arch_cpu_idle+0xe/0x30
kernel: [&lt;ffffffff810b4725&gt;] cpu_startup_entry+0xf5/0x290
kernel: [&lt;ffffffff815cfee1&gt;] start_secondary+0x265/0x27b
kernel: ---[ end trace 11aa7726f18d7e80 ]---

Fixes: a848ade408b ("bnx2x: add CSUM and TSO support for encapsulation protocols")
Reported-by: Yulong Pei &lt;ypei@redhat.com&gt;
Cc: Michal Schmidt &lt;mschmidt@redhat.com&gt;
Signed-off-by: Dmitry Kravkov &lt;Dmitry.Kravkov@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>
</entry>
<entry>
<title>net: bcmgenet: correctly pad short packets</title>
<updated>2014-08-14T01:51:47+00:00</updated>
<author>
<name>Florian Fainelli</name>
<email>f.fainelli@gmail.com</email>
</author>
<published>2014-07-22T18:01:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=34ada3629e591ddb43c1aa799f5e4f39b1a1597a'/>
<id>urn:sha1:34ada3629e591ddb43c1aa799f5e4f39b1a1597a</id>
<content type='text'>
[ Upstream commit 474ea9cafc459976827a477f2c30eaf6313cb7c1 ]

Packets shorter than ETH_ZLEN were not padded with zeroes, hence leaking
potentially sensitive information. This bug has been present since the
driver got accepted in commit 1c1008c793fa46703a2fee469f4235e1c7984333
("net: bcmgenet: add main driver file").

Signed-off-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>
</entry>
<entry>
<title>sunvnet: clean up objects created in vnet_new() on vnet_exit()</title>
<updated>2014-07-28T15:08:25+00:00</updated>
<author>
<name>Sowmini Varadhan</name>
<email>sowmini.varadhan@oracle.com</email>
</author>
<published>2014-07-16T14:02:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e87c911ec1d4330d0a97a427ccaac38b149ca45a'/>
<id>urn:sha1:e87c911ec1d4330d0a97a427ccaac38b149ca45a</id>
<content type='text'>
[ Upstream commit a4b70a07ed12a71131cab7adce2ce91c71b37060 ]

Nothing cleans up the objects created by
vnet_new(), they are completely leaked.

vnet_exit(), after doing the vio_unregister_driver() to clean
up ports, should call a helper function that iterates over vnet_list
and cleans up those objects. This includes unregister_netdevice()
as well as free_netdev().

Signed-off-by: Sowmini Varadhan &lt;sowmini.varadhan@oracle.com&gt;
Acked-by: Dave Kleikamp &lt;dave.kleikamp@oracle.com&gt;
Reviewed-by: Karl Volz &lt;karl.volz@oracle.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>
</entry>
<entry>
<title>be2net: set EQ DB clear-intr bit in be_open()</title>
<updated>2014-07-28T15:08:24+00:00</updated>
<author>
<name>Suresh Reddy</name>
<email>Suresh.Reddy@emulex.com</email>
</author>
<published>2014-07-11T08:33:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4ede81d69903e1f8f3ba6dff921ca819dbdc5029'/>
<id>urn:sha1:4ede81d69903e1f8f3ba6dff921ca819dbdc5029</id>
<content type='text'>
[ Upstream commit 4cad9f3b61c7268fa89ab8096e23202300399b5d ]

On BE3, if the clear-interrupt bit of the EQ doorbell is not set the first
time it is armed, ocassionally we have observed that the EQ doesn't raise
anymore interrupts even if it is in armed state.
This patch fixes this by setting the clear-interrupt bit when EQs are
armed for the first time in be_open().

Signed-off-by: Suresh Reddy &lt;Suresh.Reddy@emulex.com&gt;
Signed-off-by: Sathya Perla &lt;sathya.perla@emulex.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>
</entry>
<entry>
<title>net: mvneta: Fix big endian issue in mvneta_txq_desc_csum()</title>
<updated>2014-07-28T15:08:24+00:00</updated>
<author>
<name>Thomas Fitzsimmons</name>
<email>fitzsim@fitzsim.org</email>
</author>
<published>2014-07-08T23:44:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b1932501f8514a0328461ecf770d355c62dd8e2e'/>
<id>urn:sha1:b1932501f8514a0328461ecf770d355c62dd8e2e</id>
<content type='text'>
[ Upstream commit 0a1985879437d14bda8c90d0dae3455c467d7642 ]

This commit fixes the command value generated for CSUM calculation
when running in big endian mode.  The Ethernet protocol ID for IP was
being unconditionally byte-swapped in the layer 3 protocol check (with
swab16), which caused the mvneta driver to not function correctly in
big endian mode.  This patch byte-swaps the ID conditionally with
htons.

Cc: &lt;stable@vger.kernel.org&gt; # v3.13+
Signed-off-by: Thomas Fitzsimmons &lt;fitzsim@fitzsim.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: mvneta: fix operation in 10 Mbit/s mode</title>
<updated>2014-07-28T15:08:24+00:00</updated>
<author>
<name>Thomas Petazzoni</name>
<email>thomas.petazzoni@free-electrons.com</email>
</author>
<published>2014-07-08T08:49:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=df902cdef12b8c1810d5e8f6e7d044c972bb60f8'/>
<id>urn:sha1:df902cdef12b8c1810d5e8f6e7d044c972bb60f8</id>
<content type='text'>
[ Upstream commit 4d12bc63ab5e48c1d78fa13883cf6fefcea3afb1 ]

As reported by Maggie Mae Roxas, the mvneta driver doesn't behave
properly in 10 Mbit/s mode. This is due to a misconfiguration of the
MVNETA_GMAC_AUTONEG_CONFIG register: bit MVNETA_GMAC_CONFIG_MII_SPEED
must be set for a 100 Mbit/s speed, but cleared for a 10 Mbit/s speed,
which the driver was not properly doing. This commit adjusts that by
setting the MVNETA_GMAC_CONFIG_MII_SPEED bit only in 100 Mbit/s mode,
and relying on the fact that all the speed related bits of this
register are cleared at the beginning of the mvneta_adjust_link()
function.

This problem exists since c5aff18204da0 ("net: mvneta: driver for
Marvell Armada 370/XP network unit") which is the commit that
introduced the mvneta driver in the kernel.

Cc: &lt;stable@vger.kernel.org&gt; # v3.8+
Fixes: c5aff18204da0 ("net: mvneta: driver for Marvell Armada 370/XP network unit")
Reported-by: Maggie Mae Roxas &lt;maggie.mae.roxas@gmail.com&gt;
Cc: Maggie Mae Roxas &lt;maggie.mae.roxas@gmail.com&gt;
Signed-off-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>
</entry>
<entry>
<title>bnx2x: fix possible panic under memory stress</title>
<updated>2014-07-28T15:08:23+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2014-06-26T07:44:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=df3b53b955cfe5b2aa38644d9d075cd10ddb1202'/>
<id>urn:sha1:df3b53b955cfe5b2aa38644d9d075cd10ddb1202</id>
<content type='text'>
[ Upstream commit 07b0f00964def8af9321cfd6c4a7e84f6362f728 ]

While it is legal to kfree(NULL), it is not wise to use :
put_page(virt_to_head_page(NULL))

 BUG: unable to handle kernel paging request at ffffeba400000000
 IP: [&lt;ffffffffc01f5928&gt;] virt_to_head_page+0x36/0x44 [bnx2x]

Reported-by: Michel Lespinasse &lt;walken@google.com&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Ariel Elior &lt;ariel.elior@qlogic.com&gt;
Fixes: d46d132cc021 ("bnx2x: use netdev_alloc_frag()")
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drivers: net: cpsw: fix dual EMAC stall when connected to same switch</title>
<updated>2014-07-28T15:08:23+00:00</updated>
<author>
<name>Mugunthan V N</name>
<email>mugunthanvnm@ti.com</email>
</author>
<published>2014-06-18T11:51:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=54e9c55c8bfa1e255d4ebd3291c13c22e359eb07'/>
<id>urn:sha1:54e9c55c8bfa1e255d4ebd3291c13c22e359eb07</id>
<content type='text'>
[ Upstream commit e6afea0bbf129f88dc3fc39fd0d769f9ff064172 ]

In commit 629c9a8fd0bbdfc6d702526b327470166ec39c6b (drivers: net: cpsw: Add
default vlan for dual emac case also), api cpsw_add_default_vlan() also
changes the port vlan which is required to seperate the ports which results
in the following behavior

In Dual EMAC mode, when both the Etnernet connected is connected to same
switch, it creates a loop in the switch and when a broadcast packet is
received it is forwarded to the other port which stalls the whole switch
and needs a reset/power cycle to the switch to recover. So intead of using
the api, add only the default VLAN entry in dual EMAC case.

Cc: Yegor Yefremov &lt;yegorslists@googlemail.com&gt;
Cc: Felipe Balbi &lt;balbi@ti.com&gt;
Signed-off-by: Mugunthan V N &lt;mugunthanvnm@ti.com&gt;
Tested-by: Yegor Yefremov &lt;yegorslists@googlemail.com&gt;
Tested-by: Felipe Balbi &lt;balbi@ti.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>
</entry>
<entry>
<title>net/mlx4_en: Don't configure the HW vxlan parser when vxlan offloading isn't set</title>
<updated>2014-07-28T15:08:22+00:00</updated>
<author>
<name>Or Gerlitz</name>
<email>ogerlitz@mellanox.com</email>
</author>
<published>2014-07-02T14:36:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9150bacf5cd5d8381e37263518500efb9503af82'/>
<id>urn:sha1:9150bacf5cd5d8381e37263518500efb9503af82</id>
<content type='text'>
[ Upstream commit e326f2f13b209d56782609e833b87cb497e64b3b ]

The add_vxlan_port ndo driver code was wrongly testing whether HW vxlan offloads
are supported by the device instead of checking if they are currently enabled.

This causes the driver to configure the HW parser to conduct matching for vxlan
packets but since no steering rules were set, vxlan packets are dropped on RX.

Fix that by doing the right test, as done in the del_vxlan_port ndo handler.

Fixes: 1b136de ('net/mlx4: Implement vxlan ndo calls')
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>
</entry>
</feed>
