<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/net, branch v3.10.36</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.10.36</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.10.36'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2014-04-03T19:01:05Z</updated>
<entry>
<title>net: mvneta: rename MVNETA_GMAC2_PSC_ENABLE to MVNETA_GMAC2_PCS_ENABLE</title>
<updated>2014-04-03T19:01:05Z</updated>
<author>
<name>Thomas Petazzoni</name>
<email>thomas.petazzoni@free-electrons.com</email>
</author>
<published>2014-03-25T23:25:41Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d113edc6c7027a8290ddfb2f0c5ab8291a582945'/>
<id>urn:sha1:d113edc6c7027a8290ddfb2f0c5ab8291a582945</id>
<content type='text'>
commit a79121d3b57e7ad61f0b5d23eae05214054f3ccd upstream.

Bit 3 of the MVNETA_GMAC_CTRL_2 is actually used to enable the PCS,
not the PSC: there was a typo in the name of the define, which this
commit fixes.

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>e100: Fix "disabling already-disabled device" warning</title>
<updated>2014-03-31T16:58:14Z</updated>
<author>
<name>Michele Baldessari</name>
<email>michele@acksyn.org</email>
</author>
<published>2014-01-30T10:51:04Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=80ae5669330883e8bcf378a2ae6ef5f30326e809'/>
<id>urn:sha1:80ae5669330883e8bcf378a2ae6ef5f30326e809</id>
<content type='text'>
commit 2b6e0ca175fe4a20f21ba82b1e7ccc71029c4dd4 upstream.

In https://bugzilla.redhat.com/show_bug.cgi?id=994438 and
https://bugzilla.redhat.com/show_bug.cgi?id=970480  we
received different reports of e100 throwing the following
warning:

 [&lt;c06a0ba5&gt;] ? pci_disable_device+0x85/0x90
 [&lt;c044a153&gt;] warn_slowpath_fmt+0x33/0x40
 [&lt;c06a0ba5&gt;] pci_disable_device+0x85/0x90
 [&lt;f7fdf7e0&gt;] __e100_shutdown+0x80/0x120 [e100]
 [&lt;c0476ca5&gt;] ? check_preempt_curr+0x65/0x90
 [&lt;f7fdf8d6&gt;] e100_suspend+0x16/0x30 [e100]
 [&lt;c06a1ebb&gt;] pci_legacy_suspend+0x2b/0xb0
 [&lt;c098fc0f&gt;] ? wait_for_completion+0x1f/0xd0
 [&lt;c06a2d50&gt;] ? pci_pm_poweroff+0xb0/0xb0
 [&lt;c06a2de4&gt;] pci_pm_freeze+0x94/0xa0
 [&lt;c0767bb7&gt;] dpm_run_callback+0x37/0x80
 [&lt;c076a204&gt;] ? pm_wakeup_pending+0xc4/0x140
 [&lt;c0767f12&gt;] __device_suspend+0xb2/0x1f0
 [&lt;c076806f&gt;] async_suspend+0x1f/0x90
 [&lt;c04706e5&gt;] async_run_entry_fn+0x35/0x140
 [&lt;c0478aef&gt;] ? wake_up_process+0x1f/0x40
 [&lt;c0464495&gt;] process_one_work+0x115/0x370
 [&lt;c0462645&gt;] ? start_worker+0x25/0x30
 [&lt;c0464dc5&gt;] ? manage_workers.isra.27+0x1a5/0x250
 [&lt;c0464f6e&gt;] worker_thread+0xfe/0x330
 [&lt;c0464e70&gt;] ? manage_workers.isra.27+0x250/0x250
 [&lt;c046a224&gt;] kthread+0x94/0xa0
 [&lt;c0997f37&gt;] ret_from_kernel_thread+0x1b/0x28
 [&lt;c046a190&gt;] ? insert_kthread_work+0x30/0x30

This patch removes pci_disable_device() from __e100_shutdown().
pci_clear_master() is enough.

Signed-off-by: Michele Baldessari &lt;michele@acksyn.org&gt;
Tested-by: Mark Harig &lt;idirectscm@aim.com&gt;
Signed-off-by: Aaron Brown &lt;aaron.f.brown@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Cc: Josh Boyer &lt;jwboyer@fedoraproject.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>p54: clamp properly instead of just truncating</title>
<updated>2014-03-31T16:58:13Z</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2014-01-13T19:05:23Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d30a14a3f02d6d3aa51f429305c53905317bb4a7'/>
<id>urn:sha1:d30a14a3f02d6d3aa51f429305c53905317bb4a7</id>
<content type='text'>
commit 608cfbe4abaf76e9d732efd7ed1cfa3998163d91 upstream.

