<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/firewire/ohci.c, branch linux-3.12.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>firewire: ohci: fix JMicron JMB38x IT context discovery</title>
<updated>2016-01-05T16:48:50+00:00</updated>
<author>
<name>Stefan Richter</name>
<email>stefanr@s5r6.in-berlin.de</email>
</author>
<published>2015-11-03T00:46:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e0d495e250349701d7d3a7c91f84604d775e5923'/>
<id>e0d495e250349701d7d3a7c91f84604d775e5923</id>
<content type='text'>
commit 100ceb66d5c40cc0c7018e06a9474302470be73c upstream.

Reported by Clifford and Craig for JMicron OHCI-1394 + SDHCI combo
controllers:  Often or even most of the time, the controller is
initialized with the message "added OHCI v1.10 device as card 0, 4 IR +
0 IT contexts, quirks 0x10".  With 0 isochronous transmit DMA contexts
(IT contexts), applications like audio output are impossible.

However, OHCI-1394 demands that at least 4 IT contexts are implemented
by the link layer controller, and indeed JMicron JMB38x do implement
four of them.  Only their IsoXmitIntMask register is unreliable at early
access.

With my own JMB381 single function controller I found:
  - I can reproduce the problem with a lower probability than Craig's.
  - If I put a loop around the section which clears and reads
    IsoXmitIntMask, then either the first or the second attempt will
    return the correct initial mask of 0x0000000f.  I never encountered
    a case of needing more than a second attempt.
  - Consequently, if I put a dummy reg_read(...IsoXmitIntMaskSet)
    before the first write, the subsequent read will return the correct
    result.
  - If I merely ignore a wrong read result and force the known real
    result, later isochronous transmit DMA usage works just fine.

So let's just fix this chip bug up by the latter method.  Tested with
JMB381 on kernel 3.13 and 4.3.

Since OHCI-1394 generally requires 4 IT contexts at a minium, this
workaround is simply applied whenever the initial read of IsoXmitIntMask
returns 0, regardless whether it's a JMicron chip or not.  I never heard
of this issue together with any other chip though.

I am not 100% sure that this fix works on the OHCI-1394 part of JMB380
and JMB388 combo controllers exactly the same as on the JMB381 single-
function controller, but so far I haven't had a chance to let an owner
of a combo chip run a patched kernel.

Strangely enough, IsoRecvIntMask is always reported correctly, even
though it is probed right before IsoXmitIntMask.

Reported-by: Clifford Dunn
Reported-by: Craig Moore &lt;craig.moore@qenos.com&gt;
Signed-off-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 100ceb66d5c40cc0c7018e06a9474302470be73c upstream.

Reported by Clifford and Craig for JMicron OHCI-1394 + SDHCI combo
controllers:  Often or even most of the time, the controller is
initialized with the message "added OHCI v1.10 device as card 0, 4 IR +
0 IT contexts, quirks 0x10".  With 0 isochronous transmit DMA contexts
(IT contexts), applications like audio output are impossible.

However, OHCI-1394 demands that at least 4 IT contexts are implemented
by the link layer controller, and indeed JMicron JMB38x do implement
four of them.  Only their IsoXmitIntMask register is unreliable at early
access.

With my own JMB381 single function controller I found:
  - I can reproduce the problem with a lower probability than Craig's.
  - If I put a loop around the section which clears and reads
    IsoXmitIntMask, then either the first or the second attempt will
    return the correct initial mask of 0x0000000f.  I never encountered
    a case of needing more than a second attempt.
  - Consequently, if I put a dummy reg_read(...IsoXmitIntMaskSet)
    before the first write, the subsequent read will return the correct
    result.
  - If I merely ignore a wrong read result and force the known real
    result, later isochronous transmit DMA usage works just fine.

So let's just fix this chip bug up by the latter method.  Tested with
JMB381 on kernel 3.13 and 4.3.

Since OHCI-1394 generally requires 4 IT contexts at a minium, this
workaround is simply applied whenever the initial read of IsoXmitIntMask
returns 0, regardless whether it's a JMicron chip or not.  I never heard
of this issue together with any other chip though.

