<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/drivers/net/ethernet, branch dev-4.3</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-4.3</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-4.3'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2016-02-02T02:23:42+00:00</updated>
<entry>
<title>Merge tag 'v4.3.5' into dev-4.3</title>
<updated>2016-02-02T02:23:42+00:00</updated>
<author>
<name>Joel Stanley</name>
<email>joel@jms.id.au</email>
</author>
<published>2016-02-02T02:23:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=f3f4aeb9ea8954c0da3cf0d12693f9a57f1f4ac7'/>
<id>urn:sha1:f3f4aeb9ea8954c0da3cf0d12693f9a57f1f4ac7</id>
<content type='text'>
This is the 4.3.5 stable release

Signed-off-by: Joel Stanley &lt;joel@jms.id.au&gt;
</content>
</entry>
<entry>
<title>net/mlx5_core: Fix trimming down IRQ number</title>
<updated>2016-01-31T19:25:52+00:00</updated>
<author>
<name>Doron Tsur</name>
<email>doront@mellanox.com</email>
</author>
<published>2016-01-17T09:25:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=1940d0b0bbf12260a646c0420ed16edbdf9aa2df'/>
<id>urn:sha1:1940d0b0bbf12260a646c0420ed16edbdf9aa2df</id>
<content type='text'>
[ Upstream commit 0b6e26ce89391327d955a756a7823272238eb867 ]

With several ConnectX-4 cards installed on a server, one may receive
irqn &gt; 255 from the kernel API, which we mistakenly trim to 8bit.

This causes EQ creation failure with the following stack trace:
[&lt;ffffffff812a11f4&gt;] dump_stack+0x48/0x64
[&lt;ffffffff810ace21&gt;] __setup_irq+0x3a1/0x4f0
[&lt;ffffffff810ad7e0&gt;] request_threaded_irq+0x120/0x180
[&lt;ffffffffa0923660&gt;] ? mlx5_eq_int+0x450/0x450 [mlx5_core]
[&lt;ffffffffa0922f64&gt;] mlx5_create_map_eq+0x1e4/0x2b0 [mlx5_core]
[&lt;ffffffffa091de01&gt;] alloc_comp_eqs+0xb1/0x180 [mlx5_core]
[&lt;ffffffffa091ea99&gt;] mlx5_dev_init+0x5e9/0x6e0 [mlx5_core]
[&lt;ffffffffa091ec29&gt;] init_one+0x99/0x1c0 [mlx5_core]
[&lt;ffffffff812e2afc&gt;] local_pci_probe+0x4c/0xa0

Fixing it by changing of the irqn type from u8 to unsigned int to
support values &gt; 255

Fixes: 61d0e73e0a5a ('net/mlx5_core: Use the the real irqn in eq-&gt;irqn')
Reported-by: Jiri Pirko &lt;jiri@mellanox.com&gt;
Signed-off-by: Doron Tsur &lt;doront@mellanox.com&gt;
Signed-off-by: Matan Barak &lt;matanb@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>
<entry>
<title>dwc_eth_qos: Fix dma address for multi-fragment skbs</title>
<updated>2016-01-31T19:25:51+00:00</updated>
<author>
<name>Lars Persson</name>
<email>lars.persson@axis.com</email>
</author>
<published>2016-01-12T14:28:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=6b4938efb10a801e8ca99926ccd18d095b8cd7dc'/>
<id>urn:sha1:6b4938efb10a801e8ca99926ccd18d095b8cd7dc</id>
<content type='text'>
[ Upstream commit d461873272169a3fc3a8d155d7b1c92e9d97b419 ]

The offset inside the fragment was not used for the dma address and
silent data corruption resulted because TSO makes the checksum match.

Fixes: 077742dac2c7 ("dwc_eth_qos: Add support for Synopsys DWC Ethernet QoS")
Signed-off-by: Lars Persson &lt;larper@axis.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>Merge tag 'v4.3.4' into dev-4.3</title>
<updated>2016-01-27T05:33:14+00:00</updated>
<author>
<name>Joel Stanley</name>
<email>joel@jms.id.au</email>
</author>
<published>2016-01-27T05:33:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=7495d280c7566dba7211b4704e71d0ce35069762'/>
<id>urn:sha1:7495d280c7566dba7211b4704e71d0ce35069762</id>
<content type='text'>
This is the 4.3.4 stable release
</content>
</entry>
<entry>
<title>gianfar: Don't enable RX Filer if not supported</title>
<updated>2016-01-23T04:55:50+00:00</updated>
<author>
<name>Hamish Martin</name>
<email>hamish.martin@alliedtelesis.co.nz</email>
</author>
<published>2015-12-15T01:14:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=d46972df5551d3b4b5c3b4cc4abb45d613769e1e'/>
<id>urn:sha1:d46972df5551d3b4b5c3b4cc4abb45d613769e1e</id>
<content type='text'>
[ Upstream commit 7bff47da1ee23d00d1257905f2944c29594f799d ]

