<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/include/linux/libata.h, branch v3.16.61</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v3.16.61</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v3.16.61'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2018-11-20T18:05:32+00:00</updated>
<entry>
<title>ahci: Disable LPM on Lenovo 50 series laptops with a too old BIOS</title>
<updated>2018-11-20T18:05:32+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2018-07-01T10:15:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=299d81e2c0fd60590e9ac2799172ed3f8dfd1e0b'/>
<id>urn:sha1:299d81e2c0fd60590e9ac2799172ed3f8dfd1e0b</id>
<content type='text'>
commit 240630e61870e62e39a97225048f9945848fa5f5 upstream.

There have been several reports of LPM related hard freezes about once
a day on multiple Lenovo 50 series models. Strange enough these reports
where not disk model specific as LPM issues usually are and some users
with the exact same disk + laptop where seeing them while other users
where not seeing these issues.

It turns out that enabling LPM triggers a firmware bug somewhere, which
has been fixed in later BIOS versions.

This commit adds a new ahci_broken_lpm() function and a new ATA_FLAG_NO_LPM
for dealing with this.

The ahci_broken_lpm() function contains DMI match info for the 4 models
which are known to be affected by this and the DMI BIOS date field for
known good BIOS versions. If the BIOS date is older then the one in the
table LPM will be disabled and a warning will be printed.

Note the BIOS dates are for known good versions, some older versions may
work too, but we don't know for sure, the table is using dates from BIOS
versions for which users have confirmed that upgrading to that version
makes the problem go away.

Unfortunately I've been unable to get hold of the reporter who reported
that BIOS version 2.35 fixed the problems on the W541 for him. I've been
able to verify the DMI_SYS_VENDOR and DMI_PRODUCT_VERSION from an older
dmidecode, but I don't know the exact BIOS date as reported in the DMI.
Lenovo keeps a changelog with dates in their release notes, but the
dates there are the release dates not the build dates which are in DMI.
So I've chosen to set the date to which we compare to one day past the
release date of the 2.34 BIOS. I plan to fix this with a follow up
commit once I've the necessary info.

Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>ata: Add a new flag to destinguish sas controller</title>
<updated>2018-06-16T21:22:31+00:00</updated>
<author>
<name>Shaohua Li</name>
<email>shli@fb.com</email>
</author>
<published>2015-03-12T17:32:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e36909b37bcb89d57ee81a7aef151b7f02b2a496'/>
<id>urn:sha1:e36909b37bcb89d57ee81a7aef151b7f02b2a496</id>
<content type='text'>
commit 5067c0469c643512f24786990e315f9c15cc7d24 upstream.

SAS controller has its own tag allocation, which doesn't directly match to ATA
tag, so SAS and SATA have different code path for ata tags. Originally we use
port-&gt;scsi_host (98bd4be1) to destinguish SAS controller, but libsas set
-&gt;scsi_host too, so we can't use it for the destinguish, we add a new flag for
this purpose.

