--- /dev/null
+From 9c1176b6a28850703ea6e3a0f0c703f6d6c61cd3 Mon Sep 17 00:00:00 2001
+From: Stefan Richter <stefanr@s5r6.in-berlin.de>
+Date: Thu, 11 Aug 2011 00:06:04 +0200
+Subject: firewire: cdev: fix 32 bit userland on 64 bit kernel compat corner cases
+
+From: Stefan Richter <stefanr@s5r6.in-berlin.de>
+
+commit 9c1176b6a28850703ea6e3a0f0c703f6d6c61cd3 upstream.
+
+Clemens points out that we need to use compat_ptr() in order to safely
+cast from u64 to addresses of a 32-bit usermode client.
+
+Before, our conversion went wrong
+ - in practice if the client cast from pointer to integer such that
+ sign-extension happened, (libraw1394 and libdc1394 at least were not
+ doing that, IOW were not affected)
+or
+ - in theory on s390 (which doesn't have FireWire though) and on the
+ tile architecture, regardless of what the client does.
+The bug would usually be observed as the initial get_info ioctl failing
+with "Bad address" (EFAULT).
+
+Reported-by: Carl Karsten <carl@personnelware.com>
+Reported-by: Clemens Ladisch <clemens@ladisch.de>
+Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/firewire/core-cdev.c | 24 +++++++++++++++++++++---
+ 1 file changed, 21 insertions(+), 3 deletions(-)
+
+--- a/drivers/firewire/core-cdev.c
++++ b/drivers/firewire/core-cdev.c
+@@ -216,15 +216,33 @@ struct inbound_phy_packet_event {
+ struct fw_cdev_event_phy_packet phy_packet;
+ };
+
+-static inline void __user *u64_to_uptr(__u64 value)
++#ifdef CONFIG_COMPAT
++static void __user *u64_to_uptr(u64 value)
++{
++ if (is_compat_task())
++ return compat_ptr(value);
++ else
++ return (void __user *)(unsigned long)value;
++}
++
++static u64 uptr_to_u64(void __user *ptr)
++{
++ if (is_compat_task())
++ return ptr_to_compat(ptr);
++ else
++ return (u64)(unsigned long)ptr;
++}
++#else
++static inline void __user *u64_to_uptr(u64 value)
+ {
+ return (void __user *)(unsigned long)value;
+ }
+
+-static inline __u64 uptr_to_u64(void __user *ptr)
++static inline u64 uptr_to_u64(void __user *ptr)
+ {
+- return (__u64)(unsigned long)ptr;
++ return (u64)(unsigned long)ptr;
+ }
++#endif /* CONFIG_COMPAT */
+
+ static int fw_device_op_open(struct inode *inode, struct file *file)
+ {
--- /dev/null
+From aaff12039ffd812d0c8bbff50b87b6f1f09bec3e Mon Sep 17 00:00:00 2001
+From: Stefan Richter <stefanr@s5r6.in-berlin.de>
+Date: Sun, 7 Aug 2011 15:20:18 +0200
+Subject: firewire: core: handle ack_busy when fetching the Config ROM
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Stefan Richter <stefanr@s5r6.in-berlin.de>
+
+commit aaff12039ffd812d0c8bbff50b87b6f1f09bec3e upstream.
+
+Some older Panasonic made camcorders (Panasonic AG-EZ30 and NV-DX110,
+Grundig Scenos DLC 2000) reject requests with ack_busy_X if a request is
+sent immediately after they sent a response to a prior transaction.
+This causes firewire-core to fail probing of the camcorder with "giving
+up on config rom for node id ...". Consequently, programs like kino or
+dvgrab are unaware of the presence of a camcorder.
+
+Such transaction failures happen also with the ieee1394 driver stack
+(of the 2.4...2.6 kernel series until 2.6.36 inclusive) but with a lower
+likelihood, such that kino or dvgrab are generally able to use these
+camcorders via the older driver stack. The cause for firewire-ohci's or
+firewire-core's worse behavior is not yet known. Gap count optimization
+in firewire-core is not the cause. Perhaps the slightly higher latency
+of transaction completion in the older stack plays a role. (ieee1394:
+AR-resp DMA context tasklet -> packet completion ktread -> user process;
+firewire-core: tasklet -> user process.)
+
+This change introduces retries and delays after ack_busy_X into
+firewire-core's Config ROM reader, such that at least firewire-core's
+probing and /dev/fw* creation are successful. This still leaves the
+problem that userland processes are facing transaction failures.
+gscanbus's built-in retry routines deal with them successfully, but
+neither kino's nor dvgrab's do ever succeed.
+
+But at least DV capture with "dvgrab -noavc -card 0" works now. Live
+video preview in kino works too, but not actual capture.
+
+One way to prevent Configuration ROM reading failures in application
+programs is to modify libraw1394 to synthesize read responses by means
+of firewire-core's Configuration ROM cache. This would only leave
+CMP and FCP transaction failures as a potential problem source for
+applications.
+
+Reported-and-tested-by: Thomas Seilund <tps@netmaster.dk>
+Reported-and-tested-by: René Fritz <rene@colorcube.de>
+Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/firewire/core-device.c | 15 ++++++++++-----
+ 1 file changed, 10 insertions(+), 5 deletions(-)
+
+--- a/drivers/firewire/core-device.c
++++ b/drivers/firewire/core-device.c
+@@ -455,15 +455,20 @@ static struct device_attribute fw_device
+ static int read_rom(struct fw_device *device,
+ int generation, int index, u32 *data)
+ {
+- int rcode;
++ u64 offset = (CSR_REGISTER_BASE | CSR_CONFIG_ROM) + index * 4;
++ int i, rcode;
+
+ /* device->node_id, accessed below, must not be older than generation */
+ smp_rmb();
+
+- rcode = fw_run_transaction(device->card, TCODE_READ_QUADLET_REQUEST,
+- device->node_id, generation, device->max_speed,
+- (CSR_REGISTER_BASE | CSR_CONFIG_ROM) + index * 4,
+- data, 4);
++ for (i = 10; i < 100; i += 10) {
++ rcode = fw_run_transaction(device->card,
++ TCODE_READ_QUADLET_REQUEST, device->node_id,
++ generation, device->max_speed, offset, data, 4);
++ if (rcode != RCODE_BUSY)
++ break;
++ msleep(i);
++ }
+ be32_to_cpus(data);
+
+ return rcode;
projects / thirdparty / kernel / stable-queue.git / commitdiff
