linux-toradex.git/drivers, branch v2.6.32.6 Linux kernel for Apalis and Colibri modules USB: fix usbstorage for 2770:915d delivers no FAT 2010-01-25T18:49:42+00:00 Ryan May rmay31@gmail.com 2010-01-06T16:09:25+00:00 3d0cc9a9a1cd4a043ffcd3251161d07a846a103c commit 10d2cdb6102669279bee2d9a00a22431b74583d5 upstream. Resolves kernel.org bug 14914. Remove entry for 2770:915d (usb digital camera with mass storage support) from unusual_devs.h. The fix triggered by the entry causes the file system on the camera to be completely inaccessible (no partition table, the device is not mountable). The patch works, but let me clarify a few things about it. All the patch does is remove the entry for this device from the drivers/usb/storage/unusual_devs.h, which is supposed to help with a problem with the device's reported size (I think). I'm pretty sure it was originally added for a reason, so I'm not sure removing it won't cause other problems to reappear. Also, I should note that this unusual_devs.h entry was present (and activating workarounds) in 2.6.29, but in that version everything works fine. Starting with 2.6.30, things no longer work. Signed-off-by: Ryan May <rmay31@gmail.com> Cc: Rohan Hart <rohan.hart17@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 10d2cdb6102669279bee2d9a00a22431b74583d5 upstream.

Resolves kernel.org bug 14914.

Remove entry for 2770:915d (usb digital camera with mass storage
support) from unusual_devs.h. The fix triggered by the entry causes
the file system on the camera to be completely inaccessible (no
partition table, the device is not mountable).

The patch works, but let me clarify a few things about it.  All the
patch does is remove the entry for this device from the
drivers/usb/storage/unusual_devs.h, which is supposed to help with a
problem with the device's reported size (I think).  I'm pretty sure it
was originally added for a reason, so I'm not sure removing it won't
cause other problems to reappear.  Also, I should note that this
unusual_devs.h entry was present (and activating workarounds) in
2.6.29, but in that version everything works fine.  Starting with
2.6.30, things no longer work.

Signed-off-by: Ryan May <rmay31@gmail.com>
Cc: Rohan Hart <rohan.hart17@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
DM: Fix device mapper topology stacking 2010-01-25T18:49:41+00:00 Martin K. Petersen martin.petersen@oracle.com 2010-01-11T08:21:50+00:00 e0f5cfa7c18b411634e73923841eccd3a4c0ce7f commit b27d7f16d3c6c27345d4280a739809c1c2c4c0b5 upstream. Make DM use bdev_stack_limits() function so that partition offsets get taken into account when calculating alignment. Clarify stacking warnings. Also remove obsolete clearing of final alignment_offset and misalignment flag. Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: Alasdair G. Kergon <agk@redhat.com> Signed-off-by: Jens Axboe <jens.axboe@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit b27d7f16d3c6c27345d4280a739809c1c2c4c0b5 upstream.

Make DM use bdev_stack_limits() function so that partition offsets get
taken into account when calculating alignment.  Clarify stacking
warnings.

Also remove obsolete clearing of final alignment_offset and misalignment
flag.

Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: Alasdair G. Kergon <agk@redhat.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
drm/i915: try another possible DDC bus for the SDVO device with multiple outputs 2010-01-25T18:49:39+00:00 Zhao Yakui yakui.zhao@intel.com 2010-01-08T02:58:20+00:00 ed0cd89c7333b17d50812201602f436b57ef1482 commit 7c3f0a2726fed78e0e0afe3b6fc3c1f5b298e447 upstream. There exist multiple DDC buses for the SDVO cards with multiple outputs. When we can't get the EDID by using the select DDC bus, we can try the other possible DDC bus to see whether the EDID can be obtained. https://bugs.freedesktop.org/show_bug.cgi?id=23842 Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Tested-by: Sebastien Caty <sebastien.caty@mrnf.gouv.qc.ca> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 7c3f0a2726fed78e0e0afe3b6fc3c1f5b298e447 upstream.

There exist multiple DDC buses for the SDVO cards with multiple outputs.
When we can't get the EDID by using the select DDC bus, we can try the other
possible DDC bus to see whether the EDID can be obtained.