Without this patch, the following oops can happen because scsi-mq uses
a host-wide tag map shared among all devices with some integer tag
values &gt;= ATA_MAX_QUEUE.  These unexpectedly high tag values cause
__ata_qc_from_tag() to return NULL, which is then dereferenced in
ata_qc_new_init().

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
  IP: [&lt;ffffffff804fd46e&gt;] ata_qc_new_init+0x3e/0x120
  PGD 32adf0067 PUD 32adf1067 PMD 0
  Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
  Modules linked in: iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi igb
  i2c_algo_bit ptp pps_core pm80xx libsas scsi_transport_sas sg coretemp
  eeprom w83795 i2c_i801
  CPU: 4 PID: 1450 Comm: cydiskbench Not tainted 4.0.0-rc3 #1
  Hardware name: Supermicro X8DTH-i/6/iF/6F/X8DTH, BIOS 2.1b       05/04/12
  task: ffff8800ba86d500 ti: ffff88032a064000 task.ti: ffff88032a064000
  RIP: 0010:[&lt;ffffffff804fd46e&gt;]  [&lt;ffffffff804fd46e&gt;] ata_qc_new_init+0x3e/0x120
  RSP: 0018:ffff88032a067858  EFLAGS: 00010046
  RAX: 0000000000000000 RBX: ffff8800ba0d2230 RCX: 000000000000002a
  RDX: ffffffff80505ae0 RSI: 0000000000000020 RDI: ffff8800ba0d2230
  RBP: ffff88032a067868 R08: 0000000000000201 R09: 0000000000000001
  R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800ba0d0000
  R13: ffff8800ba0d2230 R14: ffffffff80505ae0 R15: ffff8800ba0d0000
  FS:  0000000041223950(0063) GS:ffff88033e480000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
  CR2: 0000000000000058 CR3: 000000032a0a3000 CR4: 00000000000006e0
  Stack:
   ffff880329eee758 ffff880329eee758 ffff88032a0678a8 ffffffff80502dad
   ffff8800ba167978 ffff880329eee758 ffff88032bf9c520 ffff8800ba167978
   ffff88032bf9c520 ffff88032bf9a290 ffff88032a0678b8 ffffffff80506909
  Call Trace:
   [&lt;ffffffff80502dad&gt;] ata_scsi_translate+0x3d/0x1b0
   [&lt;ffffffff80506909&gt;] ata_sas_queuecmd+0x149/0x2a0
   [&lt;ffffffffa0046650&gt;] sas_queuecommand+0xa0/0x1f0 [libsas]
   [&lt;ffffffff804ea544&gt;] scsi_dispatch_cmd+0xd4/0x1a0
   [&lt;ffffffff804eb50f&gt;] scsi_queue_rq+0x66f/0x7f0
   [&lt;ffffffff803e5098&gt;] __blk_mq_run_hw_queue+0x208/0x3f0
   [&lt;ffffffff803e54b8&gt;] blk_mq_run_hw_queue+0x88/0xc0
   [&lt;ffffffff803e5c74&gt;] blk_mq_insert_request+0xc4/0x130
   [&lt;ffffffff803e0b63&gt;] blk_execute_rq_nowait+0x73/0x160
   [&lt;ffffffffa0023fca&gt;] sg_common_write+0x3da/0x720 [sg]
   [&lt;ffffffffa0025100&gt;] sg_new_write+0x250/0x360 [sg]
   [&lt;ffffffffa0025feb&gt;] sg_write+0x13b/0x450 [sg]
   [&lt;ffffffff8032ec91&gt;] vfs_write+0xd1/0x1b0
   [&lt;ffffffff8032ee54&gt;] SyS_write+0x54/0xc0
   [&lt;ffffffff80689932&gt;] system_call_fastpath+0x12/0x17

tj: updated description.

Fixes: 12cb5ce101ab ("libata: use blk taging")
Reported-and-tested-by: Tony Battersby &lt;tonyb@cybernetics.com&gt;
Signed-off-by: Shaohua Li &lt;shli@fb.com&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
[bwh: Backported to 3.16: Drop changes to ata_qc_{new_init,free}(); we don't
 actually have the tag allocation bug]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>libata: Align ata_device's id on a cacheline</title>
<updated>2016-03-24T10:00:54+00:00</updated>
<author>
<name>Harvey Hunt</name>
<email>harvey.hunt@imgtec.com</email>
</author>
<published>2016-02-24T15:16:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=740b87f7f34c4731301ae7e953a9f8c6a797e3c2'/>
<id>urn:sha1:740b87f7f34c4731301ae7e953a9f8c6a797e3c2</id>
<content type='text'>
commit 4ee34ea3a12396f35b26d90a094c75db95080baa upstream.

The id buffer in ata_device is a DMA target, but it isn't explicitly
cacheline aligned. Due to this, adjacent fields can be overwritten with
stale data from memory on non coherent architectures. As a result, the
kernel is sometimes unable to communicate with an ATA device.

Fix this by ensuring that the id buffer is cacheline aligned.

This issue is similar to that fixed by Commit 84bda12af31f
("libata: align ap-&gt;sector_buf").

Signed-off-by: Harvey Hunt &lt;harvey.hunt@imgtec.com&gt;
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
</entry>
<entry>
<title>libata: add ATA_HORKAGE_NOTRIM</title>
<updated>2015-08-11T08:57:31+00:00</updated>
<author>
<name>Arne Fitzenreiter</name>
<email>arne_f@ipfire.org</email>
</author>
<published>2015-07-15T11:54:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=17702a9ba8c13611c6c94d23401183cbcfd06b26'/>
<id>urn:sha1:17702a9ba8c13611c6c94d23401183cbcfd06b26</id>
<content type='text'>
commit 71d126fd28de2d4d9b7b2088dbccd7ca62fad6e0 upstream.

