diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/ABI/README | 77 | ||||
| -rw-r--r-- | Documentation/ABI/obsolete/devfs | 13 | ||||
| -rw-r--r-- | Documentation/ABI/stable/syscalls | 10 | ||||
| -rw-r--r-- | Documentation/ABI/stable/sysfs-module | 30 | ||||
| -rw-r--r-- | Documentation/ABI/testing/sysfs-class | 16 | ||||
| -rw-r--r-- | Documentation/ABI/testing/sysfs-devices | 25 | ||||
| -rw-r--r-- | Documentation/arm/Sharp-LH/ADC-LH7-Touchscreen | 61 | ||||
| -rw-r--r-- | Documentation/arm/Sharp-LH/LCDPanels | 59 | ||||
| -rw-r--r-- | Documentation/feature-removal-schedule.txt | 4 | ||||
| -rw-r--r-- | Documentation/filesystems/inotify.txt | 130 | ||||
| -rw-r--r-- | Documentation/isdn/README.gigaset | 7 | ||||
| -rw-r--r-- | Documentation/power/devices.txt | 90 | ||||
| -rw-r--r-- | Documentation/power/swsusp.txt | 37 | ||||
| -rw-r--r-- | Documentation/scsi/00-INDEX | 2 | ||||
| -rw-r--r-- | Documentation/scsi/ChangeLog.megaraid_sas | 13 | ||||
| -rw-r--r-- | Documentation/scsi/aacraid.txt | 8 | ||||
| -rw-r--r-- | Documentation/scsi/cpqfc.txt | 272 | ||||
| -rw-r--r-- | Documentation/scsi/hptiop.txt | 92 | ||||
| -rw-r--r-- | Documentation/usb/usbmon.txt | 32 |
19 files changed, 571 insertions, 407 deletions
diff --git a/Documentation/ABI/README b/Documentation/ABI/README new file mode 100644 index 00000000000..9feaf16f161 --- /dev/null +++ b/Documentation/ABI/README @@ -0,0 +1,77 @@ +This directory attempts to document the ABI between the Linux kernel and +userspace, and the relative stability of these interfaces. Due to the +everchanging nature of Linux, and the differing maturity levels, these +interfaces should be used by userspace programs in different ways. + +We have four different levels of ABI stability, as shown by the four +different subdirectories in this location. Interfaces may change levels +of stability according to the rules described below. + +The different levels of stability are: + + stable/ + This directory documents the interfaces that the developer has + defined to be stable. Userspace programs are free to use these + interfaces with no restrictions, and backward compatibility for + them will be guaranteed for at least 2 years. Most interfaces + (like syscalls) are expected to never change and always be + available. + + testing/ + This directory documents interfaces that are felt to be stable, + as the main development of this interface has been completed. + The interface can be changed to add new features, but the + current interface will not break by doing this, unless grave + errors or security problems are found in them. Userspace + programs can start to rely on these interfaces, but they must be + aware of changes that can occur before these interfaces move to + be marked stable. Programs that use these interfaces are + strongly encouraged to add their name to the description of + these interfaces, so that the kernel developers can easily + notify them if any changes occur (see the description of the + layout of the files below for details on how to do this.) + + obsolete/ + This directory documents interfaces that are still remaining in + the kernel, but are marked to be removed at some later point in + time. The description of the interface will document the reason + why it is obsolete and when it can be expected to be removed. + The file Documentation/feature-removal-schedule.txt may describe + some of these interfaces, giving a schedule for when they will + be removed. + + removed/ + This directory contains a list of the old interfaces that have + been removed from the kernel. + +Every file in these directories will contain the following information: + +What: Short description of the interface +Date: Date created +KernelVersion: Kernel version this feature first showed up in. +Contact: Primary contact for this interface (may be a mailing list) +Description: Long description of the interface and how to use it. +Users: All users of this interface who wish to be notified when + it changes. This is very important for interfaces in + the "testing" stage, so that kernel developers can work + with userspace developers to ensure that things do not + break in ways that are unacceptable. It is also + important to get feedback for these interfaces to make + sure they are working in a proper way and do not need to + be changed further. + + +How things move between levels: + +Interfaces in stable may move to obsolete, as long as the proper +notification is given. + +Interfaces may be removed from obsolete and the kernel as long as the +documented amount of time has gone by. + +Interfaces in the testing state can move to the stable state when the +developers feel they are finished. They cannot be removed from the +kernel tree without going through the obsolete state first. + +It's up to the developer to place their interfaces in the category they +wish for it to start out in. diff --git a/Documentation/ABI/obsolete/devfs b/Documentation/ABI/obsolete/devfs new file mode 100644 index 00000000000..b8b87399bc8 --- /dev/null +++ b/Documentation/ABI/obsolete/devfs @@ -0,0 +1,13 @@ +What: devfs +Date: July 2005 +Contact: Greg Kroah-Hartman <gregkh@suse.de> +Description: + devfs has been unmaintained for a number of years, has unfixable + races, contains a naming policy within the kernel that is + against the LSB, and can be replaced by using udev. + The files fs/devfs/*, include/linux/devfs_fs*.h will be removed, + along with the the assorted devfs function calls throughout the + kernel tree. + +Users: + diff --git a/Documentation/ABI/stable/syscalls b/Documentation/ABI/stable/syscalls new file mode 100644 index 00000000000..c3ae3e7d6a0 --- /dev/null +++ b/Documentation/ABI/stable/syscalls @@ -0,0 +1,10 @@ +What: The kernel syscall interface +Description: + This interface matches much of the POSIX interface and is based + on it and other Unix based interfaces. It will only be added to + over time, and not have things removed from it. + + Note that this interface is different for every architecture + that Linux supports. Please see the architecture-specific + documentation for details on the syscall numbers that are to be + mapped to each syscall. diff --git a/Documentation/ABI/stable/sysfs-module b/Documentation/ABI/stable/sysfs-module new file mode 100644 index 00000000000..75be4311833 --- /dev/null +++ b/Documentation/ABI/stable/sysfs-module @@ -0,0 +1,30 @@ +What: /sys/module +Description: + The /sys/module tree consists of the following structure: + + /sys/module/MODULENAME + The name of the module that is in the kernel. This + module name will show up either if the module is built + directly into the kernel, or if it is loaded as a + dyanmic module. + + /sys/module/MODULENAME/parameters + This directory contains individual files that are each + individual parameters of the module that are able to be + changed at runtime. See the individual module + documentation as to the contents of these parameters and + what they accomplish. + + Note: The individual parameter names and values are not + considered stable, only the fact that they will be + placed in this location within sysfs. See the + individual driver documentation for details as to the + stability of the different parameters. + + /sys/module/MODULENAME/refcnt + If the module is able to be unloaded from the kernel, this file + will contain the current reference count of the module. + + Note: If the module is built into the kernel, or if the + CONFIG_MODULE_UNLOAD kernel configuration value is not enabled, + this file will not be present. diff --git a/Documentation/ABI/testing/sysfs-class b/Documentation/ABI/testing/sysfs-class new file mode 100644 index 00000000000..4b0cb891e46 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class @@ -0,0 +1,16 @@ +What: /sys/class/ +Date: Febuary 2006 +Contact: Greg Kroah-Hartman <gregkh@suse.de> +Description: + The /sys/class directory will consist of a group of + subdirectories describing individual classes of devices + in the kernel. The individual directories will consist + of either subdirectories, or symlinks to other + directories. + + All programs that use this directory tree must be able + to handle both subdirectories or symlinks in order to + work properly. + +Users: + udev <linux-hotplug-devel@lists.sourceforge.net> diff --git a/Documentation/ABI/testing/sysfs-devices b/Documentation/ABI/testing/sysfs-devices new file mode 100644 index 00000000000..6a25671ee5f --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices @@ -0,0 +1,25 @@ +What: /sys/devices +Date: February 2006 +Contact: Greg Kroah-Hartman <gregkh@suse.de> +Description: + The /sys/devices tree contains a snapshot of the + internal state of the kernel device tree. Devices will + be added and removed dynamically as the machine runs, + and between different kernel versions, the layout of the + devices within this tree will change. + + Please do not rely on the format of this tree because of + this. If a program wishes to find different things in + the tree, please use the /sys/class structure and rely + on the symlinks there to point to the proper location + within the /sys/devices tree of the individual devices. + Or rely on the uevent messages to notify programs of + devices being added and removed from this tree to find + the location of those devices. + + Note that sometimes not all devices along the directory + chain will have emitted uevent messages, so userspace + programs must be able to handle such occurrences. + +Users: + udev <linux-hotplug-devel@lists.sourceforge.net> diff --git a/Documentation/arm/Sharp-LH/ADC-LH7-Touchscreen b/Documentation/arm/Sharp-LH/ADC-LH7-Touchscreen new file mode 100644 index 00000000000..1e6a23fdf2f --- /dev/null +++ b/Documentation/arm/Sharp-LH/ADC-LH7-Touchscreen @@ -0,0 +1,61 @@ +README on the ADC/Touchscreen Controller +======================================== + +The LH79524 and LH7A404 include a built-in Analog to Digital +controller (ADC) that is used to process input from a touchscreen. +The driver only implements a four-wire touch panel protocol. + +The touchscreen driver is maintenance free except for the pen-down or +touch threshold. Some resistive displays and board combinations may +require tuning of this threshold. The driver exposes some of it's +internal state in the sys filesystem. If the kernel is configured +with it, CONFIG_SYSFS, and sysfs is mounted at /sys, there will be a +directory + + /sys/devices/platform/adc-lh7.0 + +containing these files. + + -r--r--r-- 1 root root 4096 Jan 1 00:00 samples + -rw-r--r-- 1 root root 4096 Jan 1 00:00 threshold + -r--r--r-- 1 root root 4096 Jan 1 00:00 threshold_range + +The threshold is the current touch threshold. It defaults to 750 on +most targets. + + # cat threshold + 750 + +The threshold_range contains the range of valid values for the +threshold. Values outside of this range will be silently ignored. + + # cat threshold_range + 0 1023 + +To change the threshold, write a value to the threshold file. + + # echo 500 > threshold + # cat threshold + 500 + +The samples file contains the most recently sampled values from the +ADC. There are 12. Below are typical of the last sampled values when +the pen has been released. The first two and last two samples are for +detecting whether or not the pen is down. The third through sixth are +X coordinate samples. The seventh through tenth are Y coordinate +samples. + + # cat samples + 1023 1023 0 0 0 0 530 529 530 529 1023 1023 + +To determine a reasonable threshold, press on the touch panel with an +appropriate stylus and read the values from samples. + + # cat samples + 1023 676 92 103 101 102 855 919 922 922 1023 679 + +The first and eleventh samples are discarded. Thus, the important +values are the second and twelfth which are used to determine if the +pen is down. When both are below the threshold, the driver registers +that the pen is down. When either is above the threshold, it +registers then pen is up. diff --git a/Documentation/arm/Sharp-LH/LCDPanels b/Documentation/arm/Sharp-LH/LCDPanels new file mode 100644 index 00000000000..fb1b21c2f2f --- /dev/null +++ b/Documentation/arm/Sharp-LH/LCDPanels @@ -0,0 +1,59 @@ +README on the LCD Panels +======================== + +Configuration options for several LCD panels, available from Logic PD, +are included in the kernel source. This README will help you +understand the configuration data and give you some guidance for +adding support for other panels if you wish. + + +lcd-panels.h +------------ + +There is no way, at present, to detect which panel is attached to the +system at runtime. Thus the kernel configuration is static. The file +arch/arm/mach-ld7a40x/lcd-panels.h (or similar) defines all of the +panel specific parameters. + +It should be possible for this data to be shared among several device +families. The current layout may be insufficiently general, but it is +amenable to improvement. + + +PIXEL_CLOCK +----------- + +The panel data sheets will give a range of acceptable pixel clocks. +The fundamental LCDCLK input frequency is divided down by a PCD +constant in field '.tim2'. It may happen that it is impossible to set +the pixel clock within this range. A clock which is too slow will +tend to flicker. For the highest quality image, set the clock as high +as possible. + + +MARGINS +------- + +These values may be difficult to glean from the panel data sheet. In +the case of the Sharp panels, the upper margin is explicitly called +out as a specific number of lines from the top of the frame. The +other values may not matter as much as the panels tend to +automatically center the image. + + +Sync Sense +---------- + +The sense of the hsync and vsync pulses may be called out in the data +sheet. On one panel, the sense of these pulses determine the height +of the visible region on the panel. Most of the Sharp panels use +negative sense sync pulses set by the TIM2_IHS and TIM2_IVS bits in +'.tim2'. + + +Pel Layout +---------- + +The Sharp color TFT panels are all configured for 16 bit direct color +modes. The amba-lcd driver sets the pel mode to 565 for 5 bits of +each red and blue and 6 bits of green. diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index f50cf8fac3f..f7293297f32 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -49,11 +49,11 @@ Who: Paul E. McKenney <paulmck@us.ibm.com> --------------------------- What: raw1394: requests of type RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN -When: November 2005 +When: November 2006 Why: Deprecated in favour of the new ioctl-based rawiso interface, which is more efficient. You should really be using libraw1394 for raw1394 access anyway. -Who: Jody McIntyre <scjody@steamballoon.com> +Who: Jody McIntyre <scjody@modernduck.com> --------------------------- diff --git a/Documentation/filesystems/inotify.txt b/Documentation/filesystems/inotify.txt index 6d501903f68..59a919f1614 100644 --- a/Documentation/filesystems/inotify.txt +++ b/Documentation/filesystems/inotify.txt @@ -69,17 +69,135 @@ Prototypes: int inotify_rm_watch (int fd, __u32 mask); -(iii) Internal Kernel Implementation +(iii) Kernel Interface -Each inotify instance is associated with an inotify_device structure. +Inotify's kernel API consists a set of functions for managing watches and an +event callback. + +To use the kernel API, you must first initialize an inotify instance with a set +of inotify_operations. You are given an opaque inotify_handle, which you use +for any further calls to inotify. + + struct inotify_handle *ih = inotify_init(my_event_handler); + +You must provide a function for processing events and a function for destroying +the inotify watch. + + void handle_event(struct inotify_watch *watch, u32 wd, u32 mask, + u32 cookie, const char *name, struct inode *inode) + + watch - the pointer to the inotify_watch that triggered this call + wd - the watch descriptor + mask - describes the event that occurred + cookie - an identifier for synchronizing events + name - the dentry name for affected files in a directory-based event + inode - the affected inode in a directory-based event + + void destroy_watch(struct inotify_watch *watch) + +You may add watches by providing a pre-allocated and initialized inotify_watch +structure and specifying the inode to watch along with an inotify event mask. +You must pin the inode during the call. You will likely wish to embed the +inotify_watch structure in a structure of your own which contains other +information about the watch. Once you add an inotify watch, it is immediately +subject to removal depending on filesystem events. You must grab a reference if +you depend on the watch hanging around after the call. + + inotify_init_watch(&my_watch->iwatch); + inotify_get_watch(&my_watch->iwatch); // optional + s32 wd = inotify_add_watch(ih, &my_watch->iwatch, inode, mask); + inotify_put_watch(&my_watch->iwatch); // optional + +You may use the watch descriptor (wd) or the address of the inotify_watch for +other inotify operations. You must not directly read or manipulate data in the +inotify_watch. Additionally, you must not call inotify_add_watch() more than +once for a given inotify_watch structure, unless you have first called either +inotify_rm_watch() or inotify_rm_wd(). + +To determine if you have already registered a watch for a given inode, you may +call inotify_find_watch(), which gives you both the wd and the watch pointer for +the inotify_watch, or an error if the watch does not exist. + + wd = inotify_find_watch(ih, inode, &watchp); + +You may use container_of() on the watch pointer to access your own data +associated with a given watch. When an existing watch is found, +inotify_find_watch() bumps the refcount before releasing its locks. You must +put that reference with: + + put_inotify_watch(watchp); + +Call inotify_find_update_watch() to update the event mask for an existing watch. +inotify_find_update_watch() returns the wd of the updated watch, or an error if +the watch does not exist. + + wd = inotify_find_update_watch(ih, inode, mask); + +An existing watch may be removed by calling either inotify_rm_watch() or +inotify_rm_wd(). + + int ret = inotify_rm_watch(ih, &my_watch->iwatch); + int ret = inotify_rm_wd(ih, wd); + +A watch may be removed while executing your event handler with the following: + + inotify_remove_watch_locked(ih, iwatch); + +Call inotify_destroy() to remove all watches from your inotify instance and +release it. If there are no outstanding references, inotify_destroy() will call +your destroy_watch op for each watch. + + inotify_destroy(ih); + +When inotify removes a watch, it sends an IN_IGNORED event to your callback. +You may use this event as an indication to free the watch memory. Note that +inotify may remove a watch due to filesystem events, as well as by your request. +If you use IN_ONESHOT, inotify will remove the watch after the first event, at +which point you may call the final inotify_put_watch. + +(iv) Kernel Interface Prototypes + + struct inotify_handle *inotify_init(struct inotify_operations *ops); + + inotify_init_watch(struct inotify_watch *watch); + + s32 inotify_add_watch(struct inotify_handle *ih, + struct inotify_watch *watch, + struct inode *inode, u32 mask); + + s32 inotify_find_watch(struct inotify_handle *ih, struct inode *inode, + struct inotify_watch **watchp); + + s32 inotify_find_update_watch(struct inotify_handle *ih, + struct inode *inode, u32 mask); + + int inotify_rm_wd(struct inotify_handle *ih, u32 wd); + + int inotify_rm_watch(struct inotify_handle *ih, + struct inotify_watch *watch); + + void inotify_remove_watch_locked(struct inotify_handle *ih, + struct inotify_watch *watch); + + void inotify_destroy(struct inotify_handle *ih); + + void get_inotify_watch(struct inotify_watch *watch); + void put_inotify_watch(struct inotify_watch *watch); + + +(v) Internal Kernel Implementation + +Each inotify instance is represented by an inotify_handle structure. +Inotify's userspace consumers also have an inotify_device which is +associated with the inotify_handle, and on which events are queued. Each watch is associated with an inotify_watch structure. Watches are chained -off of each associated device and each associated inode. +off of each associated inotify_handle and each associated inode. -See fs/inotify.c for the locking and lifetime rules. +See fs/inotify.c and fs/inotify_user.c for the locking and lifetime rules. -(iv) Rationale +(vi) Rationale Q: What is the design decision behind not tying the watch to the open fd of the watched object? @@ -145,7 +263,7 @@ A: The poor user-space interface is the second biggest problem with dnotify. file descriptor-based one that allows basic file I/O and poll/select. Obtaining the fd and managing the watches could have been done either via a device file or a family of new system calls. We decided to implement a - family of system calls because that is the preffered approach for new kernel + family of system calls because that is the preferred approach for new kernel interfaces. The only real difference was whether we wanted to use open(2) and ioctl(2) or a couple of new system calls. System calls beat ioctls. diff --git a/Documentation/isdn/README.gigaset b/Documentation/isdn/README.gigaset index 85a64defd38..fa0d4cca964 100644 --- a/Documentation/isdn/README.gigaset +++ b/Documentation/isdn/README.gigaset @@ -124,7 +124,8 @@ GigaSet 307x Device Driver You can use some configuration tool of your distribution to configure this "modem" or configure pppd/wvdial manually. There are some example ppp - configuration files and chat scripts in the gigaset-VERSION/ppp directory. + configuration files and chat scripts in the gigaset-VERSION/ppp directory + in the driver packages from http://sourceforge.net/projects/gigaset307x/. Please note that the USB drivers are not able to change the state of the control lines (the M105 driver can be configured to use some undocumented control requests, if you really need the control lines, though). This means @@ -164,8 +165,8 @@ GigaSet 307x Device Driver If you want both of these at once, you are out of luck. - You can also use /sys/module/<name>/parameters/cidmode for changing - the CID mode setting (<name> is usb_gigaset or bas_gigaset). + You can also use /sys/class/tty/ttyGxy/cidmode for changing the CID mode + setting (ttyGxy is ttyGU0 or ttyGB0). 3. Troubleshooting diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt index f987afe43e2..fba1e05c47c 100644 --- a/Documentation/power/devices.txt +++ b/Documentation/power/devices.txt @@ -135,96 +135,6 @@ HW. FREEZE -- stop DMA and interrupts, and be prepared to reinit HW from scratch. That probably means stop accepting upstream requests, the -actual policy of what to do with them beeing specific to a given -driver. It's acceptable for a network driver to just drop packets -while a block driver is expected to block the queue so no request is -lost. (Use IDE as an example on how to do that). FREEZE requires no -power state change, and it's expected for drivers to be able to -quickly transition back to operating state. - -SUSPEND -- like FREEZE, but also put hardware into low-power state. If -there's need to distinguish several levels of sleep, additional flag -is probably best way to do that. - -Transitions are only from a resumed state to a suspended state, never -between 2 suspended states. (ON -> FREEZE or ON -> SUSPEND can happen, -FREEZE -> SUSPEND or SUSPEND -> FREEZE can not). - -All events are: - -[NOTE NOTE NOTE: If you are driver author, you should not care; you -should only look at event, and ignore flags.] - -#Prepare for suspend -- userland is still running but we are going to -#enter suspend state. This gives drivers chance to load firmware from -#disk and store it in memory, or do other activities taht require -#operating userland, ability to kmalloc GFP_KERNEL, etc... All of these -#are forbiden once the suspend dance is started.. event = ON, flags = -#PREPARE_TO_SUSPEND - -Apm standby -- prepare for APM event. Quiesce devices to make life -easier for APM BIOS. event = FREEZE, flags = APM_STANDBY - -Apm suspend -- same as APM_STANDBY, but it we should probably avoid -spinning down disks. event = FREEZE, flags = APM_SUSPEND - -System halt, reboot -- quiesce devices to make life easier for BIOS. event -= FREEZE, flags = SYSTEM_HALT or SYSTEM_REBOOT - -System shutdown -- at least disks need to be spun down, or data may be -lost. Quiesce devices, just to make life easier for BIOS. event = -FREEZE, flags = SYSTEM_SHUTDOWN - -Kexec -- turn off DMAs and put hardware into some state where new -kernel can take over. event = FREEZE, flags = KEXEC - -Powerdown at end of swsusp -- very similar to SYSTEM_SHUTDOWN, except wake -may need to be enabled on some devices. This actually has at least 3 -subtypes, system can reboot, enter S4 and enter S5 at the end of -swsusp. event = FREEZE, flags = SWSUSP and one of SYSTEM_REBOOT, -SYSTEM_SHUTDOWN, SYSTEM_S4 - -Suspend to ram -- put devices into low power state. event = SUSPEND, -flags = SUSPEND_TO_RAM - -Freeze for swsusp snapshot -- stop DMA and interrupts. No need to put -devices into low power mode, but you must be able to reinitialize -device from scratch in resume method. This has two flavors, its done -once on suspending kernel, once on resuming kernel. event = FREEZE, -flags = DURING_SUSPEND or DURING_RESUME - -Device detach requested from /sys -- deinitialize device; proably same as -SYSTEM_SHUTDOWN, I do not understand this one too much. probably event -= FREEZE, flags = DEV_DETACH. - -#These are not really events sent: -# -#System fully on -- device is working normally; this is probably never -#passed to suspend() method... event = ON, flags = 0 -# -#Ready after resume -- userland is now running, again. Time to free any -#memory you ate during prepare to suspend... event = ON, flags = -#READY_AFTER_RESUME -# - - -pm_message_t meaning - -pm_message_t has two fields. event ("major"), and flags. If driver -does not know event code, it aborts the request, returning error. Some -drivers may need to deal with special cases based on the actual type -of suspend operation being done at the system level. This is why -there are flags. - -Event codes are: - -ON -- no need to do anything except special cases like broken -HW. - -# NOTIFICATION -- pretty much same as ON? - -FREEZE -- stop DMA and interrupts, and be prepared to reinit HW from -scratch. That probably means stop accepting upstream requests, the actual policy of what to do with them being specific to a given driver. It's acceptable for a network driver to just drop packets while a block driver is expected to block the queue so no request is diff --git a/Documentation/power/swsusp.txt b/Documentation/power/swsusp.txt index d7814a113ee..516c5019013 100644 --- a/Documentation/power/swsusp.txt +++ b/Documentation/power/swsusp.txt @@ -18,10 +18,11 @@ Some warnings, first. * * (*) suspend/resume support is needed to make it safe. * - * If you have any filesystems on USB devices mounted before suspend, + * If you have any filesystems on USB devices mounted before software suspend, * they won't be accessible after resume and you may lose data, as though - * you have unplugged the USB devices with mounted filesystems on them - * (see the FAQ below for details). + * you have unplugged the USB devices with mounted filesystems on them; + * see the FAQ below for details. (This is not true for more traditional + * power states like "standby", which normally don't turn USB off.) You need to append resume=/dev/your_swap_partition to kernel command line. Then you suspend by @@ -204,7 +205,7 @@ Q: There don't seem to be any generally useful behavioral distinctions between SUSPEND and FREEZE. A: Doing SUSPEND when you are asked to do FREEZE is always correct, -but it may be unneccessarily slow. If you want USB to stay simple, +but it may be unneccessarily slow. If you want your driver to stay simple, slowness may not matter to you. It can always be fixed later. For devices like disk it does matter, you do not want to spindown for @@ -357,17 +358,25 @@ Q: Is this true that if I have a mounted filesystem on a USB device and I suspend to disk, I can lose data unless the filesystem has been mounted with "sync"? -A: That's right. It depends on your hardware, and it could be true even for -suspend-to-RAM. In fact, even with "-o sync" you can lose data if your -programs have information in buffers they haven't written out to disk. +A: That's right ... if you disconnect that device, you may lose data. +In fact, even with "-o sync" you can lose data if your programs have +information in buffers they haven't written out to a disk you disconnect, +or if you disconnect before the device finished saving data you wrote. -If you're lucky, your hardware will support low-power modes for USB -controllers while the system is asleep. Lots of hardware doesn't, -however. Shutting off the power to a USB controller is equivalent to -unplugging all the attached devices. +Software suspend normally powers down USB controllers, which is equivalent +to disconnecting all USB devices attached to your system. + +Your system might well support low-power modes for its USB controllers +while the system is asleep, maintaining the connection, using true sleep +modes like "suspend-to-RAM" or "standby". (Don't write "disk" to the +/sys/power/state file; write "standby" or "mem".) We've not seen any +hardware that can use these modes through software suspend, although in +theory some systems might support "platform" or "firmware" modes that +won't break the USB connections. Remember that it's always a bad idea to unplug a disk drive containing a -mounted filesystem. With USB that's true even when your system is asleep! -The safest thing is to unmount all USB-based filesystems before suspending -and remount them after resuming. +mounted filesystem. That's true even when your system is asleep! The +safest thing is to unmount all filesystems on removable media (such USB, +Firewire, CompactFlash, MMC, external SATA, or even IDE hotplug bays) +before suspending; then remount them after resuming. diff --git a/Documentation/scsi/00-INDEX b/Documentation/scsi/00-INDEX index e7da8c3a255..12354830c6b 100644 --- a/Documentation/scsi/00-INDEX +++ b/Documentation/scsi/00-INDEX @@ -30,8 +30,6 @@ aic7xxx.txt - info on driver for Adaptec controllers aic7xxx_old.txt - info on driver for Adaptec controllers, old generation -cpqfc.txt - - info on driver for Compaq Tachyon TS adapters dpti.txt - info on driver for DPT SmartRAID and Adaptec I2O RAID based adapters dtc3x80.txt diff --git a/Documentation/scsi/ChangeLog.megaraid_sas b/Documentation/scsi/ChangeLog.megaraid_sas index 2dafa63bd37..0a85a7e8120 100644 --- a/Documentation/scsi/ChangeLog.megaraid_sas +++ b/Documentation/scsi/ChangeLog.megaraid_sas @@ -1,3 +1,16 @@ + +1 Release Date : Wed Feb 03 14:31:44 PST 2006 - Sumant Patro <Sumant.Patro@lsil.com> +2 Current Version : 00.00.02.04 +3 Older Version : 00.00.02.04 + +i. Remove superflous instance_lock + + gets rid of the otherwise superflous instance_lock and avoids an unsave + unsynchronized access in the error handler. + + - Christoph Hellwig <hch@lst.de> + + 1 Release Date : Wed Feb 03 14:31:44 PST 2006 - Sumant Patro <Sumant.Patro@lsil.com> 2 Current Version : 00.00.02.04 3 Older Version : 00.00.02.04 diff --git a/Documentation/scsi/aacraid.txt b/Documentation/scsi/aacraid.txt index 820fd079350..be55670851a 100644 --- a/Documentation/scsi/aacraid.txt +++ b/Documentation/scsi/aacraid.txt @@ -24,10 +24,10 @@ Supported Cards/Chipsets 9005:0285:9005:0296 Adaptec 2240S (SabreExpress) 9005:0285:9005:0290 Adaptec 2410SA (Jaguar) 9005:0285:9005:0293 Adaptec 21610SA (Corsair-16) - 9005:0285:103c:3227 Adaptec 2610SA (Bearcat) + 9005:0285:103c:3227 Adaptec 2610SA (Bearcat HP release) 9005:0285:9005:0292 Adaptec 2810SA (Corsair-8) 9005:0285:9005:0294 Adaptec Prowler - 9005:0286:9005:029d Adaptec 2420SA (Intruder) + 9005:0286:9005:029d Adaptec 2420SA (Intruder HP release) 9005:0286:9005:029c Adaptec 2620SA (Intruder) 9005:0286:9005:029b Adaptec 2820SA (Intruder) 9005:0286:9005:02a7 Adaptec 2830SA (Skyray) @@ -38,7 +38,7 @@ Supported Cards/Chipsets 9005:0285:9005:0297 Adaptec 4005SAS (AvonPark) 9005:0285:9005:0299 Adaptec 4800SAS (Marauder-X) 9005:0285:9005:029a Adaptec 4805SAS (Marauder-E) - 9005:0286:9005:02a2 Adaptec 4810SAS (Hurricane) + 9005:0286:9005:02a2 Adaptec 3800SAS (Hurricane44) 1011:0046:9005:0364 Adaptec 5400S (Mustang) 1011:0046:9005:0365 Adaptec 5400S (Mustang) 9005:0283:9005:0283 Adaptec Catapult (3210S with arc firmware) @@ -72,7 +72,7 @@ Supported Cards/Chipsets 9005:0286:9005:02a1 ICP ICP9087MA (Lancer) 9005:0286:9005:02a4 ICP ICP9085LI (Marauder-X) 9005:0286:9005:02a5 ICP ICP5085BR (Marauder-E) - 9005:0286:9005:02a3 ICP ICP5085AU (Hurricane) + 9005:0286:9005:02a3 ICP ICP5445AU (Hurricane44) 9005:0286:9005:02a6 ICP ICP9067MA (Intruder-6) 9005:0286:9005:02a9 ICP ICP5087AU (Skyray) 9005:0286:9005:02aa ICP ICP5047AU (Skyray) diff --git a/Documentation/scsi/cpqfc.txt b/Documentation/scsi/cpqfc.txt deleted file mode 100644 index dd33e61c064..00000000000 --- a/Documentation/scsi/cpqfc.txt +++ /dev/null @@ -1,272 +0,0 @@ -Notes for CPQFCTS driver for Compaq Tachyon TS -Fibre Channel Host Bus Adapter, PCI 64-bit, 66MHz -for Linux (RH 6.1, 6.2 kernel 2.2.12-32, 2.2.14-5) -SMP tested -Tested in single and dual HBA configuration, 32 and 64bit busses, -33 and 66MHz. Only supports FC-AL. -SEST size 512 Exchanges (simultaneous I/Os) limited by module kmalloc() - max of 128k bytes contiguous. - -Ver 2.5.4 Oct 03, 2002 - * fixed memcpy of sense buffer in ioctl to copy the smaller defined size -Ver 2.5.3 Aug 01, 2002 - * fix the passthru ioctl to handle the Scsi_Cmnd->request being a pointer -Ver 2.5.1 Jul 30, 2002 - * fix ioctl to pay attention to the specified LUN. -Ver 2.5.0 Nov 29, 2001 - * eliminated io_request_lock. This change makes the driver specific - to the 2.5.x kernels. - * silenced excessively noisy printks. - -Ver 2.1.2 July 23, 2002 - * initialize DumCmnd->lun in cpqfcTS_ioctl (used in fcFindLoggedInPorts as LUN index) - -Ver 2.1.1 Oct 18, 2001 - * reinitialize Cmnd->SCp.sent_command (used to identify commands as - passthrus) on calling scsi_done, since the scsi mid layer does not - use (or reinitialize) this field to prevent subsequent comands from - having it set incorrectly. - -Ver 2.1.0 Aug 27, 2001 - * Revise driver to use new kernel 2.4.x PCI DMA API, instead of - virt_to_bus(). (enables driver to work w/ ia64 systems with >2Gb RAM.) - Rework main scatter-gather code to handle cases where SG element - lengths are larger than 0x7FFFF bytes and use as many scatter - gather pages as necessary. (Steve Cameron) - * Makefile changes to bring cpqfc into line w/ rest of SCSI drivers - (thanks to Keith Owens) - -Ver 2.0.5 Aug 06, 2001 - * Reject non-existent luns in the driver rather than letting the - hardware do it. (some HW behaves differently than others in this area.) - * Changed Makefile to rely on "make dep" instead of explicit dependencies - * ifdef'ed out fibre channel analyzer triggering debug code - * fixed a jiffies wrapping issue - -Ver 2.0.4 Aug 01, 2001 - * Incorporated fix for target device reset from Steeleye - * Fixed passthrough ioctl so it doesn't hang. - * Fixed hang in launch_FCworker_thread() that occurred on some machines. - * Avoid problem when number of volumes in a single cabinet > 8 - -Ver 2.0.2 July 23, 2001 - Changed the semiphore changes so the driver would compile in 2.4.7. - This version is for 2.4.7 and beyond. - -Ver 2.0.1 May 7, 2001 - Merged version 1.3.6 fixes into version 2.0.0. - -Ver 2.0.0 May 7, 2001 - Fixed problem so spinlock is being initialized to UNLOCKED. - Fixed updated driver so it compiles in the 2.4 tree. - - Ver 1.3.6 Feb 27, 2001 - Added Target_Device_Reset function for SCSI error handling - Fixed problem with not reseting addressing mode after implicit logout - - -Ver 1.3.4 Sep 7, 2000 - Added Modinfo information - Fixed problem with statically linking the driver - -Ver 1.3.3, Aug 23, 2000 - Fixed device/function number in ioctl - -Ver 1.3.2, July 27, 2000 - Add include for Alpha compile on 2.2.14 kernel (cpq*i2c.c) - Change logic for different FCP-RSP sense_buffer location for HSG80 target - And search for Agilent Tachyon XL2 HBAs (not finished! - in test) - -Tested with -(storage): - Compaq RA-4x000, RAID firmware ver 2.40 - 2.54 - Seagate FC drives model ST39102FC, rev 0006 - Hitachi DK31CJ-72FC rev J8A8 - IBM DDYF-T18350R rev F60K - Compaq FC-SCSI bridge w/ DLT 35/70 Gb DLT (tape) -(servers): - Compaq PL-1850R - Compaq PL-6500 Xeon (400MHz) - Compaq PL-8500 (500MHz, 66MHz, 64bit PCI) - Compaq Alpha DS20 (RH 6.1) -(hubs): - Vixel Rapport 1000 (7-port "dumb") - Gadzoox Gibralter (12-port "dumb") - Gadzoox Capellix 2000, 3000 -(switches): - Brocade 2010, 2400, 2800, rev 2.0.3a (& later) - Gadzoox 3210 (Fabric blade beta) - Vixel 7100 (Fabric beta firmare - known hot plug issues) -using "qa_test" (esp. io_test script) suite modified from Unix tests. - -Installation: -make menuconfig - (select SCSI low-level, Compaq FC HBA) -make modules -make modules_install - -e.g. insmod -f cpqfc - -Due to Fabric/switch delays, driver requires 4 seconds -to initialize. If adapters are found, there will be a entries at -/proc/scsi/cpqfcTS/* - -sample contents of startup messages - -************************* - scsi_register allocating 3596 bytes for CPQFCHBA - ioremap'd Membase: c887e600 - HBA Tachyon RevId 1.2 -Allocating 119808 for 576 Exchanges @ c0dc0000 -Allocating 112904 for LinkQ @ c0c20000 (576 elements) -Allocating 110600 for TachSEST for 512 Exchanges - cpqfcTS: writing IMQ BASE 7C0000h PI 7C4000h - cpqfcTS: SEST c0e40000(virt): Wrote base E40000h @ c887e740 -cpqfcTS: New FC port 0000E8h WWN: 500507650642499D SCSI Chan/Trgt 0/0 -cpqfcTS: New FC port 0000EFh WWN: 50000E100000D5A6 SCSI Chan/Trgt 0/1 -cpqfcTS: New FC port 0000E4h WWN: 21000020370097BB SCSI Chan/Trgt 0/2 -cpqfcTS: New FC port 0000E2h WWN: 2100002037009946 SCSI Chan/Trgt 0/3 -cpqfcTS: New FC port 0000E1h WWN: 21000020370098FE SCSI Chan/Trgt 0/4 -cpqfcTS: New FC port 0000E0h WWN: 21000020370097B2 SCSI Chan/Trgt 0/5 -cpqfcTS: New FC port 0000DCh WWN: 2100002037006CC1 SCSI Chan/Trgt 0/6 -cpqfcTS: New FC port 0000DAh WWN: 21000020370059F6 SCSI Chan/Trgt 0/7 -cpqfcTS: New FC port 00000Fh WWN: 500805F1FADB0E20 SCSI Chan/Trgt 0/8 -cpqfcTS: New FC port 000008h WWN: 500805F1FADB0EBA SCSI Chan/Trgt 0/9 -cpqfcTS: New FC port 000004h WWN: 500805F1FADB1EB9 SCSI Chan/Trgt 0/10 -cpqfcTS: New FC port 000002h WWN: 500805F1FADB1ADE SCSI Chan/Trgt 0/11 -cpqfcTS: New FC port 000001h WWN: 500805F1FADBA2CA SCSI Chan/Trgt 0/12 -scsi4 : Compaq FibreChannel HBA Tachyon TS HPFC-5166A/1.2: WWN 500508B200193F50 - on PCI bus 0 device 0xa0fc irq 5 IObaseL 0x3400, MEMBASE 0xc6ef8600 -PCI bus width 32 bits, bus speed 33 MHz -FCP-SCSI Driver v1.3.0 -GBIC detected: Short-wave. LPSM 0h Monitor -scsi : 5 hosts. - Vendor: IBM Model: DDYF-T18350R Rev: F60K - Type: Direct-Access ANSI SCSI revision: 03 -Detected scsi disk sdb at scsi4, channel 0, id 0, lun 0 - Vendor: HITACHI Model: DK31CJ-72FC Rev: J8A8 - Type: Direct-Access ANSI SCSI revision: 02 -Detected scsi disk sdc at scsi4, channel 0, id 1, lun 0 - Vendor: SEAGATE Model: ST39102FC Rev: 0006 - Type: Direct-Access ANSI SCSI revision: 02 -Detected scsi disk sdd at scsi4, channel 0, id 2, lun 0 - Vendor: SEAGATE Model: ST39102FC Rev: 0006 - Type: Direct-Access ANSI SCSI revision: 02 -Detected scsi disk sde at scsi4, channel 0, id 3, lun 0 - Vendor: SEAGATE Model: ST39102FC Rev: 0006 - Type: Direct-Access ANSI SCSI revision: 02 -Detected scsi disk sdf at scsi4, channel 0, id 4, lun 0 - Vendor: SEAGATE Model: ST39102FC Rev: 0006 - Type: Direct-Access ANSI SCSI revision: 02 -Detected scsi disk sdg at scsi4, channel 0, id 5, lun 0 - Vendor: SEAGATE Model: ST39102FC Rev: 0006 - Type: Direct-Access ANSI SCSI revision: 02 -Detected scsi disk sdh at scsi4, channel 0, id 6, lun 0 - Vendor: SEAGATE Model: ST39102FC Rev: 0006 - Type: Direct-Access ANSI SCSI revision: 02 -Detected scsi disk sdi at scsi4, channel 0, id 7, lun 0 - Vendor: COMPAQ Model: LOGICAL VOLUME Rev: 2.48 - Type: Direct-Access ANSI SCSI revision: 02 -Detected scsi disk sdj at scsi4, channel 0, id 8, lun 0 - Vendor: COMPAQ Model: LOGICAL VOLUME Rev: 2.48 - Type: Direct-Access ANSI SCSI revision: 02 -Detected scsi disk sdk at scsi4, channel 0, id 8, lun 1 - Vendor: COMPAQ Model: LOGICAL VOLUME Rev: 2.40 - Type: Direct-Access ANSI SCSI revision: 02 -Detected scsi disk sdl at scsi4, channel 0, id 9, lun 0 - Vendor: COMPAQ Model: LOGICAL VOLUME Rev: 2.40 - Type: Direct-Access ANSI SCSI revision: 02 -Detected scsi disk sdm at scsi4, channel 0, id 9, lun 1 - Vendor: COMPAQ Model: LOGICAL VOLUME Rev: 2.54 - Type: Direct-Access ANSI SCSI revision: 02 -Detected scsi disk sdn at scsi4, channel 0, id 10, lun 0 - Vendor: COMPAQ Model: LOGICAL VOLUME Rev: 2.54 - Type: Direct-Access ANSI SCSI revision: 02 -Detected scsi disk sdo at scsi4, channel 0, id 11, lun 0 - Vendor: COMPAQ Model: LOGICAL VOLUME Rev: 2.54 - Type: Direct-Access ANSI SCSI revision: 02 -Detected scsi disk sdp at scsi4, channel 0, id 11, lun 1 - Vendor: COMPAQ Model: LOGICAL VOLUME Rev: 2.54 - Type: Direct-Access ANSI SCSI revision: 02 -Detected scsi disk sdq at scsi4, channel 0, id 12, lun 0 - Vendor: COMPAQ Model: LOGICAL VOLUME Rev: 2.54 - Type: Direct-Access ANSI SCSI revision: 02 -Detected scsi disk sdr at scsi4, channel 0, id 12, lun 1 -resize_dma_pool: unknown device type 12 -resize_dma_pool: unknown device type 12 -SCSI device sdb: hdwr sector= 512 bytes. Sectors= 35843670 [17501 MB] [17.5 GB] - sdb: sdb1 -SCSI device sdc: hdwr sector= 512 bytes. Sectors= 144410880 [70513 MB] [70.5 GB] - sdc: sdc1 -SCSI device sdd: hdwr sector= 512 bytes. Sectors= 17783240 [8683 MB] [8.7 GB] - sdd: sdd1 -SCSI device sde: hdwr sector= 512 bytes. Sectors= 17783240 [8683 MB] [8.7 GB] - sde: sde1 -SCSI device sdf: hdwr sector= 512 bytes. Sectors= 17783240 [8683 MB] [8.7 GB] - sdf: sdf1 -SCSI device sdg: hdwr sector= 512 bytes. Sectors= 17783240 [8683 MB] [8.7 GB] - sdg: sdg1 -SCSI device sdh: hdwr sector= 512 bytes. Sectors= 17783240 [8683 MB] [8.7 GB] - sdh: sdh1 -SCSI device sdi: hdwr sector= 512 bytes. Sectors= 17783240 [8683 MB] [8.7 GB] - sdi: sdi1 -SCSI device sdj: hdwr sector= 512 bytes. Sectors= 2056160 [1003 MB] [1.0 GB] - sdj: sdj1 -SCSI device sdk: hdwr sector= 512 bytes. Sectors= 2052736 [1002 MB] [1.0 GB] - sdk: sdk1 -SCSI device sdl: hdwr sector= 512 bytes. Sectors= 17764320 [8673 MB] [8.7 GB] - sdl: sdl1 -SCSI device sdm: hdwr sector= 512 bytes. Sectors= 8380320 [4091 MB] [4.1 GB] - sdm: sdm1 -SCSI device sdn: hdwr sector= 512 bytes. Sectors= 17764320 [8673 MB] [8.7 GB] - sdn: sdn1 -SCSI device sdo: hdwr sector= 512 bytes. Sectors= 17764320 [8673 MB] [8.7 GB] - sdo: sdo1 -SCSI device sdp: hdwr sector= 512 bytes. Sectors= 17764320 [8673 MB] [8.7 GB] - sdp: sdp1 -SCSI device sdq: hdwr sector= 512 bytes. Sectors= 2056160 [1003 MB] [1.0 GB] - sdq: sdq1 -SCSI device sdr: hdwr sector= 512 bytes. Sectors= 2052736 [1002 MB] [1.0 GB] - sdr: sdr1 - -************************* - -If a GBIC of type Short-wave, Long-wave, or Copper is detected, it will -print out; otherwise, "none" is displayed. If the cabling is correct -and a loop circuit is completed, you should see "Monitor"; otherwise, -"LoopFail" (on open circuit) or some LPSM number/state with bit 3 set. - - -ERRATA: -1. Normally, Linux Scsi queries FC devices with INQUIRY strings. All LUNs -found according to INQUIRY should get READ commands at sector 0 to find -partition table, etc. Older kernels only query the first 4 devices. Some -Linux kernels only look for one LUN per target (i.e. FC device). - -2. Physically removing a device, or a malfunctioning system which hides a -device, leads to a 30-second timeout and subsequent _abort call. -In some process contexts, this will hang the kernel (crashing the system). -Single bit errors in frames and virtually all hot plugging events are -gracefully handled with internal driver timer and Abort processing. - -3. Some SCSI drives with error conditions will not handle the 7 second timeout -in this software driver, leading to infinite retries on timed out SCSI commands. -The 7 secs balances the need to quickly recover from lost frames (esp. on sequence -initiatives) and time needed by older/slower/error-state drives in responding. -This can be easily changed in "Exchanges[].timeOut". - -4. Due to the nature of FC soft addressing, there is no assurance that the -same LUNs (drives) will have the same path (e.g. /dev/sdb1) from one boot to -next. Dynamic soft address changes (i.e. 24-bit FC port_id) are -supported during run time (e.g. due to hot plug event) by the use of WWN to -SCSI Nexus (channel/target/LUN) mapping. - -5. Compaq RA4x00 firmware version 2.54 and later supports SSP (Selective -Storage Presentation), which maps LUNs to a WWN. If RA4x00 firmware prior -2.54 (e.g. older controller) is used, or the FC HBA is replaced (another WWN -is used), logical volumes on the RA4x00 will no longer be visible. - - -Send questions/comments to: -Amy Vanzant-Hodge (fibrechannel@compaq.com) - diff --git a/Documentation/scsi/hptiop.txt b/Documentation/scsi/hptiop.txt new file mode 100644 index 00000000000..d28a31247d4 --- /dev/null +++ b/Documentation/scsi/hptiop.txt @@ -0,0 +1,92 @@ +HIGHPOINT ROCKETRAID 3xxx RAID DRIVER (hptiop) + +Controller Register Map +------------------------- + +The controller IOP is accessed via PCI BAR0. + + BAR0 offset Register + 0x10 Inbound Message Register 0 + 0x14 Inbound Message Register 1 + 0x18 Outbound Message Register 0 + 0x1C Outbound Message Register 1 + 0x20 Inbound Doorbell Register + 0x24 Inbound Interrupt Status Register + 0x28 Inbound Interrupt Mask Register + 0x30 Outbound Interrupt Status Register + 0x34 Outbound Interrupt Mask Register + 0x40 Inbound Queue Port + 0x44 Outbound Queue Port + + +I/O Request Workflow +---------------------- + +All queued requests are handled via inbound/outbound queue port. +A request packet can be allocated in either IOP or host memory. + +To send a request to the controller: + + - Get a free request packet by reading the inbound queue port or + allocate a free request in host DMA coherent memory. + + The value returned from the inbound queue port is an offset + relative to the IOP BAR0. + + Requests allocated in host memory must be aligned on 32-bytes boundary. + + - Fill the packet. + + - Post the packet to IOP by writing it to inbound queue. For requests + allocated in IOP memory, write the offset to inbound queue port. For + requests allocated in host memory, write (0x80000000|(bus_addr>>5)) + to the inbound queue port. + + - The IOP process the request. When the request is completed, it + will be put into outbound queue. An outbound interrupt will be + generated. + + For requests allocated in IOP memory, the request offset is posted to + outbound queue. + + For requests allocated in host memory, (0x80000000|(bus_addr>>5)) + is posted to the outbound queue. If IOP_REQUEST_FLAG_OUTPUT_CONTEXT + flag is set in the request, the low 32-bit context value will be + posted instead. + + - The host read the outbound queue and complete the request. + + For requests allocated in IOP memory, the host driver free the request + by writing it to the outbound queue. + +Non-queued requests (reset/flush etc) can be sent via inbound message +register 0. An outbound message with the same value indicates the completion +of an inbound message. + + +User-level Interface +--------------------- + +The driver exposes following sysfs attributes: + + NAME R/W Description + driver-version R driver version string + firmware-version R firmware version string + +The driver registers char device "hptiop" to communicate with HighPoint RAID +management software. Its ioctl routine acts as a general binary interface +between the IOP firmware and HighPoint RAID management software. New management +functions can be implemented in application/firmware without modification +in driver code. + + +----------------------------------------------------------------------------- +Copyright (C) 2006 HighPoint Technologies, Inc. All Rights Reserved. + + This file is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + linux@highpoint-tech.com + http://www.highpoint-tech.com diff --git a/Documentation/usb/usbmon.txt b/Documentation/usb/usbmon.txt index 63cb7edd177..e65ec828d7a 100644 --- a/Documentation/usb/usbmon.txt +++ b/Documentation/usb/usbmon.txt @@ -29,14 +29,13 @@ if usbmon is built into the kernel. # mount -t debugfs none_debugs /sys/kernel/debug # modprobe usbmon +# Verify that bus sockets are present. -[root@lembas zaitcev]# ls /sys/kernel/debug/usbmon +# ls /sys/kernel/debug/usbmon 1s 1t 2s 2t 3s 3t 4s 4t -[root@lembas zaitcev]# - -# ls /sys/kernel +# 2. Find which bus connects to the desired device @@ -76,7 +75,7 @@ that the file size is not excessive for your favourite editor. * Raw text data format -The '0t' type data consists of a stream of events, such as URB submission, +The '1t' type data consists of a stream of events, such as URB submission, URB callback, submission error. Every event is a text line, which consists of whitespace separated words. The number of position of words may depend on the event type, but there is a set of words, common for all types. @@ -97,20 +96,25 @@ Here is the list of words, from left to right: Zi Zo Isochronous input and output Ii Io Interrupt input and output Bi Bo Bulk input and output - Device address and Endpoint number are decimal numbers with leading zeroes - or 3 and 2 positions, correspondingly. -- URB Status. This field makes no sense for submissions, but is present - to help scripts with parsing. In error case, it contains the error code. - In case of a setup packet, it contains a Setup Tag. If scripts read a number - in this field, they proceed to read Data Length. Otherwise, they read - the setup packet before reading the Data Length. + Device address and Endpoint number are 3-digit and 2-digit (respectively) + decimal numbers, with leading zeroes. +- URB Status. In most cases, this field contains a number, sometimes negative, + which represents a "status" field of the URB. This field makes no sense for + submissions, but is present anyway to help scripts with parsing. When an + error occurs, the field contains the error code. In case of a submission of + a Control packet, this field contains a Setup Tag instead of an error code. + It is easy to tell whether the Setup Tag is present because it is never a + number. Thus if scripts find a number in this field, they proceed to read + Data Length. If they find something else, like a letter, they read the setup + packet before reading the Data Length. - Setup packet, if present, consists of 5 words: one of each for bmRequestType, bRequest, wValue, wIndex, wLength, as specified by the USB Specification 2.0. These words are safe to decode if Setup Tag was 's'. Otherwise, the setup packet was present, but not captured, and the fields contain filler. -- Data Length. This is the actual length in the URB. +- Data Length. For submissions, this is the requested length. For callbacks, + this is the actual length. - Data tag. The usbmon may not always capture data, even if length is nonzero. - Only if tag is '=', the data words are present. + The data words are present only if this tag is '='. - Data words follow, in big endian hexadecimal format. Notice that they are not machine words, but really just a byte stream split into words to make it easier to read. Thus, the last word may contain from one to four bytes. |