On Tue, 9 Oct 2007 18:13:55 -0400 Matt LaPlante wrote:

> Most of these fixes were already submitted for old kernel versions, and were 
> approved, but for some reason they never made it into the releases.  I've 
> updated the changes for the 2.6.23 kernel and attached the resulting patch.  
> Because this is a consolidation of a couple old missed patches, it touches 
> both Kconfigs and documentation texts.
> 
> Signed-off-by: Matt LaPlante <[EMAIL PROTECTED]>
> --

Hi Matt,
Mostly looks very good... a few nits below.


> diff -ru a/arch/ia64/Kconfig b/arch/ia64/Kconfig
> --- a/arch/ia64/Kconfig       2007-10-09 16:31:38.000000000 -0400
> +++ b/arch/ia64/Kconfig       2007-10-09 17:32:13.000000000 -0400
> @@ -443,9 +443,9 @@
>  config IA64_MC_ERR_INJECT
>       tristate "MC error injection support"
>       help
> -       Selets whether support for MC error injection. By enabling the
> -       support, kernel provide sysfs interface for user application to
> -       call MC error injection PAL procedure to inject various errors.
> +       Adds support for MC error injection. If enabled, the kernel 
> +          will provide a sysfs interface for user applications to

Use tab + 2 spaces to indent above instead of all spaces.

> +       call MC error injection PAL procedures to inject various errors.
>         This is a useful tool for MCA testing.
>  
>         If you're unsure, do not select this option.
> diff -ru a/Documentation/arm/Samsung-S3C24XX/DMA.txt 
> b/Documentation/arm/Samsung-S3C24XX/DMA.txt
> --- a/Documentation/arm/Samsung-S3C24XX/DMA.txt       2007-10-09 
> 16:31:38.000000000 -0400
> +++ b/Documentation/arm/Samsung-S3C24XX/DMA.txt       2007-10-09 
> 17:32:13.000000000 -0400
> @@ -17,15 +17,15 @@
>     channels to all sources, which means that some devices
>     have a restricted number of channels that can be used.
>  
> -   To allow flexibilty for each cpu type and board, the
> -   dma code can be given an dma ordering structure which
> +   To allow flexibility for each CPU type and board, the
> +   DMA code can be given a DMA ordering structure which
>     allows the order of channel search to be specified, as
>     well as allowing the prohibition of certain claims.
>  
>     struct s3c24xx_dma_order has a list of channels, and
> -   each channel within has a slot for a list of dma
> -   channel numbers. The slots are searched in order, for
> -   the presence of a dma channel number with DMA_CH_VALID
> +   each channel within has a slot for a list of DMA
> +   channel numbers. The slots are searched in order for
> +   the presence of a DMA channel number with DMA_CH_VALID
>     orred in.

      or-ed ?

>  
>     If the order has the flag DMA_CH_NEVER set, then after

> diff -ru a/Documentation/driver-model/devres.txt 
> b/Documentation/driver-model/devres.txt
> --- a/Documentation/driver-model/devres.txt   2007-10-09 16:31:38.000000000 
> -0400
> +++ b/Documentation/driver-model/devres.txt   2007-10-09 17:32:13.000000000 
> -0400
> @@ -32,7 +32,7 @@
>  
>  For one reason or another, low level drivers don't receive as much
>  attention or testing as core code, and bugs on driver detach or
> -initilaization failure doesn't happen often enough to be noticeable.
> +initialization failure doesn't happen often enough to be noticeable.

                          don't

>  Init failure path is worse because it's much less travelled while
>  needs to handle multiple entry points.
>  
> diff -ru a/Documentation/input/iforce-protocol.txt 
> b/Documentation/input/iforce-protocol.txt
> --- a/Documentation/input/iforce-protocol.txt 2007-10-09 16:31:38.000000000 
> -0400
> +++ b/Documentation/input/iforce-protocol.txt 2007-10-09 17:43:28.000000000 
> -0400
> @@ -234,12 +234,16 @@
>  
>  ** Appendix: How to study the protocol ? **
>  
> -1. Generate effects using the force editor provided with the DirectX SDK, or 
> use Immersion Studio (freely available at their web site in the developer 
> section: www.immersion.com)
> -2. Start a soft spying RS232 or USB (depending on where you connected your 
> joystick/wheel). I used ComPortSpy from fCoder (alpha version!)
> +1. Generate effects using the force editor provided with the DirectX SDK, or 
> +use Immersion Studio (freely available at their web site in the developer 
> section: 
> +www.immersion.com)
> +2. Start a soft spying RS232 or USB (depending on where you connected your 
> +joystick/wheel). I used ComPortSpy from fCoder (alpha version!)
>  3. Play the effect, and watch what happens on the spy screen.
>  
>  A few words about ComPortSpy:
> -At first glance, this soft seems, hum, well... buggy. In fact, data appear 
> with a few seconds latency. Personnaly, I restart it every time I play an 
> effect.
> +At first glance, this soft seems, hum, well... buggy. In fact, data appear 
> with a 

                         software