Some devices lose data on TRIM whether queued or not.  This patch adds
a horkage to disable TRIM.

tj: Collapsed unnecessary if() nesting.

Signed-off-by: Arne Fitzenreiter &lt;arne_f@ipfire.org&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
[ luis: backported to 3.16:
  - dropped changes to show_ata_dev_trim
  - adjusted context ]
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
</entry>
<entry>
<title>libata: Ignore spurious PHY event on LPM policy change</title>
<updated>2015-05-28T08:59:58+00:00</updated>
<author>
<name>Gabriele Mazzotta</name>
<email>gabriele.mzt@gmail.com</email>
</author>
<published>2015-04-25T17:52:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=578267ded59cebc351e9b7920f0e6e4cc18ee42b'/>
<id>urn:sha1:578267ded59cebc351e9b7920f0e6e4cc18ee42b</id>
<content type='text'>
commit 09c5b4803a80a5451d950d6a539d2eb311dc0fb1 upstream.

When the LPM policy is set to ATA_LPM_MAX_POWER, the device might
generate a spurious PHY event that cuases errors on the link.
Ignore this event if it occured within 10s after the policy change.

The timeout was chosen observing that on a Dell XPS13 9333 these
spurious events can occur up to roughly 6s after the policy change.

Link: http://lkml.kernel.org/g/3352987.ugV1Ipy7Z5@xps13
Signed-off-by: Gabriele Mazzotta &lt;gabriele.mzt@gmail.com&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
</entry>
<entry>
<title>libata: Add helper to determine when PHY events should be ignored</title>
<updated>2015-05-28T08:59:57+00:00</updated>
<author>
<name>Gabriele Mazzotta</name>
<email>gabriele.mzt@gmail.com</email>
</author>
<published>2015-04-25T17:52:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9a47bdd057fa2c1c677d0208ce5c693be4169084'/>
<id>urn:sha1:9a47bdd057fa2c1c677d0208ce5c693be4169084</id>
<content type='text'>
commit 8393b811f38acdf7fd8da2028708edad3e68ce1f upstream.

This is a preparation commit that will allow to add other criteria
according to which PHY events should be dropped.

Signed-off-by: Gabriele Mazzotta &lt;gabriele.mzt@gmail.com&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
</entry>
<entry>
<title>libata: allow sata_sil24 to opt-out of tag ordered submission</title>
<updated>2015-02-04T10:57:34+00:00</updated>
<author>
<name>Dan Williams</name>
<email>dan.j.williams@intel.com</email>
</author>
<published>2015-01-16T23:13:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8758523813c3229e7e7f2e96681ffb6d68b39e76'/>
<id>urn:sha1:8758523813c3229e7e7f2e96681ffb6d68b39e76</id>
<content type='text'>
commit 72dd299d5039a336493993dcc63413cf31d0e662 upstream.

Ronny reports: https://bugzilla.kernel.org/show_bug.cgi?id=87101
    "Since commit 8a4aeec8d "libata/ahci: accommodate tag ordered
    controllers" the access to the harddisk on the first SATA-port is
    failing on its first access. The access to the harddisk on the
    second port is working normal.

    When reverting the above commit, access to both harddisks is working
    fine again."

Maintain tag ordered submission as the default, but allow sata_sil24 to
continue with the old behavior.

