提交 86d68898 编写于 作者: J James Morris

Merge branch 'master' into next

要显示的变更太多。

To preserve performance only 1000 of 1000+ files are displayed.
...@@ -89,8 +89,6 @@ cciss.txt ...@@ -89,8 +89,6 @@ cciss.txt
- info, major/minor #'s for Compaq's SMART Array Controllers. - info, major/minor #'s for Compaq's SMART Array Controllers.
cdrom/ cdrom/
- directory with information on the CD-ROM drivers that Linux has. - directory with information on the CD-ROM drivers that Linux has.
cli-sti-removal.txt
- cli()/sti() removal guide.
computone.txt computone.txt
- info on Computone Intelliport II/Plus Multiport Serial Driver. - info on Computone Intelliport II/Plus Multiport Serial Driver.
connector/ connector/
......
...@@ -12,7 +12,7 @@ DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \ ...@@ -12,7 +12,7 @@ DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \
kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \ kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \
gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \ gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
genericirq.xml s390-drivers.xml uio-howto.xml scsi.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): # The build process is as follows (targets):
...@@ -102,6 +102,13 @@ C-procfs-example = procfs_example.xml ...@@ -102,6 +102,13 @@ C-procfs-example = procfs_example.xml
C-procfs-example2 = $(addprefix $(obj)/,$(C-procfs-example)) C-procfs-example2 = $(addprefix $(obj)/,$(C-procfs-example))
$(obj)/procfs-guide.xml: $(C-procfs-example2) $(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 ***"; \ notfoundtemplate = echo "*** You have to install docbook-utils or xmlto ***"; \
exit 1 exit 1
db2xtemplate = db2TYPE -o $(dir $@) $< db2xtemplate = db2TYPE -o $(dir $@) $<
......
...@@ -189,8 +189,6 @@ static int __init init_procfs_example(void) ...@@ -189,8 +189,6 @@ static int __init init_procfs_example(void)
return 0; return 0;
no_symlink: no_symlink:
remove_proc_entry("tty", example_dir);
no_tty:
remove_proc_entry("bar", example_dir); remove_proc_entry("bar", example_dir);
no_bar: no_bar:
remove_proc_entry("foo", example_dir); remove_proc_entry("foo", example_dir);
...@@ -206,7 +204,6 @@ static int __init init_procfs_example(void) ...@@ -206,7 +204,6 @@ static int __init init_procfs_example(void)
static void __exit cleanup_procfs_example(void) static void __exit cleanup_procfs_example(void)
{ {
remove_proc_entry("jiffies_too", example_dir); remove_proc_entry("jiffies_too", example_dir);
remove_proc_entry("tty", example_dir);
remove_proc_entry("bar", example_dir); remove_proc_entry("bar", example_dir);
remove_proc_entry("foo", example_dir); remove_proc_entry("foo", example_dir);
remove_proc_entry("jiffies", example_dir); remove_proc_entry("jiffies", example_dir);
...@@ -222,3 +219,4 @@ module_exit(cleanup_procfs_example); ...@@ -222,3 +219,4 @@ module_exit(cleanup_procfs_example);
MODULE_AUTHOR("Erik Mouw"); MODULE_AUTHOR("Erik Mouw");
MODULE_DESCRIPTION("procfs examples"); MODULE_DESCRIPTION("procfs examples");
MODULE_LICENSE("GPL");
...@@ -100,7 +100,7 @@ ...@@ -100,7 +100,7 @@
the hardware structures represented here, please consult the Principles the hardware structures represented here, please consult the Principles
of Operation. of Operation.
</para> </para>
!Iinclude/asm-s390/cio.h !Iarch/s390/include/asm/cio.h
</sect1> </sect1>
<sect1 id="ccwdev"> <sect1 id="ccwdev">
<title>ccw devices</title> <title>ccw devices</title>
...@@ -114,7 +114,7 @@ ...@@ -114,7 +114,7 @@
ccw device structure. Device drivers must not bypass those functions ccw device structure. Device drivers must not bypass those functions
or strange side effects may happen. or strange side effects may happen.
</para> </para>
!Iinclude/asm-s390/ccwdev.h !Iarch/s390/include/asm/ccwdev.h
!Edrivers/s390/cio/device.c !Edrivers/s390/cio/device.c
!Edrivers/s390/cio/device_ops.c !Edrivers/s390/cio/device_ops.c
</sect1> </sect1>
...@@ -125,7 +125,7 @@ ...@@ -125,7 +125,7 @@
measurement data which is made available by the channel subsystem measurement data which is made available by the channel subsystem
for each channel attached device. for each channel attached device.
</para> </para>
!Iinclude/asm-s390/cmb.h !Iarch/s390/include/asm/cmb.h
!Edrivers/s390/cio/cmf.c !Edrivers/s390/cio/cmf.c
</sect1> </sect1>
</chapter> </chapter>
...@@ -142,7 +142,7 @@ ...@@ -142,7 +142,7 @@
</para> </para>
<sect1 id="ccwgroupdevices"> <sect1 id="ccwgroupdevices">
<title>ccw group devices</title> <title>ccw group devices</title>
!Iinclude/asm-s390/ccwgroup.h !Iarch/s390/include/asm/ccwgroup.h
!Edrivers/s390/cio/ccwgroup.c !Edrivers/s390/cio/ccwgroup.c
</sect1> </sect1>
</chapter> </chapter>
......
<?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>
...@@ -1648,7 +1648,7 @@ static struct video_buffer capture_fb; ...@@ -1648,7 +1648,7 @@ static struct video_buffer capture_fb;
<chapter id="pubfunctions"> <chapter id="pubfunctions">
<title>Public Functions Provided</title> <title>Public Functions Provided</title>
!Edrivers/media/video/videodev.c !Edrivers/media/video/v4l2-dev.c
</chapter> </chapter>
</book> </book>
...@@ -69,12 +69,6 @@ ...@@ -69,12 +69,6 @@
device to be used as both a tty interface and as a synchronous device to be used as both a tty interface and as a synchronous
controller is a project for Linux post the 2.4 release controller is a project for Linux post the 2.4 release
</para> </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>
<chapter id="Driver_Modes"> <chapter id="Driver_Modes">
...@@ -179,35 +173,27 @@ ...@@ -179,35 +173,27 @@
<para> <para>
If you wish to use the network interface facilities of the driver, 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 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 you need to follow some additional plumbing rules. They may seem
complex but a look at the example hostess_sv11 driver should complex but a look at the example hostess_sv11 driver should
reassure you. reassure you.
</para> </para>
<para> <para>
The network device used for each channel should be pointed to by 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 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 able to find your private data from this.
sync ppp layer the private data must start with a void * pointer
to the syncppp structures.
</para> </para>
<para> <para>
The way most drivers approach this particular problem is to The way most drivers approach this particular problem is to
create a structure holding the Z8530 device definition and create a structure holding the Z8530 device definition and
put that and the syncppp pointer into the private field of put that into the private field of the network device. The
the network device. The network device fields of the channels network device fields of the channels then point back to the
then point back to the network devices. The ppp_device can also network devices.
be put in the private structure conveniently.
</para> </para>
<para> <para>
If you wish to use the synchronous ppp then you need to attach If you wish to use the generic HDLC then you need to register
the syncppp layer to the network device. You should do this before the HDLC device.
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.
</para> </para>
<para> <para>
Before you register your network device you will also need to Before you register your network device you will also need to
...@@ -314,10 +300,10 @@ ...@@ -314,10 +300,10 @@
buffer in sk_buff format and queues it for transmission. The buffer in sk_buff format and queues it for transmission. The
caller must provide the entire packet with the exception of the caller must provide the entire packet with the exception of the
bitstuffing and CRC. This is normally done by the caller via bitstuffing and CRC. This is normally done by the caller via
the syncppp interface layer. It returns 0 if the buffer has been 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 queued and non zero values for queue full. If the function accepts
the buffer it becomes property of the Z8530 layer and the caller the buffer it becomes property of the Z8530 layer and the caller
should not free it. should not free it.
</para> </para>
<para> <para>
The function <function>z8530_get_stats</function> returns a pointer The function <function>z8530_get_stats</function> returns a pointer
......
obj-m := DocBook/ accounting/ auxdisplay/ connector/ \
filesystems/configfs/ ia64/ networking/ \
pcmcia/ spi/ video4linux/ vm/ watchdog/src/
# 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
...@@ -201,13 +201,19 @@ void print_delayacct(struct taskstats *t) ...@@ -201,13 +201,19 @@ void print_delayacct(struct taskstats *t)
"RECLAIM %12s%15s\n" "RECLAIM %12s%15s\n"
" %15llu%15llu\n", " %15llu%15llu\n",
"count", "real total", "virtual total", "delay total", "count", "real total", "virtual total", "delay total",
t->cpu_count, t->cpu_run_real_total, t->cpu_run_virtual_total, (unsigned long long)t->cpu_count,
t->cpu_delay_total, (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", "count", "delay total",
t->blkio_count, t->blkio_delay_total, (unsigned long long)t->blkio_count,
"count", "delay total", t->swapin_count, t->swapin_delay_total, (unsigned long long)t->blkio_delay_total,
"count", "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) void task_context_switch_counts(struct taskstats *t)
...@@ -215,14 +221,17 @@ 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" printf("\n\nTask %15s%15s\n"
" %15llu%15llu\n", " %15llu%15llu\n",
"voluntary", "nonvoluntary", "voluntary", "nonvoluntary",
t->nvcsw, t->nivcsw); (unsigned long long)t->nvcsw, (unsigned long long)t->nivcsw);
} }
void print_cgroupstats(struct cgroupstats *c) void print_cgroupstats(struct cgroupstats *c)
{ {
printf("sleeping %llu, blocked %llu, running %llu, stopped %llu, " printf("sleeping %llu, blocked %llu, running %llu, stopped %llu, "
"uninterruptible %llu\n", c->nr_sleeping, c->nr_io_wait, "uninterruptible %llu\n", (unsigned long long)c->nr_sleeping,
c->nr_running, c->nr_stopped, c->nr_uninterruptible); (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);
} }
......
...@@ -32,7 +32,7 @@ Linux currently supports the following features on the IXP4xx chips: ...@@ -32,7 +32,7 @@ Linux currently supports the following features on the IXP4xx chips:
- Flash access (MTD/JFFS) - Flash access (MTD/JFFS)
- I2C through GPIO on IXP42x - I2C through GPIO on IXP42x
- GPIO for input/output/interrupts - 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) - Timers (watchdog, OS)
The following components of the chips are not supported by Linux and The following components of the chips are not supported by Linux and
......
...@@ -158,7 +158,7 @@ So, what's changed? ...@@ -158,7 +158,7 @@ So, what's changed?
be re-checked for pending events. (see the Neponset IRQ handler for be re-checked for pending events. (see the Neponset IRQ handler for
details). 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 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 hardware based. Mixing level-based and edge-based IRQs on the same
......
...@@ -79,7 +79,7 @@ Machine/Platform support ...@@ -79,7 +79,7 @@ Machine/Platform support
To this end, we now have arch/arm/mach-$(MACHINE) directories which are 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, designed to house the non-driver files for a particular machine (eg, PCI,
memory management, architecture definitions etc). For all future 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. directory.
...@@ -176,7 +176,7 @@ Kernel entry (head.S) ...@@ -176,7 +176,7 @@ Kernel entry (head.S)
class typically based around one or more system on a chip devices, and class typically based around one or more system on a chip devices, and
acts as a natural container around the actual implementations. These acts as a natural container around the actual implementations. These
classes are given directories - arch/arm/mach-<class> and 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 support the machine class. This directories also contain any machine
specific supporting code. specific supporting code.
......
...@@ -13,16 +13,31 @@ Introduction ...@@ -13,16 +13,31 @@ Introduction
data-sheet/users manual to find out the complete list. 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 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 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 The GPIO management functions are defined in the hardware
header include/asm-arm/arch-s3c2410/hardware.h which can be header arch/arm/mach-s3c2410/include/mach/hardware.h which can be
included by #include <asm/arch/hardware.h> included by #include <mach/hardware.h>
A useful amount 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. header on how the GPIO functions (and others) work.
......
...@@ -8,9 +8,10 @@ Introduction ...@@ -8,9 +8,10 @@ Introduction
The Samsung S3C24XX range of ARM9 System-on-Chip CPUs are supported The Samsung S3C24XX range of ARM9 System-on-Chip CPUs are supported
by the 's3c2410' architecture of ARM Linux. Currently the S3C2410, 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 Configuration
------------- -------------
...@@ -36,7 +37,23 @@ Layout ...@@ -36,7 +37,23 @@ Layout
in arch/arm/mach-s3c2410 and S3C2440 in arch/arm/mach-s3c2440 in arch/arm/mach-s3c2410 and S3C2440 in arch/arm/mach-s3c2440
Register, kernel and platform data definitions are held in the 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 Machines
...@@ -159,6 +176,17 @@ NAND ...@@ -159,6 +176,17 @@ NAND
For more information see Documentation/arm/Samsung-S3C24XX/NAND.txt 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 Serial
------ ------
...@@ -178,6 +206,9 @@ GPIO ...@@ -178,6 +206,9 @@ GPIO
The core contains support for manipulating the GPIO, see the The core contains support for manipulating the GPIO, see the
documentation in GPIO.txt in the same directory as this file. 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 Clock Management
---------------- ----------------
......
...@@ -49,7 +49,7 @@ Board Support ...@@ -49,7 +49,7 @@ Board Support
Platform Data 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 descriptions of the platform device data. An implementation
can be found in linux/arch/arm/mach-s3c2410/usb-simtec.c . can be found in linux/arch/arm/mach-s3c2410/usb-simtec.c .
......
# 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
...@@ -112,27 +112,18 @@ Hot plug support for SCSI tape drives ...@@ -112,27 +112,18 @@ Hot plug support for SCSI tape drives
Hot plugging of SCSI tape drives is supported, with some caveats. Hot plugging of SCSI tape drives is supported, with some caveats.
The cciss driver must be informed that changes to the SCSI bus The cciss driver must be informed that changes to the SCSI bus
have been made, in addition to and prior to informing the SCSI have been made. This may be done via the /proc filesystem.
mid layer. This may be done via the /proc filesystem. For example: For example:
echo "rescan" > /proc/scsi/cciss0/1 echo "rescan" > /proc/scsi/cciss0/1
This causes the adapter to query the adapter about changes to the This causes the driver to query the adapter about changes to the
physical SCSI buses and/or fibre channel arbitrated loop and the physical SCSI buses and/or fibre channel arbitrated loop and the
driver to make note of any new or removed sequential access devices driver to make note of any new or removed sequential access devices
or medium changers. The driver will output messages indicating what or medium changers. The driver will output messages indicating what
devices have been added or removed and the controller, bus, target and 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 lun used to address the device. It then notifies the SCSI mid layer
can be informed of changes to the virtual SCSI bus which the driver of these changes.
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.
Note that the naming convention of the /proc filesystem entries Note that the naming convention of the /proc filesystem entries
contains a number in addition to the driver name. (E.g. "cciss0" contains a number in addition to the driver name. (E.g. "cciss0"
......
#### 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 :-)
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
...@@ -59,15 +59,10 @@ apicid values in those tables for disabled apics. In the event BIOS doesn't ...@@ -59,15 +59,10 @@ apicid values in those tables for disabled apics. In the event BIOS doesn't
mark such hot-pluggable cpus as disabled entries, one could use this mark such hot-pluggable cpus as disabled entries, one could use this
parameter "additional_cpus=x" to represent those cpus in the cpu_possible_map. parameter "additional_cpus=x" to represent those cpus in the cpu_possible_map.
s390 uses the number of cpus it detects at IPL time to also the number of bits
in cpu_possible_map. If it is desired to add additional cpus at a later time
the number should be specified using this option or the possible_cpus option.
possible_cpus=n [s390 only] use this to set hotpluggable cpus. possible_cpus=n [s390 only] use this to set hotpluggable cpus.
This option sets possible_cpus bits in This option sets possible_cpus bits in
cpu_possible_map. Thus keeping the numbers of bits set cpu_possible_map. Thus keeping the numbers of bits set
constant even if the machine gets rebooted. constant even if the machine gets rebooted.
This option overrides additional_cpus.
CPU maps and such CPU maps and such
----------------- -----------------
......
...@@ -2560,9 +2560,6 @@ Your cooperation is appreciated. ...@@ -2560,9 +2560,6 @@ Your cooperation is appreciated.
96 = /dev/usb/hiddev0 1st USB HID device 96 = /dev/usb/hiddev0 1st USB HID device
... ...
111 = /dev/usb/hiddev15 16th USB HID device 111 = /dev/usb/hiddev15 16th USB HID device
112 = /dev/usb/auer0 1st auerswald ISDN device
...
127 = /dev/usb/auer15 16th auerswald ISDN device
128 = /dev/usb/brlvgr0 First Braille Voyager device 128 = /dev/usb/brlvgr0 First Braille Voyager device
... ...
131 = /dev/usb/brlvgr3 Fourth Braille Voyager device 131 = /dev/usb/brlvgr3 Fourth Braille Voyager device
......
...@@ -19,15 +19,6 @@ Who: Pavel Machek <pavel@suse.cz> ...@@ -19,15 +19,6 @@ Who: Pavel Machek <pavel@suse.cz>
--------------------------- ---------------------------
What: old NCR53C9x driver
When: October 2007
Why: Replaced by the much better esp_scsi driver. Actual low-level
driver can be ported over almost trivially.
Who: David Miller <davem@davemloft.net>
Christoph Hellwig <hch@lst.de>
---------------------------
What: Video4Linux API 1 ioctls and video_decoder.h from Video devices. What: Video4Linux API 1 ioctls and video_decoder.h from Video devices.
When: December 2008 When: December 2008
Files: include/linux/video_decoder.h include/linux/videodev.h Files: include/linux/video_decoder.h include/linux/videodev.h
...@@ -205,19 +196,6 @@ Who: Tejun Heo <htejun@gmail.com> ...@@ -205,19 +196,6 @@ Who: Tejun Heo <htejun@gmail.com>
--------------------------- ---------------------------
What: The arch/ppc and include/asm-ppc directories
When: Jun 2008
Why: The arch/powerpc tree is the merged architecture for ppc32 and ppc64
platforms. Currently there are efforts underway to port the remaining
arch/ppc platforms to the merged tree. New submissions to the arch/ppc
tree have been frozen with the 2.6.22 kernel release and that tree will
remain in bug-fix only mode until its scheduled removal. Platforms
that are not ported by June 2008 will be removed due to the lack of an
interested maintainer.
Who: linuxppc-dev@ozlabs.org
---------------------------
What: i386/x86_64 bzImage symlinks What: i386/x86_64 bzImage symlinks
When: April 2010 When: April 2010
......
ifneq ($(CONFIG_CONFIGFS_FS),)
obj-m += configfs_example_explicit.o configfs_example_macros.o
endif
...@@ -26,6 +26,12 @@ Mailing list: linux-ext4@vger.kernel.org ...@@ -26,6 +26,12 @@ Mailing list: linux-ext4@vger.kernel.org
git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git
- Note that it is highly important to install the mke2fs.conf file
that comes with the e2fsprogs 1.41.x sources in /etc/mke2fs.conf. If
you have edited the /etc/mke2fs.conf file installed on your system,
you will need to merge your changes with the version from e2fsprogs
1.41.x.
- Create a new filesystem using the ext4dev filesystem type: - Create a new filesystem using the ext4dev filesystem type:
# mke2fs -t ext4dev /dev/hda1 # mke2fs -t ext4dev /dev/hda1
......
...@@ -3,14 +3,14 @@ Quota subsystem ...@@ -3,14 +3,14 @@ Quota subsystem
=============== ===============
Quota subsystem allows system administrator to set limits on used space and Quota subsystem allows system administrator to set limits on used space and
number of used inodes (inode is a filesystem structure which is associated number of used inodes (inode is a filesystem structure which is associated with
with each file or directory) for users and/or groups. For both used space and each file or directory) for users and/or groups. For both used space and number
number of used inodes there are actually two limits. The first one is called of used inodes there are actually two limits. The first one is called softlimit
softlimit and the second one hardlimit. An user can never exceed a hardlimit and the second one hardlimit. An user can never exceed a hardlimit for any
for any resource. User is allowed to exceed softlimit but only for limited resource (unless he has CAP_SYS_RESOURCE capability). User is allowed to exceed
period of time. This period is called "grace period" or "grace time". When softlimit but only for limited period of time. This period is called "grace
grace time is over, user is not able to allocate more space/inodes until he period" or "grace time". When grace time is over, user is not able to allocate
frees enough of them to get below softlimit. more space/inodes until he frees enough of them to get below softlimit.
Quota limits (and amount of grace time) are set independently for each Quota limits (and amount of grace time) are set independently for each
filesystem. filesystem.
...@@ -53,6 +53,12 @@ in parentheses): ...@@ -53,6 +53,12 @@ in parentheses):
QUOTA_NL_BSOFTLONGWARN - space (block) softlimit is exceeded QUOTA_NL_BSOFTLONGWARN - space (block) softlimit is exceeded
longer than given grace period. longer than given grace period.
QUOTA_NL_BSOFTWARN - space (block) softlimit QUOTA_NL_BSOFTWARN - space (block) softlimit
- four warnings are also defined for the event when user stops
exceeding some limit:
QUOTA_NL_IHARDBELOW - inode hardlimit
QUOTA_NL_ISOFTBELOW - inode softlimit
QUOTA_NL_BHARDBELOW - space (block) hardlimit
QUOTA_NL_BSOFTBELOW - space (block) softlimit
QUOTA_NL_A_DEV_MAJOR (u32) QUOTA_NL_A_DEV_MAJOR (u32)
- major number of a device with the affected filesystem - major number of a device with the affected filesystem
QUOTA_NL_A_DEV_MINOR (u32) QUOTA_NL_A_DEV_MINOR (u32)
......
...@@ -57,7 +57,7 @@ Similarly to JFFS2, UBIFS supports on-the-flight compression which makes ...@@ -57,7 +57,7 @@ Similarly to JFFS2, UBIFS supports on-the-flight compression which makes
it possible to fit quite a lot of data to the flash. it possible to fit quite a lot of data to the flash.
Similarly to JFFS2, UBIFS is tolerant of unclean reboots and power-cuts. Similarly to JFFS2, UBIFS is tolerant of unclean reboots and power-cuts.
It does not need stuff like ckfs.ext2. UBIFS automatically replays its It does not need stuff like fsck.ext2. UBIFS automatically replays its
journal and recovers from crashes, ensuring that the on-flash data journal and recovers from crashes, ensuring that the on-flash data
structures are consistent. structures are consistent.
......
...@@ -10,6 +10,10 @@ Supported chips: ...@@ -10,6 +10,10 @@ Supported chips:
Prefix: 'sch311x' Prefix: 'sch311x'
Addresses scanned: none, address read from Super-I/O config space Addresses scanned: none, address read from Super-I/O config space
Datasheet: http://www.nuhorizons.com/FeaturedProducts/Volume1/SMSC/311x.pdf Datasheet: http://www.nuhorizons.com/FeaturedProducts/Volume1/SMSC/311x.pdf
* SMSC SCH5027
Prefix: 'sch5027'
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
Datasheet: Provided by SMSC upon request and under NDA
Authors: Authors:
Juerg Haefliger <juergh@gmail.com> Juerg Haefliger <juergh@gmail.com>
...@@ -27,33 +31,31 @@ Module Parameters ...@@ -27,33 +31,31 @@ Module Parameters
following boards: following boards:
- VIA EPIA SN18000 - VIA EPIA SN18000
Note that there is no need to use this parameter if the driver loads without
complaining. The driver will say so if it is necessary.
Description Description
----------- -----------
This driver implements support for the hardware monitoring capabilities of the This driver implements support for the hardware monitoring capabilities of the
SMSC DME1737 and Asus A8000 (which are the same) and SMSC SCH311x Super-I/O SMSC DME1737 and Asus A8000 (which are the same), SMSC SCH5027, and SMSC
chips. These chips feature monitoring of 3 temp sensors temp[1-3] (2 remote SCH311x Super-I/O chips. These chips feature monitoring of 3 temp sensors
diodes and 1 internal), 7 voltages in[0-6] (6 external and 1 internal) and up temp[1-3] (2 remote diodes and 1 internal), 7 voltages in[0-6] (6 external and
to 6 fan speeds fan[1-6]. Additionally, the chips implement up to 5 PWM 1 internal) and up to 6 fan speeds fan[1-6]. Additionally, the chips implement
outputs pwm[1-3,5-6] for controlling fan speeds both manually and up to 5 PWM outputs pwm[1-3,5-6] for controlling fan speeds both manually and
automatically. automatically.
For the DME1737 and A8000, fan[1-2] and pwm[1-2] are always present. Fan[3-6] For the DME1737, A8000 and SCH5027, fan[1-2] and pwm[1-2] are always present.
and pwm[3,5-6] are optional features and their availability depends on the Fan[3-6] and pwm[3,5-6] are optional features and their availability depends on
configuration of the chip. The driver will detect which features are present the configuration of the chip. The driver will detect which features are
during initialization and create the sysfs attributes accordingly. present during initialization and create the sysfs attributes accordingly.
For the SCH311x, fan[1-3] and pwm[1-3] are always present and fan[4-6] and For the SCH311x, fan[1-3] and pwm[1-3] are always present and fan[4-6] and
pwm[5-6] don't exist. pwm[5-6] don't exist.
The hardware monitoring features of the DME1737 and A8000 are only accessible The hardware monitoring features of the DME1737, A8000, and SCH5027 are only
via SMBus, while the SCH311x only provides access via the ISA bus. The driver accessible via SMBus, while the SCH311x only provides access via the ISA bus.
will therefore register itself as an I2C client driver if it detects a DME1737 The driver will therefore register itself as an I2C client driver if it detects
or A8000 and as a platform driver if it detects a SCH311x chip. a DME1737, A8000, or SCH5027 and as a platform driver if it detects a SCH311x
chip.
Voltage Monitoring Voltage Monitoring
...@@ -64,6 +66,7 @@ scaling resistors. The values returned by the driver therefore reflect true ...@@ -64,6 +66,7 @@ scaling resistors. The values returned by the driver therefore reflect true
millivolts and don't need scaling. The voltage inputs are mapped as follows millivolts and don't need scaling. The voltage inputs are mapped as follows
(the last column indicates the input ranges): (the last column indicates the input ranges):
DME1737, A8000:
in0: +5VTR (+5V standby) 0V - 6.64V in0: +5VTR (+5V standby) 0V - 6.64V
in1: Vccp (processor core) 0V - 3V in1: Vccp (processor core) 0V - 3V
in2: VCC (internal +3.3V) 0V - 4.38V in2: VCC (internal +3.3V) 0V - 4.38V
...@@ -72,6 +75,24 @@ millivolts and don't need scaling. The voltage inputs are mapped as follows ...@@ -72,6 +75,24 @@ millivolts and don't need scaling. The voltage inputs are mapped as follows
in5: VTR (+3.3V standby) 0V - 4.38V in5: VTR (+3.3V standby) 0V - 4.38V
in6: Vbat (+3.0V) 0V - 4.38V in6: Vbat (+3.0V) 0V - 4.38V
SCH311x:
in0: +2.5V 0V - 6.64V
in1: Vccp (processor core) 0V - 2V
in2: VCC (internal +3.3V) 0V - 4.38V
in3: +5V 0V - 6.64V
in4: +12V 0V - 16V
in5: VTR (+3.3V standby) 0V - 4.38V
in6: Vbat (+3.0V) 0V - 4.38V
SCH5027:
in0: +5VTR (+5V standby) 0V - 6.64V
in1: Vccp (processor core) 0V - 3V
in2: VCC (internal +3.3V) 0V - 4.38V
in3: V2_IN 0V - 1.5V
in4: V1_IN 0V - 1.5V
in5: VTR (+3.3V standby) 0V - 4.38V
in6: Vbat (+3.0V) 0V - 4.38V
Each voltage input has associated min and max limits which trigger an alarm Each voltage input has associated min and max limits which trigger an alarm
when crossed. when crossed.
......
Kernel driver ibmaem Kernel driver ibmaem
====================== ======================
This driver talks to the IBM Systems Director Active Energy Manager, known
henceforth as AEM.
Supported systems: Supported systems:
* Any recent IBM System X server with Active Energy Manager support. * Any recent IBM System X server with AEM support.
This includes the x3350, x3550, x3650, x3655, x3755, x3850 M2, This includes the x3350, x3550, x3650, x3655, x3755, x3850 M2,
x3950 M2, and certain HS2x/LS2x/QS2x blades. The IPMI host interface x3950 M2, and certain HS2x/LS2x/QS2x blades. The IPMI host interface
driver ("ipmi-si") needs to be loaded for this driver to do anything. driver ("ipmi-si") needs to be loaded for this driver to do anything.
...@@ -14,24 +17,22 @@ Author: Darrick J. Wong ...@@ -14,24 +17,22 @@ Author: Darrick J. Wong
Description Description
----------- -----------
This driver implements sensor reading support for the energy and power This driver implements sensor reading support for the energy and power meters
meters available on various IBM System X hardware through the BMC. All available on various IBM System X hardware through the BMC. All sensor banks
sensor banks will be exported as platform devices; this driver can talk will be exported as platform devices; this driver can talk to both v1 and v2
to both v1 and v2 interfaces. This driver is completely separate from the interfaces. This driver is completely separate from the older ibmpex driver.
older ibmpex driver.
The v1 AEM interface has a simple set of features to monitor energy use. The v1 AEM interface has a simple set of features to monitor energy use. There
There is a register that displays an estimate of raw energy consumption is a register that displays an estimate of raw energy consumption since the
since the last BMC reset, and a power sensor that returns average power last BMC reset, and a power sensor that returns average power use over a
use over a configurable interval. configurable interval.
The v2 AEM interface is a bit more sophisticated, being able to present The v2 AEM interface is a bit more sophisticated, being able to present a wider
a wider range of energy and power use registers, the power cap as range of energy and power use registers, the power cap as set by the AEM
set by the AEM software, and temperature sensors. software, and temperature sensors.
Special Features Special Features
---------------- ----------------
The "power_cap" value displays the current system power cap, as set by The "power_cap" value displays the current system power cap, as set by the AEM
the Active Energy Manager software. Setting the power cap from the host software. Setting the power cap from the host is not currently supported.
is not currently supported.
...@@ -6,12 +6,14 @@ Supported chips: ...@@ -6,12 +6,14 @@ Supported chips:
Prefix: 'it87' Prefix: 'it87'
Addresses scanned: from Super I/O config space (8 I/O ports) Addresses scanned: from Super I/O config space (8 I/O ports)
Datasheet: Publicly available at the ITE website Datasheet: Publicly available at the ITE website
http://www.ite.com.tw/ http://www.ite.com.tw/product_info/file/pc/IT8705F_V.0.4.1.pdf
* IT8712F * IT8712F
Prefix: 'it8712' Prefix: 'it8712'
Addresses scanned: from Super I/O config space (8 I/O ports) Addresses scanned: from Super I/O config space (8 I/O ports)
Datasheet: Publicly available at the ITE website Datasheet: Publicly available at the ITE website
http://www.ite.com.tw/ http://www.ite.com.tw/product_info/file/pc/IT8712F_V0.9.1.pdf
http://www.ite.com.tw/product_info/file/pc/Errata%20V0.1%20for%20IT8712F%20V0.9.1.pdf
http://www.ite.com.tw/product_info/file/pc/IT8712F_V0.9.3.pdf
* IT8716F/IT8726F * IT8716F/IT8726F
Prefix: 'it8716' Prefix: 'it8716'
Addresses scanned: from Super I/O config space (8 I/O ports) Addresses scanned: from Super I/O config space (8 I/O ports)
...@@ -90,14 +92,13 @@ upper VID bits share their pins with voltage inputs (in5 and in6) so you ...@@ -90,14 +92,13 @@ upper VID bits share their pins with voltage inputs (in5 and in6) so you
can't have both on a given board. can't have both on a given board.
The IT8716F, IT8718F and later IT8712F revisions have support for The IT8716F, IT8718F and later IT8712F revisions have support for
2 additional fans. They are supported by the driver for the IT8716F and 2 additional fans. The additional fans are supported by the driver.
IT8718F but not for the IT8712F
The IT8716F and IT8718F, and late IT8712F and IT8705F also have optional The IT8716F and IT8718F, and late IT8712F and IT8705F also have optional
16-bit tachometer counters for fans 1 to 3. This is better (no more fan 16-bit tachometer counters for fans 1 to 3. This is better (no more fan
clock divider mess) but not compatible with the older chips and clock divider mess) but not compatible with the older chips and
revisions. For now, the driver only uses the 16-bit mode on the revisions. The 16-bit tachometer mode is enabled by the driver when one
IT8716F and IT8718F. of the above chips is detected.
The IT8726F is just bit enhanced IT8716F with additional hardware The IT8726F is just bit enhanced IT8716F with additional hardware
for AMD power sequencing. Therefore the chip will appear as IT8716F for AMD power sequencing. Therefore the chip will appear as IT8716F
......
...@@ -40,10 +40,6 @@ Module Parameters ...@@ -40,10 +40,6 @@ Module Parameters
(default is 1) (default is 1)
Use 'init=0' to bypass initializing the chip. Use 'init=0' to bypass initializing the chip.
Try this if your computer crashes when you load the module. Try this if your computer crashes when you load the module.
* reset: int
(default is 0)
The driver used to reset the chip on load, but does no more. Use
'reset=1' to restore the old behavior. Report if you need to do this.
Description Description
----------- -----------
......
...@@ -22,6 +22,7 @@ Credits: ...@@ -22,6 +22,7 @@ Credits:
Additional contributors: Additional contributors:
Sven Anders <anders@anduras.de> Sven Anders <anders@anduras.de>
Marc Hulsman <m.hulsman@tudelft.nl>
Module Parameters Module Parameters
----------------- -----------------
...@@ -67,9 +68,8 @@ on until the temperature falls below the Hysteresis value. ...@@ -67,9 +68,8 @@ on until the temperature falls below the Hysteresis value.
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit. Fan triggered if the rotation speed has dropped below a programmable limit. Fan
readings can be divided by a programmable divider (1, 2, 4, 8 for fan 1/2/3 readings can be divided by a programmable divider (1, 2, 4, 8, 16,
and 1, 2, 4, 8, 16, 32, 64 or 128 for fan 4/5) to give the readings more 32, 64 or 128 for all fans) to give the readings more range or accuracy.
range or accuracy.
Voltage sensors (also known as IN sensors) report their values in millivolts. Voltage sensors (also known as IN sensors) report their values in millivolts.
An alarm is triggered if the voltage has crossed a programmable minimum An alarm is triggered if the voltage has crossed a programmable minimum
......
# kbuild trick to avoid linker error. Can be omitted if a module is built.
obj- := dummy.o
# List of programs to build
hostprogs-y := aliasing-test
# Tell kbuild to always build the programs
always := $(hostprogs-y)
...@@ -105,7 +105,6 @@ Code Seq# Include File Comments ...@@ -105,7 +105,6 @@ Code Seq# Include File Comments
'T' all linux/soundcard.h conflict! 'T' all linux/soundcard.h conflict!
'T' all asm-i386/ioctls.h conflict! 'T' all asm-i386/ioctls.h conflict!
'U' 00-EF linux/drivers/usb/usb.h 'U' 00-EF linux/drivers/usb/usb.h
'U' F0-FF drivers/usb/auerswald.c
'V' all linux/vt.h 'V' all linux/vt.h
'W' 00-1F linux/watchdog.h conflict! 'W' 00-1F linux/watchdog.h conflict!
'W' 00-1F linux/wanrouter.h conflict! 'W' 00-1F linux/wanrouter.h conflict!
......
...@@ -11,14 +11,14 @@ for non English (read: Japanese) speakers and is not intended as a ...@@ -11,14 +11,14 @@ for non English (read: Japanese) speakers and is not intended as a
fork. So if you have any comments or updates for this file, please try fork. So if you have any comments or updates for this file, please try
to update the original English file first. to update the original English file first.
Last Updated: 2007/11/16 Last Updated: 2008/08/21
================================== ==================================
これは、 これは、
linux-2.6.24/Documentation/HOWTO linux-2.6.27/Documentation/HOWTO
の和訳です。 の和訳です。
翻訳団体: JF プロジェクト < http://www.linux.or.jp/JF/ > 翻訳団体: JF プロジェクト < http://www.linux.or.jp/JF/ >
翻訳日: 2007/11/10 翻訳日: 2008/8/5
翻訳者: Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com> 翻訳者: Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com>
校正者: 松倉さん <nbh--mats at nifty dot com> 校正者: 松倉さん <nbh--mats at nifty dot com>
小林 雅典さん (Masanori Kobayasi) <zap03216 at nifty dot ne dot jp> 小林 雅典さん (Masanori Kobayasi) <zap03216 at nifty dot ne dot jp>
...@@ -287,13 +287,15 @@ Linux カーネルの開発プロセスは現在幾つかの異なるメイン ...@@ -287,13 +287,15 @@ Linux カーネルの開発プロセスは現在幾つかの異なるメイン
に安定した状態にあると判断したときにリリースされます。目標は毎週新 に安定した状態にあると判断したときにリリースされます。目標は毎週新
しい -rc カーネルをリリースすることです。 しい -rc カーネルをリリースすることです。
- 以下の URL で各 -rc リリースに存在する既知の後戻り問題のリスト
が追跡されます-
http://kernelnewbies.org/known_regressions
- このプロセスはカーネルが 「準備ができた」と考えられるまで継続しま - このプロセスはカーネルが 「準備ができた」と考えられるまで継続しま
す。このプロセスはだいたい 6週間継続します。 す。このプロセスはだいたい 6週間継続します。
- 各リリースでの既知の後戻り問題(regression: このリリースの中で新規
に作り込まれた問題を指す) はその都度 Linux-kernel メーリングリスト
に投稿されます。ゴールとしては、カーネルが 「準備ができた」と宣言
する前にこのリストの長さをゼロに減らすことですが、現実には、数個の
後戻り問題がリリース時にたびたび残ってしまいます。
Andrew Morton が Linux-kernel メーリングリストにカーネルリリースについ Andrew Morton が Linux-kernel メーリングリストにカーネルリリースについ
て書いたことをここで言っておくことは価値があります- て書いたことをここで言っておくことは価値があります-
「カーネルがいつリリースされるかは誰も知りません。なぜなら、これは現 「カーネルがいつリリースされるかは誰も知りません。なぜなら、これは現
...@@ -303,18 +305,20 @@ Andrew Morton が Linux-kernel メーリングリストにカーネルリリー ...@@ -303,18 +305,20 @@ Andrew Morton が Linux-kernel メーリングリストにカーネルリリー
2.6.x.y -stable カーネルツリー 2.6.x.y -stable カーネルツリー
--------------------------- ---------------------------
バージョンに4つ目の数字がついたカーネルは -stable カーネルです。これに バージョン番号が4つの数字に分かれているカーネルは -stable カーネルです。
は、2.6.x カーネルで見つかったセキュリティ問題や重大な後戻りに対する比 これには、2.6.x カーネルで見つかったセキュリティ問題や重大な後戻りに対
較的小さい重要な修正が含まれます。 する比較的小さい重要な修正が含まれます。
これは、開発/実験的バージョンのテストに協力することに興味が無く、 これは、開発/実験的バージョンのテストに協力することに興味が無く、
最新の安定したカーネルを使いたいユーザに推奨するブランチです。 最新の安定したカーネルを使いたいユーザに推奨するブランチです。
もし、2.6.x.y カーネルが存在しない場合には、番号が一番大きい 2.6.x もし、2.6.x.y カーネルが存在しない場合には、番号が一番大きい 2.6.x
最新の安定版カーネルです。 最新の安定版カーネルです。
2.6.x.y は "stable" チーム <stable@kernel.org> でメンテされており、だ 2.6.x.y は "stable" チーム <stable@kernel.org> でメンテされており、必
いたい隔週でリリースされています。 要に応じてリリースされます。通常のリリース期間は 2週間毎ですが、差し迫っ
た問題がなければもう少し長くなることもあります。セキュリティ関連の問題
の場合はこれに対してだいたいの場合、すぐにリリースがされます。
カーネルツリーに入っている、Documentation/stable_kernel_rules.txt ファ カーネルツリーに入っている、Documentation/stable_kernel_rules.txt ファ
イルにはどのような種類の変更が -stable ツリーに受け入れ可能か、またリ イルにはどのような種類の変更が -stable ツリーに受け入れ可能か、またリ
...@@ -341,7 +345,9 @@ linux-kernel メーリングリストで収集された多数のパッチと同 ...@@ -341,7 +345,9 @@ linux-kernel メーリングリストで収集された多数のパッチと同
メインラインへ入れるように Linus にプッシュします。 メインラインへ入れるように Linus にプッシュします。
メインカーネルツリーに含めるために Linus に送る前に、すべての新しいパッ メインカーネルツリーに含めるために Linus に送る前に、すべての新しいパッ
チが -mm ツリーでテストされることが強く推奨されます。 チが -mm ツリーでテストされることが強く推奨されています。マージウィン
ドウが開く前に -mm ツリーに現れなかったパッチはメインラインにマージさ
れることは困難になります。
これらのカーネルは安定して動作すべきシステムとして使うのには適切ではあ これらのカーネルは安定して動作すべきシステムとして使うのには適切ではあ
りませんし、カーネルブランチの中でももっとも動作にリスクが高いものです。 りませんし、カーネルブランチの中でももっとも動作にリスクが高いものです。
...@@ -395,13 +401,15 @@ linux-kernel メーリングリストで収集された多数のパッチと同 ...@@ -395,13 +401,15 @@ linux-kernel メーリングリストで収集された多数のパッチと同
- pcmcia, Dominik Brodowski <linux@dominikbrodowski.net> - pcmcia, Dominik Brodowski <linux@dominikbrodowski.net>
git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
- SCSI, James Bottomley <James.Bottomley@SteelEye.com> - SCSI, James Bottomley <James.Bottomley@hansenpartnership.com>
git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
- x86, Ingo Molnar <mingo@elte.hu>
git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
quilt ツリー- quilt ツリー-
- USB, PCI ドライバコアと I2C, Greg Kroah-Hartman <gregkh@suse.de> - USB, ドライバコアと I2C, Greg Kroah-Hartman <gregkh@suse.de>
kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/ kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
- x86-64 と i386 の仲間 Andi Kleen <ak@suse.de>
その他のカーネルツリーは http://git.kernel.org/ と MAINTAINERS ファ その他のカーネルツリーは http://git.kernel.org/ と MAINTAINERS ファ
イルに一覧表があります。 イルに一覧表があります。
...@@ -412,13 +420,32 @@ linux-kernel メーリングリストで収集された多数のパッチと同 ...@@ -412,13 +420,32 @@ linux-kernel メーリングリストで収集された多数のパッチと同
bugzilla.kernel.org は Linux カーネル開発者がカーネルのバグを追跡する bugzilla.kernel.org は Linux カーネル開発者がカーネルのバグを追跡する
場所です。ユーザは見つけたバグの全てをこのツールで報告すべきです。 場所です。ユーザは見つけたバグの全てをこのツールで報告すべきです。
どう kernel bugzilla を使うかの詳細は、以下を参照してください- どう kernel bugzilla を使うかの詳細は、以下を参照してください-
http://test.kernel.org/bugzilla/faq.html http://bugzilla.kernel.org/page.cgi?id=faq.html
メインカーネルソースディレクトリにあるファイル REPORTING-BUGS はカーネ メインカーネルソースディレクトリにあるファイル REPORTING-BUGS はカーネ
ルバグらしいものについてどうレポートするかの良いテンプレートであり、問 ルバグらしいものについてどうレポートするかの良いテンプレートであり、問
題の追跡を助けるためにカーネル開発者にとってどんな情報が必要なのかの詳 題の追跡を助けるためにカーネル開発者にとってどんな情報が必要なのかの詳
細が書かれています。 細が書かれています。
バグレポートの管理
-------------------
あなたのハッキングのスキルを訓練する最高の方法のひとつに、他人がレポー
トしたバグを修正することがあります。あなたがカーネルをより安定化させる
こに寄与するということだけでなく、あなたは 現実の問題を修正することを
学び、自分のスキルも強化でき、また他の開発者があなたの存在に気がつき
ます。バグを修正することは、多くの開発者の中から自分が功績をあげる最善
の道です、なぜなら多くの人は他人のバグの修正に時間を浪費することを好ま
ないからです。
すでにレポートされたバグのために仕事をするためには、
http://bugzilla.kernel.org に行ってください。もし今後のバグレポートに
ついてアドバイスを受けたいのであれば、bugme-new メーリングリスト(新し
いバグレポートだけがここにメールされる) または bugme-janitor メーリン
グリスト(bugzilla の変更毎にここにメールされる)を購読できます。
http://lists.linux-foundation.org/mailman/listinfo/bugme-new
http://lists.linux-foundation.org/mailman/listinfo/bugme-janitors
メーリングリスト メーリングリスト
------------- -------------
......
NOTE:
This is a version of Documentation/SubmitChecklist into Japanese.
This document is maintained by Takenori Nagano <t-nagano@ah.jp.nec.com>
and the JF Project team <http://www.linux.or.jp/JF/>.
If you find any difference between this document and the original file
or a problem with the translation,
please contact the maintainer of this file or JF project.
Please also note that the purpose of this file is to be easier to read
for non English (read: Japanese) speakers and is not intended as a
fork. So if you have any comments or updates of this file, please try
to update the original English file first.
Last Updated: 2008/07/14
==================================
これは、
linux-2.6.26/Documentation/SubmitChecklist の和訳です。
翻訳団体: JF プロジェクト < http://www.linux.or.jp/JF/ >
翻訳日: 2008/07/14
翻訳者: Takenori Nagano <t-nagano at ah dot jp dot nec dot com>
校正者: Masanori Kobayashi さん <zap03216 at nifty dot ne dot jp>
==================================
Linux カーネルパッチ投稿者向けチェックリスト
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
本書では、パッチをより素早く取り込んでもらいたい開発者が実践すべき基本的な事柄
をいくつか紹介します。ここにある全ての事柄は、Documentation/SubmittingPatches
などのLinuxカーネルパッチ投稿に際しての心得を補足するものです。
1: 妥当なCONFIGオプションや変更されたCONFIGオプション、つまり =y, =m, =n
全てで正しくビルドできることを確認してください。その際、gcc及びリンカが
warningやerrorを出していないことも確認してください。
2: allnoconfig, allmodconfig オプションを用いて正しくビルドできることを
確認してください。
3: 手許のクロスコンパイルツールやOSDLのPLMのようなものを用いて、複数の
アーキテクチャにおいても正しくビルドできることを確認してください。
4: 64bit長の'unsigned long'を使用しているppc64は、クロスコンパイルでの
チェックに適当なアーキテクチャです。
5: カーネルコーディングスタイルに準拠しているかどうか確認してください(!)
6: CONFIGオプションの追加・変更をした場合には、CONFIGメニューが壊れていない
ことを確認してください。
7: 新しくKconfigのオプションを追加する際には、必ずそのhelpも記述してください。
8: 適切なKconfigの依存関係を考えながら慎重にチェックしてください。
ただし、この作業はマシンを使ったテストできちんと行うのがとても困難です。
うまくやるには、自分の頭で考えることです。
9: sparseを利用してちゃんとしたコードチェックをしてください。
10: 'make checkstack' と 'make namespacecheck' を利用し、問題が発見されたら
修正してください。'make checkstack' は明示的に問題を示しませんが、どれか
1つの関数が512バイトより大きいスタックを使っていれば、修正すべき候補と
なります。
11: グローバルなkernel API を説明する kernel-doc をソースの中に含めてください。
( staticな関数においては必須ではありませんが、含めてもらっても結構です )
そして、'make htmldocs' もしくは 'make mandocs' を利用して追記した
ドキュメントのチェックを行い、問題が見つかった場合には修正を行ってください。
12: CONFIG_PREEMPT, CONFIG_DEBUG_PREEMPT, CONFIG_DEBUG_SLAB,
CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES, CONFIG_DEBUG_SPINLOCK,
CONFIG_DEBUG_SPINLOCK_SLEEP これら全てを同時に有効にして動作確認を
行ってください。
13: CONFIG_SMP, CONFIG_PREEMPT を有効にした場合と無効にした場合の両方で
ビルドした上、動作確認を行ってください。
14: もしパッチがディスクのI/O性能などに影響を与えるようであれば、
'CONFIG_LBD'オプションを有効にした場合と無効にした場合の両方で
テストを実施してみてください。
15: lockdepの機能を全て有効にした上で、全てのコードパスを評価してください。
16: /proc に新しいエントリを追加した場合には、Documentation/ 配下に
必ずドキュメントを追加してください。
17: 新しいブートパラメータを追加した場合には、
必ずDocumentation/kernel-parameters.txt に説明を追加してください。
18: 新しくmoduleにパラメータを追加した場合には、MODULE_PARM_DESC()を
利用して必ずその説明を記述してください。
19: 新しいuserspaceインタフェースを作成した場合には、Documentation/ABI/ に
Documentation/ABI/README を参考にして必ずドキュメントを追加してください。
20: 'make headers_check'を実行して全く問題がないことを確認してください。
21: 少なくともslabアロケーションとpageアロケーションに失敗した場合の
挙動について、fault-injectionを利用して確認してください。
Documentation/fault-injection/ を参照してください。
追加したコードがかなりの量であったならば、サブシステム特有の
fault-injectionを追加したほうが良いかもしれません。
22: 新たに追加したコードは、`gcc -W'でコンパイルしてください。
このオプションは大量の不要なメッセージを出力しますが、
"warning: comparison between signed and unsigned" のようなメッセージは、
バグを見つけるのに役に立ちます。
23: 投稿したパッチが -mm パッチセットにマージされた後、全ての既存のパッチや
VM, VFS およびその他のサブシステムに関する様々な変更と、現時点でも共存
できることを確認するテストを行ってください。
...@@ -365,6 +365,8 @@ and is between 256 and 4096 characters. It is defined in the file ...@@ -365,6 +365,8 @@ and is between 256 and 4096 characters. It is defined in the file
no delay (0). no delay (0).
Format: integer Format: integer
bootmem_debug [KNL] Enable bootmem allocator debug messages.
bttv.card= [HW,V4L] bttv (bt848 + bt878 based grabber cards) bttv.card= [HW,V4L] bttv (bt848 + bt878 based grabber cards)
bttv.radio= Most important insmod options are available as bttv.radio= Most important insmod options are available as
kernel args too. kernel args too.
...@@ -1072,6 +1074,9 @@ and is between 256 and 4096 characters. It is defined in the file ...@@ -1072,6 +1074,9 @@ and is between 256 and 4096 characters. It is defined in the file
* [no]ncq: Turn on or off NCQ. * [no]ncq: Turn on or off NCQ.
* nohrst, nosrst, norst: suppress hard, soft
and both resets.
If there are multiple matching configurations changing If there are multiple matching configurations changing
the same attribute, the last one is used. the same attribute, the last one is used.
......
...@@ -895,6 +895,9 @@ static void handle_console_output(int fd, struct virtqueue *vq, bool timeout) ...@@ -895,6 +895,9 @@ static void handle_console_output(int fd, struct virtqueue *vq, bool timeout)
} }
} }
/* This is called when we no longer want to hear about Guest changes to a
* virtqueue. This is more efficient in high-traffic cases, but it means we
* have to set a timer to check if any more changes have occurred. */
static void block_vq(struct virtqueue *vq) static void block_vq(struct virtqueue *vq)
{ {
struct itimerval itm; struct itimerval itm;
...@@ -939,6 +942,11 @@ static void handle_net_output(int fd, struct virtqueue *vq, bool timeout) ...@@ -939,6 +942,11 @@ static void handle_net_output(int fd, struct virtqueue *vq, bool timeout)
if (!timeout && num) if (!timeout && num)
block_vq(vq); block_vq(vq);
/* We never quite know how long should we wait before we check the
* queue again for more packets. We start at 500 microseconds, and if
* we get fewer packets than last time, we assume we made the timeout
* too small and increase it by 10 microseconds. Otherwise, we drop it
* by one microsecond every time. It seems to work well enough. */
if (timeout) { if (timeout) {
if (num < last_timeout_num) if (num < last_timeout_num)
timeout_usec += 10; timeout_usec += 10;
...@@ -1447,21 +1455,6 @@ static void configure_device(int fd, const char *tapif, u32 ipaddr) ...@@ -1447,21 +1455,6 @@ static void configure_device(int fd, const char *tapif, u32 ipaddr)
err(1, "Bringing interface %s up", tapif); err(1, "Bringing interface %s up", tapif);
} }
static void get_mac(int fd, const char *tapif, unsigned char hwaddr[6])
{
struct ifreq ifr;
memset(&ifr, 0, sizeof(ifr));
strcpy(ifr.ifr_name, tapif);
/* SIOC stands for Socket I/O Control. G means Get (vs S for Set
* above). IF means Interface, and HWADDR is hardware address.
* Simple! */
if (ioctl(fd, SIOCGIFHWADDR, &ifr) != 0)
err(1, "getting hw address for %s", tapif);
memcpy(hwaddr, ifr.ifr_hwaddr.sa_data, 6);
}
static int get_tun_device(char tapif[IFNAMSIZ]) static int get_tun_device(char tapif[IFNAMSIZ])
{ {
struct ifreq ifr; struct ifreq ifr;
...@@ -1531,11 +1524,8 @@ static void setup_tun_net(char *arg) ...@@ -1531,11 +1524,8 @@ static void setup_tun_net(char *arg)
p = strchr(arg, ':'); p = strchr(arg, ':');
if (p) { if (p) {
str2mac(p+1, conf.mac); str2mac(p+1, conf.mac);
add_feature(dev, VIRTIO_NET_F_MAC);
*p = '\0'; *p = '\0';
} else {
p = arg + strlen(arg);
/* None supplied; query the randomly assigned mac. */
get_mac(ipfd, tapif, conf.mac);
} }
/* arg is now either an IP address or a bridge name */ /* arg is now either an IP address or a bridge name */
...@@ -1547,13 +1537,10 @@ static void setup_tun_net(char *arg) ...@@ -1547,13 +1537,10 @@ static void setup_tun_net(char *arg)
/* Set up the tun device. */ /* Set up the tun device. */
configure_device(ipfd, tapif, ip); configure_device(ipfd, tapif, ip);
/* Tell Guest what MAC address to use. */
add_feature(dev, VIRTIO_NET_F_MAC);
add_feature(dev, VIRTIO_F_NOTIFY_ON_EMPTY); add_feature(dev, VIRTIO_F_NOTIFY_ON_EMPTY);
/* Expect Guest to handle everything except UFO */ /* Expect Guest to handle everything except UFO */
add_feature(dev, VIRTIO_NET_F_CSUM); add_feature(dev, VIRTIO_NET_F_CSUM);
add_feature(dev, VIRTIO_NET_F_GUEST_CSUM); add_feature(dev, VIRTIO_NET_F_GUEST_CSUM);
add_feature(dev, VIRTIO_NET_F_MAC);
add_feature(dev, VIRTIO_NET_F_GUEST_TSO4); add_feature(dev, VIRTIO_NET_F_GUEST_TSO4);
add_feature(dev, VIRTIO_NET_F_GUEST_TSO6); add_feature(dev, VIRTIO_NET_F_GUEST_TSO6);
add_feature(dev, VIRTIO_NET_F_GUEST_ECN); add_feature(dev, VIRTIO_NET_F_GUEST_ECN);
......
# kbuild trick to avoid linker error. Can be omitted if a module is built.
obj- := dummy.o
# List of programs to build
hostprogs-y := ifenslave
# Tell kbuild to always build the programs
always := $(hostprogs-y)
...@@ -1081,7 +1081,7 @@ static int set_if_addr(char *master_ifname, char *slave_ifname) ...@@ -1081,7 +1081,7 @@ static int set_if_addr(char *master_ifname, char *slave_ifname)
} }
ipaddr = ifr.ifr_addr.sa_data; ipaddr = (unsigned char *)ifr.ifr_addr.sa_data;
v_print("Interface '%s': set IP %s to %d.%d.%d.%d\n", v_print("Interface '%s': set IP %s to %d.%d.%d.%d\n",
slave_ifname, ifra[i].desc, slave_ifname, ifra[i].desc,
ipaddr[0], ipaddr[1], ipaddr[2], ipaddr[3]); ipaddr[0], ipaddr[1], ipaddr[2], ipaddr[3]);
......
# kbuild trick to avoid linker error. Can be omitted if a module is built.
obj- := dummy.o
# List of programs to build
hostprogs-y := crc32hash
# Tell kbuild to always build the programs
always := $(hostprogs-y)
HOSTCFLAGS_crc32hash.o += -I$(objtree)/usr/include
...@@ -26,7 +26,7 @@ int main(int argc, char **argv) { ...@@ -26,7 +26,7 @@ int main(int argc, char **argv) {
printf("no string passed as argument\n"); printf("no string passed as argument\n");
return -1; return -1;
} }
result = crc32(argv[1], strlen(argv[1])); result = crc32((unsigned char const *)argv[1], strlen(argv[1]));
printf("0x%x\n", result); printf("0x%x\n", result);
return 0; return 0;
} }
PM quality of Service interface. PM Quality Of Service Interface.
This interface provides a kernel and user mode interface for registering This interface provides a kernel and user mode interface for registering
performance expectations by drivers, subsystems and user space applications on performance expectations by drivers, subsystems and user space applications on
...@@ -7,6 +7,11 @@ one of the parameters. ...@@ -7,6 +7,11 @@ one of the parameters.
Currently we have {cpu_dma_latency, network_latency, network_throughput} as the Currently we have {cpu_dma_latency, network_latency, network_throughput} as the
initial set of pm_qos parameters. initial set of pm_qos parameters.
Each parameters have defined units:
* latency: usec
* timeout: usec
* throughput: kbs (kilo bit / sec)
The infrastructure exposes multiple misc device nodes one per implemented The infrastructure exposes multiple misc device nodes one per implemented
parameter. The set of parameters implement is defined by pm_qos_power_init() parameter. The set of parameters implement is defined by pm_qos_power_init()
and pm_qos_params.h. This is done because having the available parameters and pm_qos_params.h. This is done because having the available parameters
......
...@@ -278,7 +278,7 @@ it with special cases. ...@@ -278,7 +278,7 @@ it with special cases.
a 64-bit platform. a 64-bit platform.
d) request and get assigned a platform number (see PLATFORM_* d) request and get assigned a platform number (see PLATFORM_*
constants in include/asm-powerpc/processor.h constants in arch/powerpc/include/asm/processor.h
32-bit embedded kernels: 32-bit embedded kernels:
...@@ -340,7 +340,7 @@ the block to RAM before passing it to the kernel. ...@@ -340,7 +340,7 @@ the block to RAM before passing it to the kernel.
--------- ---------
The kernel is entered with r3 pointing to an area of memory that is The kernel is entered with r3 pointing to an area of memory that is
roughly described in include/asm-powerpc/prom.h by the structure roughly described in arch/powerpc/include/asm/prom.h by the structure
boot_param_header: boot_param_header:
struct boot_param_header { struct boot_param_header {
......
...@@ -133,7 +133,7 @@ error. Given an arbitrary address, the routine ...@@ -133,7 +133,7 @@ error. Given an arbitrary address, the routine
pci_get_device_by_addr() will find the pci device associated pci_get_device_by_addr() will find the pci device associated
with that address (if any). with that address (if any).
The default include/asm-powerpc/io.h macros readb(), inb(), insb(), The default arch/powerpc/include/asm/io.h macros readb(), inb(), insb(),
etc. include a check to see if the i/o read returned all-0xff's. etc. include a check to see if the i/o read returned all-0xff's.
If so, these make a call to eeh_dn_check_failure(), which in turn If so, these make a call to eeh_dn_check_failure(), which in turn
asks the firmware if the all-ff's value is the sign of a true EEH asks the firmware if the all-ff's value is the sign of a true EEH
......
...@@ -363,6 +363,11 @@ This rule exists because users of the rfkill subsystem expect to get (and set, ...@@ -363,6 +363,11 @@ This rule exists because users of the rfkill subsystem expect to get (and set,
when possible) the overall transmitter rfkill state, not of a particular rfkill when possible) the overall transmitter rfkill state, not of a particular rfkill
line. line.
5. During suspend, the rfkill class will attempt to soft-block the radio
through a call to rfkill->toggle_radio, and will try to restore its previous
state during resume. After a rfkill class is suspended, it will *not* call
rfkill->toggle_radio until it is resumed.
Example of a WLAN wireless driver connected to the rfkill subsystem: Example of a WLAN wireless driver connected to the rfkill subsystem:
-------------------------------------------------------------------- --------------------------------------------------------------------
......
1 Release Date : Thur.July. 24 11:41:51 PST 2008 -
(emaild-id:megaraidlinux@lsi.com)
Sumant Patro
Bo Yang
2 Current Version : 00.00.04.01
3 Older Version : 00.00.03.22
1. Add the new controller (0078, 0079) support to the driver
Those controllers are LSI's next generatation(gen2) SAS controllers.
1 Release Date : Mon.June. 23 10:12:45 PST 2008 -
(emaild-id:megaraidlinux@lsi.com)
Sumant Patro
Bo Yang
2 Current Version : 00.00.03.22
3 Older Version : 00.00.03.20
1. Add shutdown DCMD cmd to the shutdown routine to make FW shutdown proper.
2. Unexpected interrupt occurs in HWR Linux driver, add the dumy readl pci flush will fix this issue.
1 Release Date : Mon. March 10 11:02:31 PDT 2008 - 1 Release Date : Mon. March 10 11:02:31 PDT 2008 -
(emaild-id:megaraidlinux@lsi.com) (emaild-id:megaraidlinux@lsi.com)
Sumant Patro Sumant Patro
......
...@@ -1144,8 +1144,6 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. ...@@ -1144,8 +1144,6 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
This module supports autoprobe and multiple cards. This module supports autoprobe and multiple cards.
Power management is _not_ supported.
Module snd-ice1712 Module snd-ice1712
------------------ ------------------
...@@ -1628,8 +1626,6 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. ...@@ -1628,8 +1626,6 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
This module supports autoprobe and multiple cards. This module supports autoprobe and multiple cards.
Power management is _not_ supported.
Module snd-pcsp Module snd-pcsp
----------------- -----------------
...@@ -2081,13 +2077,11 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. ...@@ -2081,13 +2077,11 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
Module snd-virtuoso Module snd-virtuoso
------------------- -------------------
Module for sound cards based on the Asus AV200 chip, i.e., Module for sound cards based on the Asus AV100/AV200 chips,
Xonar D2 and Xonar D2X. i.e., Xonar D1, DX, D2 and D2X.
This module supports autoprobe and multiple cards. This module supports autoprobe and multiple cards.
Power management is _not_ supported.
Module snd-vx222 Module snd-vx222
---------------- ----------------
......
# kbuild trick to avoid linker error. Can be omitted if a module is built.
obj- := dummy.o
# List of programs to build
hostprogs-y := spidev_test spidev_fdx
# Tell kbuild to always build the programs
always := $(hostprogs-y)
HOSTCFLAGS_spidev_test.o += -I$(objtree)/usr/include
HOSTCFLAGS_spidev_fdx.o += -I$(objtree)/usr/include
...@@ -19,7 +19,7 @@ Declaring PXA2xx Master Controllers ...@@ -19,7 +19,7 @@ Declaring PXA2xx Master Controllers
----------------------------------- -----------------------------------
Typically a SPI master is defined in the arch/.../mach-*/board-*.c as a Typically a SPI master is defined in the arch/.../mach-*/board-*.c as a
"platform device". The master configuration is passed to the driver via a table "platform device". The master configuration is passed to the driver via a table
found in include/asm-arm/arch-pxa/pxa2xx_spi.h: found in arch/arm/mach-pxa/include/mach/pxa2xx_spi.h:
struct pxa2xx_spi_master { struct pxa2xx_spi_master {
enum pxa_ssp_type ssp_type; enum pxa_ssp_type ssp_type;
...@@ -94,7 +94,7 @@ using the "spi_board_info" structure found in "linux/spi/spi.h". See ...@@ -94,7 +94,7 @@ using the "spi_board_info" structure found in "linux/spi/spi.h". See
Each slave device attached to the PXA must provide slave specific configuration Each slave device attached to the PXA must provide slave specific configuration
information via the structure "pxa2xx_spi_chip" found in information via the structure "pxa2xx_spi_chip" found in
"include/asm-arm/arch-pxa/pxa2xx_spi.h". The pxa2xx_spi master controller driver "arch/arm/mach-pxa/include/mach/pxa2xx_spi.h". The pxa2xx_spi master controller driver
will uses the configuration whenever the driver communicates with the slave will uses the configuration whenever the driver communicates with the slave
device. device.
......
...@@ -210,7 +210,7 @@ board should normally be set up and registered. ...@@ -210,7 +210,7 @@ board should normally be set up and registered.
So for example arch/.../mach-*/board-*.c files might have code like: So for example arch/.../mach-*/board-*.c files might have code like:
#include <asm/arch/spi.h> /* for mysoc_spi_data */ #include <mach/spi.h> /* for mysoc_spi_data */
/* if your mach-* infrastructure doesn't support kernels that can /* if your mach-* infrastructure doesn't support kernels that can
* run on multiple boards, pdata wouldn't benefit from "__init". * run on multiple boards, pdata wouldn't benefit from "__init".
...@@ -227,7 +227,7 @@ So for example arch/.../mach-*/board-*.c files might have code like: ...@@ -227,7 +227,7 @@ So for example arch/.../mach-*/board-*.c files might have code like:
And SOC-specific utility code might look something like: And SOC-specific utility code might look something like:
#include <asm/arch/spi.h> #include <mach/spi.h>
static struct platform_device spi2 = { ... }; static struct platform_device spi2 = { ... };
......
Auerswald USB kernel driver
===========================
What is it? What can I do with it?
==================================
The auerswald USB kernel driver connects your linux 2.4.x
system to the auerswald usb-enabled devices.
There are two types of auerswald usb devices:
a) small PBX systems (ISDN)
b) COMfort system telephones (ISDN)
The driver installation creates the devices
/dev/usb/auer0..15. These devices carry a vendor-
specific protocol. You may run all auerswald java
software on it. The java software needs a native
library "libAuerUsbJNINative.so" installed on
your system. This library is available from
auerswald and shipped as part of the java software.
You may create the devices with:
mknod -m 666 /dev/usb/auer0 c 180 112
...
mknod -m 666 /dev/usb/auer15 c 180 127
Future plans
============
- Connection to ISDN4LINUX (the hisax interface)
The maintainer of this driver is wolfgang@iksw-muees.de
...@@ -436,7 +436,12 @@ post_reset; the USB core guarantees that this is true of internal ...@@ -436,7 +436,12 @@ post_reset; the USB core guarantees that this is true of internal
suspend/resume events as well. suspend/resume events as well.
If a driver wants to block all suspend/resume calls during some If a driver wants to block all suspend/resume calls during some
critical section, it can simply acquire udev->pm_mutex. critical section, it can simply acquire udev->pm_mutex. Note that
calls to resume may be triggered indirectly. Block IO due to memory
allocations can make the vm subsystem resume a device. Thus while
holding this lock you must not allocate memory with GFP_KERNEL or
GFP_NOFS.
Alternatively, if the critical section might call some of the Alternatively, if the critical section might call some of the
usb_autopm_* routines, the driver can avoid deadlock by doing: usb_autopm_* routines, the driver can avoid deadlock by doing:
......
# kbuild trick to avoid linker error. Can be omitted if a module is built.
obj- := dummy.o
# List of programs to build
hostprogs-y := v4lgrab
# Tell kbuild to always build the programs
always := $(hostprogs-y)
...@@ -226,6 +226,7 @@ sonixj 0c45:6130 Sonix Pccam ...@@ -226,6 +226,7 @@ sonixj 0c45:6130 Sonix Pccam
sonixj 0c45:6138 Sn9c120 Mo4000 sonixj 0c45:6138 Sn9c120 Mo4000
sonixj 0c45:613b Surfer SN-206 sonixj 0c45:613b Surfer SN-206
sonixj 0c45:613c Sonix Pccam168 sonixj 0c45:613c Sonix Pccam168
sonixj 0c45:6143 Sonix Pccam168
sunplus 0d64:0303 Sunplus FashionCam DXG sunplus 0d64:0303 Sunplus FashionCam DXG
etoms 102c:6151 Qcam Sangha CIF etoms 102c:6151 Qcam Sangha CIF
etoms 102c:6251 Qcam xxxxxx VGA etoms 102c:6251 Qcam xxxxxx VGA
......
# kbuild trick to avoid linker error. Can be omitted if a module is built.
obj- := dummy.o
# List of programs to build
hostprogs-y := slabinfo
# Tell kbuild to always build the programs
always := $(hostprogs-y)
...@@ -18,10 +18,11 @@ migrate_pages function call takes two sets of nodes and moves pages of a ...@@ -18,10 +18,11 @@ migrate_pages function call takes two sets of nodes and moves pages of a
process that are located on the from nodes to the destination nodes. process that are located on the from nodes to the destination nodes.
Page migration functions are provided by the numactl package by Andi Kleen Page migration functions are provided by the numactl package by Andi Kleen
(a version later than 0.9.3 is required. Get it from (a version later than 0.9.3 is required. Get it from
ftp://ftp.suse.com/pub/people/ak). numactl provided libnuma which ftp://oss.sgi.com/www/projects/libnuma/download/). numactl provides libnuma
provides an interface similar to other numa functionality for page migration. which provides an interface similar to other numa functionality for page
cat /proc/<pid>/numa_maps allows an easy review of where the pages of migration. cat /proc/<pid>/numa_maps allows an easy review of where the
a process are located. See also the numa_maps manpage in the numactl package. pages of a process are located. See also the numa_maps documentation in the
proc(5) man page.
Manual migration is useful if for example the scheduler has relocated Manual migration is useful if for example the scheduler has relocated
a process to a processor on a distant node. A batch scheduler or an a process to a processor on a distant node. A batch scheduler or an
......
# kbuild trick to avoid linker error. Can be omitted if a module is built.
obj- := dummy.o
# List of programs to build
hostprogs-y := watchdog-simple watchdog-test
# Tell kbuild to always build the programs
always := $(hostprogs-y)
...@@ -175,12 +175,18 @@ M: bcrl@kvack.org ...@@ -175,12 +175,18 @@ M: bcrl@kvack.org
L: linux-aio@kvack.org L: linux-aio@kvack.org
S: Supported S: Supported
ABIT UGURU HARDWARE MONITOR DRIVER ABIT UGURU 1,2 HARDWARE MONITOR DRIVER
P: Hans de Goede P: Hans de Goede
M: j.w.r.degoede@hhs.nl M: j.w.r.degoede@hhs.nl
L: lm-sensors@lm-sensors.org L: lm-sensors@lm-sensors.org
S: Maintained S: Maintained
ABIT UGURU 3 HARDWARE MONITOR DRIVER
P: Alistair John Strachan
M: alistair@devzero.co.uk
L: lm-sensors@lm-sensors.org
S: Maintained
ACENIC DRIVER ACENIC DRIVER
P: Jes Sorensen P: Jes Sorensen
M: jes@trained-monkey.org M: jes@trained-monkey.org
...@@ -502,6 +508,12 @@ L: openezx-devel@lists.openezx.org (subscribers-only) ...@@ -502,6 +508,12 @@ L: openezx-devel@lists.openezx.org (subscribers-only)
W: http://www.openezx.org/ W: http://www.openezx.org/
S: Maintained S: Maintained
ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
P: Sascha Hauer
M: kernel@pengutronix.de
L: linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only)
S: Maintained
ARM/GLOMATION GESBC9312SX MACHINE SUPPORT ARM/GLOMATION GESBC9312SX MACHINE SUPPORT
P: Lennert Buytenhek P: Lennert Buytenhek
M: kernel@wantstofly.org M: kernel@wantstofly.org
...@@ -588,6 +600,11 @@ M: kernel@wantstofly.org ...@@ -588,6 +600,11 @@ M: kernel@wantstofly.org
L: linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only) L: linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only)
S: Maintained S: Maintained
ARM/MAGICIAN MACHINE SUPPORT
P: Philipp Zabel
M: philipp.zabel@gmail.com
S: Maintained
ARM/TOSA MACHINE SUPPORT ARM/TOSA MACHINE SUPPORT
P: Dmitry Baryshkov P: Dmitry Baryshkov
M: dbaryshkov@gmail.com M: dbaryshkov@gmail.com
...@@ -714,6 +731,15 @@ L: linux-wireless@vger.kernel.org ...@@ -714,6 +731,15 @@ L: linux-wireless@vger.kernel.org
L: ath5k-devel@lists.ath5k.org L: ath5k-devel@lists.ath5k.org
S: Maintained S: Maintained
ATHEROS ATH9K WIRELESS DRIVER
P: Luis R. Rodriguez
M: lrodriguez@atheros.com
P: Jouni Malinen
M: jmalinen@atheros.com
L: linux-wireless@vger.kernel.org
L: ath9k-devel@lists.ath9k.org
S: Supported
ATI_REMOTE2 DRIVER ATI_REMOTE2 DRIVER
P: Ville Syrjala P: Ville Syrjala
M: syrjala@sci.fi M: syrjala@sci.fi
...@@ -916,94 +942,19 @@ M: joern@lazybastard.org ...@@ -916,94 +942,19 @@ M: joern@lazybastard.org
L: linux-mtd@lists.infradead.org L: linux-mtd@lists.infradead.org
S: Maintained S: Maintained
BLUETOOTH SUBSYSTEM BLUETOOTH DRIVERS
P: Marcel Holtmann P: Marcel Holtmann
M: marcel@holtmann.org M: marcel@holtmann.org
P: Maxim Krasnyansky
M: maxk@qualcomm.com
L: linux-bluetooth@vger.kernel.org L: linux-bluetooth@vger.kernel.org
W: http://bluez.sf.net W: http://www.bluez.org/
W: http://www.bluez.org
W: http://www.holtmann.org/linux/bluetooth/
T: git kernel.org:/pub/scm/linux/kernel/git/holtmann/bluetooth-2.6.git
S: Maintained
BLUETOOTH RFCOMM LAYER
P: Marcel Holtmann
M: marcel@holtmann.org
P: Maxim Krasnyansky
M: maxk@qualcomm.com
S: Maintained S: Maintained
BLUETOOTH BNEP LAYER BLUETOOTH SUBSYSTEM
P: Marcel Holtmann
M: marcel@holtmann.org
P: Maxim Krasnyansky
M: maxk@qualcomm.com
S: Maintained
BLUETOOTH CMTP LAYER
P: Marcel Holtmann
M: marcel@holtmann.org
S: Maintained
BLUETOOTH HIDP LAYER
P: Marcel Holtmann
M: marcel@holtmann.org
S: Maintained
BLUETOOTH HCI UART DRIVER
P: Marcel Holtmann
M: marcel@holtmann.org
P: Maxim Krasnyansky
M: maxk@qualcomm.com
S: Maintained
BLUETOOTH HCI USB DRIVER
P: Marcel Holtmann
M: marcel@holtmann.org
P: Maxim Krasnyansky
M: maxk@qualcomm.com
S: Maintained
BLUETOOTH HCI BCM203X DRIVER
P: Marcel Holtmann
M: marcel@holtmann.org
S: Maintained
BLUETOOTH HCI BPA10X DRIVER
P: Marcel Holtmann
M: marcel@holtmann.org
S: Maintained
BLUETOOTH HCI BFUSB DRIVER
P: Marcel Holtmann
M: marcel@holtmann.org
S: Maintained
BLUETOOTH HCI DTL1 DRIVER
P: Marcel Holtmann
M: marcel@holtmann.org
S: Maintained
BLUETOOTH HCI BLUECARD DRIVER
P: Marcel Holtmann
M: marcel@holtmann.org
S: Maintained
BLUETOOTH HCI BT3C DRIVER
P: Marcel Holtmann
M: marcel@holtmann.org
S: Maintained
BLUETOOTH HCI BTUART DRIVER
P: Marcel Holtmann P: Marcel Holtmann
M: marcel@holtmann.org M: marcel@holtmann.org
S: Maintained L: linux-bluetooth@vger.kernel.org
W: http://www.bluez.org/
BLUETOOTH HCI VHCI DRIVER T: git kernel.org:/pub/scm/linux/kernel/git/holtmann/bluetooth-2.6.git
P: Maxim Krasnyansky
M: maxk@qualcomm.com
S: Maintained S: Maintained
BONDING DRIVER BONDING DRIVER
...@@ -1229,7 +1180,7 @@ S: Maintained ...@@ -1229,7 +1180,7 @@ S: Maintained
CPU FREQUENCY DRIVERS CPU FREQUENCY DRIVERS
P: Dave Jones P: Dave Jones
M: davej@codemonkey.org.uk M: davej@codemonkey.org.uk
L: cpufreq@lists.linux.org.uk L: cpufreq@vger.kernel.org
W: http://www.codemonkey.org.uk/projects/cpufreq/ W: http://www.codemonkey.org.uk/projects/cpufreq/
T: git kernel.org/pub/scm/linux/kernel/git/davej/cpufreq.git T: git kernel.org/pub/scm/linux/kernel/git/davej/cpufreq.git
S: Maintained S: Maintained
...@@ -2442,7 +2393,7 @@ L: kernel-janitors@vger.kernel.org ...@@ -2442,7 +2393,7 @@ L: kernel-janitors@vger.kernel.org
W: http://www.kerneljanitors.org/ W: http://www.kerneljanitors.org/
S: Maintained S: Maintained
KERNEL NFSD KERNEL NFSD, SUNRPC, AND LOCKD SERVERS
P: J. Bruce Fields P: J. Bruce Fields
M: bfields@fieldses.org M: bfields@fieldses.org
P: Neil Brown P: Neil Brown
...@@ -2908,6 +2859,12 @@ M: jirislaby@gmail.com ...@@ -2908,6 +2859,12 @@ M: jirislaby@gmail.com
L: linux-kernel@vger.kernel.org L: linux-kernel@vger.kernel.org
S: Maintained S: Maintained
MUSB MULTIPOINT HIGH SPEED DUAL-ROLE CONTROLLER
P: Felipe Balbi
M: felipe.balbi@nokia.com
L: linux-usb@vger.kernel.org
S: Maintained
MYRICOM MYRI-10G 10GbE DRIVER (MYRI10GE) MYRICOM MYRI-10G 10GbE DRIVER (MYRI10GE)
P: Andrew Gallatin P: Andrew Gallatin
M: gallatin@myri.com M: gallatin@myri.com
...@@ -3056,9 +3013,10 @@ M: horms@verge.net.au ...@@ -3056,9 +3013,10 @@ M: horms@verge.net.au
P: Julian Anastasov P: Julian Anastasov
M: ja@ssi.bg M: ja@ssi.bg
L: netdev@vger.kernel.org L: netdev@vger.kernel.org
L: lvs-devel@vger.kernel.org
S: Maintained S: Maintained
NFS CLIENT NFS, SUNRPC, AND LOCKD CLIENTS
P: Trond Myklebust P: Trond Myklebust
M: Trond.Myklebust@netapp.com M: Trond.Myklebust@netapp.com
L: linux-nfs@vger.kernel.org L: linux-nfs@vger.kernel.org
...@@ -3721,6 +3679,16 @@ L: linux-visws-devel@lists.sf.net ...@@ -3721,6 +3679,16 @@ L: linux-visws-devel@lists.sf.net
W: http://linux-visws.sf.net W: http://linux-visws.sf.net
S: Maintained for 2.6. S: Maintained for 2.6.
SGI GRU DRIVER
P: Jack Steiner
M: steiner@sgi.com
S: Maintained
SGI XP/XPC/XPNET DRIVER
P: Dean Nelson
M: dcn@sgi.com
S: Maintained
SIMTEC EB110ATX (Chalice CATS) SIMTEC EB110ATX (Chalice CATS)
P: Ben Dooks P: Ben Dooks
P: Vincent Sanders P: Vincent Sanders
...@@ -4175,12 +4143,6 @@ M: oliver@neukum.name ...@@ -4175,12 +4143,6 @@ M: oliver@neukum.name
L: linux-usb@vger.kernel.org L: linux-usb@vger.kernel.org
S: Maintained S: Maintained
USB AUERSWALD DRIVER
P: Wolfgang Muees
M: wolfgang@iksw-muees.de
L: linux-usb@vger.kernel.org
S: Maintained
USB BLOCK DRIVER (UB ub) USB BLOCK DRIVER (UB ub)
P: Pete Zaitcev P: Pete Zaitcev
M: zaitcev@redhat.com M: zaitcev@redhat.com
...@@ -4663,12 +4625,6 @@ L: linux-wireless@vger.kernel.org ...@@ -4663,12 +4625,6 @@ L: linux-wireless@vger.kernel.org
L: zd1211-devs@lists.sourceforge.net (subscribers-only) L: zd1211-devs@lists.sourceforge.net (subscribers-only)
S: Maintained S: Maintained
ZF MACHZ WATCHDOG
P: Fernando Fuganti
M: fuganti@netbank.com.br
W: http://cvs.conectiva.com.br/drivers/ZFL-watchdog/
S: Maintained
ZR36067 VIDEO FOR LINUX DRIVER ZR36067 VIDEO FOR LINUX DRIVER
P: Ronald Bultje P: Ronald Bultje
M: rbultje@ronald.bitfreak.net M: rbultje@ronald.bitfreak.net
......
VERSION = 2 VERSION = 2
PATCHLEVEL = 6 PATCHLEVEL = 6
SUBLEVEL = 27 SUBLEVEL = 27
EXTRAVERSION = -rc1 EXTRAVERSION = -rc4
NAME = Rotary Wombat NAME = Rotary Wombat
# *DOCUMENTATION* # *DOCUMENTATION*
...@@ -821,6 +821,9 @@ ifdef CONFIG_HEADERS_CHECK ...@@ -821,6 +821,9 @@ ifdef CONFIG_HEADERS_CHECK
endif endif
ifdef CONFIG_SAMPLES ifdef CONFIG_SAMPLES
$(Q)$(MAKE) $(build)=samples $(Q)$(MAKE) $(build)=samples
endif
ifdef CONFIG_BUILD_DOCSRC
$(Q)$(MAKE) $(build)=Documentation
endif endif
$(call vmlinux-modpost) $(call vmlinux-modpost)
$(call if_changed_rule,vmlinux__) $(call if_changed_rule,vmlinux__)
...@@ -929,10 +932,10 @@ ifneq ($(KBUILD_SRC),) ...@@ -929,10 +932,10 @@ ifneq ($(KBUILD_SRC),)
echo " in the '$(srctree)' directory.";\ echo " in the '$(srctree)' directory.";\
/bin/false; \ /bin/false; \
fi; fi;
$(Q)if [ ! -d include2 ]; then mkdir -p include2; fi; $(Q)if [ ! -d include2 ]; then \
$(Q)if [ -e $(srctree)/include/asm-$(SRCARCH)/errno.h ]; then \ mkdir -p include2; \
ln -fsn $(srctree)/include/asm-$(SRCARCH) include2/asm; \ ln -fsn $(srctree)/include/asm-$(SRCARCH) include2/asm; \
fi fi
endif endif
# prepare2 creates a makefile if using a separate output directory # prepare2 creates a makefile if using a separate output directory
...@@ -1166,7 +1169,7 @@ MRPROPER_FILES += .config .config.old include/asm .version .old_version \ ...@@ -1166,7 +1169,7 @@ MRPROPER_FILES += .config .config.old include/asm .version .old_version \
# #
clean: rm-dirs := $(CLEAN_DIRS) clean: rm-dirs := $(CLEAN_DIRS)
clean: rm-files := $(CLEAN_FILES) clean: rm-files := $(CLEAN_FILES)
clean-dirs := $(addprefix _clean_,$(srctree) $(vmlinux-alldirs)) clean-dirs := $(addprefix _clean_,$(srctree) $(vmlinux-alldirs) Documentation)
PHONY += $(clean-dirs) clean archclean PHONY += $(clean-dirs) clean archclean
$(clean-dirs): $(clean-dirs):
...@@ -1492,7 +1495,7 @@ quiet_cmd_cscope-file = FILELST cscope.files ...@@ -1492,7 +1495,7 @@ quiet_cmd_cscope-file = FILELST cscope.files
cmd_cscope-file = (echo \-k; echo \-q; $(all-sources)) > cscope.files cmd_cscope-file = (echo \-k; echo \-q; $(all-sources)) > cscope.files
quiet_cmd_cscope = MAKE cscope.out quiet_cmd_cscope = MAKE cscope.out
cmd_cscope = cscope -b cmd_cscope = cscope -b -f cscope.out
cscope: FORCE cscope: FORCE
$(call cmd,cscope-file) $(call cmd,cscope-file)
......
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册