I am not 100% sure that this fix works on the OHCI-1394 part of JMB380
and JMB388 combo controllers exactly the same as on the JMB381 single-
function controller, but so far I haven't had a chance to let an owner
of a combo chip run a patched kernel.

Strangely enough, IsoRecvIntMask is always reported correctly, even
though it is probed right before IsoXmitIntMask.

Reported-by: Clifford Dunn
Reported-by: Craig Moore &lt;craig.moore@qenos.com&gt;
Signed-off-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>firewire: ohci: fix probe failure with Agere/LSI controllers</title>
<updated>2014-03-22T21:01:56+00:00</updated>
<author>
<name>Stefan Richter</name>
<email>stefanr@s5r6.in-berlin.de</email>
</author>
<published>2014-03-06T19:39:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b51610cdf9dc5b4e0cc09d7f239afc2d44ffd419'/>
<id>b51610cdf9dc5b4e0cc09d7f239afc2d44ffd419</id>
<content type='text'>
commit 0ca49345b6f489e95f8d6edeb0b092e257475b2a upstream.

Since commit bd972688eb24
"firewire: ohci: Fix 'failed to read phy reg' on FW643 rev8",
there is a high chance that firewire-ohci fails to initialize LSI née
Agere controllers.
https://bugzilla.kernel.org/show_bug.cgi?id=65151

Peter Hurley points out the reason:  IEEE 1394a:2000 clause 5A.1 (or
IEEE 1394:2008 clause 17.2.1) say:  "The PHY shall insure that no more
than 10 ms elapse from the reassertion of LPS until the interface is
reset.  The link shall not assert LReq until the reset is complete."
In other words, the link needs to give the PHY at least 10 ms to get
the interface operational.

With just the msleep(1) in bd972688eb24, the first read_phy_reg()
during ohci_enable() may happen before the phy-link interface reset was
finished, and fail.  Due to the high variability of msleep(n) with small
n, this failure was not fully reproducible, and not apparent at all with
low CONFIG_HZ setting.

On the other hand, Peter can no longer reproduce the issue with FW643
rev8.  The read phy reg failures that happened back then may have had an
unrelated cause.  So, just revert bd972688eb24, except for the valid
comment on TSB82AA2 cards.

Reported-by: Mikhail Gavrilov
Reported-by: Jay Fenlason &lt;fenlason@redhat.com&gt;
Reported-by: Clemens Ladisch &lt;clemens@ladisch.de&gt;
Reported-by: Peter Hurley &lt;peter@hurleysoftware.com&gt;
Signed-off-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 0ca49345b6f489e95f8d6edeb0b092e257475b2a upstream.

Since commit bd972688eb24
"firewire: ohci: Fix 'failed to read phy reg' on FW643 rev8",
there is a high chance that firewire-ohci fails to initialize LSI née
Agere controllers.
https://bugzilla.kernel.org/show_bug.cgi?id=65151

Peter Hurley points out the reason:  IEEE 1394a:2000 clause 5A.1 (or
IEEE 1394:2008 clause 17.2.1) say:  "The PHY shall insure that no more
than 10 ms elapse from the reassertion of LPS until the interface is
reset.  The link shall not assert LReq until the reset is complete."
In other words, the link needs to give the PHY at least 10 ms to get
the interface operational.

With just the msleep(1) in bd972688eb24, the first read_phy_reg()
during ohci_enable() may happen before the phy-link interface reset was
finished, and fail.  Due to the high variability of msleep(n) with small
n, this failure was not fully reproducible, and not apparent at all with
low CONFIG_HZ setting.

On the other hand, Peter can no longer reproduce the issue with FW643
rev8.  The read phy reg failures that happened back then may have had an
unrelated cause.  So, just revert bd972688eb24, except for the valid
comment on TSB82AA2 cards.