After commit 15bf176db1fb ("gianfar: Don't enable the Filer w/o the
Parser"), 'TSEC' model controllers (for example as seen on MPC8541E)
always have 8 bytes stripped from the front of received frames.
Only 'eTSEC' gianfar controllers have the RX Filer capability (amongst
other enhancements). Previously this was treated as always enabled
for both 'TSEC' and 'eTSEC' controllers.
In commit 15bf176db1fb ("gianfar: Don't enable the Filer w/o the Parser")
a subtle change was made to the setting of 'uses_rxfcb' to effectively
always set it (since 'rx_filer_enable' was always true). This had the
side-effect of always stripping 8 bytes from the front of received frames
on 'TSEC' type controllers.

We now only enable the RX Filer capability on controller types that
support it, thereby avoiding the issue for 'TSEC' type controllers.

Reviewed-by: Chris Packham &lt;chris.packham@alliedtelesis.co.nz&gt;
Reviewed-by: Mark Tomlinson &lt;mark.tomlinson@alliedtelesis.co.nz&gt;
Signed-off-by: Hamish Martin &lt;hamish.martin@alliedtelesis.co.nz&gt;
Reviewed-by: Claudiu Manoil &lt;claudiu.manoil@freescale.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>sh_eth: fix kernel oops in skb_put()</title>
<updated>2016-01-23T04:55:48+00:00</updated>
<author>
<name>Sergei Shtylyov</name>
<email>sergei.shtylyov@cogentembedded.com</email>
</author>
<published>2015-12-03T22:45:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=a3f531ca022824111f75b445ef5d0c91da2be325'/>
<id>urn:sha1:a3f531ca022824111f75b445ef5d0c91da2be325</id>
<content type='text'>
[ Upstream commit 248be83dcb3feb3f6332eb3d010a016402138484 ]

In a low memory situation the following kernel oops occurs:

Unable to handle kernel NULL pointer dereference at virtual address 00000050
pgd = 8490c000
[00000050] *pgd=4651e831, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#1] PREEMPT ARM
Modules linked in:
CPU: 0    Not tainted  (3.4-at16 #9)
PC is at skb_put+0x10/0x98
LR is at sh_eth_poll+0x2c8/0xa10
pc : [&lt;8035f780&gt;]    lr : [&lt;8028bf50&gt;]    psr: 60000113
sp : 84eb1a90  ip : 84eb1ac8  fp : 84eb1ac4
r10: 0000003f  r9 : 000005ea  r8 : 00000000
r7 : 00000000  r6 : 940453b0  r5 : 00030000  r4 : 9381b180
r3 : 00000000  r2 : 00000000  r1 : 000005ea  r0 : 00000000
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c53c7d  Table: 4248c059  DAC: 00000015
Process klogd (pid: 2046, stack limit = 0x84eb02e8)
[...]

This is  because netdev_alloc_skb() fails and 'mdp-&gt;rx_skbuff[entry]' is left
NULL but sh_eth_rx() later  uses it without checking.  Add such check...

Reported-by: Yasushi SHOJI &lt;yashi@atmark-techno.com&gt;
Signed-off-by: Sergei Shtylyov &lt;sergei.shtylyov@cogentembedded.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: qca_spi: fix transmit queue timeout handling</title>
<updated>2016-01-23T04:55:45+00:00</updated>
<author>
<name>Stefan Wahren</name>
<email>stefan.wahren@i2se.com</email>
</author>
<published>2015-12-04T15:29:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=de3a3fae4a7c31f8f22631c9b3ced9bce70ca2e0'/>
<id>urn:sha1:de3a3fae4a7c31f8f22631c9b3ced9bce70ca2e0</id>
<content type='text'>
[ Upstream commit ed7d42e24effbd3681e909711a7a2119a85e9217 ]

In case of a tx queue timeout every transmit is blocked until the
QCA7000 resets himself and triggers a sync which makes the driver
flushs the tx ring. So avoid this blocking situation by triggering
the sync immediately after the timeout. Waking the queue doesn't
make sense in this situation.

Signed-off-by: Stefan Wahren &lt;stefan.wahren@i2se.com&gt;
Fixes: 291ab06ecf67 ("net: qualcomm: new Ethernet over SPI driver for QCA7000")
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>atl1c: Improve driver not to do order 4 GFP_ATOMIC allocation</title>
<updated>2016-01-23T04:55:44+00:00</updated>
<author>
<name>Pavel Machek</name>
<email>pavel@ucw.cz</email>
</author>
<published>2015-12-04T08:50:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=59647282c9dbdd7814601fe20a889df744311f50'/>
<id>urn:sha1:59647282c9dbdd7814601fe20a889df744311f50</id>
<content type='text'>
[ Upstream commit f2a3771ae8aca879c32336c76ad05a017629bae2 ]

atl1c driver is doing order-4 allocation with GFP_ATOMIC
priority. That often breaks  networking after resume. Switch to
GFP_KERNEL. Still not ideal, but should be significantly better.

atl1c_setup_ring_resources() is called from .open() function, and
already uses GFP_KERNEL, so this change is safe.

Signed-off-by: Pavel Machek &lt;pavel@ucw.cz&gt;
Acked-by: Michal Hocko &lt;mhocko@suse.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>Merge tag 'v4.3.3' into dev-4.3</title>
<updated>2015-12-16T22:56:14+00:00</updated>
<author>
<name>Joel Stanley</name>
<email>joel@jms.id.au</email>
</author>
<published>2015-12-16T22:56:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=4b62e603522294dfc278ad42ee5cbf9d2f4717cb'/>
<id>urn:sha1:4b62e603522294dfc278ad42ee5cbf9d2f4717cb</id>
<content type='text'>
This is the 4.3.3 stable release
</content>
</entry>
<entry>
<title>net: thunder: Check for driver data in nicvf_remove()</title>
<updated>2015-12-15T05:40:59+00:00</updated>
<author>
<name>Pavel Fedin</name>
<email>p.fedin@samsung.com</email>
</author>
<published>2015-11-16T14:51:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=ce2ceca37c846767abceee497f8adbb3328a8dd9'/>
<id>urn:sha1:ce2ceca37c846767abceee497f8adbb3328a8dd9</id>
<content type='text'>
[ Upstream commit 7750130d93decff06120df0d8ea024ff8a038a21 ]

In some cases the crash is caused by nicvf_remove() being called from
outside. For example, if we try to feed the device to vfio after the
probe has failed for some reason. So, move the check to better place.

Signed-off-by: Pavel Fedin &lt;p.fedin@samsung.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>
