apfs/linux-apfs
0
0
Fork 0
mirror of https://github.com/linux-apfs/linux-apfs.git synced 2026-05-01 15:00:59 -07:00
Code Issues Packages Projects Releases Wiki Activity

Merge git://git.kernel.org/pub/scm/linux/kernel/git/bunk/trivial

Browse Source 
* git://git.kernel.org/pub/scm/linux/kernel/git/bunk/trivial: (39 commits)
  Add missing maintainer countries in CREDITS
  Fix bytes <-> kilobytes  typo in Kconfig for ramdisk
  fix a typo in Documentation/pi-futex.txt
  BUG_ON conversion for fs/xfs/
  BUG_ON() conversion in fs/nfsd/
  BUG_ON conversion for fs/reiserfs
  BUG_ON cleanups in arch/i386
  BUG_ON cleanup in drivers/net/tokenring/
  BUG_ON cleanup for drivers/md/
  kerneldoc-typo in led-class.c
  debugfs: spelling fix
  rcutorture: Fix incorrect description of default for nreaders parameter
  parport: Remove space in function calls
  Michal Wronski: update contact info
  Spelling fix: "control" instead of "cotrol"
  reboot parameter in Documentation/kernel-parameters.txt
  Fix copy&waste bug in comment in scripts/kernel-doc
  remove duplicate "until" from kernel/workqueue.c
  ite_gpio fix tabbage
  fix file specification in comments
  ...

Fixed trivial path conflicts due to removed files:
   arch/mips/dec/boot/decstation.c, drivers/char/ite_gpio.c