Also, that line ends with a space... (9 of those found in the entire patch)

> +few seconds latency. Personally, I restart it every time I play an effect.
>  Remember it's free (as in free beer) and alpha!
>  
>  ** URLS **

> diff -ru a/Documentation/powerpc/eeh-pci-error-recovery.txt 
> b/Documentation/powerpc/eeh-pci-error-recovery.txt
> --- a/Documentation/powerpc/eeh-pci-error-recovery.txt        2007-10-09 
> 16:31:38.000000000 -0400
> +++ b/Documentation/powerpc/eeh-pci-error-recovery.txt        2007-10-09 
> 17:32:13.000000000 -0400
> @@ -36,7 +36,7 @@
>  EEH was originally designed to guard against hardware failure, such
>  as PCI cards dying from heat, humidity, dust, vibration and bad
>  electrical connections. The vast majority of EEH errors seen in
> -"real life" are due to eithr poorly seated PCI cards, or,
> +"real life" are due to either poorly seated PCI cards, or,
>  unfortunately quite commonly, due device driver bugs, device firmware

                                 due to

>  bugs, and sometimes PCI card hardware bugs.
>  
> diff -ru a/Documentation/scsi/ibmmca.txt b/Documentation/scsi/ibmmca.txt
> --- a/Documentation/scsi/ibmmca.txt   2007-10-09 16:31:38.000000000 -0400
> +++ b/Documentation/scsi/ibmmca.txt   2007-10-09 17:32:13.000000000 -0400
> @@ -251,7 +251,7 @@
>     lun>0 or to non-existing devices, in order to satisfy the subsystem, if 
>     there are less than 15 SCSI-devices connected. In the case of more than 
> 15 
>     devices, the dynamical mapping goes active. If the get_scsi[][] reports a 
> -   device to be existant, but it has no ldn assigned, it gets a ldn out of 7 
> +   device to be existent, but it has no ldn assigned, it gets a ldn out of 7

                                                                 an ldn

>     to 14. The numbers are assigned in cyclic order. Therefore it takes 8 
>     dynamical reassignments on the SCSI-devices, until a certain device 
>     loses its ldn again. This assures that dynamical remapping is avoided 

> diff -ru a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> --- a/drivers/input/misc/Kconfig      2007-10-09 16:31:38.000000000 -0400
> +++ b/drivers/input/misc/Kconfig      2007-10-09 17:32:13.000000000 -0400
> @@ -70,9 +70,9 @@
>       select LEDS_CLASS
>       select CHECK_SIGNATURE
>       help
> -       Say Y here for support of Winstron laptop button interface, used on
> +       Say Y here for support of Winstron laptop button interfaces, used on

                                    Wistron

>         laptops of various brands, including Acer and Fujitsu-Siemens. If
> -       available, mail and wifi leds will be controlable via /sys/class/leds.
> +       available, mail and wifi LEDs will be controllable via 
> /sys/class/leds.
>  
>         To compile this driver as a module, choose M here: the module will
>         be called wistron_btns.
> diff -ru a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
> --- a/drivers/mtd/maps/Kconfig        2007-10-09 16:31:38.000000000 -0400
> +++ b/drivers/mtd/maps/Kconfig        2007-10-09 17:32:13.000000000 -0400
> @@ -73,12 +73,12 @@
>       depends on PMC_MSP && MTD_CFI
>       select MTD_PARTITIONS
>       help
> -       This provides a 'mapping' driver which support the way
> +       This provides a 'mapping' driver which supports the way
>            in which user-programmable flash chips are connected on the
> -          PMC-Sierra MSP eval/demo boards
> +          PMC-Sierra MSP eval/demo boards.

Use tab + 2 spaces for indent.

>  
>  choice
> -     prompt "Maximum mappable memory avialable for flash IO"
> +     prompt "Maximum mappable memory available for flash IO"
>       depends on MTD_PMC_MSP_EVM
>       default MSP_FLASH_MAP_LIMIT_32M
>  


Thanks.

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to