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 branch 'master' into next

Browse Source
This commit is contained in:
James Morris
2008-08-28 10:47:34 +10:00
parent 93c06cbbf9 4c246edd25
commit 86d688984d
4405 changed files with 100578 additions and 38118 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Documentation/00-INDEX
-2
View File
@@ -89,8 +89,6 @@ cciss.txt
- info, major/minor #'s for Compaq's SMART Array Controllers.
cdrom/
- directory with information on the CD-ROM drivers that Linux has.
cli-sti-removal.txt
- cli()/sti() removal guide.
computone.txt
- info on Computone Intelliport II/Plus Multiport Serial Driver.
connector/
Documentation/DocBook/Makefile
+8 -1
View File
@@ -12,7 +12,7 @@ DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \
kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \
gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
mac80211.xml debugobjects.xml
mac80211.xml debugobjects.xml sh.xml
###
# The build process is as follows (targets):
@@ -102,6 +102,13 @@ C-procfs-example = procfs_example.xml
C-procfs-example2 = $(addprefix $(obj)/,$(C-procfs-example))
$(obj)/procfs-guide.xml: $(C-procfs-example2)
# List of programs to build
##oops, this is a kernel module::hostprogs-y := procfs_example
obj-m += procfs_example.o
# Tell kbuild to always build the programs
always := $(hostprogs-y)
notfoundtemplate = echo "*** You have to install docbook-utils or xmlto ***"; \
exit 1
db2xtemplate = db2TYPE -o $(dir $@) $<
Documentation/DocBook/procfs_example.c
+1 -3
View File
@@ -189,8 +189,6 @@ static int __init init_procfs_example(void)
return 0;
no_symlink:
remove_proc_entry("tty", example_dir);
no_tty:
remove_proc_entry("bar", example_dir);
no_bar:
remove_proc_entry("foo", example_dir);
@@ -206,7 +204,6 @@ out:
static void __exit cleanup_procfs_example(void)
{
remove_proc_entry("jiffies_too", example_dir);
remove_proc_entry("tty", example_dir);
remove_proc_entry("bar", example_dir);
remove_proc_entry("foo", example_dir);
remove_proc_entry("jiffies", example_dir);
@@ -222,3 +219,4 @@ module_exit(cleanup_procfs_example);
MODULE_AUTHOR("Erik Mouw");
MODULE_DESCRIPTION("procfs examples");
MODULE_LICENSE("GPL");
Documentation/DocBook/s390-drivers.tmpl
+4 -4
View File
@@ -100,7 +100,7 @@
the hardware structures represented here, please consult the Principles
of Operation.
</para>
!Iinclude/asm-s390/cio.h
!Iarch/s390/include/asm/cio.h
</sect1>
<sect1 id="ccwdev">
<title>ccw devices</title>
@@ -114,7 +114,7 @@
ccw device structure. Device drivers must not bypass those functions
or strange side effects may happen.
</para>
!Iinclude/asm-s390/ccwdev.h
!Iarch/s390/include/asm/ccwdev.h
!Edrivers/s390/cio/device.c
!Edrivers/s390/cio/device_ops.c
</sect1>
@@ -125,7 +125,7 @@
measurement data which is made available by the channel subsystem
for each channel attached device.
</para>
!Iinclude/asm-s390/cmb.h
!Iarch/s390/include/asm/cmb.h
!Edrivers/s390/cio/cmf.c
</sect1>
</chapter>
@@ -142,7 +142,7 @@
</para>
<sect1 id="ccwgroupdevices">
<title>ccw group devices</title>
!Iinclude/asm-s390/ccwgroup.h
!Iarch/s390/include/asm/ccwgroup.h
!Edrivers/s390/cio/ccwgroup.c
</sect1>
</chapter>
Documentation/DocBook/sh.tmpl
+105
View File
@@ -0,0 +1,105 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
<book id="sh-drivers">
<bookinfo>
<title>SuperH Interfaces Guide</title>
<authorgroup>
<author>
<firstname>Paul</firstname>
<surname>Mundt</surname>
<affiliation>
<address>
<email>lethal@linux-sh.org</email>
</address>
</affiliation>
</author>
</authorgroup>
<copyright>
<year>2008</year>
<holder>Paul Mundt</holder>
</copyright>
<copyright>
<year>2008</year>
<holder>Renesas Technology Corp.</holder>
</copyright>
<legalnotice>
<para>
This documentation is free software; you can redistribute
it and/or modify it under the terms of the GNU General Public
License version 2 as published by the Free Software Foundation.
</para>
<para>
This program is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.
</para>
<para>
You should have received a copy of the GNU General Public
License along with this program; if not, write to the Free
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
MA 02111-1307 USA
</para>
<para>
For more details see the file COPYING in the source
distribution of Linux.
</para>
</legalnotice>
</bookinfo>
<toc></toc>
<chapter id="mm">
<title>Memory Management</title>
<sect1 id="sh4">
<title>SH-4</title>
<sect2 id="sq">
<title>Store Queue API</title>
!Earch/sh/kernel/cpu/sh4/sq.c
</sect2>
</sect1>
<sect1 id="sh5">
<title>SH-5</title>
<sect2 id="tlb">
<title>TLB Interfaces</title>
!Iarch/sh/mm/tlb-sh5.c
!Iarch/sh/include/asm/tlb_64.h
</sect2>
</sect1>
</chapter>
<chapter id="clk">
<title>Clock Framework Extensions</title>
!Iarch/sh/include/asm/clock.h
</chapter>
<chapter id="mach">
<title>Machine Specific Interfaces</title>
<sect1 id="dreamcast">
<title>mach-dreamcast</title>
!Iarch/sh/boards/mach-dreamcast/rtc.c
</sect1>
<sect1 id="x3proto">
<title>mach-x3proto</title>
!Earch/sh/boards/mach-x3proto/ilsel.c
</sect1>
</chapter>
<chapter id="busses">
<title>Busses</title>
<sect1 id="superhyway">
<title>SuperHyway</title>
!Edrivers/sh/superhyway/superhyway.c
</sect1>
<sect1 id="maple">
<title>Maple</title>
!Edrivers/sh/maple/maple.c
</sect1>
</chapter>
</book>
Documentation/DocBook/videobook.tmpl
+1 -1
View File
@@ -1648,7 +1648,7 @@ static struct video_buffer capture_fb;
<chapter id="pubfunctions">
<title>Public Functions Provided</title>
!Edrivers/media/video/videodev.c
!Edrivers/media/video/v4l2-dev.c
</chapter>
</book>
Documentation/DocBook/z8530book.tmpl
+12 -26
View File
@@ -69,12 +69,6 @@
device to be used as both a tty interface and as a synchronous
controller is a project for Linux post the 2.4 release
</para>
<para>
The support code handles most common card configurations and
supports running both Cisco HDLC and Synchronous PPP. With extra
glue the frame relay and X.25 protocols can also be used with this
driver.
</para>
</chapter>
<chapter id="Driver_Modes">
@@ -179,35 +173,27 @@
<para>
If you wish to use the network interface facilities of the driver,
then you need to attach a network device to each channel that is
present and in use. In addition to use the SyncPPP and Cisco HDLC
present and in use. In addition to use the generic HDLC
you need to follow some additional plumbing rules. They may seem
complex but a look at the example hostess_sv11 driver should
reassure you.
</para>
<para>
The network device used for each channel should be pointed to by
the netdevice field of each channel. The dev-&gt; priv field of the
the netdevice field of each channel. The hdlc-&gt; priv field of the
network device points to your private data - you will need to be
able to find your ppp device from this. In addition to use the
sync ppp layer the private data must start with a void * pointer
to the syncppp structures.
able to find your private data from this.
</para>
<para>
The way most drivers approach this particular problem is to
create a structure holding the Z8530 device definition and
put that and the syncppp pointer into the private field of
the network device. The network device fields of the channels
then point back to the network devices. The ppp_device can also
be put in the private structure conveniently.
put that into the private field of the network device. The
network device fields of the channels then point back to the
network devices.
</para>
<para>
If you wish to use the synchronous ppp then you need to attach
the syncppp layer to the network device. You should do this before
you register the network device. The
<function>sppp_attach</function> requires that the first void *
pointer in your private data is pointing to an empty struct
ppp_device. The function fills in the initial data for the
ppp/hdlc layer.
If you wish to use the generic HDLC then you need to register
the HDLC device.
</para>
<para>
Before you register your network device you will also need to
@@ -314,10 +300,10 @@
buffer in sk_buff format and queues it for transmission. The
caller must provide the entire packet with the exception of the
bitstuffing and CRC. This is normally done by the caller via
the syncppp interface layer. It returns 0 if the buffer has been
queued and non zero values for queue full. If the function accepts
the buffer it becomes property of the Z8530 layer and the caller
should not free it.
the generic HDLC interface layer. It returns 0 if the buffer has been
queued and non zero values for queue full. If the function accepts
the buffer it becomes property of the Z8530 layer and the caller
should not free it.
</para>
<para>
The function <function>z8530_get_stats</function> returns a pointer
Documentation/Makefile
+3
View File
@@ -0,0 +1,3 @@
obj-m := DocBook/ accounting/ auxdisplay/ connector/ \
filesystems/configfs/ ia64/ networking/ \
pcmcia/ spi/ video4linux/ vm/ watchdog/src/
Documentation/accounting/Makefile
+10
View File
@@ -0,0 +1,10 @@
# kbuild trick to avoid linker error. Can be omitted if a module is built.
obj- := dummy.o
# List of programs to build
hostprogs-y := getdelays
# Tell kbuild to always build the programs
always := $(hostprogs-y)
HOSTCFLAGS_getdelays.o += -I$(objtree)/usr/include
Documentation/accounting/getdelays.c
+17 -8
View File
@@ -201,13 +201,19 @@ void print_delayacct(struct taskstats *t)
"RECLAIM %12s%15s\n"
" %15llu%15llu\n",
"count", "real total", "virtual total", "delay total",
t->cpu_count, t->cpu_run_real_total, t->cpu_run_virtual_total,
t->cpu_delay_total,
(unsigned long long)t->cpu_count,
(unsigned long long)t->cpu_run_real_total,
(unsigned long long)t->cpu_run_virtual_total,
(unsigned long long)t->cpu_delay_total,
"count", "delay total",
t->blkio_count, t->blkio_delay_total,
"count", "delay total", t->swapin_count, t->swapin_delay_total,
(unsigned long long)t->blkio_count,
(unsigned long long)t->blkio_delay_total,
"count", "delay total",
t->freepages_count, t->freepages_delay_total);
(unsigned long long)t->swapin_count,
(unsigned long long)t->swapin_delay_total,
"count", "delay total",
(unsigned long long)t->freepages_count,
(unsigned long long)t->freepages_delay_total);
}
void task_context_switch_counts(struct taskstats *t)
@@ -215,14 +221,17 @@ void task_context_switch_counts(struct taskstats *t)
printf("\n\nTask %15s%15s\n"
" %15llu%15llu\n",
"voluntary", "nonvoluntary",
t->nvcsw, t->nivcsw);
(unsigned long long)t->nvcsw, (unsigned long long)t->nivcsw);
}
void print_cgroupstats(struct cgroupstats *c)
{
printf("sleeping %llu, blocked %llu, running %llu, stopped %llu, "
"uninterruptible %llu\n", c->nr_sleeping, c->nr_io_wait,
c->nr_running, c->nr_stopped, c->nr_uninterruptible);
"uninterruptible %llu\n", (unsigned long long)c->nr_sleeping,
(unsigned long long)c->nr_io_wait,
(unsigned long long)c->nr_running,
(unsigned long long)c->nr_stopped,
(unsigned long long)c->nr_uninterruptible);
}
Documentation/arm/IXP4xx
+1 -1
View File
@@ -32,7 +32,7 @@ Linux currently supports the following features on the IXP4xx chips:
- Flash access (MTD/JFFS)
- I2C through GPIO on IXP42x
- GPIO for input/output/interrupts
See include/asm-arm/arch-ixp4xx/platform.h for access functions.
See arch/arm/mach-ixp4xx/include/mach/platform.h for access functions.
- Timers (watchdog, OS)
The following components of the chips are not supported by Linux and
Documentation/arm/Interrupts
+1 -1
View File
@@ -158,7 +158,7 @@ So, what's changed?
be re-checked for pending events. (see the Neponset IRQ handler for
details).
7. fixup_irq() is gone, as is include/asm-arm/arch-*/irq.h
7. fixup_irq() is gone, as is arch/arm/mach-*/include/mach/irq.h
Please note that this will not solve all problems - some of them are
hardware based. Mixing level-based and edge-based IRQs on the same
Documentation/arm/README
+2 -2
View File
@@ -79,7 +79,7 @@ Machine/Platform support
To this end, we now have arch/arm/mach-$(MACHINE) directories which are
designed to house the non-driver files for a particular machine (eg, PCI,
memory management, architecture definitions etc). For all future
machines, there should be a corresponding include/asm-arm/arch-$(MACHINE)
machines, there should be a corresponding arch/arm/mach-$(MACHINE)/include/mach
directory.
@@ -176,7 +176,7 @@ Kernel entry (head.S)
class typically based around one or more system on a chip devices, and
acts as a natural container around the actual implementations. These
classes are given directories - arch/arm/mach-<class> and
include/asm-arm/arch-<class> - which contain the source files to
arch/arm/mach-<class> - which contain the source files to/include/mach
support the machine class. This directories also contain any machine
specific supporting code.
Documentation/arm/Samsung-S3C24XX/GPIO.txt
+19 -4
View File
@@ -13,16 +13,31 @@ Introduction
data-sheet/users manual to find out the complete list.
GPIOLIB
-------
With the event of the GPIOLIB in drivers/gpio, support for some
of the GPIO functions such as reading and writing a pin will
be removed in favour of this common access method.
Once all the extant drivers have been converted, the functions
listed below will be removed (they may be marked as __deprecated
in the near future).
- s3c2410_gpio_getpin
- s3c2410_gpio_setpin
Headers
-------
See include/asm-arm/arch-s3c2410/regs-gpio.h for the list
See arch/arm/mach-s3c2410/include/mach/regs-gpio.h for the list
of GPIO pins, and the configuration values for them. This
is included by using #include <asm/arch/regs-gpio.h>
is included by using #include <mach/regs-gpio.h>
The GPIO management functions are defined in the hardware
header include/asm-arm/arch-s3c2410/hardware.h which can be
included by #include <asm/arch/hardware.h>
header arch/arm/mach-s3c2410/include/mach/hardware.h which can be
included by #include <mach/hardware.h>
A useful amount of documentation can be found in the hardware
header on how the GPIO functions (and others) work.
Documentation/arm/Samsung-S3C24XX/Overview.txt
+34 -3
View File
@@ -8,9 +8,10 @@ Introduction
The Samsung S3C24XX range of ARM9 System-on-Chip CPUs are supported
by the 's3c2410' architecture of ARM Linux. Currently the S3C2410,
S3C2412, S3C2413, S3C2440 and S3C2442 devices are supported.
S3C2412, S3C2413, S3C2440, S3C2442 and S3C2443 devices are supported.
Support for the S3C2400 and S3C24A0 series are in progress.
Support for the S3C2400 series is in progress.
Configuration
-------------
@@ -36,7 +37,23 @@ Layout
in arch/arm/mach-s3c2410 and S3C2440 in arch/arm/mach-s3c2440
Register, kernel and platform data definitions are held in the
include/asm-arm/arch-s3c2410 directory.
arch/arm/mach-s3c2410 directory./include/mach
arch/arm/plat-s3c24xx:
Files in here are either common to all the s3c24xx family,
or are common to only some of them with names to indicate this
status. The files that are not common to all are generally named
with the initial cpu they support in the series to ensure a short
name without any possibility of confusion with newer devices.
As an example, initially s3c244x would cover s3c2440 and s3c2442, but
with the s3c2443 which does not share many of the same drivers in
this directory, the name becomes invalid. We stick to s3c2440-<x>
to indicate a driver that is s3c2440 and s3c2442 compatible.
This does mean that to find the status of any given SoC, a number
of directories may need to be searched.
Machines
@@ -159,6 +176,17 @@ NAND
For more information see Documentation/arm/Samsung-S3C24XX/NAND.txt
SD/MMC
------
The SD/MMC hardware pre S3C2443 is supported in the current
kernel, the driver is drivers/mmc/host/s3cmci.c and supports
1 and 4 bit SD or MMC cards.
The SDIO behaviour of this driver has not been fully tested. There is no
current support for hardware SDIO interrupts.
Serial
------
@@ -178,6 +206,9 @@ GPIO
The core contains support for manipulating the GPIO, see the
documentation in GPIO.txt in the same directory as this file.
Newer kernels carry GPIOLIB, and support is being moved towards
this with some of the older support in line to be removed.
Clock Management
----------------
Documentation/arm/Samsung-S3C24XX/USB-Host.txt
+1 -1
View File
@@ -49,7 +49,7 @@ Board Support
Platform Data
-------------
See linux/include/asm-arm/arch-s3c2410/usb-control.h for the
See arch/arm/mach-s3c2410/include/mach/usb-control.h for the
descriptions of the platform device data. An implementation
can be found in linux/arch/arm/mach-s3c2410/usb-simtec.c .
Documentation/auxdisplay/Makefile
+10
View File
@@ -0,0 +1,10 @@
# kbuild trick to avoid linker error. Can be omitted if a module is built.
obj- := dummy.o
# List of programs to build
hostprogs-y := cfag12864b-example
# Tell kbuild to always build the programs
always := $(hostprogs-y)
HOSTCFLAGS_cfag12864b-example.o += -I$(objtree)/usr/include
Documentation/cciss.txt
+6 -15
View File
@@ -112,27 +112,18 @@ Hot plug support for SCSI tape drives
Hot plugging of SCSI tape drives is supported, with some caveats.
The cciss driver must be informed that changes to the SCSI bus
have been made, in addition to and prior to informing the SCSI
mid layer. This may be done via the /proc filesystem. For example:
have been made. This may be done via the /proc filesystem.
For example:
echo "rescan" > /proc/scsi/cciss0/1
This causes the adapter to query the adapter about changes to the
physical SCSI buses and/or fibre channel arbitrated loop and the
This causes the driver to query the adapter about changes to the
physical SCSI buses and/or fibre channel arbitrated loop and the
driver to make note of any new or removed sequential access devices
or medium changers. The driver will output messages indicating what
devices have been added or removed and the controller, bus, target and
lun used to address the device. Once this is done, the SCSI mid layer
can be informed of changes to the virtual SCSI bus which the driver
presents to it in the usual way. For example:
echo scsi add-single-device 3 2 1 0 > /proc/scsi/scsi
to add a device on controller 3, bus 2, target 1, lun 0. Note that
the driver makes an effort to preserve the devices positions
in the virtual SCSI bus, so if you are only moving tape drives
around on the same adapter and not adding or removing tape drives
from the adapter, informing the SCSI mid layer may not be necessary.
lun used to address the device. It then notifies the SCSI mid layer
of these changes.
Note that the naming convention of the /proc filesystem entries
contains a number in addition to the driver name. (E.g. "cciss0"
Documentation/cli-sti-removal.txt
-133
View File
@@ -1,133 +0,0 @@
#### cli()/sti() removal guide, started by Ingo Molnar <mingo@redhat.com>
as of 2.5.28, five popular macros have been removed on SMP, and
are being phased out on UP:
cli(), sti(), save_flags(flags), save_flags_cli(flags), restore_flags(flags)
until now it was possible to protect driver code against interrupt
handlers via a cli(), but from now on other, more lightweight methods
have to be used for synchronization, such as spinlocks or semaphores.
for example, driver code that used to do something like:
struct driver_data;
irq_handler (...)
{
....
driver_data.finish = 1;
driver_data.new_work = 0;
....
}
...
ioctl_func (...)
{
...
cli();
...
driver_data.finish = 0;
driver_data.new_work = 2;
...
sti();
...
}
was SMP-correct because the cli() function ensured that no
interrupt handler (amongst them the above irq_handler()) function
would execute while the cli()-ed section is executing.
but from now on a more direct method of locking has to be used:
DEFINE_SPINLOCK(driver_lock);
struct driver_data;
irq_handler (...)
{
unsigned long flags;
....
spin_lock_irqsave(&driver_lock, flags);
....
driver_data.finish = 1;
driver_data.new_work = 0;
....
spin_unlock_irqrestore(&driver_lock, flags);
....
}
...
ioctl_func (...)
{
...
spin_lock_irq(&driver_lock);
...
driver_data.finish = 0;
driver_data.new_work = 2;
...
spin_unlock_irq(&driver_lock);
...
}
the above code has a number of advantages:
- the locking relation is easier to understand - actual lock usage
pinpoints the critical sections. cli() usage is too opaque.
Easier to understand means it's easier to debug.
- it's faster, because spinlocks are faster to acquire than the
potentially heavily-used IRQ lock. Furthermore, your driver does
not have to wait eg. for a big heavy SCSI interrupt to finish,
because the driver_lock spinlock is only used by your driver.
cli() on the other hand was used by many drivers, and extended
the critical section to the whole IRQ handler function - creating
serious lock contention.
to make the transition easier, we've still kept the cli(), sti(),
save_flags(), save_flags_cli() and restore_flags() macros defined
on UP systems - but their usage will be phased out until 2.6 is
released.
drivers that want to disable local interrupts (interrupts on the
current CPU), can use the following five macros:
local_irq_disable(), local_irq_enable(), local_save_flags(flags),
local_irq_save(flags), local_irq_restore(flags)
but beware, their meaning and semantics are much simpler, far from
that of the old cli(), sti(), save_flags(flags) and restore_flags(flags)
SMP meaning:
local_irq_disable() => turn local IRQs off
local_irq_enable() => turn local IRQs on
local_save_flags(flags) => save the current IRQ state into flags. The
state can be on or off. (on some
architectures there's even more bits in it.)
local_irq_save(flags) => save the current IRQ state into flags and
disable interrupts.
local_irq_restore(flags) => restore the IRQ state from flags.
(local_irq_save can save both irqs on and irqs off state, and
local_irq_restore can restore into both irqs on and irqs off state.)
another related change is that synchronize_irq() now takes a parameter:
synchronize_irq(irq). This change too has the purpose of making SMP
synchronization more lightweight - this way you can wait for your own
interrupt handler to finish, no need to wait for other IRQ sources.
why were these changes done? The main reason was the architectural burden
of maintaining the cli()/sti() interface - it became a real problem. The
new interrupt system is much more streamlined, easier to understand, debug,
and it's also a bit faster - the same happened to it that will happen to
cli()/sti() using drivers once they convert to spinlocks :-)
Documentation/connector/Makefile
+11
View File
@@ -0,0 +1,11 @@
ifneq ($(CONFIG_CONNECTOR),)
obj-m += cn_test.o
endif
# List of programs to build
hostprogs-y := ucon
# Tell kbuild to always build the programs
always := $(hostprogs-y)
HOSTCFLAGS_ucon.o += -I$(objtree)/usr/include

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