2007-05-07 20:33:32 -04:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2007-05-07 20:33:32 -04:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-07 14:13:14 +02:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
firewire: reorganize header files
The three header files of firewire-core, i.e.
"drivers/firewire/fw-device.h",
"drivers/firewire/fw-topology.h",
"drivers/firewire/fw-transaction.h",
are replaced by
"drivers/firewire/core.h",
"include/linux/firewire.h".
The latter includes everything which a firewire high-level driver (like
firewire-sbp2) needs besides linux/firewire-constants.h, while core.h
contains the rest which is needed by firewire-core itself and by low-
level drivers (card drivers) like firewire-ohci.
High-level drivers can now also reside outside of drivers/firewire
without having to add drivers/firewire to the header file search path in
makefiles. At least the firedtv driver will be such a driver.
I also considered to spread the contents of core.h over several files,
one for each .c file where the respective implementation resides. But
it turned out that most core .c files will end up including most of the
core .h files. Also, the combined core.h isn't unreasonably big, and it
will lose more of its contents to linux/firewire.h anyway soon when more
firewire drivers are added. (IP-over-1394, firedtv, and there are plans
for one or two more.)
Furthermore, fw-ohci.h is renamed to ohci.h. The name of core.h and
ohci.h is chosen with regard to name changes of the .c files in a
follow-up change.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-06-05 16:26:18 +02:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2010-02-20 22:24:43 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2008-10-05 10:37:11 +02:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2010-07-29 09:31:56 +02:00
|
|
|
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 17:04:11 +09:00
|
|
|
|
2008-10-03 11:19:09 -04:00
|
|
|
|
2010-01-24 16:45:03 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2009-06-06 18:36:24 +02:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2007-09-29 10:41:58 +02:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
firewire: reorganize header files
The three header files of firewire-core, i.e.
"drivers/firewire/fw-device.h",
"drivers/firewire/fw-topology.h",
"drivers/firewire/fw-transaction.h",
are replaced by
"drivers/firewire/core.h",
"include/linux/firewire.h".
The latter includes everything which a firewire high-level driver (like
firewire-sbp2) needs besides linux/firewire-constants.h, while core.h
contains the rest which is needed by firewire-core itself and by low-
level drivers (card drivers) like firewire-ohci.
High-level drivers can now also reside outside of drivers/firewire
without having to add drivers/firewire to the header file search path in
makefiles. At least the firedtv driver will be such a driver.
I also considered to spread the contents of core.h over several files,
one for each .c file where the respective implementation resides. But
it turned out that most core .c files will end up including most of the
core .h files. Also, the combined core.h isn't unreasonably big, and it
will lose more of its contents to linux/firewire.h anyway soon when more
firewire drivers are added. (IP-over-1394, firedtv, and there are plans
for one or two more.)
Furthermore, fw-ohci.h is renamed to ohci.h. The name of core.h and
ohci.h is chosen with regard to name changes of the .c files in a
follow-up change.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-06-05 16:26:18 +02:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2010-06-20 22:52:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-23 13:05:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-20 22:52:55 +02:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2007-03-07 12:12:43 -05:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
2011-01-10 17:28:39 +01:00
|
|
|
|
2007-03-27 01:43:39 -04:00
|
|
|
|
2007-02-16 17:34:38 -05:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2007-04-30 15:03:14 -04:00
|
|
|
|
2007-02-16 17:34:38 -05:00
|
|
|
|
|
|
|
|
|
2007-03-07 12:12:41 -05:00
|
|
|
|
2010-07-16 22:25:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-07 12:12:41 -05:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
firewire: cdev: fix responses to nodes at different card
My box has two firewire cards in it: card0 and card1.
My application opens /dev/fw0 (card 0) and allocates an address space.
The core makes the address space available on both cards.
Along comes the remote device, which sends a READ_QUADLET_REQUEST to
card1. The request gets passed up to my application, which calls
ioctl_send_response().
ioctl_send_response() then calls fw_send_response() with card0,
because that's the card it's bound to.
Card0's driver drops the response, because it isn't part of
a transaction that it has outstanding.
So in core-cdev: handle_request(), we need to stash the
card of the inbound request in the struct inbound_transaction_resource and
use that card to send the response to.
The hard part will be refcounting the card correctly
so it can't get deallocated while we hold a pointer to it.
Here's a trivial patch, which does not do the card refcounting, but at
least demonstrates what the problem is.
Note that we can't depend on the fact that the core-cdev:client
structure holds a card open, because in this case the card it holds
open is not the card the request came in on.
..and there's no way for the core to tell cdev "this card is gone,
kill any inbound transactions on it", while cdev holds the transaction
open until userspace issues a SEND_RESPONSE ioctl, which may be a very,
very long time. But when it does, it calls fw_send_response(), which
will dereference the card...
So how unhappy are we about userspace potentially holding a fw_card
open forever?
Signed-off-by: Jay Fenlason <fenlason@redhat.com>
Reference counting to be addressed in a separate change.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (whitespace)
2010-05-18 14:02:45 -04:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-20 13:23:59 +02:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-08 00:41:10 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
firewire: cdev: fix ABI for FCP and address range mapping, add fw_cdev_event_request2
The problem:
A target-like userspace driver, e.g. AV/C target or SBP-2/3 target,
needs to be able to act as responder and requester. In the latter role,
it needs to send requests to nods from which it received requests. This
is currently impossible because fw_cdev_event_request lacks information
about sender node ID.
Reported-by: Jay Fenlason <fenlason@redhat.com>
Libffado + libraw1394 + firewire-core is currently unable to drive two
or more audio devices on the same bus.
Reported-by: Arnold Krille <arnold@arnoldarts.de>
This is because libffado requires destination node ID of FCP requests
and sender node ID of FCP responses to match. It even prohibits
libffado from working with a bus on which libraw1394 opens a /dev/fw* as
default ioctl device that does not correspond with the audio device.
This is because libraw1394 does not receive the sender node ID from the
kernel.
Moreover, fw_cdev_event_request makes it impossible to tell unicast and
broadcast write requests apart.
The fix:
Add a replacement of struct fw_cdev_event_request request, boringly
called struct fw_cdev_event_request2. The new event will be sent to a
userspace client instead of the old one if the client claims
compatibility with <linux/firewire-cdev.h> ABI version 4 or later.
libraw1394 needs to be extended to make use of the new event, in order
to properly support libffado and other FCP or address range mapping
users who require correct sender node IDs.
Further notes:
While we are at it, change back the range of possible values of
fw_cdev_event_request.tcode to 0x0...0xb like in ABI version <= 3.
The preceding change "firewire: expose extended tcode of incoming lock
requests to (userspace) drivers" expanded it to 0x0...0x17 which could
catch sloppily coded clients by surprise. The extended range of codes
is only used in the new fw_cdev_event_request2.tcode.
Jay and I also suggested an alternative approach to fix the ABI for
incoming requests: Add an FW_CDEV_IOC_GET_REQUEST_INFO ioctl which can
be called after reception of an fw_cdev_event_request, before issuing of
the closing FW_CDEV_IOC_SEND_RESPONSE ioctl. The new ioctl would reveal
the vital information about a request that fw_cdev_event_request lacks.
Jay showed an implementation of this approach.
The former event approach adds 27 LOC of rather trivial code to
core-cdev.c, the ioctl approach 34 LOC, some of which is nontrivial.
The ioctl approach would certainly also add more LOC to userspace
programs which require the expanded information on inbound requests.
This approach is probably only on the lighter-weight side in case of
clients that want to be compatible with kernels that lack the new
capability, like libraw1394. However, the code to be added to such
libraw1394-like clients in case of the event approach is a straight-
forward additional switch () case in its event handler.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2010-06-20 22:53:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-29 18:19:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2009-10-08 00:41:38 +02:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2010-07-16 22:25:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-16 22:25:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-14 21:47:04 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-14 21:47:04 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-02 15:01:09 +01:00
|
|
|
|
2007-03-07 12:12:44 -05:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2008-05-16 11:15:23 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-09 19:23:14 -04:00
|
|
|
|
2008-02-02 15:01:09 +01:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2008-02-02 15:01:09 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2008-02-02 15:01:09 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2011-01-10 17:28:39 +01:00
|
|
|
|
2010-07-16 22:25:51 +02:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-05 10:37:11 +02:00
|
|
|
|
2007-03-07 12:12:41 -05:00
|
|
|
|
2008-10-05 10:37:11 +02:00
|
|
|
|
2007-03-07 12:12:41 -05:00
|
|
|
|
2010-04-10 16:38:05 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2007-10-08 17:00:29 -04:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
2008-12-14 21:47:04 +01:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-14 21:45:45 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2008-12-14 21:45:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2007-03-07 12:12:48 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2008-12-21 16:49:57 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-07 12:12:48 -05:00
|
|
|
|
2008-12-14 21:45:45 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2007-03-07 12:12:48 -05:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
2008-12-14 21:45:45 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-14 21:45:45 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
2008-12-14 21:47:04 +01:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-14 21:47:04 +01:00
|
|
|
|
|
|
|
|
|
2007-03-07 12:12:43 -05:00
|
|
|
|
2007-03-27 01:43:39 -04:00
|
|
|
|
2008-10-03 11:19:09 -04:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2007-03-07 12:12:43 -05:00
|
|
|
|
2007-03-27 01:43:39 -04:00
|
|
|
|
2007-03-07 12:12:43 -05:00
|
|
|
|
2008-01-24 01:53:51 +01:00
|
|
|
|
2007-03-27 01:43:39 -04:00
|
|
|
|
2007-03-07 12:12:43 -05:00
|
|
|
|
2010-06-21 23:24:35 +02:00
|
|
|
|
2007-03-07 12:12:43 -05:00
|
|
|
|
|
|
|
|
|
2008-10-03 11:19:09 -04:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2007-03-07 12:12:43 -05:00
|
|
|
|
|
|
|
|
|
2008-12-14 21:47:04 +01:00
|
|
|
|
|
|
|
|
|
2007-03-07 12:12:48 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-05 10:37:11 +02:00
|
|
|
|
2007-03-07 12:12:48 -05:00
|
|
|
|
|
|
|
|
|
2008-10-05 10:37:11 +02:00
|
|
|
|
2007-03-07 12:12:48 -05:00
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2009-10-08 00:41:10 +02:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-14 21:47:04 +01:00
|
|
|
|
2007-03-07 12:12:41 -05:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2007-03-07 12:12:41 -05:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2010-07-16 22:25:51 +02:00
|
|
|
|
2007-03-07 12:12:41 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2007-03-07 12:12:41 -05:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-07 12:12:41 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-07 12:12:48 -05:00
|
|
|
|
|
|
|
|
|
2007-03-07 12:12:41 -05:00
|
|
|
|
2007-03-07 12:12:48 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-07 12:12:41 -05:00
|
|
|
|
2007-03-07 12:12:48 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-07 12:12:41 -05:00
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-16 22:25:14 +02:00
|
|
|
|
2010-07-16 22:25:51 +02:00
|
|
|
|
2010-07-29 18:19:22 +02:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2007-03-07 12:12:43 -05:00
|
|
|
|
2008-03-24 20:54:28 +01:00
|
|
|
|
2007-03-07 12:12:43 -05:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2010-06-20 22:52:55 +02:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2007-03-07 12:12:43 -05:00
|
|
|
|
2008-03-24 20:54:28 +01:00
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
|
|
|
|
|
2007-03-20 19:42:15 +01:00
|
|
|
|
2007-03-07 12:12:43 -05:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
|
|
|
|
|
2007-03-07 12:12:43 -05:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2007-03-07 12:12:43 -05:00
|
|
|
|
2008-03-24 20:54:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
|
|
|
|
|
2007-03-27 01:43:39 -04:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
|
|
|
|
|
2007-03-07 12:12:43 -05:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-14 21:47:04 +01:00
|
|
|
|
|
|
|
|
|
2007-03-27 01:43:41 -04:00
|
|
|
|
|
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-27 01:43:41 -04:00
|
|
|
|
|
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2009-10-08 00:41:10 +02:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2007-03-27 01:43:41 -04:00
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-27 01:43:41 -04:00
|
|
|
|
|
|
|
|
|
2008-12-14 21:47:04 +01:00
|
|
|
|
|
|
|
|
|
2009-10-08 00:41:38 +02:00
|
|
|
|
2007-03-27 01:43:41 -04:00
|
|
|
|
2009-10-08 00:41:38 +02:00
|
|
|
|
2007-03-27 01:43:41 -04:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
2009-10-08 00:41:38 +02:00
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
2009-10-08 00:41:38 +02:00
|
|
|
|
|
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2007-03-27 01:43:41 -04:00
|
|
|
|
2009-10-08 00:41:38 +02:00
|
|
|
|
2007-03-27 01:43:41 -04:00
|
|
|
|
|
|
|
|
|
2009-10-08 00:41:38 +02:00
|
|
|
|
|
|
|
|
|
2007-03-27 01:43:41 -04:00
|
|
|
|
2009-10-08 00:41:38 +02:00
|
|
|
|
2007-03-27 01:43:41 -04:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2007-03-27 01:43:41 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-14 21:47:04 +01:00
|
|
|
|
|
|
|
|
|
2007-03-27 01:43:41 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-14 21:47:04 +01:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-07 12:12:50 -05:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2007-03-07 12:12:50 -05:00
|
|
|
|
2011-01-10 17:28:39 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-07 12:12:50 -05:00
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2008-07-29 23:46:25 -07:00
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2008-07-29 23:46:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-29 23:46:25 -07:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2008-07-29 23:46:25 -07:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2011-01-10 17:28:39 +01:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2008-12-05 22:44:42 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2009-03-10 21:02:21 +01:00
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2010-07-07 14:37:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2007-04-30 15:03:13 -04:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2007-04-30 15:03:13 -04:00
|
|
|
|
2008-12-05 22:44:42 +01:00
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
2008-12-05 22:44:42 +01:00
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
|
|
|
|
|
2007-03-07 12:12:50 -05:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2009-03-10 21:01:54 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2008-12-05 22:44:42 +01:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-24 16:45:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-14 21:47:04 +01:00
|
|
|
|
|
|
|
|
|
2007-03-27 01:43:41 -04:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2007-03-27 01:43:41 -04:00
|
|
|
|
2010-01-24 16:45:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
firewire: cdev: fix responses to nodes at different card
My box has two firewire cards in it: card0 and card1.
My application opens /dev/fw0 (card 0) and allocates an address space.
The core makes the address space available on both cards.
Along comes the remote device, which sends a READ_QUADLET_REQUEST to
card1. The request gets passed up to my application, which calls
ioctl_send_response().
ioctl_send_response() then calls fw_send_response() with card0,
because that's the card it's bound to.
Card0's driver drops the response, because it isn't part of
a transaction that it has outstanding.
So in core-cdev: handle_request(), we need to stash the
card of the inbound request in the struct inbound_transaction_resource and
use that card to send the response to.
The hard part will be refcounting the card correctly
so it can't get deallocated while we hold a pointer to it.
Here's a trivial patch, which does not do the card refcounting, but at
least demonstrates what the problem is.
Note that we can't depend on the fact that the core-cdev:client
structure holds a card open, because in this case the card it holds
open is not the card the request came in on.
..and there's no way for the core to tell cdev "this card is gone,
kill any inbound transactions on it", while cdev holds the transaction
open until userspace issues a SEND_RESPONSE ioctl, which may be a very,
very long time. But when it does, it calls fw_send_response(), which
will dereference the card...
So how unhappy are we about userspace potentially holding a fw_card
open forever?
Signed-off-by: Jay Fenlason <fenlason@redhat.com>
Reference counting to be addressed in a separate change.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (whitespace)
2010-05-18 14:02:45 -04:00
|
|
|
|
firewire: cdev: count references of cards during inbound transactions
If a request comes in to an address range managed by a userspace driver
i.e. <linux/firewire-cdev.h> client, the card instance of request and
response may differ from the card instance of the client device.
Therefore we need to take a reference of the card until the response was
sent.
I thought about putting the reference counting into core-transaction.c,
but the various high-level drivers besides cdev clients (firewire-net,
firewire-sbp2, firedtv) use the card pointer in their fw_address_handler
address_callback method only to look up devices of which they already
hold the necessary references. So this seems to be a specific
firewire-cdev issue which is better addressed locally.
We do not need the reference
- in case of FCP_REQUEST or FCP_RESPONSE requests because then the
firewire-core will send the split transaction response for us
already in the context of the request handler,
- if it is the same card as the client device's because we hold a
card reference indirectly via teh client->device reference.
To keep things simple, we take the reference nevertheless.
Jay Fenlason wrote:
> there's no way for the core to tell cdev "this card is gone,
> kill any inbound transactions on it", while cdev holds the transaction
> open until userspace issues a SEND_RESPONSE ioctl, which may be a very,
> very long time. But when it does, it calls fw_send_response(), which
> will dereference the card...
>
> So how unhappy are we about userspace potentially holding a fw_card
> open forever?
While termination of inbound transcations at card removal could be
implemented, it is IMO not worth the effort. Currently, the effect of
holding a reference of a card that has been removed is to block the
process that called the pci_remove of the card. This is
- either a user process ran by root. Root can find and kill processes
that have /dev/fw* open, if desired.
- a kernel thread (which one?) in case of hot removal of a PCCard or
ExpressCard.
The latter case could be a problem indeed. firewire-core's card
shutdown and card release should probably be improved not to block in
shutdown, just to defer freeing of memory until release.
This is not a new problem though; the same already always happens with
the client->device->card without the need of inbound transactions or
other special conditions involved, other than the client not closing the
file.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2010-06-20 22:52:27 +02:00
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2007-03-27 01:43:41 -04:00
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2008-12-14 21:47:04 +01:00
|
|
|
|
2010-06-20 22:50:35 +02:00
|
|
|
|
2008-12-14 21:47:04 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
firewire: cdev: fix ABI for FCP and address range mapping, add fw_cdev_event_request2
The problem:
A target-like userspace driver, e.g. AV/C target or SBP-2/3 target,
needs to be able to act as responder and requester. In the latter role,
it needs to send requests to nods from which it received requests. This
is currently impossible because fw_cdev_event_request lacks information
about sender node ID.
Reported-by: Jay Fenlason <fenlason@redhat.com>
Libffado + libraw1394 + firewire-core is currently unable to drive two
or more audio devices on the same bus.
Reported-by: Arnold Krille <arnold@arnoldarts.de>
This is because libffado requires destination node ID of FCP requests
and sender node ID of FCP responses to match. It even prohibits
libffado from working with a bus on which libraw1394 opens a /dev/fw* as
default ioctl device that does not correspond with the audio device.
This is because libraw1394 does not receive the sender node ID from the
kernel.
Moreover, fw_cdev_event_request makes it impossible to tell unicast and
broadcast write requests apart.
The fix:
Add a replacement of struct fw_cdev_event_request request, boringly
called struct fw_cdev_event_request2. The new event will be sent to a
userspace client instead of the old one if the client claims
compatibility with <linux/firewire-cdev.h> ABI version 4 or later.
libraw1394 needs to be extended to make use of the new event, in order
to properly support libffado and other FCP or address range mapping
users who require correct sender node IDs.
Further notes:
While we are at it, change back the range of possible values of
fw_cdev_event_request.tcode to 0x0...0xb like in ABI version <= 3.
The preceding change "firewire: expose extended tcode of incoming lock
requests to (userspace) drivers" expanded it to 0x0...0x17 which could
catch sloppily coded clients by surprise. The extended range of codes
is only used in the new fw_cdev_event_request2.tcode.
Jay and I also suggested an alternative approach to fix the ABI for
incoming requests: Add an FW_CDEV_IOC_GET_REQUEST_INFO ioctl which can
be called after reception of an fw_cdev_event_request, before issuing of
the closing FW_CDEV_IOC_SEND_RESPONSE ioctl. The new ioctl would reveal
the vital information about a request that fw_cdev_event_request lacks.
Jay showed an implementation of this approach.
The former event approach adds 27 LOC of rather trivial code to
core-cdev.c, the ioctl approach 34 LOC, some of which is nontrivial.
The ioctl approach would certainly also add more LOC to userspace
programs which require the expanded information on inbound requests.
This approach is probably only on the lighter-weight side in case of
clients that want to be compatible with kernels that lack the new
capability, like libraw1394. However, the code to be added to such
libraw1394-like clients in case of the event approach is a straight-
forward additional switch () case in its event handler.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2010-06-20 22:53:55 +02:00
|
|
|
|
2010-01-24 16:45:03 +01:00
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
firewire: cdev: count references of cards during inbound transactions
If a request comes in to an address range managed by a userspace driver
i.e. <linux/firewire-cdev.h> client, the card instance of request and
response may differ from the card instance of the client device.
Therefore we need to take a reference of the card until the response was
sent.
I thought about putting the reference counting into core-transaction.c,
but the various high-level drivers besides cdev clients (firewire-net,
firewire-sbp2, firedtv) use the card pointer in their fw_address_handler
address_callback method only to look up devices of which they already
hold the necessary references. So this seems to be a specific
firewire-cdev issue which is better addressed locally.
We do not need the reference
- in case of FCP_REQUEST or FCP_RESPONSE requests because then the
firewire-core will send the split transaction response for us
already in the context of the request handler,
- if it is the same card as the client device's because we hold a
card reference indirectly via teh client->device reference.
To keep things simple, we take the reference nevertheless.
Jay Fenlason wrote:
> there's no way for the core to tell cdev "this card is gone,
> kill any inbound transactions on it", while cdev holds the transaction
> open until userspace issues a SEND_RESPONSE ioctl, which may be a very,
> very long time. But when it does, it calls fw_send_response(), which
> will dereference the card...
>
> So how unhappy are we about userspace potentially holding a fw_card
> open forever?
While termination of inbound transcations at card removal could be
implemented, it is IMO not worth the effort. Currently, the effect of
holding a reference of a card that has been removed is to block the
process that called the pci_remove of the card. This is
- either a user process ran by root. Root can find and kill processes
that have /dev/fw* open, if desired.
- a kernel thread (which one?) in case of hot removal of a PCCard or
ExpressCard.
The latter case could be a problem indeed. firewire-core's card
shutdown and card release should probably be improved not to block in
shutdown, just to defer freeing of memory until release.
This is not a new problem though; the same already always happens with
the client->device->card without the need of inbound transactions or
other special conditions involved, other than the client not closing the
file.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2010-06-20 22:52:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2007-05-09 19:23:14 -04:00
|
|
|
|
2010-07-16 22:25:51 +02:00
|
|
|
|
|
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
2010-07-16 22:25:51 +02:00
|
|
|
|
firewire: cdev: fix responses to nodes at different card
My box has two firewire cards in it: card0 and card1.
My application opens /dev/fw0 (card 0) and allocates an address space.
The core makes the address space available on both cards.
Along comes the remote device, which sends a READ_QUADLET_REQUEST to
card1. The request gets passed up to my application, which calls
ioctl_send_response().
ioctl_send_response() then calls fw_send_response() with card0,
because that's the card it's bound to.
Card0's driver drops the response, because it isn't part of
a transaction that it has outstanding.
So in core-cdev: handle_request(), we need to stash the
card of the inbound request in the struct inbound_transaction_resource and
use that card to send the response to.
The hard part will be refcounting the card correctly
so it can't get deallocated while we hold a pointer to it.
Here's a trivial patch, which does not do the card refcounting, but at
least demonstrates what the problem is.
Note that we can't depend on the fact that the core-cdev:client
structure holds a card open, because in this case the card it holds
open is not the card the request came in on.
..and there's no way for the core to tell cdev "this card is gone,
kill any inbound transactions on it", while cdev holds the transaction
open until userspace issues a SEND_RESPONSE ioctl, which may be a very,
very long time. But when it does, it calls fw_send_response(), which
will dereference the card...
So how unhappy are we about userspace potentially holding a fw_card
open forever?
Signed-off-by: Jay Fenlason <fenlason@redhat.com>
Reference counting to be addressed in a separate change.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (whitespace)
2010-05-18 14:02:45 -04:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2010-01-24 16:45:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
firewire: cdev: fix ABI for FCP and address range mapping, add fw_cdev_event_request2
The problem:
A target-like userspace driver, e.g. AV/C target or SBP-2/3 target,
needs to be able to act as responder and requester. In the latter role,
it needs to send requests to nods from which it received requests. This
is currently impossible because fw_cdev_event_request lacks information
about sender node ID.
Reported-by: Jay Fenlason <fenlason@redhat.com>
Libffado + libraw1394 + firewire-core is currently unable to drive two
or more audio devices on the same bus.
Reported-by: Arnold Krille <arnold@arnoldarts.de>
This is because libffado requires destination node ID of FCP requests
and sender node ID of FCP responses to match. It even prohibits
libffado from working with a bus on which libraw1394 opens a /dev/fw* as
default ioctl device that does not correspond with the audio device.
This is because libraw1394 does not receive the sender node ID from the
kernel.
Moreover, fw_cdev_event_request makes it impossible to tell unicast and
broadcast write requests apart.
The fix:
Add a replacement of struct fw_cdev_event_request request, boringly
called struct fw_cdev_event_request2. The new event will be sent to a
userspace client instead of the old one if the client claims
compatibility with <linux/firewire-cdev.h> ABI version 4 or later.
libraw1394 needs to be extended to make use of the new event, in order
to properly support libffado and other FCP or address range mapping
users who require correct sender node IDs.
Further notes:
While we are at it, change back the range of possible values of
fw_cdev_event_request.tcode to 0x0...0xb like in ABI version <= 3.
The preceding change "firewire: expose extended tcode of incoming lock
requests to (userspace) drivers" expanded it to 0x0...0x17 which could
catch sloppily coded clients by surprise. The extended range of codes
is only used in the new fw_cdev_event_request2.tcode.
Jay and I also suggested an alternative approach to fix the ABI for
incoming requests: Add an FW_CDEV_IOC_GET_REQUEST_INFO ioctl which can
be called after reception of an fw_cdev_event_request, before issuing of
the closing FW_CDEV_IOC_SEND_RESPONSE ioctl. The new ioctl would reveal
the vital information about a request that fw_cdev_event_request lacks.
Jay showed an implementation of this approach.
The former event approach adds 27 LOC of rather trivial code to
core-cdev.c, the ioctl approach 34 LOC, some of which is nontrivial.
The ioctl approach would certainly also add more LOC to userspace
programs which require the expanded information on inbound requests.
This approach is probably only on the lighter-weight side in case of
clients that want to be compatible with kernels that lack the new
capability, like libraw1394. However, the code to be added to such
libraw1394-like clients in case of the event approach is a straight-
forward additional switch () case in its event handler.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2010-06-20 22:53:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
firewire: cdev: fix ABI for FCP and address range mapping, add fw_cdev_event_request2
The problem:
A target-like userspace driver, e.g. AV/C target or SBP-2/3 target,
needs to be able to act as responder and requester. In the latter role,
it needs to send requests to nods from which it received requests. This
is currently impossible because fw_cdev_event_request lacks information
about sender node ID.
Reported-by: Jay Fenlason <fenlason@redhat.com>
Libffado + libraw1394 + firewire-core is currently unable to drive two
or more audio devices on the same bus.
Reported-by: Arnold Krille <arnold@arnoldarts.de>
This is because libffado requires destination node ID of FCP requests
and sender node ID of FCP responses to match. It even prohibits
libffado from working with a bus on which libraw1394 opens a /dev/fw* as
default ioctl device that does not correspond with the audio device.
This is because libraw1394 does not receive the sender node ID from the
kernel.
Moreover, fw_cdev_event_request makes it impossible to tell unicast and
broadcast write requests apart.
The fix:
Add a replacement of struct fw_cdev_event_request request, boringly
called struct fw_cdev_event_request2. The new event will be sent to a
userspace client instead of the old one if the client claims
compatibility with <linux/firewire-cdev.h> ABI version 4 or later.
libraw1394 needs to be extended to make use of the new event, in order
to properly support libffado and other FCP or address range mapping
users who require correct sender node IDs.
Further notes:
While we are at it, change back the range of possible values of
fw_cdev_event_request.tcode to 0x0...0xb like in ABI version <= 3.
The preceding change "firewire: expose extended tcode of incoming lock
requests to (userspace) drivers" expanded it to 0x0...0x17 which could
catch sloppily coded clients by surprise. The extended range of codes
is only used in the new fw_cdev_event_request2.tcode.
Jay and I also suggested an alternative approach to fix the ABI for
incoming requests: Add an FW_CDEV_IOC_GET_REQUEST_INFO ioctl which can
be called after reception of an fw_cdev_event_request, before issuing of
the closing FW_CDEV_IOC_SEND_RESPONSE ioctl. The new ioctl would reveal
the vital information about a request that fw_cdev_event_request lacks.
Jay showed an implementation of this approach.
The former event approach adds 27 LOC of rather trivial code to
core-cdev.c, the ioctl approach 34 LOC, some of which is nontrivial.
The ioctl approach would certainly also add more LOC to userspace
programs which require the expanded information on inbound requests.
This approach is probably only on the lighter-weight side in case of
clients that want to be compatible with kernels that lack the new
capability, like libraw1394. However, the code to be added to such
libraw1394-like clients in case of the event approach is a straight-
forward additional switch () case in its event handler.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2010-06-20 22:53:55 +02:00
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
2010-01-24 16:45:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
firewire: fix use of multiple AV/C devices, allow multiple FCP listeners
Control of more than one AV/C device at once --- e.g. camcorders, tape
decks, audio devices, TV tuners --- failed or worked only unreliably,
depending on driver implementation. This affected kernelspace and
userspace drivers alike and was caused by firewire-core's inability to
accept multiple registrations of FCP listeners.
The fix allows multiple address handlers to be registered for the FCP
command and response registers. When a request for these registers is
received, all handlers are invoked, and the Firewire response is
generated by the core and not by any handler.
The cdev API does not change, i.e., userspace is still expected to send
a response for FCP requests; this response is silently ignored.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (changelog, rebased, whitespace)
2009-12-24 12:05:58 +01:00
|
|
|
|
firewire: cdev: count references of cards during inbound transactions
If a request comes in to an address range managed by a userspace driver
i.e. <linux/firewire-cdev.h> client, the card instance of request and
response may differ from the card instance of the client device.
Therefore we need to take a reference of the card until the response was
sent.
I thought about putting the reference counting into core-transaction.c,
but the various high-level drivers besides cdev clients (firewire-net,
firewire-sbp2, firedtv) use the card pointer in their fw_address_handler
address_callback method only to look up devices of which they already
hold the necessary references. So this seems to be a specific
firewire-cdev issue which is better addressed locally.
We do not need the reference
- in case of FCP_REQUEST or FCP_RESPONSE requests because then the
firewire-core will send the split transaction response for us
already in the context of the request handler,
- if it is the same card as the client device's because we hold a
card reference indirectly via teh client->device reference.
To keep things simple, we take the reference nevertheless.
Jay Fenlason wrote:
> there's no way for the core to tell cdev "this card is gone,
> kill any inbound transactions on it", while cdev holds the transaction
> open until userspace issues a SEND_RESPONSE ioctl, which may be a very,
> very long time. But when it does, it calls fw_send_response(), which
> will dereference the card...
>
> So how unhappy are we about userspace potentially holding a fw_card
> open forever?
While termination of inbound transcations at card removal could be
implemented, it is IMO not worth the effort. Currently, the effect of
holding a reference of a card that has been removed is to block the
process that called the pci_remove of the card. This is
- either a user process ran by root. Root can find and kill processes
that have /dev/fw* open, if desired.
- a kernel thread (which one?) in case of hot removal of a PCCard or
ExpressCard.
The latter case could be a problem indeed. firewire-core's card
shutdown and card release should probably be improved not to block in
shutdown, just to defer freeing of memory until release.
This is not a new problem though; the same already always happens with
the client->device->card without the need of inbound transactions or
other special conditions involved, other than the client not closing the
file.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2010-06-20 22:52:27 +02:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
2008-12-14 21:47:04 +01:00
|
|
|
|
|
|
|
|
|
2007-03-27 01:43:41 -04:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2007-03-27 01:43:41 -04:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2007-03-27 01:43:41 -04:00
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2010-07-23 13:05:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2008-12-14 19:21:01 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2008-12-14 19:21:01 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2010-07-23 13:05:39 +02:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2007-03-14 17:34:55 -04:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
2007-03-14 17:34:55 -04:00
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2007-03-27 01:43:41 -04:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2009-10-08 00:39:56 +02:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2010-01-24 16:45:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-19 08:28:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-24 16:45:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-08 00:39:56 +02:00
|
|
|
|
firewire: cdev: fix responses to nodes at different card
My box has two firewire cards in it: card0 and card1.
My application opens /dev/fw0 (card 0) and allocates an address space.
The core makes the address space available on both cards.
Along comes the remote device, which sends a READ_QUADLET_REQUEST to
card1. The request gets passed up to my application, which calls
ioctl_send_response().
ioctl_send_response() then calls fw_send_response() with card0,
because that's the card it's bound to.
Card0's driver drops the response, because it isn't part of
a transaction that it has outstanding.
So in core-cdev: handle_request(), we need to stash the
card of the inbound request in the struct inbound_transaction_resource and
use that card to send the response to.
The hard part will be refcounting the card correctly
so it can't get deallocated while we hold a pointer to it.
Here's a trivial patch, which does not do the card refcounting, but at
least demonstrates what the problem is.
Note that we can't depend on the fact that the core-cdev:client
structure holds a card open, because in this case the card it holds
open is not the card the request came in on.
..and there's no way for the core to tell cdev "this card is gone,
kill any inbound transactions on it", while cdev holds the transaction
open until userspace issues a SEND_RESPONSE ioctl, which may be a very,
very long time. But when it does, it calls fw_send_response(), which
will dereference the card...
So how unhappy are we about userspace potentially holding a fw_card
open forever?
Signed-off-by: Jay Fenlason <fenlason@redhat.com>
Reference counting to be addressed in a separate change.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (whitespace)
2010-05-18 14:02:45 -04:00
|
|
|
|
2009-10-08 00:39:56 +02:00
|
|
|
|
firewire: cdev: count references of cards during inbound transactions
If a request comes in to an address range managed by a userspace driver
i.e. <linux/firewire-cdev.h> client, the card instance of request and
response may differ from the card instance of the client device.
Therefore we need to take a reference of the card until the response was
sent.
I thought about putting the reference counting into core-transaction.c,
but the various high-level drivers besides cdev clients (firewire-net,
firewire-sbp2, firedtv) use the card pointer in their fw_address_handler
address_callback method only to look up devices of which they already
hold the necessary references. So this seems to be a specific
firewire-cdev issue which is better addressed locally.
We do not need the reference
- in case of FCP_REQUEST or FCP_RESPONSE requests because then the
firewire-core will send the split transaction response for us
already in the context of the request handler,
- if it is the same card as the client device's because we hold a
card reference indirectly via teh client->device reference.
To keep things simple, we take the reference nevertheless.
Jay Fenlason wrote:
> there's no way for the core to tell cdev "this card is gone,
> kill any inbound transactions on it", while cdev holds the transaction
> open until userspace issues a SEND_RESPONSE ioctl, which may be a very,
> very long time. But when it does, it calls fw_send_response(), which
> will dereference the card...
>
> So how unhappy are we about userspace potentially holding a fw_card
> open forever?
While termination of inbound transcations at card removal could be
implemented, it is IMO not worth the effort. Currently, the effect of
holding a reference of a card that has been removed is to block the
process that called the pci_remove of the card. This is
- either a user process ran by root. Root can find and kill processes
that have /dev/fw* open, if desired.
- a kernel thread (which one?) in case of hot removal of a PCCard or
ExpressCard.
The latter case could be a problem indeed. firewire-core's card
shutdown and card release should probably be improved not to block in
shutdown, just to defer freeing of memory until release.
This is not a new problem though; the same already always happens with
the client->device->card without the need of inbound transactions or
other special conditions involved, other than the client not closing the
file.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2010-06-20 22:52:27 +02:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
2009-10-08 00:39:56 +02:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2007-03-07 12:12:42 -05:00
|
|
|
|
2010-07-08 16:09:06 +02:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2010-07-08 16:09:06 +02:00
|
|
|
|
2007-03-07 12:12:42 -05:00
|
|
|
|
|
|
|
|
|
2007-03-27 01:43:41 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2007-03-27 01:43:41 -04:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2007-03-27 01:43:41 -04:00
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2007-03-28 21:26:42 +02:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
2007-03-28 21:26:42 +02:00
|
|
|
|
2009-03-10 21:00:23 +01:00
|
|
|
|
2009-05-13 21:42:14 +02:00
|
|
|
|
2009-03-10 21:00:23 +01:00
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2007-03-28 21:26:42 +02:00
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2007-03-28 21:26:42 +02:00
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
|
|
|
|
|
2007-03-28 21:26:42 +02:00
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2007-03-28 21:26:42 +02:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
|
|
|
|
|
2007-03-28 21:26:42 +02:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2007-03-28 21:26:42 +02:00
|
|
|
|
|
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
|
|
|
|
|
2007-03-28 21:26:42 +02:00
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2007-03-28 21:26:42 +02:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
2007-03-28 21:26:42 +02:00
|
|
|
|
|
|
|
|
|
2008-12-14 21:47:04 +01:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2010-06-08 00:20:10 +02:00
|
|
|
|
2010-07-16 22:25:51 +02:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2010-07-16 22:25:51 +02:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
2010-07-29 18:19:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2007-06-20 17:48:07 -04:00
|
|
|
|
2010-07-29 18:19:22 +02:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2010-07-07 14:13:14 +02:00
|
|
|
|
2010-07-29 18:19:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-16 17:34:50 -05:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2010-07-29 18:19:22 +02:00
|
|
|
|
|
|
|
|
|
2007-03-14 17:34:53 -04:00
|
|
|
|
2010-07-29 18:19:22 +02:00
|
|
|
|
|
|
|
|
|
2007-03-14 17:34:53 -04:00
|
|
|
|
|
|
|
|
|
2010-07-29 18:19:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-14 17:34:53 -04:00
|
|
|
|
2010-07-29 18:19:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-14 17:34:53 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-16 17:34:50 -05:00
|
|
|
|
2007-03-14 17:34:53 -04:00
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2010-07-29 18:19:22 +02:00
|
|
|
|
2007-06-20 17:48:07 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-14 11:46:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2007-06-20 17:48:07 -04:00
|
|
|
|
2010-06-14 11:46:25 +02:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2007-04-30 15:03:14 -04:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-29 18:19:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-31 11:16:43 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-09-12 18:09:55 +02:00
|
|
|
|
|
|
|
|
|
2007-05-31 11:16:43 -04:00
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2007-02-16 17:34:44 -05:00
|
|
|
|
2010-07-29 18:19:22 +02:00
|
|
|
|
2007-05-31 11:16:43 -04:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
2007-05-07 20:33:32 -04:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
2007-02-16 17:34:38 -05:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2007-05-07 20:33:32 -04:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2007-03-28 20:46:23 +02:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2007-03-28 20:46:23 +02:00
|
|
|
|
2007-02-16 17:34:38 -05:00
|
|
|
|
2007-03-28 20:46:23 +02:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
2010-07-29 18:19:22 +02:00
|
|
|
|
|
|
|
|
|
2007-10-14 19:34:40 +01:00
|
|
|
|
2010-07-29 18:19:22 +02:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
2007-05-31 11:16:43 -04:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2007-05-31 11:16:43 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-16 17:34:40 -05:00
|
|
|
|
2010-07-29 18:19:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-31 16:26:46 +02:00
|
|
|
|
2010-07-29 09:31:56 +02:00
|
|
|
|
2010-07-29 18:19:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-28 23:49:45 +02:00
|
|
|
|
|
|
|
|
|
2010-03-31 16:26:46 +02:00
|
|
|
|
2010-07-29 18:19:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-16 17:34:40 -05:00
|
|
|
|
2010-07-29 18:19:22 +02:00
|
|
|
|
2007-02-16 17:34:40 -05:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2010-07-29 09:31:56 +02:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-29 09:31:56 +02:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2007-02-16 17:34:51 -05:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
2007-03-28 20:46:23 +02:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
2007-02-16 17:34:44 -05:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2010-07-07 14:13:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2007-04-30 15:03:14 -04:00
|
|
|
|
2008-02-20 21:10:06 +01:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-14 17:34:54 -04:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2007-02-16 17:34:42 -05:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2007-04-30 15:03:14 -04:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2007-04-30 15:03:14 -04:00
|
|
|
|
|
|
|
|
|
2007-02-16 17:34:42 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2007-09-29 10:41:58 +02:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2007-09-29 10:41:58 +02:00
|
|
|
|
2010-02-20 12:13:49 +01:00
|
|
|
|
2010-02-20 22:24:43 +01:00
|
|
|
|
2010-02-20 12:13:49 +01:00
|
|
|
|
2007-09-29 10:41:58 +02:00
|
|
|
|
2010-02-20 22:24:43 +01:00
|
|
|
|
2007-09-29 10:41:58 +02:00
|
|
|
|
2010-06-12 20:35:52 +02:00
|
|
|
|
2010-02-20 12:13:49 +01:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2010-02-20 12:13:49 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-29 10:41:58 +02:00
|
|
|
|
2010-02-20 22:24:43 +01:00
|
|
|
|
2007-09-29 10:41:58 +02:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-20 12:13:49 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2010-02-20 12:13:49 +01:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2010-02-20 12:13:49 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2010-02-20 12:13:49 +01:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
|
|
|
|
|
2010-02-20 22:24:43 +01:00
|
|
|
|
2007-09-29 10:41:58 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-22 15:05:03 +01:00
|
|
|
|
|
|
|
|
|
2009-10-08 00:41:10 +02:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2009-06-20 13:23:59 +02:00
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-08 23:07:40 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-08 00:41:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2009-10-08 00:41:38 +02:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-08 00:41:10 +02:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-08 00:41:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-11 13:44:46 +01:00
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-08 00:41:10 +02:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2009-03-10 20:59:16 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2009-03-10 20:59:16 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2009-03-05 19:08:40 +01:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2009-03-10 21:02:21 +01:00
|
|
|
|
|
|
|
|
|
2009-03-05 19:08:40 +01:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
|
|
|
|
|
2009-03-10 21:02:21 +01:00
|
|
|
|
2009-03-05 19:08:40 +01:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2009-03-10 21:02:21 +01:00
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2009-03-10 21:02:21 +01:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-10 21:02:21 +01:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2009-03-05 19:08:40 +01:00
|
|
|
|
|
|
|
|
|
2010-07-16 22:25:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-18 13:00:50 +02:00
|
|
|
|
2010-07-16 22:25:14 +02:00
|
|
|
|
2010-07-18 13:00:50 +02:00
|
|
|
|
|
|
|
|
|
2010-07-16 22:25:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-18 13:00:50 +02:00
|
|
|
|
2010-07-16 22:25:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-30 08:24:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-16 22:25:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-18 13:00:50 +02:00
|
|
|
|
|
|
|
|
|
2010-07-16 22:25:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-16 22:25:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2010-07-16 22:24:29 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-16 22:25:14 +02:00
|
|
|
|
2010-07-16 22:25:51 +02:00
|
|
|
|
2010-07-29 18:19:22 +02:00
|
|
|
|
2007-04-30 15:03:13 -04:00
|
|
|
|
|
|
|
|
|
2008-12-14 21:47:04 +01:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2008-12-14 21:45:45 +01:00
|
|
|
|
2007-04-30 15:03:13 -04:00
|
|
|
|
2010-02-21 17:56:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-04-30 15:03:13 -04:00
|
|
|
|
2010-04-07 08:30:50 +02:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2007-04-30 15:03:13 -04:00
|
|
|
|
2010-04-07 08:30:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-04-30 15:03:13 -04:00
|
|
|
|
|
|
|
|
|
2010-02-21 17:56:21 +01:00
|
|
|
|
2008-12-14 21:45:45 +01:00
|
|
|
|
|
|
|
|
|
2007-04-30 15:03:13 -04:00
|
|
|
|
2010-04-07 08:30:50 +02:00
|
|
|
|
|
|
|
|
|
2007-04-30 15:03:13 -04:00
|
|
|
|
|
|
|
|
|
2008-12-14 21:45:45 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
2008-12-14 21:47:04 +01:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2010-02-21 17:56:42 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-14 21:47:04 +01:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2010-02-21 17:56:42 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-16 17:34:38 -05:00
|
|
|
|
|
|
|
|
|
2008-12-14 21:45:45 +01:00
|
|
|
|
2007-02-16 17:34:38 -05:00
|
|
|
|
2008-05-16 11:15:23 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-16 17:34:38 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2007-02-16 17:34:38 -05:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-16 17:34:38 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-14 21:45:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2008-12-14 21:45:45 +01:00
|
|
|
|
|
|
|
|
|
2007-02-16 17:34:38 -05:00
|
|
|
|
|
|
|
|
|
2008-12-14 21:45:45 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
2011-01-10 17:28:39 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
|
|
|
|
|
2009-10-08 00:41:38 +02:00
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
|
|
|
|
|
2009-10-08 00:41:38 +02:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-08 00:41:38 +02:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2010-07-16 22:25:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-14 19:19:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-05 20:28:10 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2007-03-28 21:26:42 +02:00
|
|
|
|
2011-01-10 17:28:39 +01:00
|
|
|
|
|
|
|
|
|
2008-12-21 16:47:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-07 12:12:50 -05:00
|
|
|
|
2009-10-08 00:41:38 +02:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2009-01-04 16:23:29 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-07 12:12:48 -05:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-07 12:12:48 -05:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2007-03-07 12:12:48 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
2007-01-14 15:29:07 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2010-04-10 16:38:05 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-10 16:38:05 +01:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
2007-01-21 20:45:32 +01:00
|
|
|
|
2006-12-19 19:58:31 -05:00
|
|
|
|
|
|
|
|
|
