<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/net, branch v3.2.11</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.2.11</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.2.11'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2012-03-12T19:31:40Z</updated>
<entry>
<title>net/usbnet: avoid recursive locking in usbnet_stop()</title>
<updated>2012-03-12T19:31:40Z</updated>
<author>
<name>Sebastian Siewior</name>
<email>bigeasy@linutronix.de</email>
</author>
<published>2012-03-07T10:19:28Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=5df11c989c126568ce9d383ec1898bfeb8548ed4'/>
<id>urn:sha1:5df11c989c126568ce9d383ec1898bfeb8548ed4</id>
<content type='text'>
commit 4231d47e6fe69f061f96c98c30eaf9fb4c14b96d upstream.

|kernel BUG at kernel/rtmutex.c:724!
|[&lt;c029599c&gt;] (rt_spin_lock_slowlock+0x108/0x2bc) from [&lt;c01c2330&gt;] (defer_bh+0x1c/0xb4)
|[&lt;c01c2330&gt;] (defer_bh+0x1c/0xb4) from [&lt;c01c3afc&gt;] (rx_complete+0x14c/0x194)
|[&lt;c01c3afc&gt;] (rx_complete+0x14c/0x194) from [&lt;c01cac88&gt;] (usb_hcd_giveback_urb+0xa0/0xf0)
|[&lt;c01cac88&gt;] (usb_hcd_giveback_urb+0xa0/0xf0) from [&lt;c01e1ff4&gt;] (musb_giveback+0x34/0x40)
|[&lt;c01e1ff4&gt;] (musb_giveback+0x34/0x40) from [&lt;c01e2b1c&gt;] (musb_advance_schedule+0xb4/0x1c0)
|[&lt;c01e2b1c&gt;] (musb_advance_schedule+0xb4/0x1c0) from [&lt;c01e2ca8&gt;] (musb_cleanup_urb.isra.9+0x80/0x8c)
|[&lt;c01e2ca8&gt;] (musb_cleanup_urb.isra.9+0x80/0x8c) from [&lt;c01e2ed0&gt;] (musb_urb_dequeue+0xec/0x108)
|[&lt;c01e2ed0&gt;] (musb_urb_dequeue+0xec/0x108) from [&lt;c01cbb90&gt;] (unlink1+0xbc/0xcc)
|[&lt;c01cbb90&gt;] (unlink1+0xbc/0xcc) from [&lt;c01cc2ec&gt;] (usb_hcd_unlink_urb+0x54/0xa8)
|[&lt;c01cc2ec&gt;] (usb_hcd_unlink_urb+0x54/0xa8) from [&lt;c01c2a84&gt;] (unlink_urbs.isra.17+0x2c/0x58)
|[&lt;c01c2a84&gt;] (unlink_urbs.isra.17+0x2c/0x58) from [&lt;c01c2b44&gt;] (usbnet_terminate_urbs+0x94/0x10c)
|[&lt;c01c2b44&gt;] (usbnet_terminate_urbs+0x94/0x10c) from [&lt;c01c2d68&gt;] (usbnet_stop+0x100/0x15c)
|[&lt;c01c2d68&gt;] (usbnet_stop+0x100/0x15c) from [&lt;c020f718&gt;] (__dev_close_many+0x94/0xc8)

defer_bh() takes the lock which is hold during unlink_urbs(). The safe
walk suggest that the skb will be removed from the list and this is done
by defer_bh() so it seems to be okay to drop the lock here.

Reported-by: AnÃ­bal Almeida Pinto &lt;anibal.pinto@efacec.com&gt;
Signed-off-by: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Acked-by: Oliver Neukum &lt;oliver@neukum.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>carl9170: fix frame delivery if sta is in powersave mode</title>
<updated>2012-03-12T19:31:40Z</updated>
<author>
<name>Christian Lamparter</name>
<email>chunkeey@googlemail.com</email>
</author>
<published>2012-02-25T20:36:36Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2cfb4e5c22726c099645a7e5fc447d4ffcfca85c'/>
<id>urn:sha1:2cfb4e5c22726c099645a7e5fc447d4ffcfca85c</id>
<content type='text'>
commit 9926a67557532acb6cddb1c1add02952175b5c72 upstream.

Nicolas Cavallari discovered that carl9170 has some
serious problems delivering data to sleeping stations.

It turns out that the driver was not honoring two
important flags (IEEE80211_TX_CTL_POLL_RESPONSE and
IEEE80211_TX_CTL_CLEAR_PS_FILT) which are set on
frames that should be sent although the receiving
station is still in powersave mode.

