<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/net, branch v3.17</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v3.17</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v3.17'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2014-10-01T20:46:34Z</updated>
<entry>
<title>r8152: disable power cut for RTL8153</title>
<updated>2014-10-01T20:46:34Z</updated>
<author>
<name>hayeswang</name>
<email>hayeswang@realtek.com</email>
</author>
<published>2014-10-01T05:25:11Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=49be17235c0acd96f2ff0fe282867fe3a83f554c'/>
<id>urn:sha1:49be17235c0acd96f2ff0fe282867fe3a83f554c</id>
<content type='text'>
The firmware would be clear when the power cut is enabled for
RTL8153.

Signed-off-by: Hayes Wang &lt;hayeswang@realtek.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>r8152: remove clearing bp</title>
<updated>2014-10-01T20:46:34Z</updated>
<author>
<name>hayeswang</name>
<email>hayeswang@realtek.com</email>
</author>
<published>2014-10-01T05:25:10Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=204c8704128943bf3f8b605f4b40bdc2b6bd89dc'/>
<id>urn:sha1:204c8704128943bf3f8b605f4b40bdc2b6bd89dc</id>
<content type='text'>
The xxx_clear_bp() is used to halt the firmware. It only necessary
for updating the new firmware. Besides, depend on the version of
the current firmware, it may have problem to halt the firmware
directly. Finally, halt the firmware would let the firmware code
useless, and the bugs which are fixed by the firmware would occur.

Signed-off-by: Hayes Wang &lt;hayeswang@realtek.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>bnx2: Correctly receive full sized 802.1ad fragmes</title>
<updated>2014-10-01T20:43:45Z</updated>
<author>
<name>Vlad Yasevich</name>
<email>vyasevich@gmail.com</email>
</author>
<published>2014-09-30T23:39:37Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=1b0ecb28b0cc216535ce6477d39aa610c3ff68a1'/>
<id>urn:sha1:1b0ecb28b0cc216535ce6477d39aa610c3ff68a1</id>
<content type='text'>
This driver, similar to tg3, has a check that will
cause full sized 802.1ad frames to be dropped.  The
frame will be larger then the standard mtu due to the
presense of vlan header that has not been stripped.
The driver should not drop this frame and should process
it just like it does for 802.1q.

CC: Sony Chacko &lt;sony.chacko@qlogic.com&gt;
CC: Dept-HSGLinuxNICDev@qlogic.com
Signed-off-by: Vladislav Yasevich &lt;vyasevic@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>tg3: Allow for recieve of full-size 8021AD frames</title>
<updated>2014-10-01T20:43:45Z</updated>
<author>
<name>Vlad Yasevich</name>
<email>vyasevich@gmail.com</email>
</author>
<published>2014-09-30T23:39:36Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=7d3083ee36b51e425b6abd76778a2046906b0fd3'/>
<id>urn:sha1:7d3083ee36b51e425b6abd76778a2046906b0fd3</id>
<content type='text'>
When receiving a vlan-tagged frame that still contains
a vlan header, the length of the packet will be greater
then MTU+ETH_HLEN since it will account of the extra
vlan header.  TG3 checks this for the case for 802.1Q,
but not for 802.1ad.  As a result, full sized 802.1ad
frames get dropped by the card.

Add a check for 802.1ad protocol when receving full
sized frames.

Suggested-by: Prashant Sreedharan &lt;prashant@broadcom.com&gt;
CC: Prashant Sreedharan &lt;prashant@broadcom.com&gt;
CC: Michael Chan &lt;mchan@broadcom.com&gt;
Signed-off-by: Vladislav Yasevich &lt;vyasevic@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>r8152: fix setting RTL8152_UNPLUG</title>
<updated>2014-09-30T20:23:51Z</updated>
<author>
<name>hayeswang</name>
<email>hayeswang@realtek.com</email>
</author>
<published>2014-09-30T08:48:01Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=f561de33d63aefb97fb0c3653a36fb32d4e8c74a'/>
<id>urn:sha1:f561de33d63aefb97fb0c3653a36fb32d4e8c74a</id>
<content type='text'>
The flag of RTL8152_UNPLUG should only be set when the device is
unplugged, not each time the rtl8152_disconnect() is called.
Otherwise, the device wouldn't be stopped normally.

Signed-off-by: Hayes Wang &lt;hayeswang@realtek.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>netxen: Fix bug in Tx completion path.</title>
<updated>2014-09-30T20:22:44Z</updated>
<author>
<name>Manish Chopra</name>
<email>manish.chopra@qlogic.com</email>
</author>
<published>2014-09-30T07:56:36Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=9295f940fb677b343980cd67f3c91a4eb48d2fae'/>
<id>urn:sha1:9295f940fb677b343980cd67f3c91a4eb48d2fae</id>
<content type='text'>
o Driver is not updating sw_consumer while processing Tx completion
  when interface is going down. Due to this interface down path gets
  stuck forever waiting for NAPI to complete.