https://bugs.freedesktop.org/show_bug.cgi?id=23842

Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Tested-by: Sebastien Caty <sebastien.caty@mrnf.gouv.qc.ca>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
drm/i915: Read the response after issuing DDC bus switch command 2010-01-25T18:49:38+00:00 Zhao Yakui yakui.zhao@intel.com 2010-01-08T02:58:19+00:00 4fb77a3f85d3e4633e6ef3a8b319f882caf7c623 commit 6a304caf0bf9c429fc261f260b86cabf5bde2cbb upstream. For some SDVO cards based on conexant chip, we can't read the EDID if we don't read the response after issuing SDVO DDC bus switch command. From the SDVO spec once when another I2C transaction is finished after completing the I2C transaction of issuing the bus switch command, it will be switched back to the SDVO internal state again. So we can't initiate a new I2C transaction to read the response after issuing the DDC bus switch command. Instead we should issue DDC bus switch command and read the response in the same I2C transaction. https://bugs.freedesktop.org/show_bug.cgi?id=23842 https://bugs.freedesktop.org/show_bug.cgi?id=24458 https://bugs.freedesktop.org/show_bug.cgi?id=24522 https://bugs.freedesktop.org/show_bug.cgi?id=24282 Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Tested-by: Sebastien Caty <sebastien.caty@mrnf.gouv.qc.ca> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 6a304caf0bf9c429fc261f260b86cabf5bde2cbb upstream.

For some SDVO cards based on conexant chip, we can't read the EDID if
we don't read the response after issuing SDVO DDC bus switch
command.

From the SDVO spec once when another I2C transaction is finished after
completing the I2C transaction of issuing the bus switch command, it
will be switched back to the SDVO internal state again. So we can't
initiate a new I2C transaction to read the response after issuing the
DDC bus switch command. Instead we should issue DDC bus switch command
and read the response in the same I2C transaction.

https://bugs.freedesktop.org/show_bug.cgi?id=23842
https://bugs.freedesktop.org/show_bug.cgi?id=24458
https://bugs.freedesktop.org/show_bug.cgi?id=24522
https://bugs.freedesktop.org/show_bug.cgi?id=24282

Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Tested-by: Sebastien Caty <sebastien.caty@mrnf.gouv.qc.ca>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
SCSI: enclosure: fix oops while iterating enclosure_status array 2010-01-25T18:49:37+00:00 James Bottomley James.Bottomley@suse.de 2009-11-26T15:50:20+00:00 8cef765ff1eafb77cc40e8dad7a7a00190d9a6fc commit cc9b2e9f6603190c009e5d2629ce8e3f99571346 upstream. Based on patch originally by Jeff Mahoney <jeffm@suse.com> enclosure_status is expected to be a NULL terminated array of strings but isn't actually NULL terminated. When writing an invalid value to /sys/class/enclosure/.../.../status, it goes off the end of the array and Oopses. Fix by making the assumption true and adding NULL at the end. Reported-by: Artur Wojcik <artur.wojcik@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit cc9b2e9f6603190c009e5d2629ce8e3f99571346 upstream.

Based on patch originally by Jeff Mahoney <jeffm@suse.com>

 enclosure_status is expected to be a NULL terminated array of strings
 but isn't actually NULL terminated. When writing an invalid value to
 /sys/class/enclosure/.../.../status, it goes off the end of the array
 and Oopses.


Fix by making the assumption true and adding NULL at the end.

Reported-by: Artur Wojcik <artur.wojcik@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ACPI: EC: Add wait for irq storm 2010-01-25T18:49:36+00:00 Alexey Starikovskiy astarikovskiy@suse.de 2009-12-30T12:53:10+00:00 5f0ab2dfbf84454894568377e4dd6578ef3938f3 commit 54070101f86ca9a6e9ba243c999d144721ec3db7 upstream. Merge of poll and irq modes accelerated EC transaction, so that keyboard starts to suffer again. Add msleep(1) into transaction path for the storm to allow keyboard controller to do its job. Reference: http://bugzilla.kernel.org/show_bug.cgi?id=14747 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com> Cc: François Valenduc <francois.valenduc@tvcablenet.be> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 54070101f86ca9a6e9ba243c999d144721ec3db7 upstream.

Merge of poll and irq modes accelerated EC transaction, so
that keyboard starts to suffer again. Add msleep(1) into
transaction path for the storm to allow keyboard controller
to do its job.

Reference: http://bugzilla.kernel.org/show_bug.cgi?id=14747

Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Cc: François Valenduc <francois.valenduc@tvcablenet.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ACPI: EC: Accelerate query execution 2010-01-25T18:49:35+00:00 Alexey Starikovskiy astarikovskiy@suse.de 2009-12-24T08:34:16+00:00 1ff7b99e4983d9e93d25e98ba1ce303ad4e4909e commit a62e8f1978f49e52f87a711ff6711b323d4b12ff upstream. Split EC query handling into acknowledge and execution phase. This allows much smaller pending query lattency and lowers chances of EC going "wild" and losing events. Reference: http://bugzilla.kernel.org/show_bug.cgi?id=14858 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com> Cc: François Valenduc <francois.valenduc@tvcablenet.be> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit a62e8f1978f49e52f87a711ff6711b323d4b12ff upstream.