Reported-by: Nicolas Cavallari &lt;Nicolas.Cavallari@lri.fr&gt;
Signed-off-by: Christian Lamparter &lt;chunkeey@googlemail.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>carl9170: Fix memory accounting when sta is in power-save mode.</title>
<updated>2012-03-12T19:31:40Z</updated>
<author>
<name>Nicolas Cavallari</name>
<email>Nicolas.Cavallari@lri.fr</email>
</author>
<published>2012-02-23T15:53:34Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=273c20d42332bbbf368a0c61c330055b5fd695dc'/>
<id>urn:sha1:273c20d42332bbbf368a0c61c330055b5fd695dc</id>
<content type='text'>
commit 992d52529d7840236d3059b51c15d5eb9e81a869 upstream.

On Access Point mode, when transmitting a packet, if the destination
station is in powersave mode, we abort transmitting the packet to the
device queue, but we do not reclaim the allocated memory.  Given enough
packets, we can go in a state where there is no packet on the device
queue, but we think the device has no memory left, so no packet gets
transmitted, connections breaks and the AP stops working.

This undo the allocation done in the TX path when the station is in
power-save mode.

Signed-off-by: Nicolas Cavallari &lt;cavallar@lri.fr&gt;
Acked-by: Christian Lamparter &lt;chunkeey@googlemail.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>rtl8192cu: Add new device IDs</title>
<updated>2012-03-12T19:31:36Z</updated>
<author>
<name>Larry Finger</name>
<email>Larry.Finger@lwfinger.net</email>
</author>
<published>2011-10-18T22:52:01Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=7b53686e9944fb4cc14b47028214d615dc6fbe9e'/>
<id>urn:sha1:7b53686e9944fb4cc14b47028214d615dc6fbe9e</id>
<content type='text'>
commit 6cddafab54e9a17b2efefe982547865955a5ff3a upstream.

The latest vendor (non-mac80211) driver of 9/22/2011 shows some new
device IDs for rtl8192cu. In addition, some typos in the table are
fixed and one duplicate is removed.

Signed-off-by: Larry Finger &lt;Larry.Finger@lwfinger.net&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: fix key removal</title>
<updated>2012-03-12T19:31:26Z</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2012-02-17T17:47:14Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=dec68ee3f8f3b49388f5480ae56ec7e0cb915561'/>
<id>urn:sha1:dec68ee3f8f3b49388f5480ae56ec7e0cb915561</id>
<content type='text'>
commit 5dcbf480473f6c3f06ad2426b7517038a2a18911 upstream.

When trying to remove a key, we always send key
flags just setting the key type, not including
the multicast flag and the key ID. As a result,
whenever any key was removed, the unicast key 0
would be removed, causing a complete connection
loss after the second rekey (the first doesn't
cause a key removal). Fix the key removal code
to include the key ID and multicast flag, thus
removing the correct key.

Reported-by: Alexander Schnaidt &lt;alex.schnaidt@googlemail.com&gt;
Tested-by: Alexander Schnaidt &lt;alex.schnaidt@googlemail.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Wey-Yi Guy &lt;wey-yi.w.guy@intel.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>ath9k_hw: prevent writes to const data on AR9160</title>
<updated>2012-03-12T19:31:26Z</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@openwrt.org</email>
</author>
<published>2012-02-15T18:31:20Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=06592e8c1b19bc007098e3d59ef6d8486a6c3c7d'/>
<id>urn:sha1:06592e8c1b19bc007098e3d59ef6d8486a6c3c7d</id>
<content type='text'>
commit 9bbb8168ed3d8b946f9c1901a63a675012de88f2 upstream.

Duplicate the data for iniAddac early on, to avoid having to do redundant
memcpy calls later. While we're at it, make AR5416 &lt; v2.2 use the same
codepath. Fixes a reported crash on x86.

Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Reported-by: Magnus Määttä &lt;magnus.maatta@logica.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>Move Logitech Harmony 900 from cdc_ether to zaurus</title>
<updated>2012-03-12T19:31:25Z</updated>
<author>
<name>Scott Talbert</name>
<email>talbert@techie.net</email>
</author>
<published>2012-02-21T13:06:00Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=4826cda9a753db2a4aea6e1292d21a1f9cd85ea3'/>
<id>urn:sha1:4826cda9a753db2a4aea6e1292d21a1f9cd85ea3</id>
<content type='text'>
commit ee932bf9acb2e2c6a309e808000f24856330e3f9 upstream.