The call to clamp_t() first truncates the variable signed 8 bit and as a
result, the actual clamp is a no-op.

Fixes: 0d78156eef1d ('p54: improve site survey')
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.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: mvm: don't WARN when statistics are handled late</title>
<updated>2014-03-24T04:38:21Z</updated>
<author>
<name>Emmanuel Grumbach</name>
<email>emmanuel.grumbach@intel.com</email>
</author>
<published>2014-03-04T08:28:23Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=798610b539f631feef5af5bd713d197712e08ff1'/>
<id>urn:sha1:798610b539f631feef5af5bd713d197712e08ff1</id>
<content type='text'>
commit 1e9291996c4eedf79883f47ec635235e39d3d6cd upstream.

Since the statistics handler is asynchrous, it can very well
be that we will handle the statistics (hence the RSSI
fluctuation) when we already disassociated.
Don't WARN on this case.

This solves: https://bugzilla.redhat.com/show_bug.cgi?id=1071998

Fixes: 2b76ef13086f ("iwlwifi: mvm: implement reduced Tx power")
Reviewed-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</content>
</entry>
<entry>
<title>can: flexcan: flexcan_open(): fix error path if flexcan_chip_start() fails</title>
<updated>2014-03-24T04:38:19Z</updated>
<author>
<name>Marc Kleine-Budde</name>
<email>mkl@pengutronix.de</email>
</author>
<published>2014-02-28T13:52:01Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=7184df3a509dcf56c01d19b21709a7860d918600'/>
<id>urn:sha1:7184df3a509dcf56c01d19b21709a7860d918600</id>
<content type='text'>
commit 7e9e148af01ef388efb6e2490805970be4622792 upstream.

If flexcan_chip_start() in flexcan_open() fails, the interrupt is not freed,
this patch adds the missing cleanup.

Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>vmxnet3: fix building without CONFIG_PCI_MSI</title>
<updated>2014-03-24T04:38:18Z</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2014-03-13T09:44:34Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=40d2b82b4cb5b65473a7f3a6a93d7b0f8ad439ff'/>
<id>urn:sha1:40d2b82b4cb5b65473a7f3a6a93d7b0f8ad439ff</id>
<content type='text'>
commit 0a8d8c446b5429d15ff2d48f46e00d8a08552303 upstream.

Since commit d25f06ea466e "vmxnet3: fix netpoll race condition",
the vmxnet3 driver fails to build when CONFIG_PCI_MSI is disabled,
because it unconditionally references the vmxnet3_msix_rx()
function.

To fix this, use the same #ifdef in the caller that exists around
the function definition.

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: Neil Horman &lt;nhorman@tuxdriver.com&gt;
Cc: Shreyas Bhatewara &lt;sbhatewara@vmware.com&gt;
Cc: "VMware, Inc." &lt;pv-drivers@vmware.com&gt;
Cc: "David S. Miller" &lt;davem@davemloft.net&gt;
Acked-by: Neil Horman &lt;nhorman@tuxdriver.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>vmxnet3: fix netpoll race condition</title>
<updated>2014-03-24T04:38:18Z</updated>
<author>
<name>Neil Horman</name>
<email>nhorman@tuxdriver.com</email>
</author>
<published>2014-03-10T10:55:55Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=757319d8bb00395874ac77cc81f474581a4644b1'/>
<id>urn:sha1:757319d8bb00395874ac77cc81f474581a4644b1</id>
<content type='text'>
commit d25f06ea466ea521b563b76661180b4e44714ae6 upstream.

