Merge branch 'master' into next
This commit is contained in:
James Morris
commit
86d688984d
4405 changed files with 100578 additions and 38118 deletions
|
|
@ -89,8 +89,6 @@ cciss.txt
|
|||
- info, major/minor #'s for Compaq's SMART Array Controllers.
|
||||
cdrom/
|
||||
- directory with information on the CD-ROM drivers that Linux has.
|
||||
cli-sti-removal.txt
|
||||
- cli()/sti() removal guide.
|
||||
computone.txt
|
||||
- info on Computone Intelliport II/Plus Multiport Serial Driver.
|
||||
connector/
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \
|
|||
kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \
|
||||
gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
|
||||
genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
|
||||
mac80211.xml debugobjects.xml
|
||||
mac80211.xml debugobjects.xml sh.xml
|
||||
|
||||
###
|
||||
# The build process is as follows (targets):
|
||||
|
|
@ -102,6 +102,13 @@ C-procfs-example = procfs_example.xml
|
|||
C-procfs-example2 = $(addprefix $(obj)/,$(C-procfs-example))
|
||||
$(obj)/procfs-guide.xml: $(C-procfs-example2)
|
||||
|
||||
# List of programs to build
|
||||
##oops, this is a kernel module::hostprogs-y := procfs_example
|
||||
obj-m += procfs_example.o
|
||||
|
||||
# Tell kbuild to always build the programs
|
||||
always := $(hostprogs-y)
|
||||
|
||||
notfoundtemplate = echo "*** You have to install docbook-utils or xmlto ***"; \
|
||||
exit 1
|
||||
db2xtemplate = db2TYPE -o $(dir $@) $<
|
||||
|
|
|
|||
|
|
@ -189,8 +189,6 @@ static int __init init_procfs_example(void)
|
|||
return 0;
|
||||
|
||||
no_symlink:
|
||||
remove_proc_entry("tty", example_dir);
|
||||
no_tty:
|
||||
remove_proc_entry("bar", example_dir);
|
||||
no_bar:
|
||||
remove_proc_entry("foo", example_dir);
|
||||
|
|
@ -206,7 +204,6 @@ static int __init init_procfs_example(void)
|
|||
static void __exit cleanup_procfs_example(void)
|
||||
{
|
||||
remove_proc_entry("jiffies_too", example_dir);
|
||||
remove_proc_entry("tty", example_dir);
|
||||
remove_proc_entry("bar", example_dir);
|
||||
remove_proc_entry("foo", example_dir);
|
||||
remove_proc_entry("jiffies", example_dir);
|
||||
|
|
@ -222,3 +219,4 @@ module_exit(cleanup_procfs_example);
|
|||
|
||||
MODULE_AUTHOR("Erik Mouw");
|
||||
MODULE_DESCRIPTION("procfs examples");
|
||||
MODULE_LICENSE("GPL");
|
||||
|
|
|
|||
|
|
@ -100,7 +100,7 @@
|
|||
the hardware structures represented here, please consult the Principles
|
||||
of Operation.
|
||||
</para>
|
||||
!Iinclude/asm-s390/cio.h
|
||||
!Iarch/s390/include/asm/cio.h
|
||||
</sect1>
|
||||
<sect1 id="ccwdev">
|
||||
<title>ccw devices</title>
|
||||
|
|
@ -114,7 +114,7 @@
|
|||
ccw device structure. Device drivers must not bypass those functions
|
||||
or strange side effects may happen.
|
||||
</para>
|
||||
!Iinclude/asm-s390/ccwdev.h
|
||||
!Iarch/s390/include/asm/ccwdev.h
|
||||
!Edrivers/s390/cio/device.c
|
||||
!Edrivers/s390/cio/device_ops.c
|
||||
</sect1>
|
||||
|
|
@ -125,7 +125,7 @@
|
|||
measurement data which is made available by the channel subsystem
|
||||
for each channel attached device.
|
||||
</para>
|
||||
!Iinclude/asm-s390/cmb.h
|
||||
!Iarch/s390/include/asm/cmb.h
|
||||
!Edrivers/s390/cio/cmf.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
|
@ -142,7 +142,7 @@
|
|||
</para>
|
||||
<sect1 id="ccwgroupdevices">
|
||||
<title>ccw group devices</title>
|
||||
!Iinclude/asm-s390/ccwgroup.h
|
||||
!Iarch/s390/include/asm/ccwgroup.h
|
||||
!Edrivers/s390/cio/ccwgroup.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
|
|
|||
105
Documentation/DocBook/sh.tmpl
Normal file
105
Documentation/DocBook/sh.tmpl
Normal file
|
|
@ -0,0 +1,105 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
|
||||
|
||||
<book id="sh-drivers">
|
||||
<bookinfo>
|
||||
<title>SuperH Interfaces Guide</title>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Paul</firstname>
|
||||
<surname>Mundt</surname>
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>lethal@linux-sh.org</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<copyright>
|
||||
<year>2008</year>
|
||||
<holder>Paul Mundt</holder>
|
||||
</copyright>
|
||||
<copyright>
|
||||
<year>2008</year>
|
||||
<holder>Renesas Technology Corp.</holder>
|
||||
</copyright>
|
||||
|
||||
<legalnotice>
|
||||
<para>
|
||||
This documentation is free software; you can redistribute
|
||||
it and/or modify it under the terms of the GNU General Public
|
||||
License version 2 as published by the Free Software Foundation.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This program is distributed in the hope that it will be
|
||||
useful, but WITHOUT ANY WARRANTY; without even the implied
|
||||
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
|
||||
See the GNU General Public License for more details.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You should have received a copy of the GNU General Public
|
||||
License along with this program; if not, write to the Free
|
||||
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
|
||||
MA 02111-1307 USA
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For more details see the file COPYING in the source
|
||||
distribution of Linux.
|
||||
</para>
|
||||
</legalnotice>
|
||||
</bookinfo>
|
||||
|
||||
<toc></toc>
|
||||
|
||||
<chapter id="mm">
|
||||
<title>Memory Management</title>
|
||||
<sect1 id="sh4">
|
||||
<title>SH-4</title>
|
||||
<sect2 id="sq">
|
||||
<title>Store Queue API</title>
|
||||
!Earch/sh/kernel/cpu/sh4/sq.c
|
||||
</sect2>
|
||||
</sect1>
|
||||
<sect1 id="sh5">
|
||||
<title>SH-5</title>
|
||||
<sect2 id="tlb">
|
||||
<title>TLB Interfaces</title>
|
||||
!Iarch/sh/mm/tlb-sh5.c
|
||||
!Iarch/sh/include/asm/tlb_64.h
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
<chapter id="clk">
|
||||
<title>Clock Framework Extensions</title>
|
||||
!Iarch/sh/include/asm/clock.h
|
||||
</chapter>
|
||||
<chapter id="mach">
|
||||
<title>Machine Specific Interfaces</title>
|
||||
<sect1 id="dreamcast">
|
||||
<title>mach-dreamcast</title>
|
||||
!Iarch/sh/boards/mach-dreamcast/rtc.c
|
||||
</sect1>
|
||||
<sect1 id="x3proto">
|
||||
<title>mach-x3proto</title>
|
||||
!Earch/sh/boards/mach-x3proto/ilsel.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
<chapter id="busses">
|
||||
<title>Busses</title>
|
||||
<sect1 id="superhyway">
|
||||
<title>SuperHyway</title>
|
||||
!Edrivers/sh/superhyway/superhyway.c
|
||||
</sect1>
|
||||
|
||||
<sect1 id="maple">
|
||||
<title>Maple</title>
|
||||
!Edrivers/sh/maple/maple.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
</book>
|
||||
|
|
@ -1648,7 +1648,7 @@ static struct video_buffer capture_fb;
|
|||
|
||||
<chapter id="pubfunctions">
|
||||
<title>Public Functions Provided</title>
|
||||
!Edrivers/media/video/videodev.c
|
||||
!Edrivers/media/video/v4l2-dev.c
|
||||
</chapter>
|
||||
|
||||
</book>
|
||||
|
|
|
|||
|
|
@ -69,12 +69,6 @@
|
|||
device to be used as both a tty interface and as a synchronous
|
||||
controller is a project for Linux post the 2.4 release
|
||||
</para>
|
||||
<para>
|
||||
The support code handles most common card configurations and
|
||||
supports running both Cisco HDLC and Synchronous PPP. With extra
|
||||
glue the frame relay and X.25 protocols can also be used with this
|
||||
driver.
|
||||
</para>
|
||||
</chapter>
|
||||
|
||||
<chapter id="Driver_Modes">
|
||||
|
|
@ -179,35 +173,27 @@
|
|||
<para>
|
||||
If you wish to use the network interface facilities of the driver,
|
||||
then you need to attach a network device to each channel that is
|
||||
present and in use. In addition to use the SyncPPP and Cisco HDLC
|
||||
present and in use. In addition to use the generic HDLC
|
||||
you need to follow some additional plumbing rules. They may seem
|
||||
complex but a look at the example hostess_sv11 driver should
|
||||
reassure you.
|
||||
</para>
|
||||
<para>
|
||||
The network device used for each channel should be pointed to by
|
||||
the netdevice field of each channel. The dev-> priv field of the
|
||||
the netdevice field of each channel. The hdlc-> priv field of the
|
||||
network device points to your private data - you will need to be
|
||||
able to find your ppp device from this. In addition to use the
|
||||
sync ppp layer the private data must start with a void * pointer
|
||||
to the syncppp structures.
|
||||
able to find your private data from this.
|
||||
</para>
|
||||
<para>
|
||||
The way most drivers approach this particular problem is to
|
||||
create a structure holding the Z8530 device definition and
|
||||
put that and the syncppp pointer into the private field of
|
||||
the network device. The network device fields of the channels
|
||||
then point back to the network devices. The ppp_device can also
|
||||
be put in the private structure conveniently.
|
||||
put that into the private field of the network device. The
|
||||
network device fields of the channels then point back to the
|
||||
network devices.
|
||||
</para>
|
||||
<para>
|
||||
If you wish to use the synchronous ppp then you need to attach
|
||||
the syncppp layer to the network device. You should do this before
|
||||
you register the network device. The
|
||||
<function>sppp_attach</function> requires that the first void *
|
||||
pointer in your private data is pointing to an empty struct
|
||||
ppp_device. The function fills in the initial data for the
|
||||
ppp/hdlc layer.
|
||||
If you wish to use the generic HDLC then you need to register
|
||||
the HDLC device.
|
||||
</para>
|
||||
<para>
|
||||
Before you register your network device you will also need to
|
||||
|
|
@ -314,10 +300,10 @@
|
|||
buffer in sk_buff format and queues it for transmission. The
|
||||
caller must provide the entire packet with the exception of the
|
||||
bitstuffing and CRC. This is normally done by the caller via
|
||||
the syncppp interface layer. It returns 0 if the buffer has been
|
||||
queued and non zero values for queue full. If the function accepts
|
||||
the buffer it becomes property of the Z8530 layer and the caller
|
||||
should not free it.
|
||||
the generic HDLC interface layer. It returns 0 if the buffer has been
|
||||
queued and non zero values for queue full. If the function accepts
|
||||
the buffer it becomes property of the Z8530 layer and the caller
|
||||
should not free it.
|
||||
</para>
|
||||
<para>
|
||||
The function <function>z8530_get_stats</function> returns a pointer
|
||||
|
|
|
|||
3
Documentation/Makefile
Normal file
3
Documentation/Makefile
Normal file
|
|
@ -0,0 +1,3 @@
|
|||
obj-m := DocBook/ accounting/ auxdisplay/ connector/ \
|
||||
filesystems/configfs/ ia64/ networking/ \
|
||||
pcmcia/ spi/ video4linux/ vm/ watchdog/src/
|
||||
10
Documentation/accounting/Makefile
Normal file
10
Documentation/accounting/Makefile
Normal file
|
|
@ -0,0 +1,10 @@
|
|||
# kbuild trick to avoid linker error. Can be omitted if a module is built.
|
||||
obj- := dummy.o
|
||||
|
||||
# List of programs to build
|
||||
hostprogs-y := getdelays
|
||||
|
||||
# Tell kbuild to always build the programs
|
||||
always := $(hostprogs-y)
|
||||
|
||||
HOSTCFLAGS_getdelays.o += -I$(objtree)/usr/include
|
||||
|
|
@ -201,13 +201,19 @@ void print_delayacct(struct taskstats *t)
|
|||
"RECLAIM %12s%15s\n"
|
||||
" %15llu%15llu\n",
|
||||
"count", "real total", "virtual total", "delay total",
|
||||
t->cpu_count, t->cpu_run_real_total, t->cpu_run_virtual_total,
|
||||
t->cpu_delay_total,
|
||||
(unsigned long long)t->cpu_count,
|
||||
(unsigned long long)t->cpu_run_real_total,
|
||||
(unsigned long long)t->cpu_run_virtual_total,
|
||||
(unsigned long long)t->cpu_delay_total,
|
||||
"count", "delay total",
|
||||
t->blkio_count, t->blkio_delay_total,
|
||||
"count", "delay total", t->swapin_count, t->swapin_delay_total,
|
||||
(unsigned long long)t->blkio_count,
|
||||
(unsigned long long)t->blkio_delay_total,
|
||||
"count", "delay total",
|
||||
t->freepages_count, t->freepages_delay_total);
|
||||
(unsigned long long)t->swapin_count,
|
||||
(unsigned long long)t->swapin_delay_total,
|
||||
"count", "delay total",
|
||||
(unsigned long long)t->freepages_count,
|
||||
(unsigned long long)t->freepages_delay_total);
|
||||
}
|
||||
|
||||
void task_context_switch_counts(struct taskstats *t)
|
||||
|
|
@ -215,14 +221,17 @@ void task_context_switch_counts(struct taskstats *t)
|
|||
printf("\n\nTask %15s%15s\n"
|
||||
" %15llu%15llu\n",
|
||||
"voluntary", "nonvoluntary",
|
||||
t->nvcsw, t->nivcsw);
|
||||
(unsigned long long)t->nvcsw, (unsigned long long)t->nivcsw);
|
||||
}
|
||||
|
||||
void print_cgroupstats(struct cgroupstats *c)
|
||||
{
|
||||
printf("sleeping %llu, blocked %llu, running %llu, stopped %llu, "
|
||||
"uninterruptible %llu\n", c->nr_sleeping, c->nr_io_wait,
|
||||
c->nr_running, c->nr_stopped, c->nr_uninterruptible);
|
||||
"uninterruptible %llu\n", (unsigned long long)c->nr_sleeping,
|
||||
(unsigned long long)c->nr_io_wait,
|
||||
(unsigned long long)c->nr_running,
|
||||
(unsigned long long)c->nr_stopped,
|
||||
(unsigned long long)c->nr_uninterruptible);
|
||||
}
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ Linux currently supports the following features on the IXP4xx chips:
|
|||
- Flash access (MTD/JFFS)
|
||||
- I2C through GPIO on IXP42x
|
||||
- GPIO for input/output/interrupts
|
||||
See include/asm-arm/arch-ixp4xx/platform.h for access functions.
|
||||
See arch/arm/mach-ixp4xx/include/mach/platform.h for access functions.
|
||||
- Timers (watchdog, OS)
|
||||
|
||||
The following components of the chips are not supported by Linux and
|
||||
|
|
|
|||
|
|
@ -158,7 +158,7 @@ So, what's changed?
|
|||
be re-checked for pending events. (see the Neponset IRQ handler for
|
||||
details).
|
||||
|
||||
7. fixup_irq() is gone, as is include/asm-arm/arch-*/irq.h
|
||||
7. fixup_irq() is gone, as is arch/arm/mach-*/include/mach/irq.h
|
||||
|
||||
Please note that this will not solve all problems - some of them are
|
||||
hardware based. Mixing level-based and edge-based IRQs on the same
|
||||
|
|
|
|||
|
|
@ -79,7 +79,7 @@ Machine/Platform support
|
|||
To this end, we now have arch/arm/mach-$(MACHINE) directories which are
|
||||
designed to house the non-driver files for a particular machine (eg, PCI,
|
||||
memory management, architecture definitions etc). For all future
|
||||
machines, there should be a corresponding include/asm-arm/arch-$(MACHINE)
|
||||
machines, there should be a corresponding arch/arm/mach-$(MACHINE)/include/mach
|
||||
directory.
|
||||
|
||||
|
||||
|
|
@ -176,7 +176,7 @@ Kernel entry (head.S)
|
|||
class typically based around one or more system on a chip devices, and
|
||||
acts as a natural container around the actual implementations. These
|
||||
classes are given directories - arch/arm/mach-<class> and
|
||||
include/asm-arm/arch-<class> - which contain the source files to
|
||||
arch/arm/mach-<class> - which contain the source files to/include/mach
|
||||
support the machine class. This directories also contain any machine
|
||||
specific supporting code.
|
||||
|
||||
|
|
|
|||
|
|
@ -13,16 +13,31 @@ Introduction
|
|||
data-sheet/users manual to find out the complete list.
|
||||
|
||||
|
||||
GPIOLIB
|
||||
-------
|
||||
|
||||
With the event of the GPIOLIB in drivers/gpio, support for some
|
||||
of the GPIO functions such as reading and writing a pin will
|
||||
be removed in favour of this common access method.
|
||||
|
||||
Once all the extant drivers have been converted, the functions
|
||||
listed below will be removed (they may be marked as __deprecated
|
||||
in the near future).
|
||||
|
||||
- s3c2410_gpio_getpin
|
||||
- s3c2410_gpio_setpin
|
||||
|
||||
|
||||
Headers
|
||||
-------
|
||||
|
||||
See include/asm-arm/arch-s3c2410/regs-gpio.h for the list
|
||||
See arch/arm/mach-s3c2410/include/mach/regs-gpio.h for the list
|
||||
of GPIO pins, and the configuration values for them. This
|
||||
is included by using #include <asm/arch/regs-gpio.h>
|
||||
is included by using #include <mach/regs-gpio.h>
|
||||
|
||||
The GPIO management functions are defined in the hardware
|
||||
header include/asm-arm/arch-s3c2410/hardware.h which can be
|
||||
included by #include <asm/arch/hardware.h>
|
||||
header arch/arm/mach-s3c2410/include/mach/hardware.h which can be
|
||||
included by #include <mach/hardware.h>
|
||||
|
||||
A useful amount of documentation can be found in the hardware
|
||||
header on how the GPIO functions (and others) work.
|
||||
|
|
|
|||
|
|
@ -8,9 +8,10 @@ Introduction
|
|||
|
||||
The Samsung S3C24XX range of ARM9 System-on-Chip CPUs are supported
|
||||
by the 's3c2410' architecture of ARM Linux. Currently the S3C2410,
|
||||
S3C2412, S3C2413, S3C2440 and S3C2442 devices are supported.
|
||||
S3C2412, S3C2413, S3C2440, S3C2442 and S3C2443 devices are supported.
|
||||
|
||||
Support for the S3C2400 and S3C24A0 series are in progress.
|
||||
|
||||
Support for the S3C2400 series is in progress.
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
|
@ -36,7 +37,23 @@ Layout
|
|||
in arch/arm/mach-s3c2410 and S3C2440 in arch/arm/mach-s3c2440
|
||||
|
||||
Register, kernel and platform data definitions are held in the
|
||||
include/asm-arm/arch-s3c2410 directory.
|
||||
arch/arm/mach-s3c2410 directory./include/mach
|
||||
|
||||
arch/arm/plat-s3c24xx:
|
||||
|
||||
Files in here are either common to all the s3c24xx family,
|
||||
or are common to only some of them with names to indicate this
|
||||
status. The files that are not common to all are generally named
|
||||
with the initial cpu they support in the series to ensure a short
|
||||
name without any possibility of confusion with newer devices.
|
||||
|
||||
As an example, initially s3c244x would cover s3c2440 and s3c2442, but
|
||||
with the s3c2443 which does not share many of the same drivers in
|
||||
this directory, the name becomes invalid. We stick to s3c2440-<x>
|
||||
to indicate a driver that is s3c2440 and s3c2442 compatible.
|
||||
|
||||
This does mean that to find the status of any given SoC, a number
|
||||
of directories may need to be searched.
|
||||
|
||||
|
||||
Machines
|
||||
|
|
@ -159,6 +176,17 @@ NAND
|
|||
For more information see Documentation/arm/Samsung-S3C24XX/NAND.txt
|
||||
|
||||
|
||||
SD/MMC
|
||||
------
|
||||
|
||||
The SD/MMC hardware pre S3C2443 is supported in the current
|
||||
kernel, the driver is drivers/mmc/host/s3cmci.c and supports
|
||||
1 and 4 bit SD or MMC cards.
|
||||
|
||||
The SDIO behaviour of this driver has not been fully tested. There is no
|
||||
current support for hardware SDIO interrupts.
|
||||
|
||||
|
||||
Serial
|
||||
------
|
||||
|
||||
|
|
@ -178,6 +206,9 @@ GPIO
|
|||
The core contains support for manipulating the GPIO, see the
|
||||
documentation in GPIO.txt in the same directory as this file.
|
||||
|
||||
Newer kernels carry GPIOLIB, and support is being moved towards
|
||||
this with some of the older support in line to be removed.
|
||||
|
||||
|
||||
Clock Management
|
||||
----------------
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ Board Support
|
|||
Platform Data
|
||||
-------------
|
||||
|
||||
See linux/include/asm-arm/arch-s3c2410/usb-control.h for the
|
||||
See arch/arm/mach-s3c2410/include/mach/usb-control.h for the
|
||||
descriptions of the platform device data. An implementation
|
||||
can be found in linux/arch/arm/mach-s3c2410/usb-simtec.c .
|
||||
|
||||
|
|
|
|||
10
Documentation/auxdisplay/Makefile
Normal file
10
Documentation/auxdisplay/Makefile
Normal file
|
|
@ -0,0 +1,10 @@
|
|||
# kbuild trick to avoid linker error. Can be omitted if a module is built.
|
||||
obj- := dummy.o
|
||||
|
||||
# List of programs to build
|
||||
hostprogs-y := cfag12864b-example
|
||||
|
||||
# Tell kbuild to always build the programs
|
||||
always := $(hostprogs-y)
|
||||
|
||||
HOSTCFLAGS_cfag12864b-example.o += -I$(objtree)/usr/include
|
||||
|
|
@ -112,27 +112,18 @@ Hot plug support for SCSI tape drives
|
|||
|
||||
Hot plugging of SCSI tape drives is supported, with some caveats.
|
||||
The cciss driver must be informed that changes to the SCSI bus
|
||||
have been made, in addition to and prior to informing the SCSI
|
||||
mid layer. This may be done via the /proc filesystem. For example:
|
||||
have been made. This may be done via the /proc filesystem.
|
||||
For example:
|
||||
|
||||
echo "rescan" > /proc/scsi/cciss0/1
|
||||
|
||||
This causes the adapter to query the adapter about changes to the
|
||||
physical SCSI buses and/or fibre channel arbitrated loop and the
|
||||
This causes the driver to query the adapter about changes to the
|
||||
physical SCSI buses and/or fibre channel arbitrated loop and the
|
||||
driver to make note of any new or removed sequential access devices
|
||||
or medium changers. The driver will output messages indicating what
|
||||
devices have been added or removed and the controller, bus, target and
|
||||
lun used to address the device. Once this is done, the SCSI mid layer
|
||||
can be informed of changes to the virtual SCSI bus which the driver
|
||||
presents to it in the usual way. For example:
|
||||
|
||||
echo scsi add-single-device 3 2 1 0 > /proc/scsi/scsi
|
||||
|
||||
to add a device on controller 3, bus 2, target 1, lun 0. Note that
|
||||
the driver makes an effort to preserve the devices positions
|
||||
in the virtual SCSI bus, so if you are only moving tape drives
|
||||
around on the same adapter and not adding or removing tape drives
|
||||
from the adapter, informing the SCSI mid layer may not be necessary.
|
||||
lun used to address the device. It then notifies the SCSI mid layer
|
||||
of these changes.
|
||||
|
||||
Note that the naming convention of the /proc filesystem entries
|
||||
contains a number in addition to the driver name. (E.g. "cciss0"
|
||||
|
|
|
|||
|
|
@ -1,133 +0,0 @@
|
|||
|
||||
#### cli()/sti() removal guide, started by Ingo Molnar <mingo@redhat.com>
|
||||
|
||||
|
||||
as of 2.5.28, five popular macros have been removed on SMP, and
|
||||
are being phased out on UP:
|
||||
|
||||
cli(), sti(), save_flags(flags), save_flags_cli(flags), restore_flags(flags)
|
||||
|
||||
until now it was possible to protect driver code against interrupt
|
||||
handlers via a cli(), but from now on other, more lightweight methods
|
||||
have to be used for synchronization, such as spinlocks or semaphores.
|
||||
|
||||
for example, driver code that used to do something like:
|
||||
|
||||
struct driver_data;
|
||||
|
||||
irq_handler (...)
|
||||
{
|
||||
....
|
||||
driver_data.finish = 1;
|
||||
driver_data.new_work = 0;
|
||||
....
|
||||
}
|
||||
|
||||
...
|
||||
|
||||
ioctl_func (...)
|
||||
{
|
||||
...
|
||||
cli();
|
||||
...
|
||||
driver_data.finish = 0;
|
||||
driver_data.new_work = 2;
|
||||
...
|
||||
sti();
|
||||
...
|
||||
}
|
||||
|
||||
was SMP-correct because the cli() function ensured that no
|
||||
interrupt handler (amongst them the above irq_handler()) function
|
||||
would execute while the cli()-ed section is executing.
|
||||
|
||||
but from now on a more direct method of locking has to be used:
|
||||
|
||||
DEFINE_SPINLOCK(driver_lock);
|
||||
struct driver_data;
|
||||
|
||||
irq_handler (...)
|
||||
{
|
||||
unsigned long flags;
|
||||
....
|
||||
spin_lock_irqsave(&driver_lock, flags);
|
||||
....
|
||||
driver_data.finish = 1;
|
||||
driver_data.new_work = 0;
|
||||
....
|
||||
spin_unlock_irqrestore(&driver_lock, flags);
|
||||
....
|
||||
}
|
||||
|
||||
...
|
||||
|
||||
ioctl_func (...)
|
||||
{
|
||||
...
|
||||
spin_lock_irq(&driver_lock);
|
||||
...
|
||||
driver_data.finish = 0;
|
||||
driver_data.new_work = 2;
|
||||
...
|
||||
spin_unlock_irq(&driver_lock);
|
||||
...
|
||||
}
|
||||
|
||||
the above code has a number of advantages:
|
||||
|
||||
- the locking relation is easier to understand - actual lock usage
|
||||
pinpoints the critical sections. cli() usage is too opaque.
|
||||
Easier to understand means it's easier to debug.
|
||||
|
||||
- it's faster, because spinlocks are faster to acquire than the
|
||||
potentially heavily-used IRQ lock. Furthermore, your driver does
|
||||
not have to wait eg. for a big heavy SCSI interrupt to finish,
|
||||
because the driver_lock spinlock is only used by your driver.
|
||||
cli() on the other hand was used by many drivers, and extended
|
||||
the critical section to the whole IRQ handler function - creating
|
||||
serious lock contention.
|
||||
|
||||
|
||||
to make the transition easier, we've still kept the cli(), sti(),
|
||||
save_flags(), save_flags_cli() and restore_flags() macros defined
|
||||
on UP systems - but their usage will be phased out until 2.6 is
|
||||
released.
|
||||
|
||||
drivers that want to disable local interrupts (interrupts on the
|
||||
current CPU), can use the following five macros:
|
||||
|
||||
local_irq_disable(), local_irq_enable(), local_save_flags(flags),
|
||||
local_irq_save(flags), local_irq_restore(flags)
|
||||
|
||||
but beware, their meaning and semantics are much simpler, far from
|
||||
that of the old cli(), sti(), save_flags(flags) and restore_flags(flags)
|
||||
SMP meaning:
|
||||
|
||||
local_irq_disable() => turn local IRQs off
|
||||
|
||||
local_irq_enable() => turn local IRQs on
|
||||
|
||||
local_save_flags(flags) => save the current IRQ state into flags. The
|
||||
state can be on or off. (on some
|
||||
architectures there's even more bits in it.)
|
||||
|
||||
local_irq_save(flags) => save the current IRQ state into flags and
|
||||
disable interrupts.
|
||||
|
||||
local_irq_restore(flags) => restore the IRQ state from flags.
|
||||
|
||||
(local_irq_save can save both irqs on and irqs off state, and
|
||||
local_irq_restore can restore into both irqs on and irqs off state.)
|
||||
|
||||
another related change is that synchronize_irq() now takes a parameter:
|
||||
synchronize_irq(irq). This change too has the purpose of making SMP
|
||||
synchronization more lightweight - this way you can wait for your own
|
||||
interrupt handler to finish, no need to wait for other IRQ sources.
|
||||
|
||||
|
||||
why were these changes done? The main reason was the architectural burden
|
||||
of maintaining the cli()/sti() interface - it became a real problem. The
|
||||
new interrupt system is much more streamlined, easier to understand, debug,
|
||||
and it's also a bit faster - the same happened to it that will happen to
|
||||
cli()/sti() using drivers once they convert to spinlocks :-)
|
||||
|
||||
11
Documentation/connector/Makefile
Normal file
11
Documentation/connector/Makefile
Normal file
|
|
@ -0,0 +1,11 @@
|
|||
ifneq ($(CONFIG_CONNECTOR),)
|
||||
obj-m += cn_test.o
|
||||
endif
|
||||
|
||||
# List of programs to build
|
||||
hostprogs-y := ucon
|
||||
|
||||
# Tell kbuild to always build the programs
|
||||
always := $(hostprogs-y)
|
||||
|
||||
HOSTCFLAGS_ucon.o += -I$(objtree)/usr/include
|
||||
|
|
@ -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
|
||||
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.
|
||||
This option sets possible_cpus bits in
|
||||
cpu_possible_map. Thus keeping the numbers of bits set
|
||||
constant even if the machine gets rebooted.
|
||||
This option overrides additional_cpus.
|
||||
|
||||
CPU maps and such
|
||||
-----------------
|
||||
|
|
|
|||
|
|
@ -2560,9 +2560,6 @@ Your cooperation is appreciated.
|
|||
96 = /dev/usb/hiddev0 1st 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
|
||||
...
|
||||
131 = /dev/usb/brlvgr3 Fourth Braille Voyager device
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
When: December 2008
|
||||
Files: include/linux/video_decoder.h include/linux/videodev.h
|
||||
|
|
@ -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
|
||||
When: April 2010
|
||||
|
||||
|
|
|
|||
3
Documentation/filesystems/configfs/Makefile
Normal file
3
Documentation/filesystems/configfs/Makefile
Normal file
|
|
@ -0,0 +1,3 @@
|
|||
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
|
|||
|
||||
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:
|
||||
|
||||
# mke2fs -t ext4dev /dev/hda1
|
||||
|
|
|
|||
|
|
@ -3,14 +3,14 @@ Quota subsystem
|
|||
===============
|
||||
|
||||
Quota subsystem allows system administrator to set limits on used space and
|
||||
number of used inodes (inode is a filesystem structure which is associated
|
||||
with each file or directory) for users and/or groups. For both used space and
|
||||
number of used inodes there are actually two limits. The first one is called
|
||||
softlimit and the second one hardlimit. An user can never exceed a hardlimit
|
||||
for any resource. User is allowed to exceed softlimit but only for limited
|
||||
period of time. This period is called "grace period" or "grace time". When
|
||||
grace time is over, user is not able to allocate more space/inodes until he
|
||||
frees enough of them to get below softlimit.
|
||||
number of used inodes (inode is a filesystem structure which is associated with
|
||||
each file or directory) for users and/or groups. For both used space and number
|
||||
of used inodes there are actually two limits. The first one is called softlimit
|
||||
and the second one hardlimit. An user can never exceed a hardlimit for any
|
||||
resource (unless he has CAP_SYS_RESOURCE capability). User is allowed to exceed
|
||||
softlimit but only for limited period of time. This period is called "grace
|
||||
period" or "grace time". When grace time is over, user is not able to allocate
|
||||
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
|
||||
filesystem.
|
||||
|
|
@ -53,6 +53,12 @@ in parentheses):
|
|||
QUOTA_NL_BSOFTLONGWARN - space (block) softlimit is exceeded
|
||||
longer than given grace period.
|
||||
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)
|
||||
- major number of a device with the affected filesystem
|
||||
QUOTA_NL_A_DEV_MINOR (u32)
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
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
|
||||
structures are consistent.
|
||||
|
||||
|
|
|
|||
|
|
@ -10,6 +10,10 @@ Supported chips:
|
|||
Prefix: 'sch311x'
|
||||
Addresses scanned: none, address read from Super-I/O config space
|
||||
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:
|
||||
Juerg Haefliger <juergh@gmail.com>
|
||||
|
|
@ -27,33 +31,31 @@ Module Parameters
|
|||
following boards:
|
||||
- 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
|
||||
-----------
|
||||
|
||||
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
|
||||
chips. These chips feature monitoring of 3 temp sensors temp[1-3] (2 remote
|
||||
diodes and 1 internal), 7 voltages in[0-6] (6 external and 1 internal) and up
|
||||
to 6 fan speeds fan[1-6]. Additionally, the chips implement up to 5 PWM
|
||||
outputs pwm[1-3,5-6] for controlling fan speeds both manually and
|
||||
SMSC DME1737 and Asus A8000 (which are the same), SMSC SCH5027, and SMSC
|
||||
SCH311x Super-I/O chips. These chips feature monitoring of 3 temp sensors
|
||||
temp[1-3] (2 remote diodes and 1 internal), 7 voltages in[0-6] (6 external and
|
||||
1 internal) and up to 6 fan speeds fan[1-6]. Additionally, the chips implement
|
||||
up to 5 PWM outputs pwm[1-3,5-6] for controlling fan speeds both manually and
|
||||
automatically.
|
||||
|
||||
For the DME1737 and A8000, fan[1-2] and pwm[1-2] are always present. Fan[3-6]
|
||||
and pwm[3,5-6] are optional features and their availability depends on the
|
||||
configuration of the chip. The driver will detect which features are present
|
||||
during initialization and create the sysfs attributes accordingly.
|
||||
For the DME1737, A8000 and SCH5027, fan[1-2] and pwm[1-2] are always present.
|
||||
Fan[3-6] and pwm[3,5-6] are optional features and their availability depends on
|
||||
the configuration of the chip. The driver will detect which features are
|
||||
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
|
||||
pwm[5-6] don't exist.
|
||||
|
||||
The hardware monitoring features of the DME1737 and A8000 are only accessible
|
||||
via SMBus, while the SCH311x only provides access via the ISA bus. The driver
|
||||
will therefore register itself as an I2C client driver if it detects a DME1737
|
||||
or A8000 and as a platform driver if it detects a SCH311x chip.
|
||||
The hardware monitoring features of the DME1737, A8000, and SCH5027 are only
|
||||
accessible via SMBus, while the SCH311x only provides access via the ISA bus.
|
||||
The driver will therefore register itself as an I2C client driver if it detects
|
||||
a DME1737, A8000, or SCH5027 and as a platform driver if it detects a SCH311x
|
||||
chip.
|
||||
|
||||
|
||||
Voltage Monitoring
|
||||
|
|
@ -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
|
||||
(the last column indicates the input ranges):
|
||||
|
||||
DME1737, A8000:
|
||||
in0: +5VTR (+5V standby) 0V - 6.64V
|
||||
in1: Vccp (processor core) 0V - 3V
|
||||
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
|
|||
in5: VTR (+3.3V standby) 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
|
||||
when crossed.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,8 +1,11 @@
|
|||
Kernel driver ibmaem
|
||||
======================
|
||||
|
||||
This driver talks to the IBM Systems Director Active Energy Manager, known
|
||||
henceforth as AEM.
|
||||
|
||||
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,
|
||||
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.
|
||||
|
|
@ -14,24 +17,22 @@ Author: Darrick J. Wong
|
|||
Description
|
||||
-----------
|
||||
|
||||
This driver implements sensor reading support for the energy and power
|
||||
meters available on various IBM System X hardware through the BMC. All
|
||||
sensor banks will be exported as platform devices; this driver can talk
|
||||
to both v1 and v2 interfaces. This driver is completely separate from the
|
||||
older ibmpex driver.
|
||||
This driver implements sensor reading support for the energy and power meters
|
||||
available on various IBM System X hardware through the BMC. All sensor banks
|
||||
will be exported as platform devices; this driver can talk to both v1 and v2
|
||||
interfaces. This driver is completely separate from the older ibmpex driver.
|
||||
|
||||
The v1 AEM interface has a simple set of features to monitor energy use.
|
||||
There is a register that displays an estimate of raw energy consumption
|
||||
since the last BMC reset, and a power sensor that returns average power
|
||||
use over a configurable interval.
|
||||
The v1 AEM interface has a simple set of features to monitor energy use. There
|
||||
is a register that displays an estimate of raw energy consumption since the
|
||||
last BMC reset, and a power sensor that returns average power use over a
|
||||
configurable interval.
|
||||
|
||||
The v2 AEM interface is a bit more sophisticated, being able to present
|
||||
a wider range of energy and power use registers, the power cap as
|
||||
set by the AEM software, and temperature sensors.
|
||||
The v2 AEM interface is a bit more sophisticated, being able to present a wider
|
||||
range of energy and power use registers, the power cap as set by the AEM
|
||||
software, and temperature sensors.
|
||||
|
||||
Special Features
|
||||
----------------
|
||||
|
||||
The "power_cap" value displays the current system power cap, as set by
|
||||
the Active Energy Manager software. Setting the power cap from the host
|
||||
is not currently supported.
|
||||
The "power_cap" value displays the current system power cap, as set by the AEM
|
||||
software. Setting the power cap from the host is not currently supported.
|
||||
|
|
|
|||
|
|
@ -6,12 +6,14 @@ Supported chips:
|
|||
Prefix: 'it87'
|
||||
Addresses scanned: from Super I/O config space (8 I/O ports)
|
||||
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
|
||||
Prefix: 'it8712'
|
||||
Addresses scanned: from Super I/O config space (8 I/O ports)
|
||||
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
|
||||
Prefix: 'it8716'
|
||||
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
|
|||
can't have both on a given board.
|
||||
|
||||
The IT8716F, IT8718F and later IT8712F revisions have support for
|
||||
2 additional fans. They are supported by the driver for the IT8716F and
|
||||
IT8718F but not for the IT8712F
|
||||
2 additional fans. The additional fans are supported by the driver.
|
||||
|
||||
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
|
||||
clock divider mess) but not compatible with the older chips and
|
||||
revisions. For now, the driver only uses the 16-bit mode on the
|
||||
IT8716F and IT8718F.
|
||||
revisions. The 16-bit tachometer mode is enabled by the driver when one
|
||||
of the above chips is detected.
|
||||
|
||||
The IT8726F is just bit enhanced IT8716F with additional hardware
|
||||
for AMD power sequencing. Therefore the chip will appear as IT8716F
|
||||
|
|
|
|||
|
|
@ -40,10 +40,6 @@ Module Parameters
|
|||
(default is 1)
|
||||
Use 'init=0' to bypass initializing the chip.
|
||||
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
|
||||
-----------
|
||||
|
|
|
|||
|
|
@ -22,6 +22,7 @@ Credits:
|
|||
|
||||
Additional contributors:
|
||||
Sven Anders <anders@anduras.de>
|
||||
Marc Hulsman <m.hulsman@tudelft.nl>
|
||||
|
||||
Module Parameters
|
||||
-----------------
|
||||
|
|
@ -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
|
||||
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
|
||||
and 1, 2, 4, 8, 16, 32, 64 or 128 for fan 4/5) to give the readings more
|
||||
range or accuracy.
|
||||
readings can be divided by a programmable divider (1, 2, 4, 8, 16,
|
||||
32, 64 or 128 for all fans) to give the readings more range or accuracy.
|
||||
|
||||
Voltage sensors (also known as IN sensors) report their values in millivolts.
|
||||
An alarm is triggered if the voltage has crossed a programmable minimum
|
||||
|
|
|
|||
8
Documentation/ia64/Makefile
Normal file
8
Documentation/ia64/Makefile
Normal file
|
|
@ -0,0 +1,8 @@
|
|||
# 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
|
|||
'T' all linux/soundcard.h conflict!
|
||||
'T' all asm-i386/ioctls.h conflict!
|
||||
'U' 00-EF linux/drivers/usb/usb.h
|
||||
'U' F0-FF drivers/usb/auerswald.c
|
||||
'V' all linux/vt.h
|
||||
'W' 00-1F linux/watchdog.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
|
|||
fork. So if you have any comments or updates for this file, please try
|
||||
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/ >
|
||||
翻訳日： 2007/11/10
|
||||
翻訳日： 2008/8/5
|
||||
翻訳者： Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com>
|
||||
校正者： 松倉さん <nbh--mats at nifty dot com>
|
||||
小林 雅典さん (Masanori Kobayasi) <zap03216 at nifty dot ne dot jp>
|
||||
|
|
@ -287,13 +287,15 @@ Linux カーネルの開発プロセスは現在幾つかの異なるメイン
|
|||
に安定した状態にあると判断したときにリリースされます。目標は毎週新
|
||||
しい -rc カーネルをリリースすることです。
|
||||
|
||||
- 以下の URL で各 -rc リリースに存在する既知の後戻り問題のリスト
|
||||
が追跡されます-
|
||||
http://kernelnewbies.org/known_regressions
|
||||
|
||||
- このプロセスはカーネルが 「準備ができた」と考えられるまで継続しま
|
||||
す。このプロセスはだいたい 6週間継続します。
|
||||
|
||||
- 各リリースでの既知の後戻り問題(regression: このリリースの中で新規
|
||||
に作り込まれた問題を指す) はその都度 Linux-kernel メーリングリスト
|
||||
に投稿されます。ゴールとしては、カーネルが 「準備ができた」と宣言
|
||||
する前にこのリストの長さをゼロに減らすことですが、現実には、数個の
|
||||
後戻り問題がリリース時にたびたび残ってしまいます。
|
||||
|
||||
Andrew Morton が Linux-kernel メーリングリストにカーネルリリースについ
|
||||
て書いたことをここで言っておくことは価値があります-
|
||||
「カーネルがいつリリースされるかは誰も知りません。なぜなら、これは現
|
||||
|
|
@ -303,18 +305,20 @@ Andrew Morton が Linux-kernel メーリングリストにカーネルリリー
|
|||
2.6.x.y -stable カーネルツリー
|
||||
---------------------------
|
||||
|
||||
バージョンに4つ目の数字がついたカーネルは -stable カーネルです。これに
|
||||
は、2.6.x カーネルで見つかったセキュリティ問題や重大な後戻りに対する比
|
||||
較的小さい重要な修正が含まれます。
|
||||
バージョン番号が4つの数字に分かれているカーネルは -stable カーネルです。
|
||||
これには、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 ファ
|
||||
イルにはどのような種類の変更が -stable ツリーに受け入れ可能か、またリ
|
||||
|
|
@ -341,7 +345,9 @@ linux-kernel メーリングリストで収集された多数のパッチと同
|
|||
メインラインへ入れるように Linus にプッシュします。
|
||||
|
||||
メインカーネルツリーに含めるために Linus に送る前に、すべての新しいパッ
|
||||
チが -mm ツリーでテストされることが強く推奨されます。
|
||||
チが -mm ツリーでテストされることが強く推奨されています。マージウィン
|
||||
ドウが開く前に -mm ツリーに現れなかったパッチはメインラインにマージさ
|
||||
れることは困難になります。
|
||||
|
||||
これらのカーネルは安定して動作すべきシステムとして使うのには適切ではあ
|
||||
りませんし、カーネルブランチの中でももっとも動作にリスクが高いものです。
|
||||
|
|
@ -395,13 +401,15 @@ linux-kernel メーリングリストで収集された多数のパッチと同
|
|||
- pcmcia, Dominik Brodowski <linux@dominikbrodowski.net>
|
||||
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
|
||||
|
||||
- x86, Ingo Molnar <mingo@elte.hu>
|
||||
git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
|
||||
|
||||
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/
|
||||
- x86-64 と i386 の仲間 Andi Kleen <ak@suse.de>
|
||||
|
||||
その他のカーネルツリーは http://git.kernel.org/ と MAINTAINERS ファ
|
||||
イルに一覧表があります。
|
||||
|
|
@ -412,13 +420,32 @@ linux-kernel メーリングリストで収集された多数のパッチと同
|
|||
bugzilla.kernel.org は Linux カーネル開発者がカーネルのバグを追跡する
|
||||
場所です。ユーザは見つけたバグの全てをこのツールで報告すべきです。
|
||||
どう kernel bugzilla を使うかの詳細は、以下を参照してください-
|
||||
http://test.kernel.org/bugzilla/faq.html
|
||||
|
||||
http://bugzilla.kernel.org/page.cgi?id=faq.html
|
||||
メインカーネルソースディレクトリにあるファイル 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
|
||||
|
||||
メーリングリスト
|
||||
-------------
|
||||
|
||||
|
|
|
|||
111
Documentation/ja_JP/SubmitChecklist
Normal file
111
Documentation/ja_JP/SubmitChecklist
Normal file
|
|
@ -0,0 +1,111 @@
|
|||
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' は明示的に問題を示しませんが、どれか
|
||||
１つの関数が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
|
|||
no delay (0).
|
||||
Format: integer
|
||||
|
||||
bootmem_debug [KNL] Enable bootmem allocator debug messages.
|
||||
|
||||
bttv.card= [HW,V4L] bttv (bt848 + bt878 based grabber cards)
|
||||
bttv.radio= Most important insmod options are available as
|
||||
kernel args too.
|
||||
|
|
@ -1072,6 +1074,9 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
|
||||
* [no]ncq: Turn on or off NCQ.
|
||||
|
||||
* nohrst, nosrst, norst: suppress hard, soft
|
||||
and both resets.
|
||||
|
||||
If there are multiple matching configurations changing
|
||||
the same attribute, the last one is used.
|
||||
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
{
|
||||
struct itimerval itm;
|
||||
|
|
@ -939,6 +942,11 @@ static void handle_net_output(int fd, struct virtqueue *vq, bool timeout)
|
|||
if (!timeout && num)
|
||||
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 (num < last_timeout_num)
|
||||
timeout_usec += 10;
|
||||
|
|
@ -1447,21 +1455,6 @@ static void configure_device(int fd, const char *tapif, u32 ipaddr)
|
|||
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])
|
||||
{
|
||||
struct ifreq ifr;
|
||||
|
|
@ -1531,11 +1524,8 @@ static void setup_tun_net(char *arg)
|
|||
p = strchr(arg, ':');
|
||||
if (p) {
|
||||
str2mac(p+1, conf.mac);
|
||||
add_feature(dev, VIRTIO_NET_F_MAC);
|
||||
*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 */
|
||||
|
|
@ -1547,13 +1537,10 @@ static void setup_tun_net(char *arg)
|
|||
/* Set up the tun device. */
|
||||
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);
|
||||
/* Expect Guest to handle everything except UFO */
|
||||
add_feature(dev, VIRTIO_NET_F_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_TSO6);
|
||||
add_feature(dev, VIRTIO_NET_F_GUEST_ECN);
|
||||
|
|
|
|||
8
Documentation/networking/Makefile
Normal file
8
Documentation/networking/Makefile
Normal file
|
|
@ -0,0 +1,8 @@
|
|||
# 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)
|
|||
|
||||
}
|
||||
|
||||
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",
|
||||
slave_ifname, ifra[i].desc,
|
||||
ipaddr[0], ipaddr[1], ipaddr[2], ipaddr[3]);
|
||||
|
|
|
|||
10
Documentation/pcmcia/Makefile
Normal file
10
Documentation/pcmcia/Makefile
Normal file
|
|
@ -0,0 +1,10 @@
|
|||
# kbuild trick to avoid linker error. Can be omitted if a module is built.
|
||||
obj- := dummy.o
|
||||
|
||||
# List of programs to build
|
||||
hostprogs-y := 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) {
|
|||
printf("no string passed as argument\n");
|
||||
return -1;
|
||||
}
|
||||
result = crc32(argv[1], strlen(argv[1]));
|
||||
result = crc32((unsigned char const *)argv[1], strlen(argv[1]));
|
||||
printf("0x%x\n", result);
|
||||
return 0;
|
||||
}
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
PM quality of Service interface.
|
||||
PM Quality Of Service Interface.
|
||||
|
||||
This interface provides a kernel and user mode interface for registering
|
||||
performance expectations by drivers, subsystems and user space applications on
|
||||
|
|
@ -7,6 +7,11 @@ one of the parameters.
|
|||
Currently we have {cpu_dma_latency, network_latency, network_throughput} as the
|
||||
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
|
||||
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
|
||||
|
|
|
|||
|
|
@ -278,7 +278,7 @@ it with special cases.
|
|||
a 64-bit 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:
|
||||
|
||||
|
|
@ -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
|
||||
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:
|
||||
|
||||
struct boot_param_header {
|
||||
|
|
|
|||
|
|
@ -133,7 +133,7 @@ error. Given an arbitrary address, the routine
|
|||
pci_get_device_by_addr() will find the pci device associated
|
||||
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.
|
||||
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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
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:
|
||||
--------------------------------------------------------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,26 @@
|
|||
|
||||
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 -
|
||||
(emaild-id:megaraidlinux@lsi.com)
|
||||
Sumant Patro
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
Power management is _not_ supported.
|
||||
|
||||
Module snd-ice1712
|
||||
------------------
|
||||
|
||||
|
|
@ -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.
|
||||
|
||||
Power management is _not_ supported.
|
||||
|
||||
Module snd-pcsp
|
||||
-----------------
|
||||
|
||||
|
|
@ -2081,13 +2077,11 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
Module snd-virtuoso
|
||||
-------------------
|
||||
|
||||
Module for sound cards based on the Asus AV200 chip, i.e.,
|
||||
Xonar D2 and Xonar D2X.
|
||||
Module for sound cards based on the Asus AV100/AV200 chips,
|
||||
i.e., Xonar D1, DX, D2 and D2X.
|
||||
|
||||
This module supports autoprobe and multiple cards.
|
||||
|
||||
Power management is _not_ supported.
|
||||
|
||||
Module snd-vx222
|
||||
----------------
|
||||
|
||||
|
|
|
|||
11
Documentation/spi/Makefile
Normal file
11
Documentation/spi/Makefile
Normal file
|
|
@ -0,0 +1,11 @@
|
|||
# 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
|
|||
-----------------------------------
|
||||
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
|
||||
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 {
|
||||
enum pxa_ssp_type ssp_type;
|
||||
|
|
@ -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
|
||||
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
|
||||
device.
|
||||
|
||||
|
|
|
|||
|
|
@ -210,7 +210,7 @@ board should normally be set up and registered.
|
|||
|
||||
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
|
||||
* 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:
|
|||
|
||||
And SOC-specific utility code might look something like:
|
||||
|
||||
#include <asm/arch/spi.h>
|
||||
#include <mach/spi.h>
|
||||
|
||||
static struct platform_device spi2 = { ... };
|
||||
|
||||
|
|
|
|||
|
|
@ -1,30 +0,0 @@
|
|||
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
|
|||
suspend/resume events as well.
|
||||
|
||||
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
|
||||
usb_autopm_* routines, the driver can avoid deadlock by doing:
|
||||
|
||||
|
|
|
|||
8
Documentation/video4linux/Makefile
Normal file
8
Documentation/video4linux/Makefile
Normal file
|
|
@ -0,0 +1,8 @@
|
|||
# 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
|
|||
sonixj 0c45:6138 Sn9c120 Mo4000
|
||||
sonixj 0c45:613b Surfer SN-206
|
||||
sonixj 0c45:613c Sonix Pccam168
|
||||
sonixj 0c45:6143 Sonix Pccam168
|
||||
sunplus 0d64:0303 Sunplus FashionCam DXG
|
||||
etoms 102c:6151 Qcam Sangha CIF
|
||||
etoms 102c:6251 Qcam xxxxxx VGA
|
||||
|
|
|
|||
8
Documentation/vm/Makefile
Normal file
8
Documentation/vm/Makefile
Normal file
|
|
@ -0,0 +1,8 @@
|
|||
# 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
|
|||
process that are located on the from nodes to the destination nodes.
|
||||
Page migration functions are provided by the numactl package by Andi Kleen
|
||||
(a version later than 0.9.3 is required. Get it from
|
||||
ftp://ftp.suse.com/pub/people/ak). numactl provided libnuma which
|
||||
provides an interface similar to other numa functionality for page migration.
|
||||
cat /proc/<pid>/numa_maps allows an easy review of where the pages of
|
||||
a process are located. See also the numa_maps manpage in the numactl package.
|
||||
ftp://oss.sgi.com/www/projects/libnuma/download/). numactl provides libnuma
|
||||
which provides an interface similar to other numa functionality for page
|
||||
migration. cat /proc/<pid>/numa_maps allows an easy review of where the
|
||||
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
|
||||
a process to a processor on a distant node. A batch scheduler or an
|
||||
|
|
|
|||
8
Documentation/watchdog/src/Makefile
Normal file
8
Documentation/watchdog/src/Makefile
Normal file
|
|
@ -0,0 +1,8 @@
|
|||
# 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)
|
||||
154
MAINTAINERS
154
MAINTAINERS
|
|
@ -175,12 +175,18 @@ M: bcrl@kvack.org
|
|||
L: linux-aio@kvack.org
|
||||
S: Supported
|
||||
|
||||
ABIT UGURU HARDWARE MONITOR DRIVER
|
||||
ABIT UGURU 1,2 HARDWARE MONITOR DRIVER
|
||||
P: Hans de Goede
|
||||
M: j.w.r.degoede@hhs.nl
|
||||
L: lm-sensors@lm-sensors.org
|
||||
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
|
||||
P: Jes Sorensen
|
||||
M: jes@trained-monkey.org
|
||||
|
|
@ -502,6 +508,12 @@ L: openezx-devel@lists.openezx.org (subscribers-only)
|
|||
W: http://www.openezx.org/
|
||||
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
|
||||
P: Lennert Buytenhek
|
||||
M: kernel@wantstofly.org
|
||||
|
|
@ -588,6 +600,11 @@ M: kernel@wantstofly.org
|
|||
L: linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only)
|
||||
S: Maintained
|
||||
|
||||
ARM/MAGICIAN MACHINE SUPPORT
|
||||
P: Philipp Zabel
|
||||
M: philipp.zabel@gmail.com
|
||||
S: Maintained
|
||||
|
||||
ARM/TOSA MACHINE SUPPORT
|
||||
P: Dmitry Baryshkov
|
||||
M: dbaryshkov@gmail.com
|
||||
|
|
@ -714,6 +731,15 @@ L: linux-wireless@vger.kernel.org
|
|||
L: ath5k-devel@lists.ath5k.org
|
||||
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
|
||||
P: Ville Syrjala
|
||||
M: syrjala@sci.fi
|
||||
|
|
@ -916,96 +942,21 @@ M: joern@lazybastard.org
|
|||
L: linux-mtd@lists.infradead.org
|
||||
S: Maintained
|
||||
|
||||
BLUETOOTH DRIVERS
|
||||
P: Marcel Holtmann
|
||||
M: marcel@holtmann.org
|
||||
L: linux-bluetooth@vger.kernel.org
|
||||
W: http://www.bluez.org/
|
||||
S: Maintained
|
||||
|
||||
BLUETOOTH SUBSYSTEM
|
||||
P: Marcel Holtmann
|
||||
M: marcel@holtmann.org
|
||||
P: Maxim Krasnyansky
|
||||
M: maxk@qualcomm.com
|
||||
L: linux-bluetooth@vger.kernel.org
|
||||
W: http://bluez.sf.net
|
||||
W: http://www.bluez.org
|
||||
W: http://www.holtmann.org/linux/bluetooth/
|
||||
W: http://www.bluez.org/
|
||||
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
|
||||
|
||||
BLUETOOTH BNEP LAYER
|
||||
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
|
||||
M: marcel@holtmann.org
|
||||
S: Maintained
|
||||
|
||||
BLUETOOTH HCI VHCI DRIVER
|
||||
P: Maxim Krasnyansky
|
||||
M: maxk@qualcomm.com
|
||||
S: Maintained
|
||||
|
||||
BONDING DRIVER
|
||||
P: Jay Vosburgh
|
||||
M: fubar@us.ibm.com
|
||||
|
|
@ -1229,7 +1180,7 @@ S: Maintained
|
|||
CPU FREQUENCY DRIVERS
|
||||
P: Dave Jones
|
||||
M: davej@codemonkey.org.uk
|
||||
L: cpufreq@lists.linux.org.uk
|
||||
L: cpufreq@vger.kernel.org
|
||||
W: http://www.codemonkey.org.uk/projects/cpufreq/
|
||||
T: git kernel.org/pub/scm/linux/kernel/git/davej/cpufreq.git
|
||||
S: Maintained
|
||||
|
|
@ -2442,7 +2393,7 @@ L: kernel-janitors@vger.kernel.org
|
|||
W: http://www.kerneljanitors.org/
|
||||
S: Maintained
|
||||
|
||||
KERNEL NFSD
|
||||
KERNEL NFSD, SUNRPC, AND LOCKD SERVERS
|
||||
P: J. Bruce Fields
|
||||
M: bfields@fieldses.org
|
||||
P: Neil Brown
|
||||
|
|
@ -2908,6 +2859,12 @@ M: jirislaby@gmail.com
|
|||
L: linux-kernel@vger.kernel.org
|
||||
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)
|
||||
P: Andrew Gallatin
|
||||
M: gallatin@myri.com
|
||||
|
|
@ -3056,9 +3013,10 @@ M: horms@verge.net.au
|
|||
P: Julian Anastasov
|
||||
M: ja@ssi.bg
|
||||
L: netdev@vger.kernel.org
|
||||
L: lvs-devel@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
NFS CLIENT
|
||||
NFS, SUNRPC, AND LOCKD CLIENTS
|
||||
P: Trond Myklebust
|
||||
M: Trond.Myklebust@netapp.com
|
||||
L: linux-nfs@vger.kernel.org
|
||||
|
|
@ -3721,6 +3679,16 @@ L: linux-visws-devel@lists.sf.net
|
|||
W: http://linux-visws.sf.net
|
||||
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)
|
||||
P: Ben Dooks
|
||||
P: Vincent Sanders
|
||||
|
|
@ -4175,12 +4143,6 @@ M: oliver@neukum.name
|
|||
L: linux-usb@vger.kernel.org
|
||||
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)
|
||||
P: Pete Zaitcev
|
||||
M: zaitcev@redhat.com
|
||||
|
|
@ -4663,12 +4625,6 @@ L: linux-wireless@vger.kernel.org
|
|||
L: zd1211-devs@lists.sourceforge.net (subscribers-only)
|
||||
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
|
||||
P: Ronald Bultje
|
||||
M: rbultje@ronald.bitfreak.net
|
||||
|
|
|
|||
15
Makefile
15
Makefile
|
|
@ -1,7 +1,7 @@
|
|||
VERSION = 2
|
||||
PATCHLEVEL = 6
|
||||
SUBLEVEL = 27
|
||||
EXTRAVERSION = -rc1
|
||||
EXTRAVERSION = -rc4
|
||||
NAME = Rotary Wombat
|
||||
|
||||
# *DOCUMENTATION*
|
||||
|
|
@ -821,6 +821,9 @@ ifdef CONFIG_HEADERS_CHECK
|
|||
endif
|
||||
ifdef CONFIG_SAMPLES
|
||||
$(Q)$(MAKE) $(build)=samples
|
||||
endif
|
||||
ifdef CONFIG_BUILD_DOCSRC
|
||||
$(Q)$(MAKE) $(build)=Documentation
|
||||
endif
|
||||
$(call vmlinux-modpost)
|
||||
$(call if_changed_rule,vmlinux__)
|
||||
|
|
@ -929,10 +932,10 @@ ifneq ($(KBUILD_SRC),)
|
|||
echo " in the '$(srctree)' directory.";\
|
||||
/bin/false; \
|
||||
fi;
|
||||
$(Q)if [ ! -d include2 ]; then mkdir -p include2; fi;
|
||||
$(Q)if [ -e $(srctree)/include/asm-$(SRCARCH)/errno.h ]; then \
|
||||
$(Q)if [ ! -d include2 ]; then \
|
||||
mkdir -p include2; \
|
||||
ln -fsn $(srctree)/include/asm-$(SRCARCH) include2/asm; \
|
||||
fi
|
||||
fi
|
||||
endif
|
||||
|
||||
# prepare2 creates a makefile if using a separate output directory
|
||||
|
|
@ -1166,7 +1169,7 @@ MRPROPER_FILES += .config .config.old include/asm .version .old_version \
|
|||
#
|
||||
clean: rm-dirs := $(CLEAN_DIRS)
|
||||
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
|
||||
$(clean-dirs):
|
||||
|
|
@ -1492,7 +1495,7 @@ quiet_cmd_cscope-file = FILELST cscope.files
|
|||
cmd_cscope-file = (echo \-k; echo \-q; $(all-sources)) > cscope.files
|
||||
|
||||
quiet_cmd_cscope = MAKE cscope.out
|
||||
cmd_cscope = cscope -b
|
||||
cmd_cscope = cscope -b -f cscope.out
|
||||
|
||||
cscope: FORCE
|
||||
$(call cmd,cscope-file)
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue