From 4c41251e31982002bca0ce7e903c0cc66218c1ec Mon Sep 17 00:00:00 2001 From: Erik Mouw Date: Mon, 3 Apr 2006 14:21:00 +0200 Subject: [CPUFREQ] Update LART site URL Update LART site URL. The LART website moved to http://www.lartmaker.nl/. This patch updates the URL in CpuFreq specific files. Signed-off-by: Erik Mouw Signed-off-by: Dave Jones --- Documentation/cpu-freq/index.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/cpu-freq/index.txt b/Documentation/cpu-freq/index.txt index 5009805f9378..ffdb5323df37 100644 --- a/Documentation/cpu-freq/index.txt +++ b/Documentation/cpu-freq/index.txt @@ -53,4 +53,4 @@ the CPUFreq Mailing list: * http://lists.linux.org.uk/mailman/listinfo/cpufreq Clock and voltage scaling for the SA-1100: -* http://www.lart.tudelft.nl/projects/scaling +* http://www.lartmaker.nl/projects/scaling -- cgit v1.2.3 From a7d7cb3cd6c97cbbe21d528c014e5f592006457d Mon Sep 17 00:00:00 2001 From: Brian Gerst Date: Sat, 25 Mar 2006 14:48:37 -0500 Subject: kbuild: fix garbled text in modules.txt Signed-off-by: Brian Gerst Signed-off-by: Sam Ravnborg --- Documentation/kbuild/modules.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/kbuild/modules.txt b/Documentation/kbuild/modules.txt index fcccf2432f98..61fc079eb966 100644 --- a/Documentation/kbuild/modules.txt +++ b/Documentation/kbuild/modules.txt @@ -44,7 +44,7 @@ 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 build the module. A complete example will be present in -chapter ¤. Creating a kbuild file for an external module". +chapter 4, "Creating a kbuild file for an external module". === 2. How to build external modules -- cgit v1.2.3 From 68a3a7feb08f960095072f28ec20f7900793c506 Mon Sep 17 00:00:00 2001 From: Andi Kleen Date: Fri, 7 Apr 2006 19:49:18 +0200 Subject: [PATCH] x86_64: Reserve SRAT hotadd memory on x86-64 From: Keith Mannthey, Andi Kleen Implement memory hotadd without sparsemem. The memory in the SRAT hotadd area is just preserved instead and can be activated later. There are a few restrictions: - Only one continuous hotadd area allowed per node The main problem is dealing with the many buggy SRAT tables that are out there. The strategy here is to reject anything suspicious. Originally from Keith Mannthey, with several hacks and changes by AK and also contributions from Andrew Morton [ TBD: Problems pointed out by KAMEZAWA Hiroyuki : 1) Goto's rebuild_zonelist patch will not work if CONFIG_MEMORY_HOTPLUG=n. Rebuilding zonelist is necessary when the system has just memory < 4G at boot, and hot add memory > 4G. because x86_64 has DMA32, ZONE_NORAML is not included into zonelist at boot time if system doesn't have memory >4G at boot. [AK: should just force the higher zones at boot time when SRAT tells us] 2) zone and node's spanned_pages and present_pages are not incremented. They should be. For example, our server (ia64/Fujitsu PrimeQuest) can equip memory from 4G to 1T(maybe 2T in future), and SRAT will *always* say we have possible 1T +memory. (Microsoft requires "write all possible memory in SRAT") When we reserve memmap for possible 1T memory, Linux will not work well in +minimum 4G configuraion ;) [AK: needs limiting to 5-10% of max memory] ] Signed-off-by: Andi Kleen Signed-off-by: Linus Torvalds --- Documentation/x86_64/boot-options.txt | 5 ++ arch/x86_64/mm/init.c | 3 +- arch/x86_64/mm/numa.c | 5 ++ arch/x86_64/mm/srat.c | 164 ++++++++++++++++++++++++++++++++-- include/asm-x86_64/numa.h | 2 + 5 files changed, 171 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/x86_64/boot-options.txt b/Documentation/x86_64/boot-options.txt index 1921353259ae..f2cd6ef53ff3 100644 --- a/Documentation/x86_64/boot-options.txt +++ b/Documentation/x86_64/boot-options.txt @@ -151,6 +151,11 @@ NUMA numa=fake=X Fake X nodes and ignore NUMA setup of the actual machine. + numa=hotadd=percent + Only allow hotadd memory to preallocate page structures upto + percent of already available memory. + numa=hotadd=0 will disable hotadd memory. + ACPI acpi=off Don't enable ACPI diff --git a/arch/x86_64/mm/init.c b/arch/x86_64/mm/init.c index 492161168402..dff870534199 100644 --- a/arch/x86_64/mm/init.c +++ b/arch/x86_64/mm/init.c @@ -530,8 +530,7 @@ int __add_pages(struct zone *z, unsigned long start_pfn, unsigned long nr_pages) unsigned long pfn; unsigned long total = 0, mem = 0; for (pfn = start_pfn; pfn < start_pfn + nr_pages; pfn++) { - unsigned long addr = pfn << PAGE_SHIFT; - if (pfn_valid(pfn) && e820_mapped(addr, addr+1, E820_RAM)) { + if (pfn_valid(pfn)) { online_page(pfn_to_page(pfn)); err = 0; mem++; diff --git a/arch/x86_64/mm/numa.c b/arch/x86_64/mm/numa.c index 4be82d6e2b48..779132af29a7 100644 --- a/arch/x86_64/mm/numa.c +++ b/arch/x86_64/mm/numa.c @@ -142,6 +142,9 @@ void __init setup_node_bootmem(int nodeid, unsigned long start, unsigned long en reserve_bootmem_node(NODE_DATA(nodeid), nodedata_phys, pgdat_size); reserve_bootmem_node(NODE_DATA(nodeid), bootmap_start, bootmap_pages<> PAGE_SHIFT; + unsigned long e_pfn = end >> PAGE_SHIFT; + int changed = 0; + struct bootnode *nd = &nodes_add[node]; + + /* I had some trouble with strange memory hotadd regions breaking + the boot. Be very strict here and reject anything unexpected. + If you want working memory hotadd write correct SRATs. + + The node size check is a basic sanity check to guard against + mistakes */ + if ((signed long)(end - start) < NODE_MIN_SIZE) { + printk(KERN_ERR "SRAT: Hotplug area too small\n"); + return -1; + } + + /* This check might be a bit too strict, but I'm keeping it for now. */ + if (e820_hole_size(s_pfn, e_pfn) != e_pfn - s_pfn) { + printk(KERN_ERR "SRAT: Hotplug area has existing memory\n"); + return -1; + } + + if (!hotadd_enough_memory(&nodes_add[node])) { + printk(KERN_ERR "SRAT: Hotplug area too large\n"); + return -1; + } + + /* Looks good */ + + found_add_area = 1; + if (nd->start == nd->end) { + nd->start = start; + nd->end = end; + changed = 1; + } else { + if (nd->start == end) { + nd->start = start; + changed = 1; + } + if (nd->end == start) { + nd->end = end; + changed = 1; + } + if (!changed) + printk(KERN_ERR "SRAT: Hotplug zone not continuous. Partly ignored\n"); + } + + if ((nd->end >> PAGE_SHIFT) > end_pfn) + end_pfn = nd->end >> PAGE_SHIFT; + + if (changed) + printk(KERN_INFO "SRAT: hot plug zone found %Lx - %Lx\n", nd->start, nd->end); + return 0; +} +#endif + /* Callback for parsing of the Proximity Domain <-> Memory Area mappings */ void __init acpi_numa_memory_affinity_init(struct acpi_table_memory_affinity *ma) { - struct bootnode *nd; + struct bootnode *nd, oldnode; unsigned long start, end; int node, pxm; int i; @@ -172,6 +292,8 @@ acpi_numa_memory_affinity_init(struct acpi_table_memory_affinity *ma) } if (ma->flags.enabled == 0) return; + if (ma->flags.hot_pluggable && hotadd_percent == 0) + return; start = ma->base_addr_lo | ((u64)ma->base_addr_hi << 32); end = start + (ma->length_lo | ((u64)ma->length_hi << 32)); pxm = ma->proximity_domain; @@ -181,10 +303,6 @@ acpi_numa_memory_affinity_init(struct acpi_table_memory_affinity *ma) bad_srat(); return; } - /* It is fine to add this area to the nodes data it will be used later*/ - if (ma->flags.hot_pluggable == 1) - printk(KERN_INFO "SRAT: hot plug zone found %lx - %lx \n", - start, end); i = conflicting_nodes(start, end); if (i == node) { printk(KERN_WARNING @@ -199,6 +317,7 @@ acpi_numa_memory_affinity_init(struct acpi_table_memory_affinity *ma) return; } nd = &nodes[node]; + oldnode = *nd; if (!node_test_and_set(node, nodes_parsed)) { nd->start = start; nd->end = end; @@ -208,8 +327,19 @@ acpi_numa_memory_affinity_init(struct acpi_table_memory_affinity *ma) if (nd->end < end) nd->end = end; } + printk(KERN_INFO "SRAT: Node %u PXM %u %Lx-%Lx\n", node, pxm, nd->start, nd->end); + +#ifdef RESERVE_HOTADD + if (ma->flags.hot_pluggable && reserve_hotadd(node, start, end) < 0) { + /* Ignore hotadd region. Undo damage */ + printk(KERN_NOTICE "SRAT: Hotplug region ignored\n"); + *nd = oldnode; + if ((nd->start | nd->end) == 0) + node_clear(node, nodes_parsed); + } +#endif } /* Sanity check to catch more bad SRATs (they are amazingly common). @@ -225,6 +355,9 @@ static int nodes_cover_memory(void) unsigned long e = nodes[i].end >> PAGE_SHIFT; pxmram += e - s; pxmram -= e820_hole_size(s, e); + pxmram -= nodes_add[i].end - nodes_add[i].start; + if ((long)pxmram < 0) + pxmram = 0; } e820ram = end_pfn - e820_hole_size(0, end_pfn); @@ -258,7 +391,7 @@ int __init acpi_scan_nodes(unsigned long start, unsigned long end) /* First clean up the node list */ for (i = 0; i < MAX_NUMNODES; i++) { - cutoff_node(i, start, end); + cutoff_node(i, start, end); if ((nodes[i].end - nodes[i].start) < NODE_MIN_SIZE) unparse_node(i); } @@ -303,6 +436,25 @@ static int node_to_pxm(int n) return 0; } +void __init srat_reserve_add_area(int nodeid) +{ + if (found_add_area && nodes_add[nodeid].end) { + u64 total_mb; + + printk(KERN_INFO "SRAT: Reserving hot-add memory space " + "for node %d at %Lx-%Lx\n", + nodeid, nodes_add[nodeid].start, nodes_add[nodeid].end); + total_mb = (nodes_add[nodeid].end - nodes_add[nodeid].start) + >> PAGE_SHIFT; + total_mb *= sizeof(struct page); + total_mb >>= 20; + printk(KERN_INFO "SRAT: This will cost you %Lu MB of " + "pre-allocated memory.\n", (unsigned long long)total_mb); + reserve_bootmem_node(NODE_DATA(nodeid), nodes_add[nodeid].start, + nodes_add[nodeid].end - nodes_add[nodeid].start); + } +} + int __node_distance(int a, int b) { int index; diff --git a/include/asm-x86_64/numa.h b/include/asm-x86_64/numa.h index f6cbb4cbb5a3..f0ba4d984bdf 100644 --- a/include/asm-x86_64/numa.h +++ b/include/asm-x86_64/numa.h @@ -18,6 +18,8 @@ extern void numa_init_array(void); extern int numa_off; extern void numa_set_node(int cpu, int node); +extern void srat_reserve_add_area(int nodeid); +extern int hotadd_percent; extern unsigned char apicid_to_node[256]; #ifdef CONFIG_NUMA -- cgit v1.2.3 From 9227c33de80ac01f269ed33624990ce84358e419 Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Sat, 1 Apr 2006 19:21:04 +0200 Subject: [PATCH] move ->eh_strategy_handler to the transport class Overriding the whole EH code is a per-transport, not per-host thing. Move ->eh_strategy_handler to the transport class, same as ->eh_timed_out. Downside is that scsi_host_alloc can't check for the total lack of EH anymore, but the transition period from old EH where we needed it is long gone already. Signed-off-by: Christoph Hellwig Signed-off-by: Jeff Garzik --- Documentation/DocBook/libata.tmpl | 2 +- Documentation/scsi/scsi_eh.txt | 14 +++++++------- Documentation/scsi/scsi_mid_low_api.txt | 19 ------------------- drivers/scsi/ahci.c | 1 - drivers/scsi/ata_piix.c | 1 - drivers/scsi/hosts.c | 12 ------------ drivers/scsi/libata-core.c | 1 - drivers/scsi/libata-scsi.c | 8 +++----- drivers/scsi/libata.h | 1 - drivers/scsi/pdc_adma.c | 1 - drivers/scsi/sata_mv.c | 2 -- drivers/scsi/sata_nv.c | 1 - drivers/scsi/sata_promise.c | 1 - drivers/scsi/sata_qstor.c | 1 - drivers/scsi/sata_sil.c | 1 - drivers/scsi/sata_sil24.c | 1 - drivers/scsi/sata_sis.c | 1 - drivers/scsi/sata_svw.c | 1 - drivers/scsi/sata_sx4.c | 1 - drivers/scsi/sata_uli.c | 1 - drivers/scsi/sata_via.c | 1 - drivers/scsi/sata_vsc.c | 1 - drivers/scsi/scsi_error.c | 4 ++-- include/linux/libata.h | 1 - include/scsi/scsi_host.h | 1 - include/scsi/scsi_transport.h | 5 +++++ 26 files changed, 18 insertions(+), 66 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/libata.tmpl b/Documentation/DocBook/libata.tmpl index 5bcbb6ee3bc0..f869b03929db 100644 --- a/Documentation/DocBook/libata.tmpl +++ b/Documentation/DocBook/libata.tmpl @@ -705,7 +705,7 @@ and other resources, etc. ata_scsi_error() - ata_scsi_error() is the current hostt->eh_strategy_handler() + ata_scsi_error() is the current transportt->eh_strategy_handler() for libata. As discussed above, this will be entered in two cases - timeout and ATAPI error completion. This function calls low level libata driver's eng_timeout() callback, the diff --git a/Documentation/scsi/scsi_eh.txt b/Documentation/scsi/scsi_eh.txt index 331afd791cbb..ce767b90bb0d 100644 --- a/Documentation/scsi/scsi_eh.txt +++ b/Documentation/scsi/scsi_eh.txt @@ -19,9 +19,9 @@ TABLE OF CONTENTS [2-1-1] Overview [2-1-2] Flow of scmds through EH [2-1-3] Flow of control - [2-2] EH through hostt->eh_strategy_handler() - [2-2-1] Pre hostt->eh_strategy_handler() SCSI midlayer conditions - [2-2-2] Post hostt->eh_strategy_handler() SCSI midlayer conditions + [2-2] EH through transportt->eh_strategy_handler() + [2-2-1] Pre transportt->eh_strategy_handler() SCSI midlayer conditions + [2-2-2] Post transportt->eh_strategy_handler() SCSI midlayer conditions [2-2-3] Things to consider @@ -413,9 +413,9 @@ scmd->allowed. layer of failure of the scmds. -[2-2] EH through hostt->eh_strategy_handler() +[2-2] EH through transportt->eh_strategy_handler() - hostt->eh_strategy_handler() is invoked in the place of + transportt->eh_strategy_handler() is invoked in the place of scsi_unjam_host() and it is responsible for whole recovery process. On completion, the handler should have made lower layers forget about all failed scmds and either ready for new commands or offline. Also, @@ -424,7 +424,7 @@ SCSI midlayer. IOW, of the steps described in [2-1-2], all steps except for #1 must be implemented by eh_strategy_handler(). -[2-2-1] Pre hostt->eh_strategy_handler() SCSI midlayer conditions +[2-2-1] Pre transportt->eh_strategy_handler() SCSI midlayer conditions The following conditions are true on entry to the handler. @@ -437,7 +437,7 @@ except for #1 must be implemented by eh_strategy_handler(). - shost->host_failed == shost->host_busy -[2-2-2] Post hostt->eh_strategy_handler() SCSI midlayer conditions +[2-2-2] Post transportt->eh_strategy_handler() SCSI midlayer conditions The following conditions must be true on exit from the handler. diff --git a/Documentation/scsi/scsi_mid_low_api.txt b/Documentation/scsi/scsi_mid_low_api.txt index 8bbae3e1abdf..75a535a975c3 100644 --- a/Documentation/scsi/scsi_mid_low_api.txt +++ b/Documentation/scsi/scsi_mid_low_api.txt @@ -804,7 +804,6 @@ Summary: eh_bus_reset_handler - issue SCSI bus reset eh_device_reset_handler - issue SCSI device reset eh_host_reset_handler - reset host (host bus adapter) - eh_strategy_handler - driver supplied alternate to scsi_unjam_host() info - supply information about given host ioctl - driver can respond to ioctls proc_info - supports /proc/scsi/{driver_name}/{host_no} @@ -969,24 +968,6 @@ Details: int eh_host_reset_handler(struct scsi_cmnd * scp) -/** - * eh_strategy_handler - driver supplied alternate to scsi_unjam_host() - * @shp: host on which error has occurred - * - * Returns TRUE if host unjammed, else FALSE. - * - * Locks: none - * - * Calling context: kernel thread - * - * Notes: Invoked from scsi_eh thread. LLD supplied alternate to - * scsi_unjam_host() found in scsi_error.c - * - * Optionally defined in: LLD - **/ - int eh_strategy_handler(struct Scsi_Host * shp) - - /** * info - supply information about given host: driver name plus data * to distinguish given host diff --git a/drivers/scsi/ahci.c b/drivers/scsi/ahci.c index 1bd82c4e52a0..b4f8fb1d628b 100644 --- a/drivers/scsi/ahci.c +++ b/drivers/scsi/ahci.c @@ -207,7 +207,6 @@ static struct scsi_host_template ahci_sht = { .name = DRV_NAME, .ioctl = ata_scsi_ioctl, .queuecommand = ata_scsi_queuecmd, - .eh_strategy_handler = ata_scsi_error, .can_queue = ATA_DEF_QUEUE, .this_id = ATA_SHT_THIS_ID, .sg_tablesize = AHCI_MAX_SG, diff --git a/drivers/scsi/ata_piix.c b/drivers/scsi/ata_piix.c index 24e71b555172..6dc88149f9f1 100644 --- a/drivers/scsi/ata_piix.c +++ b/drivers/scsi/ata_piix.c @@ -209,7 +209,6 @@ static struct scsi_host_template piix_sht = { .name = DRV_NAME, .ioctl = ata_scsi_ioctl, .queuecommand = ata_scsi_queuecmd, - .eh_strategy_handler = ata_scsi_error, .can_queue = ATA_DEF_QUEUE, .this_id = ATA_SHT_THIS_ID, .sg_tablesize = LIBATA_MAX_PRD, diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c index ef57f253031c..dfcb96f3e60c 100644 --- a/drivers/scsi/hosts.c +++ b/drivers/scsi/hosts.c @@ -294,18 +294,6 @@ struct Scsi_Host *scsi_host_alloc(struct scsi_host_template *sht, int privsize) if (sht->unchecked_isa_dma && privsize) gfp_mask |= __GFP_DMA; - /* Check to see if this host has any error handling facilities */ - if (!sht->eh_strategy_handler && !sht->eh_abort_handler && - !sht->eh_device_reset_handler && !sht->eh_bus_reset_handler && - !sht->eh_host_reset_handler) { - printk(KERN_ERR "ERROR: SCSI host `%s' has no error handling\n" - "ERROR: This is not a safe way to run your " - "SCSI host\n" - "ERROR: The error handling must be added to " - "this driver\n", sht->proc_name); - dump_stack(); - } - shost = kzalloc(sizeof(struct Scsi_Host) + privsize, gfp_mask); if (!shost) return NULL; diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c index e63c1ff1e102..bd147207f25d 100644 --- a/drivers/scsi/libata-core.c +++ b/drivers/scsi/libata-core.c @@ -4938,7 +4938,6 @@ EXPORT_SYMBOL_GPL(ata_busy_sleep); EXPORT_SYMBOL_GPL(ata_port_queue_task); EXPORT_SYMBOL_GPL(ata_scsi_ioctl); EXPORT_SYMBOL_GPL(ata_scsi_queuecmd); -EXPORT_SYMBOL_GPL(ata_scsi_error); EXPORT_SYMBOL_GPL(ata_scsi_slave_config); EXPORT_SYMBOL_GPL(ata_scsi_release); EXPORT_SYMBOL_GPL(ata_host_intr); diff --git a/drivers/scsi/libata-scsi.c b/drivers/scsi/libata-scsi.c index 53f5b0d9161c..a0289ec3e283 100644 --- a/drivers/scsi/libata-scsi.c +++ b/drivers/scsi/libata-scsi.c @@ -53,6 +53,7 @@ typedef unsigned int (*ata_xlat_func_t)(struct ata_queued_cmd *qc, const u8 *scsicmd); static struct ata_device * ata_scsi_find_dev(struct ata_port *ap, const struct scsi_device *scsidev); +static void ata_scsi_error(struct Scsi_Host *host); enum scsi_eh_timer_return ata_scsi_timed_out(struct scsi_cmnd *cmd); #define RW_RECOVERY_MPAGE 0x1 @@ -99,6 +100,7 @@ static const u8 def_control_mpage[CONTROL_MPAGE_LEN] = { * It just needs the eh_timed_out hook. */ struct scsi_transport_template ata_scsi_transport_template = { + .eh_strategy_handler = ata_scsi_error, .eh_timed_out = ata_scsi_timed_out, }; @@ -772,12 +774,9 @@ enum scsi_eh_timer_return ata_scsi_timed_out(struct scsi_cmnd *cmd) * * LOCKING: * Inherited from SCSI layer (none, can sleep) - * - * RETURNS: - * Zero. */ -int ata_scsi_error(struct Scsi_Host *host) +static void ata_scsi_error(struct Scsi_Host *host) { struct ata_port *ap; unsigned long flags; @@ -805,7 +804,6 @@ int ata_scsi_error(struct Scsi_Host *host) spin_unlock_irqrestore(&ap->host_set->lock, flags); DPRINTK("EXIT\n"); - return 0; } static void ata_eh_scsidone(struct scsi_cmnd *scmd) diff --git a/drivers/scsi/libata.h b/drivers/scsi/libata.h index 1c755b14521a..bac8cbae06fe 100644 --- a/drivers/scsi/libata.h +++ b/drivers/scsi/libata.h @@ -60,7 +60,6 @@ extern int ata_cmd_ioctl(struct scsi_device *scsidev, void __user *arg); extern struct scsi_transport_template ata_scsi_transport_template; extern void ata_scsi_scan_host(struct ata_port *ap); -extern int ata_scsi_error(struct Scsi_Host *host); extern unsigned int ata_scsiop_inq_std(struct ata_scsi_args *args, u8 *rbuf, unsigned int buflen); diff --git a/drivers/scsi/pdc_adma.c b/drivers/scsi/pdc_adma.c index 3c85c4b66e19..5cda16cfacb0 100644 --- a/drivers/scsi/pdc_adma.c +++ b/drivers/scsi/pdc_adma.c @@ -143,7 +143,6 @@ static struct scsi_host_template adma_ata_sht = { .name = DRV_NAME, .ioctl = ata_scsi_ioctl, .queuecommand = ata_scsi_queuecmd, - .eh_strategy_handler = ata_scsi_error, .can_queue = ATA_DEF_QUEUE, .this_id = ATA_SHT_THIS_ID, .sg_tablesize = LIBATA_MAX_PRD, diff --git a/drivers/scsi/sata_mv.c b/drivers/scsi/sata_mv.c index fa901fd65085..0ebf13668f51 100644 --- a/drivers/scsi/sata_mv.c +++ b/drivers/scsi/sata_mv.c @@ -378,8 +378,6 @@ static struct scsi_host_template mv_sht = { .name = DRV_NAME, .ioctl = ata_scsi_ioctl, .queuecommand = ata_scsi_queuecmd, - .eh_strategy_handler = ata_scsi_error, - .can_queue = MV_USE_Q_DEPTH, .this_id = ATA_SHT_THIS_ID, .sg_tablesize = MV_MAX_SG_CT / 2, .cmd_per_lun = ATA_SHT_CMD_PER_LUN, diff --git a/drivers/scsi/sata_nv.c b/drivers/scsi/sata_nv.c index f77bf183dfab..9f553081b5e8 100644 --- a/drivers/scsi/sata_nv.c +++ b/drivers/scsi/sata_nv.c @@ -201,7 +201,6 @@ static struct scsi_host_template nv_sht = { .name = DRV_NAME, .ioctl = ata_scsi_ioctl, .queuecommand = ata_scsi_queuecmd, - .eh_strategy_handler = ata_scsi_error, .can_queue = ATA_DEF_QUEUE, .this_id = ATA_SHT_THIS_ID, .sg_tablesize = LIBATA_MAX_PRD, diff --git a/drivers/scsi/sata_promise.c b/drivers/scsi/sata_promise.c index cc928c68a479..7eb67a6bdc64 100644 --- a/drivers/scsi/sata_promise.c +++ b/drivers/scsi/sata_promise.c @@ -111,7 +111,6 @@ static struct scsi_host_template pdc_ata_sht = { .name = DRV_NAME, .ioctl = ata_scsi_ioctl, .queuecommand = ata_scsi_queuecmd, - .eh_strategy_handler = ata_scsi_error, .can_queue = ATA_DEF_QUEUE, .this_id = ATA_SHT_THIS_ID, .sg_tablesize = LIBATA_MAX_PRD, diff --git a/drivers/scsi/sata_qstor.c b/drivers/scsi/sata_qstor.c index 9ffe1ef0d205..886f3447dd48 100644 --- a/drivers/scsi/sata_qstor.c +++ b/drivers/scsi/sata_qstor.c @@ -132,7 +132,6 @@ static struct scsi_host_template qs_ata_sht = { .name = DRV_NAME, .ioctl = ata_scsi_ioctl, .queuecommand = ata_scsi_queuecmd, - .eh_strategy_handler = ata_scsi_error, .can_queue = ATA_DEF_QUEUE, .this_id = ATA_SHT_THIS_ID, .sg_tablesize = QS_MAX_PRD, diff --git a/drivers/scsi/sata_sil.c b/drivers/scsi/sata_sil.c index 18c296c56899..106627299d55 100644 --- a/drivers/scsi/sata_sil.c +++ b/drivers/scsi/sata_sil.c @@ -146,7 +146,6 @@ static struct scsi_host_template sil_sht = { .name = DRV_NAME, .ioctl = ata_scsi_ioctl, .queuecommand = ata_scsi_queuecmd, - .eh_strategy_handler = ata_scsi_error, .can_queue = ATA_DEF_QUEUE, .this_id = ATA_SHT_THIS_ID, .sg_tablesize = LIBATA_MAX_PRD, diff --git a/drivers/scsi/sata_sil24.c b/drivers/scsi/sata_sil24.c index 068c98a4111b..f7264fd611c2 100644 --- a/drivers/scsi/sata_sil24.c +++ b/drivers/scsi/sata_sil24.c @@ -281,7 +281,6 @@ static struct scsi_host_template sil24_sht = { .name = DRV_NAME, .ioctl = ata_scsi_ioctl, .queuecommand = ata_scsi_queuecmd, - .eh_strategy_handler = ata_scsi_error, .can_queue = ATA_DEF_QUEUE, .this_id = ATA_SHT_THIS_ID, .sg_tablesize = LIBATA_MAX_PRD, diff --git a/drivers/scsi/sata_sis.c b/drivers/scsi/sata_sis.c index acc8439dea23..728530df2e07 100644 --- a/drivers/scsi/sata_sis.c +++ b/drivers/scsi/sata_sis.c @@ -87,7 +87,6 @@ static struct scsi_host_template sis_sht = { .name = DRV_NAME, .ioctl = ata_scsi_ioctl, .queuecommand = ata_scsi_queuecmd, - .eh_strategy_handler = ata_scsi_error, .can_queue = ATA_DEF_QUEUE, .this_id = ATA_SHT_THIS_ID, .sg_tablesize = ATA_MAX_PRD, diff --git a/drivers/scsi/sata_svw.c b/drivers/scsi/sata_svw.c index 724f0ed6a52d..53b0d5c0a61f 100644 --- a/drivers/scsi/sata_svw.c +++ b/drivers/scsi/sata_svw.c @@ -290,7 +290,6 @@ static struct scsi_host_template k2_sata_sht = { .name = DRV_NAME, .ioctl = ata_scsi_ioctl, .queuecommand = ata_scsi_queuecmd, - .eh_strategy_handler = ata_scsi_error, .can_queue = ATA_DEF_QUEUE, .this_id = ATA_SHT_THIS_ID, .sg_tablesize = LIBATA_MAX_PRD, diff --git a/drivers/scsi/sata_sx4.c b/drivers/scsi/sata_sx4.c index ae70f60c7c0d..4139ad4b1df0 100644 --- a/drivers/scsi/sata_sx4.c +++ b/drivers/scsi/sata_sx4.c @@ -182,7 +182,6 @@ static struct scsi_host_template pdc_sata_sht = { .name = DRV_NAME, .ioctl = ata_scsi_ioctl, .queuecommand = ata_scsi_queuecmd, - .eh_strategy_handler = ata_scsi_error, .can_queue = ATA_DEF_QUEUE, .this_id = ATA_SHT_THIS_ID, .sg_tablesize = LIBATA_MAX_PRD, diff --git a/drivers/scsi/sata_uli.c b/drivers/scsi/sata_uli.c index 7ac5a5f5a905..38b52bd3fa3f 100644 --- a/drivers/scsi/sata_uli.c +++ b/drivers/scsi/sata_uli.c @@ -81,7 +81,6 @@ static struct scsi_host_template uli_sht = { .name = DRV_NAME, .ioctl = ata_scsi_ioctl, .queuecommand = ata_scsi_queuecmd, - .eh_strategy_handler = ata_scsi_error, .can_queue = ATA_DEF_QUEUE, .this_id = ATA_SHT_THIS_ID, .sg_tablesize = LIBATA_MAX_PRD, diff --git a/drivers/scsi/sata_via.c b/drivers/scsi/sata_via.c index 791bf652ba63..9e7ae4e0db32 100644 --- a/drivers/scsi/sata_via.c +++ b/drivers/scsi/sata_via.c @@ -94,7 +94,6 @@ static struct scsi_host_template svia_sht = { .name = DRV_NAME, .ioctl = ata_scsi_ioctl, .queuecommand = ata_scsi_queuecmd, - .eh_strategy_handler = ata_scsi_error, .can_queue = ATA_DEF_QUEUE, .this_id = ATA_SHT_THIS_ID, .sg_tablesize = LIBATA_MAX_PRD, diff --git a/drivers/scsi/sata_vsc.c b/drivers/scsi/sata_vsc.c index 836bbbb26ff2..8a29ce340b47 100644 --- a/drivers/scsi/sata_vsc.c +++ b/drivers/scsi/sata_vsc.c @@ -263,7 +263,6 @@ static struct scsi_host_template vsc_sata_sht = { .name = DRV_NAME, .ioctl = ata_scsi_ioctl, .queuecommand = ata_scsi_queuecmd, - .eh_strategy_handler = ata_scsi_error, .can_queue = ATA_DEF_QUEUE, .this_id = ATA_SHT_THIS_ID, .sg_tablesize = LIBATA_MAX_PRD, diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c index 5f0fdfb2618c..1c75646f9689 100644 --- a/drivers/scsi/scsi_error.c +++ b/drivers/scsi/scsi_error.c @@ -1537,8 +1537,8 @@ int scsi_error_handler(void *data) * what we need to do to get it up and online again (if we can). * If we fail, we end up taking the thing offline. */ - if (shost->hostt->eh_strategy_handler) - shost->hostt->eh_strategy_handler(shost); + if (shost->transportt->eh_strategy_handler) + shost->transportt->eh_strategy_handler(shost); else scsi_unjam_host(shost); diff --git a/include/linux/libata.h b/include/linux/libata.h index 0d61357604d5..b80d2e7fa6d2 100644 --- a/include/linux/libata.h +++ b/include/linux/libata.h @@ -523,7 +523,6 @@ extern void ata_host_set_remove(struct ata_host_set *host_set); extern int ata_scsi_detect(struct scsi_host_template *sht); extern int ata_scsi_ioctl(struct scsi_device *dev, int cmd, void __user *arg); extern int ata_scsi_queuecmd(struct scsi_cmnd *cmd, void (*done)(struct scsi_cmnd *)); -extern int ata_scsi_error(struct Scsi_Host *host); extern void ata_eh_qc_complete(struct ata_queued_cmd *qc); extern void ata_eh_qc_retry(struct ata_queued_cmd *qc); extern int ata_scsi_release(struct Scsi_Host *host); diff --git a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h index dc6862d09e53..de6ce541a046 100644 --- a/include/scsi/scsi_host.h +++ b/include/scsi/scsi_host.h @@ -140,7 +140,6 @@ struct scsi_host_template { * * Status: REQUIRED (at least one of them) */ - int (* eh_strategy_handler)(struct Scsi_Host *); int (* eh_abort_handler)(struct scsi_cmnd *); int (* eh_device_reset_handler)(struct scsi_cmnd *); int (* eh_bus_reset_handler)(struct scsi_cmnd *); diff --git a/include/scsi/scsi_transport.h b/include/scsi/scsi_transport.h index b3657f111937..cca1d4926d2a 100644 --- a/include/scsi/scsi_transport.h +++ b/include/scsi/scsi_transport.h @@ -49,6 +49,11 @@ struct scsi_transport_template { */ unsigned int create_work_queue : 1; + /* + * Allows a transport to override the default error handler. + */ + void (* eh_strategy_handler)(struct Scsi_Host *); + /* * This is an optional routine that allows the transport to become * involved when a scsi io timer fires. The return value tells the -- cgit v1.2.3 From d1195c516a9acd767cb541f914be2c6ddcafcfc1 Mon Sep 17 00:00:00 2001 From: Pekka J Enberg Date: Tue, 11 Apr 2006 14:21:59 +0200 Subject: [PATCH] vfs: add splice_write and splice_read to documentation This patch adds the new splice_write and splice_read file operations to Documentation/filesystems/vfs.txt. Signed-off-by: Pekka Enberg Signed-off-by: Jens Axboe --- Documentation/filesystems/vfs.txt | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index adaa899e5c90..3a2e5520c1e3 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt @@ -694,7 +694,7 @@ struct file_operations ---------------------- This describes how the VFS can manipulate an open file. As of kernel -2.6.13, the following members are defined: +2.6.17, the following members are defined: struct file_operations { loff_t (*llseek) (struct file *, loff_t, int); @@ -723,6 +723,10 @@ struct file_operations { int (*check_flags)(int); int (*dir_notify)(struct file *filp, unsigned long arg); int (*flock) (struct file *, int, struct file_lock *); + ssize_t (*splice_write)(struct pipe_inode_info *, struct file *, size_t, unsigned +int); + ssize_t (*splice_read)(struct file *, struct pipe_inode_info *, size_t, unsigned +int); }; Again, all methods are called without any locks being held, unless @@ -790,6 +794,12 @@ otherwise noted. flock: called by the flock(2) system call + splice_write: called by the VFS to splice data from a pipe to a file. This + method is used by the splice(2) system call + + splice_read: called by the VFS to splice data from file to a pipe. This + method is used by the splice(2) system call + Note that the file operations are implemented by the specific filesystem in which the inode resides. When opening a device node (character or block special) most filesystems will call special -- cgit v1.2.3 From 21a26d49d1ab3163b589bf913dd9176e921eb1d7 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Mon, 10 Apr 2006 22:53:04 -0700 Subject: [PATCH] hugetlbfs doc. update Fix typos, spelling, etc., in Doc/vm/hugetlbpage.txt. Signed-off-by: Randy Dunlap Cc: David Gibson Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/vm/hugetlbpage.txt | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/vm/hugetlbpage.txt b/Documentation/vm/hugetlbpage.txt index 1ad9af1ca4d0..2803f63c1a27 100644 --- a/Documentation/vm/hugetlbpage.txt +++ b/Documentation/vm/hugetlbpage.txt @@ -27,7 +27,7 @@ number of free hugetlb pages at any time. It also displays information about the configured hugepage size - this is needed for generating the proper alignment and size of the arguments to the above system calls. -The output of "cat /proc/meminfo" will have output like: +The output of "cat /proc/meminfo" will have lines like: ..... HugePages_Total: xxx @@ -42,11 +42,11 @@ pages in the kernel. Super user can dynamically request more (or free some pre-configured) hugepages. The allocation (or deallocation) of hugetlb pages is possible only if there are enough physically contiguous free pages in system (freeing of hugepages is -possible only if there are enough hugetlb pages free that can be transfered +possible only if there are enough hugetlb pages free that can be transferred back to regular memory pool). -Pages that are used as hugetlb pages are reserved inside the kernel and can -not be used for other purposes. +Pages that are used as hugetlb pages are reserved inside the kernel and cannot +be used for other purposes. Once the kernel with Hugetlb page support is built and running, a user can use either the mmap system call or shared memory system calls to start using @@ -60,7 +60,7 @@ Use the following command to dynamically allocate/deallocate hugepages: This command will try to configure 20 hugepages in the system. The success or failure of allocation depends on the amount of physically contiguous memory that is preset in system at this time. System administrators may want -to put this command in one of the local rc init file. This will enable the +to put this command in one of the local rc init files. This will enable the kernel to request huge pages early in the boot process (when the possibility of getting physical contiguous pages is still very high). @@ -78,8 +78,8 @@ the uid and gid of the current process are taken. The mode option sets the mode of root of file system to value & 0777. This value is given in octal. By default the value 0755 is picked. The size option sets the maximum value of memory (huge pages) allowed for that filesystem (/mnt/huge). The size is -rounded down to HPAGE_SIZE. The option nr_inode sets the maximum number of -inodes that /mnt/huge can use. If the size or nr_inode options are not +rounded down to HPAGE_SIZE. The option nr_inodes sets the maximum number of +inodes that /mnt/huge can use. If the size or nr_inodes options are not provided on command line then no limits are set. For size and nr_inodes options, you can use [G|g]/[M|m]/[K|k] to represent giga/mega/kilo. For example, size=2K has the same meaning as size=2048. An example is given at @@ -88,7 +88,7 @@ the end of this document. read and write system calls are not supported on files that reside on hugetlb file systems. -A regular chown, chgrp and chmod commands (with right permissions) could be +Regular chown, chgrp, and chmod commands (with right permissions) could be used to change the file attributes on hugetlbfs. Also, it is important to note that no such mount command is required if the @@ -96,8 +96,8 @@ applications are going to use only shmat/shmget system calls. Users who wish to use hugetlb page via shared memory segment should be a member of a supplementary group and system admin needs to configure that gid into /proc/sys/vm/hugetlb_shm_group. It is possible for same or different -applications to use any combination of mmaps and shm* calls. Though the -mount of filesystem will be required for using mmaps. +applications to use any combination of mmaps and shm* calls, though the +mount of filesystem will be required for using mmap calls. ******************************************************************* -- cgit v1.2.3 From aa7271076ae6547d7f370ad7e91ef86fdb318f17 Mon Sep 17 00:00:00 2001 From: Adrian Bunk Date: Mon, 10 Apr 2006 22:53:59 -0700 Subject: [PATCH] the scheduled unexport of panic_timeout Implement the scheduled unexport of panic_timeout. Signed-off-by: Adrian Bunk Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/feature-removal-schedule.txt | 8 -------- include/linux/kernel.h | 2 +- kernel/panic.c | 1 - 3 files changed, 1 insertion(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 59d0c74c79c9..293fed113dff 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -71,14 +71,6 @@ Who: Mauro Carvalho Chehab --------------------------- -What: remove EXPORT_SYMBOL(panic_timeout) -When: April 2006 -Files: kernel/panic.c -Why: No modular usage in the kernel. -Who: Adrian Bunk - ---------------------------- - What: remove EXPORT_SYMBOL(insert_resource) When: April 2006 Files: kernel/resource.c diff --git a/include/linux/kernel.h b/include/linux/kernel.h index a3720f973ea5..e1bd0842f6a1 100644 --- a/include/linux/kernel.h +++ b/include/linux/kernel.h @@ -176,7 +176,7 @@ static inline void console_verbose(void) extern void bust_spinlocks(int yes); extern int oops_in_progress; /* If set, an oops, panic(), BUG() or die() is in progress */ -extern __deprecated_for_modules int panic_timeout; +extern int panic_timeout; extern int panic_on_oops; extern int tainted; extern const char *print_tainted(void); diff --git a/kernel/panic.c b/kernel/panic.c index f895c7c01d5b..cc2a4c9c36ac 100644 --- a/kernel/panic.c +++ b/kernel/panic.c @@ -27,7 +27,6 @@ static int pause_on_oops_flag; static DEFINE_SPINLOCK(pause_on_oops_lock); int panic_timeout; -EXPORT_SYMBOL(panic_timeout); ATOMIC_NOTIFIER_HEAD(panic_notifier_list); -- cgit v1.2.3 From 56b146d36db933844011d5026c6f55593037c7b8 Mon Sep 17 00:00:00 2001 From: Tobias Klauser Date: Mon, 10 Apr 2006 22:54:21 -0700 Subject: [PATCH] Last DMA_xBIT_MASK cleanups These are the last conversions of pci_set_dma_mask(), pci_set_consistent_dma_mask() and pci_dma_supported() to use DMA_xBIT_MASK constants from linux/dma-mapping.h Signed-off-by: Tobias Klauser Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/DMA-mapping.txt | 4 ++-- .../sound/alsa/DocBook/writing-an-alsa-driver.tmpl | 16 ++++++++-------- drivers/media/video/saa7134/saa7134-core.c | 3 ++- drivers/sn/ioc3.c | 5 +++-- include/linux/dma-mapping.h | 2 +- sound/oss/emu10k1/main.c | 3 ++- sound/pci/als300.c | 5 +++-- 7 files changed, 21 insertions(+), 17 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DMA-mapping.txt b/Documentation/DMA-mapping.txt index ee4bb73683cd..10bf4deb96aa 100644 --- a/Documentation/DMA-mapping.txt +++ b/Documentation/DMA-mapping.txt @@ -194,7 +194,7 @@ document for how to handle this case. Finally, if your device can only drive the low 24-bits of address during PCI bus mastering you might do something like: - if (pci_set_dma_mask(pdev, 0x00ffffff)) { + if (pci_set_dma_mask(pdev, DMA_24BIT_MASK)) { printk(KERN_WARNING "mydev: 24-bit DMA addressing not available.\n"); goto ignore_this_device; @@ -212,7 +212,7 @@ functions (for example a sound card provides playback and record functions) and the various different functions have _different_ DMA addressing limitations, you may wish to probe each mask and only provide the functionality which the machine can handle. It -is important that the last call to pci_set_dma_mask() be for the +is important that the last call to pci_set_dma_mask() be for the most specific mask. Here is pseudo-code showing how this might be done: diff --git a/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl b/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl index 6feef9e82b63..68eeebc17ff4 100644 --- a/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl +++ b/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl @@ -1123,8 +1123,8 @@ if ((err = pci_enable_device(pci)) < 0) return err; /* check PCI availability (28bit DMA) */ - if (pci_set_dma_mask(pci, 0x0fffffff) < 0 || - pci_set_consistent_dma_mask(pci, 0x0fffffff) < 0) { + if (pci_set_dma_mask(pci, DMA_28BIT_MASK) < 0 || + pci_set_consistent_dma_mask(pci, DMA_28BIT_MASK) < 0) { printk(KERN_ERR "error to set 28bit mask DMA\n"); pci_disable_device(pci); return -ENXIO; @@ -1216,7 +1216,7 @@ The allocation of PCI resources is done in the probe() function, and usually an extra xxx_create() function is written for this - purpose. + purpose. @@ -1225,7 +1225,7 @@ allocating resources. Also, you need to set the proper PCI DMA mask to limit the accessed i/o range. In some cases, you might need to call pci_set_master() function, - too. + too. @@ -1236,8 +1236,8 @@ Now assume that this PCI device has an I/O port with 8 bytes and an interrupt. Then struct mychip will have the - following fields: + following fields: diff --git a/drivers/media/video/saa7134/saa7134-core.c b/drivers/media/video/saa7134/saa7134-core.c index c98571c9d5a6..13de05532e0a 100644 --- a/drivers/media/video/saa7134/saa7134-core.c +++ b/drivers/media/video/saa7134/saa7134-core.c @@ -32,6 +32,7 @@ #include #include #include +#include #include "saa7134-reg.h" #include "saa7134.h" @@ -870,7 +871,7 @@ static int __devinit saa7134_initdev(struct pci_dev *pci_dev, pci_name(pci_dev), dev->pci_rev, pci_dev->irq, dev->pci_lat,pci_resource_start(pci_dev,0)); pci_set_master(pci_dev); - if (!pci_dma_supported(pci_dev,0xffffffff)) { + if (!pci_dma_supported(pci_dev, DMA_32BIT_MASK)) { printk("%s: Oops: no 32bit PCI DMA ???\n",dev->name); err = -EIO; goto fail1; diff --git a/drivers/sn/ioc3.c b/drivers/sn/ioc3.c index 93449a1a0065..0b49ff78efc1 100644 --- a/drivers/sn/ioc3.c +++ b/drivers/sn/ioc3.c @@ -11,6 +11,7 @@ #include #include #include +#include #include #include #include @@ -619,9 +620,9 @@ static int ioc3_probe(struct pci_dev *pdev, const struct pci_device_id *pci_id) pci_set_master(pdev); #ifdef USE_64BIT_DMA - ret = pci_set_dma_mask(pdev, 0xffffffffffffffffULL); + ret = pci_set_dma_mask(pdev, DMA_64BIT_MASK); if (!ret) { - ret = pci_set_consistent_dma_mask(pdev, 0xffffffffffffffffULL); + ret = pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK); if (ret < 0) { printk(KERN_WARNING "%s: Unable to obtain 64 bit DMA " "for consistent allocations\n", diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index 9b4751aecc23..ff61817082fa 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -21,7 +21,7 @@ enum dma_data_direction { #define DMA_30BIT_MASK 0x000000003fffffffULL #define DMA_29BIT_MASK 0x000000001fffffffULL #define DMA_28BIT_MASK 0x000000000fffffffULL -#define DMA_24BIT_MASK 0x0000000000ffffffULL +#define DMA_24BIT_MASK 0x0000000000ffffffULL #include diff --git a/sound/oss/emu10k1/main.c b/sound/oss/emu10k1/main.c index 0cd44a6f7ac0..3721c5857b90 100644 --- a/sound/oss/emu10k1/main.c +++ b/sound/oss/emu10k1/main.c @@ -94,6 +94,7 @@ #include #include #include +#include #include "hwaccess.h" #include "8010.h" @@ -119,7 +120,7 @@ /* the emu10k1 _seems_ to only supports 29 bit (512MiB) bit bus master */ -#define EMU10K1_DMA_MASK 0x1fffffff /* DMA buffer mask for pci_alloc_consist */ +#define EMU10K1_DMA_MASK DMA_29BIT_MASK /* DMA buffer mask for pci_alloc_consist */ #ifndef PCI_VENDOR_ID_CREATIVE #define PCI_VENDOR_ID_CREATIVE 0x1102 diff --git a/sound/pci/als300.c b/sound/pci/als300.c index 37b80570a5c6..91899f87f037 100644 --- a/sound/pci/als300.c +++ b/sound/pci/als300.c @@ -35,6 +35,7 @@ #include #include #include +#include #include #include @@ -691,8 +692,8 @@ static int __devinit snd_als300_create(snd_card_t *card, if ((err = pci_enable_device(pci)) < 0) return err; - if (pci_set_dma_mask(pci, 0x0fffffff) < 0 || - pci_set_consistent_dma_mask(pci, 0x0fffffff) < 0) { + if (pci_set_dma_mask(pci, DMA_28BIT_MASK) < 0 || + pci_set_consistent_dma_mask(pci, DMA_28BIT_MASK) < 0) { printk(KERN_ERR "error setting 28bit DMA mask\n"); pci_disable_device(pci); return -ENXIO; -- cgit v1.2.3 From 8c37bea1a0506f45111c64bac4325173e066b22d Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Mon, 10 Apr 2006 22:54:21 -0700 Subject: [PATCH] docs: laptop-mode.txt source file build Fix C source file in Doc/laptop-mode.txt to compile. Signed-off-by: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/laptop-mode.txt | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/laptop-mode.txt b/Documentation/laptop-mode.txt index b18e21675906..5696e879449b 100644 --- a/Documentation/laptop-mode.txt +++ b/Documentation/laptop-mode.txt @@ -919,11 +919,11 @@ int main(int argc, char **argv) int settle_time = 60; /* Parse the simple command-line */ - if (ac == 2) - disk = av[1]; - else if (ac == 4) { - settle_time = atoi(av[2]); - disk = av[3]; + if (argc == 2) + disk = argv[1]; + else if (argc == 4) { + settle_time = atoi(argv[2]); + disk = argv[3]; } else usage(); -- cgit v1.2.3 From 235963b2edc080b577000031b9ad75804dd83c88 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Mon, 10 Apr 2006 22:54:22 -0700 Subject: [PATCH] Doc: fix mtrr userspace programs to build cleanly Fix mtrr-add.c and mtrr-show.c in Doc/mtrr.txt to build cleanly. Signed-off-by: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/mtrr.txt | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/mtrr.txt b/Documentation/mtrr.txt index b78af1c32996..c39ac395970e 100644 --- a/Documentation/mtrr.txt +++ b/Documentation/mtrr.txt @@ -138,19 +138,29 @@ Reading MTRRs from a C program using ioctl()'s: */ #include +#include #include #include #include #include #include #include -#define MTRR_NEED_STRINGS #include #define TRUE 1 #define FALSE 0 #define ERRSTRING strerror (errno) +static char *mtrr_strings[MTRR_NUM_TYPES] = +{ + "uncachable", /* 0 */ + "write-combining", /* 1 */ + "?", /* 2 */ + "?", /* 3 */ + "write-through", /* 4 */ + "write-protect", /* 5 */ + "write-back", /* 6 */ +}; int main () { @@ -232,13 +242,22 @@ Creating MTRRs from a C programme using ioctl()'s: #include #include #include -#define MTRR_NEED_STRINGS #include #define TRUE 1 #define FALSE 0 #define ERRSTRING strerror (errno) +static char *mtrr_strings[MTRR_NUM_TYPES] = +{ + "uncachable", /* 0 */ + "write-combining", /* 1 */ + "?", /* 2 */ + "?", /* 3 */ + "write-through", /* 4 */ + "write-protect", /* 5 */ + "write-back", /* 6 */ +}; int main (int argc, char **argv) { -- cgit v1.2.3 From dbc8700e27a94621de9d22c506c67913e0121501 Mon Sep 17 00:00:00 2001 From: David Howells Date: Mon, 10 Apr 2006 22:54:23 -0700 Subject: [PATCH] Fix memory barrier docs wrt atomic ops Fix the memory barrier documentation to attempt to describe atomic ops correctly. atomic_t ops that return a value _do_ imply smp_mb() either side, and so don't actually require smp_mb__*_atomic_*() special barriers. Also explains why special barriers exist in addition to normal barriers. Further fix the memory barrier documents to portray bitwise operation memory barrier effects correctly following Nick Piggin's comments. It makes the point that any atomic op that both modifies some state in memory and returns information on that state implies memory barriers on both sides. Signed-off-by: David Howells Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/memory-barriers.txt | 52 +++++++++++++++++++++++++-------------- 1 file changed, 33 insertions(+), 19 deletions(-) (limited to 'Documentation') diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index f8550310a6d5..528d52f52eeb 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -829,8 +829,8 @@ There are some more advanced barrier functions: (*) smp_mb__after_atomic_inc(); These are for use with atomic add, subtract, increment and decrement - functions, especially when used for reference counting. These functions - do not imply memory barriers. + functions that don't return a value, especially when used for reference + counting. These functions do not imply memory barriers. As an example, consider a piece of code that marks an object as being dead and then decrements the object's reference count: @@ -1263,15 +1263,17 @@ else. ATOMIC OPERATIONS ----------------- -Though they are technically interprocessor interaction considerations, atomic -operations are noted specially as they do _not_ generally imply memory -barriers. The possible offenders include: +Whilst they are technically interprocessor interaction considerations, atomic +operations are noted specially as some of them imply full memory barriers and +some don't, but they're very heavily relied on as a group throughout the +kernel. + +Any atomic operation that modifies some state in memory and returns information +about the state (old or new) implies an SMP-conditional general memory barrier +(smp_mb()) on each side of the actual operation. These include: xchg(); cmpxchg(); - test_and_set_bit(); - test_and_clear_bit(); - test_and_change_bit(); atomic_cmpxchg(); atomic_inc_return(); atomic_dec_return(); @@ -1282,21 +1284,31 @@ barriers. The possible offenders include: atomic_sub_and_test(); atomic_add_negative(); atomic_add_unless(); + test_and_set_bit(); + test_and_clear_bit(); + test_and_change_bit(); + +These are used for such things as implementing LOCK-class and UNLOCK-class +operations and adjusting reference counters towards object destruction, and as +such the implicit memory barrier effects are necessary. -These may be used for such things as implementing LOCK operations or controlling -the lifetime of objects by decreasing their reference counts. In such cases -they need preceding memory barriers. -The following may also be possible offenders as they may be used as UNLOCK -operations. +The following operation are potential problems as they do _not_ imply memory +barriers, but might be used for implementing such things as UNLOCK-class +operations: + atomic_set(); set_bit(); clear_bit(); change_bit(); - atomic_set(); + +With these the appropriate explicit memory barrier should be used if necessary +(smp_mb__before_clear_bit() for instance). -The following are a little tricky: +The following also do _not_ imply memory barriers, and so may require explicit +memory barriers under some circumstances (smp_mb__before_atomic_dec() for +instance)): atomic_add(); atomic_sub(); @@ -1317,10 +1329,12 @@ specific order. Basically, each usage case has to be carefully considered as to whether memory -barriers are needed or not. The simplest rule is probably: if the atomic -operation is protected by a lock, then it does not require a barrier unless -there's another operation within the critical section with respect to which an -ordering must be maintained. +barriers are needed or not. + +[!] Note that special memory barrier primitives are available for these +situations because on some CPUs the atomic instructions used imply full memory +barriers, and so barrier instructions are superfluous in conjunction with them, +and in such cases the special barrier primitives will be no-ops. See Documentation/atomic_ops.txt for more information. -- cgit v1.2.3 From c14038c39ddd9c14225907a05a6ac4d91d645ef1 Mon Sep 17 00:00:00 2001 From: David Howells Date: Mon, 10 Apr 2006 22:54:24 -0700 Subject: [PATCH] Improve data-dependency memory barrier example in documentation In the memory barrier document, improve the example of the data dependency barrier situation by: (1) showing the initial values of the variables involved; and (2) repeating the instruction sequence description, this time with the data dependency barrier actually shown to make it clear what the revised sequence actually is. Signed-off-by: David Howells Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/memory-barriers.txt | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 528d52f52eeb..92f0056d928c 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -610,6 +610,7 @@ loads. Consider the following sequence of events: CPU 1 CPU 2 ======================= ======================= + { B = 7; X = 9; Y = 8; C = &Y } STORE A = 1 STORE B = 2 @@ -651,7 +652,20 @@ In the above example, CPU 2 perceives that B is 7, despite the load of *C (which would be B) coming after the the LOAD of C. If, however, a data dependency barrier were to be placed between the load of C -and the load of *C (ie: B) on CPU 2, then the following will occur: +and the load of *C (ie: B) on CPU 2: + + CPU 1 CPU 2 + ======================= ======================= + { B = 7; X = 9; Y = 8; C = &Y } + STORE A = 1 + STORE B = 2 + + STORE C = &B LOAD X + STORE D = 4 LOAD C (gets &B) + + LOAD *C (reads B) + +then the following will occur: +-------+ : : : : | | +------+ +-------+ -- cgit v1.2.3 From 27d1ac2ef7d0b9250ca9fd2ef506e12866ce8fdf Mon Sep 17 00:00:00 2001 From: Tilman Schmidt Date: Mon, 10 Apr 2006 22:55:15 -0700 Subject: [PATCH] isdn4linux: Siemens Gigaset drivers: add README With Hansjoerg Lipp Add a README file for the Siemens Gigaset drivers to the Documentation/isdn directory. Signed-off-by: Hansjoerg Lipp Signed-off-by: Tilman Schmidt Cc: Karsten Keil Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/isdn/README.gigaset | 286 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 286 insertions(+) create mode 100644 Documentation/isdn/README.gigaset (limited to 'Documentation') diff --git a/Documentation/isdn/README.gigaset b/Documentation/isdn/README.gigaset new file mode 100644 index 000000000000..85a64defd385 --- /dev/null +++ b/Documentation/isdn/README.gigaset @@ -0,0 +1,286 @@ +GigaSet 307x Device Driver +========================== + +1. Requirements + ------------ +1.1. Hardware + -------- + This release supports the connection of the Gigaset 307x/417x family of + ISDN DECT bases via Gigaset M101 Data, Gigaset M105 Data or direct USB + connection. The following devices are reported to be compatible: + 307x/417x: + Gigaset SX255isdn + Gigaset SX353isdn + Sinus 45 [AB] isdn (Deutsche Telekom) + Sinus 721X/XA + Vox Chicago 390 ISDN (KPN Telecom) + M101: + Sinus 45 Data 1 (Telekom) + M105: + Gigaset USB Adapter DECT + Sinus 45 Data 2 (Telekom) + Sinus 721 data + Chicago 390 USB (KPN) + See also http://www.erbze.info/sinus_gigaset.htm and + http://gigaset307x.sourceforge.net/ + + We had also reports from users of Gigaset M105 who could use the drivers + with SX 100 and CX 100 ISDN bases (only in unimodem mode, see section 2.4.) + If you have another device that works with our driver, please let us know. + For example, Gigaset SX205isdn/Sinus 721 X SE and Gigaset SX303isdn bases + are just versions without answering machine of models known to work, so + they should work just as well; but so far we are lacking positive reports + on these. + + Chances of getting an USB device to work are good if the output of + lsusb + at the command line contains one of the following: + ID 0681:0001 + ID 0681:0002 + ID 0681:0009 + ID 0681:0021 + ID 0681:0022 + +1.2. Software + -------- + The driver works with ISDN4linux and so can be used with any software + which is able to use ISDN4linux for ISDN connections (voice or data). + CAPI4Linux support is planned but not yet available. + + There are some user space tools available at + http://sourceforge.net/projects/gigaset307x/ + which provide access to additional device specific functions like SMS, + phonebook or call journal. + + +2. How to use the driver + --------------------- +2.1. Modules + ------- + To get the device working, you have to load the proper kernel module. You + can do this using + modprobe modulename + where modulename is usb_gigaset (M105) or bas_gigaset (direct USB + connection to the base). + +2.2. Device nodes for user space programs + ------------------------------------ + The device can be accessed from user space (eg. by the user space tools + mentioned in 1.2.) through the device nodes: + + - /dev/ttyGU0 for M105 (USB data boxes) + - /dev/ttyGB0 for the base driver (direct USB connection) + + You can also select a "default device" which is used by the frontends when + no device node is given as parameter, by creating a symlink /dev/ttyG to + one of them, eg.: + + ln -s /dev/ttyGB0 /dev/ttyG + +2.3. ISDN4linux + ---------- + This is the "normal" mode of operation. After loading the module you can + set up the ISDN system just as you'd do with any ISDN card. + Your distribution should provide some configuration utility. + If not, you can use some HOWTOs like + http://www.linuxhaven.de/dlhp/HOWTO/DE-ISDN-HOWTO-5.html + If this doesn't work, because you have some recent device like SX100 where + debug output (see section 3.2.) shows something like this when dialing + CMD Received: ERROR + Available Params: 0 + Connection State: 0, Response: -1 + gigaset_process_response: resp_code -1 in ConState 0 ! + Timeout occurred + you might need to use unimodem mode: + +2.4. Unimodem mode + ------------- + This is needed for some devices [e.g. SX100] as they have problems with + the "normal" commands. + + If you have installed the command line tool gigacontr, you can enter + unimodem mode using + gigacontr --mode unimodem + You can switch back using + gigacontr --mode isdn + + You can also load the driver using e.g. + modprobe usb_gigaset startmode=0 + to prevent the driver from starting in "isdn4linux mode". + + In this mode the device works like a modem connected to a serial port + (the /dev/ttyGU0, ... mentioned above) which understands the commands + ATZ init, reset + => OK or ERROR + ATD + ATDT dial + => OK, CONNECT, + BUSY, + NO DIAL TONE, + NO CARRIER, + NO ANSWER + +++ change to command mode when connected + ATH hangup + + You can use some configuration tool of your distribution to configure this + "modem" or configure pppd/wvdial manually. There are some example ppp + configuration files and chat scripts in the gigaset-VERSION/ppp directory. + Please note that the USB drivers are not able to change the state of the + control lines (the M105 driver can be configured to use some undocumented + control requests, if you really need the control lines, though). This means + you must use "Stupid Mode" if you are using wvdial or you should use the + nocrtscts option of pppd. + You must also assure that the ppp_async module is loaded with the parameter + flag_time=0. You can do this e.g. by adding a line like + + options ppp_async flag_time=0 + + to /etc/modprobe.conf. If your distribution has some local module + configuration file like /etc/modprobe.conf.local, + using that should be preferred. + +2.5. Call-ID (CID) mode + ------------------ + Call-IDs are numbers used to tag commands to, and responses from, the + Gigaset base in order to support the simultaneous handling of multiple + ISDN calls. Their use can be enabled ("CID mode") or disabled ("Unimodem + mode"). Without Call-IDs (in Unimodem mode), only a very limited set of + functions is available. It allows outgoing data connections only, but + does not signal incoming calls or other base events. + + DECT cordless data devices (M10x) permanently occupy the cordless + connection to the base while Call-IDs are activated. As the Gigaset + bases only support one DECT data connection at a time, this prevents + other DECT cordless data devices from accessing the base. + + During active operation, the driver switches to the necessary mode + automatically. However, for the reasons above, the mode chosen when + the device is not in use (idle) can be selected by the user. + - If you want to receive incoming calls, you can use the default + settings (CID mode). + - If you have several DECT data devices (M10x) which you want to use + in turn, select Unimodem mode by passing the parameter "cidmode=0" to + the driver ("modprobe usb_gigaset cidmode=0" or modprobe.conf). + + If you want both of these at once, you are out of luck. + + You can also use /sys/module//parameters/cidmode for changing + the CID mode setting ( is usb_gigaset or bas_gigaset). + + +3. Troubleshooting + --------------- +3.1. Solutions to frequently reported problems + ----------------------------------------- + Problem: + You have a slow provider and isdn4linux gives up dialing too early. + Solution: + Load the isdn module using the dialtimeout option. You can do this e.g. + by adding a line like + + options isdn dialtimeout=15 + + to /etc/modprobe.conf. If your distribution has some local module + configuration file like /etc/modprobe.conf.local, + using that should be preferred. + + Problem: + Your isdn script aborts with a message about isdnlog. + Solution: + Try deactivating (or commenting out) isdnlog. This driver does not + support it. + + Problem: + You have two or more DECT data adapters (M101/M105) and only the + first one you turn on works. + Solution: + Select Unimodem mode for all DECT data adapters. (see section 2.4.) + +3.2. Telling the driver to provide more information + ---------------------------------------------- + Building the driver with the "Gigaset debugging" kernel configuration + option (CONFIG_GIGASET_DEBUG) gives it the ability to produce additional + information useful for debugging. + + You can control the amount of debugging information the driver produces by + writing an appropriate value to /sys/module/gigaset/parameters/debug, e.g. + echo 0 > /sys/module/gigaset/parameters/debug + switches off debugging output completely, + echo 0x10a020 > /sys/module/gigaset/parameters/debug + enables the standard set of debugging output messages. These values are + bit patterns where every bit controls a certain type of debugging output. + See the constants DEBUG_* in the source file gigaset.h for details. + + The initial value can be set using the debug parameter when loading the + module "gigaset", e.g. by adding a line + options gigaset debug=0 + to /etc/modprobe.conf, ... + + Generated debugging information can be found + - as output of the command + dmesg + - in system log files written by your syslog daemon, usually + in /var/log/, e.g. /var/log/messages. + +3.3. Reporting problems and bugs + --------------------------- + If you can't solve problems with the driver on your own, feel free to + use one of the forums, bug trackers, or mailing lists on + http://sourceforge.net/projects/gigaset307x + or write an electronic mail to the maintainers. + + Try to provide as much information as possible, such as + - distribution + - kernel version (uname -r) + - gcc version (gcc --version) + - hardware architecture (uname -m, ...) + - type and firmware version of your device (base and wireless module, + if any) + - output of "lsusb -v" (if using an USB device) + - error messages + - relevant system log messages (it would help if you activate debug + output as described in 3.2.) + + For help with general configuration problems not specific to our driver, + such as isdn4linux and network configuration issues, please refer to the + appropriate forums and newsgroups. + +3.4. Reporting problem solutions + --------------------------- + If you solved a problem with our drivers, wrote startup scripts for your + distribution, ... feel free to contact us (using one of the places + mentioned in 3.3.). We'd like to add scripts, hints, documentation + to the driver and/or the project web page. + + +4. Links, other software + --------------------- + - Sourceforge project developing this driver and associated tools + http://sourceforge.net/projects/gigaset307x + - Yahoo! Group on the Siemens Gigaset family of devices + http://de.groups.yahoo.com/group/Siemens-Gigaset + - Siemens Gigaset/T-Sinus compatibility table + http://www.erbze.info/sinus_gigaset.htm + + +5. Credits + ------- + Thanks to + + Karsten Keil + for his help with isdn4linux + Deti Fliegl + for his base driver code + Dennis Dietrich + for his kernel 2.6 patches + Andreas Rummel + for his work and logs to get unimodem mode working + Andreas Degert + for his logs and patches to get cx 100 working + Dietrich Feist + for his generous donation of one M105 and two M101 cordless adapters + Christoph Schweers + for his generous donation of a M34 device + + and all the other people who sent logs and other information. + -- cgit v1.2.3 From e97b81ddbb8b8c72b85330ac4a454a4513dcba8a Mon Sep 17 00:00:00 2001 From: "Mark M. Hoffman" Date: Thu, 23 Mar 2006 16:50:25 +0100 Subject: [PATCH] i2c-parport: Make type parameter mandatory This patch forces the user to specify what type of adapter is present when loading i2c-parport or i2c-parport-light. If none is specified, the driver init simply fails - instead of assuming adapter type 0. This alleviates the sometimes lengthy boot time delays which can be caused by accidentally building one of these into a kernel along with several i2c slave drivers that have lengthy probe routines (e.g. hwmon drivers). Kconfig and documentation updated accordingly. Signed-off-by: Mark M. Hoffman Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/i2c/busses/i2c-parport | 16 ++++++++++------ drivers/i2c/busses/Kconfig | 5 ++++- drivers/i2c/busses/i2c-parport-light.c | 9 +++++++-- drivers/i2c/busses/i2c-parport.c | 9 +++++++-- drivers/i2c/busses/i2c-parport.h | 2 +- 5 files changed, 29 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/i2c/busses/i2c-parport b/Documentation/i2c/busses/i2c-parport index d9f23c0763f1..77b995dfca22 100644 --- a/Documentation/i2c/busses/i2c-parport +++ b/Documentation/i2c/busses/i2c-parport @@ -12,18 +12,22 @@ meant as a replacement for the older, individual drivers: teletext adapters) It currently supports the following devices: - * Philips adapter - * home brew teletext adapter - * Velleman K8000 adapter - * ELV adapter - * Analog Devices evaluation boards (ADM1025, ADM1030, ADM1031, ADM1032) - * Barco LPT->DVI (K5800236) adapter + * (type=0) Philips adapter + * (type=1) home brew teletext adapter + * (type=2) Velleman K8000 adapter + * (type=3) ELV adapter + * (type=4) Analog Devices ADM1032 evaluation board + * (type=5) Analog Devices evaluation boards: ADM1025, ADM1030, ADM1031 + * (type=6) 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 way to autodetect the devices. Support for different pinout configurations can be easily added when needed. +Earlier kernels defaulted to type=0 (Philips). But now, if the type +parameter is missing, the driver will simply fail to initialize. + Building your own adapter ------------------------- diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index 089c6f5b24de..d6d44946a283 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -286,7 +286,10 @@ config I2C_PARPORT This driver is a replacement for (and was inspired by) an older driver named i2c-philips-par. The new driver supports more devices, and makes it easier to add support for new devices. - + + An adapter type parameter is now mandatory. Please read the file + Documentation/i2c/busses/i2c-parport for details. + Another driver exists, named i2c-parport-light, which doesn't depend on the parport driver. This is meant for embedded systems. Don't say Y here if you intend to say Y or M there. diff --git a/drivers/i2c/busses/i2c-parport-light.c b/drivers/i2c/busses/i2c-parport-light.c index c63025a4c861..e09ebbb2f9f0 100644 --- a/drivers/i2c/busses/i2c-parport-light.c +++ b/drivers/i2c/busses/i2c-parport-light.c @@ -121,9 +121,14 @@ static struct i2c_adapter parport_adapter = { static int __init i2c_parport_init(void) { - if (type < 0 || type >= ARRAY_SIZE(adapter_parm)) { + if (type < 0) { + printk(KERN_WARNING "i2c-parport: adapter type unspecified\n"); + return -ENODEV; + } + + if (type >= ARRAY_SIZE(adapter_parm)) { printk(KERN_WARNING "i2c-parport: invalid type (%d)\n", type); - type = 0; + return -ENODEV; } if (base == 0) { diff --git a/drivers/i2c/busses/i2c-parport.c b/drivers/i2c/busses/i2c-parport.c index 7e2e8cd1c14a..934bd55bae15 100644 --- a/drivers/i2c/busses/i2c-parport.c +++ b/drivers/i2c/busses/i2c-parport.c @@ -241,9 +241,14 @@ static struct parport_driver i2c_parport_driver = { static int __init i2c_parport_init(void) { - if (type < 0 || type >= ARRAY_SIZE(adapter_parm)) { + if (type < 0) { + printk(KERN_WARNING "i2c-parport: adapter type unspecified\n"); + return -ENODEV; + } + + if (type >= ARRAY_SIZE(adapter_parm)) { printk(KERN_WARNING "i2c-parport: invalid type (%d)\n", type); - type = 0; + return -ENODEV; } return parport_register_driver(&i2c_parport_driver); diff --git a/drivers/i2c/busses/i2c-parport.h b/drivers/i2c/busses/i2c-parport.h index d702e5e0388d..9ddd816d5d0f 100644 --- a/drivers/i2c/busses/i2c-parport.h +++ b/drivers/i2c/busses/i2c-parport.h @@ -90,7 +90,7 @@ static struct adapter_parm adapter_parm[] = { }, }; -static int type; +static int type = -1; module_param(type, int, 0); MODULE_PARM_DESC(type, "Type of adapter:\n" -- cgit v1.2.3 From 21440d313358043b0ce5e43b00ff3c9b35a8616c Mon Sep 17 00:00:00 2001 From: David Brownell Date: Sat, 1 Apr 2006 10:21:52 -0800 Subject: [PATCH] dma doc updates This updates the DMA API documentation to address a few issues: - The dma_map_sg() call results are used like pci_map_sg() results: using sg_dma_address() and sg_dma_len(). That's not wholly obvious to folk reading _only_ the "new" DMA-API.txt writeup. - Buffers allocated by dma_alloc_coherent() may not be completely free of coherency concerns ... some CPUs also have write buffers that may need to be flushed. - Cacheline coherence issues are now mentioned as being among issues which affect dma buffers, and complicate/prevent using of static and (especially) stack based buffers with the DMA calls. I don't think many drivers currently need to worry about flushing write buffers, but I did hit it with one SOC using external SDRAM for DMA descriptors: without explicit writebuffer flushing, the on-chip DMA controller accessed descriptors before the CPU completed the writes. Signed-off-by: David Brownell Signed-off-by: Greg Kroah-Hartman --- Documentation/DMA-API.txt | 49 +++++++++++++++++++++++++++++++------------ Documentation/DMA-mapping.txt | 22 ++++++++++++++----- 2 files changed, 53 insertions(+), 18 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt index 1af0f2d50220..2ffb0d62f0fe 100644 --- a/Documentation/DMA-API.txt +++ b/Documentation/DMA-API.txt @@ -33,7 +33,9 @@ pci_alloc_consistent(struct pci_dev *dev, size_t size, Consistent memory is memory for which a write by either the device or the processor can immediately be read by the processor or device -without having to worry about caching effects. +without having to worry about caching effects. (You may however need +to make sure to flush the processor's write buffers before telling +devices to read that memory.) This routine allocates a region of bytes of consistent memory. it also returns a which may be cast to an unsigned @@ -304,12 +306,12 @@ dma address with dma_mapping_error(). A non zero return value means the mapping could not be created and the driver should take appropriate action (eg reduce current DMA mapping usage or delay and try again later). -int -dma_map_sg(struct device *dev, struct scatterlist *sg, int nents, - enum dma_data_direction direction) -int -pci_map_sg(struct pci_dev *hwdev, struct scatterlist *sg, - int nents, int direction) + int + dma_map_sg(struct device *dev, struct scatterlist *sg, + int nents, enum dma_data_direction direction) + int + pci_map_sg(struct pci_dev *hwdev, struct scatterlist *sg, + int nents, int direction) Maps a scatter gather list from the block layer. @@ -327,12 +329,33 @@ critical that the driver do something, in the case of a block driver aborting the request or even oopsing is better than doing nothing and corrupting the filesystem. -void -dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nhwentries, - enum dma_data_direction direction) -void -pci_unmap_sg(struct pci_dev *hwdev, struct scatterlist *sg, - int nents, int direction) +With scatterlists, you use the resulting mapping like this: + + int i, count = dma_map_sg(dev, sglist, nents, direction); + struct scatterlist *sg; + + for (i = 0, sg = sglist; i < count; i++, sg++) { + hw_address[i] = sg_dma_address(sg); + hw_len[i] = sg_dma_len(sg); + } + +where nents is the number of entries in the sglist. + +The implementation is free to merge several consecutive sglist entries +into one (e.g. with an IOMMU, or if several pages just happen to be +physically contiguous) and returns the actual number of sg entries it +mapped them to. On failure 0, is returned. + +Then you should loop count times (note: this can be less than nents times) +and use sg_dma_address() and sg_dma_len() macros where you previously +accessed sg->address and sg->length as shown above. + + void + dma_unmap_sg(struct device *dev, struct scatterlist *sg, + int nhwentries, enum dma_data_direction direction) + void + pci_unmap_sg(struct pci_dev *hwdev, struct scatterlist *sg, + int nents, int direction) unmap the previously mapped scatter/gather list. All the parameters must be the same as those and passed in to the scatter/gather mapping diff --git a/Documentation/DMA-mapping.txt b/Documentation/DMA-mapping.txt index 10bf4deb96aa..7c717699032c 100644 --- a/Documentation/DMA-mapping.txt +++ b/Documentation/DMA-mapping.txt @@ -58,11 +58,15 @@ translating each of those pages back to a kernel address using something like __va(). [ EDIT: Update this when we integrate Gerd Knorr's generic code which does this. ] -This rule also means that you may not use kernel image addresses -(ie. items in the kernel's data/text/bss segment, or your driver's) -nor may you use kernel stack addresses for DMA. Both of these items -might be mapped somewhere entirely different than the rest of physical -memory. +This rule also means that you may use neither kernel image addresses +(items in data/text/bss segments), nor module image addresses, nor +stack addresses for DMA. These could all be mapped somewhere entirely +different than the rest of physical memory. Even if those classes of +memory could physically work with DMA, you'd need to ensure the I/O +buffers were cacheline-aligned. Without that, you'd see cacheline +sharing problems (data corruption) on CPUs with DMA-incoherent caches. +(The CPU could write to one word, DMA would write to a different one +in the same cache line, and one of them could be overwritten.) Also, this means that you cannot take the return of a kmap() call and DMA to/from that. This is similar to vmalloc(). @@ -284,6 +288,11 @@ There are two types of DMA mappings: in order to get correct behavior on all platforms. + Also, on some platforms your driver may need to flush CPU write + buffers in much the same way as it needs to flush write buffers + found in PCI bridges (such as by reading a register's value + after writing it). + - Streaming DMA mappings which are usually mapped for one DMA transfer, unmapped right after it (unless you use pci_dma_sync_* below) and for which hardware can optimize for sequential accesses. @@ -303,6 +312,9 @@ There are two types of DMA mappings: Neither type of DMA mapping has alignment restrictions that come from PCI, although some devices may have such restrictions. +Also, systems with caches that aren't DMA-coherent will work better +when the underlying buffers don't share cache lines with other data. + Using Consistent DMA mappings. -- cgit v1.2.3 From b8a99520f78e23e47f9efffeb0060c1385064ff6 Mon Sep 17 00:00:00 2001 From: Jamal Hadi Salim Date: Fri, 14 Apr 2006 15:05:16 -0700 Subject: [XFRM]: Add documentation for async events. Documentation to describe asynchronous xfrm events to help people writting HA code in user space. Signed-off-by: Jamal Hadi Salim Signed-off-by: David S. Miller --- Documentation/networking/xfrm_sync.txt | 166 +++++++++++++++++++++++++++++++++ 1 file changed, 166 insertions(+) create mode 100644 Documentation/networking/xfrm_sync.txt (limited to 'Documentation') diff --git a/Documentation/networking/xfrm_sync.txt b/Documentation/networking/xfrm_sync.txt new file mode 100644 index 000000000000..8be626f7c0b8 --- /dev/null +++ b/Documentation/networking/xfrm_sync.txt @@ -0,0 +1,166 @@ + +The sync patches work is based on initial patches from +Krisztian and others and additional patches +from Jamal . + +The end goal for syncing is to be able to insert attributes + generate +events so that the an SA can be safely moved from one machine to another +for HA purposes. +The idea is to synchronize the SA so that the takeover machine can do +the processing of the SA as accurate as possible if it has access to it. + +We already have the ability to generate SA add/del/upd events. +These patches add ability to sync and have accurate lifetime byte (to +ensure proper decay of SAs) and replay counters to avoid replay attacks +with as minimal loss at failover time. +This way a backup stays as closely uptodate as an active member. + +Because the above items change for every packet the SA receives, +it is possible for a lot of the events to be generated. +For this reason, we also add a nagle-like algorithm to restrict +the events. i.e we are going to set thresholds to say "let me +know if the replay sequence threshold is reached or 10 secs have passed" +These thresholds are set system-wide via sysctls or can be updated +per SA. + +The identified items that need to be synchronized are: +- the lifetime byte counter +note that: lifetime time limit is not important if you assume the failover +machine is known ahead of time since the decay of the time countdown +is not driven by packet arrival. +- the replay sequence for both inbound and outbound + +1) Message Structure +---------------------- + +nlmsghdr:aevent_id:optional-TLVs. + +The netlink message types are: + +XFRM_MSG_NEWAE and XFRM_MSG_GETAE. + +A XFRM_MSG_GETAE does not have TLVs. +A XFRM_MSG_NEWAE will have at least two TLVs (as is +discussed further below). + +aevent_id structure looks like: + + struct xfrm_aevent_id { + struct xfrm_usersa_id sa_id; + __u32 flags; + }; + +xfrm_usersa_id in this message layout identifies the SA. + +flags are used to indicate different things. The possible +flags are: + XFRM_AE_RTHR=1, /* replay threshold*/ + XFRM_AE_RVAL=2, /* replay value */ + XFRM_AE_LVAL=4, /* lifetime value */ + XFRM_AE_ETHR=8, /* expiry timer threshold */ + XFRM_AE_CR=16, /* Event cause is replay update */ + XFRM_AE_CE=32, /* Event cause is timer expiry */ + XFRM_AE_CU=64, /* Event cause is policy update */ + +How these flags are used is dependent on the direction of the +message (kernel<->user) as well the cause (config, query or event). +This is described below in the different messages. + +The pid will be set appropriately in netlink to recognize direction +(0 to the kernel and pid = processid that created the event +when going from kernel to user space) + +A program needs to subscribe to multicast group XFRMNLGRP_AEVENTS +to get notified of these events. + +2) TLVS reflect the different parameters: +----------------------------------------- + +a) byte value (XFRMA_LTIME_VAL) +This TLV carries the running/current counter for byte lifetime since +last event. + +b)replay value (XFRMA_REPLAY_VAL) +This TLV carries the running/current counter for replay sequence since +last event. + +c)replay threshold (XFRMA_REPLAY_THRESH) +This TLV carries the threshold being used by the kernel to trigger events +when the replay sequence is exceeded. + +d) expiry timer (XFRMA_ETIMER_THRESH) +This is a timer value in milliseconds which is used as the nagle +value to rate limit the events. + +3) Default configurations for the parameters: +---------------------------------------------- + +By default these events should be turned off unless there is +at least one listener registered to listen to the multicast +group XFRMNLGRP_AEVENTS. + +Programs installing SAs will need to specify the two thresholds, however, +in order to not change existing applications such as racoon +we also provide default threshold values for these different parameters +in case they are not specified. + +the two sysctls/proc entries are: +a) /proc/sys/net/core/sysctl_xfrm_aevent_etime +used to provide default values for the XFRMA_ETIMER_THRESH in incremental +units of time of 100ms. The default is 10 (1 second) + +b) /proc/sys/net/core/sysctl_xfrm_aevent_rseqth +used to provide default values for XFRMA_REPLAY_THRESH parameter +in incremental packet count. The default is two packets. + +4) Message types +---------------- + +a) XFRM_MSG_GETAE issued by user-->kernel. +XFRM_MSG_GETAE does not carry any TLVs. +The response is a XFRM_MSG_NEWAE which is formatted based on what +XFRM_MSG_GETAE queried for. +The response will always have XFRMA_LTIME_VAL and XFRMA_REPLAY_VAL TLVs. +*if XFRM_AE_RTHR flag is set, then XFRMA_REPLAY_THRESH is also retrieved +*if XFRM_AE_ETHR flag is set, then XFRMA_ETIMER_THRESH is also retrieved + +b) XFRM_MSG_NEWAE is issued by either user space to configure +or kernel to announce events or respond to a XFRM_MSG_GETAE. + +i) user --> kernel to configure a specific SA. +any of the values or threshold parameters can be updated by passing the +appropriate TLV. +A response is issued back to the sender in user space to indicate success +or failure. +In the case of success, additionally an event with +XFRM_MSG_NEWAE is also issued to any listeners as described in iii). + +ii) kernel->user direction as a response to XFRM_MSG_GETAE +The response will always have XFRMA_LTIME_VAL and XFRMA_REPLAY_VAL TLVs. +The threshold TLVs will be included if explicitly requested in +the XFRM_MSG_GETAE message. + +iii) kernel->user to report as event if someone sets any values or +thresholds for an SA using XFRM_MSG_NEWAE (as described in #i above). +In such a case XFRM_AE_CU flag is set to inform the user that +the change happened as a result of an update. +The message will always have XFRMA_LTIME_VAL and XFRMA_REPLAY_VAL TLVs. + +iv) kernel->user to report event when replay threshold or a timeout +is exceeded. +In such a case either XFRM_AE_CR (replay exceeded) or XFRM_AE_CE (timeout +happened) is set to inform the user what happened. +Note the two flags are mutually exclusive. +The message will always have XFRMA_LTIME_VAL and XFRMA_REPLAY_VAL TLVs. + +Exceptions to threshold settings +-------------------------------- + +If you have an SA that is getting hit by traffic in bursts such that +there is a period where the timer threshold expires with no packets +seen, then an odd behavior is seen as follows: +The first packet arrival after a timer expiry will trigger a timeout +aevent; i.e we dont wait for a timeout period or a packet threshold +to be reached. This is done for simplicity and efficiency reasons. + +-JHS -- cgit v1.2.3 From 67ab7f596b6adbaef5abc539dbee822e298a36e1 Mon Sep 17 00:00:00 2001 From: Russell King Date: Sat, 15 Apr 2006 20:46:11 +0100 Subject: [SERIAL] Update serial driver documentation Improve serial driver documentation: - Remove CVS id. - Update pointer to reference driver documentation. - Add comments about new uart_write_console function. - Add TIOCM_LOOP modem control bit description. - Add commentry about enable_ms method being called multiple times. - Add commentry about startup/shutdown method calling. - Mention that dereferencing port->info after shutdown is invalid. Signed-off-by: Russell King --- Documentation/serial/driver | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/serial/driver b/Documentation/serial/driver index 42ef9970bc86..df82116a9f26 100644 --- a/Documentation/serial/driver +++ b/Documentation/serial/driver @@ -3,14 +3,11 @@ -------------------- - $Id: driver,v 1.10 2002/07/22 15:27:30 rmk Exp $ - - This document is meant as a brief overview of some aspects of the new serial driver. It is not complete, any questions you have should be directed to -The reference implementation is contained within serial_amba.c. +The reference implementation is contained within amba_pl011.c. @@ -31,6 +28,11 @@ The serial core provides a few helper functions. This includes identifing the correct port structure (via uart_get_console) and decoding command line arguments (uart_parse_options). +There is also a helper function (uart_write_console) which performs a +character by character write, translating newlines to CRLF sequences. +Driver writers are recommended to use this function rather than implementing +their own version. + Locking ------- @@ -86,6 +88,7 @@ hardware. - TIOCM_DTR DTR signal. - TIOCM_OUT1 OUT1 signal. - TIOCM_OUT2 OUT2 signal. + - TIOCM_LOOP Set the port into loopback mode. If the appropriate bit is set, the signal should be driven active. If the bit is clear, the signal should be driven inactive. @@ -141,6 +144,10 @@ hardware. enable_ms(port) Enable the modem status interrupts. + This method may be called multiple times. Modem status + interrupts should be disabled when the shutdown method is + called. + Locking: port->lock taken. Interrupts: locally disabled. This call must not sleep @@ -160,6 +167,8 @@ hardware. state. Enable the port for reception. It should not activate RTS nor DTR; this will be done via a separate call to set_mctrl. + This method will only be called when the port is initially opened. + Locking: port_sem taken. Interrupts: globally disabled. @@ -169,6 +178,11 @@ hardware. RTS nor DTR; this will have already been done via a separate call to set_mctrl. + Drivers must not access port->info once this call has completed. + + This method will only be called when there are no more users of + this port. + Locking: port_sem taken. Interrupts: caller dependent. -- cgit v1.2.3 From 5e1222717932ff7d447af6da03c10a81fb60af7d Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Tue, 18 Apr 2006 22:21:51 -0700 Subject: [PATCH] Doc: vm/hugetlbpage update-2 Add new line of /proc/meminfo output. Explain the HugePage_ lines in /proc/meminfo (from Bill Irwin). Change KB to kB since the latter is what is used in the kernel. Signed-off-by: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/vm/hugetlbpage.txt | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/vm/hugetlbpage.txt b/Documentation/vm/hugetlbpage.txt index 2803f63c1a27..687104bfd09a 100644 --- a/Documentation/vm/hugetlbpage.txt +++ b/Documentation/vm/hugetlbpage.txt @@ -32,7 +32,16 @@ The output of "cat /proc/meminfo" will have lines like: ..... HugePages_Total: xxx HugePages_Free: yyy -Hugepagesize: zzz KB +HugePages_Rsvd: www +Hugepagesize: zzz kB + +where: +HugePages_Total is the size of the pool of hugepages. +HugePages_Free is the number of hugepages in the pool that are not yet +allocated. +HugePages_Rsvd is short for "reserved," and is the number of hugepages +for which a commitment to allocate from the pool has been made, but no +allocation has yet been made. It's vaguely analogous to overcommit. /proc/filesystems should also show a filesystem of type "hugetlbfs" configured in the kernel. -- cgit v1.2.3 From 73af994c7d58dd513922dc9d5cd76b124ec02b1b Mon Sep 17 00:00:00 2001 From: Valdis Kletnieks Date: Wed, 19 Apr 2006 09:23:09 +0200 Subject: [PATCH] Document online io scheduler switching We added the ability to change a block device's IO elevator scheduler both at kernel boot and on-the-fly, but we only documented the elevator= boot parameter. Add a quick how-to on doing it on the fly. Signed-off-by: Valdis Kletnieks Signed-off-by: Andrew Morton Signed-off-by: Jens Axboe --- Documentation/block/switching-sched.txt | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 Documentation/block/switching-sched.txt (limited to 'Documentation') diff --git a/Documentation/block/switching-sched.txt b/Documentation/block/switching-sched.txt new file mode 100644 index 000000000000..5fa130a67531 --- /dev/null +++ b/Documentation/block/switching-sched.txt @@ -0,0 +1,22 @@ +As of the Linux 2.6.10 kernel, it is now possible to change the +IO scheduler for a given block device on the fly (thus making it possible, +for instance, to set the CFQ scheduler for the system default, but +set a specific device to use the anticipatory or noop schedulers - which +can improve that device's throughput). + +To set a specific scheduler, simply do this: + +echo SCHEDNAME > /sys/block/DEV/queue/scheduler + +where SCHEDNAME is the name of a defined IO scheduler, and DEV is the +device name (hda, hdb, sga, or whatever you happen to have). + +The list of defined schedulers can be found by simply doing +a "cat /sys/block/DEV/queue/scheduler" - the list of valid names +will be displayed, with the currently selected scheduler in brackets: + +# cat /sys/block/hda/queue/scheduler +noop anticipatory deadline [cfq] +# echo anticipatory > /sys/block/hda/queue/scheduler +# cat /sys/block/hda/queue/scheduler +noop [anticipatory] deadline cfq -- cgit v1.2.3 From aafda4e0d0424180023e16f43785f9344ea35719 Mon Sep 17 00:00:00 2001 From: Adrian Bunk Date: Thu, 20 Apr 2006 02:43:21 -0700 Subject: [PATCH] update OBSOLETE_OSS_DRIVER schedule and dependencies Update the schedule for the removal of drivers depending on OBSOLETE_OSS_DRIVER as follows: - adjust OBSOLETE_OSS_DRIVER dependencie - from the release of 2.6.16 till the release of 2.6.17: approx. two months for users to report problems with the ALSA drivers for the same hardware - after the release of 2.6.17 (and before 2.6.18): remove the subset of drivers marked at OBSOLETE_OSS_DRIVER without known regressions in the ALSA drivers for the same hardware Additionally, correct some OBSOLETE_OSS_DRIVER dependencies. A rationale of the changes is in http://lkml.org/lkml/2006/1/28/135 Signed-off-by: Adrian Bunk Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/feature-removal-schedule.txt | 5 +- sound/oss/Kconfig | 336 +---------------------------- 2 files changed, 8 insertions(+), 333 deletions(-) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 293fed113dff..421bcfff6ad2 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -25,8 +25,9 @@ Who: Adrian Bunk --------------------------- -What: drivers depending on OBSOLETE_OSS_DRIVER -When: January 2006 +What: drivers that were depending on OBSOLETE_OSS_DRIVER + (config options already removed) +When: before 2.6.19 Why: OSS drivers with ALSA replacements Who: Adrian Bunk diff --git a/sound/oss/Kconfig b/sound/oss/Kconfig index 88e52dc84c09..f1ed710a18d7 100644 --- a/sound/oss/Kconfig +++ b/sound/oss/Kconfig @@ -5,23 +5,9 @@ # # Prompt user for primary drivers. -config OBSOLETE_OSS_DRIVER - bool "Obsolete OSS drivers" - depends on SOUND_PRIME - help - This option enables support for obsolete OSS drivers that - are scheduled for removal in the near future since there - are ALSA drivers for the same hardware. - - Please contact Adrian Bunk if you had to - say Y here because your soundcard is not properly supported - by ALSA. - - If unsure, say N. - config SOUND_BT878 tristate "BT878 audio dma" - depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER + depends on SOUND_PRIME && PCI ---help--- Audio DMA support for bt878 based grabber boards. As you might have already noticed, bt878 is listed with two functions in /proc/pci. @@ -35,48 +21,9 @@ config SOUND_BT878 To compile this driver as a module, choose M here: the module will be called btaudio. -config SOUND_CMPCI - tristate "C-Media PCI (CMI8338/8738)" - depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER - help - Say Y or M if you have a PCI sound card using the CMI8338 - or the CMI8738 chipset. Data on these chips are available at - . - - A userspace utility to control some internal registers of these - chips is available at - . - -config SOUND_CMPCI_FM - bool "Enable legacy FM" - depends on SOUND_CMPCI && X86 - help - Say Y here to enable the legacy FM (frequency-modulation) synthesizer - support on a card using the CMI8338 or CMI8378 chipset. Even it is - enabled, you need to set fmio as proper value to enable it. - Say N here if you don't need this. - -config SOUND_CMPCI_MIDI - bool "Enable legacy MPU-401" - depends on SOUND_CMPCI && X86 - help - Say Y here to enable the legacy MPU401 MIDI synthesizer support on a - card using the CMI8338 or CMI8378 chipset. Even it is enabled, - you need to set mpuio as proper value to enable it. - Say N here if you don't need this. - -config SOUND_CMPCI_JOYSTICK - bool "Enable joystick" - depends on SOUND_CMPCI && X86 && (GAMEPORT=y || SOUND_CMPCI=GAMEPORT) - help - Say Y here in order to enable the joystick port on a sound card using - the CMI8338 or the CMI8738 chipset. You need to config the - gameport support and set joystick parameter as 1 to use it. - Say N here if you don't need this. - config SOUND_EMU10K1 tristate "Creative SBLive! (EMU10K1)" - depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER + depends on SOUND_PRIME && PCI ---help--- Say Y or M if you have a PCI sound card using the EMU10K1 chipset, such as the Creative SBLive!, SB PCI512 or Emu-APS. @@ -108,13 +55,6 @@ config SOUND_FUSION series) when wired as native sound drivers with AC97 codecs. If this driver does not work try the CS4232 driver. -config SOUND_CS4281 - tristate "Crystal Sound CS4281" - depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER - help - Picture and feature list at - . - config SOUND_BCM_CS4297A tristate "Crystal Sound CS4297a (for Swarm)" depends on SOUND_PRIME && SIBYTE_SWARM @@ -125,22 +65,9 @@ config SOUND_BCM_CS4297A note that CONFIG_KGDB should not be enabled at the same time, since it also attempts to use this UART port. -config SOUND_ES1370 - tristate "Ensoniq AudioPCI (ES1370)" - depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER - help - Say Y or M if you have a PCI sound card utilizing the Ensoniq - ES1370 chipset, such as Ensoniq's AudioPCI (non-97). To find - out if your sound card uses an ES1370 without removing your - computer's cover, use lspci -n and look for the PCI ID - 1274:5000. Since Ensoniq was bought by Creative Labs, - Sound Blaster 64/PCI models are either ES1370 or ES1371 based. - This driver differs slightly from OSS/Free, so PLEASE READ - . - config SOUND_ES1371 tristate "Creative Ensoniq AudioPCI 97 (ES1371)" - depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER + depends on SOUND_PRIME && PCI help Say Y or M if you have a PCI sound card utilizing the Ensoniq ES1371 chipset, such as Ensoniq's AudioPCI97. To find out if @@ -151,33 +78,6 @@ config SOUND_ES1371 slightly from OSS/Free, so PLEASE READ . -config SOUND_ESSSOLO1 - tristate "ESS Technology Solo1" - depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER - help - Say Y or M if you have a PCI sound card utilizing the ESS Technology - Solo1 chip. To find out if your sound card uses a - Solo1 chip without removing your computer's cover, use - lspci -n and look for the PCI ID 125D:1969. This driver - differs slightly from OSS/Free, so PLEASE READ - . - -config SOUND_MAESTRO - tristate "ESS Maestro, Maestro2, Maestro2E driver" - depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER - help - Say Y or M if you have a sound system driven by ESS's Maestro line - of PCI sound chips. These include the Maestro 1, Maestro 2, and - Maestro 2E. See for more - details. - -config SOUND_MAESTRO3 - tristate "ESS Maestro3/Allegro driver (EXPERIMENTAL)" - depends on SOUND_PRIME && PCI && EXPERIMENTAL && OBSOLETE_OSS_DRIVER - help - Say Y or M if you have a sound system driven by ESS's Maestro 3 - PCI sound chip. - config SOUND_ICH tristate "Intel ICH (i8xx) audio support" depends on SOUND_PRIME && PCI @@ -185,24 +85,6 @@ config SOUND_ICH Support for integral audio in Intel's I/O Controller Hub (ICH) chipset, as used on the 810/820/840 motherboards. -config SOUND_HARMONY - tristate "PA Harmony audio driver" - depends on GSC_LASI && SOUND_PRIME && OBSOLETE_OSS_DRIVER - help - Say 'Y' or 'M' to include support for Harmony soundchip - on HP 712, 715/new and many other GSC based machines. - -config SOUND_SONICVIBES - tristate "S3 SonicVibes" - depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER - help - Say Y or M if you have a PCI sound card utilizing the S3 - SonicVibes chipset. To find out if your sound card uses a - SonicVibes chip without removing your computer's cover, use - lspci -n and look for the PCI ID 5333:CA00. This driver - differs slightly from OSS/Free, so PLEASE READ - . - config SOUND_VWSND tristate "SGI Visual Workstation Sound" depends on SOUND_PRIME && X86_VISWS @@ -231,10 +113,6 @@ config SOUND_VRC5477 integrated, multi-function controller chip for MIPS CPUs. Works with the AC97 codec. -config SOUND_AU1000 - tristate "Au1000 Sound" - depends on SOUND_PRIME && (SOC_AU1000 || SOC_AU1100 || SOC_AU1500) && OBSOLETE_OSS_DRIVER - config SOUND_AU1550_AC97 tristate "Au1550 AC97 Sound" depends on SOUND_PRIME && SOC_AU1550 @@ -505,26 +383,6 @@ config MSND_FIFOSIZE and Pinnacle). Larger values reduce the chance of data overruns at the expense of overall latency. If unsure, use the default. -config SOUND_VIA82CXXX - tristate "VIA 82C686 Audio Codec" - depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER - help - Say Y here to include support for the audio codec found on VIA - 82Cxxx-based chips. Typically these are built into a motherboard. - - DO NOT select Sound Blaster or Adlib with this driver, unless - you have a Sound Blaster or Adlib card in addition to your VIA - audio chip. - -config MIDI_VIA82CXXX - bool "VIA 82C686 MIDI" - depends on SOUND_VIA82CXXX && ISA_DMA_API - help - Answer Y to use the MIDI interface of the Via686. You may need to - enable this in the BIOS before it will work. This is for connection - to external MIDI hardware, and is not required for software playback - of MIDI files. - config SOUND_OSS tristate "OSS sound modules" depends on SOUND_PRIME && ISA_DMA_API @@ -576,18 +434,6 @@ config SOUND_AD1889 Say M here if you have a sound card based on the Analog Devices AD1889 chip. -config SOUND_SGALAXY - tristate "Aztech Sound Galaxy (non-PnP) cards" - depends on SOUND_OSS && OBSOLETE_OSS_DRIVER - help - This module initializes the older non Plug and Play sound galaxy - cards from Aztech. It supports the Waverider Pro 32 - 3D and the - Galaxy Washington 16. - - If you compile the driver into the kernel, you have to add - "sgalaxy=,,,," to the kernel command - line. - config SOUND_ADLIB tristate "Adlib Cards" depends on SOUND_OSS @@ -612,56 +458,6 @@ config SOUND_ACI_MIXER This driver is also available as a module and will be called aci. -config SOUND_CS4232 - tristate "Crystal CS4232 based (PnP) cards" - depends on SOUND_OSS && OBSOLETE_OSS_DRIVER - help - Say Y here if you have a card based on the Crystal CS4232 chip set, - which uses its own Plug and Play protocol. - - If you compile the driver into the kernel, you have to add - "cs4232=,,,,," to the kernel - command line. - - See for more information on - configuring this card. - -config SOUND_SSCAPE - tristate "Ensoniq SoundScape support" - depends on SOUND_OSS && OBSOLETE_OSS_DRIVER - help - Answer Y if you have a sound card based on the Ensoniq SoundScape - chipset. Such cards are being manufactured at least by Ensoniq, Spea - and Reveal (Reveal makes also other cards). - - If you compile the driver into the kernel, you have to add - "sscape=,,,," to the kernel command - line. - -config SOUND_GUS - tristate "Gravis Ultrasound support" - depends on SOUND_OSS && OBSOLETE_OSS_DRIVER - help - Say Y here for any type of Gravis Ultrasound card, including the GUS - or GUS MAX. See also for more - information on configuring this card with modules. - - If you compile the driver into the kernel, you have to add - "gus=,,," to the kernel command line. - -config SOUND_GUS16 - bool "16 bit sampling option of GUS (_NOT_ GUS MAX)" - depends on SOUND_GUS - help - Support for Gravis Ulstrasound (GUS) cards (other than the GUS), - sampling at 16-bit width. - -config SOUND_GUSMAX - bool "GUS MAX support" - depends on SOUND_GUS - help - Support for Gravis Ulstrasound MAX. - config SOUND_VMIDI tristate "Loopback MIDI device support" depends on SOUND_OSS @@ -742,7 +538,7 @@ config SOUND_MPU401 config SOUND_NM256 tristate "NM256AV/NM256ZX audio support" - depends on SOUND_OSS && OBSOLETE_OSS_DRIVER + depends on SOUND_OSS help Say M here to include audio support for the NeoMagic 256AV/256ZX chipsets. These are the audio chipsets found in the Sony @@ -752,35 +548,6 @@ config SOUND_NM256 See for further information. -config SOUND_MAD16 - tristate "OPTi MAD16 and/or Mozart based cards" - depends on SOUND_OSS && OBSOLETE_OSS_DRIVER - ---help--- - Answer Y if your card has a Mozart (OAK OTI-601) or MAD16 (OPTi - 82C928 or 82C929 or 82C931) audio interface chip. These chips are - quite common so it's possible that many no-name cards have one of - them. In addition the MAD16 chip is used in some cards made by known - manufacturers such as Turtle Beach (Tropez), Reveal (some models) - and Diamond (latest ones). Note however that the Tropez sound cards - have their own driver; if you have one of those, say N here and Y or - M to "Full support for Turtle Beach WaveFront", below. - - If you compile the driver into the kernel, you have to add - "mad16=,,,,," to the - kernel command line. - - See also and - for more information on setting - these cards up as modules. - -config MAD16_OLDCARD - bool "Support MIDI in older MAD16 based cards (requires SB)" - depends on SOUND_MAD16 - help - Answer Y (or M) if you have an older card based on the C928 or - Mozart chipset and you want to have MIDI support. If you enable this - option you also need to enable support for Sound Blaster. - config SOUND_PAS tristate "ProAudioSpectrum 16 support" depends on SOUND_OSS @@ -873,53 +640,9 @@ config SOUND_SB You can say M here to compile this driver as a module; the module is called sb. -config SOUND_AWE32_SYNTH - tristate "AWE32 synth" - depends on SOUND_OSS && OBSOLETE_OSS_DRIVER - help - Say Y here if you have a Sound Blaster SB32, AWE32-PnP, SB AWE64 or - similar sound card. See , - and the Soundblaster-AWE - mini-HOWTO, available from - for more info. - -config SOUND_WAVEFRONT - tristate "Full support for Turtle Beach WaveFront (Tropez Plus, Tropez, Maui) synth/soundcards" - depends on SOUND_OSS && m && OBSOLETE_OSS_DRIVER - help - Answer Y or M if you have a Tropez Plus, Tropez or Maui sound card - and read the files and - . - -config SOUND_MAUI - tristate "Limited support for Turtle Beach Wave Front (Maui, Tropez) synthesizers" - depends on SOUND_OSS && OBSOLETE_OSS_DRIVER - help - Say Y here if you have a Turtle Beach Wave Front, Maui, or Tropez - sound card. - - If you compile the driver into the kernel, you have to add - "maui=," to the kernel command line. - -config MAUI_HAVE_BOOT - bool "Have OSWF.MOT firmware file" - depends on SOUND_MAUI=y && !STANDALONE - help - Turtle Beach Maui and Tropez sound cards have a microcontroller - which needs to be initialized prior to use. OSWF.MOT is a file - distributed with the card's DOS/Windows drivers. Answer Y if you - have this file. - -config MAUI_BOOT_FILE - string "Full pathname of OSWF.MOT firmware file" - depends on MAUI_HAVE_BOOT - default "/etc/sound/oswf.mot" - help - Enter the full pathname of your OSWF.MOT file, starting from /. - config SOUND_YM3812 tristate "Yamaha FM synthesizer (YM3812/OPL-3) support" - depends on SOUND_OSS && OBSOLETE_OSS_DRIVER + depends on SOUND_OSS ---help--- Answer Y if your card has a FM chip made by Yamaha (OPL2/OPL3/OPL4). Answering Y is usually a safe and recommended choice, however some @@ -933,18 +656,6 @@ config SOUND_YM3812 If unsure, say Y. -config SOUND_OPL3SA1 - tristate "Yamaha OPL3-SA1 audio controller" - depends on SOUND_OSS && OBSOLETE_OSS_DRIVER - help - Say Y or M if you have a Yamaha OPL3-SA1 sound chip, which is - usually built into motherboards. Read - for details. - - If you compile the driver into the kernel, you have to add - "opl3sa=,,,,," to the kernel - command line. - config SOUND_OPL3SA2 tristate "Yamaha OPL3-SA2 and SA3 based PnP cards" depends on SOUND_OSS @@ -959,19 +670,6 @@ config SOUND_OPL3SA2 "opl3sa2=,,,,," to the kernel command line. -config SOUND_YMFPCI - tristate "Yamaha YMF7xx PCI audio (native mode)" - depends on SOUND_OSS && PCI && OBSOLETE_OSS_DRIVER - help - Support for Yamaha cards including the YMF711, YMF715, YMF718, - YMF719, YMF724, Waveforce 192XG, and Waveforce 192 Digital. - -config SOUND_YMFPCI_LEGACY - bool "Yamaha PCI legacy ports support" - depends on SOUND_YMFPCI - help - Support for YMF7xx PCI cards emulating an MP401. - config SOUND_UART6850 tristate "6850 UART support" depends on SOUND_OSS @@ -1101,30 +799,6 @@ config SOUND_KAHLUA tristate "XpressAudio Sound Blaster emulation" depends on SOUND_SB -config SOUND_ALI5455 - tristate "ALi5455 audio support" - depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER - -config SOUND_FORTE - tristate "ForteMedia FM801 driver" - depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER - help - Say Y or M if you want driver support for the ForteMedia FM801 PCI - audio controller (Abit AU10, Genius Sound Maker, HP Workstation - zx2000, and others). - -config SOUND_RME96XX - tristate "RME Hammerfall (RME96XX) support" - depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER - help - Say Y or M if you have a Hammerfall or Hammerfall light - multichannel card from RME. If you want to access advanced - features of the card, read . - -config SOUND_AD1980 - tristate "AD1980 front/back switch plugin" - depends on SOUND_PRIME && OBSOLETE_OSS_DRIVER - config SOUND_SH_DAC_AUDIO tristate "SuperH DAC audio support" depends on SOUND_PRIME && CPU_SH3 -- cgit v1.2.3