<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/net, branch v3.13.2</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>xen-netfront: fix resource leak in netfront</title>
<updated>2014-02-06T19:34:08+00:00</updated>
<author>
<name>Annie Li</name>
<email>annie.li@oracle.com</email>
</author>
<published>2014-01-28T03:35:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b84c36cb8ca10bdfc0ee8f3e1e74eaeb4010756c'/>
<id>b84c36cb8ca10bdfc0ee8f3e1e74eaeb4010756c</id>
<content type='text'>
[ Upstream commit cefe0078eea52af17411eb1248946a94afb84ca5 ]

This patch removes grant transfer releasing code from netfront, and uses
gnttab_end_foreign_access to end grant access since
gnttab_end_foreign_access_ref may fail when the grant entry is
currently used for reading or writing.

* clean up grant transfer code kept from old netfront(2.6.18) which grants
pages for access/map and transfer. But grant transfer is deprecated in current
netfront, so remove corresponding release code for transfer.

* fix resource leak, release grant access (through gnttab_end_foreign_access)
and skb for tx/rx path, use get_page to ensure page is released when grant
access is completed successfully.

Xen-blkfront/xen-tpmfront/xen-pcifront also have similar issue, but patches
for them will be created separately.

V6: Correct subject line and commit message.

V5: Remove unecessary change in xennet_end_access.

V4: Revert put_page in gnttab_end_foreign_access, and keep netfront change in
single patch.

V3: Changes as suggestion from David Vrabel, ensure pages are not freed untill
grant acess is ended.

V2: Improve patch comments.

Signed-off-by: Annie Li &lt;annie.li@oracle.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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit cefe0078eea52af17411eb1248946a94afb84ca5 ]

This patch removes grant transfer releasing code from netfront, and uses
gnttab_end_foreign_access to end grant access since
gnttab_end_foreign_access_ref may fail when the grant entry is
currently used for reading or writing.

* clean up grant transfer code kept from old netfront(2.6.18) which grants
pages for access/map and transfer. But grant transfer is deprecated in current
netfront, so remove corresponding release code for transfer.

* fix resource leak, release grant access (through gnttab_end_foreign_access)
and skb for tx/rx path, use get_page to ensure page is released when grant
access is completed successfully.

Xen-blkfront/xen-tpmfront/xen-pcifront also have similar issue, but patches
for them will be created separately.

V6: Correct subject line and commit message.

V5: Remove unecessary change in xennet_end_access.

V4: Revert put_page in gnttab_end_foreign_access, and keep netfront change in
single patch.

V3: Changes as suggestion from David Vrabel, ensure pages are not freed untill
grant acess is ended.

V2: Improve patch comments.

Signed-off-by: Annie Li &lt;annie.li@oracle.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net/vxlan: Share RX skb de-marking and checksum checks with ovs</title>
<updated>2014-02-06T19:34:07+00:00</updated>
<author>
<name>Or Gerlitz</name>
<email>ogerlitz@mellanox.com</email>
</author>
<published>2014-01-23T09:28:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=93199ca47ddf8047144d5569f19564fdbaf7ec40'/>
<id>93199ca47ddf8047144d5569f19564fdbaf7ec40</id>
<content type='text'>
[ Upstream commit d0bc65557ad09a57b4db176e9e3ccddb26971453 ]

Make sure the practice set by commit 0afb166 "vxlan: Add capability
of Rx checksum offload for inner packet" is applied when the skb
goes through the portion of the RX code which is shared between
vxlan netdevices and ovs vxlan port instances.

Cc: Joseph Gasparakis &lt;joseph.gasparakis@intel.com&gt;
Cc: Pravin B Shelar &lt;pshelar@nicira.com&gt;
Signed-off-by: Or Gerlitz &lt;ogerlitz@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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit d0bc65557ad09a57b4db176e9e3ccddb26971453 ]

Make sure the practice set by commit 0afb166 "vxlan: Add capability
of Rx checksum offload for inner packet" is applied when the skb
goes through the portion of the RX code which is shared between
vxlan netdevices and ovs vxlan port instances.