vmxnet3's netpoll driver is incorrectly coded.  It directly calls
vmxnet3_do_poll, which is the driver internal napi poll routine.  As the netpoll
controller method doesn't block real napi polls in any way, there is a potential
for race conditions in which the netpoll controller method and the napi poll
method run concurrently.  The result is data corruption causing panics such as this
one recently observed:
PID: 1371   TASK: ffff88023762caa0  CPU: 1   COMMAND: "rs:main Q:Reg"
 #0 [ffff88023abd5780] machine_kexec at ffffffff81038f3b
 #1 [ffff88023abd57e0] crash_kexec at ffffffff810c5d92
 #2 [ffff88023abd58b0] oops_end at ffffffff8152b570
 #3 [ffff88023abd58e0] die at ffffffff81010e0b
 #4 [ffff88023abd5910] do_trap at ffffffff8152add4
 #5 [ffff88023abd5970] do_invalid_op at ffffffff8100cf95
 #6 [ffff88023abd5a10] invalid_op at ffffffff8100bf9b
    [exception RIP: vmxnet3_rq_rx_complete+1968]
    RIP: ffffffffa00f1e80  RSP: ffff88023abd5ac8  RFLAGS: 00010086
    RAX: 0000000000000000  RBX: ffff88023b5dcee0  RCX: 00000000000000c0
    RDX: 0000000000000000  RSI: 00000000000005f2  RDI: ffff88023b5dcee0
    RBP: ffff88023abd5b48   R8: 0000000000000000   R9: ffff88023a3b6048
    R10: 0000000000000000  R11: 0000000000000002  R12: ffff8802398d4cd8
    R13: ffff88023af35140  R14: ffff88023b60c890  R15: 0000000000000000
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
 #7 [ffff88023abd5b50] vmxnet3_do_poll at ffffffffa00f204a [vmxnet3]
 #8 [ffff88023abd5b80] vmxnet3_netpoll at ffffffffa00f209c [vmxnet3]
 #9 [ffff88023abd5ba0] netpoll_poll_dev at ffffffff81472bb7

The fix is to do as other drivers do, and have the poll controller call the top
half interrupt handler, which schedules a napi poll properly to recieve frames

Tested by myself, successfully.

Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
CC: Shreyas Bhatewara &lt;sbhatewara@vmware.com&gt;
CC: "VMware, Inc." &lt;pv-drivers@vmware.com&gt;
CC: "David S. Miller" &lt;davem@davemloft.net&gt;
Reviewed-by: Shreyas N Bhatewara &lt;sbhatewara@vmware.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: save and copy AP's VHT capability info correctly</title>
<updated>2014-03-24T04:38:13Z</updated>
<author>
<name>Amitkumar Karwar</name>
<email>akarwar@marvell.com</email>
</author>
<published>2014-03-05T02:43:14Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=5184c0b7c349f6783986d1848a5f1cdf333075b1'/>
<id>urn:sha1:5184c0b7c349f6783986d1848a5f1cdf333075b1</id>
<content type='text'>
commit d51246481c7f28bbfa1f814ded2da65e531cd4b2 upstream.

While preparing association request, intersection of device's
VHT capability information and corresponding field advertised
by AP is used.

This patch fixes a couple errors while saving and copying vht_cap
and vht_oper fields from AP's beacon.

Signed-off-by: Amitkumar Karwar &lt;akarwar@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: copy AP's HT capability info correctly</title>
<updated>2014-03-24T04:38:13Z</updated>
<author>
<name>Amitkumar Karwar</name>
<email>akarwar@marvell.com</email>
</author>
<published>2014-03-05T02:43:13Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=eab0ff3d06510c626d121d51e599d4012847fd0f'/>
<id>urn:sha1:eab0ff3d06510c626d121d51e599d4012847fd0f</id>
<content type='text'>
commit c99b1861c232e1f641f13b8645e0febb3712cc71 upstream.

While preparing association request, intersection of device's HT
capability information and corresponding fields advertised by AP
is used.

This patch fixes an error while copying this field from AP's
beacon.

Signed-off-by: Amitkumar Karwar &lt;akarwar@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: do not advertise usb autosuspend support</title>
<updated>2014-03-24T04:38:13Z</updated>
<author>
<name>Bing Zhao</name>
<email>bzhao@marvell.com</email>
</author>
<published>2014-02-27T04:11:22Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=23436be689aa00750bfa3e7b99dfac26f45c4f0f'/>
<id>urn:sha1:23436be689aa00750bfa3e7b99dfac26f45c4f0f</id>
<content type='text'>
commit adb07df1e039e9fe43e66aeea8b4771f83659dbb upstream.

As many Surface Pro I &amp; II users have found out, the mwifiex_usb
doesn't support usb autosuspend, and it has caused some system
stability issues.

Bug 69661 - mwifiex_usb on MS Surface Pro 1 is unstable
Bug 60815 - Interface hangs in mwifiex_usb
Bug 64111 - mwifiex_usb USB8797 crash failed to get signal
 	    information

USB autosuspend get triggered when Surface Pro's AC power is
removed or powertop enables power saving on USB8797 device.
Driver's suspend handler is called here, but resume handler
won't be called until the AC power is put back on or powertop
disables power saving for USB8797.

We need to refactor the suspend/resume handlers to support
usb autosuspend properly. For now let's just remove it.

Signed-off-by: Bing Zhao &lt;bzhao@marvell.com&gt;
Signed-off-by: Amitkumar Karwar &lt;akarwar@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>
</feed>
