This patch (as1163b) adds a "quirks=" module parameter to usb-storage.
This will allow people to make short-term changes to their
unusual_devs list without rebuilding the entire driver. Testing will
become much easier, and less-sophisticated users will be able to
access their buggy devices after a simple config-file change instead
of having to wait for a new kernel release.
The patch also adds a documentation entry for usb-storage's
"delay_use" parameter, which has been around for years but but was
never listed among the kernel parameters.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
A published errata for ppc440epx states, that when running Linux with
both EHCI and OHCI modules loaded, the EHCI module experiences a fatal
error when a high-speed device is connected to the USB2.0, and
functions normally if OHCI module is not loaded.
There used to be recommendation to use only hi-speed or full-speed
devices with specific conditions, when respective module was unloaded.
Later, it was observed that ohci suspend is enough to keep things
going, and it was turned into workaround, as explained below.
Quote from original descriprion:
The 440EPx USB 2.0 Host controller is an EHCI compliant controller. In
USB 2.0 Host controllers, each EHCI controller has one or more companion
controllers, which may be OHCI or UHCI. An USB 2.0 Host controller will
contain one or more ports. For each port, only one of the controllers
is connected at any one time. In the 440EPx, there is only one OHCI
companion controller, and only one USB 2.0 Host port.
All ports on an USB 2.0 controller default to the companion
controller. If you load only an ohci driver, it will have control of
the ports and any deviceplugged in will operate, although high speed
devices will be forced to operate at full speed. When an ehci driver
is loaded, it explicitly takes control of the ports. If there is a
device connected, and / or every time there is a new device connected,
the ehci driver determines if the device is high speed or not. If it
is high speed, the driver retains control of the port. If it is not,
the driver explicitly gives the companion controller control of the
port.
The is a software workaround that uses
Initial version of the software workaround was posted to
linux-usb-devel:
http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg54019.html
and later available from amcc.com:
http://www.amcc.com/Embedded/Downloads/download.html?cat=1&family=15&ins=2
The patch below is generally based on the latter, but reworked to
powerpc/of_device USB drivers, and uses a few devicetree inquiries to
get rid of (some) hardcoded defines.
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The QE UDC doesn't check for cpm_muram_alloc() return values, this
might cause all sorts of misbehaviour when cpm_muram_alloc() failed
to allocate the muram memory.
While at at, change few dev_dbg() calls to dev_err(), so that the
driver would not die silently.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Li Yang <leoli@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1161) changes the interface to
usb_lock_device_for_reset(). The existing interface is apparently not
very clear, judging from the fact that several of its callers don't
use it correctly. The new interface always returns 0 for success and
it always requires the caller to unlock the device afterward.
The new routine will not return immediately if it is called while the
driver's probe method is running. Instead it will wait until the
probe is over and the device has been unlocked. This shouldn't cause
any problems; I don't know of any cases where drivers call
usb_lock_device_for_reset() during probe.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Pete Zaitcev <zaitcev@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
It seems that there's rather involved way to say something
which is commonly written in a plain simple form.
Some type changes would probably be necessary to get gcc
to do bitops instead of divide but it's no worse after my
change than before I think.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
this introduces a sanity check into berry_charge to give up before
damage is done if we lack juice.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Just over a year ago (!) I had this brief exchange with Alan Stern:
>> It seems that the signal that can be used with USBDEVFS_DISCSIGNAL and
>> in usbdevfs_urb.signr is limited to the real-time signals SIGRTMIN to
>> SIGRTMAX. What's the rationale for this restriction? I believe that a
>> process can kill() itself with any signal number, can't it? I was
>> planning to use SIGIO for usbdevfs_urb.signr and SIGTERM (uncaught) for
>> USBDEVFS_DISCSIGNAL. I don't think I'll have a problem with using
>> SIGRTMIN+n instead, but I'm curious to know if there's some subtle
>> problem with the non-real-time signals that I should be aware of.
>
> I don't know of any reason for this restriction.
Since no-one else could think of a reason either, I offer the following
patch which allows any signal to be used with USBDEVFS_DISCSIGNAL and
usbdevfs_urb.signr.
Signed-off-by: Phil Endecott <usbpatch@chezphil.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Also a trivial annotation in rh.c for:
drivers/usb/wusbcore/rh.c:366:9: warning: incorrect type in assignment (different base types)
drivers/usb/wusbcore/rh.c:366:9: expected unsigned short [unsigned] [short] [usertype] <noident>
drivers/usb/wusbcore/rh.c:366:9: got restricted __le16 [usertype] <noident>
drivers/usb/wusbcore/rh.c:367:9: warning: incorrect type in assignment (different base types)
drivers/usb/wusbcore/rh.c:367:9: expected unsigned short [unsigned] [short] [usertype] <noident>
drivers/usb/wusbcore/rh.c:367:9: got restricted __le16 [usertype] <noident>
Association types annotation fixes piles of warnings similar to:
drivers/usb/wusbcore/cbaf.c:238:30: warning: incorrect type in initializer (different base types)
drivers/usb/wusbcore/cbaf.c:238:30: expected restricted __le16 [usertype] id
drivers/usb/wusbcore/cbaf.c:238:30: got int
drivers/usb/wusbcore/cbaf.c:238:30: warning: incorrect type in initializer (different base types)
drivers/usb/wusbcore/cbaf.c:238:30: expected restricted __le16 [usertype] len
drivers/usb/wusbcore/cbaf.c:238:30: got int
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Cc: David Vrabel <david.vrabel@csr.com>
Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Instead of waiting a painful 5000ms, quirk_usb_disable_ehci() now does a
1000ms loop to wait for the BIOS to acknowledge the handoff.
The five second delay is really quite irritating to have to deal with
every boot up, and I very seriously doubt any non-broken bios takes more
than a second to do the actual handoff.
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: David Brownell <david-b@pacbell.net>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1156) straightens out some code in usbcore. The
usb_create_intf_ep_files() and usb_remove_intf_ep_files() routines
don't need to be separate inlines; they should be moved bodily into
the places where they get used.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
There's no need to take the address of the function params or local variables
when the direct value byteswapping routines are available.
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This will let us use this header in other header files.
Will be needed for the FHCI USB Host driver.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This driver implements the support for Oxford OXU210HP USB high-speed host,
no peripheral nor OTG.
Signed-off-by: Rodolfo Giometti <giometti@linux.it>
Cc: Kan Liu <kan.k.liu@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
For function ehci_bus_resume()
- Added flag resume_needed
No need to wait for 20ms if no port was suspended
- Change mdelay to msleep
- release and reacquire the spinlock around mdelay
Signed-off-by: vikram pandita <vikram.pandita@ti.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Use the newly introduced pci_ioremap_bar() function in drivers/usb.
pci_ioremap_bar() just takes a pci device and a bar number, with the goal
of making it really hard to get wrong, while also having a central place
to stick sanity checks.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
temp, bytes and param->{length,sglen,vary} are unsigned so
these tests do nothing.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch corrects the issue when one connects a Nokia 5200 cell
phone in data storage mode. If one uses an unpatched unusual_devs.h,
the following messages appear on /var/log/messages:
Dec 12 01:03:24 alberich kernel: usb 4-2: new full speed USB device
using uhci_hcd and address 3
Dec 12 01:03:25 alberich kernel: usb 4-2: configuration #1 chosen from 1 choice
Dec 12 01:03:25 alberich kernel: scsi10 : SCSI emulation for USB Mass
Storage devices
Dec 12 01:03:25 alberich kernel: usb 4-2: New USB device found,
idVendor=0421, idProduct=04bd
Dec 12 01:03:25 alberich kernel: usb 4-2: New USB device strings:
Mfr=1, Product=2, SerialNumber=3
Dec 12 01:03:25 alberich kernel: usb 4-2: Product: Nokia 5200
Dec 12 01:03:25 alberich kernel: usb 4-2: Manufacturer: Nokia
Dec 12 01:03:25 alberich kernel: usb 4-2: SerialNumber: 353930018354523
Dec 12 01:03:25 alberich kernel: usbcore: registered new interface driver ub
Dec 12 01:03:30 alberich kernel: scsi 10:0:0:0: Direct-Access
Nokia Nokia 5200 0000 PQ: 0 AN
SI: 4
Dec 12 01:03:30 alberich kernel: sd 10:0:0:0: [sdg] 3985409 512-byte
hardware sectors (2041 MB)
Dec 12 01:03:30 alberich kernel: sd 10:0:0:0: [sdg] Write Protect is off
Dec 12 01:03:30 alberich kernel: sd 10:0:0:0: [sdg] Assuming drive
cache: write through
Dec 12 01:03:30 alberich kernel: sd 10:0:0:0: [sdg] 3985409 512-byte
hardware sectors (2041 MB)
Dec 12 01:03:30 alberich kernel: sd 10:0:0:0: [sdg] Write Protect is off
Dec 12 01:03:30 alberich kernel: sd 10:0:0:0: [sdg] Assuming drive
cache: write through
Dec 12 01:03:30 alberich kernel: sdg: sdg1
Dec 12 01:03:30 alberich kernel: sd 10:0:0:0: [sdg] Attached SCSI removable disk
Dec 12 01:03:30 alberich kernel: sd 10:0:0:0: Attached scsi generic sg9 type 0
Dec 12 01:03:30 alberich kernel: sd 10:0:0:0: [sdg] Sense Key : No
Sense [current]
Dec 12 01:03:30 alberich kernel: sd 10:0:0:0: [sdg] Add. Sense: No
additional sense information
Dec 12 01:03:30 alberich kernel: sd 10:0:0:0: [sdg] Sense Key : No
Sense [current]
Dec 12 01:03:30 alberich kernel: sd 10:0:0:0: [sdg] Add. Sense: No
additional sense information
Dec 12 01:03:30 alberich kernel: sd 10:0:0:0: [sdg] Sense Key : No
Sense [current]
(...)
The MicroSD card in the phone remains inaccessible and finally the
cell phone turns itself off. The patch solves this problem and makes
the cell phone fully accessible:
[root@alberich kernel-linus-2.6.27.5-1mdv]# df -h
Sist. Arq. Tam Usad Disp Uso% Montado em
/dev/sda6 31G 5,2G 26G 17% /
/dev/sda1 92M 27M 61M 31% /boot
/dev/mapper/homevg-homelv 240G 237G 3,5G 99% /home
/dev/sda3 21G 7,9G 13G 40% /mnt/windows
/dev/sdg1 2,0G 287M 1,7G 15% /media/disk <--------
I've found necessary to use the FL_US_CAPACITY_FIX switch, as without
it the cell phone is recognized but it went berserk when performing
low-level functions on it (a fdisk -l /dev/uba for example).
lsusb -v output follows:
Bus 004 Device 004: ID 0421:04bd Nokia Mobile Phones
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0421 Nokia Mobile Phones
idProduct 0x04bd
bcdDevice 6.03
iManufacturer 1 Nokia
iProduct 2 Nokia 5200
iSerial 3 353930018354523
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0001
Self Powered
Signed-off-by: Paulo Afonso Graner Fessel <pfessel@gmail.com>
Signed-off-by: Phil Dibowitz <phil@ipom.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This device has been released in a new revision which is still buggy.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Phil Dibowitz <phil@ipom.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
I have another Argosy USB storage device, which has the same problem
with the Argosy USB storage device already fixed in 2.6.27.7. But this
device has another product ID (840:84), so this patch adds a new entry
into unusual_devs to fix the mount problem.
I enclose here two patches: one against 2.6.27.8, and another against
the latest linus-git tree.
The information about the Argosy device is like below:
#lsusb -v -d 840:84
Bus 005 Device 005: ID 0840:0084 Argosy Research, Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0840 Argosy Research, Inc.
idProduct 0x0084
bcdDevice 0.01
iManufacturer 1 Generic
iProduct 2 USB 2.0 Storage Device
iSerial 3 8400000000002549
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 2mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
Before the patch, dmesg returns a lot of information like below (my
dmesg is overflown):
....
[ 138.833390] sd 7:0:0:0: [sdb] Add. Sense: No additional sense information
[ 138.877631] sd 7:0:0:0: [sdb] Sense Key : No Sense [current]
[ 138.877643] sd 7:0:0:0: [sdb] Add. Sense: No additional sense information
[ 138.921906] sd 7:0:0:0: [sdb] Sense Key : No Sense [current]
[ 138.921923] sd 7:0:0:0: [sdb] Add. Sense: No additional sense information
....
After the fix, dmesg returns below information:
....
usb 5-1: new high speed USB device using ehci_hcd and address 5
usb 5-1: configuration #1 chosen from 1 choice
scsi7 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 5
usb-storage: waiting for device to settle before scanning
usb-storage: device scan complete
scsi 7:0:0:0: Direct-Access HTS54808 0M9AT00 MG4O PQ: 0 ANSI: 0
sd 7:0:0:0: [sdb] 156301488 512-byte hardware sectors (80026 MB)
sd 7:0:0:0: [sdb] Write Protect is off
sd 7:0:0:0: [sdb] Mode Sense: 03 00 00 00
sd 7:0:0:0: [sdb] Assuming drive cache: write through
sd 7:0:0:0: [sdb] 156301488 512-byte hardware sectors (80026 MB)
sd 7:0:0:0: [sdb] Write Protect is off
sd 7:0:0:0: [sdb] Mode Sense: 03 00 00 00
sd 7:0:0:0: [sdb] Assuming drive cache: write through
sdb: sdb1
sd 7:0:0:0: [sdb] Attached SCSI disk
sd 7:0:0:0: Attached scsi generic sg1 type 0
kjournald starting. Commit interval 5 seconds
EXT3 FS on sdb1, internal journal
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
Cc: Kuniyasu Suzaki <k.suzaki@aist.go.jp>
Signed-off-by: Nguyen Anh Quynh <aquynh@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The __SWAB_64_THRU_32__ case of a 64-bit byte swap was depending on the
no-longer-existant ___swab32() method (three underscores). We got rid
of some of the worst indirection and complexity, and now it should just
use the 32-bit swab function that was defined right above it.
Reported-and-tested-by: Nicolas Pitre <nico@cam.org>
Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This implementation caused problems in userspace which can, and does
define _both_ __LITTLE_ENDIAN and __BIG_ENDIAN.
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The first step to make swab.h a regular header that will
include an asm/swab.h with arch overrides.
Avoid the gratuitous differences introduced in the new
linux/swab.h by naming the ___constant_swabXX bits and
__fswabXX bits exactly as found in the old implementation
in byteorder/swab[b].h
Use this new swab.h in byteorder/[big|little]_endian.h and
remove the two old swab headers.
Although the inclusion of asm/byteorder.h looks strange in
linux/swab.h, this will allow each arch to move the actual
arch overrides for the swab bits in an asm file and then
the includes can be cleaned up without requiring a flag day
for all arches at once.
Keep providing __fswabXX in case some userspace was using them
directly, but the revised __swabXX should be used instead in
any new code and will always do constant folding not dependent
on the optimization level, which means the __constant versions
can be phased out in-kernel.
Arches that use the old-style arch macros will lose their
optimized versions until they move to the new style, but at
least they will still compile. Many arches have already moved
and the patches to move the remaining arches are trivial.
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm: fix ordering of driver unload vs agp unload.
drm/i915: Respect the other stolen memory sizes we know of.
drm/i915: Non-mobile parts don't have integrated TV-out.
drm/i915: Add support for integrated HDMI on G4X hardware.
drm/i915: Pin cursor bo and unpin old bo when setting cursor.
drm/i915: Don't allow objects to get bound while VT switched.
This is ported directly from the userland 2D driver code. The HDMI audio bits
aren't hooked up yet.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
We also didn't track the cursor bo before and would leak a reference
when the cursor image was change.
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
This avoids a BUG_ON in the enter_vt path due to objects being in the GTT
when we shouldn't have ever let them be (as we're not supposed to touch the
device during that time).
This was triggered by a change in the 2D driver to use the GTT mapping of
objects after pinning them to improve software fallback performance.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
Alan Stern