Cc: Joseph Gasparakis &lt;joseph.gasparakis@intel.com&gt;
Cc: Pravin B Shelar &lt;pshelar@nicira.com&gt;
Signed-off-by: Or Gerlitz &lt;ogerlitz@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;
</pre>
</div>
</content>
</entry>
<entry>
<title>ath9k: Disable cross-band FCC</title>
<updated>2014-02-06T19:33:57+00:00</updated>
<author>
<name>Sujith Manoharan</name>
<email>c_manoha@qca.qualcomm.com</email>
</author>
<published>2014-01-09T03:21:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f4c8e868983e927b1bf93508c805f1f08a2afcc4'/>
<id>f4c8e868983e927b1bf93508c805f1f08a2afcc4</id>
<content type='text'>
commit 1e2f9295f4c657500111514f92a3d3894d0e05b4 upstream.

Fast Channel Change across bands was enabled for
AR9462 recently, but this is causing baseband issues.
Disable it until this feature is tested well. Also,
remove the feature bit for AR9565 since it is
a single-band card and doesn't support this feature.

Reported-by: Oleksij Rempel &lt;linux@rempel-privat.de&gt;
Signed-off-by: Sujith Manoharan &lt;c_manoha@qca.qualcomm.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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 1e2f9295f4c657500111514f92a3d3894d0e05b4 upstream.

Fast Channel Change across bands was enabled for
AR9462 recently, but this is causing baseband issues.
Disable it until this feature is tested well. Also,
remove the feature bit for AR9565 since it is
a single-band card and doesn't support this feature.

Reported-by: Oleksij Rempel &lt;linux@rempel-privat.de&gt;
Signed-off-by: Sujith Manoharan &lt;c_manoha@qca.qualcomm.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ath9k: Use correct channel for RX packets</title>
<updated>2014-02-06T19:33:57+00:00</updated>
<author>
<name>Sujith Manoharan</name>
<email>c_manoha@qca.qualcomm.com</email>
</author>
<published>2014-01-09T03:21:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=84666036f8a6b46492db7dd04b733732a4f3a542'/>
<id>84666036f8a6b46492db7dd04b733732a4f3a542</id>
<content type='text'>
commit ff9a93f2ebb88ac7aab9568de80b64b92078e96d upstream.

Accessing the current channel definition in mac80211
when processing RX packets is problematic because it
could have been updated when a scan is issued. Since a
channel change involves flushing the existing packets
in the RX queue before a chip-reset is done, they would
be processed using the wrong band/channel information.

To avoid this, use the current channel information
maintained in the driver.

Reported-by: Oleksij Rempel &lt;linux@rempel-privat.de&gt;
Signed-off-by: Sujith Manoharan &lt;c_manoha@qca.qualcomm.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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ff9a93f2ebb88ac7aab9568de80b64b92078e96d upstream.

Accessing the current channel definition in mac80211
when processing RX packets is problematic because it
could have been updated when a scan is issued. Since a
channel change involves flushing the existing packets
in the RX queue before a chip-reset is done, they would
be processed using the wrong band/channel information.

To avoid this, use the current channel information
maintained in the driver.

Reported-by: Oleksij Rempel &lt;linux@rempel-privat.de&gt;
Signed-off-by: Sujith Manoharan &lt;c_manoha@qca.qualcomm.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>b43: fix the wrong assignment of status.freq in b43_rx()</title>
<updated>2014-02-06T19:33:57+00:00</updated>
<author>
<name>ZHAO Gang</name>
<email>gamerh2o@gmail.com</email>
</author>
<published>2014-01-17T16:17:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ed8034b113a9d491499ab650be0487431b6e32cf'/>
<id>ed8034b113a9d491499ab650be0487431b6e32cf</id>
<content type='text'>
commit 64e5acb09ca6b50c97299cff9ef51299470b29f2 upstream.

Use the right function to update frequency value.

If rx skb is probe response or beacon, the wrong frequency value can
cause problem that bss info can't be updated when it should be.

Fixes: 8318d78a44d4 ("cfg80211 API for channels/bitrates, mac80211 and driver conversion")
Signed-off-by: ZHAO Gang &lt;gamerh2o@gmail.com&gt;
Acked-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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 64e5acb09ca6b50c97299cff9ef51299470b29f2 upstream.

Use the right function to update frequency value.

If rx skb is probe response or beacon, the wrong frequency value can
cause problem that bss info can't be updated when it should be.

Fixes: 8318d78a44d4 ("cfg80211 API for channels/bitrates, mac80211 and driver conversion")
Signed-off-by: ZHAO Gang &lt;gamerh2o@gmail.com&gt;
Acked-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;

