From e55a3e8aed99626dd9a9a6732fc0eb5b75ef29bd Mon Sep 17 00:00:00 2001 From: Roman Zippel Date: Thu, 8 Jun 2006 22:12:49 -0700 Subject: kconfig: remove leading whitespace in menu prompts This removes all the leading whitespace kconfig now warns about. Signed-off-by: Roman Zippel Signed-off-by: Andrew Morton Signed-off-by: Sam Ravnborg --- sound/oss/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'sound') diff --git a/sound/oss/Kconfig b/sound/oss/Kconfig index 558c6ed443b..e5bce16b0c4 100644 --- a/sound/oss/Kconfig +++ b/sound/oss/Kconfig @@ -838,6 +838,6 @@ config SOUND_SH_DAC_AUDIO depends on SOUND_PRIME && CPU_SH3 config SOUND_SH_DAC_AUDIO_CHANNEL - int " DAC channel" + int "DAC channel" default "1" depends on SOUND_SH_DAC_AUDIO -- cgit v1.2.3 From d6e05edc59ecd79e8badf440c0d295a979bdfa3e Mon Sep 17 00:00:00 2001 From: Andreas Mohr Date: Mon, 26 Jun 2006 18:35:02 +0200 Subject: spelling fixes acquired (aquired) contiguous (contigious) successful (succesful, succesfull) surprise (suprise) whether (weather) some other misspellings Signed-off-by: Andreas Mohr Signed-off-by: Adrian Bunk --- sound/core/seq/seq_memory.h | 2 +- sound/oss/sb_ess.c | 28 ++++++++++++++-------------- sound/pci/cs5535audio/cs5535audio_pcm.c | 2 +- 3 files changed, 16 insertions(+), 16 deletions(-) (limited to 'sound') diff --git a/sound/core/seq/seq_memory.h b/sound/core/seq/seq_memory.h index 39c60d9e1ef..63e91431a29 100644 --- a/sound/core/seq/seq_memory.h +++ b/sound/core/seq/seq_memory.h @@ -31,7 +31,7 @@ struct snd_seq_event_cell { struct snd_seq_event_cell *next; /* next cell */ }; -/* design note: the pool is a contigious block of memory, if we dynamicly +/* design note: the pool is a contiguous block of memory, if we dynamicly want to add additional cells to the pool be better store this in another pool as we need to know the base address of the pool when releasing memory. */ diff --git a/sound/oss/sb_ess.c b/sound/oss/sb_ess.c index fae05fe3de4..180e95c87e3 100644 --- a/sound/oss/sb_ess.c +++ b/sound/oss/sb_ess.c @@ -97,19 +97,19 @@ * * The documentation is an adventure: it's close but not fully accurate. I * found out that after a reset some registers are *NOT* reset, though the - * docs say the would be. Interresting ones are 0x7f, 0x7d and 0x7a. They are - * related to the Audio 2 channel. I also was suprised about the consequenses + * docs say the would be. Interesting ones are 0x7f, 0x7d and 0x7a. They are + * related to the Audio 2 channel. I also was surprised about the consequences * of writing 0x00 to 0x7f (which should be done by reset): The ES1887 moves * into ES1888 mode. This means that it claims IRQ 11, which happens to be my * ISDN adapter. Needless to say it no longer worked. I now understand why * after rebooting 0x7f already was 0x05, the value of my choice: the BIOS * did it. * - * Oh, and this is another trap: in ES1887 docs mixer register 0x70 is decribed - * as if it's exactly the same as register 0xa1. This is *NOT* true. The - * description of 0x70 in ES1869 docs is accurate however. + * Oh, and this is another trap: in ES1887 docs mixer register 0x70 is + * described as if it's exactly the same as register 0xa1. This is *NOT* true. + * The description of 0x70 in ES1869 docs is accurate however. * Well, the assumption about ES1869 was wrong: register 0x70 is very much - * like register 0xa1, except that bit 7 is allways 1, whatever you want + * like register 0xa1, except that bit 7 is always 1, whatever you want * it to be. * * When using audio 2 mixer register 0x72 seems te be meaningless. Only 0xa2 @@ -117,10 +117,10 @@ * * Software reset not being able to reset all registers is great! Especially * the fact that register 0x78 isn't reset is great when you wanna change back - * to single dma operation (simplex): audio 2 is still operation, and uses the - * same dma as audio 1: your ess changes into a funny echo machine. + * to single dma operation (simplex): audio 2 is still operational, and uses + * the same dma as audio 1: your ess changes into a funny echo machine. * - * Received the new that ES1688 is detected as a ES1788. Did some thinking: + * Received the news that ES1688 is detected as a ES1788. Did some thinking: * the ES1887 detection scheme suggests in step 2 to try if bit 3 of register * 0x64 can be changed. This is inaccurate, first I inverted the * check: "If * can be modified, it's a 1688", which lead to a correct detection @@ -135,7 +135,7 @@ * About recognition of ESS chips * * The distinction of ES688, ES1688, ES1788, ES1887 and ES1888 is described in - * a (preliminary ??) datasheet on ES1887. It's aim is to identify ES1887, but + * a (preliminary ??) datasheet on ES1887. Its aim is to identify ES1887, but * during detection the text claims that "this chip may be ..." when a step * fails. This scheme is used to distinct between the above chips. * It appears however that some PnP chips like ES1868 are recognized as ES1788 @@ -156,9 +156,9 @@ * * The existing ES1688 support didn't take care of the ES1688+ recording * levels very well. Whenever a device was selected (recmask) for recording - * it's recording level was loud, and it couldn't be changed. The fact that + * its recording level was loud, and it couldn't be changed. The fact that * internal register 0xb4 could take care of RECLEV, didn't work meaning until - * it's value was restored every time the chip was reset; this reset the + * its value was restored every time the chip was reset; this reset the * value of 0xb4 too. I guess that's what 4front also had (have?) trouble with. * * About ES1887 support: @@ -169,9 +169,9 @@ * the latter case the recording volumes are 0. * Now recording levels of inputs can be controlled, by changing the playback * levels. Futhermore several devices can be recorded together (which is not - * possible with the ES1688. + * possible with the ES1688). * Besides the separate recording level control for each input, the common - * recordig level can also be controlled by RECLEV as described above. + * recording level can also be controlled by RECLEV as described above. * * Not only ES1887 have this recording mixer. I know the following from the * documentation: diff --git a/sound/pci/cs5535audio/cs5535audio_pcm.c b/sound/pci/cs5535audio/cs5535audio_pcm.c index f0a48693d68..5450a9e8f13 100644 --- a/sound/pci/cs5535audio/cs5535audio_pcm.c +++ b/sound/pci/cs5535audio/cs5535audio_pcm.c @@ -143,7 +143,7 @@ static int cs5535audio_build_dma_packets(struct cs5535audio *cs5535au, if (dma->periods == periods && dma->period_bytes == period_bytes) return 0; - /* the u32 cast is okay because in snd*create we succesfully told + /* the u32 cast is okay because in snd*create we successfully told pci alloc that we're only 32 bit capable so the uppper will be 0 */ addr = (u32) substream->runtime->dma_addr; desc_addr = (u32) dma->desc_buf.addr; -- cgit v1.2.3 From b3c681e09193559ba15f6c9562bd37045f120a96 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Tue, 27 Jun 2006 02:53:53 -0700 Subject: [PATCH] update two drivers for poison.h Update two drivers to use poison.h. Signed-off-by: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- sound/oss/via82cxxx_audio.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'sound') diff --git a/sound/oss/via82cxxx_audio.c b/sound/oss/via82cxxx_audio.c index 1a921ee71ab..2343dedd44a 100644 --- a/sound/oss/via82cxxx_audio.c +++ b/sound/oss/via82cxxx_audio.c @@ -24,6 +24,7 @@ #include #include #include +#include #include #include #include @@ -3522,7 +3523,7 @@ err_out_have_mixer: err_out_kfree: #ifndef VIA_NDEBUG - memset (card, 0xAB, sizeof (*card)); /* poison memory */ + memset (card, OSS_POISON_FREE, sizeof (*card)); /* poison memory */ #endif kfree (card); @@ -3559,7 +3560,7 @@ static void __devexit via_remove_one (struct pci_dev *pdev) via_ac97_cleanup (card); #ifndef VIA_NDEBUG - memset (card, 0xAB, sizeof (*card)); /* poison memory */ + memset (card, OSS_POISON_FREE, sizeof (*card)); /* poison memory */ #endif kfree (card); -- cgit v1.2.3 From 11bcab9071ac204b1ca2bb0514ad1641bc4c280b Mon Sep 17 00:00:00 2001 From: Linus Torvalds Date: Tue, 27 Jun 2006 18:47:18 -0700 Subject: Properly delete sound/ppc/toonie.c The previous "delete" had actually just truncated it to a zero size, something that can easily happen if you just apply a patch. Signed-off-by: Linus Torvalds --- sound/ppc/toonie.c | 0 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 sound/ppc/toonie.c (limited to 'sound') diff --git a/sound/ppc/toonie.c b/sound/ppc/toonie.c deleted file mode 100644 index e69de29bb2d..00000000000 -- cgit v1.2.3