In the current kernel implementation, the Logitech Harmony 900 remote
control is matched to the cdc_ether driver through the generic
USB_CDC_SUBCLASS_MDLM entry.  However, this device appears to be of the
pseudo-MDLM (Belcarra) type, rather than the standard one.  This patch
blacklists the Harmony 900 from the cdc_ether driver and whitelists it for
the pseudo-MDLM driver in zaurus.

Signed-off-by: Scott Talbert &lt;talbert@techie.net&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>can: sja1000: fix isr hang when hw is unplugged under load</title>
<updated>2012-03-01T00:31:21Z</updated>
<author>
<name>Oliver Hartkopp</name>
<email>socketcan@hartkopp.net</email>
</author>
<published>2012-02-15T16:51:56Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9bda01cc81b40639565e63223d7c5413bb15b99a'/>
<id>urn:sha1:9bda01cc81b40639565e63223d7c5413bb15b99a</id>
<content type='text'>
commit a7762b10c12a70c5dbf2253142764b728ac88c3a upstream.

In the case of hotplug enabled devices (PCMCIA/PCIeC) the removal of the
hardware can cause an infinite loop in the common sja1000 isr.

Use the already retrieved status register to indicate a possible hardware
removal and double check by reading the mode register in sja1000_is_absent.

Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Acked-by: Wolfgang Grandegger &lt;wg@grandegger.com&gt;
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>davinci_emac: Do not free all rx dma descriptors during init</title>
<updated>2012-03-01T00:31:19Z</updated>
<author>
<name>Christian Riesch</name>
<email>christian.riesch@omicron.at</email>
</author>
<published>2012-02-23T01:14:17Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=df9a5f8f94f3276aaa8c960a46f6838f7fdab974'/>
<id>urn:sha1:df9a5f8f94f3276aaa8c960a46f6838f7fdab974</id>
<content type='text'>
commit 5d69703263d588dbb03f4e57091afd8942d96e6d upstream.

This patch fixes a regression that was introduced by

commit 0a5f38467765ee15478db90d81e40c269c8dda20
davinci_emac: Add Carrier Link OK check in Davinci RX Handler

Said commit adds a check whether the carrier link is ok. If the link is
not ok, the skb is freed and no new dma descriptor added to the rx dma
channel. This causes trouble during initialization when the carrier
status has not yet been updated. If a lot of packets are received while
netif_carrier_ok returns false, all dma descriptors are freed and the
rx dma transfer is stopped.

The bug occurs when the board is connected to a network with lots of
traffic and the ifconfig down/up is done, e.g., when reconfiguring
the interface with DHCP.

The bug can be reproduced by flood pinging the davinci board while doing
ifconfig eth0 down
ifconfig eth0 up
on the board.

After that, the rx path stops working and the overrun value reported
by ifconfig is counting up.

This patch reverts commit 0a5f38467765ee15478db90d81e40c269c8dda20
and instead issues warnings only if cpdma_chan_submit returns -ENOMEM.

Signed-off-by: Christian Riesch &lt;christian.riesch@omicron.at&gt;
Cc: Cyril Chemparathy &lt;cyril@ti.com&gt;
Cc: Sascha Hauer &lt;s.hauer@pengutronix.de&gt;
Tested-by: Rajashekhara, Sudhakar &lt;sudhakar.raj@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>jme: Fix FIFO flush issue</title>
<updated>2012-03-01T00:31:19Z</updated>
<author>
<name>Guo-Fu Tseng</name>
<email>cooldavid@cooldavid.org</email>
</author>
<published>2012-02-22T08:58:10Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=5fbc730462e4c65e83bc343c4d3f97292b867ff7'/>
<id>urn:sha1:5fbc730462e4c65e83bc343c4d3f97292b867ff7</id>
<content type='text'>
commit ba9adbe67e288823ac1deb7f11576ab5653f833e upstream.

Set the RX FIFO flush watermark lower.
According to Federico and JMicron's reply,
setting it to 16QW would be stable on most platforms.
Otherwise, user might experience packet drop issue.

Reported-by: Federico Quagliata &lt;federico@quagliata.org&gt;
Fixed-by: Federico Quagliata &lt;federico@quagliata.org&gt;
Signed-off-by: Guo-Fu Tseng &lt;cooldavid@cooldavid.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>
</feed>