</pre>
</div>
</content>
</entry>
<entry>
<title>b43legacy: Fix unload oops if firmware is not available</title>
<updated>2014-02-06T19:33:57+00:00</updated>
<author>
<name>Larry Finger</name>
<email>Larry.Finger@lwfinger.net</email>
</author>
<published>2014-01-12T21:11:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=94080dee38400618751ed156107ffac856ac22b9'/>
<id>94080dee38400618751ed156107ffac856ac22b9</id>
<content type='text'>
commit 452028665312672c6ba9e16a19248ee00ead9400 upstream.

The asyncronous firmware load uses a completion struct to hold firmware
processing until the user-space routines are up and running. There is.
however, a problem in that the waiter is nevered canceled during teardown.
As a result, unloading the driver when firmware is not available causes an oops.

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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 452028665312672c6ba9e16a19248ee00ead9400 upstream.

The asyncronous firmware load uses a completion struct to hold firmware
processing until the user-space routines are up and running. There is.
however, a problem in that the waiter is nevered canceled during teardown.
As a result, unloading the driver when firmware is not available causes an oops.

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;

</pre>
</div>
</content>
</entry>
<entry>
<title>b43: Fix unload oops if firmware is not available</title>
<updated>2014-02-06T19:33:57+00:00</updated>
<author>
<name>Larry Finger</name>
<email>Larry.Finger@lwfinger.net</email>
</author>
<published>2014-01-12T21:11:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8365103d678e6be9952722b22dbe7c2b8331757c'/>
<id>8365103d678e6be9952722b22dbe7c2b8331757c</id>
<content type='text'>
commit 0673effd41dba323d6a280ef37b5ef29f3f5a653 upstream.

The asyncronous firmware load uses a completion struct to hold firmware
processing until the user-space routines are up and running. There is.
however, a problem in that the waiter is nevered canceled during teardown.
As a result, unloading the driver when firmware is not available causes an oops.

To be able to access the completion structure at teardown, it had to be moved
into the b43_wldev structure.

This patch also fixes a typo in a comment.

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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 0673effd41dba323d6a280ef37b5ef29f3f5a653 upstream.

The asyncronous firmware load uses a completion struct to hold firmware
processing until the user-space routines are up and running. There is.
however, a problem in that the waiter is nevered canceled during teardown.
As a result, unloading the driver when firmware is not available causes an oops.

To be able to access the completion structure at teardown, it had to be moved
into the b43_wldev structure.

This patch also fixes a typo in a comment.

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;

</pre>
</div>
</content>
</entry>
<entry>
<title>b43: Fix lockdep splat</title>
<updated>2014-02-06T19:33:57+00:00</updated>
<author>
<name>Larry Finger</name>
<email>Larry.Finger@lwfinger.net</email>
</author>
<published>2014-01-12T21:11:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=dd6ccf171f67ef638f000f6e70bb83c62e6c62c7'/>
<id>dd6ccf171f67ef638f000f6e70bb83c62e6c62c7</id>
<content type='text'>
commit 09164043f63c947a49797750a09ca1cd7c31108e upstream.

In https://bugzilla.kernel.org/show_bug.cgi?id=67561, a locking dependency is reported
when b43 is used with hostapd, and rfkill is used to kill the radio output.

The lockdep splat (in part) is as follows:

======================================================
[ INFO: possible circular locking dependency detected ]
3.12.0 #1 Not tainted
-------------------------------------------------------
rfkill/10040 is trying to acquire lock:
 (rtnl_mutex){+.+.+.}, at: [&lt;ffffffff8146f282&gt;] rtnl_lock+0x12/0x20

but task is already holding lock:
 (rfkill_global_mutex){+.+.+.}, at: [&lt;ffffffffa04832ca&gt;] rfkill_fop_write+0x6a/0x170 [rfkill]

--snip--

Chain exists of:
  rtnl_mutex --&gt; misc_mtx --&gt; rfkill_global_mutex

The fix is to move the initialization of the hardware random number generator
outside the code range covered by the rtnl_mutex.

Reported-by: yury &lt;urykhy@gmail.com&gt;
Tested-by: yury &lt;urykhy@gmail.com&gt;
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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 09164043f63c947a49797750a09ca1cd7c31108e upstream.

In https://bugzilla.kernel.org/show_bug.cgi?id=67561, a locking dependency is reported
when b43 is used with hostapd, and rfkill is used to kill the radio output.

The lockdep splat (in part) is as follows:

======================================================
[ INFO: possible circular locking dependency detected ]
3.12.0 #1 Not tainted
-------------------------------------------------------
rfkill/10040 is trying to acquire lock:
 (rtnl_mutex){+.+.+.}, at: [&lt;ffffffff8146f282&gt;] rtnl_lock+0x12/0x20

