<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/net, branch v3.8.12</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/drivers/net?h=v3.8.12</id>
<link rel='self' href='https://git.amat.us/linux/atom/drivers/net?h=v3.8.12'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2013-05-08T03:08:24Z</updated>
<entry>
<title>ixgbe: fix EICR write in ixgbe_msix_other</title>
<updated>2013-05-08T03:08:24Z</updated>
<author>
<name>Jacob Keller</name>
<email>jacob.e.keller@intel.com</email>
</author>
<published>2013-03-02T07:51:42Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=c7e1e426d0b6bc1ab07779615c81faf6176901e5'/>
<id>urn:sha1:c7e1e426d0b6bc1ab07779615c81faf6176901e5</id>
<content type='text'>
commit d87d830720a1446403ed38bfc2da268be0d356d1 upstream.

Previously, the ixgbe_msix_other was writing the full 32bits of the set
interrupts, instead of only the ones which the ixgbe_msix_other is
handling. This resulted in a loss of performance when the X540's PPS feature is
enabled due to sometimes clearing queue interrupts which resulted in the driver
not getting the interrupt for cleaning the q_vector rings often enough. The fix
is to simply mask the lower 16bits off so that this handler does not write them
in the EICR, which causes them to remain high and be properly handled by the
clean_rings interrupt routine as normal.

Signed-off-by: Jacob Keller &lt;jacob.e.keller@intel.com&gt;
Tested-by: Phil Schmitt &lt;phillip.j.schmitt@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>rt2x00: Fix transmit power troubles on some Ralink RT30xx cards</title>
<updated>2013-05-08T03:08:20Z</updated>
<author>
<name>Alex A. Mihaylov</name>
<email>minimumlaw@rambler.ru</email>
</author>
<published>2013-04-15T03:29:35Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=3fc6be3dd634f426922da16bc1966f9d4227a9dc'/>
<id>urn:sha1:3fc6be3dd634f426922da16bc1966f9d4227a9dc</id>
<content type='text'>
commit 7e9dafd873034dd64ababcb858be424c4780ae13 upstream.

Some cards on Ralink RT30xx chipset not have correctly TX_MIXER_GAIN
value in them EEPROM/EFUSE. In this case, we must use default value,
but always used EEPROM/EFUSE value. As result we have tranmitt power
range from -10dBm to +6dBm instead 0dBm to +16dBm.

Correctly value in EEPROM/EFUSE is one or more for RT3070 and two or
more for other RT30xx chips.

Tested on Canyon CNP-WF518N1 usb Wi-Fi dongle and Jorjin WN8020 usb
embedded Wi-Fi module.

Signed-off-by: Alex A. Mihaylov &lt;minimumlaw@rambler.ru&gt;
Acked-by: Gertjan van Wingerde &lt;gwingerde@gmail.com&gt;
Acked-by: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>gianfar: do not advertise any alarm capability.</title>
<updated>2013-05-08T03:08:19Z</updated>
<author>
<name>Richard Cochran</name>
<email>richardcochran@gmail.com</email>
</author>
<published>2013-04-22T19:42:16Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b35abd4e63783b8b8a13866dcc5d2fd65dc3cee6'/>
<id>urn:sha1:b35abd4e63783b8b8a13866dcc5d2fd65dc3cee6</id>
<content type='text'>
commit cd4baaaa04b4aaa3b0ec4d13a6f3d203b92eadbd upstream.

An early draft of the PHC patch series included an alarm in the
gianfar driver. During the review process, the alarm code was dropped,
but the capability removal was overlooked. This patch fixes the issue
by advertising zero alarms.

This patch should be applied to every 3.x stable kernel.

Signed-off-by: Richard Cochran &lt;richardcochran@gmail.com&gt;
Reported-by: Chris LaRocque &lt;clarocq@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>mwifiex: Call pci_release_region after calling pci_disable_device</title>
<updated>2013-05-08T03:08:17Z</updated>
<author>
<name>Yogesh Ashok Powar</name>
<email>yogeshp@marvell.com</email>
</author>
<published>2013-04-23T23:49:48Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=e03eb5f7fe183ba234e9b096a08ff2cb1d27e50b'/>
<id>urn:sha1:e03eb5f7fe183ba234e9b096a08ff2cb1d27e50b</id>
<content type='text'>
commit 5b0d9b218b74042ff72bf4bfda6eeb2e4bf98397 upstream.

"drivers should call pci_release_region() AFTER
calling pci_disable_device()"

Please refer section 3.2 Request MMIO/IOP resources
in Documentation/PCI/pci.txt

Signed-off-by: Avinash Patil &lt;patila@marvell.com&gt;
Signed-off-by: Amitkumar Karwar &lt;akarwar@marvell.com&gt;
Signed-off-by: Yogesh Ashok Powar &lt;yogeshp@marvell.com&gt;
Signed-off-by: Bing Zhao &lt;bzhao@marvell.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mwifiex: Use pci_release_region() instead of a pci_release_regions()</title>
<updated>2013-05-08T03:08:17Z</updated>
<author>
<name>Yogesh Ashok Powar</name>
<email>yogeshp@marvell.com</email>
</author>
<published>2013-04-23T23:49:47Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=1ded766000402267865ec2c96ef4759fe3402ff9'/>
<id>urn:sha1:1ded766000402267865ec2c96ef4759fe3402ff9</id>
<content type='text'>
commit c380aafb77b7435d010698fe3ca6d3e1cd745fde upstream.

PCI regions are associated with the device using
pci_request_region() call. Hence use pci_release_region()
instead of pci_release_regions().

