mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-29 19:21:31 -04:00
Fix occurrences of "the the "
Signed-off-by: Michael Opdenacker <[email protected]> Signed-off-by: Adrian Bunk <[email protected]>
This commit is contained in:
parent
02a3e59a08
commit
59c51591a0
72 changed files with 79 additions and 79 deletions
|
|
@ -6,7 +6,7 @@ Description:
|
|||
races, contains a naming policy within the kernel that is
|
||||
against the LSB, and can be replaced by using udev.
|
||||
The files fs/devfs/*, include/linux/devfs_fs*.h were removed,
|
||||
along with the the assorted devfs function calls throughout the
|
||||
along with the assorted devfs function calls throughout the
|
||||
kernel tree.
|
||||
|
||||
Users:
|
||||
|
|
|
|||
|
|
@ -125,7 +125,7 @@ three different ways to find such a match:
|
|||
usually register later during booting, or by module loading.
|
||||
|
||||
- Registering a driver using platform_driver_probe() works just like
|
||||
using platform_driver_register(), except that the the driver won't
|
||||
using platform_driver_register(), except that the driver won't
|
||||
be probed later if another device registers. (Which is OK, since
|
||||
this interface is only for use with non-hotpluggable devices.)
|
||||
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ The communication layer exists to allow NetLabel configuration and monitoring
|
|||
from user space. The NetLabel communication layer uses a message based
|
||||
protocol built on top of the Generic NETLINK transport mechanism. The exact
|
||||
formatting of these NetLabel messages as well as the Generic NETLINK family
|
||||
names can be found in the the 'net/netlabel/' directory as comments in the
|
||||
names can be found in the 'net/netlabel/' directory as comments in the
|
||||
header files as well as in 'include/net/netlabel.h'.
|
||||
|
||||
* Security Module API
|
||||
|
|
|
|||
|
|
@ -373,7 +373,7 @@ E.g. clearing pending interrupts.
|
|||
|
||||
3.6 Register IRQ handler
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
While calling request_irq() is the the last step described here,
|
||||
While calling request_irq() is the last step described here,
|
||||
this is often just another intermediate step to initialize a device.
|
||||
This step can often be deferred until the device is opened for use.
|
||||
|
||||
|
|
|
|||
|
|
@ -1444,7 +1444,7 @@ platforms are moved over to use the flattened-device-tree model.
|
|||
Basically, it is a bus of devices, that could act more or less
|
||||
as a complete entity (UCC, USB etc ). All of them should be siblings on
|
||||
the "root" qe node, using the common properties from there.
|
||||
The description below applies to the the qe of MPC8360 and
|
||||
The description below applies to the qe of MPC8360 and
|
||||
more nodes and properties would be extended in the future.
|
||||
|
||||
i) Root QE device
|
||||
|
|
|
|||
Loading…
Reference in a new issue