Split EC query handling into acknowledge and execution phase.
This allows much smaller pending query lattency and lowers chances
of EC going "wild" and losing events.

Reference: http://bugzilla.kernel.org/show_bug.cgi?id=14858

Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Cc: François Valenduc <francois.valenduc@tvcablenet.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: add speed values for USB 3.0 and wireless controllers 2010-01-25T18:49:34+00:00 Greg Kroah-Hartman gregkh@suse.de 2010-01-14T18:33:19+00:00 111ab4bcb4a3c6d803f4cefde0c910de1fdbfc90 commit b132b04e193908a94d95065d0628f8fb0159cc55 upstream. These controllers say "unknown" for their speed in sysfs, which obviously isn't correct. Reported-by: Kurt Garloff <garloff@novell.com> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: David Vrabel <david.vrabel@csr.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit b132b04e193908a94d95065d0628f8fb0159cc55 upstream.

These controllers say "unknown" for their speed in sysfs, which
obviously isn't correct.

Reported-by: Kurt Garloff <garloff@novell.com>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: David Vrabel <david.vrabel@csr.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: add missing delay during remote wakeup 2010-01-25T18:49:33+00:00 Alan Stern stern@rowland.harvard.edu 2010-01-08T16:18:38+00:00 a2a5b33aa3675f267259604218d0663b9778227f commit 49d0f078f494b9d81e820a13dd8093a9bfb0b6b1 upstream. This patch (as1330) fixes a bug in khbud's handling of remote wakeups. When a device sends a remote-wakeup request, the parent hub (or the host controller driver, for directly attached devices) begins the resume sequence and notifies khubd when the sequence finishes. At this point the port's SUSPEND feature is automatically turned off. However the device needs an additional 10-ms resume-recovery time (TRSMRCY in the USB spec). Khubd does not wait for this delay if the SUSPEND feature is off, and as a result some devices fail to behave properly following a remote wakeup. This patch adds the missing delay to the remote-wakeup path. It also extends the resume-signalling delay used by ehci-hcd and uhci-hcd from 20 ms (the value in the spec) to 25 ms (the value we use for non-remote-wakeup resumes). The extra time appears to help some devices. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: Rickard Bellini <rickard.bellini@ericsson.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 49d0f078f494b9d81e820a13dd8093a9bfb0b6b1 upstream.

This patch (as1330) fixes a bug in khbud's handling of remote
wakeups.  When a device sends a remote-wakeup request, the parent hub
(or the host controller driver, for directly attached devices) begins
the resume sequence and notifies khubd when the sequence finishes.  At
this point the port's SUSPEND feature is automatically turned off.

However the device needs an additional 10-ms resume-recovery time
(TRSMRCY in the USB spec).  Khubd does not wait for this delay if the
SUSPEND feature is off, and as a result some devices fail to behave
properly following a remote wakeup.  This patch adds the missing
delay to the remote-wakeup path.

It also extends the resume-signalling delay used by ehci-hcd and
uhci-hcd from 20 ms (the value in the spec) to 25 ms (the value we use
for non-remote-wakeup resumes).  The extra time appears to help some
devices.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Rickard Bellini <rickard.bellini@ericsson.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: EHCI & UHCI: fix race between root-hub suspend and port resume 2010-01-25T18:49:32+00:00 Alan Stern stern@rowland.harvard.edu 2010-01-08T16:18:20+00:00 bfec5cee7784fdc9c07c9ef72312dbad0bff5690 commit cec3a53c7fe794237b582e8e77fc0e48465e65ee upstream. This patch (as1321) fixes a problem with EHCI and UHCI root-hub suspends: If the suspend occurs while a port is trying to resume, the resume doesn't finish and simply gets lost. When remote wakeup is enabled, this is undesirable behavior. The patch checks first to see if any port resumes are in progress, and if they are then it fails the root-hub suspend with -EBUSY. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit cec3a53c7fe794237b582e8e77fc0e48465e65ee upstream.

This patch (as1321) fixes a problem with EHCI and UHCI root-hub
suspends: If the suspend occurs while a port is trying to resume, the
resume doesn't finish and simply gets lost.  When remote wakeup is
enabled, this is undesirable behavior.

The patch checks first to see if any port resumes are in progress, and
if they are then it fails the root-hub suspend with -EBUSY.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>