but task is already holding lock:
 (rfkill_global_mutex){+.+.+.}, at: [&lt;ffffffffa04832ca&gt;] rfkill_fop_write+0x6a/0x170 [rfkill]

--snip--

Chain exists of:
  rtnl_mutex --&gt; misc_mtx --&gt; rfkill_global_mutex

The fix is to move the initialization of the hardware random number generator
outside the code range covered by the rtnl_mutex.

Reported-by: yury &lt;urykhy@gmail.com&gt;
Tested-by: yury &lt;urykhy@gmail.com&gt;
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;

</pre>
</div>
</content>
</entry>
<entry>
<title>iwlwifi: mvm: fix missing cleanup in .start() error path</title>
<updated>2014-02-06T19:33:57+00:00</updated>
<author>
<name>Eliad Peller</name>
<email>eliadx.peller@intel.com</email>
</author>
<published>2014-01-05T10:41:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4aca366c885d29df6ca9803c13fd92e2b4f42854'/>
<id>4aca366c885d29df6ca9803c13fd92e2b4f42854</id>
<content type='text'>
commit 91b0d1198417cf4fd9a7bd4138b6909f0b359099 upstream.

Cleanup of iwl_mvm_leds was missing in case of error,
resulting in the following warning:

WARNING: at lib/kobject.c:196 kobject_add_internal+0x1f4/0x210()
kobject_add_internal failed for phy0-led with -EEXIST, don't try to register things with the same name in the same directory.

which prevents further reloads of the driver.

Signed-off-by: Eliad Peller &lt;eliadx.peller@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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 91b0d1198417cf4fd9a7bd4138b6909f0b359099 upstream.

Cleanup of iwl_mvm_leds was missing in case of error,
resulting in the following warning:

WARNING: at lib/kobject.c:196 kobject_add_internal+0x1f4/0x210()
kobject_add_internal failed for phy0-led with -EEXIST, don't try to register things with the same name in the same directory.

which prevents further reloads of the driver.

Signed-off-by: Eliad Peller &lt;eliadx.peller@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;

</pre>
</div>
</content>
</entry>
<entry>
<title>iwlwifi: pcie: enable oscillator for L1 exit</title>
<updated>2014-02-06T19:33:56+00:00</updated>
<author>
<name>Emmanuel Grumbach</name>
<email>emmanuel.grumbach@intel.com</email>
</author>
<published>2013-12-24T12:15:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=79a7d9a826165fcdde29bac4bec2f3da41f0a18a'/>
<id>79a7d9a826165fcdde29bac4bec2f3da41f0a18a</id>
<content type='text'>
commit 2d93aee152b1758a94a18fe15d72153ba73b5679 upstream.

Enabling the oscillator consumes slightly more power (100uA)
but allows to make sure that we exit from L1 on time.

Not doing so might lead to a PCIe specification violation
since we might wake up from L1 at the wrong time.
This issue has been identified on 3160 and 7260 only.
On older NICs L1 off is not enabled, on newer NICs (7265),
the issue is fixed.

When the bug occurs the user sees that the NIC has
disappeared from the PCI bridge, any access to the device
returns 0xff.

This fixes:
	https://bugzilla.kernel.org/show_bug.cgi?id=64541

and has been extensively discussed here:
	http://markmail.org/thread/mfmpzqt3r333n4bo

Fixes: 99cd47142399 ("iwlwifi: add 7000 series device configuration")
Reported-and-tested-by: wzyboy &lt;wzyboy@wzyboy.org&gt;
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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2d93aee152b1758a94a18fe15d72153ba73b5679 upstream.

Enabling the oscillator consumes slightly more power (100uA)
but allows to make sure that we exit from L1 on time.

Not doing so might lead to a PCIe specification violation
since we might wake up from L1 at the wrong time.
This issue has been identified on 3160 and 7260 only.
On older NICs L1 off is not enabled, on newer NICs (7265),
the issue is fixed.

When the bug occurs the user sees that the NIC has
disappeared from the PCI bridge, any access to the device
returns 0xff.

This fixes:
	https://bugzilla.kernel.org/show_bug.cgi?id=64541

and has been extensively discussed here:
	http://markmail.org/thread/mfmpzqt3r333n4bo

Fixes: 99cd47142399 ("iwlwifi: add 7000 series device configuration")
Reported-and-tested-by: wzyboy &lt;wzyboy@wzyboy.org&gt;
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;

</pre>
</div>
</content>
</entry>
</feed>
