Documentation/: it's -> its where appropriate
Fix obvious cases of "it's" being used when "its" was meant. Signed-off-by: Francis Galiegue <fgaliegue@gmail.com> Acked-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This commit is contained in:
parent
6c9468e9eb
commit
a33f32244d
@ -43,7 +43,7 @@ Date: September 2008
|
|||||||
Contact: Badari Pulavarty <pbadari@us.ibm.com>
|
Contact: Badari Pulavarty <pbadari@us.ibm.com>
|
||||||
Description:
|
Description:
|
||||||
The file /sys/devices/system/memory/memoryX/state
|
The file /sys/devices/system/memory/memoryX/state
|
||||||
is read-write. When read, it's contents show the
|
is read-write. When read, its contents show the
|
||||||
online/offline state of the memory section. When written,
|
online/offline state of the memory section. When written,
|
||||||
root can toggle the the online/offline state of a removable
|
root can toggle the the online/offline state of a removable
|
||||||
memory section (see removable file description above)
|
memory section (see removable file description above)
|
||||||
|
@ -742,7 +742,7 @@ failure can be determined by:
|
|||||||
|
|
||||||
Closing
|
Closing
|
||||||
|
|
||||||
This document, and the API itself, would not be in it's current
|
This document, and the API itself, would not be in its current
|
||||||
form without the feedback and suggestions from numerous individuals.
|
form without the feedback and suggestions from numerous individuals.
|
||||||
We would like to specifically mention, in no particular order, the
|
We would like to specifically mention, in no particular order, the
|
||||||
following people:
|
following people:
|
||||||
|
@ -490,7 +490,7 @@ void (*host_stop) (struct ata_host_set *host_set);
|
|||||||
allocates space for a legacy IDE PRD table and returns.
|
allocates space for a legacy IDE PRD table and returns.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
->port_stop() is called after ->host_stop(). It's sole function
|
->port_stop() is called after ->host_stop(). Its sole function
|
||||||
is to release DMA/memory resources, now that they are no longer
|
is to release DMA/memory resources, now that they are no longer
|
||||||
actively being used. Many drivers also free driver-private
|
actively being used. Many drivers also free driver-private
|
||||||
data from port at this time.
|
data from port at this time.
|
||||||
|
@ -216,7 +216,7 @@ The driver should return one of the following result codes:
|
|||||||
|
|
||||||
- PCI_ERS_RESULT_NEED_RESET
|
- PCI_ERS_RESULT_NEED_RESET
|
||||||
Driver returns this if it thinks the device is not
|
Driver returns this if it thinks the device is not
|
||||||
recoverable in it's current state and it needs a slot
|
recoverable in its current state and it needs a slot
|
||||||
reset to proceed.
|
reset to proceed.
|
||||||
|
|
||||||
- PCI_ERS_RESULT_DISCONNECT
|
- PCI_ERS_RESULT_DISCONNECT
|
||||||
@ -241,7 +241,7 @@ in working condition.
|
|||||||
|
|
||||||
The driver is not supposed to restart normal driver I/O operations
|
The driver is not supposed to restart normal driver I/O operations
|
||||||
at this point. It should limit itself to "probing" the device to
|
at this point. It should limit itself to "probing" the device to
|
||||||
check it's recoverability status. If all is right, then the platform
|
check its recoverability status. If all is right, then the platform
|
||||||
will call resume() once all drivers have ack'd link_reset().
|
will call resume() once all drivers have ack'd link_reset().
|
||||||
|
|
||||||
Result codes:
|
Result codes:
|
||||||
|
@ -73,7 +73,7 @@ NOTE: Smack labels are limited to 23 characters. The attr command
|
|||||||
If you don't do anything special all users will get the floor ("_")
|
If you don't do anything special all users will get the floor ("_")
|
||||||
label when they log in. If you do want to log in via the hacked ssh
|
label when they log in. If you do want to log in via the hacked ssh
|
||||||
at other labels use the attr command to set the smack value on the
|
at other labels use the attr command to set the smack value on the
|
||||||
home directory and it's contents.
|
home directory and its contents.
|
||||||
|
|
||||||
You can add access rules in /etc/smack/accesses. They take the form:
|
You can add access rules in /etc/smack/accesses. They take the form:
|
||||||
|
|
||||||
|
@ -32,7 +32,7 @@ Notes:
|
|||||||
|
|
||||||
- The flash on board is divided into 3 partitions.
|
- The flash on board is divided into 3 partitions.
|
||||||
You should be careful to use flash on board.
|
You should be careful to use flash on board.
|
||||||
It's partition is different from GraphicsClient Plus and GraphicsMaster
|
Its partition is different from GraphicsClient Plus and GraphicsMaster
|
||||||
|
|
||||||
- 16bpp mode requires a different cable than what ships with the board.
|
- 16bpp mode requires a different cable than what ships with the board.
|
||||||
Contact ADS or look through the manual to wire your own. Currently,
|
Contact ADS or look through the manual to wire your own. Currently,
|
||||||
|
@ -7,7 +7,7 @@ The driver only implements a four-wire touch panel protocol.
|
|||||||
|
|
||||||
The touchscreen driver is maintenance free except for the pen-down or
|
The touchscreen driver is maintenance free except for the pen-down or
|
||||||
touch threshold. Some resistive displays and board combinations may
|
touch threshold. Some resistive displays and board combinations may
|
||||||
require tuning of this threshold. The driver exposes some of it's
|
require tuning of this threshold. The driver exposes some of its
|
||||||
internal state in the sys filesystem. If the kernel is configured
|
internal state in the sys filesystem. If the kernel is configured
|
||||||
with it, CONFIG_SYSFS, and sysfs is mounted at /sys, there will be a
|
with it, CONFIG_SYSFS, and sysfs is mounted at /sys, there will be a
|
||||||
directory
|
directory
|
||||||
|
@ -320,7 +320,7 @@ counter decrement would not become globally visible until the
|
|||||||
obj->active update does.
|
obj->active update does.
|
||||||
|
|
||||||
As a historical note, 32-bit Sparc used to only allow usage of
|
As a historical note, 32-bit Sparc used to only allow usage of
|
||||||
24-bits of it's atomic_t type. This was because it used 8 bits
|
24-bits of its atomic_t type. This was because it used 8 bits
|
||||||
as a spinlock for SMP safety. Sparc32 lacked a "compare and swap"
|
as a spinlock for SMP safety. Sparc32 lacked a "compare and swap"
|
||||||
type instruction. However, 32-bit Sparc has since been moved over
|
type instruction. However, 32-bit Sparc has since been moved over
|
||||||
to a "hash table of spinlocks" scheme, that allows the full 32-bit
|
to a "hash table of spinlocks" scheme, that allows the full 32-bit
|
||||||
|
@ -43,7 +43,7 @@
|
|||||||
void bfin_gpio_irq_free(unsigned gpio);
|
void bfin_gpio_irq_free(unsigned gpio);
|
||||||
|
|
||||||
The request functions will record the function state for a certain pin,
|
The request functions will record the function state for a certain pin,
|
||||||
the free functions will clear it's function state.
|
the free functions will clear its function state.
|
||||||
Once a pin is requested, it can't be requested again before it is freed by
|
Once a pin is requested, it can't be requested again before it is freed by
|
||||||
previous caller, otherwise kernel will dump stacks, and the request
|
previous caller, otherwise kernel will dump stacks, and the request
|
||||||
function fail.
|
function fail.
|
||||||
|
@ -5,7 +5,7 @@
|
|||||||
|
|
||||||
This document describes the cache/tlb flushing interfaces called
|
This document describes the cache/tlb flushing interfaces called
|
||||||
by the Linux VM subsystem. It enumerates over each interface,
|
by the Linux VM subsystem. It enumerates over each interface,
|
||||||
describes it's intended purpose, and what side effect is expected
|
describes its intended purpose, and what side effect is expected
|
||||||
after the interface is invoked.
|
after the interface is invoked.
|
||||||
|
|
||||||
The side effects described below are stated for a uniprocessor
|
The side effects described below are stated for a uniprocessor
|
||||||
@ -231,7 +231,7 @@ require a whole different set of interfaces to handle properly.
|
|||||||
The biggest problem is that of virtual aliasing in the data cache
|
The biggest problem is that of virtual aliasing in the data cache
|
||||||
of a processor.
|
of a processor.
|
||||||
|
|
||||||
Is your port susceptible to virtual aliasing in it's D-cache?
|
Is your port susceptible to virtual aliasing in its D-cache?
|
||||||
Well, if your D-cache is virtually indexed, is larger in size than
|
Well, if your D-cache is virtually indexed, is larger in size than
|
||||||
PAGE_SIZE, and does not prevent multiple cache lines for the same
|
PAGE_SIZE, and does not prevent multiple cache lines for the same
|
||||||
physical address from existing at once, you have this problem.
|
physical address from existing at once, you have this problem.
|
||||||
@ -249,7 +249,7 @@ one way to solve this (in particular SPARC_FLAG_MMAPSHARED).
|
|||||||
Next, you have to solve the D-cache aliasing issue for all
|
Next, you have to solve the D-cache aliasing issue for all
|
||||||
other cases. Please keep in mind that fact that, for a given page
|
other cases. Please keep in mind that fact that, for a given page
|
||||||
mapped into some user address space, there is always at least one more
|
mapped into some user address space, there is always at least one more
|
||||||
mapping, that of the kernel in it's linear mapping starting at
|
mapping, that of the kernel in its linear mapping starting at
|
||||||
PAGE_OFFSET. So immediately, once the first user maps a given
|
PAGE_OFFSET. So immediately, once the first user maps a given
|
||||||
physical page into its address space, by implication the D-cache
|
physical page into its address space, by implication the D-cache
|
||||||
aliasing problem has the potential to exist since the kernel already
|
aliasing problem has the potential to exist since the kernel already
|
||||||
|
@ -244,7 +244,7 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
|
|||||||
we have to check if OLDPAGE/NEWPAGE is a valid page after commit().
|
we have to check if OLDPAGE/NEWPAGE is a valid page after commit().
|
||||||
|
|
||||||
8. LRU
|
8. LRU
|
||||||
Each memcg has its own private LRU. Now, it's handling is under global
|
Each memcg has its own private LRU. Now, its handling is under global
|
||||||
VM's control (means that it's handled under global zone->lru_lock).
|
VM's control (means that it's handled under global zone->lru_lock).
|
||||||
Almost all routines around memcg's LRU is called by global LRU's
|
Almost all routines around memcg's LRU is called by global LRU's
|
||||||
list management functions under zone->lru_lock().
|
list management functions under zone->lru_lock().
|
||||||
|
@ -263,7 +263,7 @@ some of the pages cached in the cgroup (page cache pages).
|
|||||||
|
|
||||||
4.2 Task migration
|
4.2 Task migration
|
||||||
|
|
||||||
When a task migrates from one cgroup to another, it's charge is not
|
When a task migrates from one cgroup to another, its charge is not
|
||||||
carried forward by default. The pages allocated from the original cgroup still
|
carried forward by default. The pages allocated from the original cgroup still
|
||||||
remain charged to it, the charge is dropped when the page is freed or
|
remain charged to it, the charge is dropped when the page is freed or
|
||||||
reclaimed.
|
reclaimed.
|
||||||
|
@ -88,7 +88,7 @@ int cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask);
|
|||||||
int gfp_mask - GFP mask.
|
int gfp_mask - GFP mask.
|
||||||
|
|
||||||
Note: When registering new callback user, connector core assigns
|
Note: When registering new callback user, connector core assigns
|
||||||
netlink group to the user which is equal to it's id.idx.
|
netlink group to the user which is equal to its id.idx.
|
||||||
|
|
||||||
/*****************************************/
|
/*****************************************/
|
||||||
Protocol description.
|
Protocol description.
|
||||||
|
@ -41,7 +41,7 @@ This application requires the following to function properly as of now.
|
|||||||
|
|
||||||
* Cards that fall in this category
|
* Cards that fall in this category
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
At present the cards that fall in this category are the Twinhan and it's
|
At present the cards that fall in this category are the Twinhan and its
|
||||||
clones, these cards are available as VVMER, Tomato, Hercules, Orange and
|
clones, these cards are available as VVMER, Tomato, Hercules, Orange and
|
||||||
so on.
|
so on.
|
||||||
|
|
||||||
|
@ -1,7 +1,7 @@
|
|||||||
Thanks go to the following people for patches and contributions:
|
Thanks go to the following people for patches and contributions:
|
||||||
|
|
||||||
Michael Hunold <m.hunold@gmx.de>
|
Michael Hunold <m.hunold@gmx.de>
|
||||||
for the initial saa7146 driver and it's recent overhaul
|
for the initial saa7146 driver and its recent overhaul
|
||||||
|
|
||||||
Christian Theiss
|
Christian Theiss
|
||||||
for his work on the initial Linux DVB driver
|
for his work on the initial Linux DVB driver
|
||||||
|
@ -146,7 +146,7 @@ found to be inadequate, in this case. The Generic Netlink system was
|
|||||||
used for this as raw Netlink would lead to a significant increase in
|
used for this as raw Netlink would lead to a significant increase in
|
||||||
complexity. There's no question that the Generic Netlink system is an
|
complexity. There's no question that the Generic Netlink system is an
|
||||||
elegant solution for common case ioctl functions but it's not a complete
|
elegant solution for common case ioctl functions but it's not a complete
|
||||||
replacement probably because it's primary purpose in life is to be a
|
replacement probably because its primary purpose in life is to be a
|
||||||
message bus implementation rather than specifically an ioctl replacement.
|
message bus implementation rather than specifically an ioctl replacement.
|
||||||
While it would be possible to work around this there is one concern
|
While it would be possible to work around this there is one concern
|
||||||
that lead to the decision to not use it. This is that the autofs
|
that lead to the decision to not use it. This is that the autofs
|
||||||
|
@ -90,7 +90,7 @@ Mount Options
|
|||||||
Specify the IP and/or port the client should bind to locally.
|
Specify the IP and/or port the client should bind to locally.
|
||||||
There is normally not much reason to do this. If the IP is not
|
There is normally not much reason to do this. If the IP is not
|
||||||
specified, the client's IP address is determined by looking at the
|
specified, the client's IP address is determined by looking at the
|
||||||
address it's connection to the monitor originates from.
|
address its connection to the monitor originates from.
|
||||||
|
|
||||||
wsize=X
|
wsize=X
|
||||||
Specify the maximum write size in bytes. By default there is no
|
Specify the maximum write size in bytes. By default there is no
|
||||||
|
@ -47,7 +47,7 @@ You'll want to start heartbeating on a volume which all the nodes in
|
|||||||
your lockspace can access. The easiest way to do this is via
|
your lockspace can access. The easiest way to do this is via
|
||||||
ocfs2_hb_ctl (distributed with ocfs2-tools). Right now it requires
|
ocfs2_hb_ctl (distributed with ocfs2-tools). Right now it requires
|
||||||
that an OCFS2 file system be in place so that it can automatically
|
that an OCFS2 file system be in place so that it can automatically
|
||||||
find it's heartbeat area, though it will eventually support heartbeat
|
find its heartbeat area, though it will eventually support heartbeat
|
||||||
against raw disks.
|
against raw disks.
|
||||||
|
|
||||||
Please see the ocfs2_hb_ctl and mkfs.ocfs2 manual pages distributed
|
Please see the ocfs2_hb_ctl and mkfs.ocfs2 manual pages distributed
|
||||||
|
@ -38,7 +38,7 @@ flags, it will return EBADR and the contents of fm_flags will contain
|
|||||||
the set of flags which caused the error. If the kernel is compatible
|
the set of flags which caused the error. If the kernel is compatible
|
||||||
with all flags passed, the contents of fm_flags will be unmodified.
|
with all flags passed, the contents of fm_flags will be unmodified.
|
||||||
It is up to userspace to determine whether rejection of a particular
|
It is up to userspace to determine whether rejection of a particular
|
||||||
flag is fatal to it's operation. This scheme is intended to allow the
|
flag is fatal to its operation. This scheme is intended to allow the
|
||||||
fiemap interface to grow in the future but without losing
|
fiemap interface to grow in the future but without losing
|
||||||
compatibility with old software.
|
compatibility with old software.
|
||||||
|
|
||||||
@ -56,7 +56,7 @@ If this flag is set, the kernel will sync the file before mapping extents.
|
|||||||
|
|
||||||
* FIEMAP_FLAG_XATTR
|
* FIEMAP_FLAG_XATTR
|
||||||
If this flag is set, the extents returned will describe the inodes
|
If this flag is set, the extents returned will describe the inodes
|
||||||
extended attribute lookup tree, instead of it's data tree.
|
extended attribute lookup tree, instead of its data tree.
|
||||||
|
|
||||||
|
|
||||||
Extent Mapping
|
Extent Mapping
|
||||||
@ -89,7 +89,7 @@ struct fiemap_extent {
|
|||||||
};
|
};
|
||||||
|
|
||||||
All offsets and lengths are in bytes and mirror those on disk. It is valid
|
All offsets and lengths are in bytes and mirror those on disk. It is valid
|
||||||
for an extents logical offset to start before the request or it's logical
|
for an extents logical offset to start before the request or its logical
|
||||||
length to extend past the request. Unless FIEMAP_EXTENT_NOT_ALIGNED is
|
length to extend past the request. Unless FIEMAP_EXTENT_NOT_ALIGNED is
|
||||||
returned, fe_logical, fe_physical, and fe_length will be aligned to the
|
returned, fe_logical, fe_physical, and fe_length will be aligned to the
|
||||||
block size of the file system. With the exception of extents flagged as
|
block size of the file system. With the exception of extents flagged as
|
||||||
@ -125,7 +125,7 @@ been allocated for the file yet.
|
|||||||
|
|
||||||
* FIEMAP_EXTENT_DELALLOC
|
* FIEMAP_EXTENT_DELALLOC
|
||||||
- This will also set FIEMAP_EXTENT_UNKNOWN.
|
- This will also set FIEMAP_EXTENT_UNKNOWN.
|
||||||
Delayed allocation - while there is data for this extent, it's
|
Delayed allocation - while there is data for this extent, its
|
||||||
physical location has not been allocated yet.
|
physical location has not been allocated yet.
|
||||||
|
|
||||||
* FIEMAP_EXTENT_ENCODED
|
* FIEMAP_EXTENT_ENCODED
|
||||||
@ -159,7 +159,7 @@ Data is located within a meta data block.
|
|||||||
Data is packed into a block with data from other files.
|
Data is packed into a block with data from other files.
|
||||||
|
|
||||||
* FIEMAP_EXTENT_UNWRITTEN
|
* FIEMAP_EXTENT_UNWRITTEN
|
||||||
Unwritten extent - the extent is allocated but it's data has not been
|
Unwritten extent - the extent is allocated but its data has not been
|
||||||
initialized. This indicates the extent's data will be all zero if read
|
initialized. This indicates the extent's data will be all zero if read
|
||||||
through the filesystem but the contents are undefined if read directly from
|
through the filesystem but the contents are undefined if read directly from
|
||||||
the device.
|
the device.
|
||||||
@ -176,7 +176,7 @@ VFS -> File System Implementation
|
|||||||
|
|
||||||
File systems wishing to support fiemap must implement a ->fiemap callback on
|
File systems wishing to support fiemap must implement a ->fiemap callback on
|
||||||
their inode_operations structure. The fs ->fiemap call is responsible for
|
their inode_operations structure. The fs ->fiemap call is responsible for
|
||||||
defining it's set of supported fiemap flags, and calling a helper function on
|
defining its set of supported fiemap flags, and calling a helper function on
|
||||||
each discovered extent:
|
each discovered extent:
|
||||||
|
|
||||||
struct inode_operations {
|
struct inode_operations {
|
||||||
|
@ -91,7 +91,7 @@ Mount options
|
|||||||
'default_permissions'
|
'default_permissions'
|
||||||
|
|
||||||
By default FUSE doesn't check file access permissions, the
|
By default FUSE doesn't check file access permissions, the
|
||||||
filesystem is free to implement it's access policy or leave it to
|
filesystem is free to implement its access policy or leave it to
|
||||||
the underlying file access mechanism (e.g. in case of network
|
the underlying file access mechanism (e.g. in case of network
|
||||||
filesystems). This option enables permission checking, restricting
|
filesystems). This option enables permission checking, restricting
|
||||||
access based on file mode. It is usually useful together with the
|
access based on file mode. It is usually useful together with the
|
||||||
@ -171,7 +171,7 @@ or may honor them by sending a reply to the _original_ request, with
|
|||||||
the error set to EINTR.
|
the error set to EINTR.
|
||||||
|
|
||||||
It is also possible that there's a race between processing the
|
It is also possible that there's a race between processing the
|
||||||
original request and it's INTERRUPT request. There are two possibilities:
|
original request and its INTERRUPT request. There are two possibilities:
|
||||||
|
|
||||||
1) The INTERRUPT request is processed before the original request is
|
1) The INTERRUPT request is processed before the original request is
|
||||||
processed
|
processed
|
||||||
|
@ -103,7 +103,7 @@ to analyze or change OS2SYS.INI.
|
|||||||
Codepages
|
Codepages
|
||||||
|
|
||||||
HPFS can contain several uppercasing tables for several codepages and each
|
HPFS can contain several uppercasing tables for several codepages and each
|
||||||
file has a pointer to codepage it's name is in. However OS/2 was created in
|
file has a pointer to codepage its name is in. However OS/2 was created in
|
||||||
America where people don't care much about codepages and so multiple codepages
|
America where people don't care much about codepages and so multiple codepages
|
||||||
support is quite buggy. I have Czech OS/2 working in codepage 852 on my disk.
|
support is quite buggy. I have Czech OS/2 working in codepage 852 on my disk.
|
||||||
Once I booted English OS/2 working in cp 850 and I created a file on my 852
|
Once I booted English OS/2 working in cp 850 and I created a file on my 852
|
||||||
|
@ -185,7 +185,7 @@ failed lookup meant a definite 'no'.
|
|||||||
request/response format
|
request/response format
|
||||||
-----------------------
|
-----------------------
|
||||||
|
|
||||||
While each cache is free to use it's own format for requests
|
While each cache is free to use its own format for requests
|
||||||
and responses over channel, the following is recommended as
|
and responses over channel, the following is recommended as
|
||||||
appropriate and support routines are available to help:
|
appropriate and support routines are available to help:
|
||||||
Each request or response record should be printable ASCII
|
Each request or response record should be printable ASCII
|
||||||
|
@ -965,7 +965,7 @@ your system and how much traffic was routed over those devices:
|
|||||||
...] 1375103 17405 0 0 0 0 0 0
|
...] 1375103 17405 0 0 0 0 0 0
|
||||||
...] 1703981 5535 0 0 0 3 0 0
|
...] 1703981 5535 0 0 0 3 0 0
|
||||||
|
|
||||||
In addition, each Channel Bond interface has it's own directory. For
|
In addition, each Channel Bond interface has its own directory. For
|
||||||
example, the bond0 device will have a directory called /proc/net/bond0/.
|
example, the bond0 device will have a directory called /proc/net/bond0/.
|
||||||
It will contain information that is specific to that bond, such as the
|
It will contain information that is specific to that bond, such as the
|
||||||
current slaves of the bond, the link status of the slaves, and how
|
current slaves of the bond, the link status of the slaves, and how
|
||||||
@ -1362,7 +1362,7 @@ been accounted as having caused 1MB of write.
|
|||||||
In other words: The number of bytes which this process caused to not happen,
|
In other words: The number of bytes which this process caused to not happen,
|
||||||
by truncating pagecache. A task can cause "negative" IO too. If this task
|
by truncating pagecache. A task can cause "negative" IO too. If this task
|
||||||
truncates some dirty pagecache, some IO which another task has been accounted
|
truncates some dirty pagecache, some IO which another task has been accounted
|
||||||
for (in it's write_bytes) will not be happening. We _could_ just subtract that
|
for (in its write_bytes) will not be happening. We _could_ just subtract that
|
||||||
from the truncating task's write_bytes, but there is information loss in doing
|
from the truncating task's write_bytes, but there is information loss in doing
|
||||||
that.
|
that.
|
||||||
|
|
||||||
|
@ -3,6 +3,6 @@ protocol used by Windows for Workgroups, Windows 95 and Windows NT.
|
|||||||
Smbfs was inspired by Samba, the program written by Andrew Tridgell
|
Smbfs was inspired by Samba, the program written by Andrew Tridgell
|
||||||
that turns any Unix host into a file server for DOS or Windows clients.
|
that turns any Unix host into a file server for DOS or Windows clients.
|
||||||
|
|
||||||
Smbfs is a SMB client, but uses parts of samba for it's operation. For
|
Smbfs is a SMB client, but uses parts of samba for its operation. For
|
||||||
more info on samba, including documentation, please go to
|
more info on samba, including documentation, please go to
|
||||||
http://www.samba.org/ and then on to your nearest mirror.
|
http://www.samba.org/ and then on to your nearest mirror.
|
||||||
|
@ -72,7 +72,7 @@ structure (this is the kernel-side implementation of file
|
|||||||
descriptors). The freshly allocated file structure is initialized with
|
descriptors). The freshly allocated file structure is initialized with
|
||||||
a pointer to the dentry and a set of file operation member functions.
|
a pointer to the dentry and a set of file operation member functions.
|
||||||
These are taken from the inode data. The open() file method is then
|
These are taken from the inode data. The open() file method is then
|
||||||
called so the specific filesystem implementation can do it's work. You
|
called so the specific filesystem implementation can do its work. You
|
||||||
can see that this is another switch performed by the VFS. The file
|
can see that this is another switch performed by the VFS. The file
|
||||||
structure is placed into the file descriptor table for the process.
|
structure is placed into the file descriptor table for the process.
|
||||||
|
|
||||||
|
@ -157,7 +157,7 @@ temperature configuration points:
|
|||||||
|
|
||||||
There are three PWM outputs. The LM85 datasheet suggests that the
|
There are three PWM outputs. The LM85 datasheet suggests that the
|
||||||
pwm3 output control both fan3 and fan4. Each PWM can be individually
|
pwm3 output control both fan3 and fan4. Each PWM can be individually
|
||||||
configured and assigned to a zone for it's control value. Each PWM can be
|
configured and assigned to a zone for its control value. Each PWM can be
|
||||||
configured individually according to the following options.
|
configured individually according to the following options.
|
||||||
|
|
||||||
* pwm#_auto_pwm_min - this specifies the PWM value for temp#_auto_temp_off
|
* pwm#_auto_pwm_min - this specifies the PWM value for temp#_auto_temp_off
|
||||||
|
@ -402,7 +402,7 @@ for the port of the SoundFusion is supported by the cs461x.c module.
|
|||||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
The Live! has a special PCI gameport, which, although it doesn't provide
|
The Live! has a special PCI gameport, which, although it doesn't provide
|
||||||
any "Enhanced" stuff like 4DWave and friends, is quite a bit faster than
|
any "Enhanced" stuff like 4DWave and friends, is quite a bit faster than
|
||||||
it's ISA counterparts. It also requires special support, hence the
|
its ISA counterparts. It also requires special support, hence the
|
||||||
emu10k1-gp.c module for it instead of the normal ns558.c one.
|
emu10k1-gp.c module for it instead of the normal ns558.c one.
|
||||||
|
|
||||||
3.15 SoundBlaster 64 and 128 - ES1370 and ES1371, ESS Solo1 and S3 SonicVibes
|
3.15 SoundBlaster 64 and 128 - ES1370 and ES1371, ESS Solo1 and S3 SonicVibes
|
||||||
|
@ -126,7 +126,7 @@ o Tboot then applies an (optional) user-defined launch policy to
|
|||||||
o Tboot adjusts the e820 table provided by the bootloader to reserve
|
o Tboot adjusts the e820 table provided by the bootloader to reserve
|
||||||
its own location in memory as well as to reserve certain other
|
its own location in memory as well as to reserve certain other
|
||||||
TXT-related regions.
|
TXT-related regions.
|
||||||
o As part of it's launch, tboot DMA protects all of RAM (using the
|
o As part of its launch, tboot DMA protects all of RAM (using the
|
||||||
VT-d PMRs). Thus, the kernel must be booted with 'intel_iommu=on'
|
VT-d PMRs). Thus, the kernel must be booted with 'intel_iommu=on'
|
||||||
in order to remove this blanket protection and use VT-d's
|
in order to remove this blanket protection and use VT-d's
|
||||||
page-level protection.
|
page-level protection.
|
||||||
|
@ -181,7 +181,7 @@ Expressions are listed in decreasing order of precedence.
|
|||||||
(7) Returns the result of max(/expr/, /expr/).
|
(7) Returns the result of max(/expr/, /expr/).
|
||||||
|
|
||||||
An expression can have a value of 'n', 'm' or 'y' (or 0, 1, 2
|
An expression can have a value of 'n', 'm' or 'y' (or 0, 1, 2
|
||||||
respectively for calculations). A menu entry becomes visible when it's
|
respectively for calculations). A menu entry becomes visible when its
|
||||||
expression evaluates to 'm' or 'y'.
|
expression evaluates to 'm' or 'y'.
|
||||||
|
|
||||||
There are two types of symbols: constant and non-constant symbols.
|
There are two types of symbols: constant and non-constant symbols.
|
||||||
|
@ -116,7 +116,7 @@
|
|||||||
Author: Ingo Molnar, Gadi Oxman and Miguel de Icaza.
|
Author: Ingo Molnar, Gadi Oxman and Miguel de Icaza.
|
||||||
URL: http://www.linuxjournal.com/article.php?sid=2391
|
URL: http://www.linuxjournal.com/article.php?sid=2391
|
||||||
Keywords: RAID, MD driver.
|
Keywords: RAID, MD driver.
|
||||||
Description: Linux Journal Kernel Korner article. Here is it's
|
Description: Linux Journal Kernel Korner article. Here is its
|
||||||
abstract: "A description of the implementation of the RAID-1,
|
abstract: "A description of the implementation of the RAID-1,
|
||||||
RAID-4 and RAID-5 personalities of the MD device driver in the
|
RAID-4 and RAID-5 personalities of the MD device driver in the
|
||||||
Linux kernel, providing users with high performance and reliable,
|
Linux kernel, providing users with high performance and reliable,
|
||||||
@ -127,7 +127,7 @@
|
|||||||
URL: http://www.linuxjournal.com/article.php?sid=1219
|
URL: http://www.linuxjournal.com/article.php?sid=1219
|
||||||
Keywords: device driver, module, loading/unloading modules,
|
Keywords: device driver, module, loading/unloading modules,
|
||||||
allocating resources.
|
allocating resources.
|
||||||
Description: Linux Journal Kernel Korner article. Here is it's
|
Description: Linux Journal Kernel Korner article. Here is its
|
||||||
abstract: "This is the first of a series of four articles
|
abstract: "This is the first of a series of four articles
|
||||||
co-authored by Alessandro Rubini and Georg Zezchwitz which present
|
co-authored by Alessandro Rubini and Georg Zezchwitz which present
|
||||||
a practical approach to writing Linux device drivers as kernel
|
a practical approach to writing Linux device drivers as kernel
|
||||||
@ -141,7 +141,7 @@
|
|||||||
Keywords: character driver, init_module, clean_up module,
|
Keywords: character driver, init_module, clean_up module,
|
||||||
autodetection, mayor number, minor number, file operations,
|
autodetection, mayor number, minor number, file operations,
|
||||||
open(), close().
|
open(), close().
|
||||||
Description: Linux Journal Kernel Korner article. Here is it's
|
Description: Linux Journal Kernel Korner article. Here is its
|
||||||
abstract: "This article, the second of four, introduces part of
|
abstract: "This article, the second of four, introduces part of
|
||||||
the actual code to create custom module implementing a character
|
the actual code to create custom module implementing a character
|
||||||
device driver. It describes the code for module initialization and
|
device driver. It describes the code for module initialization and
|
||||||
@ -152,7 +152,7 @@
|
|||||||
URL: http://www.linuxjournal.com/article.php?sid=1221
|
URL: http://www.linuxjournal.com/article.php?sid=1221
|
||||||
Keywords: read(), write(), select(), ioctl(), blocking/non
|
Keywords: read(), write(), select(), ioctl(), blocking/non
|
||||||
blocking mode, interrupt handler.
|
blocking mode, interrupt handler.
|
||||||
Description: Linux Journal Kernel Korner article. Here is it's
|
Description: Linux Journal Kernel Korner article. Here is its
|
||||||
abstract: "This article, the third of four on writing character
|
abstract: "This article, the third of four on writing character
|
||||||
device drivers, introduces concepts of reading, writing, and using
|
device drivers, introduces concepts of reading, writing, and using
|
||||||
ioctl-calls".
|
ioctl-calls".
|
||||||
@ -161,7 +161,7 @@
|
|||||||
Author: Alessandro Rubini and Georg v. Zezschwitz.
|
Author: Alessandro Rubini and Georg v. Zezschwitz.
|
||||||
URL: http://www.linuxjournal.com/article.php?sid=1222
|
URL: http://www.linuxjournal.com/article.php?sid=1222
|
||||||
Keywords: interrupts, irqs, DMA, bottom halves, task queues.
|
Keywords: interrupts, irqs, DMA, bottom halves, task queues.
|
||||||
Description: Linux Journal Kernel Korner article. Here is it's
|
Description: Linux Journal Kernel Korner article. Here is its
|
||||||
abstract: "This is the fourth in a series of articles about
|
abstract: "This is the fourth in a series of articles about
|
||||||
writing character device drivers as loadable kernel modules. This
|
writing character device drivers as loadable kernel modules. This
|
||||||
month, we further investigate the field of interrupt handling.
|
month, we further investigate the field of interrupt handling.
|
||||||
|
@ -332,7 +332,7 @@ occurs during execution of kp->pre_handler or kp->post_handler,
|
|||||||
or during single-stepping of the probed instruction, Kprobes calls
|
or during single-stepping of the probed instruction, Kprobes calls
|
||||||
kp->fault_handler. Any or all handlers can be NULL. If kp->flags
|
kp->fault_handler. Any or all handlers can be NULL. If kp->flags
|
||||||
is set KPROBE_FLAG_DISABLED, that kp will be registered but disabled,
|
is set KPROBE_FLAG_DISABLED, that kp will be registered but disabled,
|
||||||
so, it's handlers aren't hit until calling enable_kprobe(kp).
|
so, its handlers aren't hit until calling enable_kprobe(kp).
|
||||||
|
|
||||||
NOTE:
|
NOTE:
|
||||||
1. With the introduction of the "symbol_name" field to struct kprobe,
|
1. With the introduction of the "symbol_name" field to struct kprobe,
|
||||||
|
@ -207,7 +207,7 @@ Tips & Tricks
|
|||||||
* Drew Scott Daniels observed: "I don't know why, but when I decrease the number
|
* Drew Scott Daniels observed: "I don't know why, but when I decrease the number
|
||||||
of colours that my display uses it consumes less battery power. I've seen
|
of colours that my display uses it consumes less battery power. I've seen
|
||||||
this on powerbooks too. I hope that this is a piece of information that
|
this on powerbooks too. I hope that this is a piece of information that
|
||||||
might be useful to the Laptop Mode patch or it's users."
|
might be useful to the Laptop Mode patch or its users."
|
||||||
|
|
||||||
* In syslog.conf, you can prefix entries with a dash ``-'' to omit syncing the
|
* In syslog.conf, you can prefix entries with a dash ``-'' to omit syncing the
|
||||||
file after every logging. When you're using laptop-mode and your disk doesn't
|
file after every logging. When you're using laptop-mode and your disk doesn't
|
||||||
|
@ -263,7 +263,7 @@ static u8 *get_feature_bits(struct device *dev)
|
|||||||
* Launcher virtual with an offset.
|
* Launcher virtual with an offset.
|
||||||
*
|
*
|
||||||
* This can be tough to get your head around, but usually it just means that we
|
* This can be tough to get your head around, but usually it just means that we
|
||||||
* use these trivial conversion functions when the Guest gives us it's
|
* use these trivial conversion functions when the Guest gives us its
|
||||||
* "physical" addresses:
|
* "physical" addresses:
|
||||||
*/
|
*/
|
||||||
static void *from_guest_phys(unsigned long addr)
|
static void *from_guest_phys(unsigned long addr)
|
||||||
|
@ -136,7 +136,7 @@ raid_disks != 0.
|
|||||||
|
|
||||||
Then uninitialized devices can be added with ADD_NEW_DISK. The
|
Then uninitialized devices can be added with ADD_NEW_DISK. The
|
||||||
structure passed to ADD_NEW_DISK must specify the state of the device
|
structure passed to ADD_NEW_DISK must specify the state of the device
|
||||||
and it's role in the array.
|
and its role in the array.
|
||||||
|
|
||||||
Once started with RUN_ARRAY, uninitialized spares can be added with
|
Once started with RUN_ARRAY, uninitialized spares can be added with
|
||||||
HOT_ADD_DISK.
|
HOT_ADD_DISK.
|
||||||
|
@ -38,7 +38,7 @@ Depending on the exact configuration, translation between the network packet
|
|||||||
label and the internal LSM security identifier can be time consuming. The
|
label and the internal LSM security identifier can be time consuming. The
|
||||||
NetLabel label mapping cache is a caching mechanism which can be used to
|
NetLabel label mapping cache is a caching mechanism which can be used to
|
||||||
sidestep much of this overhead once a mapping has been established. Once the
|
sidestep much of this overhead once a mapping has been established. Once the
|
||||||
LSM has received a packet, used NetLabel to decode it's security attributes,
|
LSM has received a packet, used NetLabel to decode its security attributes,
|
||||||
and translated the security attributes into a LSM internal identifier the LSM
|
and translated the security attributes into a LSM internal identifier the LSM
|
||||||
can use the NetLabel caching functions to associate the LSM internal
|
can use the NetLabel caching functions to associate the LSM internal
|
||||||
identifier with the network packet's label. This means that in the future
|
identifier with the network packet's label. This means that in the future
|
||||||
|
@ -756,7 +756,7 @@ static int enslave(char *master_ifname, char *slave_ifname)
|
|||||||
*/
|
*/
|
||||||
if (abi_ver < 1) {
|
if (abi_ver < 1) {
|
||||||
/* For old ABI, the master needs to be
|
/* For old ABI, the master needs to be
|
||||||
* down before setting it's hwaddr
|
* down before setting its hwaddr
|
||||||
*/
|
*/
|
||||||
res = set_if_down(master_ifname, master_flags.ifr_flags);
|
res = set_if_down(master_ifname, master_flags.ifr_flags);
|
||||||
if (res) {
|
if (res) {
|
||||||
|
@ -100,7 +100,7 @@ by the kernel.
|
|||||||
The destruction of the socket and all associated resources
|
The destruction of the socket and all associated resources
|
||||||
is done by a simple call to close(fd).
|
is done by a simple call to close(fd).
|
||||||
|
|
||||||
Next I will describe PACKET_MMAP settings and it's constraints,
|
Next I will describe PACKET_MMAP settings and its constraints,
|
||||||
also the mapping of the circular buffer in the user process and
|
also the mapping of the circular buffer in the user process and
|
||||||
the use of this buffer.
|
the use of this buffer.
|
||||||
|
|
||||||
@ -432,7 +432,7 @@ TP_STATUS_LOSING : indicates there were packet drops from last time
|
|||||||
the PACKET_STATISTICS option.
|
the PACKET_STATISTICS option.
|
||||||
|
|
||||||
TP_STATUS_CSUMNOTREADY: currently it's used for outgoing IP packets which
|
TP_STATUS_CSUMNOTREADY: currently it's used for outgoing IP packets which
|
||||||
it's checksum will be done in hardware. So while
|
its checksum will be done in hardware. So while
|
||||||
reading the packet we should not try to check the
|
reading the packet we should not try to check the
|
||||||
checksum.
|
checksum.
|
||||||
|
|
||||||
|
@ -8,11 +8,11 @@ Please see overview.txt for a description of the terms used in this text.
|
|||||||
1. Consumer Regulator Access (static & dynamic drivers)
|
1. Consumer Regulator Access (static & dynamic drivers)
|
||||||
=======================================================
|
=======================================================
|
||||||
|
|
||||||
A consumer driver can get access to it's supply regulator by calling :-
|
A consumer driver can get access to its supply regulator by calling :-
|
||||||
|
|
||||||
regulator = regulator_get(dev, "Vcc");
|
regulator = regulator_get(dev, "Vcc");
|
||||||
|
|
||||||
The consumer passes in it's struct device pointer and power supply ID. The core
|
The consumer passes in its struct device pointer and power supply ID. The core
|
||||||
then finds the correct regulator by consulting a machine specific lookup table.
|
then finds the correct regulator by consulting a machine specific lookup table.
|
||||||
If the lookup is successful then this call will return a pointer to the struct
|
If the lookup is successful then this call will return a pointer to the struct
|
||||||
regulator that supplies this consumer.
|
regulator that supplies this consumer.
|
||||||
@ -34,7 +34,7 @@ usually be called in your device drivers probe() and remove() respectively.
|
|||||||
2. Regulator Output Enable & Disable (static & dynamic drivers)
|
2. Regulator Output Enable & Disable (static & dynamic drivers)
|
||||||
====================================================================
|
====================================================================
|
||||||
|
|
||||||
A consumer can enable it's power supply by calling:-
|
A consumer can enable its power supply by calling:-
|
||||||
|
|
||||||
int regulator_enable(regulator);
|
int regulator_enable(regulator);
|
||||||
|
|
||||||
@ -49,7 +49,7 @@ int regulator_is_enabled(regulator);
|
|||||||
This will return > zero when the regulator is enabled.
|
This will return > zero when the regulator is enabled.
|
||||||
|
|
||||||
|
|
||||||
A consumer can disable it's supply when no longer needed by calling :-
|
A consumer can disable its supply when no longer needed by calling :-
|
||||||
|
|
||||||
int regulator_disable(regulator);
|
int regulator_disable(regulator);
|
||||||
|
|
||||||
@ -140,7 +140,7 @@ by calling :-
|
|||||||
int regulator_set_optimum_mode(struct regulator *regulator, int load_uA);
|
int regulator_set_optimum_mode(struct regulator *regulator, int load_uA);
|
||||||
|
|
||||||
This will cause the core to recalculate the total load on the regulator (based
|
This will cause the core to recalculate the total load on the regulator (based
|
||||||
on all it's consumers) and change operating mode (if necessary and permitted)
|
on all its consumers) and change operating mode (if necessary and permitted)
|
||||||
to best match the current operating load.
|
to best match the current operating load.
|
||||||
|
|
||||||
The load_uA value can be determined from the consumers datasheet. e.g.most
|
The load_uA value can be determined from the consumers datasheet. e.g.most
|
||||||
|
@ -52,7 +52,7 @@ static struct regulator_init_data regulator1_data = {
|
|||||||
};
|
};
|
||||||
|
|
||||||
Regulator-1 supplies power to Regulator-2. This relationship must be registered
|
Regulator-1 supplies power to Regulator-2. This relationship must be registered
|
||||||
with the core so that Regulator-1 is also enabled when Consumer A enables it's
|
with the core so that Regulator-1 is also enabled when Consumer A enables its
|
||||||
supply (Regulator-2). The supply regulator is set by the supply_regulator_dev
|
supply (Regulator-2). The supply regulator is set by the supply_regulator_dev
|
||||||
field below:-
|
field below:-
|
||||||
|
|
||||||
|
@ -35,16 +35,16 @@ Some terms used in this document:-
|
|||||||
o Consumer - Electronic device that is supplied power by a regulator.
|
o Consumer - Electronic device that is supplied power by a regulator.
|
||||||
Consumers can be classified into two types:-
|
Consumers can be classified into two types:-
|
||||||
|
|
||||||
Static: consumer does not change it's supply voltage or
|
Static: consumer does not change its supply voltage or
|
||||||
current limit. It only needs to enable or disable it's
|
current limit. It only needs to enable or disable it's
|
||||||
power supply. It's supply voltage is set by the hardware,
|
power supply. Its supply voltage is set by the hardware,
|
||||||
bootloader, firmware or kernel board initialisation code.
|
bootloader, firmware or kernel board initialisation code.
|
||||||
|
|
||||||
Dynamic: consumer needs to change it's supply voltage or
|
Dynamic: consumer needs to change it's supply voltage or
|
||||||
current limit to meet operation demands.
|
current limit to meet operation demands.
|
||||||
|
|
||||||
|
|
||||||
o Power Domain - Electronic circuit that is supplied it's input power by the
|
o Power Domain - Electronic circuit that is supplied its input power by the
|
||||||
output power of a regulator, switch or by another power
|
output power of a regulator, switch or by another power
|
||||||
domain.
|
domain.
|
||||||
|
|
||||||
|
@ -1289,7 +1289,7 @@ link between a device node and its interrupt parent in
|
|||||||
the interrupt tree. The value of interrupt-parent is the
|
the interrupt tree. The value of interrupt-parent is the
|
||||||
phandle of the parent node.
|
phandle of the parent node.
|
||||||
|
|
||||||
If the interrupt-parent property is not defined for a node, it's
|
If the interrupt-parent property is not defined for a node, its
|
||||||
interrupt parent is assumed to be an ancestor in the node's
|
interrupt parent is assumed to be an ancestor in the node's
|
||||||
_device tree_ hierarchy.
|
_device tree_ hierarchy.
|
||||||
|
|
||||||
|
@ -19,7 +19,7 @@ dump offers several strong, practical advantages:
|
|||||||
immediately available to the system for normal use.
|
immediately available to the system for normal use.
|
||||||
-- After the dump is completed, no further reboots are
|
-- After the dump is completed, no further reboots are
|
||||||
required; the system will be fully usable, and running
|
required; the system will be fully usable, and running
|
||||||
in it's normal, production mode on it normal kernel.
|
in its normal, production mode on its normal kernel.
|
||||||
|
|
||||||
The above can only be accomplished by coordination with,
|
The above can only be accomplished by coordination with,
|
||||||
and assistance from the hypervisor. The procedure is
|
and assistance from the hypervisor. The procedure is
|
||||||
|
@ -657,7 +657,7 @@ here.
|
|||||||
|
|
||||||
The waiter structure has a "task" field that points to the task that is blocked
|
The waiter structure has a "task" field that points to the task that is blocked
|
||||||
on the mutex. This field can be NULL the first time it goes through the loop
|
on the mutex. This field can be NULL the first time it goes through the loop
|
||||||
or if the task is a pending owner and had it's mutex stolen. If the "task"
|
or if the task is a pending owner and had its mutex stolen. If the "task"
|
||||||
field is NULL then we need to set up the accounting for it.
|
field is NULL then we need to set up the accounting for it.
|
||||||
|
|
||||||
Task blocks on mutex
|
Task blocks on mutex
|
||||||
|
@ -707,7 +707,7 @@ Changes from 20040920 to 20041018
|
|||||||
* Integrate patches from Christoph Hellwig: two new helpers common
|
* Integrate patches from Christoph Hellwig: two new helpers common
|
||||||
to lpfc_sli_resume_iocb and lpfc_sli_issue_iocb - singificant
|
to lpfc_sli_resume_iocb and lpfc_sli_issue_iocb - singificant
|
||||||
cleanup of those two functions - the unused SLI_IOCB_USE_TXQ is
|
cleanup of those two functions - the unused SLI_IOCB_USE_TXQ is
|
||||||
gone - lpfc_sli_issue_iocb_wait loses it's flags argument
|
gone - lpfc_sli_issue_iocb_wait loses its flags argument
|
||||||
totally.
|
totally.
|
||||||
* Fix in lpfc_sli.c: we can not store a 5 bit value in a 4-bit
|
* Fix in lpfc_sli.c: we can not store a 5 bit value in a 4-bit
|
||||||
field.
|
field.
|
||||||
@ -1028,7 +1028,7 @@ Changes from 20040614 to 20040709
|
|||||||
* Remove the need for buf_tmo.
|
* Remove the need for buf_tmo.
|
||||||
* Changed ULP_BDE64 to struct ulp_bde64.
|
* Changed ULP_BDE64 to struct ulp_bde64.
|
||||||
* Changed ULP_BDE to struct ulp_bde.
|
* Changed ULP_BDE to struct ulp_bde.
|
||||||
* Cleanup lpfc_os_return_scsi_cmd() and it's call path.
|
* Cleanup lpfc_os_return_scsi_cmd() and its call path.
|
||||||
* Removed lpfc_no_device_delay.
|
* Removed lpfc_no_device_delay.
|
||||||
* Consolidating lpfc_hba_put_event() into lpfc_put_event().
|
* Consolidating lpfc_hba_put_event() into lpfc_put_event().
|
||||||
* Removed following attributes and their functionality:
|
* Removed following attributes and their functionality:
|
||||||
|
@ -71,7 +71,7 @@ peters@mylex.com
|
|||||||
|
|
||||||
Ever since its introduction last October, the BusLogic FlashPoint LT has
|
Ever since its introduction last October, the BusLogic FlashPoint LT has
|
||||||
been problematic for members of the Linux community, in that no Linux
|
been problematic for members of the Linux community, in that no Linux
|
||||||
drivers have been available for this new Ultra SCSI product. Despite it's
|
drivers have been available for this new Ultra SCSI product. Despite its
|
||||||
officially being positioned as a desktop workstation product, and not being
|
officially being positioned as a desktop workstation product, and not being
|
||||||
particularly well suited for a high performance multitasking operating
|
particularly well suited for a high performance multitasking operating
|
||||||
system like Linux, the FlashPoint LT has been touted by computer system
|
system like Linux, the FlashPoint LT has been touted by computer system
|
||||||
|
@ -12,7 +12,7 @@ The 3180 does not. Otherwise, they are identical.
|
|||||||
The DTC3x80 does not support DMA but it does have Pseudo-DMA which is
|
The DTC3x80 does not support DMA but it does have Pseudo-DMA which is
|
||||||
supported by the driver.
|
supported by the driver.
|
||||||
|
|
||||||
It's DTC406 scsi chip is supposedly compatible with the NCR 53C400.
|
Its DTC406 scsi chip is supposedly compatible with the NCR 53C400.
|
||||||
It is memory mapped, uses an IRQ, but no dma or io-port. There is
|
It is memory mapped, uses an IRQ, but no dma or io-port. There is
|
||||||
internal DMA, between SCSI bus and an on-chip 128-byte buffer. Double
|
internal DMA, between SCSI bus and an on-chip 128-byte buffer. Double
|
||||||
buffering is done automagically by the chip. Data is transferred
|
buffering is done automagically by the chip. Data is transferred
|
||||||
|
@ -1479,7 +1479,7 @@ Wide16 SCSI.
|
|||||||
Enabling serial NVRAM support enables detection of the serial NVRAM included
|
Enabling serial NVRAM support enables detection of the serial NVRAM included
|
||||||
on Symbios and some Symbios compatible host adaptors, and Tekram boards. The
|
on Symbios and some Symbios compatible host adaptors, and Tekram boards. The
|
||||||
serial NVRAM is used by Symbios and Tekram to hold set up parameters for the
|
serial NVRAM is used by Symbios and Tekram to hold set up parameters for the
|
||||||
host adaptor and it's attached drives.
|
host adaptor and its attached drives.
|
||||||
|
|
||||||
The Symbios NVRAM also holds data on the boot order of host adaptors in a
|
The Symbios NVRAM also holds data on the boot order of host adaptors in a
|
||||||
system with more than one host adaptor. This enables the order of scanning
|
system with more than one host adaptor. This enables the order of scanning
|
||||||
|
@ -40,7 +40,7 @@ behavior looks very much the same as st to the userspace applications.
|
|||||||
|
|
||||||
History
|
History
|
||||||
-------
|
-------
|
||||||
In the first place, osst shared it's identity very much with st. That meant
|
In the first place, osst shared its identity very much with st. That meant
|
||||||
that it used the same kernel structures and the same device node as st.
|
that it used the same kernel structures and the same device node as st.
|
||||||
So you could only have either of them being present in the kernel. This has
|
So you could only have either of them being present in the kernel. This has
|
||||||
been fixed by registering an own device, now.
|
been fixed by registering an own device, now.
|
||||||
|
@ -70,7 +70,7 @@ Overview:
|
|||||||
up to an administrative entity controlling the vport. For example,
|
up to an administrative entity controlling the vport. For example,
|
||||||
if vports are to be associated with virtual machines, a XEN mgmt
|
if vports are to be associated with virtual machines, a XEN mgmt
|
||||||
utility would be responsible for creating wwpn/wwnn's for the vport,
|
utility would be responsible for creating wwpn/wwnn's for the vport,
|
||||||
using it's own naming authority and OUI. (Note: it already does this
|
using its own naming authority and OUI. (Note: it already does this
|
||||||
for virtual MAC addresses).
|
for virtual MAC addresses).
|
||||||
|
|
||||||
|
|
||||||
@ -81,7 +81,7 @@ Device Trees and Vport Objects:
|
|||||||
with rports and scsi target objects underneath it. Currently the FC
|
with rports and scsi target objects underneath it. Currently the FC
|
||||||
transport creates the vport object and places it under the scsi_host
|
transport creates the vport object and places it under the scsi_host
|
||||||
object corresponding to the physical adapter. The LLDD will allocate
|
object corresponding to the physical adapter. The LLDD will allocate
|
||||||
a new scsi_host for the vport and link it's object under the vport.
|
a new scsi_host for the vport and link its object under the vport.
|
||||||
The remainder of the tree under the vports scsi_host is the same
|
The remainder of the tree under the vports scsi_host is the same
|
||||||
as the non-NPIV case. The transport is written currently to easily
|
as the non-NPIV case. The transport is written currently to easily
|
||||||
allow the parent of the vport to be something other than the scsi_host.
|
allow the parent of the vport to be something other than the scsi_host.
|
||||||
|
@ -687,7 +687,7 @@ maintain the driver code.
|
|||||||
Enabling serial NVRAM support enables detection of the serial NVRAM included
|
Enabling serial NVRAM support enables detection of the serial NVRAM included
|
||||||
on Symbios and some Symbios compatible host adaptors, and Tekram boards. The
|
on Symbios and some Symbios compatible host adaptors, and Tekram boards. The
|
||||||
serial NVRAM is used by Symbios and Tekram to hold set up parameters for the
|
serial NVRAM is used by Symbios and Tekram to hold set up parameters for the
|
||||||
host adaptor and it's attached drives.
|
host adaptor and its attached drives.
|
||||||
|
|
||||||
The Symbios NVRAM also holds data on the boot order of host adaptors in a
|
The Symbios NVRAM also holds data on the boot order of host adaptors in a
|
||||||
system with more than one host adaptor. This information is no longer used
|
system with more than one host adaptor. This information is no longer used
|
||||||
|
@ -188,8 +188,8 @@ The WM8731 output mixer has 3 inputs (sources)
|
|||||||
3. Mic Sidetone Input
|
3. Mic Sidetone Input
|
||||||
|
|
||||||
Each input in this example has a kcontrol associated with it (defined in example
|
Each input in this example has a kcontrol associated with it (defined in example
|
||||||
above) and is connected to the output mixer via it's kcontrol name. We can now
|
above) and is connected to the output mixer via its kcontrol name. We can now
|
||||||
connect the destination widget (wrt audio signal) with it's source widgets.
|
connect the destination widget (wrt audio signal) with its source widgets.
|
||||||
|
|
||||||
/* output mixer */
|
/* output mixer */
|
||||||
{"Output Mixer", "Line Bypass Switch", "Line Input"},
|
{"Output Mixer", "Line Bypass Switch", "Line Input"},
|
||||||
|
@ -67,7 +67,7 @@ static struct snd_soc_dai_link corgi_dai = {
|
|||||||
.ops = &corgi_ops,
|
.ops = &corgi_ops,
|
||||||
};
|
};
|
||||||
|
|
||||||
struct snd_soc_card then sets up the machine with it's DAIs. e.g.
|
struct snd_soc_card then sets up the machine with its DAIs. e.g.
|
||||||
|
|
||||||
/* corgi audio machine driver */
|
/* corgi audio machine driver */
|
||||||
static struct snd_soc_card snd_soc_corgi = {
|
static struct snd_soc_card snd_soc_corgi = {
|
||||||
|
@ -33,7 +33,7 @@ features :-
|
|||||||
and machines.
|
and machines.
|
||||||
|
|
||||||
* Easy I2S/PCM audio interface setup between codec and SoC. Each SoC
|
* Easy I2S/PCM audio interface setup between codec and SoC. Each SoC
|
||||||
interface and codec registers it's audio interface capabilities with the
|
interface and codec registers its audio interface capabilities with the
|
||||||
core and are subsequently matched and configured when the application
|
core and are subsequently matched and configured when the application
|
||||||
hardware parameters are known.
|
hardware parameters are known.
|
||||||
|
|
||||||
|
@ -381,7 +381,7 @@ descriptor that gives us the status of the transfer, its identification
|
|||||||
we issue another URB to read into the destination buffer the chunk of
|
we issue another URB to read into the destination buffer the chunk of
|
||||||
data coming out of the remote endpoint. Done, wait for the next guy. The
|
data coming out of the remote endpoint. Done, wait for the next guy. The
|
||||||
callbacks for the URBs issued from here are the ones that will declare
|
callbacks for the URBs issued from here are the ones that will declare
|
||||||
the xfer complete at some point and call it's callback.
|
the xfer complete at some point and call its callback.
|
||||||
|
|
||||||
Seems simple, but the implementation is not trivial.
|
Seems simple, but the implementation is not trivial.
|
||||||
|
|
||||||
|
@ -45,7 +45,7 @@ most general to most specific:
|
|||||||
to establish the task policy for a child task exec()'d from an
|
to establish the task policy for a child task exec()'d from an
|
||||||
executable image that has no awareness of memory policy. See the
|
executable image that has no awareness of memory policy. See the
|
||||||
MEMORY POLICY APIS section, below, for an overview of the system call
|
MEMORY POLICY APIS section, below, for an overview of the system call
|
||||||
that a task may use to set/change it's task/process policy.
|
that a task may use to set/change its task/process policy.
|
||||||
|
|
||||||
In a multi-threaded task, task policies apply only to the thread
|
In a multi-threaded task, task policies apply only to the thread
|
||||||
[Linux kernel task] that installs the policy and any threads
|
[Linux kernel task] that installs the policy and any threads
|
||||||
@ -301,7 +301,7 @@ decrement this reference count, respectively. mpol_put() will only free
|
|||||||
the structure back to the mempolicy kmem cache when the reference count
|
the structure back to the mempolicy kmem cache when the reference count
|
||||||
goes to zero.
|
goes to zero.
|
||||||
|
|
||||||
When a new memory policy is allocated, it's reference count is initialized
|
When a new memory policy is allocated, its reference count is initialized
|
||||||
to '1', representing the reference held by the task that is installing the
|
to '1', representing the reference held by the task that is installing the
|
||||||
new policy. When a pointer to a memory policy structure is stored in another
|
new policy. When a pointer to a memory policy structure is stored in another
|
||||||
structure, another reference is added, as the task's reference will be dropped
|
structure, another reference is added, as the task's reference will be dropped
|
||||||
|
@ -25,7 +25,7 @@ When a w1 master driver registers with the w1 subsystem, the following occurs:
|
|||||||
- sysfs entries for that w1 master are created
|
- sysfs entries for that w1 master are created
|
||||||
- the w1 bus is periodically searched for new slave devices
|
- the w1 bus is periodically searched for new slave devices
|
||||||
|
|
||||||
When a device is found on the bus, w1 core checks if driver for it's family is
|
When a device is found on the bus, w1 core checks if driver for its family is
|
||||||
loaded. If so, the family driver is attached to the slave.
|
loaded. If so, the family driver is attached to the slave.
|
||||||
If there is no driver for the family, default one is assigned, which allows to perform
|
If there is no driver for the family, default one is assigned, which allows to perform
|
||||||
almost any kind of operations. Each logical operation is a transaction
|
almost any kind of operations. Each logical operation is a transaction
|
||||||
|
Loading…
Reference in New Issue
Block a user