Reported-by: Mikhail Gavrilov
Reported-by: Jay Fenlason &lt;fenlason@redhat.com&gt;
Reported-by: Clemens Ladisch &lt;clemens@ladisch.de&gt;
Reported-by: Peter Hurley &lt;peter@hurleysoftware.com&gt;
Signed-off-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>firewire: ohci: Fix deadlock at bus reset</title>
<updated>2013-08-29T20:35:05+00:00</updated>
<author>
<name>Stephan Gatzka</name>
<email>stephan.gatzka@gmail.com</email>
</author>
<published>2013-08-26T18:50:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=db9ae8fec7b19f0ac6c60d998cac968d801a998d'/>
<id>db9ae8fec7b19f0ac6c60d998cac968d801a998d</id>
<content type='text'>
Put bus_reset_work into its own workqueue.  By doing this, forward
progress of bus_reset_work() is guaranteed if the work is switched over
to a rescuer thread.

Switching work to a rescuer thread happens if a new worker thread could
not be allocated in certain time (MAYDAY_INITIAL_TIMEOUT, typically 10
ms).  This might not be possible under high memory pressure or even on a
heavily loaded embedded system running a slow serial console.

The former deadlock occured in the following situation:
The rescuer thread ran
fw_device_init-&gt;read_config_rom-&gt;read_rom-&gt;fw_run_transaction.
fw_run_transaction blocked waiting for the completion object.
This completion object would have been completed in bus_reset_work,
but this work was never executed in the rescuer thread due to its
strictly sequential behaviour.

[Stefan R.:  Removed WQ_NON_REENTRANT flag from allocation because
it is no longer needed in current kernels.  Add it back if you backport
to kernels older than 3.7, i.e. one which does not contain dbf2576e37da
"workqueue: make all workqueues non-reentrant".  Swapped order of
destroy_workqueue and pci_unregister_driver.]

Signed-off-by: Stephan Gatzka &lt;stephan.gatzka@gmail.com&gt;
Signed-off-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Put bus_reset_work into its own workqueue.  By doing this, forward
progress of bus_reset_work() is guaranteed if the work is switched over
to a rescuer thread.

Switching work to a rescuer thread happens if a new worker thread could
not be allocated in certain time (MAYDAY_INITIAL_TIMEOUT, typically 10
ms).  This might not be possible under high memory pressure or even on a
heavily loaded embedded system running a slow serial console.

The former deadlock occured in the following situation:
The rescuer thread ran
fw_device_init-&gt;read_config_rom-&gt;read_rom-&gt;fw_run_transaction.
fw_run_transaction blocked waiting for the completion object.
This completion object would have been completed in bus_reset_work,
but this work was never executed in the rescuer thread due to its
strictly sequential behaviour.

[Stefan R.:  Removed WQ_NON_REENTRANT flag from allocation because
it is no longer needed in current kernels.  Add it back if you backport
to kernels older than 3.7, i.e. one which does not contain dbf2576e37da
"workqueue: make all workqueues non-reentrant".  Swapped order of
destroy_workqueue and pci_unregister_driver.]

Signed-off-by: Stephan Gatzka &lt;stephan.gatzka@gmail.com&gt;
Signed-off-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>firewire: ohci: Change module_pci_driver to module_init/module_exit</title>
<updated>2013-08-29T20:30:54+00:00</updated>
<author>
<name>Stephan Gatzka</name>
<email>stephan.gatzka@gmail.com</email>
</author>
<published>2013-08-26T18:50:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7a723c6ed9e92bf91db5c65542c78106030afdbe'/>
<id>7a723c6ed9e92bf91db5c65542c78106030afdbe</id>
<content type='text'>
This is a prerequisite to allocate a per driver self_id workqueue.
This reverts the ohci.c part of patch
fe2af11c220c7bb3a67f7aec0594811e5c59e019.

Signed-off-by: Stephan Gatzka &lt;stephan.gatzka@gmail.com&gt;
Signed-off-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is a prerequisite to allocate a per driver self_id workqueue.
This reverts the ohci.c part of patch
fe2af11c220c7bb3a67f7aec0594811e5c59e019.