Signed-off-by: Manish Chopra &lt;manish.chopra@qlogic.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>netxen: Fix BUG "sleeping function called from invalid context"</title>
<updated>2014-09-30T20:22:43Z</updated>
<author>
<name>Manish Chopra</name>
<email>manish.chopra@qlogic.com</email>
</author>
<published>2014-09-30T07:56:35Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=0d36882013e61dc47aa835c4ec98b1fe776c9db8'/>
<id>urn:sha1:0d36882013e61dc47aa835c4ec98b1fe776c9db8</id>
<content type='text'>
o __netxen_nic_down() function might sleep while holding spinlock_t(tx_clean_lock).
  Acquire this lock for only releasing TX buffers instead of taking it
  for whole down path.

Reported-by: Mike Galbraith &lt;umgwanakikbuti@gmail.com&gt;
Signed-off-by: Manish Chopra &lt;manish.chopra@qlogic.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>hyperv: Fix a bug in netvsc_start_xmit()</title>
<updated>2014-09-30T05:21:03Z</updated>
<author>
<name>KY Srinivasan</name>
<email>kys@microsoft.com</email>
</author>
<published>2014-09-29T05:16:43Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=dedb845ded56ded1c62f5398a94ffa8615d4592d'/>
<id>urn:sha1:dedb845ded56ded1c62f5398a94ffa8615d4592d</id>
<content type='text'>
After the packet is successfully sent, we should not touch the skb
as it may have been freed. This patch is based on the work done by
Long Li &lt;longli@microsoft.com&gt;.

In this version of the patch I have fixed issues pointed out by David.
David, please queue this up for stable.

Signed-off-by: K. Y. Srinivasan &lt;kys@microsoft.com&gt;
Tested-by: Long Li &lt;longli@microsoft.com&gt;
Tested-by: Sitsofe Wheeler &lt;sitsofe@yahoo.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: stmmac: fix stmmac_pci_probe failed when CONFIG_HAVE_CLK is selected</title>
<updated>2014-09-29T20:36:58Z</updated>
<author>
<name>Kweh, Hock Leong</name>
<email>hock.leong.kweh@intel.com</email>
</author>
<published>2014-09-26T13:42:55Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=c5bb86c3848174aad59ea6cf5748e210fbb8f744'/>
<id>urn:sha1:c5bb86c3848174aad59ea6cf5748e210fbb8f744</id>
<content type='text'>
When the CONFIG_HAVE_CLK is selected for the system, the stmmac_pci_probe
will fail with dmesg:
[    2.167225] stmmaceth 0000:00:14.6: enabling device (0000 -&gt; 0002)
[    2.178267] stmmaceth 0000:00:14.6: enabling bus mastering
[    2.178436] stmmaceth 0000:00:14.6: irq 24 for MSI/MSI-X
[    2.178703] stmmaceth 0000:00:14.6: stmmac_dvr_probe: warning: cannot
get CSR clock
[    2.186503] stmmac_pci_probe: main driver probe failed
[    2.194003] stmmaceth 0000:00:14.6: disabling bus mastering
[    2.196473] stmmaceth: probe of 0000:00:14.6 failed with error -2

This patch fix the issue by breaking the dependency to devm_clk_get()
as the CSR clock can be obtained at priv-&gt;plat-&gt;clk_csr from pci driver.

Reported-by: Tobias Klausmann &lt;tobias.johannes.klausmann@mni.thm.de&gt;
Signed-off-by: Kweh, Hock Leong &lt;hock.leong.kweh@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net/mlx4_core: Allow not to specify probe_vf in SRIOV IB mode</title>
<updated>2014-09-26T20:43:23Z</updated>
<author>
<name>Matan Barak</name>
<email>matanb@mellanox.com</email>
</author>
<published>2014-09-23T13:05:59Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=effa4bc4e75a265105f4ccb55857057e5ad231ed'/>
<id>urn:sha1:effa4bc4e75a265105f4ccb55857057e5ad231ed</id>
<content type='text'>
When the HCA is configured in SRIOV IB mode (that is, at least one of
the ports is IB) and the probe_vf module param isn't specified,
mlx4_init_one() failed because of the following condition:

if (ib_ports &amp;&amp; (num_vfs_argc &gt; 1 || probe_vfs_argc &gt; 1)) {
	 .....
}

The root cause for that is a mistake in the initialization of num_vfs_argc
and probe_vfs_argc. When num_vfs / probe_vf aren't given, their argument
count counterpart should be 0, fix that.

Fixes: dd41cc3bb90e ('net/mlx4: Adapt num_vfs/probed_vf params for single port VF')
Signed-off-by: Matan Barak &lt;matanb@mellanox.com&gt;
Signed-off-by: Or Gerlitz &lt;ogerlitz@mellanox.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