Cc: Tejun Heo &lt;tj@kernel.org&gt;
Reported-by: Ronny Hegewald &lt;Ronny.Hegewald@online.de&gt;
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
</entry>
<entry>
<title>libata: introduce ata_host-&gt;n_tags to avoid oops on SAS controllers</title>
<updated>2014-07-23T14:30:34+00:00</updated>
<author>
<name>Tejun Heo</name>
<email>tj@kernel.org</email>
</author>
<published>2014-07-23T13:05:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1a112d10f03e83fb3a2fdc4c9165865dec8a3ca6'/>
<id>urn:sha1:1a112d10f03e83fb3a2fdc4c9165865dec8a3ca6</id>
<content type='text'>
1871ee134b73 ("libata: support the ata host which implements a queue
depth less than 32") directly used ata_port-&gt;scsi_host-&gt;can_queue from
ata_qc_new() to determine the number of tags supported by the host;
unfortunately, SAS controllers doing SATA don't initialize -&gt;scsi_host
leading to the following oops.

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
 IP: [&lt;ffffffff814e0618&gt;] ata_qc_new_init+0x188/0x1b0
 PGD 0
 Oops: 0002 [#1] SMP
 Modules linked in: isci libsas scsi_transport_sas mgag200 drm_kms_helper ttm
 CPU: 1 PID: 518 Comm: udevd Not tainted 3.16.0-rc6+ #62
 Hardware name: Intel Corporation S2600CO/S2600CO, BIOS SE5C600.86B.02.02.0002.122320131210 12/23/2013
 task: ffff880c1a00b280 ti: ffff88061a000000 task.ti: ffff88061a000000
 RIP: 0010:[&lt;ffffffff814e0618&gt;]  [&lt;ffffffff814e0618&gt;] ata_qc_new_init+0x188/0x1b0
 RSP: 0018:ffff88061a003ae8  EFLAGS: 00010012
 RAX: 0000000000000001 RBX: ffff88000241ca80 RCX: 00000000000000fa
 RDX: 0000000000000020 RSI: 0000000000000020 RDI: ffff8806194aa298
 RBP: ffff88061a003ae8 R08: ffff8806194a8000 R09: 0000000000000000
 R10: 0000000000000000 R11: ffff88000241ca80 R12: ffff88061ad58200
 R13: ffff8806194aa298 R14: ffffffff814e67a0 R15: ffff8806194a8000
 FS:  00007f3ad7fe3840(0000) GS:ffff880627620000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000058 CR3: 000000061a118000 CR4: 00000000001407e0
 Stack:
  ffff88061a003b20 ffffffff814e96e1 ffff88000241ca80 ffff88061ad58200
  ffff8800b6bf6000 ffff880c1c988000 ffff880619903850 ffff88061a003b68
  ffffffffa0056ce1 ffff88061a003b48 0000000013d6e6f8 ffff88000241ca80
 Call Trace:
  [&lt;ffffffff814e96e1&gt;] ata_sas_queuecmd+0xa1/0x430
  [&lt;ffffffffa0056ce1&gt;] sas_queuecommand+0x191/0x220 [libsas]
  [&lt;ffffffff8149afee&gt;] scsi_dispatch_cmd+0x10e/0x300
  [&lt;ffffffff814a3bc5&gt;] scsi_request_fn+0x2f5/0x550
  [&lt;ffffffff81317613&gt;] __blk_run_queue+0x33/0x40
  [&lt;ffffffff8131781a&gt;] queue_unplugged+0x2a/0x90
  [&lt;ffffffff8131ceb4&gt;] blk_flush_plug_list+0x1b4/0x210
  [&lt;ffffffff8131d274&gt;] blk_finish_plug+0x14/0x50
  [&lt;ffffffff8117eaa8&gt;] __do_page_cache_readahead+0x198/0x1f0
  [&lt;ffffffff8117ee21&gt;] force_page_cache_readahead+0x31/0x50
  [&lt;ffffffff8117ee7e&gt;] page_cache_sync_readahead+0x3e/0x50
  [&lt;ffffffff81172ac6&gt;] generic_file_read_iter+0x496/0x5a0
  [&lt;ffffffff81219897&gt;] blkdev_read_iter+0x37/0x40
  [&lt;ffffffff811e307e&gt;] new_sync_read+0x7e/0xb0
  [&lt;ffffffff811e3734&gt;] vfs_read+0x94/0x170
  [&lt;ffffffff811e43c6&gt;] SyS_read+0x46/0xb0
  [&lt;ffffffff811e33d1&gt;] ? SyS_lseek+0x91/0xb0
  [&lt;ffffffff8171ee29&gt;] system_call_fastpath+0x16/0x1b
 Code: 00 00 00 88 50 29 83 7f 08 01 19 d2 83 e2 f0 83 ea 50 88 50 34 c6 81 1d 02 00 00 40 c6 81 17 02 00 00 00 5d c3 66 0f 1f 44 00 00 &lt;89&gt; 14 25 58 00 00 00

Fix it by introducing ata_host-&gt;n_tags which is initialized to
ATA_MAX_QUEUE - 1 in ata_host_init() for SAS controllers and set to
scsi_host_template-&gt;can_queue in ata_host_register() for !SAS ones.
As SAS hosts are never registered, this will give them the same
ATA_MAX_QUEUE - 1 as before.  Note that we can't use
scsi_host-&gt;can_queue directly for SAS hosts anyway as they can go
higher than the libata maximum.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Reported-by: Mike Qiu &lt;qiudayu@linux.vnet.ibm.com&gt;
Reported-by: Jesse Brandeburg &lt;jesse.brandeburg@gmail.com&gt;
Reported-by: Peter Hurley &lt;peter@hurleysoftware.com&gt;
Reported-by: Peter Zijlstra &lt;peterz@infradead.org&gt;
Tested-by: Alexey Kardashevskiy &lt;aik@ozlabs.ru&gt;
Fixes: 1871ee134b73 ("libata: support the ata host which implements a queue depth less than 32")
Cc: Kevin Hao &lt;haokexin@gmail.com&gt;
Cc: Dan Williams &lt;dan.j.williams@intel.com&gt;
Cc: stable@vger.kernel.org
</content>
</entry>
<entry>
<title>libata/ahci: accommodate tag ordered controllers</title>
<updated>2014-04-18T19:56:03+00:00</updated>
<author>
<name>Dan Williams</name>
<email>dan.j.williams@intel.com</email>
</author>
<published>2014-04-17T18:48:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8a4aeec8d2d6a3edeffbdfae451cdf05cbf0fefd'/>
<id>urn:sha1:8a4aeec8d2d6a3edeffbdfae451cdf05cbf0fefd</id>
<content type='text'>
The AHCI spec allows implementations to issue commands in tag order
rather than FIFO order:

	5.3.2.12 P:SelectCmd
	HBA sets pSlotLoc = (pSlotLoc + 1) mod (CAP.NCS + 1)
	or HBA selects the command to issue that has had the
	PxCI bit set to '1' longer than any other command
	pending to be issued.

The result is that commands posted sequentially (time-wise) may play out
of sequence when issued by hardware.

This behavior has likely been hidden by drives that arrange for commands
to complete in issue order.  However, it appears recent drives (two from
different vendors that we have found so far) inflict out-of-order
completions as a matter of course.  So, we need to take care to maintain
ordered submission, otherwise we risk triggering a drive to fall out of
sequential-io automation and back to random-io processing, which incurs
large latency and degrades throughput.

This issue was found in simple benchmarks where QD=2 seq-write
performance was 30-50% *greater* than QD=32 seq-write performance.

Tagging for -stable and making the change globally since it has a low
risk-to-reward ratio.  Also, word is that recent versions of an unnamed
OS also does it this way now.  So, drives in the field are already
experienced with this tag ordering scheme.

Cc: &lt;stable@vger.kernel.org&gt;
Cc: Dave Jiang &lt;dave.jiang@intel.com&gt;
Cc: Ed Ciechanowski &lt;ed.ciechanowski@intel.com&gt;
Reviewed-by: Matthew Wilcox &lt;matthew.r.wilcox@intel.com&gt;
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
</content>
</entry>
<entry>
<title>libata: remove unused ata_sas_port_async_resume() stub</title>
<updated>2014-03-19T20:30:23+00:00</updated>
<author>
<name>Dan Williams</name>
<email>dan.j.williams@intel.com</email>
</author>
<published>2014-03-19T18:14:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0dd5d6f0e8763ff09939adf3e5b1465a3a414fea'/>
<id>urn:sha1:0dd5d6f0e8763ff09939adf3e5b1465a3a414fea</id>
<content type='text'>
Commit bc6e7c4b0d1a "libata, libsas: kill pm_result and related cleanup"
renamed ata_sas_port_async_resume() to ata_sas_port_resume(), but missed
a CONFIG_PM=n stub conversion.  Randy fixed that up in commit
a5a6569959fc "libata.h: add stub for ata_sas_port_resume", but missed
the deletion of the now unused ata_sas_port_async_resume() routine.

Cc: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
</content>
</entry>
</feed>