Signed-off-by: Yogesh Ashok Powar &lt;yogeshp@marvell.com&gt;
Signed-off-by: Amitkumar Karwar &lt;akarwar@marvell.com&gt;
Signed-off-by: Avinash Patil &lt;patila@marvell.com&gt;
Signed-off-by: Bing Zhao &lt;bzhao@marvell.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iwlwifi: dvm: don't send zeroed LQ cmd</title>
<updated>2013-05-08T03:08:17Z</updated>
<author>
<name>Emmanuel Grumbach</name>
<email>emmanuel.grumbach@intel.com</email>
</author>
<published>2013-04-17T06:47:00Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=6a30b99e412dbbaaca684efb88d4142d1b2309fa'/>
<id>urn:sha1:6a30b99e412dbbaaca684efb88d4142d1b2309fa</id>
<content type='text'>
commit 63b77bf489881747c5118476918cc8c29378ee63 upstream.

When the stations are being restored because of unassoc
RXON, the LQ cmd may not have been initialized because it
is initialized only after association.
Sending zeroed LQ_CMD makes the fw unhappy: it raises
SYSASSERT_2078.

Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Reviewed-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
[move zero_lq and make static const]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iwlwifi: fix freeing uninitialized pointer</title>
<updated>2013-05-08T03:08:17Z</updated>
<author>
<name>Stanislaw Gruszka</name>
<email>sgruszka@redhat.com</email>
</author>
<published>2013-04-16T13:38:29Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=3b878e81dd0be24d6b0851266920c03519ad728b'/>
<id>urn:sha1:3b878e81dd0be24d6b0851266920c03519ad728b</id>
<content type='text'>
commit 3309ccf7fcebceef540ebe90c65d2f94d745a45b upstream.

If on iwl_dump_nic_event_log() error occurs before that function
initialize buf, we process uninitiated pointer in
iwl_dbgfs_log_event_read() and can hit "BUG at mm/slub.c:3409"

Resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=951241

Reported-by: ian.odette@eprize.com
Signed-off-by: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Reviewed-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>net: cdc_mbim: remove bogus sizeof()</title>
<updated>2013-05-01T16:46:19Z</updated>
<author>
<name>Bjørn Mork</name>
<email>bjorn@mork.no</email>
</author>
<published>2013-04-16T00:17:07Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b0914393f1e376bc55fce1bb48972966a1761d5c'/>
<id>urn:sha1:b0914393f1e376bc55fce1bb48972966a1761d5c</id>
<content type='text'>
[ Upstream commit 32b161aa88aa40a83888a995c6e2ef81140219b1 ]

The intention was to test against the constant, not the size of
the constant.

Signed-off-by: Bjørn Mork &lt;bjorn@mork.no&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 improper tx queue usage in mvneta_tx()</title>
<updated>2013-05-01T16:46:19Z</updated>
<author>
<name>Willy Tarreau</name>
<email>w@1wt.eu</email>
</author>
<published>2013-04-11T21:00:37Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=f18af2e655211794d6892f7809299ec271dfb588'/>
<id>urn:sha1:f18af2e655211794d6892f7809299ec271dfb588</id>
<content type='text'>
[ Upstream commit ee40a116ebf139f900c3d2e6febb8388738e96d0 ]

mvneta_tx() was using a static tx queue number causing crashes as
soon as a little bit of traffic was sent via the interface, because
it is normally expected that the same queue should be used as in
dev_queue_xmit().

As suggested by Ben Hutchings, let's use skb_get_queue_mapping() to
get the proper Tx queue number, and use alloc_etherdev_mqs() instead
of alloc_etherdev_mq() to create the queues.

Both my Mirabox and my OpenBlocks AX3 used to crash without this patch
and don't anymore with it. The issue appeared in 3.8 but became more
visible after the fix allowing GSO to be enabled.

Original work was done by Dmitri Epshtein and Thomas Petazzoni. I
just adapted it to take care of Ben's comments.

Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
Cc: Dmitri Epshtein &lt;dima@marvell.com&gt;
Cc: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
Cc: Gregory CLEMENT &lt;gregory.clement@free-electrons.com&gt;
Cc: Ben Hutchings &lt;bhutchings@solarflare.com&gt;
Tested-by: Gregory CLEMENT &lt;gregory.clement@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>net: mvmdio: add select PHYLIB</title>
<updated>2013-05-01T16:46:19Z</updated>
<author>
<name>Thomas Petazzoni</name>
<email>thomas.petazzoni@free-electrons.com</email>
</author>
<published>2013-04-13T06:18:56Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=bb0fc43840dfbeb4f91d5fdd217449ad72b5d70d'/>
<id>urn:sha1:bb0fc43840dfbeb4f91d5fdd217449ad72b5d70d</id>
<content type='text'>
[ Upstream commit 2e0cbf2cc2c9371f0aa198857d799175ffe231a6 ]

The mvmdio driver uses the phylib API, so it should select the PHYLIB
symbol, otherwise, a build with mvmdio (but without mvneta) fails to
build with undefined symbols such as mdiobus_unregister, mdiobus_free,
etc.

The mvneta driver does not use the phylib API directly, so it does not
need to select PHYLIB. It already selects the mvmdio driver anyway.

Historically, this problem is due to the fact that the PHY handling
was originally part of mvneta, and was later moved to a separate
driver, without updating the Kconfig select statements
accordingly. And since there was no functional reason to use mvmdio
without mvneta, this case was not tested.

Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
Reported-by: Fengguang Wu &lt;fengguang.wu@intel.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>