Signed-off-by: Stephan Gatzka &lt;stephan.gatzka@gmail.com&gt;
Signed-off-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>firewire: ohci: beautify some macro definitions</title>
<updated>2013-08-19T07:02:05+00:00</updated>
<author>
<name>Stefan Richter</name>
<email>stefanr@s5r6.in-berlin.de</email>
</author>
<published>2013-08-05T13:14:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0dbe15f88be5b2cdf4ca4145797861dfb0d583a5'/>
<id>0dbe15f88be5b2cdf4ca4145797861dfb0d583a5</id>
<content type='text'>
a) Sort device IDs by vendor -- device -- revision.

b) Write quirk flags in hexadecimal.  This affects the user-visible
output of "modinfo firewire-ohci".  Since more flags have been added
recently, it is now easier to cope with them in hexadecimal represen-
tation.  Besides, the device-specific combination of quirk flags is
shown in hexadecimal in the kernel log too.  (And firewire-sbp2
presents its own quirk flags in modinfo as hexadecimals as well.)

Signed-off-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
a) Sort device IDs by vendor -- device -- revision.

b) Write quirk flags in hexadecimal.  This affects the user-visible
output of "modinfo firewire-ohci".  Since more flags have been added
recently, it is now easier to cope with them in hexadecimal represen-
tation.  Besides, the device-specific combination of quirk flags is
shown in hexadecimal in the kernel log too.  (And firewire-sbp2
presents its own quirk flags in modinfo as hexadecimals as well.)

Signed-off-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>firewire: ohci: change confusing name of a struct member</title>
<updated>2013-08-19T07:02:05+00:00</updated>
<author>
<name>Stefan Richter</name>
<email>stefanr@s5r6.in-berlin.de</email>
</author>
<published>2013-08-05T13:10:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=af53122a2a6239ef235e55cedc324499e31dad87'/>
<id>af53122a2a6239ef235e55cedc324499e31dad87</id>
<content type='text'>
We have got

	struct descriptor *descriptors;
	dma_addr_t         descriptors_bus;

	dma_addr_t         buffer_bus;
	struct descriptor buffer[0];

	void      *misc_buffer;
	dma_addr_t misc_buffer_bus;

	__be32    *config_rom;
	dma_addr_t config_rom_bus;
	__be32    *next_config_rom;
	dma_addr_t next_config_rom_bus;

But then we have got

	__le32    *self_id_cpu;
	dma_addr_t self_id_bus;

Better apply the pattern of xyz vs. xyz_bus to self_id vs. self_id_bus
as well.  The _cpu suffix looks particularly weird in conversions from
little endian to CPU endian.

Signed-off-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We have got

	struct descriptor *descriptors;
	dma_addr_t         descriptors_bus;

	dma_addr_t         buffer_bus;
	struct descriptor buffer[0];

	void      *misc_buffer;
	dma_addr_t misc_buffer_bus;

	__be32    *config_rom;
	dma_addr_t config_rom_bus;
	__be32    *next_config_rom;
	dma_addr_t next_config_rom_bus;

But then we have got

	__le32    *self_id_cpu;
	dma_addr_t self_id_bus;

Better apply the pattern of xyz vs. xyz_bus to self_id vs. self_id_bus
as well.  The _cpu suffix looks particularly weird in conversions from
little endian to CPU endian.

Signed-off-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>firewire: fix libdc1394/FlyCap2 iso event regression</title>
<updated>2013-07-27T18:24:36+00:00</updated>
<author>
<name>Clemens Ladisch</name>
<email>clemens@ladisch.de</email>
</author>
<published>2013-07-22T19:32:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0699a73af3811b66b1ab5650575acee5eea841ab'/>
<id>0699a73af3811b66b1ab5650575acee5eea841ab</id>
<content type='text'>
Commit 18d627113b83 (firewire: prevent dropping of completed iso packet
header data) was intended to be an obvious bug fix, but libdc1394 and
FlyCap2 depend on the old behaviour by ignoring all returned information
and thus not noticing that not all packets have been received yet.  The
result was that the video frame buffers would be saved before they
contained the correct data.

Reintroduce the old behaviour for old clients.