This commit is contained in:
Linus Torvalds
2006-10-03 16:35:11 -07:00
parent f3c87a8999 a847825970
commit 708e16892e
596 changed files with 1095 additions and 1333 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Documentation/DMA-mapping.txt
+2 -2
View File
@@ -107,7 +107,7 @@ The query is performed via a call to pci_set_dma_mask():
int pci_set_dma_mask(struct pci_dev *pdev, u64 device_mask);
The query for consistent allocations is performed via a a call to
The query for consistent allocations is performed via a call to
pci_set_consistent_dma_mask():
int pci_set_consistent_dma_mask(struct pci_dev *pdev, u64 device_mask);
@@ -117,7 +117,7 @@ device_mask is a bit mask describing which bits of a PCI address your
device supports. It returns zero if your card can perform DMA
properly on the machine given the address mask you provided.
If it returns non-zero, your device can not perform DMA properly on
If it returns non-zero, your device cannot perform DMA properly on
this platform, and attempting to do so will result in undefined
behavior. You must either use a different mask, or not use DMA.
Documentation/DocBook/libata.tmpl
+1 -1
View File
@@ -1400,7 +1400,7 @@ and other resources, etc.
<listitem>
<para>
When it's known that HBA is in ready state but ATA/ATAPI
device in in unknown state, reset only device.
device is in unknown state, reset only device.
</para>
</listitem>
Documentation/DocBook/usb.tmpl
+2 -3
View File
@@ -314,8 +314,7 @@
<emphasis>usbdevfs</emphasis> although it wasn't solving what
<emphasis>devfs</emphasis> was.
Every USB device will appear in usbfs, regardless of whether or
not it has a kernel driver; but only devices with kernel drivers
show up in devfs.
not it has a kernel driver.
</para>
<sect1>
@@ -741,7 +740,7 @@ usbdev_ioctl (int fd, int ifno, unsigned request, void *param)
<title>Synchronous I/O Support</title>
<para>Synchronous requests involve the kernel blocking
until until the user mode request completes, either by
until the user mode request completes, either by
finishing successfully or by reporting an error.
In most cases this is the simplest way to use usbfs,
although as noted above it does prevent performing I/O
Documentation/DocBook/writing_usb_driver.tmpl
+1 -6
View File
@@ -224,13 +224,8 @@ static int skel_probe(struct usb_interface *interface,
Conversely, when the device is removed from the USB bus, the disconnect
function is called with the device pointer. The driver needs to clean any
private data that has been allocated at this time and to shut down any
pending urbs that are in the USB system. The driver also unregisters
itself from the devfs subsystem with the call:
pending urbs that are in the USB system.
</para>
<programlisting>
/* remove our devfs node */
devfs_unregister(skel->devfs);
</programlisting>
<para>
Now that the device is plugged into the system and the driver is bound to
the device, any of the functions in the file_operations structure that
Documentation/IPMI.txt
+2 -2
View File
@@ -468,12 +468,12 @@ BMCs specified on the smb_addr line will be detected.
Setting smb_dbg_probe to 1 will enable debugging of the probing and
detection process for BMCs on the SMBusses.
Discovering the IPMI compilant BMC on the SMBus can cause devices
Discovering the IPMI compliant BMC on the SMBus can cause devices
on the I2C bus to fail. The SMBus driver writes a "Get Device ID" IPMI
message as a block write to the I2C bus and waits for a response.
This action can be detrimental to some I2C devices. It is highly recommended
that the known I2c address be given to the SMBus driver in the smb_addr
parameter. The default adrress range will not be used when a smb_addr
parameter. The default address range will not be used when a smb_addr
parameter is provided.
When compiled into the kernel, the addresses can be specified on the
Documentation/MSI-HOWTO.txt
+1 -1
View File
@@ -267,7 +267,7 @@ y = The number of MSI capable devices populated in the system.
vector reserved to avoid the case where some MSI-X capable
drivers may attempt to claim all available vector resources.
z = The number of MSI-X capable devices pupulated in the system.
z = The number of MSI-X capable devices populated in the system.
This policy ensures that maximum (x - y) is distributed
evenly among MSI-X capable devices.
Documentation/RCU/whatisRCU.txt
+2 -2
View File
@@ -582,7 +582,7 @@ The rcu_read_lock() and rcu_read_unlock() primitive read-acquire
and release a global reader-writer lock. The synchronize_rcu()
primitive write-acquires this same lock, then immediately releases
it. This means that once synchronize_rcu() exits, all RCU read-side
critical sections that were in progress before synchonize_rcu() was
critical sections that were in progress before synchronize_rcu() was
called are guaranteed to have completed -- there is no way that
synchronize_rcu() would have been able to write-acquire the lock
otherwise.
@@ -750,7 +750,7 @@ Or, for those who prefer a side-by-side listing:
Either way, the differences are quite small. Read-side locking moves
to rcu_read_lock() and rcu_read_unlock, update-side locking moves from
from a reader-writer lock to a simple spinlock, and a synchronize_rcu()
a reader-writer lock to a simple spinlock, and a synchronize_rcu()
precedes the kfree().
However, there is one potential catch: the read-side and update-side
Documentation/aoe/todo.txt
+1 -1
View File
@@ -7,7 +7,7 @@ not been observed, but it would be nice to eliminate any potential for
deadlock under memory pressure.
Because ATA over Ethernet is not fragmented by the kernel's IP code,
the destructore member of the struct sk_buff is available to the aoe
the destructor member of the struct sk_buff is available to the aoe
driver. By using a mempool for allocating all but the first few
sk_buffs, and by registering a destructor, we should be able to
efficiently allocate sk_buffs without introducing any potential for
Documentation/arm/SA1100/serial_UART
+2 -2
View File
@@ -24,8 +24,8 @@ The SA1100 serial port had its major/minor numbers officially assigned:
> 7 = /dev/cusa2 Callout device for ttySA2
>
If you're not using devfs, you must create those inodes in /dev
on the root filesystem used by your SA1100-based device:
You must create those inodes in /dev on the root filesystem used
by your SA1100-based device:
mknod ttySA0 c 204 5
mknod ttySA1 c 204 6
Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt
+1 -1
View File
@@ -38,7 +38,7 @@ MTD
---
The NAND and NOR support has been merged from the linux-mtd project.
Any prolbems, see http://www.linux-mtd.infradead.org/ for more
Any problems, see http://www.linux-mtd.infradead.org/ for more
information or up-to-date versions of linux-mtd.
Documentation/arm/Samsung-S3C24XX/GPIO.txt
+1 -1
View File
@@ -24,7 +24,7 @@ Headers
header include/asm-arm/arch-s3c2410/hardware.h which can be
included by #include <asm/arch/hardware.h>
A useful ammount of documentation can be found in the hardware
A useful amount of documentation can be found in the hardware
header on how the GPIO functions (and others) work.
Whilst a number of these functions do make some checks on what
Documentation/arm/Samsung-S3C24XX/Overview.txt
+1 -1
View File
@@ -80,7 +80,7 @@ Machines
Adding New Machines
-------------------
The archicture has been designed to support as many machines as can
The architecture has been designed to support as many machines as can
be configured for it in one kernel build, and any future additions
should keep this in mind before altering items outside of their own
machine files.
Documentation/arm/Samsung-S3C24XX/S3C2412.txt
+1 -1
View File
@@ -80,7 +80,7 @@ RTC
Watchdog
--------
The watchdog harware is the same as the S3C2410, and is supported by
The watchdog hardware is the same as the S3C2410, and is supported by
the s3c2410_wdt driver.
Documentation/block/as-iosched.txt
+2 -2
View File
@@ -99,8 +99,8 @@ contrast, many write requests may be dispatched to the disk controller
at a time during a write batch. It is this characteristic that can make
the anticipatory scheduler perform anomalously with controllers supporting
TCQ, or with hardware striped RAID devices. Setting the antic_expire
queue paramter (see below) to zero disables this behavior, and the anticipatory
scheduler behaves essentially like the deadline scheduler.
queue parameter (see below) to zero disables this behavior, and the
anticipatory scheduler behaves essentially like the deadline scheduler.
When read anticipation is enabled (antic_expire is not zero), reads
are dispatched to the disk controller one at a time.
Documentation/block/barrier.txt
+3 -3
View File
@@ -25,7 +25,7 @@ of the following three ways.
i. For devices which have queue depth greater than 1 (TCQ devices) and
support ordered tags, block layer can just issue the barrier as an
ordered request and the lower level driver, controller and drive
itself are responsible for making sure that the ordering contraint is
itself are responsible for making sure that the ordering constraint is
met. Most modern SCSI controllers/drives should support this.
NOTE: SCSI ordered tag isn't currently used due to limitation in the
@@ -42,7 +42,7 @@ iii. Devices which have queue depth of 1. This is a degenerate case
of ii. Just keeping issue order suffices. Ancient SCSI
controllers/drives and IDE drives are in this category.
2. Forced flushing to physcial medium
2. Forced flushing to physical medium
Again, if you're not gonna do synchronization with disk drives (dang,
it sounds even more appealing now!), the reason you use I/O barriers
@@ -56,7 +56,7 @@ There are four cases,
i. No write-back cache. Keeping requests ordered is enough.
ii. Write-back cache but no flush operation. There's no way to
gurantee physical-medium commit order. This kind of devices can't to
guarantee physical-medium commit order. This kind of devices can't to
I/O barriers.
iii. Write-back cache and flush operation but no FUA (forced unit
Documentation/block/biodoc.txt
+5 -5
View File
@@ -135,7 +135,7 @@ Some new queue property settings:
Sets two variables that limit the size of the request.
- The request queue's max_sectors, which is a soft size in
in units of 512 byte sectors, and could be dynamically varied
units of 512 byte sectors, and could be dynamically varied
by the core kernel.
- The request queue's max_hw_sectors, which is a hard limit
@@ -783,7 +783,7 @@ all the outstanding requests. There's a third helper to do that:
blk_queue_invalidate_tags(request_queue_t *q)
Clear the internal block tag queue and readd all the pending requests
Clear the internal block tag queue and re-add all the pending requests
to the request queue. The driver will receive them again on the
next request_fn run, just like it did the first time it encountered
them.
@@ -890,7 +890,7 @@ Aside:
Kvec i/o:
Ben LaHaise's aio code uses a slighly different structure instead
Ben LaHaise's aio code uses a slightly different structure instead
of kiobufs, called a kvec_cb. This contains an array of <page, offset, len>
tuples (very much like the networking code), together with a callback function
and data pointer. This is embedded into a brw_cb structure when passed
@@ -988,7 +988,7 @@ elevator_exit_fn Allocate and free any elevator specific storage
for a queue.
4.2 Request flows seen by I/O schedulers
All requests seens by I/O schedulers strictly follow one of the following three
All requests seen by I/O schedulers strictly follow one of the following three
flows.
set_req_fn ->
@@ -1203,6 +1203,6 @@ temporarily map a bio into the virtual address space.
and Linus' comments - Jan 2001)
9.2 Discussions about kiobuf and bh design on lkml between sct, linus, alan
et al - Feb-March 2001 (many of the initial thoughts that led to bio were
brought up in this discusion thread)
brought up in this discussion thread)
9.3 Discussions on mempool on lkml - Dec 2001.
Documentation/block/deadline-iosched.txt
+2 -2
View File
@@ -23,11 +23,11 @@ you can do so by typing:
read_expire (in ms)
-----------
The goal of the deadline io scheduler is to attempt to guarentee a start
The goal of the deadline io scheduler is to attempt to guarantee a start
service time for a request. As we focus mainly on read latencies, this is
tunable. When a read request first enters the io scheduler, it is assigned
a deadline that is the current time + the read_expire value in units of
miliseconds.
milliseconds.
write_expire (in ms)
Documentation/cciss.txt
+2 -2
View File
@@ -80,7 +80,7 @@ the /proc filesystem entry which the "block" side of the driver creates as
the SCSI core may not yet be initialized (because the driver is a block
driver) and attempting to register it with the SCSI core in such a case
would cause a hang. This is best done via an initialization script
(typically in /etc/init.d, but could vary depending on distibution).
(typically in /etc/init.d, but could vary depending on distribution).
For example:
for x in /proc/driver/cciss/cciss[0-9]*
@@ -152,7 +152,7 @@ side during the SCSI error recovery process, the cciss driver only
implements the first two of these actions, aborting the command, and
resetting the device. Additionally, most tape drives will not oblige
in aborting commands, and sometimes it appears they will not even
obey a reset coommand, though in most circumstances they will. In
obey a reset command, though in most circumstances they will. In
the case that the command cannot be aborted and the device cannot be
reset, the device will be set offline.
Documentation/computone.txt
+2 -68
View File
@@ -199,30 +199,6 @@ boxes this will leave gaps in the sequence of device names. ip2mkdev uses
Linux tty naming conventions: ttyF0 - ttyF255 for normal devices, and
cuf0 - cuf255 for callout devices.
If you are using devfs, existing devices are automatically created within
the devfs name space. Normal devices will be tts/F0 - tts/F255 and callout
devices will be cua/F0 - cua/F255. With devfs installed, ip2mkdev will
create symbolic links in /dev from the old conventional names to the newer
devfs names as follows:
/dev/ip2ipl[n] -> /dev/ip2/ipl[n] n = 0 - 3
/dev/ip2stat[n] -> /dev/ip2/stat[n] n = 0 - 3
/dev/ttyF[n] -> /dev/tts/F[n] n = 0 - 255
/dev/cuf[n] -> /dev/cua/F[n] n = 0 - 255
Only devices for existing ports and boards will be created.
IMPORTANT NOTE: The naming convention used for devfs by this driver
was changed from 1.2.12 to 1.2.13. The old naming convention was to
use ttf/%d for the tty device and cuf/%d for the cua device. That
has been changed to conform to an agreed-upon standard of placing
all the tty devices under tts. The device names are now tts/F%d for
the tty device and cua/F%d for the cua devices. If you were using
the older devfs names, you must update for the newer convention.
You do not need to run ip2mkdev if you are using devfs and only want to
use the devfs native device names.
4. USING THE DRIVERS
@@ -256,57 +232,15 @@ cut out and run as "ip2mkdev" to create the necessary device files. To
use the ip2mkdev script, you must have procfs enabled and the proc file
system mounted on /proc.
You do not need to run ip2mkdev if you are using devfs and only want to
use the devfs native device names.
6. DEVFS
DEVFS is the DEVice File System available as an add on package for the
2.2.x kernels and available as a configuration option in 2.3.46 and higher.
Devfs allows for the automatic creation and management of device names
under control of the device drivers themselves. The Devfs namespace is
hierarchical and reduces the clutter present in the normal flat /dev
namespace. Devfs names and conventional device names may be intermixed.
A userspace daemon, devfsd, exists to allow for automatic creation and
management of symbolic links from the devfs name space to the conventional
names. More details on devfs can be found on the DEVFS home site at
<http://www.atnf.csiro.au/~rgooch/linux/> or in the file kernel
documentation files, .../linux/Documentation/filesystems/devfs/README.
If you are using devfs, existing devices are automatically created within
the devfs name space. Normal devices will be tts/F0 - tts/F255 and callout
devices will be cua/F0 - cua/F255. With devfs installed, ip2mkdev will
create symbolic links in /dev from the old conventional names to the newer
devfs names as follows:
/dev/ip2ipl[n] -> /dev/ip2/ipl[n] n = 0 - 3
/dev/ip2stat[n] -> /dev/ip2/stat[n] n = 0 - 3
/dev/ttyF[n] -> /dev/tts/F[n] n = 0 - 255
/dev/cuf[n] -> /dev/cua/F[n] n = 0 - 255
Only devices for existing ports and boards will be created.
IMPORTANT NOTE: The naming convention used for devfs by this driver
was changed from 1.2.12 to 1.2.13. The old naming convention was to
use ttf/%d for the tty device and cuf/%d for the cua device. That
has been changed to conform to an agreed-upon standard of placing
all the tty devices under tts. The device names are now tts/F%d for
the tty device and cua/F%d for the cua devices. If you were using
the older devfs names, you must update for the newer convention.
You do not need to run ip2mkdev if you are using devfs and only want to
use the devfs native device names.
7. NOTES
6. NOTES
This is a release version of the driver, but it is impossible to test it
in all configurations of Linux. If there is any anomalous behaviour that
does not match the standard serial port's behaviour please let us know.
8. ip2mkdev shell script
7. ip2mkdev shell script
Previously, this script was simply attached here. It is now attached as a
shar archive to make it easier to extract the script from the documentation.
Documentation/cpu-freq/cpufreq-stats.txt
+5 -5
View File
@@ -1,5 +1,5 @@
CPU frequency and voltage scaling statictics in the Linux(TM) kernel
CPU frequency and voltage scaling statistics in the Linux(TM) kernel
L i n u x c p u f r e q - s t a t s d r i v e r
@@ -18,8 +18,8 @@ Contents
1. Introduction
cpufreq-stats is a driver that provices CPU frequency statistics for each CPU.
This statistics is provided in /sysfs as a bunch of read_only interfaces. This
interface (when configured) will appear in a seperate directory under cpufreq
These statistics are provided in /sysfs as a bunch of read_only interfaces. This
interface (when configured) will appear in a separate directory under cpufreq
in /sysfs (<sysfs root>/devices/system/cpu/cpuX/cpufreq/stats/) for each CPU.
Various statistics will form read_only files under this directory.
@@ -53,7 +53,7 @@ drwxr-xr-x 3 root root 0 May 14 15:58 ..
This gives the amount of time spent in each of the frequencies supported by
this CPU. The cat output will have "<frequency> <time>" pair in each line, which
will mean this CPU spent <time> usertime units of time at <frequency>. Output
will have one line for each of the supported freuencies. usertime units here
will have one line for each of the supported frequencies. usertime units here
is 10mS (similar to other time exported in /proc).
--------------------------------------------------------------------------------
@@ -115,7 +115,7 @@ basic statistics which includes time_in_state and total_trans.
"CPU frequency translation statistics details" (CONFIG_CPU_FREQ_STAT_DETAILS)
provides fine grained cpufreq stats by trans_table. The reason for having a
seperate config option for trans_table is:
separate config option for trans_table is:
- trans_table goes against the traditional /sysfs rule of one value per
interface. It provides a whole bunch of value in a 2 dimensional matrix
form.

Some files were not shown because too many files have changed in this diff Show More