From 7301c8d3a05dc52d33598364da7c4eb6ab6357eb Mon Sep 17 00:00:00 2001 From: Jody McIntyre Date: Fri, 18 Nov 2005 00:16:26 -0500 Subject: Remove amdtp, cmp drivers. Remove the Audio and Music Data Transmission Protocol driver and the Connection Management Procedures driver. These are incomplete, have never worked, and are better implemented in userland via raw1394 (see http://freebob.sourceforge.net/ for example.) Signed-off-by: Jody McIntyre Cc: Adrian Bunk --- Documentation/feature-removal-schedule.txt | 11 ----------- 1 file changed, 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index b67189a8d8d..daaf03eaea6 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -40,17 +40,6 @@ Who: Paul E. McKenney --------------------------- -What: IEEE1394 Audio and Music Data Transmission Protocol driver, - Connection Management Procedures driver -When: November 2005 -Files: drivers/ieee1394/{amdtp,cmp}* -Why: These are incomplete, have never worked, and are better implemented - in userland via raw1394 (see http://freebob.sourceforge.net/ for - example.) -Who: Jody McIntyre - ---------------------------- - What: raw1394: requests of type RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN When: November 2005 Why: Deprecated in favour of the new ioctl-based rawiso interface, which is -- cgit v1.2.3 From 7f7f53168dbee6d6a462acea666fddd18aad4f08 Mon Sep 17 00:00:00 2001 From: Andy Fleming Date: Fri, 11 Nov 2005 12:38:59 -0600 Subject: [PATCH] Gianfar update and sysfs support This seems to have gotten lost, so I'll resend. Signed-off-by: Andy Fleming * Added sysfs support to gianfar for modifying FIFO and stashing parameters * Updated driver to support 10 Mbit, full duplex operation * Improved comments throughout * Cleaned up and optimized offloading code * Fixed a bug where rx buffers were being improperly mapped and unmapped * (only manifested if cache-coherency was off) * Added support for using the eTSEC exact-match MAC registers * Bumped the version to 1.3 * Added support for distinguishing between reduced 100 and 10 Mbit modes * Modified default coalescing values to lower latency * Added documentation Signed-off-by: Jeff Garzik --- Documentation/networking/gianfar.txt | 72 ++++++++++++++++++++++++++++++++++++ 1 file changed, 72 insertions(+) create mode 100644 Documentation/networking/gianfar.txt (limited to 'Documentation') diff --git a/Documentation/networking/gianfar.txt b/Documentation/networking/gianfar.txt new file mode 100644 index 00000000000..ad474ea07d0 --- /dev/null +++ b/Documentation/networking/gianfar.txt @@ -0,0 +1,72 @@ +The Gianfar Ethernet Driver +Sysfs File description + +Author: Andy Fleming +Updated: 2005-07-28 + +SYSFS + +Several of the features of the gianfar driver are controlled +through sysfs files. These are: + +bd_stash: +To stash RX Buffer Descriptors in the L2, echo 'on' or '1' to +bd_stash, echo 'off' or '0' to disable + +rx_stash_len: +To stash the first n bytes of the packet in L2, echo the number +of bytes to buf_stash_len. echo 0 to disable. + +WARNING: You could really screw these up if you set them too low or high! +fifo_threshold: +To change the number of bytes the controller needs in the +fifo before it starts transmission, echo the number of bytes to +fifo_thresh. Range should be 0-511. + +fifo_starve: +When the FIFO has less than this many bytes during a transmit, it +enters starve mode, and increases the priority of TX memory +transactions. To change, echo the number of bytes to +fifo_starve. Range should be 0-511. + +fifo_starve_off: +Once in starve mode, the FIFO remains there until it has this +many bytes. To change, echo the number of bytes to +fifo_starve_off. Range should be 0-511. + +CHECKSUM OFFLOADING + +The eTSEC controller (first included in parts from late 2005 like +the 8548) has the ability to perform TCP, UDP, and IP checksums +in hardware. The Linux kernel only offloads the TCP and UDP +checksums (and always performs the pseudo header checksums), so +the driver only supports checksumming for TCP/IP and UDP/IP +packets. Use ethtool to enable or disable this feature for RX +and TX. + +VLAN + +In order to use VLAN, please consult Linux documentation on +configuring VLANs. The gianfar driver supports hardware insertion and +extraction of VLAN headers, but not filtering. Filtering will be +done by the kernel. + +MULTICASTING + +The gianfar driver supports using the group hash table on the +TSEC (and the extended hash table on the eTSEC) for multicast +filtering. On the eTSEC, the exact-match MAC registers are used +before the hash tables. See Linux documentation on how to join +multicast groups. + +PADDING + +The gianfar driver supports padding received frames with 2 bytes +to align the IP header to a 16-byte boundary, when supported by +hardware. + +ETHTOOL + +The gianfar driver supports the use of ethtool for many +configuration options. You must run ethtool only on currently +open interfaces. See ethtool documentation for details. -- cgit v1.2.3 From 537208c8072280ab87916710d5a3f7ef11ab94ff Mon Sep 17 00:00:00 2001 From: Alexander Clouter Date: Thu, 1 Dec 2005 01:09:23 -0800 Subject: [PATCH] cpufreq: documentation for 'ondemand' and 'conservative' Added a more verbose entry for the 'ondemend' governor and an entry for the 'conservative' governor to the documentation. Signed-off-by: Alexander Clouter Signed-off-by: Andrew Morton Signed-off-by: Dave Jones --- Documentation/cpu-freq/governors.txt | 62 ++++++++++++++++++++++++++++++++++-- 1 file changed, 59 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cpu-freq/governors.txt b/Documentation/cpu-freq/governors.txt index 933fae74c33..f4b8dc4237e 100644 --- a/Documentation/cpu-freq/governors.txt +++ b/Documentation/cpu-freq/governors.txt @@ -27,6 +27,7 @@ Contents: 2.2 Powersave 2.3 Userspace 2.4 Ondemand +2.5 Conservative 3. The Governor Interface in the CPUfreq Core @@ -110,9 +111,64 @@ directory. The CPUfreq govenor "ondemand" sets the CPU depending on the current usage. To do this the CPU must have the capability to -switch the frequency very fast. - - +switch the frequency very quickly. There are a number of sysfs file +accessible parameters: + +sampling_rate: measured in uS (10^-6 seconds), this is how often you +want the kernel to look at the CPU usage and to make decisions on +what to do about the frequency. Typically this is set to values of +around '10000' or more. + +show_sampling_rate_(min|max): the minimum and maximum sampling rates +available that you may set 'sampling_rate' to. + +up_threshold: defines what the average CPU usaged between the samplings +of 'sampling_rate' needs to be for the kernel to make a decision on +whether it should increase the frequency. For example when it is set +to its default value of '80' it means that between the checking +intervals the CPU needs to be on average more than 80% in use to then +decide that the CPU frequency needs to be increased. + +sampling_down_factor: this parameter controls the rate that the CPU +makes a decision on when to decrease the frequency. When set to its +default value of '5' it means that at 1/5 the sampling_rate the kernel +makes a decision to lower the frequency. Five "lower rate" decisions +have to be made in a row before the CPU frequency is actually lower. +If set to '1' then the frequency decreases as quickly as it increases, +if set to '2' it decreases at half the rate of the increase. + +ignore_nice_load: this parameter takes a value of '0' or '1', when set +to '0' (its default) then all processes are counted towards towards the +'cpu utilisation' value. When set to '1' then processes that are +run with a 'nice' value will not count (and thus be ignored) in the +overal usage calculation. This is useful if you are running a CPU +intensive calculation on your laptop that you do not care how long it +takes to complete as you can 'nice' it and prevent it from taking part +in the deciding process of whether to increase your CPU frequency. + + +2.5 Conservative +---------------- + +The CPUfreq governor "conservative", much like the "ondemand" +governor, sets the CPU depending on the current usage. It differs in +behaviour in that it gracefully increases and decreases the CPU speed +rather than jumping to max speed the moment there is any load on the +CPU. This behaviour more suitable in a battery powered environment. +The governor is tweaked in the same manner as the "ondemand" governor +through sysfs with the addition of: + +freq_step: this describes what percentage steps the cpu freq should be +increased and decreased smoothly by. By default the cpu frequency will +increase in 5% chunks of your maximum cpu frequency. You can change this +value to anywhere between 0 and 100 where '0' will effectively lock your +CPU at a speed regardless of its load whilst '100' will, in theory, make +it behave identically to the "ondemand" governor. + +down_threshold: same as the 'up_threshold' found for the "ondemand" +governor but for the opposite direction. For example when set to its +default value of '20' it means that if the CPU usage needs to be below +20% between samples to have the frequency decreased. 3. The Governor Interface in the CPUfreq Core ============================================= -- cgit v1.2.3 From 2bd0fa3b62e8565a80f9535e0f2bd51bba46213f Mon Sep 17 00:00:00 2001 From: Jesse Barnes Date: Tue, 13 Dec 2005 03:05:03 -0500 Subject: [PATCH] add boot option to control Intel SATA/PATA combined mode Combined mode sucks. Especially when both libata and the legacy IDE drivers try to drive ports on the same device, since that makes DMA rather difficult. This patch addresses the problem by allowing the user to control which driver binds to the ports in a combined mode configuration. In many cases, they'll probably want the libata driver to control both ports since it can use DMA for talking with ATAPI devices (when libata.atapi_enabled=1 of course). It also allows the user to get old school behavior by letting the legacy IDE driver bind to both ports. But neither is forced, the patch doesn't change current behavior unless one of combined_mode=ide or combined_mode=libata is passed on the boot line. Either of those options may require you to access your devices via different device nodes (/dev/hd* in the ide case and /dev/sd* in the libata case), though of course if you have udev installed nicely you may not notice anything. :) Let me know if the documentation is too cryptic, I'd be happy to expand on it if necessary. I think most users will want to boot with 'combined_mode=libata' and add 'options libata atapi_enabled=1' to their modules.conf to get good DVD playing and disk behavior (haven't tested CD or DVD writing though). I'd much rather things behave sanely by default (i.e. DMA for devices on both ports), but apparently that's difficult given the various chip bugs and hardware configs out there (not to mention that people's drives may suddenly change from /dev/hdc to /dev/sdb), so this boot option may be the correct long term fix. Signed-off-by: Jesse Barnes Signed-off-by: Jeff Garzik --- Documentation/kernel-parameters.txt | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 5dffcfefc3c..61a56b100c6 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -633,6 +633,14 @@ running once the system is up. inport.irq= [HW] Inport (ATI XL and Microsoft) busmouse driver Format: + combined_mode= [HW] control which driver uses IDE ports in combined + mode: legacy IDE driver, libata, or both + (in the libata case, libata.atapi_enabled=1 may be + useful as well). Note that using the ide or libata + options may affect your device naming (e.g. by + changing hdc to sdb). + Format: combined (default), ide, or libata + inttest= [IA64] io7= [HW] IO7 for Marvel based alpha systems -- cgit v1.2.3 From ed7e8ef7f12f5c3c8bbb85eeb0a1ded91c7c5dbf Mon Sep 17 00:00:00 2001 From: "Ju, Seokmann" Date: Thu, 17 Nov 2005 13:17:25 -0500 Subject: [SCSI] megaraid_{mbox,mm} : remove PCI Id overlaping between megaraid_legacy and megaraid_{mbox,mm} Signed-off-by: James Bottomley --- Documentation/scsi/ChangeLog.megaraid | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) (limited to 'Documentation') diff --git a/Documentation/scsi/ChangeLog.megaraid b/Documentation/scsi/ChangeLog.megaraid index 5331d91432c..09f6300eda4 100644 --- a/Documentation/scsi/ChangeLog.megaraid +++ b/Documentation/scsi/ChangeLog.megaraid @@ -1,3 +1,38 @@ +Release Date : Fri Nov 11 12:27:22 EST 2005 - Seokmann Ju +Current Version : 2.20.4.7 (scsi module), 2.20.2.6 (cmm module) +Older Version : 2.20.4.6 (scsi module), 2.20.2.6 (cmm module) + +1. Sorted out PCI IDs to remove megaraid support overlaps. + Based on the patch from Daniel, sorted out PCI IDs along with + charactor node name change from 'megadev' to 'megadev_legacy' to avoid + conflict. + --- + Hopefully we'll be getting the build restriction zapped much sooner, + but we should also be thinking about totally removing the hardware + support overlap in the megaraid drivers. + + This patch pencils in a date of Feb 06 for this, and performs some + printk abuse in hope that existing legacy users might pick up on what's + going on. + + Signed-off-by: Daniel Drake + --- + +2. Fixed a issue: megaraid always fails to reset handler. + --- + I found that the megaraid driver always fails to reset the + adapter with the following message: + megaraid: resetting the host... + megaraid mbox: reset sequence completed successfully + megaraid: fast sync command timed out + megaraid: reservation reset failed + when the "Cluster mode" of the adapter BIOS is enabled. + So, whenever the reset occurs, the adapter goes to + offline and just become unavailable. + + Jun'ichi Nomura [mailto:jnomura@mtc.biglobe.ne.jp] + --- + Release Date : Mon Mar 07 12:27:22 EST 2005 - Seokmann Ju Current Version : 2.20.4.6 (scsi module), 2.20.2.6 (cmm module) Older Version : 2.20.4.5 (scsi module), 2.20.2.5 (cmm module) -- cgit v1.2.3 From dc25fcfbba513f8de8d1531b47fc9daa33d84f5a Mon Sep 17 00:00:00 2001 From: Matthew Wilcox Date: Thu, 10 Nov 2005 07:45:55 -0700 Subject: [SCSI] Mention scsi_scan_host() in scsi_mid_low_api.txt Update to mention scsi_scan_host() Signed-off-by: Matthew Wilcox Signed-off-by: James Bottomley --- Documentation/scsi/scsi_mid_low_api.txt | 37 +++++++++++++++++++++++++-------- 1 file changed, 28 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/scsi/scsi_mid_low_api.txt b/Documentation/scsi/scsi_mid_low_api.txt index 66565d42288..c4af92bc705 100644 --- a/Documentation/scsi/scsi_mid_low_api.txt +++ b/Documentation/scsi/scsi_mid_low_api.txt @@ -150,7 +150,8 @@ scsi devices of which only the first 2 respond: LLD mid level LLD ===-------------------=========--------------------===------ scsi_host_alloc() --> -scsi_add_host() --------+ +scsi_add_host() ----> +scsi_scan_host() -------+ | slave_alloc() slave_configure() --> scsi_adjust_queue_depth() @@ -196,7 +197,7 @@ of the issues involved. See the section on reference counting below. The hotplug concept may be extended to SCSI devices. Currently, when an -HBA is added, the scsi_add_host() function causes a scan for SCSI devices +HBA is added, the scsi_scan_host() function causes a scan for SCSI devices attached to the HBA's SCSI transport. On newer SCSI transports the HBA may become aware of a new SCSI device _after_ the scan has completed. An LLD can use this sequence to make the mid level aware of a SCSI device: @@ -372,7 +373,7 @@ names all start with "scsi_". Summary: scsi_activate_tcq - turn on tag command queueing scsi_add_device - creates new scsi device (lu) instance - scsi_add_host - perform sysfs registration and SCSI bus scan. + scsi_add_host - perform sysfs registration and set up transport class scsi_adjust_queue_depth - change the queue depth on a SCSI device scsi_assign_lock - replace default host_lock with given lock scsi_bios_ptable - return copy of block device's partition table @@ -386,6 +387,7 @@ Summary: scsi_remove_device - detach and remove a SCSI device scsi_remove_host - detach and remove all SCSI devices owned by host scsi_report_bus_reset - report scsi _bus_ reset observed + scsi_scan_host - scan SCSI bus scsi_track_queue_full - track successive QUEUE_FULL events scsi_unblock_requests - allow further commands to be queued to given host scsi_unregister - [calls scsi_host_put()] @@ -425,10 +427,10 @@ void scsi_activate_tcq(struct scsi_device *sdev, int depth) * Might block: yes * * Notes: This call is usually performed internally during a scsi - * bus scan when an HBA is added (i.e. scsi_add_host()). So it + * bus scan when an HBA is added (i.e. scsi_scan_host()). So it * should only be called if the HBA becomes aware of a new scsi - * device (lu) after scsi_add_host() has completed. If successful - * this call we lead to slave_alloc() and slave_configure() callbacks + * device (lu) after scsi_scan_host() has completed. If successful + * this call can lead to slave_alloc() and slave_configure() callbacks * into the LLD. * * Defined in: drivers/scsi/scsi_scan.c @@ -439,7 +441,7 @@ struct scsi_device * scsi_add_device(struct Scsi_Host *shost, /** - * scsi_add_host - perform sysfs registration and SCSI bus scan. + * scsi_add_host - perform sysfs registration and set up transport class * @shost: pointer to scsi host instance * @dev: pointer to struct device of type scsi class * @@ -448,7 +450,11 @@ struct scsi_device * scsi_add_device(struct Scsi_Host *shost, * Might block: no * * Notes: Only required in "hotplug initialization model" after a - * successful call to scsi_host_alloc(). + * successful call to scsi_host_alloc(). This function does not + * scan the bus; this can be done by calling scsi_scan_host() or + * in some other transport-specific way. The LLD must set up + * the transport template before calling this function and may only + * access the transport class data after this function has been called. * * Defined in: drivers/scsi/hosts.c **/ @@ -559,7 +565,7 @@ void scsi_deactivate_tcq(struct scsi_device *sdev, int depth) * area for the LLD's exclusive use. * Both associated refcounting objects have their refcount set to 1. * Full registration (in sysfs) and a bus scan are performed later when - * scsi_add_host() is called. + * scsi_add_host() and scsi_scan_host() are called. * * Defined in: drivers/scsi/hosts.c . **/ @@ -698,6 +704,19 @@ int scsi_remove_host(struct Scsi_Host *shost) void scsi_report_bus_reset(struct Scsi_Host * shost, int channel) +/** + * scsi_scan_host - scan SCSI bus + * @shost: a pointer to a scsi host instance + * + * Might block: yes + * + * Notes: Should be called after scsi_add_host() + * + * Defined in: drivers/scsi/scsi_scan.c + **/ +void scsi_scan_host(struct Scsi_Host *shost) + + /** * scsi_track_queue_full - track successive QUEUE_FULL events on given * device to determine if and when there is a need -- cgit v1.2.3 From 98a1e444111c9fd3f7a2b55225f7febf4209c020 Mon Sep 17 00:00:00 2001 From: Brian Strand Date: Tue, 22 Nov 2005 01:23:08 +0000 Subject: kbuild: patch to Documentation/kbuild/modules.txt First off, thanks for the kbuild docs, they are very useful! Second, I've attached a patch to modules.txt (from 2.6.14.2) with a "compile" fix to a Makefile example, and some trivial spelling/grammar nits. Please let me know if you want the patch in some other format (eg not MIME), or if I should go bother someone else about it. Signed-off-by: Sam Ravnborg --- Documentation/kbuild/modules.txt | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kbuild/modules.txt b/Documentation/kbuild/modules.txt index c91caf7eb30..1c0db652b36 100644 --- a/Documentation/kbuild/modules.txt +++ b/Documentation/kbuild/modules.txt @@ -38,7 +38,7 @@ included in the kernel tree. What is covered within this file is mainly information to authors of modules. The author of an external modules should supply a makefile that hides most of the complexity so one only has to type -'make' to buld the module. A complete example will be present in +'make' to build the module. A complete example will be present in chapter ¤. Creating a kbuild file for an external module". @@ -69,7 +69,7 @@ when building an external module. --- 2.2 Available targets - $KDIR refers to path to kernel source top-level directory + $KDIR refers to the path to the kernel source top-level directory make -C $KDIR M=`pwd` Will build the module(s) located in current directory. @@ -87,11 +87,11 @@ when building an external module. make -C $KDIR M=$PWD modules_install Install the external module(s). Installation default is in /lib/modules//extra, - but may be prefixed with INSTALL_MOD_PATH - see separate chater. + but may be prefixed with INSTALL_MOD_PATH - see separate chapter. make -C $KDIR M=$PWD clean Remove all generated files for the module - the kernel - source directory is not moddified. + source directory is not modified. make -C $KDIR M=`pwd` help help will list the available target when building external @@ -99,7 +99,7 @@ when building an external module. --- 2.3 Available options: - $KDIR refer to path to kernel src + $KDIR refers to the path to the kernel source top-level directory make -C $KDIR Used to specify where to find the kernel source. @@ -206,11 +206,11 @@ following files: KERNELDIR := /lib/modules/`uname -r`/build all:: - $(MAKE) -C $KERNELDIR M=`pwd` $@ + $(MAKE) -C $(KERNELDIR) M=`pwd` $@ # Module specific targets genbin: - echo "X" > 8123_bini.o_shipped + echo "X" > 8123_bin.o_shipped endif @@ -341,13 +341,13 @@ directory and therefore needs to deal with this in their kbuild file. EXTRA_CFLAGS := -Iinclude 8123-y := 8123_if.o 8123_pci.o 8123_bin.o - Note that in the assingment there is no space between -I and the path. - This is a kbuild limitation and no space must be present. + Note that in the assignment there is no space between -I and the path. + This is a kbuild limitation: there must be no space present. === 6. Module installation -Modules which are included in the kernel is installed in the directory: +Modules which are included in the kernel are installed in the directory: /lib/modules/$(KERNELRELEASE)/kernel @@ -365,7 +365,7 @@ External modules are installed in the directory: => Install dir: /frodo/lib/modules/$(KERNELRELEASE)/kernel INSTALL_MOD_PATH may be set as an ordinary shell variable or as in the - example above be specified on the commandline when calling make. + example above be specified on the command line when calling make. INSTALL_MOD_PATH has effect both when installing modules included in the kernel as well as when installing external modules. @@ -384,7 +384,7 @@ External modules are installed in the directory: === 7. Module versioning -Module versioning are enabled by the CONFIG_MODVERSIONS tag. +Module versioning is enabled by the CONFIG_MODVERSIONS tag. Module versioning is used as a simple ABI consistency check. The Module versioning creates a CRC value of the full prototype for an exported symbol and -- cgit v1.2.3 From 3e8731740e17f01ec1ecce556ccdc4c42279ce1b Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Thu, 17 Nov 2005 10:15:37 +0100 Subject: [ALSA] Minor clean up and fixes for CS5535 audio driver Modules: Documentation,CS5535 driver Minor clean up and fixes for CS5535 audio driver. Added an entry in ALSA-Configuration.txt, too. Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/ALSA-Configuration.txt | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt index 2f27f391c7c..23d1870d522 100644 --- a/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/Documentation/sound/alsa/ALSA-Configuration.txt @@ -410,6 +410,13 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. The power-management is supported. + Module snd-cs5535audio + ---------------------- + + Module for multifunction CS5535 companion PCI device + + Module supports up to 8 cards. + Module snd-dt019x ----------------- -- cgit v1.2.3 From 10e4097fb47b57d095204d3fad10b25e3b4d42a3 Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Thu, 17 Nov 2005 11:04:55 +0100 Subject: [ALSA] [Trivial] Fix ac97_quirk option in document Modules: Documentation Fix a wrong option value for ac97_quirk option in the document. Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/ALSA-Configuration.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt index 23d1870d522..84068baf587 100644 --- a/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/Documentation/sound/alsa/ALSA-Configuration.txt @@ -1481,7 +1481,7 @@ the proper value with this option. The following strings are accepted: - default Don't override the default setting - - disable Disable the quirk + - none Disable the quirk - hp_only Bind Master and Headphone controls as a single control - swap_hp Swap headphone and master controls - swap_surround Swap master and surround controls -- cgit v1.2.3 From 59de641ca37b88dd34d0e1d853800b488f642624 Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Thu, 17 Nov 2005 11:05:34 +0100 Subject: [ALSA] Small update of Procfile.txt Modules: Documentation Small update of Procfile.txt for hda and usb proc files. Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/Procfile.txt | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/Procfile.txt b/Documentation/sound/alsa/Procfile.txt index 25c5d648aef..1fe48846d78 100644 --- a/Documentation/sound/alsa/Procfile.txt +++ b/Documentation/sound/alsa/Procfile.txt @@ -138,6 +138,22 @@ card*/codec97#0/ac97#?-?+regs # echo 02 9f1f > /proc/asound/card0/codec97#0/ac97#0-0+regs +USB Audio Streams +----------------- + +card*/stream* + Shows the assignment and the current status of each audio stream + of the given card. This information is very useful for debugging. + + +HD-Audio Codecs +--------------- + +card*/codec#* + Shows the general codec information and the attribute of each + widget node. + + Sequencer Information --------------------- -- cgit v1.2.3 From 446ab5f5039df4209a2e28752bd48c99007d3d82 Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Thu, 17 Nov 2005 15:12:54 +0100 Subject: [ALSA] Remove xxx_t typedefs: Documentation Modules: Documentation Remove xxx_t typedefs from documentation. Signed-off-by: Takashi Iwai --- .../sound/alsa/DocBook/writing-an-alsa-driver.tmpl | 419 ++++++++++----------- Documentation/sound/alsa/hda_codec.txt | 14 +- 2 files changed, 214 insertions(+), 219 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl b/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl index 260334c98d9..f2e59fe802b 100644 --- a/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl +++ b/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl @@ -403,9 +403,8 @@ static int enable[SNDRV_CARDS] = SNDRV_DEFAULT_ENABLE_PNP; /* definition of the chip-specific record */ - typedef struct snd_mychip mychip_t; - struct snd_mychip { - snd_card_t *card; + struct mychip { + struct snd_card *card; // rest of implementation will be in the section // "PCI Resource Managements" }; @@ -413,7 +412,7 @@ /* chip-specific destructor * (see "PCI Resource Managements") */ - static int snd_mychip_free(mychip_t *chip) + static int snd_mychip_free(struct mychip *chip) { .... // will be implemented later... } @@ -421,22 +420,21 @@ /* component-destructor * (see "Management of Cards and Components") */ - static int snd_mychip_dev_free(snd_device_t *device) + static int snd_mychip_dev_free(struct snd_device *device) { - mychip_t *chip = device->device_data; - return snd_mychip_free(chip); + return snd_mychip_free(device->device_data); } /* chip-specific constructor * (see "Management of Cards and Components") */ - static int __devinit snd_mychip_create(snd_card_t *card, + static int __devinit snd_mychip_create(struct snd_card *card, struct pci_dev *pci, - mychip_t **rchip) + struct mychip **rchip) { - mychip_t *chip; + struct mychip *chip; int err; - static snd_device_ops_t ops = { + static struct snd_device_ops ops = { .dev_free = snd_mychip_dev_free, }; @@ -474,8 +472,8 @@ const struct pci_device_id *pci_id) { static int dev; - snd_card_t *card; - mychip_t *chip; + struct snd_card *card; + struct mychip *chip; int err; /* (1) */ @@ -582,7 +580,7 @@ @@ -605,7 +603,7 @@ @@ -830,7 +828,7 @@ After the card is created, you can attach the components (devices) to the card instance. On ALSA driver, a component is - represented as a snd_device_t object. + represented as a struct snd_device object. A component can be a PCM instance, a control interface, a raw MIDI interface, etc. Each of such instances has one component entry. @@ -891,14 +889,11 @@ The chip-specific information, e.g. the i/o port address, its resource pointer, or the irq number, is stored in the chip-specific record. - Usually, the chip-specific record is typedef'ed as - xxx_t like the following: @@ -918,12 +913,12 @@ - whether mychip_t is the type of the chip record. + whether struct mychip is the type of the chip record. @@ -932,7 +927,7 @@ private_data; + struct mychip *chip = (struct mychip *)card->private_data; ]]> @@ -954,8 +949,8 @@ @@ -1000,7 +995,7 @@ device_data; - return snd_mychip_free(chip); + return snd_mychip_free(device->device_data); } ]]> @@ -1087,15 +1081,15 @@ PCI Resource Managements Example port = pci_resource_start(pci, 0); if (request_irq(pci->irq, snd_mychip_interrupt, - SA_INTERRUPT|SA_SHIRQ, "My Chip", - (void *)chip)) { + SA_INTERRUPT|SA_SHIRQ, "My Chip", chip)) { printk(KERN_ERR "cannot grab irq %d\n", pci->irq); snd_mychip_free(chip); return -EBUSY; @@ -1268,14 +1261,14 @@ Now assume that this PCI device has an I/O port with 8 bytes - and an interrupt. Then mychip_t will have the + and an interrupt. Then struct mychip will have the following fields: irq, snd_mychip_interrupt, - SA_INTERRUPT|SA_SHIRQ, "My Chip", - (void *)chip)) { + SA_INTERRUPT|SA_SHIRQ, "My Chip", chip)) { printk(KERN_ERR "cannot grab irq %d\n", pci->irq); snd_mychip_free(chip); return -EBUSY; @@ -1372,7 +1364,7 @@ static irqreturn_t snd_mychip_interrupt(int irq, void *dev_id, struct pt_regs *regs) { - mychip_t *chip = dev_id; + struct mychip *chip = dev_id; .... return IRQ_HANDLED; } @@ -1487,7 +1479,7 @@ iobase_virt) @@ -1537,7 +1529,7 @@ Registration of Device Struct At some point, typically after calling snd_device_new(), - you need to register the struct device of the chip + you need to register the struct device of the chip you're handling for udev and co. ALSA provides a macro for compatibility with older kernels. Simply call like the following: @@ -1739,7 +1731,7 @@ .... /* hardware definition */ - static snd_pcm_hardware_t snd_mychip_playback_hw = { + static struct snd_pcm_hardware snd_mychip_playback_hw = { .info = (SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER | @@ -1758,7 +1750,7 @@ }; /* hardware definition */ - static snd_pcm_hardware_t snd_mychip_capture_hw = { + static struct snd_pcm_hardware snd_mychip_capture_hw = { .info = (SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER | @@ -1777,10 +1769,10 @@ }; /* open callback */ - static int snd_mychip_playback_open(snd_pcm_substream_t *substream) + static int snd_mychip_playback_open(struct snd_pcm_substream *substream) { - mychip_t *chip = snd_pcm_substream_chip(substream); - snd_pcm_runtime_t *runtime = substream->runtime; + struct mychip *chip = snd_pcm_substream_chip(substream); + struct snd_pcm_runtime *runtime = substream->runtime; runtime->hw = snd_mychip_playback_hw; // more hardware-initialization will be done here @@ -1788,19 +1780,19 @@ } /* close callback */ - static int snd_mychip_playback_close(snd_pcm_substream_t *substream) + static int snd_mychip_playback_close(struct snd_pcm_substream *substream) { - mychip_t *chip = snd_pcm_substream_chip(substream); + struct mychip *chip = snd_pcm_substream_chip(substream); // the hardware-specific codes will be here return 0; } /* open callback */ - static int snd_mychip_capture_open(snd_pcm_substream_t *substream) + static int snd_mychip_capture_open(struct snd_pcm_substream *substream) { - mychip_t *chip = snd_pcm_substream_chip(substream); - snd_pcm_runtime_t *runtime = substream->runtime; + struct mychip *chip = snd_pcm_substream_chip(substream); + struct snd_pcm_runtime *runtime = substream->runtime; runtime->hw = snd_mychip_capture_hw; // more hardware-initialization will be done here @@ -1808,33 +1800,33 @@ } /* close callback */ - static int snd_mychip_capture_close(snd_pcm_substream_t *substream) + static int snd_mychip_capture_close(struct snd_pcm_substream *substream) { - mychip_t *chip = snd_pcm_substream_chip(substream); + struct mychip *chip = snd_pcm_substream_chip(substream); // the hardware-specific codes will be here return 0; } /* hw_params callback */ - static int snd_mychip_pcm_hw_params(snd_pcm_substream_t *substream, - snd_pcm_hw_params_t * hw_params) + static int snd_mychip_pcm_hw_params(struct snd_pcm_substream *substream, + struct snd_pcm_hw_params *hw_params) { return snd_pcm_lib_malloc_pages(substream, params_buffer_bytes(hw_params)); } /* hw_free callback */ - static int snd_mychip_pcm_hw_free(snd_pcm_substream_t *substream) + static int snd_mychip_pcm_hw_free(struct snd_pcm_substream *substream) { return snd_pcm_lib_free_pages(substream); } /* prepare callback */ - static int snd_mychip_pcm_prepare(snd_pcm_substream_t *substream) + static int snd_mychip_pcm_prepare(struct snd_pcm_substream *substream) { - mychip_t *chip = snd_pcm_substream_chip(substream); - snd_pcm_runtime_t *runtime = substream->runtime; + struct mychip *chip = snd_pcm_substream_chip(substream); + struct snd_pcm_runtime *runtime = substream->runtime; /* set up the hardware with the current configuration * for example... @@ -1849,7 +1841,7 @@ } /* trigger callback */ - static int snd_mychip_pcm_trigger(snd_pcm_substream_t *substream, + static int snd_mychip_pcm_trigger(struct snd_pcm_substream *substream, int cmd) { switch (cmd) { @@ -1866,9 +1858,9 @@ /* pointer callback */ static snd_pcm_uframes_t - snd_mychip_pcm_pointer(snd_pcm_substream_t *substream) + snd_mychip_pcm_pointer(struct snd_pcm_substream *substream) { - mychip_t *chip = snd_pcm_substream_chip(substream); + struct mychip *chip = snd_pcm_substream_chip(substream); unsigned int current_ptr; /* get the current hardware pointer */ @@ -1877,7 +1869,7 @@ } /* operators */ - static snd_pcm_ops_t snd_mychip_playback_ops = { + static struct snd_pcm_ops snd_mychip_playback_ops = { .open = snd_mychip_playback_open, .close = snd_mychip_playback_close, .ioctl = snd_pcm_lib_ioctl, @@ -1889,7 +1881,7 @@ }; /* operators */ - static snd_pcm_ops_t snd_mychip_capture_ops = { + static struct snd_pcm_ops snd_mychip_capture_ops = { .open = snd_mychip_capture_open, .close = snd_mychip_capture_close, .ioctl = snd_pcm_lib_ioctl, @@ -1905,9 +1897,9 @@ */ /* create a pcm device */ - static int __devinit snd_mychip_new_pcm(mychip_t *chip) + static int __devinit snd_mychip_new_pcm(struct mychip *chip) { - snd_pcm_t *pcm; + struct snd_pcm *pcm; int err; if ((err = snd_pcm_new(chip->card, "My Chip", 0, 1, 1, @@ -1944,9 +1936,9 @@ card, "My Chip", 0, 1, 1, @@ -1989,13 +1981,13 @@ specify more numbers, but they must be handled properly in open/close, etc. callbacks. When you need to know which substream you are referring to, then it can be obtained from - snd_pcm_substream_t data passed to each callback + struct snd_pcm_substream data passed to each callback as follows: number; ]]> @@ -2024,7 +2016,7 @@ PCM Instance with a Destructor my_private_pcm_data); // do what you like else .... } - static int __devinit snd_mychip_new_pcm(mychip_t *chip) + static int __devinit snd_mychip_new_pcm(struct mychip *chip) { - snd_pcm_t *pcm; + struct snd_pcm *pcm; .... /* allocate your own data */ chip->my_private_pcm_data = kmalloc(...); @@ -2149,7 +2141,7 @@ @@ -2252,7 +2244,7 @@ struct _snd_pcm_runtime {
Hardware Description - The hardware descriptor (snd_pcm_hardware_t) + The hardware descriptor (struct snd_pcm_hardware) contains the definitions of the fundamental hardware configuration. Above all, you'll need to define this in @@ -2267,7 +2259,7 @@ struct _snd_pcm_runtime { runtime; + struct snd_pcm_runtime *runtime = substream->runtime; ... runtime->hw = snd_mychip_playback_hw; /* common definition */ if (chip->model == VERY_OLD_ONE) @@ -2282,7 +2274,7 @@ struct _snd_pcm_runtime { Running Status The running status can be referred via runtime->status. - This is the pointer to snd_pcm_mmap_status_t + This is the pointer to struct snd_pcm_mmap_status record. For example, you can get the current DMA hardware pointer via runtime->status->hw_ptr. @@ -2520,7 +2512,7 @@ struct _snd_pcm_runtime { The DMA application pointer can be referred via runtime->control, which points - snd_pcm_mmap_control_t record. + struct snd_pcm_mmap_control record. However, accessing directly to this value is not recommended.
@@ -2542,9 +2534,9 @@ struct _snd_pcm_runtime { runtime->private_data = data; @@ -2586,7 +2578,7 @@ struct _snd_pcm_runtime { The callback function takes at least the argument with - snd_pcm_substream_t pointer. For retrieving the + snd_pcm_substream pointer. For retrieving the chip record from the given substream instance, you can use the following macro. @@ -2594,7 +2586,7 @@ struct _snd_pcm_runtime { @@ -2616,7 +2608,7 @@ struct _snd_pcm_runtime { @@ -2631,10 +2623,10 @@ struct _snd_pcm_runtime { runtime; + struct mychip *chip = snd_pcm_substream_chip(substream); + struct snd_pcm_runtime *runtime = substream->runtime; runtime->hw = snd_mychip_playback_hw; return 0; @@ -2667,7 +2659,7 @@ struct _snd_pcm_runtime { @@ -2682,7 +2674,7 @@ struct _snd_pcm_runtime { runtime->private_data); @@ -2709,8 +2701,8 @@ struct _snd_pcm_runtime { @@ -2785,7 +2777,7 @@ struct _snd_pcm_runtime { @@ -2820,7 +2812,7 @@ struct _snd_pcm_runtime { @@ -2869,7 +2861,7 @@ struct _snd_pcm_runtime { @@ -2939,7 +2931,7 @@ struct _snd_pcm_runtime { @@ -3067,7 +3059,7 @@ struct _snd_pcm_runtime { static irqreturn_t snd_mychip_interrupt(int irq, void *dev_id, struct pt_regs *regs) { - mychip_t *chip = dev_id; + struct mychip *chip = dev_id; spin_lock(&chip->lock); .... if (pcm_irq_invoked(chip)) { @@ -3111,7 +3103,7 @@ struct _snd_pcm_runtime { static irqreturn_t snd_mychip_interrupt(int irq, void *dev_id, struct pt_regs *regs) { - mychip_t *chip = dev_id; + struct mychip *chip = dev_id; spin_lock(&chip->lock); .... if (pcm_irq_invoked(chip)) { @@ -3221,13 +3213,13 @@ struct _snd_pcm_runtime { snd_pcm_hardware_t stucture (or in any + specified in the snd_pcm_hardware stucture (or in any other constraint_list). You can build a rule like this: Example of Hardware Constraints for Channels min < 2) { @@ -3298,12 +3291,13 @@ struct _snd_pcm_runtime { Example of Hardware Constraints for Channels bits[0] == SNDRV_PCM_FMTBIT_S16_LE) { @@ -3376,13 +3370,13 @@ struct _snd_pcm_runtime { callbacks: info, get and put. Then, define a - snd_kcontrol_new_t record, such as: + struct snd_kcontrol_new record, such as: Definition of a Control The info callback is used to get the detailed information of this control. This must store the - values of the given snd_ctl_elem_info_t + values of the given struct snd_ctl_elem_info object. For example, for a boolean control with a single element will be: @@ -3607,8 +3601,8 @@ struct _snd_pcm_runtime { Example of info callback type = SNDRV_CTL_ELEM_TYPE_BOOLEAN; uinfo->count = 1; @@ -3642,8 +3636,8 @@ struct _snd_pcm_runtime { Example of get callback value.integer.value[0] = get_some_value(chip); return 0; } @@ -3717,8 +3711,8 @@ struct _snd_pcm_runtime { private_value & 0xff; int shift = (kcontrol->private_value >> 16) & 0xff; @@ -3754,10 +3748,10 @@ struct _snd_pcm_runtime { Example of put callback current_value != ucontrol->value.integer.value[0]) { @@ -3814,7 +3808,7 @@ struct _snd_pcm_runtime { where my_control is the - snd_kcontrol_new_t object defined above, and chip + struct snd_kcontrol_new object defined above, and chip is the object pointer to be passed to kcontrol->private_data which can be referred in callbacks. @@ -3822,7 +3816,7 @@ struct _snd_pcm_runtime { snd_ctl_new1() allocates a new - snd_kcontrol_t instance (that's why the definition + snd_kcontrol instance (that's why the definition of my_control can be with __devinitdata prefix), and snd_ctl_add assigns the given @@ -3849,7 +3843,7 @@ struct _snd_pcm_runtime { control id pointer for the notification. The event-mask specifies the types of notification, for example, in the above example, the change of control values is notified. - The id pointer is the pointer of snd_ctl_elem_id_t + The id pointer is the pointer of struct snd_ctl_elem_id to be notified. You can find some examples in es1938.c or es1968.c for hardware volume interrupts. @@ -3882,35 +3876,35 @@ struct _snd_pcm_runtime { Example of AC97 Interface private_data; + struct mychip *chip = ac97->private_data; .... // read a register value here from the codec return the_register_value; } - static void snd_mychip_ac97_write(ac97_t *ac97, + static void snd_mychip_ac97_write(struct snd_ac97 *ac97, unsigned short reg, unsigned short val) { - mychip_t *chip = ac97->private_data; + struct mychip *chip = ac97->private_data; .... // write the given register value to the codec } - static int snd_mychip_ac97(mychip_t *chip) + static int snd_mychip_ac97(struct mychip *chip) { - ac97_bus_t *bus; - ac97_template_t ac97; + struct snd_ac97_bus *bus; + struct snd_ac97_template ac97; int err; - static ac97_bus_ops_t ops = { + static struct snd_ac97_bus_ops ops = { .write = snd_mychip_ac97_write, .read = snd_mychip_ac97_read, }; @@ -3937,8 +3931,8 @@ struct _snd_pcm_runtime { - And then call snd_ac97_mixer() with an ac97_template_t + And then call snd_ac97_mixer() with an + struct snd_ac97_template record together with the bus pointer created above. private_data; + struct mychip *chip = ac97->private_data; .... return the_register_value; } @@ -4016,7 +4011,7 @@ struct _snd_pcm_runtime { @@ -4163,7 +4158,7 @@ struct _snd_pcm_runtime { Multiple Codecs When there are several codecs on the same card, you need to - call snd_ac97_new() multiple times with + call snd_ac97_mixer() multiple times with ac97.num=1 or greater. The num field specifies the codec number. @@ -4212,7 +4207,7 @@ struct _snd_pcm_runtime { @@ -4253,17 +4248,17 @@ struct _snd_pcm_runtime { Usually, the port address corresponds to the command port and port + 1 corresponds to the data port. If not, you may change the cport field of - mpu401_t manually - afterward. However, mpu401_t pointer is not + struct snd_mpu401 manually + afterward. However, snd_mpu401 pointer is not returned explicitly by snd_mpu401_uart_new(). You need to cast rmidi->private_data to - mpu401_t explicitly, + snd_mpu401 explicitly, private_data; ]]> @@ -4359,7 +4354,7 @@ struct _snd_pcm_runtime { card, "MyMIDI", 0, outs, ins, &rmidi); if (err < 0) return err; @@ -4419,7 +4414,7 @@ struct _snd_pcm_runtime { streams[SNDRV_RAWMIDI_STREAM_OUTPUT].substreams) { - substream = list_entry(list, snd_rawmidi_substream_t, list); + substream = list_entry(list, struct snd_rawmidi_substream, list); sprintf(substream->name, "My MIDI Port %d", substream->number + 1); } /* same for SNDRV_RAWMIDI_STREAM_INPUT */ @@ -4463,12 +4458,12 @@ struct _snd_pcm_runtime { If there is more than one port, your callbacks can determine the - port index from the snd_rawmidi_substream_t data passed to each + port index from the struct snd_rawmidi_substream data passed to each callback: number; ]]> @@ -4481,7 +4476,7 @@ struct _snd_pcm_runtime { @@ -4499,7 +4494,7 @@ struct _snd_pcm_runtime { @@ -4522,7 +4517,7 @@ struct _snd_pcm_runtime { @@ -4547,7 +4542,7 @@ struct _snd_pcm_runtime { @@ -4603,7 +4598,7 @@ struct _snd_pcm_runtime { @@ -4647,7 +4642,7 @@ struct _snd_pcm_runtime { @@ -4661,7 +4656,7 @@ struct _snd_pcm_runtime { This callback is optional. If you do not set - drain in the snd_rawmidi_ops_t + drain in the struct snd_rawmidi_ops structure, ALSA will simply wait for 50 milliseconds instead. @@ -4703,7 +4698,7 @@ struct _snd_pcm_runtime { @@ -4736,7 +4731,7 @@ struct _snd_pcm_runtime { @@ -4767,7 +4762,7 @@ struct _snd_pcm_runtime { @@ -4804,7 +4799,7 @@ struct _snd_pcm_runtime { @@ -4823,7 +4818,7 @@ struct _snd_pcm_runtime { private_data = p; hw->private_free = mydata_free; ]]> @@ -4835,9 +4830,9 @@ struct _snd_pcm_runtime { private_data; + struct mydata *p = hw->private_data; kfree(p); } ]]> @@ -5061,9 +5056,9 @@ struct _snd_pcm_runtime { @@ -5144,7 +5139,7 @@ struct _snd_pcm_runtime { @@ -5211,7 +5206,7 @@ struct _snd_pcm_runtime { dma_private; + struct snd_sg_buf *sgbuf = (struct snd_sg_buf_t*)substream->dma_private; ]]> @@ -5266,7 +5261,7 @@ struct _snd_pcm_runtime { #include /* get the physical page pointer on the given offset */ - static struct page *mychip_page(snd_pcm_substream_t *substream, + static struct page *mychip_page(struct snd_pcm_substream *substream, unsigned long offset) { void *pageptr = substream->runtime->dma_area + offset; @@ -5301,7 +5296,7 @@ struct _snd_pcm_runtime { @@ -5345,8 +5340,8 @@ struct _snd_pcm_runtime { @@ -5361,10 +5356,10 @@ struct _snd_pcm_runtime { private_data; + struct my_chip *chip = entry->private_data; snd_iprintf(buffer, "This is my chip!\n"); snd_iprintf(buffer, "Port = %ld\n", chip->port); @@ -5453,7 +5448,7 @@ struct _snd_pcm_runtime { pm_private_data; + struct mychip *chip = card->pm_private_data; /* (2) */ snd_pcm_suspend_all(chip->pcm); /* (3) */ @@ -5570,10 +5565,10 @@ struct _snd_pcm_runtime { pm_private_data; + struct mychip *chip = card->pm_private_data; /* (2) */ pci_enable_device(chip->pci); /* (3) */ @@ -5602,8 +5597,8 @@ struct _snd_pcm_runtime { const struct pci_device_id *pci_id) { .... - snd_card_t *card; - mychip_t *chip; + struct snd_card *card; + struct mychip *chip; .... snd_card_set_pm_callback(card, snd_my_suspend, snd_my_resume, chip); .... diff --git a/Documentation/sound/alsa/hda_codec.txt b/Documentation/sound/alsa/hda_codec.txt index e9d07b8f1ac..0be57ed8130 100644 --- a/Documentation/sound/alsa/hda_codec.txt +++ b/Documentation/sound/alsa/hda_codec.txt @@ -63,7 +63,7 @@ The bus instance is created via snd_hda_bus_new(). You need to pass the card instance, the template, and the pointer to store the resultant bus instance. -int snd_hda_bus_new(snd_card_t *card, const struct hda_bus_template *temp, +int snd_hda_bus_new(struct snd_card *card, const struct hda_bus_template *temp, struct hda_bus **busp); It returns zero if successful. A negative return value means any @@ -166,14 +166,14 @@ The ops field contains the following callback functions: struct hda_pcm_ops { int (*open)(struct hda_pcm_stream *info, struct hda_codec *codec, - snd_pcm_substream_t *substream); + struct snd_pcm_substream *substream); int (*close)(struct hda_pcm_stream *info, struct hda_codec *codec, - snd_pcm_substream_t *substream); + struct snd_pcm_substream *substream); int (*prepare)(struct hda_pcm_stream *info, struct hda_codec *codec, unsigned int stream_tag, unsigned int format, - snd_pcm_substream_t *substream); + struct snd_pcm_substream *substream); int (*cleanup)(struct hda_pcm_stream *info, struct hda_codec *codec, - snd_pcm_substream_t *substream); + struct snd_pcm_substream *substream); }; All are non-NULL, so you can call them safely without NULL check. @@ -284,7 +284,7 @@ parameter, and PCI subsystem IDs. If the matching entry is found, it returns the config field value. snd_hda_add_new_ctls() can be used to create and add control entries. -Pass the zero-terminated array of snd_kcontrol_new_t. The same array +Pass the zero-terminated array of struct snd_kcontrol_new. The same array can be passed to snd_hda_resume_ctls() for resume. Note that this will call control->put callback of these entries. So, put callback should check codec->in_resume and force to restore the @@ -292,7 +292,7 @@ given value if it's non-zero even if the value is identical with the cached value. Macros HDA_CODEC_VOLUME(), HDA_CODEC_MUTE() and their variables can be -used for the entry of snd_kcontrol_new_t. +used for the entry of struct snd_kcontrol_new. The input MUX helper callbacks for such a control are provided, too: snd_hda_input_mux_info() and snd_hda_input_mux_put(). See -- cgit v1.2.3 From a4efc230c60ad15584e723755316e67b3c708d67 Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Thu, 17 Nov 2005 17:24:26 +0100 Subject: [ALSA] document - Add PM support Modules: Documentation Mark the drivers newly supporting PM in the documentation. Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/ALSA-Configuration.txt | 52 +++++++++++++++++++++++++ 1 file changed, 52 insertions(+) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt index 84068baf587..9a58ed9e695 100644 --- a/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/Documentation/sound/alsa/ALSA-Configuration.txt @@ -148,6 +148,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Module supports up to 8 cards. This module does not support autoprobe thus main port must be specified!!! Other ports are optional. + The power-management is supported. + Module snd-ad1889 ----------------- @@ -186,6 +188,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Module supports up to 8 cards, autoprobe and PnP. + The power-management is supported. + Module snd-als4000 ------------------ @@ -196,6 +200,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Module supports up to 8 cards, autoprobe and PnP. + The power-management is supported. + Module snd-atiixp ----------------- @@ -213,6 +219,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. implementation depends on the motherboard, and you'll need to choose the correct one via spdif_aclink module option. + The power-management is supported. + Module snd-atiixp-modem ----------------------- @@ -223,6 +231,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Note: The default index value of this module is -2, i.e. the first slot is excluded. + The power-management is supported. + Module snd-au8810, snd-au8820, snd-au8830 ----------------------------------------- @@ -265,6 +275,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Module supports up to 8 cards, PnP and autoprobe. + The power-management is supported. + Module snd-azt3328 ------------------ @@ -310,6 +322,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Module supports up to 8 cards and autoprobe. + The power-management is supported. + Module snd-cmipci ----------------- @@ -323,6 +337,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Module supports autoprobe and multiple chips (max 8). + The power-management is supported. + Module snd-cs4231 ----------------- @@ -433,6 +449,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Module supports up to 8 cards. This module is enabled only with ISA PnP support. + The power-management is supported. + Module snd-dummy ---------------- @@ -440,6 +458,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. or input, but you may use this module for any application which requires a sound card (like RealPlayer). + The power-management is supported. + Module snd-emu10k1 ------------------ @@ -473,6 +493,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. * Creative Card 5.1 (c) 2003 [0x3fc3/0x7cff] * Creative Card all ins and outs [0x3fff/0x7fff] + The power-management is supported. + Module snd-emu10k1x ------------------- @@ -515,6 +537,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Module supports up to 8 cards, PnP and autoprobe. + The power-management is supported. + Module snd-es1688 ----------------- @@ -554,6 +578,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Module supports up to 8 cards and autoprobe. + The power-management is supported. + Module snd-es1968 ----------------- @@ -586,6 +612,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Module supports up to 8 cards and autoprobe. + The power-management is supported. + Module snd-gusclassic --------------------- @@ -695,6 +723,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. (Usually SD_LPLIB register is more accurate than the position buffer.) + The power-management is supported. + Module snd-hdsp --------------- @@ -846,6 +876,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Note: The default index value of this module is -2, i.e. the first slot is excluded. + The power-management is supported. + Module snd-interwave -------------------- @@ -1091,6 +1123,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. For ARM architecture only. + The power-management is supported. + Module snd-rme32 ---------------- @@ -1131,6 +1165,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Module supports only one card. Module has no enable and index options. + The power-management is supported. + Module snd-sb8 -------------- @@ -1144,6 +1180,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Module supports up to 8 cards and autoprobe. + The power-management is supported. + Module snd-sb16 and snd-sbawe ----------------------------- @@ -1170,6 +1208,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. half duplex mode through 8-bit DMA channel by disabling their 16-bit DMA channel. + The power-management is supported. + Module snd-sgalaxy ------------------ @@ -1182,6 +1222,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Module supports up to 8 cards. + The power-management is supported. + Module snd-sscape ----------------- @@ -1363,6 +1405,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Note: for the MPU401 on VIA823x, use snd-mpu401 driver additionally. The mpu_port option is for VIA686 chips only. + The power-management is supported. + Module snd-via82xx-modem ------------------------ @@ -1375,6 +1419,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Note: The default index value of this module is -2, i.e. the first slot is excluded. + The power-management is supported. + Module snd-virmidi ------------------ @@ -1413,6 +1459,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. size is chosen. The possible IBL values can be found in /proc/asound/cardX/vx-status proc file. + The power-management is supported. + Module snd-vxpocket ------------------- @@ -1441,6 +1489,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Note2: snd-vxp440 driver is merged to snd-vxpocket driver since ALSA 1.0.10. + The power-management is supported. + Module snd-ymfpci ----------------- @@ -1465,6 +1515,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Note: the driver is build only when CONFIG_ISA is set. + The power-management is supported. + AC97 Quirk Option ================= -- cgit v1.2.3 From 5fe76e4dc60a2c3ff9b1143f5275a953db685e26 Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Thu, 17 Nov 2005 17:26:09 +0100 Subject: [ALSA] document - Update PM support Modules: Documentation Update the description about the PCI PM support. Signed-off-by: Takashi Iwai --- .../sound/alsa/DocBook/writing-an-alsa-driver.tmpl | 185 ++++++++++++++++----- 1 file changed, 146 insertions(+), 39 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl b/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl index f2e59fe802b..4963d83d151 100644 --- a/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl +++ b/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl @@ -18,8 +18,8 @@ - October 6, 2005 - 0.3.5 + November 17, 2005 + 0.3.6 @@ -2329,9 +2329,14 @@ struct _snd_pcm_runtime { PAUSE bit means that the pcm supports the pause operation, while the RESUME bit means that the pcm supports - the suspend/resume operation. If these flags - are set, the trigger callback below - must handle the corresponding commands. + the full suspend/resume operation. + If PAUSE flag is set, + the trigger callback below + must handle the corresponding (pause push/release) commands. + The suspend/resume trigger commands can be defined even without + RESUME flag. See + Power Management section for details. @@ -2903,8 +2908,8 @@ struct _snd_pcm_runtime { - When the pcm supports the suspend/resume operation - (i.e. SNDRV_PCM_INFO_RESUME flag is set), + When the pcm supports the suspend/resume operation, + regardless of full or partial suspend/resume support, SUSPEND and RESUME commands must be handled, too. These commands are issued when the power-management status is @@ -2913,6 +2918,8 @@ struct _snd_pcm_runtime { do suspend and resume of the pcm substream, and usually, they are identical with STOP and START commands, respectively. + See + Power Management section for details. @@ -5483,22 +5490,60 @@ struct _snd_pcm_runtime { CONFIG_PM. + + If the driver supports the suspend/resume + fully, that is, the device can be + properly resumed to the status at the suspend is called, + you can set SNDRV_PCM_INFO_RESUME flag + to pcm info field. Usually, this is possible when the + registers of ths chip can be safely saved and restored to the + RAM. If this is set, the trigger callback is called with + SNDRV_PCM_TRIGGER_RESUME after resume + callback is finished. + + + + Even if the driver doesn't support PM fully but only the + partial suspend/resume is possible, it's still worthy to + implement suspend/resume callbacks. In such a case, applications + would reset the status by calling + snd_pcm_prepare() and restart the stream + appropriately. Hence, you can define suspend/resume callbacks + below but don't set SNDRV_PCM_INFO_RESUME + info flag to the PCM. + + + + Note that the trigger with SUSPEND can be always called when + snd_pcm_suspend_all is called, + regardless of SNDRV_PCM_INFO_RESUME flag. + The RESUME flag affects only the behavior + of snd_pcm_resume(). + (Thus, in theory, + SNDRV_PCM_TRIGGER_RESUME isn't needed + to be handled in the trigger callback when no + SNDRV_PCM_INFO_RESUME flag is set. But, + it's better to keep it for compatibility reason.) + - ALSA provides the common power-management layer. Each card driver - needs to have only low-level suspend and resume callbacks. + In the earlier version of ALSA drivers, a common + power-management layer was provided, but it has been removed. + The driver needs to define the suspend/resume hooks according to + the bus the device is assigned. In the case of PCI driver, the + callbacks look like below: - Retrieve the chip data from pm_private_data field. + Retrieve the card and the chip data. + Call snd_power_change_state() with + SNDRV_CTL_POWER_D3hot to change the + power status. Call snd_pcm_suspend_all() to suspend the running PCM streams. + If AC97 codecs are used, call + snd_ac97_resume() for each codec. Save the register values if necessary. Stop the hardware if necessary. - Disable the PCI device by calling pci_disable_device(). + Disable the PCI device by calling + pci_disable_device(). Then, call + pci_save_state() at last. @@ -5525,18 +5577,24 @@ struct _snd_pcm_runtime { pm_private_data; + struct snd_card *card = pci_get_drvdata(pci); + struct mychip *chip = card->private_data; /* (2) */ - snd_pcm_suspend_all(chip->pcm); + snd_power_change_state(card, SNDRV_CTL_POWER_D3hot); /* (3) */ - snd_mychip_save_registers(chip); + snd_pcm_suspend_all(chip->pcm); /* (4) */ - snd_mychip_stop_hardware(chip); + snd_ac97_suspend(chip->ac97); /* (5) */ - pci_disable_device(chip->pci); + snd_mychip_save_registers(chip); + /* (6) */ + snd_mychip_stop_hardware(chip); + /* (7) */ + pci_disable_device(pci); + pci_save_state(pci); return 0; } ]]> @@ -5548,14 +5606,17 @@ struct _snd_pcm_runtime { The scheme of the real resume job is as following. - Retrieve the chip data from pm_private_data field. - Enable the pci device again by calling - pci_enable_device(). + Retrieve the card and the chip data. + Set up PCI. First, call pci_restore_state(). + Then enable the pci device again by calling pci_enable_device(). + Call pci_set_master() if necessary, too. Re-initialize the chip. Restore the saved registers if necessary. Resume the mixer, e.g. calling snd_ac97_resume(). Restart the hardware (if any). + Call snd_power_change_state() with + SNDRV_CTL_POWER_D0 to notify the processes. @@ -5565,12 +5626,15 @@ struct _snd_pcm_runtime { pm_private_data; + struct snd_card *card = pci_get_drvdata(pci); + struct mychip *chip = card->private_data; /* (2) */ - pci_enable_device(chip->pci); + pci_restore_state(pci); + pci_enable_device(pci); + pci_set_master(pci); /* (3) */ snd_mychip_reinit_chip(chip); /* (4) */ @@ -5579,6 +5643,8 @@ struct _snd_pcm_runtime { snd_ac97_resume(chip->ac97); /* (6) */ snd_mychip_restart_chip(chip); + /* (7) */ + snd_power_change_state(card, SNDRV_CTL_POWER_D0); return 0; } ]]> @@ -5587,8 +5653,48 @@ struct _snd_pcm_runtime { - OK, we have all callbacks now. Let's set up them now. In the - initialization of the card, add the following: + As shown in the above, it's better to save registers after + suspending the PCM operations via + snd_pcm_suspend_all() or + snd_pcm_suspend(). It means that the PCM + streams are already stoppped when the register snapshot is + taken. But, remind that you don't have to restart the PCM + stream in the resume callback. It'll be restarted via + trigger call with SNDRV_PCM_TRIGGER_RESUME + when necessary. + + + + OK, we have all callbacks now. Let's set them up. In the + initialization of the card, make sure that you can get the chip + data from the card instance, typically via + private_data field, in case you + created the chip data individually. + + + +private_data = chip; + .... + } +]]> + + + + When you created the chip data with + snd_card_new(), it's anyway accessible + via private_data field. @@ -5600,30 +5706,28 @@ struct _snd_pcm_runtime { struct snd_card *card; struct mychip *chip; .... - snd_card_set_pm_callback(card, snd_my_suspend, snd_my_resume, chip); + card = snd_card_new(index[dev], id[dev], THIS_MODULE, + sizeof(struct mychip)); + .... + chip = card->private_data; .... } ]]> - Here you don't have to put ifdef CONFIG_PM around, since it's already - checked in the header and expanded to empty if not needed. - If you need a space for saving the registers, you'll need to - allocate the buffer for it here, too, since it would be fatal + If you need a space for saving the registers, allocate the + buffer for it here, too, since it would be fatal if you cannot allocate a memory in the suspend phase. The allocated buffer should be released in the corresponding destructor. - And next, set suspend/resume callbacks to the pci_driver, - This can be done by passing a macro SND_PCI_PM_CALLBACKS - in the pci_driver struct. This macro is expanded to the correct - (global) callbacks if CONFIG_PM is set. + And next, set suspend/resume callbacks to the pci_driver. @@ -5633,7 +5737,10 @@ struct _snd_pcm_runtime { .id_table = snd_my_ids, .probe = snd_my_probe, .remove = __devexit_p(snd_my_remove), - SND_PCI_PM_CALLBACKS + #ifdef CONFIG_PM + .suspend = snd_my_suspend, + .resume = snd_my_resume, + #endif }; ]]> -- cgit v1.2.3 From 0ef797c5ca8a73853c827cf495caed44676cfe17 Mon Sep 17 00:00:00 2001 From: Clemens Ladisch Date: Mon, 21 Nov 2005 07:30:20 +0100 Subject: [ALSA] adjust documentation for higher card limit Modules: Documentation Fix all places in the docs where the card number limit is mentioned. Signed-off-by: Clemens Ladisch --- Documentation/sound/alsa/ALSA-Configuration.txt | 128 ++++++++++++------------ 1 file changed, 64 insertions(+), 64 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt index 9a58ed9e695..c30fd30a19e 100644 --- a/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/Documentation/sound/alsa/ALSA-Configuration.txt @@ -105,7 +105,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Each of top level sound card module takes the following options. index - index (slot #) of sound card - - Values: 0 through 7 or negative + - Values: 0 through 31 or negative - If nonnegative, assign that index number - if negative, interpret as a bitmask of permissible indices; the first free permitted index is assigned @@ -134,7 +134,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. dma2 - second DMA # for AD1816A chip (PnP setup) clockfreq - Clock frequency for AD1816A chip (default = 0, 33000Hz) - Module supports up to 8 cards, autoprobe and PnP. + This module supports multiple cards, autoprobe and PnP. Module snd-ad1848 ----------------- @@ -145,7 +145,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. irq - IRQ # for AD1848 chip dma1 - DMA # for AD1848 chip (0,1,3) - Module supports up to 8 cards. This module does not support autoprobe + This module supports multiple cards. It does not support autoprobe thus main port must be specified!!! Other ports are optional. The power-management is supported. @@ -158,7 +158,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. ac97_quirk - AC'97 workaround for strange hardware See the description of intel8x0 module for details. - This module supports up to 8 cards. + This module supports multiple cards. Module snd-ali5451 ------------------ @@ -186,7 +186,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. mpu_irq - IRQ # for MPU-401 (PnP setup) fm_port - port # for OPL3 FM (PnP setup) - Module supports up to 8 cards, autoprobe and PnP. + This module supports multiple cards, autoprobe and PnP. The power-management is supported. @@ -198,7 +198,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. joystick_port - port # for legacy joystick support. 0 = disabled (default), 1 = auto-detect - Module supports up to 8 cards, autoprobe and PnP. + This module supports multiple cards, autoprobe and PnP. The power-management is supported. @@ -273,7 +273,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. dma1 - 1st DMA # for AZT2320 (WSS) chip (PnP setup) dma2 - 2nd DMA # for AZT2320 (WSS) chip (PnP setup) - Module supports up to 8 cards, PnP and autoprobe. + This module supports multiple cards, PnP and autoprobe. The power-management is supported. @@ -284,7 +284,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. joystick - Enable joystick (default off) - Module supports up to 8 cards. + This module supports multiple cards. Module snd-bt87x ---------------- @@ -294,7 +294,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. digital_rate - Override the default digital rate (Hz) load_all - Load the driver even if the card model isn't known - Module supports up to 8 cards. + This module supports multiple cards. Note: The default index value of this module is -2, i.e. the first slot is excluded. @@ -304,7 +304,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Module for Creative Audigy LS and SB Live 24bit - Module supports up to 8 cards. + This module supports multiple cards. Module snd-cmi8330 @@ -320,7 +320,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. sbdma8 - 8bit DMA # for CMI8330 chip (SB16) sbdma16 - 16bit DMA # for CMI8330 chip (SB16) - Module supports up to 8 cards and autoprobe. + This module supports multiple cards and autoprobe. The power-management is supported. @@ -335,7 +335,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. (default = 1) joystick_port - Joystick port address (0 = disable, 1 = auto-detect) - Module supports autoprobe and multiple chips (max 8). + This module supports autoprobe and multiple cards. The power-management is supported. @@ -351,7 +351,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. dma1 - first DMA # for CS4231 chip dma2 - second DMA # for CS4231 chip - Module supports up to 8 cards. This module does not support autoprobe + This module supports multiple cards. This module does not support autoprobe thus main port must be specified!!! Other ports are optional. The power-management is supported. @@ -371,7 +371,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. dma2 - second DMA # for Yamaha CS4232 chip (0,1,3), -1 = disable isapnp - ISA PnP detection - 0 = disable, 1 = enable (default) - Module supports up to 8 cards. This module does not support autoprobe + This module supports multiple cards. This module does not support autoprobe thus main port must be specified!!! Other ports are optional. The power-management is supported. @@ -392,7 +392,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. dma2 - second DMA # for CS4236 chip (0,1,3), -1 = disable isapnp - ISA PnP detection - 0 = disable, 1 = enable (default) - Module supports up to 8 cards. This module does not support autoprobe + This module supports multiple cards. This module does not support autoprobe (if ISA PnP is not used) thus main port and control port must be specified!!! Other ports are optional. @@ -405,7 +405,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. dual_codec - Secondary codec ID (0 = disable, default) - Module supports up to 8 cards. + This module supports multiple cards. The power-management is supported. @@ -419,7 +419,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. thinkpad - Force to enable Thinkpad's CLKRUN control. mmap_valid - Support OSS mmap mode (default = 0). - Module supports up to 8 cards and autoprobe. + This module supports multiple cards and autoprobe. Usually external amp and CLKRUN controls are detected automatically from PCI sub vendor/device ids. If they don't work, give the options above explicitly. @@ -431,7 +431,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Module for multifunction CS5535 companion PCI device - Module supports up to 8 cards. + This module supports multiple cards. Module snd-dt019x ----------------- @@ -446,7 +446,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. mpu_irq - IRQ # for MPU-401 (PnP setup) dma8 - DMA # (PnP setup) - Module supports up to 8 cards. This module is enabled only with + This module supports multiple cards. This module is enabled only with ISA PnP support. The power-management is supported. @@ -477,7 +477,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. given in MB unit. Default value is 128. enable_ir - enable IR - Module supports up to 8 cards and autoprobe. + This module supports multiple cards and autoprobe. Input & Output configurations [extin/extout] * Creative Card wo/Digital out [0x0003/0x1f03] @@ -500,7 +500,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Module for Creative Emu10k1X (SB Live Dell OEM version) - Module supports up to 8 cards. + This module supports multiple cards. Module snd-ens1370 ------------------ @@ -511,7 +511,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. joystick - Enable joystick (default off) - Module supports up to 8 cards and autoprobe. + This module supports multiple cards and autoprobe. Module snd-ens1371 ------------------ @@ -524,7 +524,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. joystick_port - port # for joystick (0x200,0x208,0x210,0x218), 0 = disable (default), 1 = auto-detect - Module supports up to 8 cards and autoprobe. + This module supports multiple cards and autoprobe. Module snd-es968 ---------------- @@ -535,7 +535,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. irq - IRQ # for ES968 (SB8) chip (PnP setup) dma1 - DMA # for ES968 (SB8) chip (PnP setup) - Module supports up to 8 cards, PnP and autoprobe. + This module supports multiple cards, PnP and autoprobe. The power-management is supported. @@ -550,7 +550,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. mpu_irq - IRQ # for MPU-401 port (5,7,9,10) dma8 - DMA # for ES-1688 chip (0,1,3) - Module supports up to 8 cards and autoprobe (without MPU-401 port). + This module supports multiple cards and autoprobe (without MPU-401 port). Module snd-es18xx ----------------- @@ -565,8 +565,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. dma2 - first DMA # for ES-18xx chip (0,1,3) isapnp - ISA PnP detection - 0 = disable, 1 = enable (default) - Module supports up to 8 cards ISA PnP and autoprobe (without MPU-401 port - if native ISA PnP routines are not used). + This module supports multiple cards, ISA PnP and autoprobe (without MPU-401 + port if native ISA PnP routines are not used). When dma2 is equal with dma1, the driver works as half-duplex. The power-management is supported. @@ -576,7 +576,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Module for sound cards based on ESS Solo-1 (ES1938,ES1946) chips. - Module supports up to 8 cards and autoprobe. + This module supports multiple cards and autoprobe. The power-management is supported. @@ -594,7 +594,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. enable_mpu - enable MPU401 (0 = off, 1 = on, 2 = auto (default)) joystick - enable joystick (default off) - Module supports up to 8 cards and autoprobe. + This module supports multiple cards and autoprobe. The power-management is supported. @@ -610,7 +610,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. - High 16-bits are video (radio) device number + 1 - example: 0x10002 (MediaForte 256-PCPR, device 1) - Module supports up to 8 cards and autoprobe. + This module supports multiple cards and autoprobe. The power-management is supported. @@ -627,7 +627,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. voices - GF1 voices limit (14-32) pcm_voices - reserved PCM voices - Module supports up to 8 cards and autoprobe. + This module supports multiple cards and autoprobe. Module snd-gusextreme --------------------- @@ -646,7 +646,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. voices - GF1 voices limit (14-32) pcm_voices - reserved PCM voices - Module supports up to 8 cards and autoprobe (without MPU-401 port). + This module supports multiple cards and autoprobe (without MPU-401 port). Module snd-gusmax ----------------- @@ -661,7 +661,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. voices - GF1 voices limit (14-32) pcm_voices - reserved PCM voices - Module supports up to 8 cards and autoprobe. + This module supports multiple cards and autoprobe. Module snd-hda-intel -------------------- @@ -730,7 +730,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Module for RME Hammerfall DSP audio interface(s) - Module supports up to 8 cards. + This module supports multiple cards. Note: The firmware data can be automatically loaded via hotplug when CONFIG_FW_LOADER is set. Otherwise, you need to load @@ -788,7 +788,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. cs8427_timeout - reset timeout for the CS8427 chip (S/PDIF transciever) in msec resolution, default value is 500 (0.5 sec) - Module supports up to 8 cards and autoprobe. Note: The consumer part + This module supports multiple cards and autoprobe. Note: The consumer part is not used with all Envy24 based cards (for example in the MidiMan Delta serie). @@ -824,7 +824,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. aureon71, universe, k8x800, phase22, phase28, ms300, av710 - Module supports up to 8 cards and autoprobe. + This module supports multiple cards and autoprobe. Note: The supported board is detected by reading EEPROM or PCI SSID (if EEPROM isn't available). You can override the @@ -894,7 +894,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. effect - 1 = InterWave effects enable (default 0); requires 8 voices - Module supports up to 8 cards, autoprobe and ISA PnP. + This module supports multiple cards, autoprobe and ISA PnP. Module snd-interwave-stb ------------------------ @@ -914,14 +914,14 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. effect - 1 = InterWave effects enable (default 0); requires 8 voices - Module supports up to 8 cards, autoprobe and ISA PnP. + This module supports multiple cards, autoprobe and ISA PnP. Module snd-korg1212 ------------------- Module for Korg 1212 IO PCI card - Module supports up to 8 cards. + This module supports multiple cards. Module snd-maestro3 ------------------- @@ -933,7 +933,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. -1 for default pin (8 for allegro, 1 for others) - Module supports autoprobe and multiple chips (max 8). + This module supports autoprobe and multiple chips. Note: the binding of amplifier is dependent on hardware. If there is no sound even though all channels are unmuted, try to @@ -948,7 +948,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Module for Digigram miXart8 sound cards. - Module supports multiple cards. + This module supports multiple cards. Note: One miXart8 board will be represented as 4 alsa cards. See MIXART.txt for details. @@ -967,7 +967,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. irq - IRQ number or -1 (disable) pnp - PnP detection - 0 = disable, 1 = enable (default) - Module supports multiple devices (max 8) and PnP. + This module supports multiple devices and PnP. Module snd-mtpav ---------------- @@ -1053,7 +1053,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. dma2 - second DMA # for Yamaha OPL3-SA chip (0,1,3), -1 = disable isapnp - ISA PnP detection - 0 = disable, 1 = enable (default) - Module supports up to 8 cards and ISA PnP. This module does not support + This module supports multiple cards and ISA PnP. It does not support autoprobe (if ISA PnP is not used) thus all ports must be specified!!! The power-management is supported. @@ -1131,14 +1131,14 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Module for RME Digi32, Digi32 Pro and Digi32/8 (Sek'd Prodif32, Prodif96 and Prodif Gold) sound cards. - Module supports up to 8 cards. + This module supports multiple cards. Module snd-rme96 ---------------- Module for RME Digi96, Digi96/8 and Digi96/8 PRO/PAD/PST sound cards. - Module supports up to 8 cards. + This module supports multiple cards. Module snd-rme9652 ------------------ @@ -1148,7 +1148,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. precise_ptr - Enable precise pointer (doesn't work reliably). (default = 0) - Module supports up to 8 cards. + This module supports multiple cards. Note: snd-page-alloc module does the job which snd-hammerfall-mem module did formerly. It will allocate the buffers in advance @@ -1178,7 +1178,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. irq - IRQ # for SB DSP chip (5,7,9,10) dma8 - DMA # for SB DSP chip (1,3) - Module supports up to 8 cards and autoprobe. + This module supports multiple cards and autoprobe. The power-management is supported. @@ -1200,7 +1200,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. csp - ASP/CSP chip support - 0 = disable (default), 1 = enable isapnp - ISA PnP detection - 0 = disable, 1 = enable (default) - Module supports up to 8 cards, autoprobe and ISA PnP. + This module supports multiple cards, autoprobe and ISA PnP. Note: To use Vibra16X cards in 16-bit half duplex mode, you must disable 16bit DMA with dma16 = -1 module parameter. @@ -1220,7 +1220,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. irq - IRQ # (7,9,10,11) dma1 - DMA # - Module supports up to 8 cards. + This module supports multiple cards. The power-management is supported. @@ -1234,7 +1234,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. mpu_irq - MPU-401 IRQ # (PnP setup) dma - DMA # (PnP setup) - Module supports up to 8 cards. ISA PnP must be enabled. + This module supports multiple cards. ISA PnP must be enabled. You need sscape_ctl tool in alsa-tools package for loading the microcode. @@ -1243,21 +1243,21 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Module for AMD7930 sound chips found on Sparcs. - Module supports up to 8 cards. + This module supports multiple cards. Module snd-sun-cs4231 (on sparc only) ------------------------------------- Module for CS4231 sound chips found on Sparcs. - Module supports up to 8 cards. + This module supports multiple cards. Module snd-sun-dbri (on sparc only) ----------------------------------- Module for DBRI sound chips found on Sparcs. - Module supports up to 8 cards. + This module supports multiple cards. Module snd-wavefront -------------------- @@ -1277,7 +1277,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. dma2 - DMA2 # for CS4232 PCM interface. isapnp - ISA PnP detection - 0 = disable, 1 = enable (default) - Module supports up to 8 cards and ISA PnP. + This module supports multiple cards and ISA PnP. Module snd-sonicvibes --------------------- @@ -1289,7 +1289,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. - SoundCard must have onboard SRAM for this. mge - Mic Gain Enable - 1 = enable, 0 = disable (default) - Module supports up to 8 cards and autoprobe. + This module supports multiple cards and autoprobe. Module snd-serial-u16550 ------------------------ @@ -1308,7 +1308,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. 0 = Soundcanvas, 1 = MS-124T, 2 = MS-124W S/A, 3 = MS-124W M/B, 4 = Generic - Module supports up to 8 cards. This module does not support autoprobe + This module supports multiple cards. This module does not support autoprobe thus the main port must be specified!!! Other options are optional. Module snd-trident @@ -1327,7 +1327,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. pcm_channels - max channels (voices) reserved for PCM wavetable_size - max wavetable size in kB (4-?kb) - Module supports up to 8 cards and autoprobe. + This module supports multiple cards and autoprobe. The power-management is supported. @@ -1339,14 +1339,14 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. vid - Vendor ID for the device (optional) pid - Product ID for the device (optional) - This module supports up to 8 cards, autoprobe and hotplugging. + This module supports multiple devices, autoprobe and hotplugging. Module snd-usb-usx2y -------------------- Module for Tascam USB US-122, US-224 and US-428 devices. - This module supports up to 8 cards, autoprobe and hotplugging. + This module supports multiple devices, autoprobe and hotplugging. Note: you need to load the firmware via usx2yloader utility included in alsa-tools and alsa-firmware packages. @@ -1428,9 +1428,9 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. This module creates virtual rawmidi devices which communicate to the corresponding ALSA sequencer ports. - midi_devs - MIDI devices # (1-8, default=4) + midi_devs - MIDI devices # (1-4, default=4) - Module supports up to 8 cards. + This module supports multiple cards. Module snd-vx222 ---------------- @@ -1440,7 +1440,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. mic - Enable Microphone on V222 Mic (NYI) ibl - Capture IBL size. (default = 0, minimum size) - Module supports up to 8 cards. + This module supports multiple cards. When the driver is compiled as a module and the hotplug firmware is supported, the firmware data is loaded via hotplug automatically. @@ -1468,7 +1468,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. ibl - Capture IBL size. (default = 0, minimum size) - Module supports up to 8 cards. The module is compiled only when + This module supports multiple cards. The module is compiled only when PCMCIA is supported on kernel. With the older 2.6.x kernel, to activate the driver via the card @@ -1504,7 +1504,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. 1 (auto-detect) rear_switch - enable shared rear/line-in switch (bool) - Module supports autoprobe and multiple chips (max 8). + This module supports autoprobe and multiple chips. The power-management is supported. -- cgit v1.2.3 From e12229b4d2b7863b1baaeca759aa87703bf9fdf8 Mon Sep 17 00:00:00 2001 From: Markus Bollinger Date: Tue, 6 Dec 2005 13:55:26 +0100 Subject: [ALSA] Add PCXHR driver Modules: Documentation,PCI drivers,Digigram PCXHR driver Add Digigram PCXHR driver. Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/ALSA-Configuration.txt | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt index c30fd30a19e..d2578013e82 100644 --- a/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/Documentation/sound/alsa/ALSA-Configuration.txt @@ -1103,6 +1103,13 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. This module supports only one card, autoprobe and PnP. + Module snd-pcxhr + ---------------- + + Module for Digigram PCXHR boards + + This module supports multiple cards. + Module snd-powermac (on ppc only) --------------------------------- -- cgit v1.2.3 From 5e03e2c48fc2952f6a9e986cfa194fe905d0f569 Mon Sep 17 00:00:00 2001 From: "Adam D. Moss" Date: Tue, 3 Jan 2006 13:31:01 +0100 Subject: update for Documentation/sysrq.txt This patch for 2.4.x updates the dead email address for 'Mydraal' and since he no longer wishes to field questions concerning SysRq or this document removes the statement stating otherwise. Signed-off-by: Adrian Bunk --- Documentation/sysrq.txt | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sysrq.txt b/Documentation/sysrq.txt index baf17b38158..ad0bedf678b 100644 --- a/Documentation/sysrq.txt +++ b/Documentation/sysrq.txt @@ -202,17 +202,13 @@ you must call __handle_sysrq_nolock instead. * I have more questions, who can I ask? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -You may feel free to send email to myrdraal@deathsdoor.com, and I will -respond as soon as possible. - -Myrdraal - And I'll answer any questions about the registration system you got, also responding as soon as possible. -Crutcher * Credits ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Written by Mydraal +Written by Mydraal Updated by Adam Sulmicki Updated by Jeremy M. Dolan 2001/01/28 10:15:59 Added to by Crutcher Dunnavant -- cgit v1.2.3 From f62870db3c73683fe566a05efa2a05f3faeb44f5 Mon Sep 17 00:00:00 2001 From: Kees Cook Date: Tue, 3 Jan 2006 13:33:31 +0100 Subject: Documentation/SubmittingPatches: update Trivial Patch Monkey information While looking for where to send trivial patches, I found old contact information in Documentation/SubmittingPatches. Signed-off-by: Kees Cook Signed-off-by: Adrian Bunk --- Documentation/SubmittingPatches | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 237d54c44bc..1d47e6c09dc 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -158,7 +158,7 @@ Even if the maintainer did not respond in step #4, make sure to ALWAYS copy the maintainer when you change their code. For small patches you may want to CC the Trivial Patch Monkey -trivial@rustcorp.com.au set up by Rusty Russell; which collects "trivial" +trivial@kernel.org managed by Adrian Bunk; which collects "trivial" patches. Trivial patches must qualify for one of the following rules: Spelling fixes in documentation Spelling fixes which could break grep(1). @@ -171,7 +171,7 @@ patches. Trivial patches must qualify for one of the following rules: since people copy, as long as it's trivial) Any fix by the author/maintainer of the file. (ie. patch monkey in re-transmission mode) -URL: +URL: -- cgit v1.2.3 From e3e1bfe4f28de86d065bc041456161a3f3a9aef7 Mon Sep 17 00:00:00 2001 From: Jim Cromie Date: Tue, 3 Jan 2006 13:35:41 +0100 Subject: Documentation/filesystems/vfs.txt: typo fix This patch removes an extra occurrence of 'generic'. Acked-by: Pekka Enberg Signed-off-by: Adrian Bunk --- Documentation/filesystems/vfs.txt | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index ee4c0a8b8db..e56e842847d 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt @@ -162,9 +162,8 @@ get_sb() method fills in is the "s_op" field. This is a pointer to a "struct super_operations" which describes the next level of the filesystem implementation. -Usually, a filesystem uses generic one of the generic get_sb() -implementations and provides a fill_super() method instead. The -generic methods are: +Usually, a filesystem uses one of the generic get_sb() implementations +and provides a fill_super() method instead. The generic methods are: get_sb_bdev: mount a filesystem residing on a block device -- cgit v1.2.3 From f4b09ebc8baa51ec8394c4173e3de9d62b2cc97a Mon Sep 17 00:00:00 2001 From: Adrian Bunk Date: Tue, 3 Jan 2006 13:37:51 +0100 Subject: update the email address of Randy Dunlap This patch removes all references to the bouncing address rddunlap@osdl.org and one dead web page from the kernel. Signed-off-by: Adrian Bunk Acked-by: Randy Dunlap --- Documentation/block/biodoc.txt | 2 +- Documentation/scsi/scsi_mid_low_api.txt | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt index 0fe01c80548..303c57a7fad 100644 --- a/Documentation/block/biodoc.txt +++ b/Documentation/block/biodoc.txt @@ -31,7 +31,7 @@ The following people helped with review comments and inputs for this document: Christoph Hellwig Arjan van de Ven - Randy Dunlap + Randy Dunlap Andre Hedrick The following people helped with fixes/contributions to the bio patches diff --git a/Documentation/scsi/scsi_mid_low_api.txt b/Documentation/scsi/scsi_mid_low_api.txt index 66565d42288..3209b37e07e 100644 --- a/Documentation/scsi/scsi_mid_low_api.txt +++ b/Documentation/scsi/scsi_mid_low_api.txt @@ -1433,7 +1433,7 @@ The following people have contributed to this document: Christoph Hellwig Doug Ledford Andries Brouwer - Randy Dunlap + Randy Dunlap Alan Stern -- cgit v1.2.3 From 48d727a9f93e617d6d443507acf7d1b849c63366 Mon Sep 17 00:00:00 2001 From: Paolo 'Blaisorblade' Giarrusso Date: Tue, 3 Jan 2006 13:44:23 +0100 Subject: Documentation/filesystems/00-INDEX: remove entry for fat_cvf.txt Remove non-existing entry for fat_cvf.txt (was it ever supported?). Signed-off-by: Paolo 'Blaisorblade' Giarrusso Signed-off-by: Adrian Bunk --- Documentation/filesystems/00-INDEX | 2 -- 1 file changed, 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/00-INDEX b/Documentation/filesystems/00-INDEX index bcfbab899b3..7e17712f322 100644 --- a/Documentation/filesystems/00-INDEX +++ b/Documentation/filesystems/00-INDEX @@ -18,8 +18,6 @@ devfs/ - directory containing devfs documentation. ext2.txt - info, mount options and specifications for the Ext2 filesystem. -fat_cvf.txt - - info on the Compressed Volume Files extension to the FAT filesystem hpfs.txt - info and mount options for the OS/2 HPFS. isofs.txt -- cgit v1.2.3 From 7063fbf2261194f72ee75afca67b3b38b554b5fa Mon Sep 17 00:00:00 2001 From: Joel Becker Date: Thu, 15 Dec 2005 14:29:43 -0800 Subject: [PATCH] configfs: User-driven configuration filesystem Configfs, a file system for userspace-driven kernel object configuration. The OCFS2 stack makes extensive use of this for propagation of cluster configuration information into kernel. Signed-off-by: Joel Becker --- Documentation/filesystems/00-INDEX | 2 + Documentation/filesystems/configfs/configfs.txt | 434 +++++++++++++++++++ .../filesystems/configfs/configfs_example.c | 474 +++++++++++++++++++++ 3 files changed, 910 insertions(+) create mode 100644 Documentation/filesystems/configfs/configfs.txt create mode 100644 Documentation/filesystems/configfs/configfs_example.c (limited to 'Documentation') diff --git a/Documentation/filesystems/00-INDEX b/Documentation/filesystems/00-INDEX index bcfbab899b3..628f8a7adb8 100644 --- a/Documentation/filesystems/00-INDEX +++ b/Documentation/filesystems/00-INDEX @@ -12,6 +12,8 @@ cifs.txt - description of the CIFS filesystem coda.txt - description of the CODA filesystem. +configfs/ + - directory containing configfs documentation and example code. cramfs.txt - info on the cram filesystem for small storage (ROMs etc) devfs/ diff --git a/Documentation/filesystems/configfs/configfs.txt b/Documentation/filesystems/configfs/configfs.txt new file mode 100644 index 00000000000..c4ff96b7c4e --- /dev/null +++ b/Documentation/filesystems/configfs/configfs.txt @@ -0,0 +1,434 @@ + +configfs - Userspace-driven kernel object configuation. + +Joel Becker + +Updated: 31 March 2005 + +Copyright (c) 2005 Oracle Corporation, + Joel Becker + + +[What is configfs?] + +configfs is a ram-based filesystem that provides the converse of +sysfs's functionality. Where sysfs is a filesystem-based view of +kernel objects, configfs is a filesystem-based manager of kernel +objects, or config_items. + +With sysfs, an object is created in kernel (for example, when a device +is discovered) and it is registered with sysfs. Its attributes then +appear in sysfs, allowing userspace to read the attributes via +readdir(3)/read(2). It may allow some attributes to be modified via +write(2). The important point is that the object is created and +destroyed in kernel, the kernel controls the lifecycle of the sysfs +representation, and sysfs is merely a window on all this. + +A configfs config_item is created via an explicit userspace operation: +mkdir(2). It is destroyed via rmdir(2). The attributes appear at +mkdir(2) time, and can be read or modified via read(2) and write(2). +As with sysfs, readdir(3) queries the list of items and/or attributes. +symlink(2) can be used to group items together. Unlike sysfs, the +lifetime of the representation is completely driven by userspace. The +kernel modules backing the items must respond to this. + +Both sysfs and configfs can and should exist together on the same +system. One is not a replacement for the other. + +[Using configfs] + +configfs can be compiled as a module or into the kernel. You can access +it by doing + + mount -t configfs none /config + +The configfs tree will be empty unless client modules are also loaded. +These are modules that register their item types with configfs as +subsystems. Once a client subsystem is loaded, it will appear as a +subdirectory (or more than one) under /config. Like sysfs, the +configfs tree is always there, whether mounted on /config or not. + +An item is created via mkdir(2). The item's attributes will also +appear at this time. readdir(3) can determine what the attributes are, +read(2) can query their default values, and write(2) can store new +values. Like sysfs, attributes should be ASCII text files, preferably +with only one value per file. The same efficiency caveats from sysfs +apply. Don't mix more than one attribute in one attribute file. + +Like sysfs, configfs expects write(2) to store the entire buffer at +once. When writing to configfs attributes, userspace processes should +first read the entire file, modify the portions they wish to change, and +then write the entire buffer back. Attribute files have a maximum size +of one page (PAGE_SIZE, 4096 on i386). + +When an item needs to be destroyed, remove it with rmdir(2). An +item cannot be destroyed if any other item has a link to it (via +symlink(2)). Links can be removed via unlink(2). + +[Configuring FakeNBD: an Example] + +Imagine there's a Network Block Device (NBD) driver that allows you to +access remote block devices. Call it FakeNBD. FakeNBD uses configfs +for its configuration. Obviously, there will be a nice program that +sysadmins use to configure FakeNBD, but somehow that program has to tell +the driver about it. Here's where configfs comes in. + +When the FakeNBD driver is loaded, it registers itself with configfs. +readdir(3) sees this just fine: + + # ls /config + fakenbd + +A fakenbd connection can be created with mkdir(2). The name is +arbitrary, but likely the tool will make some use of the name. Perhaps +it is a uuid or a disk name: + + # mkdir /config/fakenbd/disk1 + # ls /config/fakenbd/disk1 + target device rw + +The target attribute contains the IP address of the server FakeNBD will +connect to. The device attribute is the device on the server. +Predictably, the rw attribute determines whether the connection is +read-only or read-write. + + # echo 10.0.0.1 > /config/fakenbd/disk1/target + # echo /dev/sda1 > /config/fakenbd/disk1/device + # echo 1 > /config/fakenbd/disk1/rw + +That's it. That's all there is. Now the device is configured, via the +shell no less. + +[Coding With configfs] + +Every object in configfs is a config_item. A config_item reflects an +object in the subsystem. It has attributes that match values on that +object. configfs handles the filesystem representation of that object +and its attributes, allowing the subsystem to ignore all but the +basic show/store interaction. + +Items are created and destroyed inside a config_group. A group is a +collection of items that share the same attributes and operations. +Items are created by mkdir(2) and removed by rmdir(2), but configfs +handles that. The group has a set of operations to perform these tasks + +A subsystem is the top level of a client module. During initialization, +the client module registers the subsystem with configfs, the subsystem +appears as a directory at the top of the configfs filesystem. A +subsystem is also a config_group, and can do everything a config_group +can. + +[struct config_item] + + struct config_item { + char *ci_name; + char ci_namebuf[UOBJ_NAME_LEN]; + struct kref ci_kref; + struct list_head ci_entry; + struct config_item *ci_parent; + struct config_group *ci_group; + struct config_item_type *ci_type; + struct dentry *ci_dentry; + }; + + void config_item_init(struct config_item *); + void config_item_init_type_name(struct config_item *, + const char *name, + struct config_item_type *type); + struct config_item *config_item_get(struct config_item *); + void config_item_put(struct config_item *); + +Generally, struct config_item is embedded in a container structure, a +structure that actually represents what the subsystem is doing. The +config_item portion of that structure is how the object interacts with +configfs. + +Whether statically defined in a source file or created by a parent +config_group, a config_item must have one of the _init() functions +called on it. This initializes the reference count and sets up the +appropriate fields. + +All users of a config_item should have a reference on it via +config_item_get(), and drop the reference when they are done via +config_item_put(). + +By itself, a config_item cannot do much more than appear in configfs. +Usually a subsystem wants the item to display and/or store attributes, +among other things. For that, it needs a type. + +[struct config_item_type] + + struct configfs_item_operations { + void (*release)(struct config_item *); + ssize_t (*show_attribute)(struct config_item *, + struct configfs_attribute *, + char *); + ssize_t (*store_attribute)(struct config_item *, + struct configfs_attribute *, + const char *, size_t); + int (*allow_link)(struct config_item *src, + struct config_item *target); + int (*drop_link)(struct config_item *src, + struct config_item *target); + }; + + struct config_item_type { + struct module *ct_owner; + struct configfs_item_operations *ct_item_ops; + struct configfs_group_operations *ct_group_ops; + struct configfs_attribute **ct_attrs; + }; + +The most basic function of a config_item_type is to define what +operations can be performed on a config_item. All items that have been +allocated dynamically will need to provide the ct_item_ops->release() +method. This method is called when the config_item's reference count +reaches zero. Items that wish to display an attribute need to provide +the ct_item_ops->show_attribute() method. Similarly, storing a new +attribute value uses the store_attribute() method. + +[struct configfs_attribute] + + struct configfs_attribute { + char *ca_name; + struct module *ca_owner; + mode_t ca_mode; + }; + +When a config_item wants an attribute to appear as a file in the item's +configfs directory, it must define a configfs_attribute describing it. +It then adds the attribute to the NULL-terminated array +config_item_type->ct_attrs. When the item appears in configfs, the +attribute file will appear with the configfs_attribute->ca_name +filename. configfs_attribute->ca_mode specifies the file permissions. + +If an attribute is readable and the config_item provides a +ct_item_ops->show_attribute() method, that method will be called +whenever userspace asks for a read(2) on the attribute. The converse +will happen for write(2). + +[struct config_group] + +A config_item cannot live in a vaccum. The only way one can be created +is via mkdir(2) on a config_group. This will trigger creation of a +child item. + + struct config_group { + struct config_item cg_item; + struct list_head cg_children; + struct configfs_subsystem *cg_subsys; + struct config_group **default_groups; + }; + + void config_group_init(struct config_group *group); + void config_group_init_type_name(struct config_group *group, + const char *name, + struct config_item_type *type); + + +The config_group structure contains a config_item. Properly configuring +that item means that a group can behave as an item in its own right. +However, it can do more: it can create child items or groups. This is +accomplished via the group operations specified on the group's +config_item_type. + + struct configfs_group_operations { + struct config_item *(*make_item)(struct config_group *group, + const char *name); + struct config_group *(*make_group)(struct config_group *group, + const char *name); + int (*commit_item)(struct config_item *item); + void (*drop_item)(struct config_group *group, + struct config_item *item); + }; + +A group creates child items by providing the +ct_group_ops->make_item() method. If provided, this method is called from mkdir(2) in the group's directory. The subsystem allocates a new +config_item (or more likely, its container structure), initializes it, +and returns it to configfs. Configfs will then populate the filesystem +tree to reflect the new item. + +If the subsystem wants the child to be a group itself, the subsystem +provides ct_group_ops->make_group(). Everything else behaves the same, +using the group _init() functions on the group. + +Finally, when userspace calls rmdir(2) on the item or group, +ct_group_ops->drop_item() is called. As a config_group is also a +config_item, it is not necessary for a seperate drop_group() method. +The subsystem must config_item_put() the reference that was initialized +upon item allocation. If a subsystem has no work to do, it may omit +the ct_group_ops->drop_item() method, and configfs will call +config_item_put() on the item on behalf of the subsystem. + +IMPORTANT: drop_item() is void, and as such cannot fail. When rmdir(2) +is called, configfs WILL remove the item from the filesystem tree +(assuming that it has no children to keep it busy). The subsystem is +responsible for responding to this. If the subsystem has references to +the item in other threads, the memory is safe. It may take some time +for the item to actually disappear from the subsystem's usage. But it +is gone from configfs. + +A config_group cannot be removed while it still has child items. This +is implemented in the configfs rmdir(2) code. ->drop_item() will not be +called, as the item has not been dropped. rmdir(2) will fail, as the +directory is not empty. + +[struct configfs_subsystem] + +A subsystem must register itself, ususally at module_init time. This +tells configfs to make the subsystem appear in the file tree. + + struct configfs_subsystem { + struct config_group su_group; + struct semaphore su_sem; + }; + + int configfs_register_subsystem(struct configfs_subsystem *subsys); + void configfs_unregister_subsystem(struct configfs_subsystem *subsys); + + A subsystem consists of a toplevel config_group and a semaphore. +The group is where child config_items are created. For a subsystem, +this group is usually defined statically. Before calling +configfs_register_subsystem(), the subsystem must have initialized the +group via the usual group _init() functions, and it must also have +initialized the semaphore. + When the register call returns, the subsystem is live, and it +will be visible via configfs. At that point, mkdir(2) can be called and +the subsystem must be ready for it. + +[An Example] + +The best example of these basic concepts is the simple_children +subsystem/group and the simple_child item in configfs_example.c It +shows a trivial object displaying and storing an attribute, and a simple +group creating and destroying these children. + +[Hierarchy Navigation and the Subsystem Semaphore] + +There is an extra bonus that configfs provides. The config_groups and +config_items are arranged in a hierarchy due to the fact that they +appear in a filesystem. A subsystem is NEVER to touch the filesystem +parts, but the subsystem might be interested in this hierarchy. For +this reason, the hierarchy is mirrored via the config_group->cg_children +and config_item->ci_parent structure members. + +A subsystem can navigate the cg_children list and the ci_parent pointer +to see the tree created by the subsystem. This can race with configfs' +management of the hierarchy, so configfs uses the subsystem semaphore to +protect modifications. Whenever a subsystem wants to navigate the +hierarchy, it must do so under the protection of the subsystem +semaphore. + +A subsystem will be prevented from acquiring the semaphore while a newly +allocated item has not been linked into this hierarchy. Similarly, it +will not be able to acquire the semaphore while a dropping item has not +yet been unlinked. This means that an item's ci_parent pointer will +never be NULL while the item is in configfs, and that an item will only +be in its parent's cg_children list for the same duration. This allows +a subsystem to trust ci_parent and cg_children while they hold the +semaphore. + +[Item Aggregation Via symlink(2)] + +configfs provides a simple group via the group->item parent/child +relationship. Often, however, a larger environment requires aggregation +outside of the parent/child connection. This is implemented via +symlink(2). + +A config_item may provide the ct_item_ops->allow_link() and +ct_item_ops->drop_link() methods. If the ->allow_link() method exists, +symlink(2) may be called with the config_item as the source of the link. +These links are only allowed between configfs config_items. Any +symlink(2) attempt outside the configfs filesystem will be denied. + +When symlink(2) is called, the source config_item's ->allow_link() +method is called with itself and a target item. If the source item +allows linking to target item, it returns 0. A source item may wish to +reject a link if it only wants links to a certain type of object (say, +in its own subsystem). + +When unlink(2) is called on the symbolic link, the source item is +notified via the ->drop_link() method. Like the ->drop_item() method, +this is a void function and cannot return failure. The subsystem is +responsible for responding to the change. + +A config_item cannot be removed while it links to any other item, nor +can it be removed while an item links to it. Dangling symlinks are not +allowed in configfs. + +[Automatically Created Subgroups] + +A new config_group may want to have two types of child config_items. +While this could be codified by magic names in ->make_item(), it is much +more explicit to have a method whereby userspace sees this divergence. + +Rather than have a group where some items behave differently than +others, configfs provides a method whereby one or many subgroups are +automatically created inside the parent at its creation. Thus, +mkdir("parent) results in "parent", "parent/subgroup1", up through +"parent/subgroupN". Items of type 1 can now be created in +"parent/subgroup1", and items of type N can be created in +"parent/subgroupN". + +These automatic subgroups, or default groups, do not preclude other +children of the parent group. If ct_group_ops->make_group() exists, +other child groups can be created on the parent group directly. + +A configfs subsystem specifies default groups by filling in the +NULL-terminated array default_groups on the config_group structure. +Each group in that array is populated in the configfs tree at the same +time as the parent group. Similarly, they are removed at the same time +as the parent. No extra notification is provided. When a ->drop_item() +method call notifies the subsystem the parent group is going away, it +also means every default group child associated with that parent group. + +As a consequence of this, default_groups cannot be removed directly via +rmdir(2). They also are not considered when rmdir(2) on the parent +group is checking for children. + +[Committable Items] + +NOTE: Committable items are currently unimplemented. + +Some config_items cannot have a valid initial state. That is, no +default values can be specified for the item's attributes such that the +item can do its work. Userspace must configure one or more attributes, +after which the subsystem can start whatever entity this item +represents. + +Consider the FakeNBD device from above. Without a target address *and* +a target device, the subsystem has no idea what block device to import. +The simple example assumes that the subsystem merely waits until all the +appropriate attributes are configured, and then connects. This will, +indeed, work, but now every attribute store must check if the attributes +are initialized. Every attribute store must fire off the connection if +that condition is met. + +Far better would be an explicit action notifying the subsystem that the +config_item is ready to go. More importantly, an explicit action allows +the subsystem to provide feedback as to whether the attibutes are +initialized in a way that makes sense. configfs provides this as +committable items. + +configfs still uses only normal filesystem operations. An item is +committed via rename(2). The item is moved from a directory where it +can be modified to a directory where it cannot. + +Any group that provides the ct_group_ops->commit_item() method has +committable items. When this group appears in configfs, mkdir(2) will +not work directly in the group. Instead, the group will have two +subdirectories: "live" and "pending". The "live" directory does not +support mkdir(2) or rmdir(2) either. It only allows rename(2). The +"pending" directory does allow mkdir(2) and rmdir(2). An item is +created in the "pending" directory. Its attributes can be modified at +will. Userspace commits the item by renaming it into the "live" +directory. At this point, the subsystem recieves the ->commit_item() +callback. If all required attributes are filled to satisfaction, the +method returns zero and the item is moved to the "live" directory. + +As rmdir(2) does not work in the "live" directory, an item must be +shutdown, or "uncommitted". Again, this is done via rename(2), this +time from the "live" directory back to the "pending" one. The subsystem +is notified by the ct_group_ops->uncommit_object() method. + + diff --git a/Documentation/filesystems/configfs/configfs_example.c b/Documentation/filesystems/configfs/configfs_example.c new file mode 100644 index 00000000000..f3c6e4946f9 --- /dev/null +++ b/Documentation/filesystems/configfs/configfs_example.c @@ -0,0 +1,474 @@ +/* + * vim: noexpandtab ts=8 sts=0 sw=8: + * + * configfs_example.c - This file is a demonstration module containing + * a number of configfs subsystems. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. + * + * This program 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. + * + * You should have received a copy of the GNU General Public + * License along with this program; if not, write to the + * Free Software Foundation, Inc., 59 Temple Place - Suite 330, + * Boston, MA 021110-1307, USA. + * + * Based on sysfs: + * sysfs is Copyright (C) 2001, 2002, 2003 Patrick Mochel + * + * configfs Copyright (C) 2005 Oracle. All rights reserved. + */ + +#include +#include +#include + +#include + + + +/* + * 01-childless + * + * This first example is a childless subsystem. It cannot create + * any config_items. It just has attributes. + * + * Note that we are enclosing the configfs_subsystem inside a container. + * This is not necessary if a subsystem has no attributes directly + * on the subsystem. See the next example, 02-simple-children, for + * such a subsystem. + */ + +struct childless { + struct configfs_subsystem subsys; + int showme; + int storeme; +}; + +struct childless_attribute { + struct configfs_attribute attr; + ssize_t (*show)(struct childless *, char *); + ssize_t (*store)(struct childless *, const char *, size_t); +}; + +static inline struct childless *to_childless(struct config_item *item) +{ + return item ? container_of(to_configfs_subsystem(to_config_group(item)), struct childless, subsys) : NULL; +} + +static ssize_t childless_showme_read(struct childless *childless, + char *page) +{ + ssize_t pos; + + pos = sprintf(page, "%d\n", childless->showme); + childless->showme++; + + return pos; +} + +static ssize_t childless_storeme_read(struct childless *childless, + char *page) +{ + return sprintf(page, "%d\n", childless->storeme); +} + +static ssize_t childless_storeme_write(struct childless *childless, + const char *page, + size_t count) +{ + unsigned long tmp; + char *p = (char *) page; + + tmp = simple_strtoul(p, &p, 10); + if (!p || (*p && (*p != '\n'))) + return -EINVAL; + + if (tmp > INT_MAX) + return -ERANGE; + + childless->storeme = tmp; + + return count; +} + +static ssize_t childless_description_read(struct childless *childless, + char *page) +{ + return sprintf(page, +"[01-childless]\n" +"\n" +"The childless subsystem is the simplest possible subsystem in\n" +"configfs. It does not support the creation of child config_items.\n" +"It only has a few attributes. In fact, it isn't much different\n" +"than a directory in /proc.\n"); +} + +static struct childless_attribute childless_attr_showme = { + .attr = { .ca_owner = THIS_MODULE, .ca_name = "showme", .ca_mode = S_IRUGO }, + .show = childless_showme_read, +}; +static struct childless_attribute childless_attr_storeme = { + .attr = { .ca_owner = THIS_MODULE, .ca_name = "storeme", .ca_mode = S_IRUGO | S_IWUSR }, + .show = childless_storeme_read, + .store = childless_storeme_write, +}; +static struct childless_attribute childless_attr_description = { + .attr = { .ca_owner = THIS_MODULE, .ca_name = "description", .ca_mode = S_IRUGO }, + .show = childless_description_read, +}; + +static struct configfs_attribute *childless_attrs[] = { + &childless_attr_showme.attr, + &childless_attr_storeme.attr, + &childless_attr_description.attr, + NULL, +}; + +static ssize_t childless_attr_show(struct config_item *item, + struct configfs_attribute *attr, + char *page) +{ + struct childless *childless = to_childless(item); + struct childless_attribute *childless_attr = + container_of(attr, struct childless_attribute, attr); + ssize_t ret = 0; + + if (childless_attr->show) + ret = childless_attr->show(childless, page); + return ret; +} + +static ssize_t childless_attr_store(struct config_item *item, + struct configfs_attribute *attr, + const char *page, size_t count) +{ + struct childless *childless = to_childless(item); + struct childless_attribute *childless_attr = + container_of(attr, struct childless_attribute, attr); + ssize_t ret = -EINVAL; + + if (childless_attr->store) + ret = childless_attr->store(childless, page, count); + return ret; +} + +static struct configfs_item_operations childless_item_ops = { + .show_attribute = childless_attr_show, + .store_attribute = childless_attr_store, +}; + +static struct config_item_type childless_type = { + .ct_item_ops = &childless_item_ops, + .ct_attrs = childless_attrs, + .ct_owner = THIS_MODULE, +}; + +static struct childless childless_subsys = { + .subsys = { + .su_group = { + .cg_item = { + .ci_namebuf = "01-childless", + .ci_type = &childless_type, + }, + }, + }, +}; + + +/* ----------------------------------------------------------------- */ + +/* + * 02-simple-children + * + * This example merely has a simple one-attribute child. Note that + * there is no extra attribute structure, as the child's attribute is + * known from the get-go. Also, there is no container for the + * subsystem, as it has no attributes of its own. + */ + +struct simple_child { + struct config_item item; + int storeme; +}; + +static inline struct simple_child *to_simple_child(struct config_item *item) +{ + return item ? container_of(item, struct simple_child, item) : NULL; +} + +static struct configfs_attribute simple_child_attr_storeme = { + .ca_owner = THIS_MODULE, + .ca_name = "storeme", + .ca_mode = S_IRUGO | S_IWUSR, +}; + +static struct configfs_attribute *simple_child_attrs[] = { + &simple_child_attr_storeme, + NULL, +}; + +static ssize_t simple_child_attr_show(struct config_item *item, + struct configfs_attribute *attr, + char *page) +{ + ssize_t count; + struct simple_child *simple_child = to_simple_child(item); + + count = sprintf(page, "%d\n", simple_child->storeme); + + return count; +} + +static ssize_t simple_child_attr_store(struct config_item *item, + struct configfs_attribute *attr, + const char *page, size_t count) +{ + struct simple_child *simple_child = to_simple_child(item); + unsigned long tmp; + char *p = (char *) page; + + tmp = simple_strtoul(p, &p, 10); + if (!p || (*p && (*p != '\n'))) + return -EINVAL; + + if (tmp > INT_MAX) + return -ERANGE; + + simple_child->storeme = tmp; + + return count; +} + +static void simple_child_release(struct config_item *item) +{ + kfree(to_simple_child(item)); +} + +static struct configfs_item_operations simple_child_item_ops = { + .release = simple_child_release, + .show_attribute = simple_child_attr_show, + .store_attribute = simple_child_attr_store, +}; + +static struct config_item_type simple_child_type = { + .ct_item_ops = &simple_child_item_ops, + .ct_attrs = simple_child_attrs, + .ct_owner = THIS_MODULE, +}; + + +static struct config_item *simple_children_make_item(struct config_group *group, const char *name) +{ + struct simple_child *simple_child; + + simple_child = kmalloc(sizeof(struct simple_child), GFP_KERNEL); + if (!simple_child) + return NULL; + + memset(simple_child, 0, sizeof(struct simple_child)); + + config_item_init_type_name(&simple_child->item, name, + &simple_child_type); + + simple_child->storeme = 0; + + return &simple_child->item; +} + +static struct configfs_attribute simple_children_attr_description = { + .ca_owner = THIS_MODULE, + .ca_name = "description", + .ca_mode = S_IRUGO, +}; + +static struct configfs_attribute *simple_children_attrs[] = { + &simple_children_attr_description, + NULL, +}; + +static ssize_t simple_children_attr_show(struct config_item *item, + struct configfs_attribute *attr, + char *page) +{ + return sprintf(page, +"[02-simple-children]\n" +"\n" +"This subsystem allows the creation of child config_items. These\n" +"items have only one attribute that is readable and writeable.\n"); +} + +static struct configfs_item_operations simple_children_item_ops = { + .show_attribute = simple_children_attr_show, +}; + +/* + * Note that, since no extra work is required on ->drop_item(), + * no ->drop_item() is provided. + */ +static struct configfs_group_operations simple_children_group_ops = { + .make_item = simple_children_make_item, +}; + +static struct config_item_type simple_children_type = { + .ct_item_ops = &simple_children_item_ops, + .ct_group_ops = &simple_children_group_ops, + .ct_attrs = simple_children_attrs, +}; + +static struct configfs_subsystem simple_children_subsys = { + .su_group = { + .cg_item = { + .ci_namebuf = "02-simple-children", + .ci_type = &simple_children_type, + }, + }, +}; + + +/* ----------------------------------------------------------------- */ + +/* + * 03-group-children + * + * This example reuses the simple_children group from above. However, + * the simple_children group is not the subsystem itself, it is a + * child of the subsystem. Creation of a group in the subsystem creates + * a new simple_children group. That group can then have simple_child + * children of its own. + */ + +struct simple_children { + struct config_group group; +}; + +static struct config_group *group_children_make_group(struct config_group *group, const char *name) +{ + struct simple_children *simple_children; + + simple_children = kmalloc(sizeof(struct simple_children), + GFP_KERNEL); + if (!simple_children) + return NULL; + + memset(simple_children, 0, sizeof(struct simple_children)); + + config_group_init_type_name(&simple_children->group, name, + &simple_children_type); + + return &simple_children->group; +} + +static struct configfs_attribute group_children_attr_description = { + .ca_owner = THIS_MODULE, + .ca_name = "description", + .ca_mode = S_IRUGO, +}; + +static struct configfs_attribute *group_children_attrs[] = { + &group_children_attr_description, + NULL, +}; + +static ssize_t group_children_attr_show(struct config_item *item, + struct configfs_attribute *attr, + char *page) +{ + return sprintf(page, +"[03-group-children]\n" +"\n" +"This subsystem allows the creation of child config_groups. These\n" +"groups are like the subsystem simple-children.\n"); +} + +static struct configfs_item_operations group_children_item_ops = { + .show_attribute = group_children_attr_show, +}; + +/* + * Note that, since no extra work is required on ->drop_item(), + * no ->drop_item() is provided. + */ +static struct configfs_group_operations group_children_group_ops = { + .make_group = group_children_make_group, +}; + +static struct config_item_type group_children_type = { + .ct_item_ops = &group_children_item_ops, + .ct_group_ops = &group_children_group_ops, + .ct_attrs = group_children_attrs, +}; + +static struct configfs_subsystem group_children_subsys = { + .su_group = { + .cg_item = { + .ci_namebuf = "03-group-children", + .ci_type = &group_children_type, + }, + }, +}; + +/* ----------------------------------------------------------------- */ + +/* + * We're now done with our subsystem definitions. + * For convenience in this module, here's a list of them all. It + * allows the init function to easily register them. Most modules + * will only have one subsystem, and will only call register_subsystem + * on it directly. + */ +static struct configfs_subsystem *example_subsys[] = { + &childless_subsys.subsys, + &simple_children_subsys, + &group_children_subsys, + NULL, +}; + +static int __init configfs_example_init(void) +{ + int ret; + int i; + struct configfs_subsystem *subsys; + + for (i = 0; example_subsys[i]; i++) { + subsys = example_subsys[i]; + + config_group_init(&subsys->su_group); + init_MUTEX(&subsys->su_sem); + ret = configfs_register_subsystem(subsys); + if (ret) { + printk(KERN_ERR "Error %d while registering subsystem %s\n", + ret, + subsys->su_group.cg_item.ci_namebuf); + goto out_unregister; + } + } + + return 0; + +out_unregister: + for (; i >= 0; i--) { + configfs_unregister_subsystem(example_subsys[i]); + } + + return ret; +} + +static void __exit configfs_example_exit(void) +{ + int i; + + for (i = 0; example_subsys[i]; i++) { + configfs_unregister_subsystem(example_subsys[i]); + } +} + +module_init(configfs_example_init); +module_exit(configfs_example_exit); +MODULE_LICENSE("GPL"); -- cgit v1.2.3 From 8df08c89c668e1bd922a053fdb5ba1fadbecbb38 Mon Sep 17 00:00:00 2001 From: Mark Fasheh Date: Thu, 15 Dec 2005 14:31:23 -0800 Subject: [PATCH] OCFS2: The Second Oracle Cluster Filesystem dlmfs: A minimal dlm userspace interface implemented via a virtual file system. Most of the OCFS2 tools make use of this to take cluster locks when doing operations on the file system. Signed-off-by: Mark Fasheh Signed-off-by: Kurt Hackel --- Documentation/filesystems/00-INDEX | 2 + Documentation/filesystems/dlmfs.txt | 130 ++++++++++++++++++++++++++++++++++++ 2 files changed, 132 insertions(+) create mode 100644 Documentation/filesystems/dlmfs.txt (limited to 'Documentation') diff --git a/Documentation/filesystems/00-INDEX b/Documentation/filesystems/00-INDEX index 628f8a7adb8..d9b0a069186 100644 --- a/Documentation/filesystems/00-INDEX +++ b/Documentation/filesystems/00-INDEX @@ -18,6 +18,8 @@ cramfs.txt - info on the cram filesystem for small storage (ROMs etc) devfs/ - directory containing devfs documentation. +dlmfs.txt + - info on the userspace interface to the OCFS2 DLM. ext2.txt - info, mount options and specifications for the Ext2 filesystem. fat_cvf.txt diff --git a/Documentation/filesystems/dlmfs.txt b/Documentation/filesystems/dlmfs.txt new file mode 100644 index 00000000000..9afab845a90 --- /dev/null +++ b/Documentation/filesystems/dlmfs.txt @@ -0,0 +1,130 @@ +dlmfs +================== +A minimal DLM userspace interface implemented via a virtual file +system. + +dlmfs is built with OCFS2 as it requires most of its infrastructure. + +Project web page: http://oss.oracle.com/projects/ocfs2 +Tools web page: http://oss.oracle.com/projects/ocfs2-tools +OCFS2 mailing lists: http://oss.oracle.com/projects/ocfs2/mailman/ + +All code copyright 2005 Oracle except when otherwise noted. + +CREDITS +======= + +Some code taken from ramfs which is Copyright (C) 2000 Linus Torvalds +and Transmeta Corp. + +Mark Fasheh + +Caveats +======= +- Right now it only works with the OCFS2 DLM, though support for other + DLM implementations should not be a major issue. + +Mount options +============= +None + +Usage +===== + +If you're just interested in OCFS2, then please see ocfs2.txt. The +rest of this document will be geared towards those who want to use +dlmfs for easy to setup and easy to use clustered locking in +userspace. + +Setup +===== + +dlmfs requires that the OCFS2 cluster infrastructure be in +place. Please download ocfs2-tools from the above url and configure a +cluster. + +You'll want to start heartbeating on a volume which all the nodes in +your lockspace can access. The easiest way to do this is via +ocfs2_hb_ctl (distributed with ocfs2-tools). Right now it requires +that an OCFS2 file system be in place so that it can automatically +find it's heartbeat area, though it will eventually support heartbeat +against raw disks. + +Please see the ocfs2_hb_ctl and mkfs.ocfs2 manual pages distributed +with ocfs2-tools. + +Once you're heartbeating, DLM lock 'domains' can be easily created / +destroyed and locks within them accessed. + +Locking +======= + +Users may access dlmfs via standard file system calls, or they can use +'libo2dlm' (distributed with ocfs2-tools) which abstracts the file +system calls and presents a more traditional locking api. + +dlmfs handles lock caching automatically for the user, so a lock +request for an already acquired lock will not generate another DLM +call. Userspace programs are assumed to handle their own local +locking. + +Two levels of locks are supported - Shared Read, and Exlcusive. +Also supported is a Trylock operation. + +For information on the libo2dlm interface, please see o2dlm.h, +distributed with ocfs2-tools. + +Lock value blocks can be read and written to a resource via read(2) +and write(2) against the fd obtained via your open(2) call. The +maximum currently supported LVB length is 64 bytes (though that is an +OCFS2 DLM limitation). Through this mechanism, users of dlmfs can share +small amounts of data amongst their nodes. + +mkdir(2) signals dlmfs to join a domain (which will have the same name +as the resulting directory) + +rmdir(2) signals dlmfs to leave the domain + +Locks for a given domain are represented by regular inodes inside the +domain directory. Locking against them is done via the open(2) system +call. + +The open(2) call will not return until your lock has been granted or +an error has occurred, unless it has been instructed to do a trylock +operation. If the lock succeeds, you'll get an fd. + +open(2) with O_CREAT to ensure the resource inode is created - dlmfs does +not automatically create inodes for existing lock resources. + +Open Flag Lock Request Type +--------- ----------------- +O_RDONLY Shared Read +O_RDWR Exclusive + +Open Flag Resulting Locking Behavior +--------- -------------------------- +O_NONBLOCK Trylock operation + +You must provide exactly one of O_RDONLY or O_RDWR. + +If O_NONBLOCK is also provided and the trylock operation was valid but +could not lock the resource then open(2) will return ETXTBUSY. + +close(2) drops the lock associated with your fd. + +Modes passed to mkdir(2) or open(2) are adhered to locally. Chown is +supported locally as well. This means you can use them to restrict +access to the resources via dlmfs on your local node only. + +The resource LVB may be read from the fd in either Shared Read or +Exclusive modes via the read(2) system call. It can be written via +write(2) only when open in Exclusive mode. + +Once written, an LVB will be visible to other nodes who obtain Read +Only or higher level locks on the resource. + +See Also +======== +http://opendlm.sourceforge.net/cvsmirror/opendlm/docs/dlmbook_final.pdf + +For more information on the VMS distributed locking API. -- cgit v1.2.3 From ccd979bdbce9fba8412beb3f1de68a9d0171b12c Mon Sep 17 00:00:00 2001 From: Mark Fasheh Date: Thu, 15 Dec 2005 14:31:24 -0800 Subject: [PATCH] OCFS2: The Second Oracle Cluster Filesystem The OCFS2 file system module. Signed-off-by: Mark Fasheh Signed-off-by: Kurt Hackel --- Documentation/filesystems/00-INDEX | 2 ++ Documentation/filesystems/ocfs2.txt | 55 +++++++++++++++++++++++++++++++++++++ 2 files changed, 57 insertions(+) create mode 100644 Documentation/filesystems/ocfs2.txt (limited to 'Documentation') diff --git a/Documentation/filesystems/00-INDEX b/Documentation/filesystems/00-INDEX index d9b0a069186..2580ada100a 100644 --- a/Documentation/filesystems/00-INDEX +++ b/Documentation/filesystems/00-INDEX @@ -36,6 +36,8 @@ ntfs.txt - info and mount options for the NTFS filesystem (Windows NT). proc.txt - info on Linux's /proc filesystem. +ocfs2.txt + - info and mount options for the OCFS2 clustered filesystem. romfs.txt - Description of the ROMFS filesystem. smbfs.txt diff --git a/Documentation/filesystems/ocfs2.txt b/Documentation/filesystems/ocfs2.txt new file mode 100644 index 00000000000..f2595caf052 --- /dev/null +++ b/Documentation/filesystems/ocfs2.txt @@ -0,0 +1,55 @@ +OCFS2 filesystem +================== +OCFS2 is a general purpose extent based shared disk cluster file +system with many similarities to ext3. It supports 64 bit inode +numbers, and has automatically extending metadata groups which may +also make it attractive for non-clustered use. + +You'll want to install the ocfs2-tools package in order to at least +get "mount.ocfs2" and "ocfs2_hb_ctl". + +Project web page: http://oss.oracle.com/projects/ocfs2 +Tools web page: http://oss.oracle.com/projects/ocfs2-tools +OCFS2 mailing lists: http://oss.oracle.com/projects/ocfs2/mailman/ + +All code copyright 2005 Oracle except when otherwise noted. + +CREDITS: +Lots of code taken from ext3 and other projects. + +Authors in alphabetical order: +Joel Becker +Zach Brown +Mark Fasheh +Kurt Hackel +Sunil Mushran +Manish Singh + +Caveats +======= +Features which OCFS2 does not support yet: + - sparse files + - extended attributes + - shared writeable mmap + - loopback is supported, but data written will not + be cluster coherent. + - quotas + - cluster aware flock + - Directory change notification (F_NOTIFY) + - Distributed Caching (F_SETLEASE/F_GETLEASE/break_lease) + - POSIX ACLs + - readpages / writepages (not user visible) + +Mount options +============= + +OCFS2 supports the following mount options: +(*) == default + +barrier=1 This enables/disables barriers. barrier=0 disables it, + barrier=1 enables it. +errors=remount-ro(*) Remount the filesystem read-only on an error. +errors=panic Panic and halt the machine if an error occurs. +intr (*) Allow signals to interrupt cluster operations. +nointr Do not allow signals to interrupt cluster + operations. -- cgit v1.2.3 From 89cee8b1cbb9dac40c92ef1968aea2b45f82fd18 Mon Sep 17 00:00:00 2001 From: Herbert Xu Date: Tue, 13 Dec 2005 23:14:27 -0800 Subject: [IPV4]: Safer reassembly Another spin of Herbert Xu's "safer ip reassembly" patch for 2.6.16. (The original patch is here: http://marc.theaimsgroup.com/?l=linux-netdev&m=112281936522415&w=2 and my only contribution is to have tested it.) This patch (optionally) does additional checks before accepting IP fragments, which can greatly reduce the possibility of reassembling fragments which originated from different IP datagrams. Signed-off-by: Herbert Xu Signed-off-by: Arthur Kepner Signed-off-by: David S. Miller --- Documentation/networking/ip-sysctl.txt | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index ebc09a159f6..2b7cf19a06a 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -46,6 +46,29 @@ ipfrag_secret_interval - INTEGER for the hash secret) for IP fragments. Default: 600 +ipfrag_max_dist - INTEGER + ipfrag_max_dist is a non-negative integer value which defines the + maximum "disorder" which is allowed among fragments which share a + common IP source address. Note that reordering of packets is + not unusual, but if a large number of fragments arrive from a source + IP address while a particular fragment queue remains incomplete, it + probably indicates that one or more fragments belonging to that queue + have been lost. When ipfrag_max_dist is positive, an additional check + is done on fragments before they are added to a reassembly queue - if + ipfrag_max_dist (or more) fragments have arrived from a particular IP + address between additions to any IP fragment queue using that source + address, it's presumed that one or more fragments in the queue are + lost. The existing fragment queue will be dropped, and a new one + started. An ipfrag_max_dist value of zero disables this check. + + Using a very small value, e.g. 1 or 2, for ipfrag_max_dist can + result in unnecessarily dropping fragment queues when normal + reordering of packets occurs, which could lead to poor application + performance. Using a very large value, e.g. 50000, increases the + likelihood of incorrectly reassembling IP fragments that originate + from different IP datagrams, which could result in data corruption. + Default: 64 + INET peer storage: inet_peer_threshold - INTEGER -- cgit v1.2.3 From ddae41be6145f5f9cb4e6df35661a09121b90672 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Wed, 16 Nov 2005 13:41:28 -0800 Subject: [PATCH] USB: reorg some functions out of the main usb.c file This will make the dynamic-id stuff easier to do, as it will be self-contained. No logic was changed at all. Signed-off-by: Greg Kroah-Hartman --- Documentation/DocBook/usb.tmpl | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/usb.tmpl b/Documentation/DocBook/usb.tmpl index 15ce0f21e5e..320af25de3a 100644 --- a/Documentation/DocBook/usb.tmpl +++ b/Documentation/DocBook/usb.tmpl @@ -253,6 +253,7 @@ !Edrivers/usb/core/urb.c !Edrivers/usb/core/message.c !Edrivers/usb/core/file.c +!Edrivers/usb/core/driver.c !Edrivers/usb/core/usb.c !Edrivers/usb/core/hub.c -- cgit v1.2.3 From 312c004d36ce6c739512bac83b452f4c20ab1f62 Mon Sep 17 00:00:00 2001 From: Kay Sievers Date: Wed, 16 Nov 2005 09:00:00 +0100 Subject: [PATCH] driver core: replace "hotplug" by "uevent" Leave the overloaded "hotplug" word to susbsystems which are handling real devices. The driver core does not "plug" anything, it just exports the state to userspace and generates events. Signed-off-by: Kay Sievers Signed-off-by: Greg Kroah-Hartman --- Documentation/powerpc/eeh-pci-error-recovery.txt | 31 ++++++++++++------------ 1 file changed, 16 insertions(+), 15 deletions(-) (limited to 'Documentation') diff --git a/Documentation/powerpc/eeh-pci-error-recovery.txt b/Documentation/powerpc/eeh-pci-error-recovery.txt index e75d7474322..67a11a36270 100644 --- a/Documentation/powerpc/eeh-pci-error-recovery.txt +++ b/Documentation/powerpc/eeh-pci-error-recovery.txt @@ -115,7 +115,7 @@ Current PPC64 Linux EEH Implementation At this time, a generic EEH recovery mechanism has been implemented, so that individual device drivers do not need to be modified to support EEH recovery. This generic mechanism piggy-backs on the PCI hotplug -infrastructure, and percolates events up through the hotplug/udev +infrastructure, and percolates events up through the userspace/udev infrastructure. Followiing is a detailed description of how this is accomplished. @@ -172,7 +172,7 @@ A handler for the EEH notifier_block events is implemented in drivers/pci/hotplug/pSeries_pci.c, called handle_eeh_events(). It saves the device BAR's and then calls rpaphp_unconfig_pci_adapter(). This last call causes the device driver for the card to be stopped, -which causes hotplug events to go out to user space. This triggers +which causes uevents to go out to user space. This triggers user-space scripts that might issue commands such as "ifdown eth0" for ethernet cards, and so on. This handler then sleeps for 5 seconds, hoping to give the user-space scripts enough time to complete. @@ -258,29 +258,30 @@ rpa_php_unconfig_pci_adapter() { // in rpaphp_pci.c calls pci_destroy_dev (struct pci_dev *) { calls - device_unregister (&dev->dev) { // in /drivers/base/core.c + device_unregister (&dev->dev) { // in /drivers/base/core.c calls - device_del(struct device * dev) { // in /drivers/base/core.c + device_del(struct device * dev) { // in /drivers/base/core.c calls - kobject_del() { //in /libs/kobject.c + kobject_del() { //in /libs/kobject.c calls - kobject_hotplug() { // in /libs/kobject.c + kobject_uevent() { // in /libs/kobject.c calls - kset_hotplug() { // in /lib/kobject.c + kset_uevent() { // in /lib/kobject.c calls - kset->hotplug_ops->hotplug() which is really just + kset->uevent_ops->uevent() // which is really just a call to - dev_hotplug() { // in /drivers/base/core.c + dev_uevent() { // in /drivers/base/core.c calls - dev->bus->hotplug() which is really just a call to - pci_hotplug () { // in drivers/pci/hotplug.c + dev->bus->uevent() which is really just a call to + pci_uevent () { // in drivers/pci/hotplug.c which prints device name, etc.... } } - then kset_hotplug() calls - call_usermodehelper () with - argv[0]=hotplug_path[] which is "/sbin/hotplug" - --> event to userspace, + then kobject_uevent() sends a netlink uevent to userspace + --> userspace uevent + (during early boot, nobody listens to netlink events and + kobject_uevent() executes uevent_helper[], which runs the + event process /sbin/hotplug) } } kobject_del() then calls sysfs_remove_dir(), which would -- cgit v1.2.3 From 98e4c28b7ec390c2dad6a4c69d69629c0f7e8b10 Mon Sep 17 00:00:00 2001 From: Dominik Brodowski Date: Mon, 14 Nov 2005 21:21:18 +0100 Subject: [PATCH] pcmcia: new suspend core Move the suspend and resume methods out of the event handler, and into special functions. Also use these functions for pre- and post-reset, as almost all drivers already do, and the remaining ones can easily be converted. Bugfix to include/pcmcia/ds.c Signed-off-by: Andrew Morton Signed-off-by: Dominik Brodowski --- Documentation/pcmcia/driver-changes.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/pcmcia/driver-changes.txt b/Documentation/pcmcia/driver-changes.txt index 403e7b4dcdd..5c822f54d46 100644 --- a/Documentation/pcmcia/driver-changes.txt +++ b/Documentation/pcmcia/driver-changes.txt @@ -1,5 +1,11 @@ This file details changes in 2.6 which affect PCMCIA card driver authors: +* Move suspend, resume and reset out of event handler (as of 2.6.16) + int (*suspend) (struct pcmcia_device *dev); + int (*resume) (struct pcmcia_device *dev); + should be initialized in struct pcmcia_driver, and handle + (SUSPEND == RESET_PHYSICAL) and (RESUME == CARD_RESET) events + * event handler initialization in struct pcmcia_driver (as of 2.6.13) The event handler is notified of all events, and must be initialized as the event() callback in the driver's struct pcmcia_driver. -- cgit v1.2.3 From cc3b4866bee996c922e875b8c8efe9f0d8803aae Mon Sep 17 00:00:00 2001 From: Dominik Brodowski Date: Mon, 14 Nov 2005 21:23:14 +0100 Subject: [PATCH] pcmcia: unify detach, REMOVAL_EVENT handlers into one remove callback Unify the "detach" and REMOVAL_EVENT handlers to one "remove" function. Old functionality is preserved, for the moment. Signed-off-by: Dominik Brodowski --- Documentation/pcmcia/driver-changes.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/pcmcia/driver-changes.txt b/Documentation/pcmcia/driver-changes.txt index 5c822f54d46..45c25c7a344 100644 --- a/Documentation/pcmcia/driver-changes.txt +++ b/Documentation/pcmcia/driver-changes.txt @@ -1,5 +1,8 @@ This file details changes in 2.6 which affect PCMCIA card driver authors: +* Unify detach and REMOVAL event code (as of 2.6.16) + void (*remove) (struct pcmcia_device *dev); + * Move suspend, resume and reset out of event handler (as of 2.6.16) int (*suspend) (struct pcmcia_device *dev); int (*resume) (struct pcmcia_device *dev); -- cgit v1.2.3 From f8cfa618dccbdc6dab5297f75779566a388a98fd Mon Sep 17 00:00:00 2001 From: Dominik Brodowski Date: Mon, 14 Nov 2005 21:25:51 +0100 Subject: [PATCH] pcmcia: unify attach, EVENT_CARD_INSERTION handlers into one probe callback Unify the EVENT_CARD_INSERTION and "attach" callbacks to one unified probe() callback. As all in-kernel drivers are changed to this new callback, there will be no temporary backwards-compatibility. Inside a probe() function, each driver _must_ set struct pcmcia_device *p_dev->instance and instance->handle correctly. With these patches, the basic driver interface for 16-bit PCMCIA drivers now has the classic four callbacks known also from other buses: int (*probe) (struct pcmcia_device *dev); void (*remove) (struct pcmcia_device *dev); int (*suspend) (struct pcmcia_device *dev); int (*resume) (struct pcmcia_device *dev); Signed-off-by: Dominik Brodowski --- Documentation/pcmcia/driver-changes.txt | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/pcmcia/driver-changes.txt b/Documentation/pcmcia/driver-changes.txt index 45c25c7a344..97420f08c78 100644 --- a/Documentation/pcmcia/driver-changes.txt +++ b/Documentation/pcmcia/driver-changes.txt @@ -1,7 +1,9 @@ This file details changes in 2.6 which affect PCMCIA card driver authors: -* Unify detach and REMOVAL event code (as of 2.6.16) - void (*remove) (struct pcmcia_device *dev); +* Unify detach and REMOVAL event code, as well as attach and INSERTION + code (as of 2.6.16) + void (*remove) (struct pcmcia_device *dev); + int (*probe) (struct pcmcia_device *dev); * Move suspend, resume and reset out of event handler (as of 2.6.16) int (*suspend) (struct pcmcia_device *dev); -- cgit v1.2.3 From 07421cabdc62519d0f747149b7c9b425b4d746cd Mon Sep 17 00:00:00 2001 From: Grant Coady Date: Sun, 6 Nov 2005 23:13:06 +0100 Subject: [PATCH] hwmon: remove deprecated sysfs names of adm1025 and adm1026 drivers, hwmon, adm1025 and adm1026: remove deprecated sysfs names. these names have been listed for removal for six months, time for them to go Signed-off-by: Grant Coady Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/feature-removal-schedule.txt | 9 --------- 1 file changed, 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 9b743198f77..cb13b963f7a 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -82,15 +82,6 @@ Who: Mauro Carvalho Chehab --------------------------- -What: i2c sysfs name change: in1_ref, vid deprecated in favour of cpu0_vid -When: November 2005 -Files: drivers/i2c/chips/adm1025.c, drivers/i2c/chips/adm1026.c -Why: Match the other drivers' name for the same function, duplicate names - will be available until removal of old names. -Who: Grant Coady - ---------------------------- - What: remove EXPORT_SYMBOL(panic_timeout) When: April 2006 Files: kernel/panic.c -- cgit v1.2.3 From 5b319400f5e2cd31a82b38405856ff2b46a9bb83 Mon Sep 17 00:00:00 2001 From: "Mark M. Hoffman" Date: Sat, 26 Nov 2005 20:10:56 +0100 Subject: [PATCH] hwmon: Clarify the W83627THF VID documentation This patch clarifies the W83627THF VID documentation. Signed-off-by: Mark M. Hoffman Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/hwmon/w83627hf | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/w83627hf b/Documentation/hwmon/w83627hf index 78f37c2d602..5d23776e990 100644 --- a/Documentation/hwmon/w83627hf +++ b/Documentation/hwmon/w83627hf @@ -54,13 +54,16 @@ If you really want i2c accesses for these Super I/O chips, use the w83781d driver. However this is not the preferred method now that this ISA driver has been developed. -Technically, the w83627thf does not support a VID reading. However, it's -possible or even likely that your mainboard maker has routed these signals -to a specific set of general purpose IO pins (the Asus P4C800-E is one such -board). The w83627thf driver now interprets these as VID. If the VID on -your board doesn't work, first see doc/vid in the lm_sensors package. If -that still doesn't help, email us at lm-sensors@lm-sensors.org. +The w83627_HF_ uses pins 110-106 as VID0-VID4. The w83627_THF_ uses the +same pins as GPIO[0:4]. Technically, the w83627_THF_ does not support a +VID reading. However the two chips have the identical 128 pin package. So, +it is possible or even likely for a w83627thf to have the VID signals routed +to these pins despite their not being labeled for that purpose. Therefore, +the w83627thf driver interprets these as VID. If the VID on your board +doesn't work, first see doc/vid in the lm_sensors package[1]. If that still +doesn't help, you may just ignore the bogus VID reading with no harm done. -For further information on this driver see the w83781d driver -documentation. +For further information on this driver see the w83781d driver documentation. + +[1] http://www2.lm-sensors.nu/~lm78/cvs/browse.cgi/lm_sensors2/doc/vid -- cgit v1.2.3 From 1d26f455eb0db0bf4d4b7177547f4310b645a32a Mon Sep 17 00:00:00 2001 From: Peter Korsgaard Date: Sat, 26 Nov 2005 20:18:43 +0100 Subject: [PATCH] i2c: Add support for Barco LPT->DVI to i2c-parport The following patch adds support for the Barco LPT->DVI I2C adapter to the i2c-parport driver. Signed-off-by: Peter Korsgaard Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/i2c/busses/i2c-parport | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/i2c/busses/i2c-parport b/Documentation/i2c/busses/i2c-parport index 9f1d0082da1..d9f23c0763f 100644 --- a/Documentation/i2c/busses/i2c-parport +++ b/Documentation/i2c/busses/i2c-parport @@ -17,6 +17,7 @@ It currently supports the following devices: * Velleman K8000 adapter * ELV adapter * Analog Devices evaluation boards (ADM1025, ADM1030, ADM1031, ADM1032) + * Barco LPT->DVI (K5800236) adapter These devices use different pinout configurations, so you have to tell the driver what you have, using the type module parameter. There is no -- cgit v1.2.3 From 8a9947552d43b0d20d5fa23ac0ba435d526be454 Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Sat, 26 Nov 2005 20:28:06 +0100 Subject: [PATCH] i2c: Drop i2c_driver.flags, 2 of 3 Just about every i2c chip driver sets the I2C_DF_NOTIFY flag, so we can simply make it the default and drop the flag. If any driver really doesn't want to be notified when i2c adapters are added, that driver can simply omit to set .attach_adapter. This approach is also more robust as it prevents accidental NULL pointer dereferences. Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/i2c/porting-clients | 3 +++ Documentation/i2c/writing-clients | 5 ----- 2 files changed, 3 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/i2c/porting-clients b/Documentation/i2c/porting-clients index 184fac2377a..64c610bf2fb 100644 --- a/Documentation/i2c/porting-clients +++ b/Documentation/i2c/porting-clients @@ -109,6 +109,9 @@ Technical changes: there is a MODULE_LICENSE() line, at the bottom of the file (after MODULE_AUTHOR() and MODULE_DESCRIPTION(), in this order). +* [Driver] The flags field of the i2c_driver structure is gone. + I2C_DF_NOTIFY is now the default behavior. + Coding policy: * [Copyright] Use (C), not (c), for copyright. diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients index d19993cc060..59d2c169cd6 100644 --- a/Documentation/i2c/writing-clients +++ b/Documentation/i2c/writing-clients @@ -27,7 +27,6 @@ address. static struct i2c_driver foo_driver = { .owner = THIS_MODULE, .name = "Foo version 2.3 driver", - .flags = I2C_DF_NOTIFY, .attach_adapter = &foo_attach_adapter, .detach_client = &foo_detach_client, .command = &foo_command /* may be NULL */ @@ -36,10 +35,6 @@ static struct i2c_driver foo_driver = { The name field must match the driver name, including the case. It must not contain spaces, and may be up to 31 characters long. -Don't worry about the flags field; just put I2C_DF_NOTIFY into it. This -means that your driver will be notified when new adapters are found. -This is almost always what you want. - All other fields are for call-back functions which will be explained below. -- cgit v1.2.3 From cf02df770228350254251fde520007a2709db785 Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Sat, 26 Nov 2005 21:03:41 +0100 Subject: [PATCH] i2c: Rework client usage count, 3 of 3 Do not limit the usage count of i2c clients to 1. In other words, change the client usage count behavior from the old I2C_CLIENT_ALLOW_USE to the old I2C_CLIENT_ALLOW_MULTIPLE_USE. The rationale is that no driver actually needs the limiting behavior, and the unlimiting behavior is slightly easier to implement. Update the documentation to reflect this change. Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/i2c/porting-clients | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/i2c/porting-clients b/Documentation/i2c/porting-clients index 64c610bf2fb..6b07f23039d 100644 --- a/Documentation/i2c/porting-clients +++ b/Documentation/i2c/porting-clients @@ -92,6 +92,7 @@ Technical changes: Drop client->id. Drop any 24RF08 corruption prevention you find, as this is now done at the i2c-core level, and doing it twice voids it. + Don't add I2C_CLIENT_ALLOW_USE to client->flags, it's the default now. * [Init] Limits must not be set by the driver (can be done later in user-space). Chip should not be reset default (although a module -- cgit v1.2.3 From 92b429461228f0f06a994dd3d4ccf1c9ff7596bd Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Sat, 26 Nov 2005 21:05:17 +0100 Subject: [PATCH] i2c: Chip driver porting guide update Update Documentation/i2c/porting-clients. Many recent changes to the i2c and hwmon subsystems were never reported there. Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/i2c/porting-clients | 79 ++++++++++++++++++++++----------------- 1 file changed, 44 insertions(+), 35 deletions(-) (limited to 'Documentation') diff --git a/Documentation/i2c/porting-clients b/Documentation/i2c/porting-clients index 6b07f23039d..856274fc8e9 100644 --- a/Documentation/i2c/porting-clients +++ b/Documentation/i2c/porting-clients @@ -1,10 +1,13 @@ -Revision 5, 2005-07-29 +Revision 6, 2005-11-20 Jean Delvare Greg KH This is a guide on how to convert I2C chip drivers from Linux 2.4 to Linux 2.6. I have been using existing drivers (lm75, lm78) as examples. Then I converted a driver myself (lm83) and updated this document. +Note that this guide is strongly oriented towards hardware monitoring +drivers. Many points are still valid for other type of drivers, but +others may be irrelevant. There are two sets of points below. The first set concerns technical changes. The second set concerns coding policy. Both are mandatory. @@ -22,16 +25,20 @@ Technical changes: #include #include #include + #include #include + #include /* for ISA drivers */ #include /* for hardware monitoring drivers */ #include #include /* if you need VRM support */ + #include /* for class registration */ #include /* if you have I/O operations */ Please respect this inclusion order. Some extra headers may be required for a given driver (e.g. "lm75.h"). * [Addresses] SENSORS_I2C_END becomes I2C_CLIENT_END, ISA addresses - are no more handled by the i2c core. + are no more handled by the i2c core. Address ranges are no more + supported either, define each individual address separately. SENSORS_INSMOD_ becomes I2C_CLIENT_INSMOD_. * [Client data] Get rid of sysctl_id. Try using standard names for @@ -48,23 +55,23 @@ Technical changes: int kind); static void lm75_init_client(struct i2c_client *client); static int lm75_detach_client(struct i2c_client *client); - static void lm75_update_client(struct i2c_client *client); + static struct lm75_data lm75_update_device(struct device *dev); * [Sysctl] All sysctl stuff is of course gone (defines, ctl_table and functions). Instead, you have to define show and set functions for each sysfs file. Only define set for writable values. Take a look at an - existing 2.6 driver for details (lm78 for example). Don't forget + existing 2.6 driver for details (it87 for example). Don't forget to define the attributes for each file (this is that step that links callback functions). Use the file names specified in - Documentation/i2c/sysfs-interface for the individual files. Also + Documentation/hwmon/sysfs-interface for the individual files. Also convert the units these files read and write to the specified ones. If you need to add a new type of file, please discuss it on the sensors mailing list by providing a - patch to the Documentation/i2c/sysfs-interface file. + patch to the Documentation/hwmon/sysfs-interface file. * [Attach] For I2C drivers, the attach function should make sure - that the adapter's class has I2C_CLASS_HWMON, using the - following construct: + that the adapter's class has I2C_CLASS_HWMON (or whatever class is + suitable for your driver), using the following construct: if (!(adapter->class & I2C_CLASS_HWMON)) return 0; ISA-only drivers of course don't need this. @@ -72,23 +79,23 @@ Technical changes: * [Detect] As mentioned earlier, the flags parameter is gone. The type_name and client_name strings are replaced by a single - name string, which will be filled with a lowercase, short string - (typically the driver name, e.g. "lm75"). + name string, which will be filled with a lowercase, short string. In i2c-only drivers, drop the i2c_is_isa_adapter check, it's useless. Same for isa-only drivers, as the test would always be true. Only hybrid drivers (which are quite rare) still need it. - The errorN labels are reduced to the number needed. If that number - is 2 (i2c-only drivers), it is advised that the labels are named - exit and exit_free. For i2c+isa drivers, labels should be named - ERROR0, ERROR1 and ERROR2. Don't forget to properly set err before + The labels used for error paths are reduced to the number needed. + It is advised that the labels are given descriptive names such as + exit and exit_free. Don't forget to properly set err before jumping to error labels. By the way, labels should be left-aligned. Use kzalloc instead of kmalloc. Use i2c_set_clientdata to set the client data (as opposed to a direct access to client->data). - Use strlcpy instead of strcpy to copy the client name. + Use strlcpy instead of strcpy or snprintf to copy the client name. Replace the sysctl directory registration by calls to device_create_file. Move the driver initialization before any sysfs file creation. + Register the client with the hwmon class (using hwmon_device_register) + if applicable. Drop client->id. Drop any 24RF08 corruption prevention you find, as this is now done at the i2c-core level, and doing it twice voids it. @@ -96,19 +103,25 @@ Technical changes: * [Init] Limits must not be set by the driver (can be done later in user-space). Chip should not be reset default (although a module - parameter may be used to force is), and initialization should be + parameter may be used to force it), and initialization should be limited to the strictly necessary steps. -* [Detach] Get rid of data, remove the call to - i2c_deregister_entry. Do not log an error message if - i2c_detach_client fails, as i2c-core will now do it for you. +* [Detach] Remove the call to i2c_deregister_entry. Do not log an + error message if i2c_detach_client fails, as i2c-core will now do + it for you. + Unregister from the hwmon class if applicable. -* [Update] Don't access client->data directly, use - i2c_get_clientdata(client) instead. +* [Update] The function prototype changed, it is now + passed a device structure, which you have to convert to a client + using to_i2c_client(dev). The update function should return a + pointer to the client data. + Don't access client->data directly, use i2c_get_clientdata(client) + instead. + Use time_after() instead of direct jiffies comparison. -* [Interface] Init function should not print anything. Make sure - there is a MODULE_LICENSE() line, at the bottom of the file - (after MODULE_AUTHOR() and MODULE_DESCRIPTION(), in this order). +* [Interface] Make sure there is a MODULE_LICENSE() line, at the bottom + of the file (after MODULE_AUTHOR() and MODULE_DESCRIPTION(), in this + order). * [Driver] The flags field of the i2c_driver structure is gone. I2C_DF_NOTIFY is now the default behavior. @@ -118,21 +131,17 @@ Coding policy: * [Copyright] Use (C), not (c), for copyright. * [Debug/log] Get rid of #ifdef DEBUG/#endif constructs whenever you - can. Calls to printk/pr_debug for debugging purposes are replaced - by calls to dev_dbg. Here is an example on how to call it (taken - from lm75_detect): + can. Calls to printk for debugging purposes are replaced by calls to + dev_dbg where possible, else to pr_debug. Here is an example of how + to call it (taken from lm75_detect): dev_dbg(&client->dev, "Starting lm75 update\n"); Replace other printk calls with the dev_info, dev_err or dev_warn function, as appropriate. -* [Constants] Constants defines (registers, conversions, initial - values) should be aligned. This greatly improves readability. - Same goes for variables declarations. Alignments are achieved by the - means of tabs, not spaces. Remember that tabs are set to 8 in the - Linux kernel code. - -* [Structure definition] The name field should be standardized. All - lowercase and as simple as the driver name itself (e.g. "lm75"). +* [Constants] Constants defines (registers, conversions) should be + aligned. This greatly improves readability. + Alignments are achieved by the means of tabs, not spaces. Remember + that tabs are set to 8 in the Linux kernel code. * [Layout] Avoid extra empty lines between comments and what they comment. Respect the coding style (see Documentation/CodingStyle), -- cgit v1.2.3 From d45d204f0c3daa01a393dfe81415573f9459506a Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Sat, 26 Nov 2005 20:55:35 +0100 Subject: [PATCH] i2c: Drop i2c_driver.{owner,name}, 11 of 11 Document the drop of the owner and name fields of the i2c_driver structure. Signed-off-by: Jean Delvare CC: Laurent Riffard Signed-off-by: Greg Kroah-Hartman --- Documentation/i2c/porting-clients | 4 ++++ Documentation/i2c/writing-clients | 6 ++++-- 2 files changed, 8 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/i2c/porting-clients b/Documentation/i2c/porting-clients index 856274fc8e9..f997c72302a 100644 --- a/Documentation/i2c/porting-clients +++ b/Documentation/i2c/porting-clients @@ -125,6 +125,10 @@ Technical changes: * [Driver] The flags field of the i2c_driver structure is gone. I2C_DF_NOTIFY is now the default behavior. + The i2c_driver structure has a driver member, which is itself a + structure, those owner and name members should be initialized to + THIS_MODULE and a driver name string, respectively. i2c_driver + itself has no name member anymore. Coding policy: diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients index 59d2c169cd6..95eed2b2533 100644 --- a/Documentation/i2c/writing-clients +++ b/Documentation/i2c/writing-clients @@ -25,8 +25,10 @@ routines, a client structure specific information like the actual I2C address. static struct i2c_driver foo_driver = { - .owner = THIS_MODULE, - .name = "Foo version 2.3 driver", + .driver = { + .owner = THIS_MODULE, + .name = "foo", + }, .attach_adapter = &foo_attach_adapter, .detach_client = &foo_detach_client, .command = &foo_command /* may be NULL */ -- cgit v1.2.3 From d82c0bf88fa97c1993ea9d6051488e7cb012b440 Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Wed, 7 Dec 2005 21:54:26 +0100 Subject: [PATCH] i2c: Documentation update Update the i2c documentation to reflect the recent change to i2c_add_driver. Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/i2c/porting-clients | 5 ++--- Documentation/i2c/writing-clients | 1 - 2 files changed, 2 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/i2c/porting-clients b/Documentation/i2c/porting-clients index f997c72302a..f03c2a02f80 100644 --- a/Documentation/i2c/porting-clients +++ b/Documentation/i2c/porting-clients @@ -126,9 +126,8 @@ Technical changes: * [Driver] The flags field of the i2c_driver structure is gone. I2C_DF_NOTIFY is now the default behavior. The i2c_driver structure has a driver member, which is itself a - structure, those owner and name members should be initialized to - THIS_MODULE and a driver name string, respectively. i2c_driver - itself has no name member anymore. + structure, those name member should be initialized to a driver name + string. i2c_driver itself has no name member anymore. Coding policy: diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients index 95eed2b2533..27c425ac70a 100644 --- a/Documentation/i2c/writing-clients +++ b/Documentation/i2c/writing-clients @@ -26,7 +26,6 @@ address. static struct i2c_driver foo_driver = { .driver = { - .owner = THIS_MODULE, .name = "foo", }, .attach_adapter = &foo_attach_adapter, -- cgit v1.2.3 From fb687d73fa7685ffeed1a6b24fadb5f4db817783 Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Sun, 18 Dec 2005 16:51:55 +0100 Subject: [PATCH] i2c: update i2c_driver.command documentation Document i2c_driver.command as being deprecated, and don't suggest an empty implementation of this callback as it doesn't make any sense. Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/i2c/writing-clients | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients index 27c425ac70a..3a057c8e550 100644 --- a/Documentation/i2c/writing-clients +++ b/Documentation/i2c/writing-clients @@ -492,17 +492,13 @@ Note that some functions are marked by `__init', and some data structures by `__init_data'. Hose functions and structures can be removed after kernel booting (or module loading) is completed. + Command function ================ A generic ioctl-like function call back is supported. You will seldom -need this. You may even set it to NULL. - - /* No commands defined */ - int foo_command(struct i2c_client *client, unsigned int cmd, void *arg) - { - return 0; - } +need this, and its use is deprecated anyway, so newer design should not +use it. Set it to NULL. Sending and receiving -- cgit v1.2.3 From 7c72ccf09b6debe55b8e049377ad3183ed4f4cb3 Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Sun, 18 Dec 2005 17:25:18 +0100 Subject: [PATCH] i2c: i2c-nforce2 add nforce4 MCP-04 device ID One more supported PCI ID for the i2c-nforce2 driver. Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/i2c/busses/i2c-nforce2 | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/i2c/busses/i2c-nforce2 b/Documentation/i2c/busses/i2c-nforce2 index e379e182e64..d751282d9b2 100644 --- a/Documentation/i2c/busses/i2c-nforce2 +++ b/Documentation/i2c/busses/i2c-nforce2 @@ -5,7 +5,8 @@ Supported adapters: * nForce2 Ultra 400 MCP 10de:0084 * nForce3 Pro150 MCP 10de:00D4 * nForce3 250Gb MCP 10de:00E4 - * nForce4 MCP 10de:0052 + * nForce4 MCP 10de:0052 + * nForce4 MCP-04 10de:0034 Datasheet: not publically available, but seems to be similar to the AMD-8111 SMBus 2.0 adapter. -- cgit v1.2.3 From ff5b8cf1491330836d75eede4e5632caa32b776a Mon Sep 17 00:00:00 2001 From: Tejun Heo Date: Fri, 6 Jan 2006 09:58:37 +0100 Subject: [BLOCK] I/O barrier documentation update Update documentation to match new barrier implementation. Signed-off-by: Tejun Heo Signed-off-by: Jens Axboe --- Documentation/block/biodoc.txt | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt index 303c57a7fad..8e63831971d 100644 --- a/Documentation/block/biodoc.txt +++ b/Documentation/block/biodoc.txt @@ -263,14 +263,8 @@ A flag in the bio structure, BIO_BARRIER is used to identify a barrier i/o. The generic i/o scheduler would make sure that it places the barrier request and all other requests coming after it after all the previous requests in the queue. Barriers may be implemented in different ways depending on the -driver. A SCSI driver for example could make use of ordered tags to -preserve the necessary ordering with a lower impact on throughput. For IDE -this might be two sync cache flush: a pre and post flush when encountering -a barrier write. - -There is a provision for queues to indicate what kind of barriers they -can provide. This is as of yet unmerged, details will be added here once it -is in the kernel. +driver. For more details regarding I/O barriers, please read barrier.txt +in this directory. 1.2.2 Request Priority/Latency -- cgit v1.2.3 From 8d9067bda99c68e1a17d93e78cf3a5a3f67e0c35 Mon Sep 17 00:00:00 2001 From: David Howells Date: Fri, 6 Jan 2006 00:11:24 -0800 Subject: [PATCH] Keys: Remove key duplication Remove the key duplication stuff since there's nothing that uses it, no way to get at it and it's awkward to deal with for LSM purposes. Signed-off-by: David Howells Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/keys.txt | 18 ------------------ 1 file changed, 18 deletions(-) (limited to 'Documentation') diff --git a/Documentation/keys.txt b/Documentation/keys.txt index 31154882000..6304db59bfe 100644 --- a/Documentation/keys.txt +++ b/Documentation/keys.txt @@ -860,24 +860,6 @@ The structure has a number of fields, some of which are mandatory: It is safe to sleep in this method. - (*) int (*duplicate)(struct key *key, const struct key *source); - - If this type of key can be duplicated, then this method should be - provided. It is called to copy the payload attached to the source into the - new key. The data length on the new key will have been updated and the - quota adjusted already. - - This method will be called with the source key's semaphore read-locked to - prevent its payload from being changed, thus RCU constraints need not be - applied to the source key. - - This method does not have to lock the destination key in order to attach a - payload. The fact that KEY_FLAG_INSTANTIATED is not set in key->flags - prevents anything else from gaining access to the key. - - It is safe to sleep in this method. - - (*) int (*update)(struct key *key, const void *data, size_t datalen); If this type of key can be updated, then this method should be provided. -- cgit v1.2.3 From ca0aec0f7a94bf9f07fefa8bfd23282d4e8ceb8a Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Fri, 6 Jan 2006 00:15:56 -0800 Subject: [PATCH] swsusp: make image size limit tunable Make the suspend image size limit tunable via /sys/power/image_size. It is necessary for systems on which there is a limited amount of swap available for suspend. It can also be useful for optimizing performance of swsusp on systems with 1 GB of RAM or more. Signed-off-by: Rafael J. Wysocki Acked-by: Pavel Machek Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/power/interface.txt | 11 +++++++++++ Documentation/power/swsusp.txt | 5 +++++ 2 files changed, 16 insertions(+) (limited to 'Documentation') diff --git a/Documentation/power/interface.txt b/Documentation/power/interface.txt index f5ebda5f427..bd4ffb5bd49 100644 --- a/Documentation/power/interface.txt +++ b/Documentation/power/interface.txt @@ -41,3 +41,14 @@ to. Writing to this file will accept one of It will only change to 'firmware' or 'platform' if the system supports it. +/sys/power/image_size controls the size of the image created by +the suspend-to-disk mechanism. It can be written a string +representing a non-negative integer that will be used as an upper +limit of the image size, in megabytes. The suspend-to-disk mechanism will +do its best to ensure the image size will not exceed that number. However, +if this turns out to be impossible, it will try to suspend anyway using the +smallest image possible. In particular, if "0" is written to this file, the +suspend image will be as small as possible. + +Reading from this file will display the current image size limit, which +is set to 500 MB by default. diff --git a/Documentation/power/swsusp.txt b/Documentation/power/swsusp.txt index b0d50840788..cd0fcd89a6f 100644 --- a/Documentation/power/swsusp.txt +++ b/Documentation/power/swsusp.txt @@ -27,6 +27,11 @@ echo shutdown > /sys/power/disk; echo disk > /sys/power/state echo platform > /sys/power/disk; echo disk > /sys/power/state +If you want to limit the suspend image size to N megabytes, do + +echo N > /sys/power/image_size + +before suspend (it is limited to 500 MB by default). Encrypted suspend image: ------------------------ -- cgit v1.2.3 From 6ff8d8ec06690f4011a6c3ad9e0759b9094f0601 Mon Sep 17 00:00:00 2001 From: NeilBrown Date: Fri, 6 Jan 2006 00:20:15 -0800 Subject: [PATCH] md: allow dirty raid[456] arrays to be started at boot See patch to md.txt for more details Signed-off-by: Neil Brown Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/md.txt | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) (limited to 'Documentation') diff --git a/Documentation/md.txt b/Documentation/md.txt index 23e6cce40f9..1dd0fb6021c 100644 --- a/Documentation/md.txt +++ b/Documentation/md.txt @@ -51,6 +51,30 @@ superblock can be autodetected and run at boot time. The kernel parameter "raid=partitionable" (or "raid=part") means that all auto-detected arrays are assembled as partitionable. +Boot time assembly of degraded/dirty arrays +------------------------------------------- + +If a raid5 or raid6 array is both dirty and degraded, it could have +undetectable data corruption. This is because the fact that it is +'dirty' means that the parity cannot be trusted, and the fact that it +is degraded means that some datablocks are missing and cannot reliably +be reconstructed (due to no parity). + +For this reason, md will normally refuse to start such an array. This +requires the sysadmin to take action to explicitly start the array +desipite possible corruption. This is normally done with + mdadm --assemble --force .... + +This option is not really available if the array has the root +filesystem on it. In order to support this booting from such an +array, md supports a module parameter "start_dirty_degraded" which, +when set to 1, bypassed the checks and will allows dirty degraded +arrays to be started. + +So, to boot with a root filesystem of a dirty degraded raid[56], use + + md-mod.start_dirty_degraded=1 + Superblock formats ------------------ -- cgit v1.2.3 From 3b34380ae8c5df6debd85183c7fa1ac05f79b7d2 Mon Sep 17 00:00:00 2001 From: NeilBrown Date: Fri, 6 Jan 2006 00:20:47 -0800 Subject: [PATCH] md: allow chunk_size to be settable through sysfs ... only before array is started of course. Signed-off-by: Neil Brown Acked-by: Greg KH Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/md.txt | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/md.txt b/Documentation/md.txt index 1dd0fb6021c..9710138d101 100644 --- a/Documentation/md.txt +++ b/Documentation/md.txt @@ -166,6 +166,14 @@ All md devices contain: will be empty. If an array is being resized (not currently possible) this will contain the larger of the old and new sizes. + chunk_size + This is the size if bytes for 'chunks' and is only relevant to + raid levels that involve striping (1,4,5,6,10). The address space + of the array is conceptually divided into chunks and consecutive + chunks are striped onto neighbouring devices. + The size should be atleast PAGE_SIZE (4k) and should be a power + of 2. This can only be set while assembling an array + As component devices are added to an md array, they appear in the 'md' directory as new directories named dev-XXX -- cgit v1.2.3 From a35b0d695d44410eb1734c9abb632725a3138628 Mon Sep 17 00:00:00 2001 From: NeilBrown Date: Fri, 6 Jan 2006 00:20:49 -0800 Subject: [PATCH] md: allow md array component size to be accessed and set via sysfs Signed-off-by: Neil Brown Acked-by: Greg KH Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/md.txt | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/md.txt b/Documentation/md.txt index 9710138d101..0a2e10a4040 100644 --- a/Documentation/md.txt +++ b/Documentation/md.txt @@ -174,6 +174,15 @@ All md devices contain: The size should be atleast PAGE_SIZE (4k) and should be a power of 2. This can only be set while assembling an array + component_size + For arrays with data redundancy (i.e. not raid0, linear, faulty, + multipath), all components must be the same size - or at least + there must a size that they all provide space for. This is a key + part or the geometry of the array. It is measured in sectors + and can be read from here. Writing to this value may resize + the array if the personality supports it (raid1, raid5, raid6), + and if the component drives are large enough. + As component devices are added to an md array, they appear in the 'md' directory as new directories named dev-XXX -- cgit v1.2.3 From 8bb93aaca2062cd54cc2c58c76ee8409cae209a7 Mon Sep 17 00:00:00 2001 From: NeilBrown Date: Fri, 6 Jan 2006 00:20:50 -0800 Subject: [PATCH] md: expose md metadata format in sysfs Allow it to be set to a particular version, or 'none'. Signed-off-by: Neil Brown Acked-by: Greg KH Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/md.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/md.txt b/Documentation/md.txt index 0a2e10a4040..c5512afd591 100644 --- a/Documentation/md.txt +++ b/Documentation/md.txt @@ -183,6 +183,12 @@ All md devices contain: the array if the personality supports it (raid1, raid5, raid6), and if the component drives are large enough. + metadata_version + This indicates the format that is being used to record metadata + about the array. It can be 0.90 (traditional format), 1.0, 1.1, + 1.2 (newer format in varying locations) or "none" indicating that + the kernel isn't managing metadata at all. + As component devices are added to an md array, they appear in the 'md' directory as new directories named dev-XXX -- cgit v1.2.3 From d9d166c2a9d5d01af34396793950aa695883eed4 Mon Sep 17 00:00:00 2001 From: NeilBrown Date: Fri, 6 Jan 2006 00:20:51 -0800 Subject: [PATCH] md: allow array level to be set textually via sysfs Signed-off-by: Neil Brown Acked-by: Greg KH Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/md.txt | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/md.txt b/Documentation/md.txt index c5512afd591..fd43fd2cad2 100644 --- a/Documentation/md.txt +++ b/Documentation/md.txt @@ -189,6 +189,14 @@ All md devices contain: 1.2 (newer format in varying locations) or "none" indicating that the kernel isn't managing metadata at all. + level + The raid 'level' for this array. The name will often (but not + always) be the same as the name of the module that implements the + level. To be auto-loaded the module must have an alias + md-$LEVEL e.g. md-raid5 + This can be written only while the array is being assembled, not + after it is started. + As component devices are added to an md array, they appear in the 'md' directory as new directories named dev-XXX -- cgit v1.2.3 From 4dbcdc751cb25ffca3a8374cbc5ab6de961cc545 Mon Sep 17 00:00:00 2001 From: NeilBrown Date: Fri, 6 Jan 2006 00:20:52 -0800 Subject: [PATCH] md: count corrected read errors per drive Store this total in superblock (As appropriate), and make it available to userspace via sysfs. Signed-off-by: Neil Brown Acked-by: Greg KH Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/md.txt | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/md.txt b/Documentation/md.txt index fd43fd2cad2..a3eadf8e170 100644 --- a/Documentation/md.txt +++ b/Documentation/md.txt @@ -222,6 +222,17 @@ Each directory contains: of being recoverred to This list make grow in future. + errors + An approximate count of read errors that have been detected on + this device but have not caused the device to be evicted from + the array (either because they were corrected or because they + happened while the array was read-only). When using version-1 + metadata, this value persists across restarts of the array. + + This value can be written while assembling an array thus + providing an ongoing count for arrays with metadata managed by + userspace. + An active md device will also contain and entry for each active device in the array. These are named -- cgit v1.2.3 From da943b9912df063322d37b1a1f285460531d481d Mon Sep 17 00:00:00 2001 From: NeilBrown Date: Fri, 6 Jan 2006 00:20:54 -0800 Subject: [PATCH] md: allow md/raid_disks to be settable If array is active, try to reshape, else just set the value. Signed-off-by: Neil Brown Acked-by: Greg KH Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/md.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/md.txt b/Documentation/md.txt index a3eadf8e170..69f742dee00 100644 --- a/Documentation/md.txt +++ b/Documentation/md.txt @@ -165,6 +165,9 @@ All md devices contain: in a fully functional array. If this is not yet known, the file will be empty. If an array is being resized (not currently possible) this will contain the larger of the old and new sizes. + Some raid level (RAID1) allow this value to be set while the + array is active. This will reconfigure the array. Otherwise + it can only be set while assembling an array. chunk_size This is the size if bytes for 'chunks' and is only relevant to -- cgit v1.2.3 From 014236d2b8ec6faea2a6134ab8e019d84d67b524 Mon Sep 17 00:00:00 2001 From: NeilBrown Date: Fri, 6 Jan 2006 00:20:55 -0800 Subject: [PATCH] md: expose device slot information via sysfs This the role that a device has in an array can be viewed and set. Signed-off-by: Neil Brown Acked-by: Greg KH Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/md.txt | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/md.txt b/Documentation/md.txt index 69f742dee00..d525fffc873 100644 --- a/Documentation/md.txt +++ b/Documentation/md.txt @@ -236,6 +236,14 @@ Each directory contains: providing an ongoing count for arrays with metadata managed by userspace. + slot + This gives the role that the device has in the array. It will + either be 'none' if the device is not active in the array + (i.e. is a spare or has failed) or an integer less than the + 'raid_disks' number for the array indicating which possition + it currently fills. This can only be set while assembling an + array. A device for which this is set is assumed to be working. + An active md device will also contain and entry for each active device in the array. These are named -- cgit v1.2.3 From 93c8cad03f02dbd1532a5413bdced25f000d5728 Mon Sep 17 00:00:00 2001 From: NeilBrown Date: Fri, 6 Jan 2006 00:20:56 -0800 Subject: [PATCH] md: export rdev->data_offset via sysfs Signed-off-by: Neil Brown Acked-by: Greg KH Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/md.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/md.txt b/Documentation/md.txt index d525fffc873..866a1a88754 100644 --- a/Documentation/md.txt +++ b/Documentation/md.txt @@ -244,6 +244,12 @@ Each directory contains: it currently fills. This can only be set while assembling an array. A device for which this is set is assumed to be working. + offset + This gives the location in the device (in sectors from the + start) where data from the array will be stored. Any part of + the device before this offset us not touched, unless it is + used for storing metadata (Formats 1.1 and 1.2). + An active md device will also contain and entry for each active device in the array. These are named -- cgit v1.2.3 From 83303b613d00718b07ec0a4dee7c99aa66629d96 Mon Sep 17 00:00:00 2001 From: NeilBrown Date: Fri, 6 Jan 2006 00:21:06 -0800 Subject: [PATCH] md: allow available size of component devices to be set via sysfs Signed-off-by: Neil Brown Acked-by: Greg KH Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/md.txt | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/md.txt b/Documentation/md.txt index 866a1a88754..7b3d471bb9f 100644 --- a/Documentation/md.txt +++ b/Documentation/md.txt @@ -250,6 +250,13 @@ Each directory contains: the device before this offset us not touched, unless it is used for storing metadata (Formats 1.1 and 1.2). + size + The amount of the device, after the offset, that can be used + for storage of data. This will normally be the same as the + component_size. This can be written while assembling an + array. If a value less than the current component_size is + written, component_size will be reduced to this value. + An active md device will also contain and entry for each active device in the array. These are named -- cgit v1.2.3 From 6d7ff7380b2e28c2807da3bf9fa614d91d15bacf Mon Sep 17 00:00:00 2001 From: NeilBrown Date: Fri, 6 Jan 2006 00:21:16 -0800 Subject: [PATCH] md: support adding new devices to md arrays via sysfs Writing major:minor to md/new_dev will bind that device to the array. Signed-off-by: Neil Brown Acked-by: Greg KH Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/md.txt | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/md.txt b/Documentation/md.txt index 7b3d471bb9f..b8d172b254f 100644 --- a/Documentation/md.txt +++ b/Documentation/md.txt @@ -200,6 +200,14 @@ All md devices contain: This can be written only while the array is being assembled, not after it is started. + new_dev + This file can be written but not read. The value written should + be a block device number as major:minor. e.g. 8:0 + This will cause that device to be attached to the array, if it is + available. It will then appear at md/dev-XXX (depending on the + name of the device) and further configuration is then possible. + + As component devices are added to an md array, they appear in the 'md' directory as new directories named dev-XXX -- cgit v1.2.3 From 88202a0c84e1951d6630d1d557d4801a8cc5b5ef Mon Sep 17 00:00:00 2001 From: NeilBrown Date: Fri, 6 Jan 2006 00:21:36 -0800 Subject: [PATCH] md: allow sync-speed to be controlled per-device Also export current (average) speed and status in sysfs. Signed-off-by: Neil Brown Acked-by: Greg KH Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/md.txt | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) (limited to 'Documentation') diff --git a/Documentation/md.txt b/Documentation/md.txt index b8d172b254f..03a13c462cf 100644 --- a/Documentation/md.txt +++ b/Documentation/md.txt @@ -207,6 +207,28 @@ All md devices contain: available. It will then appear at md/dev-XXX (depending on the name of the device) and further configuration is then possible. + sync_speed_min + sync_speed_max + This are similar to /proc/sys/dev/raid/speed_limit_{min,max} + however they only apply to the particular array. + If no value has been written to these, of if the word 'system' + is written, then the system-wide value is used. If a value, + in kibibytes-per-second is written, then it is used. + When the files are read, they show the currently active value + followed by "(local)" or "(system)" depending on whether it is + a locally set or system-wide value. + + sync_completed + This shows the number of sectors that have been completed of + whatever the current sync_action is, followed by the number of + sectors in total that could need to be processed. The two + numbers are separated by a '/' thus effectively showing one + value, a fraction of the process that is complete. + + sync_speed + This shows the current actual speed, in K/sec, of the current + sync_action. It is averaged over the last 30 seconds. + As component devices are added to an md array, they appear in the 'md' directory as new directories named -- cgit v1.2.3 From 253dfa6e465c054a73bd3b13af51c34c9d8d233d Mon Sep 17 00:00:00 2001 From: Sam Ravnborg Date: Fri, 6 Jan 2006 20:33:41 +0100 Subject: kbuild: document howto build external modules using several directories Update modules.txt with info how to build external modules with files in several directories. The question popped up on lkml often enough to warrant this, let's see if people read this stuff - or google hits it. Signed-off-by: Sam Ravnborg --- Documentation/kbuild/modules.txt | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kbuild/modules.txt b/Documentation/kbuild/modules.txt index 1c0db652b36..7e77f93634e 100644 --- a/Documentation/kbuild/modules.txt +++ b/Documentation/kbuild/modules.txt @@ -18,6 +18,7 @@ In this document you will find information about: === 5. Include files --- 5.1 How to include files from the kernel include dir --- 5.2 External modules using an include/ dir + --- 5.3 External modules using several directories === 6. Module installation --- 6.1 INSTALL_MOD_PATH --- 6.2 INSTALL_MOD_DIR @@ -344,6 +345,45 @@ directory and therefore needs to deal with this in their kbuild file. Note that in the assignment there is no space between -I and the path. This is a kbuild limitation: there must be no space present. +--- 5.3 External modules using several directories + + If an external module does not follow the usual kernel style but + decide to spread files over several directories then kbuild can + support this too. + + Consider the following example: + + | + +- src/complex_main.c + | +- hal/hardwareif.c + | +- hal/include/hardwareif.h + +- include/complex.h + + To build a single module named complex.ko we then need the following + kbuild file: + + Kbuild: + obj-m := complex.o + complex-y := src/complex_main.o + complex-y += src/hal/hardwareif.o + + EXTRA_CFLAGS := -I$(src)/include + EXTRA_CFLAGS += -I$(src)src/hal/include + + + kbuild knows how to handle .o files located in another directory - + although this is NOT reccommended practice. The syntax is to specify + the directory relative to the directory where the Kbuild file is + located. + + To find the .h files we have to explicitly tell kbuild where to look + for the .h files. When kbuild executes current directory is always + the root of the kernel tree (argument to -C) and therefore we have to + tell kbuild how to find the .h files using absolute paths. + $(src) will specify the absolute path to the directory where the + Kbuild file are located when being build as an external module. + Therefore -I$(src)/ is used to point out the directory of the Kbuild + file and any additional path are just appended. === 6. Module installation -- cgit v1.2.3 From a72b44222d222749d54b3e370d825094352e389f Mon Sep 17 00:00:00 2001 From: Trond Myklebust Date: Tue, 3 Jan 2006 09:55:41 +0100 Subject: NFSv4: Allow user to set the port used by the NFSv4 callback channel Signed-off-by: Trond Myklebust --- Documentation/kernel-parameters.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 61a56b100c6..309c9cec6e7 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -910,6 +910,10 @@ running once the system is up. nfsroot= [NFS] nfs root filesystem for disk-less boxes. See Documentation/nfsroot.txt. + nfs.callback_tcpport= + [NFS] set the TCP port on which the NFSv4 callback + channel should listen. + nmi_watchdog= [KNL,BUGS=IA-32] Debugging features for SMP kernels no387 [BUGS=IA-32] Tells the kernel to use the 387 maths -- cgit v1.2.3 From 58df095b732529ade8f4051b41d7c29731afecd6 Mon Sep 17 00:00:00 2001 From: Trond Myklebust Date: Tue, 3 Jan 2006 09:55:57 +0100 Subject: NFSv4: Allow entries in the idmap cache to expire If someone changes the uid/gid mapping in userland, then we do eventually want those changes to be propagated to the kernel. Currently the kernel assumes that it may cache entries forever. Add an expiration time + garbage collector for idmap entries. Signed-off-by: Trond Myklebust --- Documentation/kernel-parameters.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 309c9cec6e7..a482fde09bb 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -914,6 +914,10 @@ running once the system is up. [NFS] set the TCP port on which the NFSv4 callback channel should listen. + nfs.idmap_cache_timeout= + [NFS] set the maximum lifetime for idmapper cache + entries. + nmi_watchdog= [KNL,BUGS=IA-32] Debugging features for SMP kernels no387 [BUGS=IA-32] Tells the kernel to use the 387 maths -- cgit v1.2.3