Tested-by: Stepan Salenikovich &lt;stepan.salenikovich@gmail.com&gt;
Tested-by: Josep Bosch &lt;jep250@gmail.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 3.4+
Signed-off-by: Clemens Ladisch &lt;clemens@ladisch.de&gt;
Signed-off-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit 18d627113b83 (firewire: prevent dropping of completed iso packet
header data) was intended to be an obvious bug fix, but libdc1394 and
FlyCap2 depend on the old behaviour by ignoring all returned information
and thus not noticing that not all packets have been received yet.  The
result was that the video frame buffers would be saved before they
contained the correct data.

Reintroduce the old behaviour for old clients.

Tested-by: Stepan Salenikovich &lt;stepan.salenikovich@gmail.com&gt;
Tested-by: Josep Bosch &lt;jep250@gmail.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 3.4+
Signed-off-by: Clemens Ladisch &lt;clemens@ladisch.de&gt;
Signed-off-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>firewire: ohci: dump_stack() for PHY regs read/write failures</title>
<updated>2013-04-30T18:30:16+00:00</updated>
<author>
<name>Peter Hurley</name>
<email>peter@hurleysoftware.com</email>
</author>
<published>2013-03-27T10:57:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6fe9efb9c9fbce690018c31e652924ae28019868'/>
<id>6fe9efb9c9fbce690018c31e652924ae28019868</id>
<content type='text'>
A stack trace is an invaluable tool in determining the basis
and cause of PHY regs read/write failures.

Include PHY reg addr (and value for writes) in the diagnostic.

[Stefan R:  changed whitespace]

Signed-off-by: Peter Hurley &lt;peter@hurleysoftware.com&gt;
Signed-off-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A stack trace is an invaluable tool in determining the basis
and cause of PHY regs read/write failures.

Include PHY reg addr (and value for writes) in the diagnostic.

[Stefan R:  changed whitespace]

Signed-off-by: Peter Hurley &lt;peter@hurleysoftware.com&gt;
Signed-off-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>firewire: ohci: Improve bus reset error messages</title>
<updated>2013-04-30T18:30:16+00:00</updated>
<author>
<name>Peter Hurley</name>
<email>peter@hurleysoftware.com</email>
</author>
<published>2013-03-27T10:56:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=67672134aaafd520a61dda448a662336e8fde236'/>
<id>67672134aaafd520a61dda448a662336e8fde236</id>
<content type='text'>
Many of the error messages possible from bus_reset_work() do not
contain enough information to distinguish which error condition
occurred nor enough information to evaluate the error afterwards.

Differentiate all error conditions in bus_reset_work(); add
additional information to make error diagnosis possible.

[Stefan R:  fixed self-ID endian conversion]

Signed-off-by: Peter Hurley &lt;peter@hurleysoftware.com&gt;
Signed-off-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Many of the error messages possible from bus_reset_work() do not
contain enough information to distinguish which error condition
occurred nor enough information to evaluate the error afterwards.

Differentiate all error conditions in bus_reset_work(); add
additional information to make error diagnosis possible.

[Stefan R:  fixed self-ID endian conversion]

Signed-off-by: Peter Hurley &lt;peter@hurleysoftware.com&gt;
Signed-off-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>firewire: ohci: Alias dev_* log functions</title>
<updated>2013-04-30T18:30:16+00:00</updated>
<author>
<name>Peter Hurley</name>
<email>peter@hurleysoftware.com</email>
</author>
<published>2013-03-26T15:54:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=de97cb64a959fe5ccf828b02d3a78de9f9defb67'/>
<id>de97cb64a959fe5ccf828b02d3a78de9f9defb67</id>
<content type='text'>
Convert dev_xxxx(ohci-&gt;card.device, ...) log functions to
ohci_xxxx(ohci, ...).

[Stefan R:  Peter argues that this increases readability of the code.]
[Stefan R:  changed whitespace]

Signed-off-by: Peter Hurley &lt;peter@hurleysoftware.com&gt;
Signed-off-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Convert dev_xxxx(ohci-&gt;card.device, ...) log functions to
ohci_xxxx(ohci, ...).

[Stefan R:  Peter argues that this increases readability of the code.]
[Stefan R:  changed whitespace]

Signed-off-by: Peter Hurley &lt;peter@hurleysoftware.com&gt;
Signed-off-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt;
</pre>
</div>
</content>
</entry>
</feed>
