mirror of
https://github.com/torvalds/linux.git
synced 2024-11-27 14:41:39 +00:00
Merge commit 'v2.6.27-rc7' into x86/microcode
This commit is contained in:
Ingo Molnar
commit
e6aa0f07cb
2
.mailmap
2
.mailmap
@ -96,4 +96,6 @@ Tejun Heo <htejun@gmail.com>
|
||||
Thomas Graf <tgraf@suug.ch>
|
||||
Tony Luck <tony.luck@intel.com>
|
||||
Tsuneo Yoshioka <Tsuneo.Yoshioka@f-secure.com>
|
||||
Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
|
||||
Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
|
||||
Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
|
||||
|
||||
@ -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/
|
||||
|
||||
315
Documentation/ABI/testing/sysfs-class-regulator
Normal file
315
Documentation/ABI/testing/sysfs-class-regulator
Normal file
@ -0,0 +1,315 @@
|
||||
What: /sys/class/regulator/.../state
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
state. This holds the regulator output state.
|
||||
|
||||
This will be one of the following strings:
|
||||
|
||||
'enabled'
|
||||
'disabled'
|
||||
'unknown'
|
||||
|
||||
'enabled' means the regulator output is ON and is supplying
|
||||
power to the system.
|
||||
|
||||
'disabled' means the regulator output is OFF and is not
|
||||
supplying power to the system..
|
||||
|
||||
'unknown' means software cannot determine the state.
|
||||
|
||||
NOTE: this field can be used in conjunction with microvolts
|
||||
and microamps to determine regulator output levels.
|
||||
|
||||
|
||||
What: /sys/class/regulator/.../type
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
type. This holds the regulator type.
|
||||
|
||||
This will be one of the following strings:
|
||||
|
||||
'voltage'
|
||||
'current'
|
||||
'unknown'
|
||||
|
||||
'voltage' means the regulator output voltage can be controlled
|
||||
by software.
|
||||
|
||||
'current' means the regulator output current limit can be
|
||||
controlled by software.
|
||||
|
||||
'unknown' means software cannot control either voltage or
|
||||
current limit.
|
||||
|
||||
|
||||
What: /sys/class/regulator/.../microvolts
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
microvolts. This holds the regulator output voltage setting
|
||||
measured in microvolts (i.e. E-6 Volts).
|
||||
|
||||
NOTE: This value should not be used to determine the regulator
|
||||
output voltage level as this value is the same regardless of
|
||||
whether the regulator is enabled or disabled.
|
||||
|
||||
|
||||
What: /sys/class/regulator/.../microamps
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
microamps. This holds the regulator output current limit
|
||||
setting measured in microamps (i.e. E-6 Amps).
|
||||
|
||||
NOTE: This value should not be used to determine the regulator
|
||||
output current level as this value is the same regardless of
|
||||
whether the regulator is enabled or disabled.
|
||||
|
||||
|
||||
What: /sys/class/regulator/.../opmode
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
opmode. This holds the regulator operating mode setting.
|
||||
|
||||
The opmode value can be one of the following strings:
|
||||
|
||||
'fast'
|
||||
'normal'
|
||||
'idle'
|
||||
'standby'
|
||||
'unknown'
|
||||
|
||||
The modes are described in include/linux/regulator/regulator.h
|
||||
|
||||
NOTE: This value should not be used to determine the regulator
|
||||
output operating mode as this value is the same regardless of
|
||||
whether the regulator is enabled or disabled.
|
||||
|
||||
|
||||
What: /sys/class/regulator/.../min_microvolts
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
min_microvolts. This holds the minimum safe working regulator
|
||||
output voltage setting for this domain measured in microvolts.
|
||||
|
||||
NOTE: this will return the string 'constraint not defined' if
|
||||
the power domain has no min microvolts constraint defined by
|
||||
platform code.
|
||||
|
||||
|
||||
What: /sys/class/regulator/.../max_microvolts
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
max_microvolts. This holds the maximum safe working regulator
|
||||
output voltage setting for this domain measured in microvolts.
|
||||
|
||||
NOTE: this will return the string 'constraint not defined' if
|
||||
the power domain has no max microvolts constraint defined by
|
||||
platform code.
|
||||
|
||||
|
||||
What: /sys/class/regulator/.../min_microamps
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
min_microamps. This holds the minimum safe working regulator
|
||||
output current limit setting for this domain measured in
|
||||
microamps.
|
||||
|
||||
NOTE: this will return the string 'constraint not defined' if
|
||||
the power domain has no min microamps constraint defined by
|
||||
platform code.
|
||||
|
||||
|
||||
What: /sys/class/regulator/.../max_microamps
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
max_microamps. This holds the maximum safe working regulator
|
||||
output current limit setting for this domain measured in
|
||||
microamps.
|
||||
|
||||
NOTE: this will return the string 'constraint not defined' if
|
||||
the power domain has no max microamps constraint defined by
|
||||
platform code.
|
||||
|
||||
|
||||
What: /sys/class/regulator/.../num_users
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
num_users. This holds the number of consumer devices that
|
||||
have called regulator_enable() on this regulator.
|
||||
|
||||
|
||||
What: /sys/class/regulator/.../requested_microamps
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
requested_microamps. This holds the total requested load
|
||||
current in microamps for this regulator from all its consumer
|
||||
devices.
|
||||
|
||||
|
||||
What: /sys/class/regulator/.../parent
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Some regulator directories will contain a link called parent.
|
||||
This points to the parent or supply regulator if one exists.
|
||||
|
||||
What: /sys/class/regulator/.../suspend_mem_microvolts
|
||||
Date: May 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
suspend_mem_microvolts. This holds the regulator output
|
||||
voltage setting for this domain measured in microvolts when
|
||||
the system is suspended to memory.
|
||||
|
||||
NOTE: this will return the string 'not defined' if
|
||||
the power domain has no suspend to memory voltage defined by
|
||||
platform code.
|
||||
|
||||
What: /sys/class/regulator/.../suspend_disk_microvolts
|
||||
Date: May 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
suspend_disk_microvolts. This holds the regulator output
|
||||
voltage setting for this domain measured in microvolts when
|
||||
the system is suspended to disk.
|
||||
|
||||
NOTE: this will return the string 'not defined' if
|
||||
the power domain has no suspend to disk voltage defined by
|
||||
platform code.
|
||||
|
||||
What: /sys/class/regulator/.../suspend_standby_microvolts
|
||||
Date: May 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
suspend_standby_microvolts. This holds the regulator output
|
||||
voltage setting for this domain measured in microvolts when
|
||||
the system is suspended to standby.
|
||||
|
||||
NOTE: this will return the string 'not defined' if
|
||||
the power domain has no suspend to standby voltage defined by
|
||||
platform code.
|
||||
|
||||
What: /sys/class/regulator/.../suspend_mem_mode
|
||||
Date: May 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
suspend_mem_mode. This holds the regulator operating mode
|
||||
setting for this domain when the system is suspended to
|
||||
memory.
|
||||
|
||||
NOTE: this will return the string 'not defined' if
|
||||
the power domain has no suspend to memory mode defined by
|
||||
platform code.
|
||||
|
||||
What: /sys/class/regulator/.../suspend_disk_mode
|
||||
Date: May 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
suspend_disk_mode. This holds the regulator operating mode
|
||||
setting for this domain when the system is suspended to disk.
|
||||
|
||||
NOTE: this will return the string 'not defined' if
|
||||
the power domain has no suspend to disk mode defined by
|
||||
platform code.
|
||||
|
||||
What: /sys/class/regulator/.../suspend_standby_mode
|
||||
Date: May 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
suspend_standby_mode. This holds the regulator operating mode
|
||||
setting for this domain when the system is suspended to
|
||||
standby.
|
||||
|
||||
NOTE: this will return the string 'not defined' if
|
||||
the power domain has no suspend to standby mode defined by
|
||||
platform code.
|
||||
|
||||
What: /sys/class/regulator/.../suspend_mem_state
|
||||
Date: May 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
suspend_mem_state. This holds the regulator operating state
|
||||
when suspended to memory.
|
||||
|
||||
This will be one of the following strings:
|
||||
|
||||
'enabled'
|
||||
'disabled'
|
||||
'not defined'
|
||||
|
||||
What: /sys/class/regulator/.../suspend_disk_state
|
||||
Date: May 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
suspend_disk_state. This holds the regulator operating state
|
||||
when suspended to disk.
|
||||
|
||||
This will be one of the following strings:
|
||||
|
||||
'enabled'
|
||||
'disabled'
|
||||
'not defined'
|
||||
|
||||
What: /sys/class/regulator/.../suspend_standby_state
|
||||
Date: May 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
suspend_standby_state. This holds the regulator operating
|
||||
state when suspended to standby.
|
||||
|
||||
This will be one of the following strings:
|
||||
|
||||
'enabled'
|
||||
'disabled'
|
||||
'not defined'
|
||||
27
Documentation/ABI/testing/sysfs-firmware-sgi_uv
Normal file
27
Documentation/ABI/testing/sysfs-firmware-sgi_uv
Normal file
@ -0,0 +1,27 @@
|
||||
What: /sys/firmware/sgi_uv/
|
||||
Date: August 2008
|
||||
Contact: Russ Anderson <rja@sgi.com>
|
||||
Description:
|
||||
The /sys/firmware/sgi_uv directory contains information
|
||||
about the SGI UV platform.
|
||||
|
||||
Under that directory are a number of files:
|
||||
|
||||
partition_id
|
||||
coherence_id
|
||||
|
||||
The partition_id entry contains the partition id.
|
||||
SGI UV systems can be partitioned into multiple physical
|
||||
machines, which each partition running a unique copy
|
||||
of the operating system. Each partition will have a unique
|
||||
partition id. To display the partition id, use the command:
|
||||
|
||||
cat /sys/firmware/sgi_uv/partition_id
|
||||
|
||||
The coherence_id entry contains the coherence id.
|
||||
A partitioned SGI UV system can have one or more coherence
|
||||
domain. The coherence id indicates which coherence domain
|
||||
this partition is in. To display the coherence id, use the
|
||||
command:
|
||||
|
||||
cat /sys/firmware/sgi_uv/coherence_id
|
||||
26
Documentation/ABI/testing/sysfs-gpio
Normal file
26
Documentation/ABI/testing/sysfs-gpio
Normal file
@ -0,0 +1,26 @@
|
||||
What: /sys/class/gpio/
|
||||
Date: July 2008
|
||||
KernelVersion: 2.6.27
|
||||
Contact: David Brownell <dbrownell@users.sourceforge.net>
|
||||
Description:
|
||||
|
||||
As a Kconfig option, individual GPIO signals may be accessed from
|
||||
userspace. GPIOs are only made available to userspace by an explicit
|
||||
"export" operation. If a given GPIO is not claimed for use by
|
||||
kernel code, it may be exported by userspace (and unexported later).
|
||||
Kernel code may export it for complete or partial access.
|
||||
|
||||
GPIOs are identified as they are inside the kernel, using integers in
|
||||
the range 0..INT_MAX. See Documentation/gpio.txt for more information.
|
||||
|
||||
/sys/class/gpio
|
||||
/export ... asks the kernel to export a GPIO to userspace
|
||||
/unexport ... to return a GPIO to the kernel
|
||||
/gpioN ... for each exported GPIO #N
|
||||
/value ... always readable, writes fail for input GPIOs
|
||||
/direction ... r/w as: in, out (default low); write: high, low
|
||||
/gpiochipN ... for each gpiochip; #N is its first GPIO
|
||||
/base ... (r/o) same as N
|
||||
/label ... (r/o) descriptive, not necessarily unique
|
||||
/ngpio ... (r/o) number of GPIOs; numbered N to N + (ngpio - 1)
|
||||
|
||||
@ -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 $@) $<
|
||||
|
||||
@ -98,6 +98,24 @@
|
||||
"Kernel debugging" select "KGDB: kernel debugging with remote gdb".
|
||||
</para>
|
||||
<para>
|
||||
It is advised, but not required that you turn on the
|
||||
CONFIG_FRAME_POINTER kernel option. This option inserts code to
|
||||
into the compiled executable which saves the frame information in
|
||||
registers or on the stack at different points which will allow a
|
||||
debugger such as gdb to more accurately construct stack back traces
|
||||
while debugging the kernel.
|
||||
</para>
|
||||
<para>
|
||||
If the architecture that you are using supports the kernel option
|
||||
CONFIG_DEBUG_RODATA, you should consider turning it off. This
|
||||
option will prevent the use of software breakpoints because it
|
||||
marks certain regions of the kernel's memory space as read-only.
|
||||
If kgdb supports it for the architecture you are using, you can
|
||||
use hardware breakpoints if you desire to run with the
|
||||
CONFIG_DEBUG_RODATA option turned on, else you need to turn off
|
||||
this option.
|
||||
</para>
|
||||
<para>
|
||||
Next you should choose one of more I/O drivers to interconnect debugging
|
||||
host and debugged target. Early boot debugging requires a KGDB
|
||||
I/O driver that supports early debugging and the driver must be
|
||||
|
||||
@ -189,8 +189,6 @@ static int __init init_procfs_example(void)
|
||||
return 0;
|
||||
|
||||
no_symlink:
|
||||
remove_proc_entry("tty", example_dir);
|
||||
no_tty:
|
||||
remove_proc_entry("bar", example_dir);
|
||||
no_bar:
|
||||
remove_proc_entry("foo", example_dir);
|
||||
@ -206,7 +204,6 @@ out:
|
||||
static void __exit cleanup_procfs_example(void)
|
||||
{
|
||||
remove_proc_entry("jiffies_too", example_dir);
|
||||
remove_proc_entry("tty", example_dir);
|
||||
remove_proc_entry("bar", example_dir);
|
||||
remove_proc_entry("foo", example_dir);
|
||||
remove_proc_entry("jiffies", example_dir);
|
||||
@ -222,3 +219,4 @@ module_exit(cleanup_procfs_example);
|
||||
|
||||
MODULE_AUTHOR("Erik Mouw");
|
||||
MODULE_DESCRIPTION("procfs examples");
|
||||
MODULE_LICENSE("GPL");
|
||||
|
||||
@ -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
|
||||
-----------------
|
||||
|
||||
@ -635,14 +635,16 @@ prior 'mems' setting, will not be moved.
|
||||
|
||||
There is an exception to the above. If hotplug functionality is used
|
||||
to remove all the CPUs that are currently assigned to a cpuset,
|
||||
then the kernel will automatically update the cpus_allowed of all
|
||||
tasks attached to CPUs in that cpuset to allow all CPUs. When memory
|
||||
hotplug functionality for removing Memory Nodes is available, a
|
||||
similar exception is expected to apply there as well. In general,
|
||||
the kernel prefers to violate cpuset placement, over starving a task
|
||||
that has had all its allowed CPUs or Memory Nodes taken offline. User
|
||||
code should reconfigure cpusets to only refer to online CPUs and Memory
|
||||
Nodes when using hotplug to add or remove such resources.
|
||||
then all the tasks in that cpuset will be moved to the nearest ancestor
|
||||
with non-empty cpus. But the moving of some (or all) tasks might fail if
|
||||
cpuset is bound with another cgroup subsystem which has some restrictions
|
||||
on task attaching. In this failing case, those tasks will stay
|
||||
in the original cpuset, and the kernel will automatically update
|
||||
their cpus_allowed to allow all online CPUs. When memory hotplug
|
||||
functionality for removing Memory Nodes is available, a similar exception
|
||||
is expected to apply there as well. In general, the kernel prefers to
|
||||
violate cpuset placement, over starving a task that has had all
|
||||
its allowed CPUs or Memory Nodes taken offline.
|
||||
|
||||
There is a second exception to the above. GFP_ATOMIC requests are
|
||||
kernel internal allocations that must be satisfied, immediately.
|
||||
|
||||
@ -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
|
||||
|
||||
@ -5,6 +5,8 @@
|
||||
*.css
|
||||
*.dvi
|
||||
*.eps
|
||||
*.fw.gen.S
|
||||
*.fw
|
||||
*.gif
|
||||
*.grep
|
||||
*.grp
|
||||
|
||||
@ -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
|
||||
|
||||
@ -344,3 +322,11 @@ Why: Accounting can now be enabled/disabled without kernel recompilation.
|
||||
controlled by a kernel/module/sysfs/sysctl parameter.
|
||||
Who: Krzysztof Piotr Oledzki <ole@ans.pl>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: ide-scsi (BLK_DEV_IDESCSI)
|
||||
When: 2.6.29
|
||||
Why: The 2.6 kernel supports direct writing to ide CD drives, which
|
||||
eliminates the need for ide-scsi. The new method is more
|
||||
efficient in every way.
|
||||
Who: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
|
||||
|
||||
@ -144,8 +144,8 @@ prototypes:
|
||||
void (*kill_sb) (struct super_block *);
|
||||
locking rules:
|
||||
may block BKL
|
||||
get_sb yes yes
|
||||
kill_sb yes yes
|
||||
get_sb yes no
|
||||
kill_sb yes no
|
||||
|
||||
->get_sb() returns error or 0 with locked superblock attached to the vfsmount
|
||||
(exclusive on ->s_umount).
|
||||
@ -409,12 +409,12 @@ ioctl: yes (see below)
|
||||
unlocked_ioctl: no (see below)
|
||||
compat_ioctl: no
|
||||
mmap: no
|
||||
open: maybe (see below)
|
||||
open: no
|
||||
flush: no
|
||||
release: no
|
||||
fsync: no (see below)
|
||||
aio_fsync: no
|
||||
fasync: yes (see below)
|
||||
fasync: no
|
||||
lock: yes
|
||||
readv: no
|
||||
writev: no
|
||||
@ -431,13 +431,6 @@ For many filesystems, it is probably safe to acquire the inode
|
||||
semaphore. Note some filesystems (i.e. remote ones) provide no
|
||||
protection for i_size so you will need to use the BKL.
|
||||
|
||||
->open() locking is in-transit: big lock partially moved into the methods.
|
||||
The only exception is ->open() in the instances of file_operations that never
|
||||
end up in ->i_fop/->proc_fops, i.e. ones that belong to character devices
|
||||
(chrdev_open() takes lock before replacing ->f_op and calling the secondary
|
||||
method. As soon as we fix the handling of module reference counters all
|
||||
instances of ->open() will be called without the BKL.
|
||||
|
||||
Note: ext2_release() was *the* source of contention on fs-intensive
|
||||
loads and dropping BKL on ->release() helps to get rid of that (we still
|
||||
grab BKL for cases when we close a file that had been opened r/w, but that
|
||||
|
||||
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
|
||||
@ -311,9 +311,20 @@ the subsystem must be ready for it.
|
||||
[An Example]
|
||||
|
||||
The best example of these basic concepts is the simple_children
|
||||
subsystem/group and the simple_child item in configfs_example.c It
|
||||
shows a trivial object displaying and storing an attribute, and a simple
|
||||
group creating and destroying these children.
|
||||
subsystem/group and the simple_child item in configfs_example_explicit.c
|
||||
and configfs_example_macros.c. It shows a trivial object displaying and
|
||||
storing an attribute, and a simple group creating and destroying these
|
||||
children.
|
||||
|
||||
The only difference between configfs_example_explicit.c and
|
||||
configfs_example_macros.c is how the attributes of the childless item
|
||||
are defined. The childless item has extended attributes, each with
|
||||
their own show()/store() operation. This follows a convention commonly
|
||||
used in sysfs. configfs_example_explicit.c creates these attributes
|
||||
by explicitly defining the structures involved. Conversely
|
||||
configfs_example_macros.c uses some convenience macros from configfs.h
|
||||
to define the attributes. These macros are similar to their sysfs
|
||||
counterparts.
|
||||
|
||||
[Hierarchy Navigation and the Subsystem Mutex]
|
||||
|
||||
|
||||
@ -1,485 +0,0 @@
|
||||
/*
|
||||
* vim: noexpandtab ts=8 sts=0 sw=8:
|
||||
*
|
||||
* configfs_example.c - This file is a demonstration module containing
|
||||
* a number of configfs subsystems.
|
||||
*
|
||||
* This program is free software; you can redistribute it and/or
|
||||
* modify it under the terms of the GNU General Public
|
||||
* License as published by the Free Software Foundation; either
|
||||
* version 2 of the License, or (at your option) any later version.
|
||||
*
|
||||
* 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.
|
||||
*
|
||||
* 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 021110-1307, USA.
|
||||
*
|
||||
* Based on sysfs:
|
||||
* sysfs is Copyright (C) 2001, 2002, 2003 Patrick Mochel
|
||||
*
|
||||
* configfs Copyright (C) 2005 Oracle. All rights reserved.
|
||||
*/
|
||||
|
||||
#include <linux/init.h>
|
||||
#include <linux/module.h>
|
||||
#include <linux/slab.h>
|
||||
|
||||
#include <linux/configfs.h>
|
||||
|
||||
|
||||
|
||||
/*
|
||||
* 01-childless
|
||||
*
|
||||
* This first example is a childless subsystem. It cannot create
|
||||
* any config_items. It just has attributes.
|
||||
*
|
||||
* Note that we are enclosing the configfs_subsystem inside a container.
|
||||
* This is not necessary if a subsystem has no attributes directly
|
||||
* on the subsystem. See the next example, 02-simple-children, for
|
||||
* such a subsystem.
|
||||
*/
|
||||
|
||||
struct childless {
|
||||
struct configfs_subsystem subsys;
|
||||
int showme;
|
||||
int storeme;
|
||||
};
|
||||
|
||||
struct childless_attribute {
|
||||
struct configfs_attribute attr;
|
||||
ssize_t (*show)(struct childless *, char *);
|
||||
ssize_t (*store)(struct childless *, const char *, size_t);
|
||||
};
|
||||
|
||||
static inline struct childless *to_childless(struct config_item *item)
|
||||
{
|
||||
return item ? container_of(to_configfs_subsystem(to_config_group(item)), struct childless, subsys) : NULL;
|
||||
}
|
||||
|
||||
static ssize_t childless_showme_read(struct childless *childless,
|
||||
char *page)
|
||||
{
|
||||
ssize_t pos;
|
||||
|
||||
pos = sprintf(page, "%d\n", childless->showme);
|
||||
childless->showme++;
|
||||
|
||||
return pos;
|
||||
}
|
||||
|
||||
static ssize_t childless_storeme_read(struct childless *childless,
|
||||
char *page)
|
||||
{
|
||||
return sprintf(page, "%d\n", childless->storeme);
|
||||
}
|
||||
|
||||
static ssize_t childless_storeme_write(struct childless *childless,
|
||||
const char *page,
|
||||
size_t count)
|
||||
{
|
||||
unsigned long tmp;
|
||||
char *p = (char *) page;
|
||||
|
||||
tmp = simple_strtoul(p, &p, 10);
|
||||
if (!p || (*p && (*p != '\n')))
|
||||
return -EINVAL;
|
||||
|
||||
if (tmp > INT_MAX)
|
||||
return -ERANGE;
|
||||
|
||||
childless->storeme = tmp;
|
||||
|
||||
return count;
|
||||
}
|
||||
|
||||
static ssize_t childless_description_read(struct childless *childless,
|
||||
char *page)
|
||||
{
|
||||
return sprintf(page,
|
||||
"[01-childless]\n"
|
||||
"\n"
|
||||
"The childless subsystem is the simplest possible subsystem in\n"
|
||||
"configfs. It does not support the creation of child config_items.\n"
|
||||
"It only has a few attributes. In fact, it isn't much different\n"
|
||||
"than a directory in /proc.\n");
|
||||
}
|
||||
|
||||
static struct childless_attribute childless_attr_showme = {
|
||||
.attr = { .ca_owner = THIS_MODULE, .ca_name = "showme", .ca_mode = S_IRUGO },
|
||||
.show = childless_showme_read,
|
||||
};
|
||||
static struct childless_attribute childless_attr_storeme = {
|
||||
.attr = { .ca_owner = THIS_MODULE, .ca_name = "storeme", .ca_mode = S_IRUGO | S_IWUSR },
|
||||
.show = childless_storeme_read,
|
||||
.store = childless_storeme_write,
|
||||
};
|
||||
static struct childless_attribute childless_attr_description = {
|
||||
.attr = { .ca_owner = THIS_MODULE, .ca_name = "description", .ca_mode = S_IRUGO },
|
||||
.show = childless_description_read,
|
||||
};
|
||||
|
||||
static struct configfs_attribute *childless_attrs[] = {
|
||||
&childless_attr_showme.attr,
|
||||
&childless_attr_storeme.attr,
|
||||
&childless_attr_description.attr,
|
||||
NULL,
|
||||
};
|
||||
|
||||
static ssize_t childless_attr_show(struct config_item *item,
|
||||
struct configfs_attribute *attr,
|
||||
char *page)
|
||||
{
|
||||
struct childless *childless = to_childless(item);
|
||||
struct childless_attribute *childless_attr =
|
||||
container_of(attr, struct childless_attribute, attr);
|
||||
ssize_t ret = 0;
|
||||
|
||||
if (childless_attr->show)
|
||||
ret = childless_attr->show(childless, page);
|
||||
return ret;
|
||||
}
|
||||
|
||||
static ssize_t childless_attr_store(struct config_item *item,
|
||||
struct configfs_attribute *attr,
|
||||
const char *page, size_t count)
|
||||
{
|
||||
struct childless *childless = to_childless(item);
|
||||
struct childless_attribute *childless_attr =
|
||||
container_of(attr, struct childless_attribute, attr);
|
||||
ssize_t ret = -EINVAL;
|
||||
|
||||
if (childless_attr->store)
|
||||
ret = childless_attr->store(childless, page, count);
|
||||
return ret;
|
||||
}
|
||||
|
||||
static struct configfs_item_operations childless_item_ops = {
|
||||
.show_attribute = childless_attr_show,
|
||||
.store_attribute = childless_attr_store,
|
||||
};
|
||||
|
||||
static struct config_item_type childless_type = {
|
||||
.ct_item_ops = &childless_item_ops,
|
||||
.ct_attrs = childless_attrs,
|
||||
.ct_owner = THIS_MODULE,
|
||||
};
|
||||
|
||||
static struct childless childless_subsys = {
|
||||
.subsys = {
|
||||
.su_group = {
|
||||
.cg_item = {
|
||||
.ci_namebuf = "01-childless",
|
||||
.ci_type = &childless_type,
|
||||
},
|
||||
},
|
||||
},
|
||||
};
|
||||
|
||||
|
||||
/* ----------------------------------------------------------------- */
|
||||
|
||||
/*
|
||||
* 02-simple-children
|
||||
*
|
||||
* This example merely has a simple one-attribute child. Note that
|
||||
* there is no extra attribute structure, as the child's attribute is
|
||||
* known from the get-go. Also, there is no container for the
|
||||
* subsystem, as it has no attributes of its own.
|
||||
*/
|
||||
|
||||
struct simple_child {
|
||||
struct config_item item;
|
||||
int storeme;
|
||||
};
|
||||
|
||||
static inline struct simple_child *to_simple_child(struct config_item *item)
|
||||
{
|
||||
return item ? container_of(item, struct simple_child, item) : NULL;
|
||||
}
|
||||
|
||||
static struct configfs_attribute simple_child_attr_storeme = {
|
||||
.ca_owner = THIS_MODULE,
|
||||
.ca_name = "storeme",
|
||||
.ca_mode = S_IRUGO | S_IWUSR,
|
||||
};
|
||||
|
||||
static struct configfs_attribute *simple_child_attrs[] = {
|
||||
&simple_child_attr_storeme,
|
||||
NULL,
|
||||
};
|
||||
|
||||
static ssize_t simple_child_attr_show(struct config_item *item,
|
||||
struct configfs_attribute *attr,
|
||||
char *page)
|
||||
{
|
||||
ssize_t count;
|
||||
struct simple_child *simple_child = to_simple_child(item);
|
||||
|
||||
count = sprintf(page, "%d\n", simple_child->storeme);
|
||||
|
||||
return count;
|
||||
}
|
||||
|
||||
static ssize_t simple_child_attr_store(struct config_item *item,
|
||||
struct configfs_attribute *attr,
|
||||
const char *page, size_t count)
|
||||
{
|
||||
struct simple_child *simple_child = to_simple_child(item);
|
||||
unsigned long tmp;
|
||||
char *p = (char *) page;
|
||||
|
||||
tmp = simple_strtoul(p, &p, 10);
|
||||
if (!p || (*p && (*p != '\n')))
|
||||
return -EINVAL;
|
||||
|
||||
if (tmp > INT_MAX)
|
||||
return -ERANGE;
|
||||
|
||||
simple_child->storeme = tmp;
|
||||
|
||||
return count;
|
||||
}
|
||||
|
||||
static void simple_child_release(struct config_item *item)
|
||||
{
|
||||
kfree(to_simple_child(item));
|
||||
}
|
||||
|
||||
static struct configfs_item_operations simple_child_item_ops = {
|
||||
.release = simple_child_release,
|
||||
.show_attribute = simple_child_attr_show,
|
||||
.store_attribute = simple_child_attr_store,
|
||||
};
|
||||
|
||||
static struct config_item_type simple_child_type = {
|
||||
.ct_item_ops = &simple_child_item_ops,
|
||||
.ct_attrs = simple_child_attrs,
|
||||
.ct_owner = THIS_MODULE,
|
||||
};
|
||||
|
||||
|
||||
struct simple_children {
|
||||
struct config_group group;
|
||||
};
|
||||
|
||||
static inline struct simple_children *to_simple_children(struct config_item *item)
|
||||
{
|
||||
return item ? container_of(to_config_group(item), struct simple_children, group) : NULL;
|
||||
}
|
||||
|
||||
static struct config_item *simple_children_make_item(struct config_group *group, const char *name)
|
||||
{
|
||||
struct simple_child *simple_child;
|
||||
|
||||
simple_child = kzalloc(sizeof(struct simple_child), GFP_KERNEL);
|
||||
if (!simple_child)
|
||||
return ERR_PTR(-ENOMEM);
|
||||
|
||||
|
||||
config_item_init_type_name(&simple_child->item, name,
|
||||
&simple_child_type);
|
||||
|
||||
simple_child->storeme = 0;
|
||||
|
||||
return &simple_child->item;
|
||||
}
|
||||
|
||||
static struct configfs_attribute simple_children_attr_description = {
|
||||
.ca_owner = THIS_MODULE,
|
||||
.ca_name = "description",
|
||||
.ca_mode = S_IRUGO,
|
||||
};
|
||||
|
||||
static struct configfs_attribute *simple_children_attrs[] = {
|
||||
&simple_children_attr_description,
|
||||
NULL,
|
||||
};
|
||||
|
||||
static ssize_t simple_children_attr_show(struct config_item *item,
|
||||
struct configfs_attribute *attr,
|
||||
char *page)
|
||||
{
|
||||
return sprintf(page,
|
||||
"[02-simple-children]\n"
|
||||
"\n"
|
||||
"This subsystem allows the creation of child config_items. These\n"
|
||||
"items have only one attribute that is readable and writeable.\n");
|
||||
}
|
||||
|
||||
static void simple_children_release(struct config_item *item)
|
||||
{
|
||||
kfree(to_simple_children(item));
|
||||
}
|
||||
|
||||
static struct configfs_item_operations simple_children_item_ops = {
|
||||
.release = simple_children_release,
|
||||
.show_attribute = simple_children_attr_show,
|
||||
};
|
||||
|
||||
/*
|
||||
* Note that, since no extra work is required on ->drop_item(),
|
||||
* no ->drop_item() is provided.
|
||||
*/
|
||||
static struct configfs_group_operations simple_children_group_ops = {
|
||||
.make_item = simple_children_make_item,
|
||||
};
|
||||
|
||||
static struct config_item_type simple_children_type = {
|
||||
.ct_item_ops = &simple_children_item_ops,
|
||||
.ct_group_ops = &simple_children_group_ops,
|
||||
.ct_attrs = simple_children_attrs,
|
||||
.ct_owner = THIS_MODULE,
|
||||
};
|
||||
|
||||
static struct configfs_subsystem simple_children_subsys = {
|
||||
.su_group = {
|
||||
.cg_item = {
|
||||
.ci_namebuf = "02-simple-children",
|
||||
.ci_type = &simple_children_type,
|
||||
},
|
||||
},
|
||||
};
|
||||
|
||||
|
||||
/* ----------------------------------------------------------------- */
|
||||
|
||||
/*
|
||||
* 03-group-children
|
||||
*
|
||||
* This example reuses the simple_children group from above. However,
|
||||
* the simple_children group is not the subsystem itself, it is a
|
||||
* child of the subsystem. Creation of a group in the subsystem creates
|
||||
* a new simple_children group. That group can then have simple_child
|
||||
* children of its own.
|
||||
*/
|
||||
|
||||
static struct config_group *group_children_make_group(struct config_group *group, const char *name)
|
||||
{
|
||||
struct simple_children *simple_children;
|
||||
|
||||
simple_children = kzalloc(sizeof(struct simple_children),
|
||||
GFP_KERNEL);
|
||||
if (!simple_children)
|
||||
return ERR_PTR(-ENOMEM);
|
||||
|
||||
|
||||
config_group_init_type_name(&simple_children->group, name,
|
||||
&simple_children_type);
|
||||
|
||||
return &simple_children->group;
|
||||
}
|
||||
|
||||
static struct configfs_attribute group_children_attr_description = {
|
||||
.ca_owner = THIS_MODULE,
|
||||
.ca_name = "description",
|
||||
.ca_mode = S_IRUGO,
|
||||
};
|
||||
|
||||
static struct configfs_attribute *group_children_attrs[] = {
|
||||
&group_children_attr_description,
|
||||
NULL,
|
||||
};
|
||||
|
||||
static ssize_t group_children_attr_show(struct config_item *item,
|
||||
struct configfs_attribute *attr,
|
||||
char *page)
|
||||
{
|
||||
return sprintf(page,
|
||||
"[03-group-children]\n"
|
||||
"\n"
|
||||
"This subsystem allows the creation of child config_groups. These\n"
|
||||
"groups are like the subsystem simple-children.\n");
|
||||
}
|
||||
|
||||
static struct configfs_item_operations group_children_item_ops = {
|
||||
.show_attribute = group_children_attr_show,
|
||||
};
|
||||
|
||||
/*
|
||||
* Note that, since no extra work is required on ->drop_item(),
|
||||
* no ->drop_item() is provided.
|
||||
*/
|
||||
static struct configfs_group_operations group_children_group_ops = {
|
||||
.make_group = group_children_make_group,
|
||||
};
|
||||
|
||||
static struct config_item_type group_children_type = {
|
||||
.ct_item_ops = &group_children_item_ops,
|
||||
.ct_group_ops = &group_children_group_ops,
|
||||
.ct_attrs = group_children_attrs,
|
||||
.ct_owner = THIS_MODULE,
|
||||
};
|
||||
|
||||
static struct configfs_subsystem group_children_subsys = {
|
||||
.su_group = {
|
||||
.cg_item = {
|
||||
.ci_namebuf = "03-group-children",
|
||||
.ci_type = &group_children_type,
|
||||
},
|
||||
},
|
||||
};
|
||||
|
||||
/* ----------------------------------------------------------------- */
|
||||
|
||||
/*
|
||||
* We're now done with our subsystem definitions.
|
||||
* For convenience in this module, here's a list of them all. It
|
||||
* allows the init function to easily register them. Most modules
|
||||
* will only have one subsystem, and will only call register_subsystem
|
||||
* on it directly.
|
||||
*/
|
||||
static struct configfs_subsystem *example_subsys[] = {
|
||||
&childless_subsys.subsys,
|
||||
&simple_children_subsys,
|
||||
&group_children_subsys,
|
||||
NULL,
|
||||
};
|
||||
|
||||
static int __init configfs_example_init(void)
|
||||
{
|
||||
int ret;
|
||||
int i;
|
||||
struct configfs_subsystem *subsys;
|
||||
|
||||
for (i = 0; example_subsys[i]; i++) {
|
||||
subsys = example_subsys[i];
|
||||
|
||||
config_group_init(&subsys->su_group);
|
||||
mutex_init(&subsys->su_mutex);
|
||||
ret = configfs_register_subsystem(subsys);
|
||||
if (ret) {
|
||||
printk(KERN_ERR "Error %d while registering subsystem %s\n",
|
||||
ret,
|
||||
subsys->su_group.cg_item.ci_namebuf);
|
||||
goto out_unregister;
|
||||
}
|
||||
}
|
||||
|
||||
return 0;
|
||||
|
||||
out_unregister:
|
||||
for (; i >= 0; i--) {
|
||||
configfs_unregister_subsystem(example_subsys[i]);
|
||||
}
|
||||
|
||||
return ret;
|
||||
}
|
||||
|
||||
static void __exit configfs_example_exit(void)
|
||||
{
|
||||
int i;
|
||||
|
||||
for (i = 0; example_subsys[i]; i++) {
|
||||
configfs_unregister_subsystem(example_subsys[i]);
|
||||
}
|
||||
}
|
||||
|
||||
module_init(configfs_example_init);
|
||||
module_exit(configfs_example_exit);
|
||||
MODULE_LICENSE("GPL");
|
||||
485
Documentation/filesystems/configfs/configfs_example_explicit.c
Normal file
485
Documentation/filesystems/configfs/configfs_example_explicit.c
Normal file
@ -0,0 +1,485 @@
|
||||
/*
|
||||
* vim: noexpandtab ts=8 sts=0 sw=8:
|
||||
*
|
||||
* configfs_example_explicit.c - This file is a demonstration module
|
||||
* containing a number of configfs subsystems. It explicitly defines
|
||||
* each structure without using the helper macros defined in
|
||||
* configfs.h.
|
||||
*
|
||||
* This program is free software; you can redistribute it and/or
|
||||
* modify it under the terms of the GNU General Public
|
||||
* License as published by the Free Software Foundation; either
|
||||
* version 2 of the License, or (at your option) any later version.
|
||||
*
|
||||
* 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.
|
||||
*
|
||||
* 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 021110-1307, USA.
|
||||
*
|
||||
* Based on sysfs:
|
||||
* sysfs is Copyright (C) 2001, 2002, 2003 Patrick Mochel
|
||||
*
|
||||
* configfs Copyright (C) 2005 Oracle. All rights reserved.
|
||||
*/
|
||||
|
||||
#include <linux/init.h>
|
||||
#include <linux/module.h>
|
||||
#include <linux/slab.h>
|
||||
|
||||
#include <linux/configfs.h>
|
||||
|
||||
|
||||
|
||||
/*
|
||||
* 01-childless
|
||||
*
|
||||
* This first example is a childless subsystem. It cannot create
|
||||
* any config_items. It just has attributes.
|
||||
*
|
||||
* Note that we are enclosing the configfs_subsystem inside a container.
|
||||
* This is not necessary if a subsystem has no attributes directly
|
||||
* on the subsystem. See the next example, 02-simple-children, for
|
||||
* such a subsystem.
|
||||
*/
|
||||
|
||||
struct childless {
|
||||
struct configfs_subsystem subsys;
|
||||
int showme;
|
||||
int storeme;
|
||||
};
|
||||
|
||||
struct childless_attribute {
|
||||
struct configfs_attribute attr;
|
||||
ssize_t (*show)(struct childless *, char *);
|
||||
ssize_t (*store)(struct childless *, const char *, size_t);
|
||||
};
|
||||
|
||||
static inline struct childless *to_childless(struct config_item *item)
|
||||
{
|
||||
return item ? container_of(to_configfs_subsystem(to_config_group(item)), struct childless, subsys) : NULL;
|
||||
}
|
||||
|
||||
static ssize_t childless_showme_read(struct childless *childless,
|
||||
char *page)
|
||||
{
|
||||
ssize_t pos;
|
||||
|
||||
pos = sprintf(page, "%d\n", childless->showme);
|
||||
childless->showme++;
|
||||
|
||||
return pos;
|
||||
}
|
||||
|
||||
static ssize_t childless_storeme_read(struct childless *childless,
|
||||
char *page)
|
||||
{
|
||||
return sprintf(page, "%d\n", childless->storeme);
|
||||
}
|
||||
|
||||
static ssize_t childless_storeme_write(struct childless *childless,
|
||||
const char *page,
|
||||
size_t count)
|
||||
{
|
||||
unsigned long tmp;
|
||||
char *p = (char *) page;
|
||||
|
||||
tmp = simple_strtoul(p, &p, 10);
|
||||
if (!p || (*p && (*p != '\n')))
|
||||
return -EINVAL;
|
||||
|
||||
if (tmp > INT_MAX)
|
||||
return -ERANGE;
|
||||
|
||||
childless->storeme = tmp;
|
||||
|
||||
return count;
|
||||
}
|
||||
|
||||
static ssize_t childless_description_read(struct childless *childless,
|
||||
char *page)
|
||||
{
|
||||
return sprintf(page,
|
||||
"[01-childless]\n"
|
||||
"\n"
|
||||
"The childless subsystem is the simplest possible subsystem in\n"
|
||||
"configfs. It does not support the creation of child config_items.\n"
|
||||
"It only has a few attributes. In fact, it isn't much different\n"
|
||||
"than a directory in /proc.\n");
|
||||
}
|
||||
|
||||
static struct childless_attribute childless_attr_showme = {
|
||||
.attr = { .ca_owner = THIS_MODULE, .ca_name = "showme", .ca_mode = S_IRUGO },
|
||||
.show = childless_showme_read,
|
||||
};
|
||||
static struct childless_attribute childless_attr_storeme = {
|
||||
.attr = { .ca_owner = THIS_MODULE, .ca_name = "storeme", .ca_mode = S_IRUGO | S_IWUSR },
|
||||
.show = childless_storeme_read,
|
||||
.store = childless_storeme_write,
|
||||
};
|
||||
static struct childless_attribute childless_attr_description = {
|
||||
.attr = { .ca_owner = THIS_MODULE, .ca_name = "description", .ca_mode = S_IRUGO },
|
||||
.show = childless_description_read,
|
||||
};
|
||||
|
||||
static struct configfs_attribute *childless_attrs[] = {
|
||||
&childless_attr_showme.attr,
|
||||
&childless_attr_storeme.attr,
|
||||
&childless_attr_description.attr,
|
||||
NULL,
|
||||
};
|
||||
|
||||
static ssize_t childless_attr_show(struct config_item *item,
|
||||
struct configfs_attribute *attr,
|
||||
char *page)
|
||||
{
|
||||
struct childless *childless = to_childless(item);
|
||||
struct childless_attribute *childless_attr =
|
||||
container_of(attr, struct childless_attribute, attr);
|
||||
ssize_t ret = 0;
|
||||
|
||||
if (childless_attr->show)
|
||||
ret = childless_attr->show(childless, page);
|
||||
return ret;
|
||||
}
|
||||
|
||||
static ssize_t childless_attr_store(struct config_item *item,
|
||||
struct configfs_attribute *attr,
|
||||
const char *page, size_t count)
|
||||
{
|
||||
struct childless *childless = to_childless(item);
|
||||
struct childless_attribute *childless_attr =
|
||||
container_of(attr, struct childless_attribute, attr);
|
||||
ssize_t ret = -EINVAL;
|
||||
|
||||
if (childless_attr->store)
|
||||
ret = childless_attr->store(childless, page, count);
|
||||
return ret;
|
||||
}
|
||||
|
||||
static struct configfs_item_operations childless_item_ops = {
|
||||
.show_attribute = childless_attr_show,
|
||||
.store_attribute = childless_attr_store,
|
||||
};
|
||||
|
||||
static struct config_item_type childless_type = {
|
||||
.ct_item_ops = &childless_item_ops,
|
||||
.ct_attrs = childless_attrs,
|
||||
.ct_owner = THIS_MODULE,
|
||||
};
|
||||
|
||||
static struct childless childless_subsys = {
|
||||
.subsys = {
|
||||
.su_group = {
|
||||
.cg_item = {
|
||||
.ci_namebuf = "01-childless",
|
||||
.ci_type = &childless_type,
|
||||
},
|
||||
},
|
||||
},
|
||||
};
|
||||
|
||||
|
||||
/* ----------------------------------------------------------------- */
|
||||
|
||||
/*
|
||||
* 02-simple-children
|
||||
*
|
||||
* This example merely has a simple one-attribute child. Note that
|
||||
* there is no extra attribute structure, as the child's attribute is
|
||||
* known from the get-go. Also, there is no container for the
|
||||
* subsystem, as it has no attributes of its own.
|
||||
*/
|
||||
|
||||
struct simple_child {
|
||||
struct config_item item;
|
||||
int storeme;
|
||||
};
|
||||
|
||||
static inline struct simple_child *to_simple_child(struct config_item *item)
|
||||
{
|
||||
return item ? container_of(item, struct simple_child, item) : NULL;
|
||||
}
|
||||
|
||||
static struct configfs_attribute simple_child_attr_storeme = {
|
||||
.ca_owner = THIS_MODULE,
|
||||
.ca_name = "storeme",
|
||||
.ca_mode = S_IRUGO | S_IWUSR,
|
||||
};
|
||||
|
||||
static struct configfs_attribute *simple_child_attrs[] = {
|
||||
&simple_child_attr_storeme,
|
||||
NULL,
|
||||
};
|
||||
|
||||
static ssize_t simple_child_attr_show(struct config_item *item,
|
||||
struct configfs_attribute *attr,
|
||||
char *page)
|
||||
{
|
||||
ssize_t count;
|
||||
struct simple_child *simple_child = to_simple_child(item);
|
||||
|
||||
count = sprintf(page, "%d\n", simple_child->storeme);
|
||||
|
||||
return count;
|
||||
}
|
||||
|
||||
static ssize_t simple_child_attr_store(struct config_item *item,
|
||||
struct configfs_attribute *attr,
|
||||
const char *page, size_t count)
|
||||
{
|
||||
struct simple_child *simple_child = to_simple_child(item);
|
||||
unsigned long tmp;
|
||||
char *p = (char *) page;
|
||||
|
||||
tmp = simple_strtoul(p, &p, 10);
|
||||
if (!p || (*p && (*p != '\n')))
|
||||
return -EINVAL;
|
||||
|
||||
if (tmp > INT_MAX)
|
||||
return -ERANGE;
|
||||
|
||||
simple_child->storeme = tmp;
|
||||
|
||||
return count;
|
||||
}
|
||||
|
||||
static void simple_child_release(struct config_item *item)
|
||||
{
|
||||
kfree(to_simple_child(item));
|
||||
}
|
||||
|
||||
static struct configfs_item_operations simple_child_item_ops = {
|
||||
.release = simple_child_release,
|
||||
.show_attribute = simple_child_attr_show,
|
||||
.store_attribute = simple_child_attr_store,
|
||||
};
|
||||
|
||||
static struct config_item_type simple_child_type = {
|
||||
.ct_item_ops = &simple_child_item_ops,
|
||||
.ct_attrs = simple_child_attrs,
|
||||
.ct_owner = THIS_MODULE,
|
||||
};
|
||||
|
||||
|
||||
struct simple_children {
|
||||
struct config_group group;
|
||||
};
|
||||
|
||||
static inline struct simple_children *to_simple_children(struct config_item *item)
|
||||
{
|
||||
return item ? container_of(to_config_group(item), struct simple_children, group) : NULL;
|
||||
}
|
||||
|
||||
static struct config_item *simple_children_make_item(struct config_group *group, const char *name)
|
||||
{
|
||||
struct simple_child *simple_child;
|
||||
|
||||
simple_child = kzalloc(sizeof(struct simple_child), GFP_KERNEL);
|
||||
if (!simple_child)
|
||||
return ERR_PTR(-ENOMEM);
|
||||
|
||||
config_item_init_type_name(&simple_child->item, name,
|
||||
&simple_child_type);
|
||||
|
||||
simple_child->storeme = 0;
|
||||
|
||||
return &simple_child->item;
|
||||
}
|
||||
|
||||
static struct configfs_attribute simple_children_attr_description = {
|
||||
.ca_owner = THIS_MODULE,
|
||||
.ca_name = "description",
|
||||
.ca_mode = S_IRUGO,
|
||||
};
|
||||
|
||||
static struct configfs_attribute *simple_children_attrs[] = {
|
||||
&simple_children_attr_description,
|
||||
NULL,
|
||||
};
|
||||
|
||||
static ssize_t simple_children_attr_show(struct config_item *item,
|
||||
struct configfs_attribute *attr,
|
||||
char *page)
|
||||
{
|
||||
return sprintf(page,
|
||||
"[02-simple-children]\n"
|
||||
"\n"
|
||||
"This subsystem allows the creation of child config_items. These\n"
|
||||
"items have only one attribute that is readable and writeable.\n");
|
||||
}
|
||||
|
||||
static void simple_children_release(struct config_item *item)
|
||||
{
|
||||
kfree(to_simple_children(item));
|
||||
}
|
||||
|
||||
static struct configfs_item_operations simple_children_item_ops = {
|
||||
.release = simple_children_release,
|
||||
.show_attribute = simple_children_attr_show,
|
||||
};
|
||||
|
||||
/*
|
||||
* Note that, since no extra work is required on ->drop_item(),
|
||||
* no ->drop_item() is provided.
|
||||
*/
|
||||
static struct configfs_group_operations simple_children_group_ops = {
|
||||
.make_item = simple_children_make_item,
|
||||
};
|
||||
|
||||
static struct config_item_type simple_children_type = {
|
||||
.ct_item_ops = &simple_children_item_ops,
|
||||
.ct_group_ops = &simple_children_group_ops,
|
||||
.ct_attrs = simple_children_attrs,
|
||||
.ct_owner = THIS_MODULE,
|
||||
};
|
||||
|
||||
static struct configfs_subsystem simple_children_subsys = {
|
||||
.su_group = {
|
||||
.cg_item = {
|
||||
.ci_namebuf = "02-simple-children",
|
||||
.ci_type = &simple_children_type,
|
||||
},
|
||||
},
|
||||
};
|
||||
|
||||
|
||||
/* ----------------------------------------------------------------- */
|
||||
|
||||
/*
|
||||
* 03-group-children
|
||||
*
|
||||
* This example reuses the simple_children group from above. However,
|
||||
* the simple_children group is not the subsystem itself, it is a
|
||||
* child of the subsystem. Creation of a group in the subsystem creates
|
||||
* a new simple_children group. That group can then have simple_child
|
||||
* children of its own.
|
||||
*/
|
||||
|
||||
static struct config_group *group_children_make_group(struct config_group *group, const char *name)
|
||||
{
|
||||
struct simple_children *simple_children;
|
||||
|
||||
simple_children = kzalloc(sizeof(struct simple_children),
|
||||
GFP_KERNEL);
|
||||
if (!simple_children)
|
||||
return ERR_PTR(-ENOMEM);
|
||||
|
||||
config_group_init_type_name(&simple_children->group, name,
|
||||
&simple_children_type);
|
||||
|
||||
return &simple_children->group;
|
||||
}
|
||||
|
||||
static struct configfs_attribute group_children_attr_description = {
|
||||
.ca_owner = THIS_MODULE,
|
||||
.ca_name = "description",
|
||||
.ca_mode = S_IRUGO,
|
||||
};
|
||||
|
||||
static struct configfs_attribute *group_children_attrs[] = {
|
||||
&group_children_attr_description,
|
||||
NULL,
|
||||
};
|
||||
|
||||
static ssize_t group_children_attr_show(struct config_item *item,
|
||||
struct configfs_attribute *attr,
|
||||
char *page)
|
||||
{
|
||||
return sprintf(page,
|
||||
"[03-group-children]\n"
|
||||
"\n"
|
||||
"This subsystem allows the creation of child config_groups. These\n"
|
||||
"groups are like the subsystem simple-children.\n");
|
||||
}
|
||||
|
||||
static struct configfs_item_operations group_children_item_ops = {
|
||||
.show_attribute = group_children_attr_show,
|
||||
};
|
||||
|
||||
/*
|
||||
* Note that, since no extra work is required on ->drop_item(),
|
||||
* no ->drop_item() is provided.
|
||||
*/
|
||||
static struct configfs_group_operations group_children_group_ops = {
|
||||
.make_group = group_children_make_group,
|
||||
};
|
||||
|
||||
static struct config_item_type group_children_type = {
|
||||
.ct_item_ops = &group_children_item_ops,
|
||||
.ct_group_ops = &group_children_group_ops,
|
||||
.ct_attrs = group_children_attrs,
|
||||
.ct_owner = THIS_MODULE,
|
||||
};
|
||||
|
||||
static struct configfs_subsystem group_children_subsys = {
|
||||
.su_group = {
|
||||
.cg_item = {
|
||||
.ci_namebuf = "03-group-children",
|
||||
.ci_type = &group_children_type,
|
||||
},
|
||||
},
|
||||
};
|
||||
|
||||
/* ----------------------------------------------------------------- */
|
||||
|
||||
/*
|
||||
* We're now done with our subsystem definitions.
|
||||
* For convenience in this module, here's a list of them all. It
|
||||
* allows the init function to easily register them. Most modules
|
||||
* will only have one subsystem, and will only call register_subsystem
|
||||
* on it directly.
|
||||
*/
|
||||
static struct configfs_subsystem *example_subsys[] = {
|
||||
&childless_subsys.subsys,
|
||||
&simple_children_subsys,
|
||||
&group_children_subsys,
|
||||
NULL,
|
||||
};
|
||||
|
||||
static int __init configfs_example_init(void)
|
||||
{
|
||||
int ret;
|
||||
int i;
|
||||
struct configfs_subsystem *subsys;
|
||||
|
||||
for (i = 0; example_subsys[i]; i++) {
|
||||
subsys = example_subsys[i];
|
||||
|
||||
config_group_init(&subsys->su_group);
|
||||
mutex_init(&subsys->su_mutex);
|
||||
ret = configfs_register_subsystem(subsys);
|
||||
if (ret) {
|
||||
printk(KERN_ERR "Error %d while registering subsystem %s\n",
|
||||
ret,
|
||||
subsys->su_group.cg_item.ci_namebuf);
|
||||
goto out_unregister;
|
||||
}
|
||||
}
|
||||
|
||||
return 0;
|
||||
|
||||
out_unregister:
|
||||
for (; i >= 0; i--) {
|
||||
configfs_unregister_subsystem(example_subsys[i]);
|
||||
}
|
||||
|
||||
return ret;
|
||||
}
|
||||
|
||||
static void __exit configfs_example_exit(void)
|
||||
{
|
||||
int i;
|
||||
|
||||
for (i = 0; example_subsys[i]; i++) {
|
||||
configfs_unregister_subsystem(example_subsys[i]);
|
||||
}
|
||||
}
|
||||
|
||||
module_init(configfs_example_init);
|
||||
module_exit(configfs_example_exit);
|
||||
MODULE_LICENSE("GPL");
|
||||
448
Documentation/filesystems/configfs/configfs_example_macros.c
Normal file
448
Documentation/filesystems/configfs/configfs_example_macros.c
Normal file
@ -0,0 +1,448 @@
|
||||
/*
|
||||
* vim: noexpandtab ts=8 sts=0 sw=8:
|
||||
*
|
||||
* configfs_example_macros.c - This file is a demonstration module
|
||||
* containing a number of configfs subsystems. It uses the helper
|
||||
* macros defined by configfs.h
|
||||
*
|
||||
* This program is free software; you can redistribute it and/or
|
||||
* modify it under the terms of the GNU General Public
|
||||
* License as published by the Free Software Foundation; either
|
||||
* version 2 of the License, or (at your option) any later version.
|
||||
*
|
||||
* 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.
|
||||
*
|
||||
* 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 021110-1307, USA.
|
||||
*
|
||||
* Based on sysfs:
|
||||
* sysfs is Copyright (C) 2001, 2002, 2003 Patrick Mochel
|
||||
*
|
||||
* configfs Copyright (C) 2005 Oracle. All rights reserved.
|
||||
*/
|
||||
|
||||
#include <linux/init.h>
|
||||
#include <linux/module.h>
|
||||
#include <linux/slab.h>
|
||||
|
||||
#include <linux/configfs.h>
|
||||
|
||||
|
||||
|
||||
/*
|
||||
* 01-childless
|
||||
*
|
||||
* This first example is a childless subsystem. It cannot create
|
||||
* any config_items. It just has attributes.
|
||||
*
|
||||
* Note that we are enclosing the configfs_subsystem inside a container.
|
||||
* This is not necessary if a subsystem has no attributes directly
|
||||
* on the subsystem. See the next example, 02-simple-children, for
|
||||
* such a subsystem.
|
||||
*/
|
||||
|
||||
struct childless {
|
||||
struct configfs_subsystem subsys;
|
||||
int showme;
|
||||
int storeme;
|
||||
};
|
||||
|
||||
static inline struct childless *to_childless(struct config_item *item)
|
||||
{
|
||||
return item ? container_of(to_configfs_subsystem(to_config_group(item)), struct childless, subsys) : NULL;
|
||||
}
|
||||
|
||||
CONFIGFS_ATTR_STRUCT(childless);
|
||||
#define CHILDLESS_ATTR(_name, _mode, _show, _store) \
|
||||
struct childless_attribute childless_attr_##_name = __CONFIGFS_ATTR(_name, _mode, _show, _store)
|
||||
#define CHILDLESS_ATTR_RO(_name, _show) \
|
||||
struct childless_attribute childless_attr_##_name = __CONFIGFS_ATTR_RO(_name, _show);
|
||||
|
||||
static ssize_t childless_showme_read(struct childless *childless,
|
||||
char *page)
|
||||
{
|
||||
ssize_t pos;
|
||||
|
||||
pos = sprintf(page, "%d\n", childless->showme);
|
||||
childless->showme++;
|
||||
|
||||
return pos;
|
||||
}
|
||||
|
||||
static ssize_t childless_storeme_read(struct childless *childless,
|
||||
char *page)
|
||||
{
|
||||
return sprintf(page, "%d\n", childless->storeme);
|
||||
}
|
||||
|
||||
static ssize_t childless_storeme_write(struct childless *childless,
|
||||
const char *page,
|
||||
size_t count)
|
||||
{
|
||||
unsigned long tmp;
|
||||
char *p = (char *) page;
|
||||
|
||||
tmp = simple_strtoul(p, &p, 10);
|
||||
if (!p || (*p && (*p != '\n')))
|
||||
return -EINVAL;
|
||||
|
||||
if (tmp > INT_MAX)
|
||||
return -ERANGE;
|
||||
|
||||
childless->storeme = tmp;
|
||||
|
||||
return count;
|
||||
}
|
||||
|
||||
static ssize_t childless_description_read(struct childless *childless,
|
||||
char *page)
|
||||
{
|
||||
return sprintf(page,
|
||||
"[01-childless]\n"
|
||||
"\n"
|
||||
"The childless subsystem is the simplest possible subsystem in\n"
|
||||
"configfs. It does not support the creation of child config_items.\n"
|
||||
"It only has a few attributes. In fact, it isn't much different\n"
|
||||
"than a directory in /proc.\n");
|
||||
}
|
||||
|
||||
CHILDLESS_ATTR_RO(showme, childless_showme_read);
|
||||
CHILDLESS_ATTR(storeme, S_IRUGO | S_IWUSR, childless_storeme_read,
|
||||
childless_storeme_write);
|
||||
CHILDLESS_ATTR_RO(description, childless_description_read);
|
||||
|
||||
static struct configfs_attribute *childless_attrs[] = {
|
||||
&childless_attr_showme.attr,
|
||||
&childless_attr_storeme.attr,
|
||||
&childless_attr_description.attr,
|
||||
NULL,
|
||||
};
|
||||
|
||||
CONFIGFS_ATTR_OPS(childless);
|
||||
static struct configfs_item_operations childless_item_ops = {
|
||||
.show_attribute = childless_attr_show,
|
||||
.store_attribute = childless_attr_store,
|
||||
};
|
||||
|
||||
static struct config_item_type childless_type = {
|
||||
.ct_item_ops = &childless_item_ops,
|
||||
.ct_attrs = childless_attrs,
|
||||
.ct_owner = THIS_MODULE,
|
||||
};
|
||||
|
||||
static struct childless childless_subsys = {
|
||||
.subsys = {
|
||||
.su_group = {
|
||||
.cg_item = {
|
||||
.ci_namebuf = "01-childless",
|
||||
.ci_type = &childless_type,
|
||||
},
|
||||
},
|
||||
},
|
||||
};
|
||||
|
||||
|
||||
/* ----------------------------------------------------------------- */
|
||||
|
||||
/*
|
||||
* 02-simple-children
|
||||
*
|
||||
* This example merely has a simple one-attribute child. Note that
|
||||
* there is no extra attribute structure, as the child's attribute is
|
||||
* known from the get-go. Also, there is no container for the
|
||||
* subsystem, as it has no attributes of its own.
|
||||
*/
|
||||
|
||||
struct simple_child {
|
||||
struct config_item item;
|
||||
int storeme;
|
||||
};
|
||||
|
||||
static inline struct simple_child *to_simple_child(struct config_item *item)
|
||||
{
|
||||
return item ? container_of(item, struct simple_child, item) : NULL;
|
||||
}
|
||||
|
||||
static struct configfs_attribute simple_child_attr_storeme = {
|
||||
.ca_owner = THIS_MODULE,
|
||||
.ca_name = "storeme",
|
||||
.ca_mode = S_IRUGO | S_IWUSR,
|
||||
};
|
||||
|
||||
static struct configfs_attribute *simple_child_attrs[] = {
|
||||
&simple_child_attr_storeme,
|
||||
NULL,
|
||||
};
|
||||
|
||||
static ssize_t simple_child_attr_show(struct config_item *item,
|
||||
struct configfs_attribute *attr,
|
||||
char *page)
|
||||
{
|
||||
ssize_t count;
|
||||
struct simple_child *simple_child = to_simple_child(item);
|
||||
|
||||
count = sprintf(page, "%d\n", simple_child->storeme);
|
||||
|
||||
return count;
|
||||
}
|
||||
|
||||
static ssize_t simple_child_attr_store(struct config_item *item,
|
||||
struct configfs_attribute *attr,
|
||||
const char *page, size_t count)
|
||||
{
|
||||
struct simple_child *simple_child = to_simple_child(item);
|
||||
unsigned long tmp;
|
||||
char *p = (char *) page;
|
||||
|
||||
tmp = simple_strtoul(p, &p, 10);
|
||||
if (!p || (*p && (*p != '\n')))
|
||||
return -EINVAL;
|
||||
|
||||
if (tmp > INT_MAX)
|
||||
return -ERANGE;
|
||||
|
||||
simple_child->storeme = tmp;
|
||||
|
||||
return count;
|
||||
}
|
||||
|
||||
static void simple_child_release(struct config_item *item)
|
||||
{
|
||||
kfree(to_simple_child(item));
|
||||
}
|
||||
|
||||
static struct configfs_item_operations simple_child_item_ops = {
|
||||
.release = simple_child_release,
|
||||
.show_attribute = simple_child_attr_show,
|
||||
.store_attribute = simple_child_attr_store,
|
||||
};
|
||||
|
||||
static struct config_item_type simple_child_type = {
|
||||
.ct_item_ops = &simple_child_item_ops,
|
||||
.ct_attrs = simple_child_attrs,
|
||||
.ct_owner = THIS_MODULE,
|
||||
};
|
||||
|
||||
|
||||
struct simple_children {
|
||||
struct config_group group;
|
||||
};
|
||||
|
||||
static inline struct simple_children *to_simple_children(struct config_item *item)
|
||||
{
|
||||
return item ? container_of(to_config_group(item), struct simple_children, group) : NULL;
|
||||
}
|
||||
|
||||
static struct config_item *simple_children_make_item(struct config_group *group, const char *name)
|
||||
{
|
||||
struct simple_child *simple_child;
|
||||
|
||||
simple_child = kzalloc(sizeof(struct simple_child), GFP_KERNEL);
|
||||
if (!simple_child)
|
||||
return ERR_PTR(-ENOMEM);
|
||||
|
||||
config_item_init_type_name(&simple_child->item, name,
|
||||
&simple_child_type);
|
||||
|
||||
simple_child->storeme = 0;
|
||||
|
||||
return &simple_child->item;
|
||||
}
|
||||
|
||||
static struct configfs_attribute simple_children_attr_description = {
|
||||
.ca_owner = THIS_MODULE,
|
||||
.ca_name = "description",
|
||||
.ca_mode = S_IRUGO,
|
||||
};
|
||||
|
||||
static struct configfs_attribute *simple_children_attrs[] = {
|
||||
&simple_children_attr_description,
|
||||
NULL,
|
||||
};
|
||||
|
||||
static ssize_t simple_children_attr_show(struct config_item *item,
|
||||
struct configfs_attribute *attr,
|
||||
char *page)
|
||||
{
|
||||
return sprintf(page,
|
||||
"[02-simple-children]\n"
|
||||
"\n"
|
||||
"This subsystem allows the creation of child config_items. These\n"
|
||||
"items have only one attribute that is readable and writeable.\n");
|
||||
}
|
||||
|
||||
static void simple_children_release(struct config_item *item)
|
||||
{
|
||||
kfree(to_simple_children(item));
|
||||
}
|
||||
|
||||
static struct configfs_item_operations simple_children_item_ops = {
|
||||
.release = simple_children_release,
|
||||
.show_attribute = simple_children_attr_show,
|
||||
};
|
||||
|
||||
/*
|
||||
* Note that, since no extra work is required on ->drop_item(),
|
||||
* no ->drop_item() is provided.
|
||||
*/
|
||||
static struct configfs_group_operations simple_children_group_ops = {
|
||||
.make_item = simple_children_make_item,
|
||||
};
|
||||
|
||||
static struct config_item_type simple_children_type = {
|
||||
.ct_item_ops = &simple_children_item_ops,
|
||||
.ct_group_ops = &simple_children_group_ops,
|
||||
.ct_attrs = simple_children_attrs,
|
||||
.ct_owner = THIS_MODULE,
|
||||
};
|
||||
|
||||
static struct configfs_subsystem simple_children_subsys = {
|
||||
.su_group = {
|
||||
.cg_item = {
|
||||
.ci_namebuf = "02-simple-children",
|
||||
.ci_type = &simple_children_type,
|
||||
},
|
||||
},
|
||||
};
|
||||
|
||||
|
||||
/* ----------------------------------------------------------------- */
|
||||
|
||||
/*
|
||||
* 03-group-children
|
||||
*
|
||||
* This example reuses the simple_children group from above. However,
|
||||
* the simple_children group is not the subsystem itself, it is a
|
||||
* child of the subsystem. Creation of a group in the subsystem creates
|
||||
* a new simple_children group. That group can then have simple_child
|
||||
* children of its own.
|
||||
*/
|
||||
|
||||
static struct config_group *group_children_make_group(struct config_group *group, const char *name)
|
||||
{
|
||||
struct simple_children *simple_children;
|
||||
|
||||
simple_children = kzalloc(sizeof(struct simple_children),
|
||||
GFP_KERNEL);
|
||||
if (!simple_children)
|
||||
return ERR_PTR(-ENOMEM);
|
||||
|
||||
config_group_init_type_name(&simple_children->group, name,
|
||||
&simple_children_type);
|
||||
|
||||
return &simple_children->group;
|
||||
}
|
||||
|
||||
static struct configfs_attribute group_children_attr_description = {
|
||||
.ca_owner = THIS_MODULE,
|
||||
.ca_name = "description",
|
||||
.ca_mode = S_IRUGO,
|
||||
};
|
||||
|
||||
static struct configfs_attribute *group_children_attrs[] = {
|
||||
&group_children_attr_description,
|
||||
NULL,
|
||||
};
|
||||
|
||||
static ssize_t group_children_attr_show(struct config_item *item,
|
||||
struct configfs_attribute *attr,
|
||||
char *page)
|
||||
{
|
||||
return sprintf(page,
|
||||
"[03-group-children]\n"
|
||||
"\n"
|
||||
"This subsystem allows the creation of child config_groups. These\n"
|
||||
"groups are like the subsystem simple-children.\n");
|
||||
}
|
||||
|
||||
static struct configfs_item_operations group_children_item_ops = {
|
||||
.show_attribute = group_children_attr_show,
|
||||
};
|
||||
|
||||
/*
|
||||
* Note that, since no extra work is required on ->drop_item(),
|
||||
* no ->drop_item() is provided.
|
||||
*/
|
||||
static struct configfs_group_operations group_children_group_ops = {
|
||||
.make_group = group_children_make_group,
|
||||
};
|
||||
|
||||
static struct config_item_type group_children_type = {
|
||||
.ct_item_ops = &group_children_item_ops,
|
||||
.ct_group_ops = &group_children_group_ops,
|
||||
.ct_attrs = group_children_attrs,
|
||||
.ct_owner = THIS_MODULE,
|
||||
};
|
||||
|
||||
static struct configfs_subsystem group_children_subsys = {
|
||||
.su_group = {
|
||||
.cg_item = {
|
||||
.ci_namebuf = "03-group-children",
|
||||
.ci_type = &group_children_type,
|
||||
},
|
||||
},
|
||||
};
|
||||
|
||||
/* ----------------------------------------------------------------- */
|
||||
|
||||
/*
|
||||
* We're now done with our subsystem definitions.
|
||||
* For convenience in this module, here's a list of them all. It
|
||||
* allows the init function to easily register them. Most modules
|
||||
* will only have one subsystem, and will only call register_subsystem
|
||||
* on it directly.
|
||||
*/
|
||||
static struct configfs_subsystem *example_subsys[] = {
|
||||
&childless_subsys.subsys,
|
||||
&simple_children_subsys,
|
||||
&group_children_subsys,
|
||||
NULL,
|
||||
};
|
||||
|
||||
static int __init configfs_example_init(void)
|
||||
{
|
||||
int ret;
|
||||
int i;
|
||||
struct configfs_subsystem *subsys;
|
||||
|
||||
for (i = 0; example_subsys[i]; i++) {
|
||||
subsys = example_subsys[i];
|
||||
|
||||
config_group_init(&subsys->su_group);
|
||||
mutex_init(&subsys->su_mutex);
|
||||
ret = configfs_register_subsystem(subsys);
|
||||
if (ret) {
|
||||
printk(KERN_ERR "Error %d while registering subsystem %s\n",
|
||||
ret,
|
||||
subsys->su_group.cg_item.ci_namebuf);
|
||||
goto out_unregister;
|
||||
}
|
||||
}
|
||||
|
||||
return 0;
|
||||
|
||||
out_unregister:
|
||||
for (; i >= 0; i--) {
|
||||
configfs_unregister_subsystem(example_subsys[i]);
|
||||
}
|
||||
|
||||
return ret;
|
||||
}
|
||||
|
||||
static void __exit configfs_example_exit(void)
|
||||
{
|
||||
int i;
|
||||
|
||||
for (i = 0; example_subsys[i]; i++) {
|
||||
configfs_unregister_subsystem(example_subsys[i]);
|
||||
}
|
||||
}
|
||||
|
||||
module_init(configfs_example_init);
|
||||
module_exit(configfs_example_exit);
|
||||
MODULE_LICENSE("GPL");
|
||||
@ -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
|
||||
|
||||
@ -40,7 +40,7 @@ Web site
|
||||
========
|
||||
|
||||
There is plenty of additional information on the linux-ntfs web site
|
||||
at http://linux-ntfs.sourceforge.net/
|
||||
at http://www.linux-ntfs.org/
|
||||
|
||||
The web site has a lot of additional information, such as a comprehensive
|
||||
FAQ, documentation on the NTFS on-disk format, information on the Linux-NTFS
|
||||
@ -272,7 +272,7 @@ And you would know that /dev/hda2 has a size of 37768814 - 4209030 + 1 =
|
||||
For Win2k and later dynamic disks, you can for example use the ldminfo utility
|
||||
which is part of the Linux LDM tools (the latest version at the time of
|
||||
writing is linux-ldm-0.0.8.tar.bz2). You can download it from:
|
||||
http://linux-ntfs.sourceforge.net/downloads.html
|
||||
http://www.linux-ntfs.org/
|
||||
Simply extract the downloaded archive (tar xvjf linux-ldm-0.0.8.tar.bz2), go
|
||||
into it (cd linux-ldm-0.0.8) and change to the test directory (cd test). You
|
||||
will find the precompiled (i386) ldminfo utility there. NOTE: You will not be
|
||||
|
||||
@ -1339,6 +1339,25 @@ Enables/Disables the protection of the per-process proc entries "maps" and
|
||||
"smaps". When enabled, the contents of these files are visible only to
|
||||
readers that are allowed to ptrace() the given process.
|
||||
|
||||
msgmni
|
||||
------
|
||||
|
||||
Maximum number of message queue ids on the system.
|
||||
This value scales to the amount of lowmem. It is automatically recomputed
|
||||
upon memory add/remove or ipc namespace creation/removal.
|
||||
When a value is written into this file, msgmni's value becomes fixed, i.e. it
|
||||
is not recomputed anymore when one of the above events occurs.
|
||||
Use auto_msgmni to change this behavior.
|
||||
|
||||
auto_msgmni
|
||||
-----------
|
||||
|
||||
Enables/Disables automatic recomputing of msgmni upon memory add/remove or
|
||||
upon ipc namespace creation/removal (see the msgmni description above).
|
||||
Echoing "1" into this file enables msgmni automatic recomputing.
|
||||
Echoing "0" turns it off.
|
||||
auto_msgmni default value is 1.
|
||||
|
||||
|
||||
2.4 /proc/sys/vm - The virtual memory subsystem
|
||||
-----------------------------------------------
|
||||
@ -2394,6 +2413,8 @@ The following 4 memory types are supported:
|
||||
- (bit 1) anonymous shared memory
|
||||
- (bit 2) file-backed private memory
|
||||
- (bit 3) file-backed shared memory
|
||||
- (bit 4) ELF header pages in file-backed private memory areas (it is
|
||||
effective only if the bit 2 is cleared)
|
||||
|
||||
Note that MMIO pages such as frame buffer are never dumped and vDSO pages
|
||||
are always dumped regardless of the bitmask status.
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -4,6 +4,7 @@
|
||||
Copyright 2008 Red Hat Inc.
|
||||
Author: Steven Rostedt <srostedt@redhat.com>
|
||||
License: The GNU Free Documentation License, Version 1.2
|
||||
(dual licensed under the GPL v2)
|
||||
Reviewers: Elias Oltmanns, Randy Dunlap, Andrew Morton,
|
||||
John Kacur, and David Teigland.
|
||||
|
||||
|
||||
@ -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>
|
||||
@ -22,34 +26,36 @@ Module Parameters
|
||||
and PWM output control functions. Using this parameter
|
||||
shouldn't be required since the BIOS usually takes care
|
||||
of this.
|
||||
|
||||
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.
|
||||
* probe_all_addr: bool Include non-standard LPC addresses 0x162e and 0x164e
|
||||
when probing for ISA devices. This is required for the
|
||||
following boards:
|
||||
- VIA EPIA SN18000
|
||||
|
||||
|
||||
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
|
||||
@ -60,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
|
||||
@ -68,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
|
||||
|
||||
@ -96,11 +96,6 @@ initial testing of the ADM1027 it was 1.00 degC steps. Analog Devices has
|
||||
confirmed this "bug". The ADT7463 is reported to work as described in the
|
||||
documentation. The current lm85 driver does not show the offset register.
|
||||
|
||||
The ADT7463 has a THERM asserted counter. This counter has a 22.76ms
|
||||
resolution and a range of 5.8 seconds. The driver implements a 32-bit
|
||||
accumulator of the counter value to extend the range to over a year. The
|
||||
counter will stay at it's max value until read.
|
||||
|
||||
See the vendor datasheets for more information. There is application note
|
||||
from National (AN-1260) with some additional information about the LM85.
|
||||
The Analog Devices datasheet is very detailed and describes a procedure for
|
||||
@ -206,13 +201,15 @@ Configuration choices:
|
||||
|
||||
The National LM85's have two vendor specific configuration
|
||||
features. Tach. mode and Spinup Control. For more details on these,
|
||||
see the LM85 datasheet or Application Note AN-1260.
|
||||
see the LM85 datasheet or Application Note AN-1260. These features
|
||||
are not currently supported by the lm85 driver.
|
||||
|
||||
The Analog Devices ADM1027 has several vendor specific enhancements.
|
||||
The number of pulses-per-rev of the fans can be set, Tach monitoring
|
||||
can be optimized for PWM operation, and an offset can be applied to
|
||||
the temperatures to compensate for systemic errors in the
|
||||
measurements.
|
||||
measurements. These features are not currently supported by the lm85
|
||||
driver.
|
||||
|
||||
In addition to the ADM1027 features, the ADT7463 also has Tmin control
|
||||
and THERM asserted counts. Automatic Tmin control acts to adjust the
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -44,7 +44,7 @@ detailed description):
|
||||
- LCD brightness control
|
||||
- Volume control
|
||||
- Fan control and monitoring: fan speed, fan enable/disable
|
||||
- Experimental: WAN enable and disable
|
||||
- WAN enable and disable
|
||||
|
||||
A compatibility table by model and feature is maintained on the web
|
||||
site, http://ibm-acpi.sf.net/. I appreciate any success or failure
|
||||
@ -1375,18 +1375,13 @@ with EINVAL, try to set pwm1_enable to 1 and pwm1 to at least 128 (255
|
||||
would be the safest choice, though).
|
||||
|
||||
|
||||
EXPERIMENTAL: WAN
|
||||
-----------------
|
||||
WAN
|
||||
---
|
||||
|
||||
procfs: /proc/acpi/ibm/wan
|
||||
sysfs device attribute: wwan_enable (deprecated)
|
||||
sysfs rfkill class: switch "tpacpi_wwan_sw"
|
||||
|
||||
This feature is marked EXPERIMENTAL because the implementation
|
||||
directly accesses hardware registers and may not work as expected. USE
|
||||
WITH CAUTION! To use this feature, you need to supply the
|
||||
experimental=1 parameter when loading the module.
|
||||
|
||||
This feature shows the presence and current state of a W-WAN (Sierra
|
||||
Wireless EV-DO) device.
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -101,6 +101,10 @@ of charge when battery became full/empty". It also could mean "value of
|
||||
charge when battery considered full/empty at given conditions (temperature,
|
||||
age)". I.e. these attributes represents real thresholds, not design values.
|
||||
|
||||
CHARGE_COUNTER - the current charge counter (in µAh). This could easily
|
||||
be negative; there is no empty or full value. It is only useful for
|
||||
relative, time-based measurements.
|
||||
|
||||
ENERGY_FULL, ENERGY_EMPTY - same as above but for energy.
|
||||
|
||||
CAPACITY - capacity in percents.
|
||||
|
||||
182
Documentation/power/regulator/consumer.txt
Normal file
182
Documentation/power/regulator/consumer.txt
Normal file
@ -0,0 +1,182 @@
|
||||
Regulator Consumer Driver Interface
|
||||
===================================
|
||||
|
||||
This text describes the regulator interface for consumer device drivers.
|
||||
Please see overview.txt for a description of the terms used in this text.
|
||||
|
||||
|
||||
1. Consumer Regulator Access (static & dynamic drivers)
|
||||
=======================================================
|
||||
|
||||
A consumer driver can get access to it's supply regulator by calling :-
|
||||
|
||||
regulator = regulator_get(dev, "Vcc");
|
||||
|
||||
The consumer passes in it's struct device pointer and power supply ID. The core
|
||||
then finds the correct regulator by consulting a machine specific lookup table.
|
||||
If the lookup is successful then this call will return a pointer to the struct
|
||||
regulator that supplies this consumer.
|
||||
|
||||
To release the regulator the consumer driver should call :-
|
||||
|
||||
regulator_put(regulator);
|
||||
|
||||
Consumers can be supplied by more than one regulator e.g. codec consumer with
|
||||
analog and digital supplies :-
|
||||
|
||||
digital = regulator_get(dev, "Vcc"); /* digital core */
|
||||
analog = regulator_get(dev, "Avdd"); /* analog */
|
||||
|
||||
The regulator access functions regulator_get() and regulator_put() will
|
||||
usually be called in your device drivers probe() and remove() respectively.
|
||||
|
||||
|
||||
2. Regulator Output Enable & Disable (static & dynamic drivers)
|
||||
====================================================================
|
||||
|
||||
A consumer can enable it's power supply by calling:-
|
||||
|
||||
int regulator_enable(regulator);
|
||||
|
||||
NOTE: The supply may already be enabled before regulator_enabled() is called.
|
||||
This may happen if the consumer shares the regulator or the regulator has been
|
||||
previously enabled by bootloader or kernel board initialization code.
|
||||
|
||||
A consumer can determine if a regulator is enabled by calling :-
|
||||
|
||||
int regulator_is_enabled(regulator);
|
||||
|
||||
This will return > zero when the regulator is enabled.
|
||||
|
||||
|
||||
A consumer can disable it's supply when no longer needed by calling :-
|
||||
|
||||
int regulator_disable(regulator);
|
||||
|
||||
NOTE: This may not disable the supply if it's shared with other consumers. The
|
||||
regulator will only be disabled when the enabled reference count is zero.
|
||||
|
||||
Finally, a regulator can be forcefully disabled in the case of an emergency :-
|
||||
|
||||
int regulator_force_disable(regulator);
|
||||
|
||||
NOTE: this will immediately and forcefully shutdown the regulator output. All
|
||||
consumers will be powered off.
|
||||
|
||||
|
||||
3. Regulator Voltage Control & Status (dynamic drivers)
|
||||
======================================================
|
||||
|
||||
Some consumer drivers need to be able to dynamically change their supply
|
||||
voltage to match system operating points. e.g. CPUfreq drivers can scale
|
||||
voltage along with frequency to save power, SD drivers may need to select the
|
||||
correct card voltage, etc.
|
||||
|
||||
Consumers can control their supply voltage by calling :-
|
||||
|
||||
int regulator_set_voltage(regulator, min_uV, max_uV);
|
||||
|
||||
Where min_uV and max_uV are the minimum and maximum acceptable voltages in
|
||||
microvolts.
|
||||
|
||||
NOTE: this can be called when the regulator is enabled or disabled. If called
|
||||
when enabled, then the voltage changes instantly, otherwise the voltage
|
||||
configuration changes and the voltage is physically set when the regulator is
|
||||
next enabled.
|
||||
|
||||
The regulators configured voltage output can be found by calling :-
|
||||
|
||||
int regulator_get_voltage(regulator);
|
||||
|
||||
NOTE: get_voltage() will return the configured output voltage whether the
|
||||
regulator is enabled or disabled and should NOT be used to determine regulator
|
||||
output state. However this can be used in conjunction with is_enabled() to
|
||||
determine the regulator physical output voltage.
|
||||
|
||||
|
||||
4. Regulator Current Limit Control & Status (dynamic drivers)
|
||||
===========================================================
|
||||
|
||||
Some consumer drivers need to be able to dynamically change their supply
|
||||
current limit to match system operating points. e.g. LCD backlight driver can
|
||||
change the current limit to vary the backlight brightness, USB drivers may want
|
||||
to set the limit to 500mA when supplying power.
|
||||
|
||||
Consumers can control their supply current limit by calling :-
|
||||
|
||||
int regulator_set_current_limit(regulator, min_uV, max_uV);
|
||||
|
||||
Where min_uA and max_uA are the minimum and maximum acceptable current limit in
|
||||
microamps.
|
||||
|
||||
NOTE: this can be called when the regulator is enabled or disabled. If called
|
||||
when enabled, then the current limit changes instantly, otherwise the current
|
||||
limit configuration changes and the current limit is physically set when the
|
||||
regulator is next enabled.
|
||||
|
||||
A regulators current limit can be found by calling :-
|
||||
|
||||
int regulator_get_current_limit(regulator);
|
||||
|
||||
NOTE: get_current_limit() will return the current limit whether the regulator
|
||||
is enabled or disabled and should not be used to determine regulator current
|
||||
load.
|
||||
|
||||
|
||||
5. Regulator Operating Mode Control & Status (dynamic drivers)
|
||||
=============================================================
|
||||
|
||||
Some consumers can further save system power by changing the operating mode of
|
||||
their supply regulator to be more efficient when the consumers operating state
|
||||
changes. e.g. consumer driver is idle and subsequently draws less current
|
||||
|
||||
Regulator operating mode can be changed indirectly or directly.
|
||||
|
||||
Indirect operating mode control.
|
||||
--------------------------------
|
||||
Consumer drivers can request a change in their supply regulator operating mode
|
||||
by calling :-
|
||||
|
||||
int regulator_set_optimum_mode(struct regulator *regulator, int load_uA);
|
||||
|
||||
This will cause the core to recalculate the total load on the regulator (based
|
||||
on all it's consumers) and change operating mode (if necessary and permitted)
|
||||
to best match the current operating load.
|
||||
|
||||
The load_uA value can be determined from the consumers datasheet. e.g.most
|
||||
datasheets have tables showing the max current consumed in certain situations.
|
||||
|
||||
Most consumers will use indirect operating mode control since they have no
|
||||
knowledge of the regulator or whether the regulator is shared with other
|
||||
consumers.
|
||||
|
||||
Direct operating mode control.
|
||||
------------------------------
|
||||
Bespoke or tightly coupled drivers may want to directly control regulator
|
||||
operating mode depending on their operating point. This can be achieved by
|
||||
calling :-
|
||||
|
||||
int regulator_set_mode(struct regulator *regulator, unsigned int mode);
|
||||
unsigned int regulator_get_mode(struct regulator *regulator);
|
||||
|
||||
Direct mode will only be used by consumers that *know* about the regulator and
|
||||
are not sharing the regulator with other consumers.
|
||||
|
||||
|
||||
6. Regulator Events
|
||||
===================
|
||||
Regulators can notify consumers of external events. Events could be received by
|
||||
consumers under regulator stress or failure conditions.
|
||||
|
||||
Consumers can register interest in regulator events by calling :-
|
||||
|
||||
int regulator_register_notifier(struct regulator *regulator,
|
||||
struct notifier_block *nb);
|
||||
|
||||
Consumers can uregister interest by calling :-
|
||||
|
||||
int regulator_unregister_notifier(struct regulator *regulator,
|
||||
struct notifier_block *nb);
|
||||
|
||||
Regulators use the kernel notifier framework to send event to thier interested
|
||||
consumers.
|
||||
101
Documentation/power/regulator/machine.txt
Normal file
101
Documentation/power/regulator/machine.txt
Normal file
@ -0,0 +1,101 @@
|
||||
Regulator Machine Driver Interface
|
||||
===================================
|
||||
|
||||
The regulator machine driver interface is intended for board/machine specific
|
||||
initialisation code to configure the regulator subsystem. Typical things that
|
||||
machine drivers would do are :-
|
||||
|
||||
1. Regulator -> Device mapping.
|
||||
2. Regulator supply configuration.
|
||||
3. Power Domain constraint setting.
|
||||
|
||||
|
||||
|
||||
1. Regulator -> device mapping
|
||||
==============================
|
||||
Consider the following machine :-
|
||||
|
||||
Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V]
|
||||
|
|
||||
+-> [Consumer B @ 3.3V]
|
||||
|
||||
The drivers for consumers A & B must be mapped to the correct regulator in
|
||||
order to control their power supply. This mapping can be achieved in machine
|
||||
initialisation code by calling :-
|
||||
|
||||
int regulator_set_device_supply(const char *regulator, struct device *dev,
|
||||
const char *supply);
|
||||
|
||||
and is shown with the following code :-
|
||||
|
||||
regulator_set_device_supply("Regulator-1", devB, "Vcc");
|
||||
regulator_set_device_supply("Regulator-2", devA, "Vcc");
|
||||
|
||||
This maps Regulator-1 to the 'Vcc' supply for Consumer B and maps Regulator-2
|
||||
to the 'Vcc' supply for Consumer A.
|
||||
|
||||
|
||||
2. Regulator supply configuration.
|
||||
==================================
|
||||
Consider the following machine (again) :-
|
||||
|
||||
Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V]
|
||||
|
|
||||
+-> [Consumer B @ 3.3V]
|
||||
|
||||
Regulator-1 supplies power to Regulator-2. This relationship must be registered
|
||||
with the core so that Regulator-1 is also enabled when Consumer A enables it's
|
||||
supply (Regulator-2).
|
||||
|
||||
This relationship can be register with the core via :-
|
||||
|
||||
int regulator_set_supply(const char *regulator, const char *regulator_supply);
|
||||
|
||||
In this example we would use the following code :-
|
||||
|
||||
regulator_set_supply("Regulator-2", "Regulator-1");
|
||||
|
||||
Relationships can be queried by calling :-
|
||||
|
||||
const char *regulator_get_supply(const char *regulator);
|
||||
|
||||
|
||||
3. Power Domain constraint setting.
|
||||
===================================
|
||||
Each power domain within a system has physical constraints on voltage and
|
||||
current. This must be defined in software so that the power domain is always
|
||||
operated within specifications.
|
||||
|
||||
Consider the following machine (again) :-
|
||||
|
||||
Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V]
|
||||
|
|
||||
+-> [Consumer B @ 3.3V]
|
||||
|
||||
This gives us two regulators and two power domains:
|
||||
|
||||
Domain 1: Regulator-2, Consumer B.
|
||||
Domain 2: Consumer A.
|
||||
|
||||
Constraints can be registered by calling :-
|
||||
|
||||
int regulator_set_platform_constraints(const char *regulator,
|
||||
struct regulation_constraints *constraints);
|
||||
|
||||
The example is defined as follows :-
|
||||
|
||||
struct regulation_constraints domain_1 = {
|
||||
.min_uV = 3300000,
|
||||
.max_uV = 3300000,
|
||||
.valid_modes_mask = REGULATOR_MODE_NORMAL,
|
||||
};
|
||||
|
||||
struct regulation_constraints domain_2 = {
|
||||
.min_uV = 1800000,
|
||||
.max_uV = 2000000,
|
||||
.valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
|
||||
.valid_modes_mask = REGULATOR_MODE_NORMAL,
|
||||
};
|
||||
|
||||
regulator_set_platform_constraints("Regulator-1", &domain_1);
|
||||
regulator_set_platform_constraints("Regulator-2", &domain_2);
|
||||
171
Documentation/power/regulator/overview.txt
Normal file
171
Documentation/power/regulator/overview.txt
Normal file
@ -0,0 +1,171 @@
|
||||
Linux voltage and current regulator framework
|
||||
=============================================
|
||||
|
||||
About
|
||||
=====
|
||||
|
||||
This framework is designed to provide a standard kernel interface to control
|
||||
voltage and current regulators.
|
||||
|
||||
The intention is to allow systems to dynamically control regulator power output
|
||||
in order to save power and prolong battery life. This applies to both voltage
|
||||
regulators (where voltage output is controllable) and current sinks (where
|
||||
current limit is controllable).
|
||||
|
||||
(C) 2008 Wolfson Microelectronics PLC.
|
||||
Author: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
|
||||
|
||||
Nomenclature
|
||||
============
|
||||
|
||||
Some terms used in this document:-
|
||||
|
||||
o Regulator - Electronic device that supplies power to other devices.
|
||||
Most regulators can enable and disable their output whilst
|
||||
some can control their output voltage and or current.
|
||||
|
||||
Input Voltage -> Regulator -> Output Voltage
|
||||
|
||||
|
||||
o PMIC - Power Management IC. An IC that contains numerous regulators
|
||||
and often contains other susbsystems.
|
||||
|
||||
|
||||
o Consumer - Electronic device that is supplied power by a regulator.
|
||||
Consumers can be classified into two types:-
|
||||
|
||||
Static: consumer does not change it's supply voltage or
|
||||
current limit. It only needs to enable or disable it's
|
||||
power supply. It's supply voltage is set by the hardware,
|
||||
bootloader, firmware or kernel board initialisation code.
|
||||
|
||||
Dynamic: consumer needs to change it's supply voltage or
|
||||
current limit to meet operation demands.
|
||||
|
||||
|
||||
o Power Domain - Electronic circuit that is supplied it's input power by the
|
||||
output power of a regulator, switch or by another power
|
||||
domain.
|
||||
|
||||
The supply regulator may be behind a switch(s). i.e.
|
||||
|
||||
Regulator -+-> Switch-1 -+-> Switch-2 --> [Consumer A]
|
||||
| |
|
||||
| +-> [Consumer B], [Consumer C]
|
||||
|
|
||||
+-> [Consumer D], [Consumer E]
|
||||
|
||||
That is one regulator and three power domains:
|
||||
|
||||
Domain 1: Switch-1, Consumers D & E.
|
||||
Domain 2: Switch-2, Consumers B & C.
|
||||
Domain 3: Consumer A.
|
||||
|
||||
and this represents a "supplies" relationship:
|
||||
|
||||
Domain-1 --> Domain-2 --> Domain-3.
|
||||
|
||||
A power domain may have regulators that are supplied power
|
||||
by other regulators. i.e.
|
||||
|
||||
Regulator-1 -+-> Regulator-2 -+-> [Consumer A]
|
||||
|
|
||||
+-> [Consumer B]
|
||||
|
||||
This gives us two regulators and two power domains:
|
||||
|
||||
Domain 1: Regulator-2, Consumer B.
|
||||
Domain 2: Consumer A.
|
||||
|
||||
and a "supplies" relationship:
|
||||
|
||||
Domain-1 --> Domain-2
|
||||
|
||||
|
||||
o Constraints - Constraints are used to define power levels for performance
|
||||
and hardware protection. Constraints exist at three levels:
|
||||
|
||||
Regulator Level: This is defined by the regulator hardware
|
||||
operating parameters and is specified in the regulator
|
||||
datasheet. i.e.
|
||||
|
||||
- voltage output is in the range 800mV -> 3500mV.
|
||||
- regulator current output limit is 20mA @ 5V but is
|
||||
10mA @ 10V.
|
||||
|
||||
Power Domain Level: This is defined in software by kernel
|
||||
level board initialisation code. It is used to constrain a
|
||||
power domain to a particular power range. i.e.
|
||||
|
||||
- Domain-1 voltage is 3300mV
|
||||
- Domain-2 voltage is 1400mV -> 1600mV
|
||||
- Domain-3 current limit is 0mA -> 20mA.
|
||||
|
||||
Consumer Level: This is defined by consumer drivers
|
||||
dynamically setting voltage or current limit levels.
|
||||
|
||||
e.g. a consumer backlight driver asks for a current increase
|
||||
from 5mA to 10mA to increase LCD illumination. This passes
|
||||
to through the levels as follows :-
|
||||
|
||||
Consumer: need to increase LCD brightness. Lookup and
|
||||
request next current mA value in brightness table (the
|
||||
consumer driver could be used on several different
|
||||
personalities based upon the same reference device).
|
||||
|
||||
Power Domain: is the new current limit within the domain
|
||||
operating limits for this domain and system state (e.g.
|
||||
battery power, USB power)
|
||||
|
||||
Regulator Domains: is the new current limit within the
|
||||
regulator operating parameters for input/ouput voltage.
|
||||
|
||||
If the regulator request passes all the constraint tests
|
||||
then the new regulator value is applied.
|
||||
|
||||
|
||||
Design
|
||||
======
|
||||
|
||||
The framework is designed and targeted at SoC based devices but may also be
|
||||
relevant to non SoC devices and is split into the following four interfaces:-
|
||||
|
||||
|
||||
1. Consumer driver interface.
|
||||
|
||||
This uses a similar API to the kernel clock interface in that consumer
|
||||
drivers can get and put a regulator (like they can with clocks atm) and
|
||||
get/set voltage, current limit, mode, enable and disable. This should
|
||||
allow consumers complete control over their supply voltage and current
|
||||
limit. This also compiles out if not in use so drivers can be reused in
|
||||
systems with no regulator based power control.
|
||||
|
||||
See Documentation/power/regulator/consumer.txt
|
||||
|
||||
2. Regulator driver interface.
|
||||
|
||||
This allows regulator drivers to register their regulators and provide
|
||||
operations to the core. It also has a notifier call chain for propagating
|
||||
regulator events to clients.
|
||||
|
||||
See Documentation/power/regulator/regulator.txt
|
||||
|
||||
3. Machine interface.
|
||||
|
||||
This interface is for machine specific code and allows the creation of
|
||||
voltage/current domains (with constraints) for each regulator. It can
|
||||
provide regulator constraints that will prevent device damage through
|
||||
overvoltage or over current caused by buggy client drivers. It also
|
||||
allows the creation of a regulator tree whereby some regulators are
|
||||
supplied by others (similar to a clock tree).
|
||||
|
||||
See Documentation/power/regulator/machine.txt
|
||||
|
||||
4. Userspace ABI.
|
||||
|
||||
The framework also exports a lot of useful voltage/current/opmode data to
|
||||
userspace via sysfs. This could be used to help monitor device power
|
||||
consumption and status.
|
||||
|
||||
See Documentation/ABI/testing/regulator-sysfs.txt
|
||||
30
Documentation/power/regulator/regulator.txt
Normal file
30
Documentation/power/regulator/regulator.txt
Normal file
@ -0,0 +1,30 @@
|
||||
Regulator Driver Interface
|
||||
==========================
|
||||
|
||||
The regulator driver interface is relatively simple and designed to allow
|
||||
regulator drivers to register their services with the core framework.
|
||||
|
||||
|
||||
Registration
|
||||
============
|
||||
|
||||
Drivers can register a regulator by calling :-
|
||||
|
||||
struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
|
||||
void *reg_data);
|
||||
|
||||
This will register the regulators capabilities and operations the regulator
|
||||
core. The core does not touch reg_data (private to regulator driver).
|
||||
|
||||
Regulators can be unregistered by calling :-
|
||||
|
||||
void regulator_unregister(struct regulator_dev *rdev);
|
||||
|
||||
|
||||
Regulator Events
|
||||
================
|
||||
Regulators can send events (e.g. over temp, under voltage, etc) to consumer
|
||||
drivers by calling :-
|
||||
|
||||
int regulator_notifier_call_chain(struct regulator_dev *rdev,
|
||||
unsigned long event, void *data);
|
||||
@ -20,8 +20,6 @@ mpc52xx-device-tree-bindings.txt
|
||||
- MPC5200 Device Tree Bindings
|
||||
ppc_htab.txt
|
||||
- info about the Linux/PPC /proc/ppc_htab entry
|
||||
SBC8260_memory_mapping.txt
|
||||
- EST SBC8260 board info
|
||||
smp.txt
|
||||
- use and state info about Linux/PPC on MP machines
|
||||
sound.txt
|
||||
|
||||
@ -1,197 +0,0 @@
|
||||
Please mail me (Jon Diekema, diekema_jon@si.com or diekema@cideas.com)
|
||||
if you have questions, comments or corrections.
|
||||
|
||||
* EST SBC8260 Linux memory mapping rules
|
||||
|
||||
http://www.estc.com/
|
||||
http://www.estc.com/products/boards/SBC8260-8240_ds.html
|
||||
|
||||
Initial conditions:
|
||||
-------------------
|
||||
|
||||
Tasks that need to be perform by the boot ROM before control is
|
||||
transferred to zImage (compressed Linux kernel):
|
||||
|
||||
- Define the IMMR to 0xf0000000
|
||||
|
||||
- Initialize the memory controller so that RAM is available at
|
||||
physical address 0x00000000. On the SBC8260 is this 16M (64M)
|
||||
SDRAM.
|
||||
|
||||
- The boot ROM should only clear the RAM that it is using.
|
||||
|
||||
The reason for doing this is to enhances the chances of a
|
||||
successful post mortem on a Linux panic. One of the first
|
||||
items to examine is the 16k (LOG_BUF_LEN) circular console
|
||||
buffer called log_buf which is defined in kernel/printk.c.
|
||||
|
||||
- To enhance boot ROM performance, the I-cache can be enabled.
|
||||
|
||||
Date: Mon, 22 May 2000 14:21:10 -0700
|
||||
From: Neil Russell <caret@c-side.com>
|
||||
|
||||
LiMon (LInux MONitor) runs with and starts Linux with MMU
|
||||
off, I-cache enabled, D-cache disabled. The I-cache doesn't
|
||||
need hints from the MMU to work correctly as the D-cache
|
||||
does. No D-cache means no special code to handle devices in
|
||||
the presence of cache (no snooping, etc). The use of the
|
||||
I-cache means that the monitor can run acceptably fast
|
||||
directly from ROM, rather than having to copy it to RAM.
|
||||
|
||||
- Build the board information structure (see
|
||||
include/asm-ppc/est8260.h for its definition)
|
||||
|
||||
- The compressed Linux kernel (zImage) contains a bootstrap loader
|
||||
that is position independent; you can load it into any RAM,
|
||||
ROM or FLASH memory address >= 0x00500000 (above 5 MB), or
|
||||
at its link address of 0x00400000 (4 MB).
|
||||
|
||||
Note: If zImage is loaded at its link address of 0x00400000 (4 MB),
|
||||
then zImage will skip the step of moving itself to
|
||||
its link address.
|
||||
|
||||
- Load R3 with the address of the board information structure
|
||||
|
||||
- Transfer control to zImage
|
||||
|
||||
- The Linux console port is SMC1, and the baud rate is controlled
|
||||
from the bi_baudrate field of the board information structure.
|
||||
On thing to keep in mind when picking the baud rate, is that
|
||||
there is no flow control on the SMC ports. I would stick
|
||||
with something safe and standard like 19200.
|
||||
|
||||
On the EST SBC8260, the SMC1 port is on the COM1 connector of
|
||||
the board.
|
||||
|
||||
|
||||
EST SBC8260 defaults:
|
||||
---------------------
|
||||
|
||||
Chip
|
||||
Memory Sel Bus Use
|
||||
--------------------- --- --- ----------------------------------
|
||||
0x00000000-0x03FFFFFF CS2 60x (16M or 64M)/64M SDRAM
|
||||
0x04000000-0x04FFFFFF CS4 local 4M/16M SDRAM (soldered to the board)
|
||||
0x21000000-0x21000000 CS7 60x 1B/64K Flash present detect (from the flash SIMM)
|
||||
0x21000001-0x21000001 CS7 60x 1B/64K Switches (read) and LEDs (write)
|
||||
0x22000000-0x2200FFFF CS5 60x 8K/64K EEPROM
|
||||
0xFC000000-0xFCFFFFFF CS6 60x 2M/16M flash (8 bits wide, soldered to the board)
|
||||
0xFE000000-0xFFFFFFFF CS0 60x 4M/16M flash (SIMM)
|
||||
|
||||
Notes:
|
||||
------
|
||||
|
||||
- The chip selects can map 32K blocks and up (powers of 2)
|
||||
|
||||
- The SDRAM machine can handled up to 128Mbytes per chip select
|
||||
|
||||
- Linux uses the 60x bus memory (the SDRAM DIMM) for the
|
||||
communications buffers.
|
||||
|
||||
- BATs can map 128K-256Mbytes each. There are four data BATs and
|
||||
four instruction BATs. Generally the data and instruction BATs
|
||||
are mapped the same.
|
||||
|
||||
- The IMMR must be set above the kernel virtual memory addresses,
|
||||
which start at 0xC0000000. Otherwise, the kernel may crash as
|
||||
soon as you start any threads or processes due to VM collisions
|
||||
in the kernel or user process space.
|
||||
|
||||
|
||||
Details from Dan Malek <dan_malek@mvista.com> on 10/29/1999:
|
||||
|
||||
The user application virtual space consumes the first 2 Gbytes
|
||||
(0x00000000 to 0x7FFFFFFF). The kernel virtual text starts at
|
||||
0xC0000000, with data following. There is a "protection hole"
|
||||
between the end of kernel data and the start of the kernel
|
||||
dynamically allocated space, but this space is still within
|
||||
0xCxxxxxxx.
|
||||
|
||||
Obviously the kernel can't map any physical addresses 1:1 in
|
||||
these ranges.
|
||||
|
||||
|
||||
Details from Dan Malek <dan_malek@mvista.com> on 5/19/2000:
|
||||
|
||||
During the early kernel initialization, the kernel virtual
|
||||
memory allocator is not operational. Prior to this KVM
|
||||
initialization, we choose to map virtual to physical addresses
|
||||
1:1. That is, the kernel virtual address exactly matches the
|
||||
physical address on the bus. These mappings are typically done
|
||||
in arch/ppc/kernel/head.S, or arch/ppc/mm/init.c. Only
|
||||
absolutely necessary mappings should be done at this time, for
|
||||
example board control registers or a serial uart. Normal device
|
||||
driver initialization should map resources later when necessary.
|
||||
|
||||
Although platform dependent, and certainly the case for embedded
|
||||
8xx, traditionally memory is mapped at physical address zero,
|
||||
and I/O devices above physical address 0x80000000. The lowest
|
||||
and highest (above 0xf0000000) I/O addresses are traditionally
|
||||
used for devices or registers we need to map during kernel
|
||||
initialization and prior to KVM operation. For this reason,
|
||||
and since it followed prior PowerPC platform examples, I chose
|
||||
to map the embedded 8xx kernel to the 0xc0000000 virtual address.
|
||||
This way, we can enable the MMU to map the kernel for proper
|
||||
operation, and still map a few windows before the KVM is operational.
|
||||
|
||||
On some systems, you could possibly run the kernel at the
|
||||
0x80000000 or any other virtual address. It just depends upon
|
||||
mapping that must be done prior to KVM operational. You can never
|
||||
map devices or kernel spaces that overlap with the user virtual
|
||||
space. This is why default IMMR mapping used by most BDM tools
|
||||
won't work. They put the IMMR at something like 0x10000000 or
|
||||
0x02000000 for example. You simply can't map these addresses early
|
||||
in the kernel, and continue proper system operation.
|
||||
|
||||
The embedded 8xx/82xx kernel is mature enough that all you should
|
||||
need to do is map the IMMR someplace at or above 0xf0000000 and it
|
||||
should boot far enough to get serial console messages and KGDB
|
||||
connected on any platform. There are lots of other subtle memory
|
||||
management design features that you simply don't need to worry
|
||||
about. If you are changing functions related to MMU initialization,
|
||||
you are likely breaking things that are known to work and are
|
||||
heading down a path of disaster and frustration. Your changes
|
||||
should be to make the flexibility of the processor fit Linux,
|
||||
not force arbitrary and non-workable memory mappings into Linux.
|
||||
|
||||
- You don't want to change KERNELLOAD or KERNELBASE, otherwise the
|
||||
virtual memory and MMU code will get confused.
|
||||
|
||||
arch/ppc/Makefile:KERNELLOAD = 0xc0000000
|
||||
|
||||
include/asm-ppc/page.h:#define PAGE_OFFSET 0xc0000000
|
||||
include/asm-ppc/page.h:#define KERNELBASE PAGE_OFFSET
|
||||
|
||||
- RAM is at physical address 0x00000000, and gets mapped to
|
||||
virtual address 0xC0000000 for the kernel.
|
||||
|
||||
|
||||
Physical addresses used by the Linux kernel:
|
||||
--------------------------------------------
|
||||
|
||||
0x00000000-0x3FFFFFFF 1GB reserved for RAM
|
||||
0xF0000000-0xF001FFFF 128K IMMR 64K used for dual port memory,
|
||||
64K for 8260 registers
|
||||
|
||||
|
||||
Logical addresses used by the Linux kernel:
|
||||
-------------------------------------------
|
||||
|
||||
0xF0000000-0xFFFFFFFF 256M BAT0 (IMMR: dual port RAM, registers)
|
||||
0xE0000000-0xEFFFFFFF 256M BAT1 (I/O space for custom boards)
|
||||
0xC0000000-0xCFFFFFFF 256M BAT2 (RAM)
|
||||
0xD0000000-0xDFFFFFFF 256M BAT3 (if RAM > 256MByte)
|
||||
|
||||
|
||||
EST SBC8260 Linux mapping:
|
||||
--------------------------
|
||||
|
||||
DBAT0, IBAT0, cache inhibited:
|
||||
|
||||
Chip
|
||||
Memory Sel Use
|
||||
--------------------- --- ---------------------------------
|
||||
0xF0000000-0xF001FFFF n/a IMMR: dual port RAM, registers
|
||||
|
||||
DBAT1, IBAT1, cache inhibited:
|
||||
|
||||
@ -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 {
|
||||
|
||||
@ -7,6 +7,15 @@ Currently defined compatibles:
|
||||
- fsl,cpm2-scc-uart
|
||||
- fsl,qe-uart
|
||||
|
||||
Modem control lines connected to GPIO controllers are listed in the gpios
|
||||
property as described in booting-without-of.txt, section IX.1 in the following
|
||||
order:
|
||||
|
||||
CTS, RTS, DCD, DSR, DTR, and RI.
|
||||
|
||||
The gpios property is optional and can be left out when control lines are
|
||||
not used.
|
||||
|
||||
Example:
|
||||
|
||||
serial@11a00 {
|
||||
@ -18,4 +27,6 @@ Example:
|
||||
interrupt-parent = <&PIC>;
|
||||
fsl,cpm-brg = <1>;
|
||||
fsl,cpm-command = <00800000>;
|
||||
gpios = <&gpio_c 15 0
|
||||
&gpio_d 29 0>;
|
||||
};
|
||||
|
||||
@ -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:
|
||||
--------------------------------------------------------------------
|
||||
|
||||
@ -390,9 +395,10 @@ rfkill lines are inactive, it must return RFKILL_STATE_SOFT_BLOCKED if its soft
|
||||
rfkill input line is active. Only if none of the rfkill input lines are
|
||||
active, will it return RFKILL_STATE_UNBLOCKED.
|
||||
|
||||
If it doesn't implement the get_state() hook, it must make sure that its calls
|
||||
to rfkill_force_state() are enough to keep the status always up-to-date, and it
|
||||
must do a rfkill_force_state() on resume from sleep.
|
||||
Since the device has a hardware rfkill line, it IS subject to state changes
|
||||
external to rfkill. Therefore, the driver must make sure that it calls
|
||||
rfkill_force_state() to keep the status always up-to-date, and it must do a
|
||||
rfkill_force_state() on resume from sleep.
|
||||
|
||||
Every time the driver gets a notification from the card that one of its rfkill
|
||||
lines changed state (polling might be needed on badly designed cards that don't
|
||||
@ -422,13 +428,24 @@ of the hardware is unknown), or read-write (where the hardware can be queried
|
||||
about its current state).
|
||||
|
||||
The rfkill class will call the get_state hook of a device every time it needs
|
||||
to know the *real* current state of the hardware. This can happen often.
|
||||
to know the *real* current state of the hardware. This can happen often, but
|
||||
it does not do any polling, so it is not enough on hardware that is subject
|
||||
to state changes outside of the rfkill subsystem.
|
||||
|
||||
Therefore, calling rfkill_force_state() when a state change happens is
|
||||
mandatory when the device has a hardware rfkill line, or when something else
|
||||
like the firmware could cause its state to be changed without going through the
|
||||
rfkill class.
|
||||
|
||||
Some hardware provides events when its status changes. In these cases, it is
|
||||
best for the driver to not provide a get_state hook, and instead register the
|
||||
rfkill class *already* with the correct status, and keep it updated using
|
||||
rfkill_force_state() when it gets an event from the hardware.
|
||||
|
||||
rfkill_force_state() must be used on the device resume handlers to update the
|
||||
rfkill status, should there be any chance of the device status changing during
|
||||
the sleep.
|
||||
|
||||
There is no provision for a statically-allocated rfkill struct. You must
|
||||
use rfkill_allocate() to allocate one.
|
||||
|
||||
|
||||
@ -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:
|
||||
|
||||
|
||||
@ -3,3 +3,4 @@
|
||||
2 -> Hauppauge HVR850 (au0828) [2040:7240]
|
||||
3 -> DViCO FusionHDTV USB (au0828) [0fe9:d620]
|
||||
4 -> Hauppauge HVR950Q rev xxF8 (au0828) [2040:7201,2040:7211,2040:7281]
|
||||
5 -> Hauppauge Woodbury (au0828) [2040:8200]
|
||||
|
||||
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)
|
||||
@ -88,14 +88,14 @@ zc3xx 0471:0325 Philips SPC 200 NC
|
||||
zc3xx 0471:0326 Philips SPC 300 NC
|
||||
sonixj 0471:0327 Philips SPC 600 NC
|
||||
sonixj 0471:0328 Philips SPC 700 NC
|
||||
zc3xx 0471:032d Philips spc210nc
|
||||
zc3xx 0471:032e Philips spc315nc
|
||||
sonixj 0471:0330 Philips SPC 710NC
|
||||
zc3xx 0471:032d Philips SPC 210 NC
|
||||
zc3xx 0471:032e Philips SPC 315 NC
|
||||
sonixj 0471:0330 Philips SPC 710 NC
|
||||
spca501 0497:c001 Smile International
|
||||
sunplus 04a5:3003 Benq DC 1300
|
||||
sunplus 04a5:3008 Benq DC 1500
|
||||
sunplus 04a5:300a Benq DC3410
|
||||
spca500 04a5:300c Benq DC1016
|
||||
sunplus 04a5:300a Benq DC 3410
|
||||
spca500 04a5:300c Benq DC 1016
|
||||
sunplus 04f1:1001 JVC GC A50
|
||||
spca561 04fc:0561 Flexcam 100
|
||||
sunplus 04fc:500c Sunplus CA500C
|
||||
@ -175,19 +175,21 @@ sunplus 08ca:2060 Aiptek PocketDV5300
|
||||
tv8532 0923:010f ICM532 cams
|
||||
mars 093a:050f Mars-Semi Pc-Camera
|
||||
pac207 093a:2460 PAC207 Qtec Webcam 100
|
||||
pac207 093a:2463 Philips spc200nc pac207
|
||||
pac207 093a:2463 Philips SPC 220 NC
|
||||
pac207 093a:2464 Labtec Webcam 1200
|
||||
pac207 093a:2468 PAC207
|
||||
pac207 093a:2470 Genius GF112
|
||||
pac207 093a:2471 PAC207 Genius VideoCam ge111
|
||||
pac207 093a:2472 PAC207 Genius VideoCam ge110
|
||||
pac207 093a:2471 Genius VideoCam ge111
|
||||
pac207 093a:2472 Genius VideoCam ge110
|
||||
pac7311 093a:2600 PAC7311 Typhoon
|
||||
pac7311 093a:2601 PAC7311 Phillips SPC610NC
|
||||
pac7311 093a:2601 Philips SPC 610 NC
|
||||
pac7311 093a:2603 PAC7312
|
||||
pac7311 093a:2608 PAC7311 Trust WB-3300p
|
||||
pac7311 093a:260e PAC7311 Gigaware VGA PC Camera, Trust WB-3350p, SIGMA cam 2350
|
||||
pac7311 093a:260f PAC7311 SnakeCam
|
||||
pac7311 093a:2608 Trust WB-3300p
|
||||
pac7311 093a:260e Gigaware VGA PC Camera, Trust WB-3350p, SIGMA cam 2350
|
||||
pac7311 093a:260f SnakeCam
|
||||
pac7311 093a:2621 PAC731x
|
||||
pac7311 093a:2624 PAC7302
|
||||
pac7311 093a:2626 Labtec 2200
|
||||
zc3xx 0ac8:0302 Z-star Vimicro zc0302
|
||||
vc032x 0ac8:0321 Vimicro generic vc0321
|
||||
vc032x 0ac8:0323 Vimicro Vc0323
|
||||
@ -220,12 +222,14 @@ sonixj 0c45:60c0 Sangha Sn535
|
||||
sonixj 0c45:60ec SN9C105+MO4000
|
||||
sonixj 0c45:60fb Surfer NoName
|
||||
sonixj 0c45:60fc LG-LIC300
|
||||
sonixj 0c45:6128 Microdia/Sonix SNP325
|
||||
sonixj 0c45:612a Avant Camera
|
||||
sonixj 0c45:612c Typhoon Rasy Cam 1.3MPix
|
||||
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
|
||||
@ -233,7 +237,7 @@ zc3xx 10fd:0128 Typhoon Webshot II USB 300k 0x0128
|
||||
spca561 10fd:7e50 FlyCam Usb 100
|
||||
zc3xx 10fd:8050 Typhoon Webshot II USB 300k
|
||||
spca501 1776:501c Arowana 300K CMOS Camera
|
||||
t613 17a1:0128 T613/TAS5130A
|
||||
t613 17a1:0128 TASCORP JPEG Webcam, NGS Cyclops
|
||||
vc032x 17ef:4802 Lenovo Vc0323+MI1310_SOC
|
||||
pac207 2001:f115 D-Link DSB-C120
|
||||
spca500 2899:012c Toptro Industrial
|
||||
|
||||
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)
|
||||
358
MAINTAINERS
358
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
|
||||
@ -216,8 +222,7 @@ W: http://code.google.com/p/aceracpi
|
||||
S: Maintained
|
||||
|
||||
ACPI
|
||||
P: Andi Kleen
|
||||
M: ak@linux.intel.com
|
||||
P: Len Brown
|
||||
M: lenb@kernel.org
|
||||
L: linux-acpi@vger.kernel.org
|
||||
W: http://www.lesswatts.org/projects/acpi/
|
||||
@ -266,20 +271,20 @@ W: http://www.lesswatts.org/projects/acpi/
|
||||
S: Supported
|
||||
|
||||
ACPI WMI DRIVER
|
||||
P: Carlos Corbacho
|
||||
M: carlos@strangeworlds.co.uk
|
||||
L: linux-acpi@vger.kernel.org
|
||||
W: http://www.lesswatts.org/projects/acpi/
|
||||
S: Maintained
|
||||
P: Carlos Corbacho
|
||||
M: carlos@strangeworlds.co.uk
|
||||
L: linux-acpi@vger.kernel.org
|
||||
W: http://www.lesswatts.org/projects/acpi/
|
||||
S: Maintained
|
||||
|
||||
AD1889 ALSA SOUND DRIVER
|
||||
P: Kyle McMartin
|
||||
M: kyle@mcmartin.ca
|
||||
P: Thibaut Varene
|
||||
M: T-Bone@parisc-linux.org
|
||||
W: http://wiki.parisc-linux.org/AD1889
|
||||
L: linux-parisc@vger.kernel.org
|
||||
S: Maintained
|
||||
P: Kyle McMartin
|
||||
M: kyle@mcmartin.ca
|
||||
P: Thibaut Varene
|
||||
M: T-Bone@parisc-linux.org
|
||||
W: http://wiki.parisc-linux.org/AD1889
|
||||
L: linux-parisc@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
ADM1025 HARDWARE MONITOR DRIVER
|
||||
P: Jean Delvare
|
||||
@ -418,6 +423,12 @@ L: linux-laptop@vger.kernel.org
|
||||
W: http://www.canb.auug.org.au/~sfr/
|
||||
S: Supported
|
||||
|
||||
APPLE BCM5974 MULTITOUCH DRIVER
|
||||
P: Henrik Rydberg
|
||||
M: rydberg@euromail.se
|
||||
L: linux-input@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
APPLE SMC DRIVER
|
||||
P: Nicolas Boichat
|
||||
M: nicolas@boichat.ch
|
||||
@ -467,11 +478,11 @@ L: linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only)
|
||||
S: Maintained
|
||||
|
||||
ARM/ATMEL AT91RM9200 ARM ARCHITECTURE
|
||||
P: Andrew Victor
|
||||
M: linux@maxim.org.za
|
||||
L: linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only)
|
||||
W: http://maxim.org.za/at91_26.html
|
||||
S: Maintained
|
||||
P: Andrew Victor
|
||||
M: linux@maxim.org.za
|
||||
L: linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only)
|
||||
W: http://maxim.org.za/at91_26.html
|
||||
S: Maintained
|
||||
|
||||
ARM/CIRRUS LOGIC EP93XX ARM ARCHITECTURE
|
||||
P: Lennert Buytenhek
|
||||
@ -507,6 +518,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
|
||||
@ -520,10 +537,10 @@ L: linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only)
|
||||
S: Maintained
|
||||
|
||||
ARM/HP JORNADA 7XX MACHINE SUPPORT
|
||||
P: Kristoffer Ericson
|
||||
M: kristoffer.ericson@gmail.com
|
||||
W: www.jlime.com
|
||||
S: Maintained
|
||||
P: Kristoffer Ericson
|
||||
M: kristoffer.ericson@gmail.com
|
||||
W: www.jlime.com
|
||||
S: Maintained
|
||||
|
||||
ARM/INTEL IOP32X ARM ARCHITECTURE
|
||||
P: Lennert Buytenhek
|
||||
@ -593,6 +610,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
|
||||
@ -719,16 +741,27 @@ 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
|
||||
S: Maintained
|
||||
|
||||
ATL1 ETHERNET DRIVER
|
||||
ATLX ETHERNET DRIVERS
|
||||
P: Jay Cliburn
|
||||
M: jcliburn@gmail.com
|
||||
P: Chris Snook
|
||||
M: csnook@redhat.com
|
||||
P: Jie Yang
|
||||
M: jie.yang@atheros.com
|
||||
L: atl1-devel@lists.sourceforge.net
|
||||
W: http://sourceforge.net/projects/atl1
|
||||
W: http://atl1.sourceforge.net
|
||||
@ -921,96 +954,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
|
||||
@ -1064,7 +1022,7 @@ T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git
|
||||
S: Maintained
|
||||
|
||||
CAFE CMOS INTEGRATED CAMERA CONTROLLER DRIVER
|
||||
P: Jonathan Corbet
|
||||
P: Jonathan Corbet
|
||||
M: corbet@lwn.net
|
||||
L: video4linux-list@redhat.com
|
||||
S: Maintained
|
||||
@ -1234,7 +1192,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
|
||||
@ -1406,7 +1364,7 @@ P: Digi International, Inc
|
||||
M: Eng.Linux@digi.com
|
||||
L: Eng.Linux@digi.com
|
||||
W: http://www.digi.com
|
||||
S: Orphaned
|
||||
S: Orphan
|
||||
|
||||
DIRECTORY NOTIFICATION
|
||||
P: Stephen Rothwell
|
||||
@ -1470,12 +1428,12 @@ L: linux-acpi@vger.kernel.org
|
||||
S: Supported
|
||||
|
||||
DOCUMENTATION (/Documentation directory)
|
||||
P: Michael Kerrisk
|
||||
M: mtk.manpages@gmail.com
|
||||
P: Randy Dunlap
|
||||
M: rdunlap@xenotime.net
|
||||
L: linux-doc@vger.kernel.org
|
||||
S: Maintained
|
||||
P: Michael Kerrisk
|
||||
M: mtk.manpages@gmail.com
|
||||
P: Randy Dunlap
|
||||
M: rdunlap@xenotime.net
|
||||
L: linux-doc@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
DOUBLETALK DRIVER
|
||||
P: James R. Van Zandt
|
||||
@ -1506,7 +1464,7 @@ S: Maintained
|
||||
DVB SUBSYSTEM AND DRIVERS
|
||||
P: LinuxTV.org Project
|
||||
M: v4l-dvb-maintainer@linuxtv.org
|
||||
L: linux-dvb@linuxtv.org (subscription required)
|
||||
L: linux-dvb@linuxtv.org (subscription required)
|
||||
W: http://linuxtv.org/
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git
|
||||
S: Maintained
|
||||
@ -1642,7 +1600,7 @@ S: Supported
|
||||
EMBEDDED LINUX
|
||||
P: Paul Gortmaker
|
||||
M: paul.gortmaker@windriver.com
|
||||
P David Woodhouse
|
||||
P: David Woodhouse
|
||||
M: dwmw2@infradead.org
|
||||
L: linux-embedded@vger.kernel.org
|
||||
S: Maintained
|
||||
@ -1844,7 +1802,7 @@ FUTURE DOMAIN TMC-16x0 SCSI DRIVER (16-bit)
|
||||
P: Rik Faith
|
||||
M: faith@cs.unc.edu
|
||||
L: linux-scsi@vger.kernel.org
|
||||
S: Odd fixes (e.g., new signatures)
|
||||
S: Odd Fixes (e.g., new signatures)
|
||||
|
||||
GDT SCSI DISK ARRAY CONTROLLER DRIVER
|
||||
P: Achim Leubner
|
||||
@ -1883,16 +1841,12 @@ W: http://gigaset307x.sourceforge.net/
|
||||
S: Maintained
|
||||
|
||||
HARDWARE MONITORING
|
||||
P: Mark M. Hoffman
|
||||
M: mhoffman@lightlink.com
|
||||
L: lm-sensors@lm-sensors.org
|
||||
W: http://www.lm-sensors.org/
|
||||
T: git lm-sensors.org:/kernel/mhoffman/hwmon-2.6.git testing
|
||||
T: git lm-sensors.org:/kernel/mhoffman/hwmon-2.6.git release
|
||||
S: Maintained
|
||||
S: Orphan
|
||||
|
||||
HARDWARE RANDOM NUMBER GENERATOR CORE
|
||||
S: Orphaned
|
||||
S: Orphan
|
||||
|
||||
HARD DRIVE ACTIVE PROTECTION SYSTEM (HDAPS) DRIVER
|
||||
P: Robert Love
|
||||
@ -2159,7 +2113,7 @@ M: rolandd@cisco.com
|
||||
P: Sean Hefty
|
||||
M: sean.hefty@intel.com
|
||||
P: Hal Rosenstock
|
||||
M: hal.rosenstock@gmail.com
|
||||
M: hal.rosenstock@gmail.com
|
||||
L: general@lists.openfabrics.org
|
||||
W: http://www.openib.org/
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
|
||||
@ -2451,7 +2405,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
|
||||
@ -2747,17 +2701,17 @@ S: Maintained
|
||||
|
||||
MARVELL YUKON / SYSKONNECT DRIVER
|
||||
P: Mirko Lindner
|
||||
M: mlindner@syskonnect.de
|
||||
M: mlindner@syskonnect.de
|
||||
P: Ralph Roesler
|
||||
M: rroesler@syskonnect.de
|
||||
W: http://www.syskonnect.com
|
||||
S: Supported
|
||||
M: rroesler@syskonnect.de
|
||||
W: http://www.syskonnect.com
|
||||
S: Supported
|
||||
|
||||
MAN-PAGES: MANUAL PAGES FOR LINUX -- Sections 2, 3, 4, 5, and 7
|
||||
P: Michael Kerrisk
|
||||
M: mtk.manpages@gmail.com
|
||||
W: http://www.kernel.org/doc/man-pages
|
||||
S: Supported
|
||||
W: http://www.kernel.org/doc/man-pages
|
||||
S: Supported
|
||||
|
||||
MARVELL LIBERTAS WIRELESS DRIVER
|
||||
P: Dan Williams
|
||||
@ -2786,7 +2740,7 @@ S: Maintained
|
||||
MEGARAID SCSI DRIVERS
|
||||
P: Neela Syam Kolli
|
||||
M: megaraidlinux@lsi.com
|
||||
S: linux-scsi@vger.kernel.org
|
||||
L: linux-scsi@vger.kernel.org
|
||||
W: http://megaraid.lsilogic.com
|
||||
S: Maintained
|
||||
|
||||
@ -2904,7 +2858,7 @@ MULTIMEDIA CARD (MMC) ETC. OVER SPI
|
||||
P: David Brownell
|
||||
M: dbrownell@users.sourceforge.net
|
||||
L: linux-kernel@vger.kernel.org
|
||||
S: Odd fixes
|
||||
S: Odd Fixes
|
||||
|
||||
MULTISOUND SOUND DRIVER
|
||||
P: Andrew Veliath
|
||||
@ -2917,6 +2871,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
|
||||
@ -2927,7 +2887,7 @@ W: http://www.myri.com/scs/download-Myri10GE.html
|
||||
S: Supported
|
||||
|
||||
NATSEMI ETHERNET DRIVER (DP8381x)
|
||||
P: Tim Hockin
|
||||
P: Tim Hockin
|
||||
M: thockin@hockin.org
|
||||
S: Maintained
|
||||
|
||||
@ -3065,9 +3025,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
|
||||
@ -3102,7 +3063,7 @@ P: Anton Altaparmakov
|
||||
M: aia21@cantab.net
|
||||
L: linux-ntfs-dev@lists.sourceforge.net
|
||||
L: linux-kernel@vger.kernel.org
|
||||
W: http://linux-ntfs.sf.net/
|
||||
W: http://www.linux-ntfs.org/
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/aia21/ntfs-2.6.git
|
||||
S: Maintained
|
||||
|
||||
@ -3145,7 +3106,7 @@ M: laforge@gnumonks.org
|
||||
S: Maintained
|
||||
|
||||
OMNIVISION OV7670 SENSOR DRIVER
|
||||
P: Jonathan Corbet
|
||||
P: Jonathan Corbet
|
||||
M: corbet@lwn.net
|
||||
L: video4linux-list@redhat.com
|
||||
S: Maintained
|
||||
@ -3255,7 +3216,7 @@ T: git kernel.org:/pub/scm/linux/kernel/git/jbarnes/pci-2.6.git
|
||||
S: Supported
|
||||
|
||||
PCI HOTPLUG CORE
|
||||
P: Kristen Carlson Accardi
|
||||
P: Kristen Carlson Accardi
|
||||
M: kristen.c.accardi@intel.com
|
||||
S: Supported
|
||||
|
||||
@ -3694,7 +3655,7 @@ M: jmorris@namei.org
|
||||
P: Eric Paris
|
||||
M: eparis@parisplace.org
|
||||
L: linux-kernel@vger.kernel.org (kernel issues)
|
||||
L: selinux@tycho.nsa.gov (subscribers-only, general discussion)
|
||||
L: selinux@tycho.nsa.gov (subscribers-only, general discussion)
|
||||
W: http://www.nsa.gov/selinux
|
||||
S: Supported
|
||||
|
||||
@ -3730,6 +3691,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
|
||||
@ -3802,10 +3773,10 @@ M: bn@niasdigital.com
|
||||
S: Maintained
|
||||
|
||||
SOC-CAMERA V4L2 SUBSYSTEM
|
||||
P: Guennadi Liakhovetski
|
||||
M: g.liakhovetski@gmx.de
|
||||
L: video4linux-list@redhat.com
|
||||
S: Maintained
|
||||
P: Guennadi Liakhovetski
|
||||
M: g.liakhovetski@gmx.de
|
||||
L: video4linux-list@redhat.com
|
||||
S: Maintained
|
||||
|
||||
SOFTWARE RAID (Multiple Disks) SUPPORT
|
||||
P: Ingo Molnar
|
||||
@ -3959,7 +3930,7 @@ S: Maintained
|
||||
|
||||
STARMODE RADIO IP (STRIP) PROTOCOL DRIVER
|
||||
W: http://mosquitonet.Stanford.EDU/strip.html
|
||||
S: Unsupported ?
|
||||
S: Orphan
|
||||
|
||||
STRADIS MPEG-2 DECODER DRIVER
|
||||
P: Nathan Laredo
|
||||
@ -3973,7 +3944,7 @@ M: lethal@linux-sh.org
|
||||
L: linux-sh@vger.kernel.org
|
||||
W: http://www.linux-sh.org
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.git
|
||||
S: Maintained
|
||||
S: Supported
|
||||
|
||||
SUN3/3X
|
||||
P: Sam Creasey
|
||||
@ -4040,13 +4011,13 @@ T: git repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
|
||||
S: Maintained
|
||||
|
||||
TI FLASH MEDIA INTERFACE DRIVER
|
||||
P: Alex Dubov
|
||||
M: oakad@yahoo.com
|
||||
S: Maintained
|
||||
P: Alex Dubov
|
||||
M: oakad@yahoo.com
|
||||
S: Maintained
|
||||
|
||||
TI OMAP MMC INTERFACE DRIVER
|
||||
P: Carlos Aguiar, Anderson Briglia and Syed Khasim
|
||||
M: linux-omap-open-source@linux.omap.com (subscribers only)
|
||||
M: linux-omap@vger.kernel.org
|
||||
W: http://linux.omap.com
|
||||
W: http://www.muru.com/linux/omap/
|
||||
S: Maintained
|
||||
@ -4184,23 +4155,17 @@ 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
|
||||
L: linux-kernel@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Supported
|
||||
|
||||
USB CDC ETHERNET DRIVER
|
||||
P: Greg Kroah-Hartman
|
||||
M: greg@kroah.com
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Maintained
|
||||
W: http://www.kroah.com/linux-usb/
|
||||
|
||||
@ -4227,13 +4192,13 @@ S: Maintained
|
||||
USB EHCI DRIVER
|
||||
P: David Brownell
|
||||
M: dbrownell@users.sourceforge.net
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Odd Fixes
|
||||
|
||||
USB ET61X[12]51 DRIVER
|
||||
P: Luca Risolia
|
||||
M: luca.risolia@studio.unibo.it
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: video4linux-list@redhat.com
|
||||
W: http://www.linux-projects.org
|
||||
S: Maintained
|
||||
@ -4241,33 +4206,33 @@ S: Maintained
|
||||
USB GADGET/PERIPHERAL SUBSYSTEM
|
||||
P: David Brownell
|
||||
M: dbrownell@users.sourceforge.net
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
W: http://www.linux-usb.org/gadget
|
||||
S: Maintained
|
||||
|
||||
USB HID/HIDBP DRIVERS (USB KEYBOARDS, MICE, REMOTE CONTROLS, ...)
|
||||
P: Jiri Kosina
|
||||
M: jkosina@suse.cz
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/jikos/hid.git
|
||||
S: Maintained
|
||||
|
||||
USB ISP116X DRIVER
|
||||
P: Olav Kongas
|
||||
M: ok@artecdesign.ee
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
USB KAWASAKI LSI DRIVER
|
||||
P: Oliver Neukum
|
||||
M: oliver@neukum.name
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
USB MASS STORAGE DRIVER
|
||||
P: Matthew Dharm
|
||||
M: mdharm-usb@one-eyed-alien.net
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: usb-storage@lists.one-eyed-alien.net
|
||||
S: Maintained
|
||||
W: http://www.one-eyed-alien.net/~mdharm/linux-usb/
|
||||
@ -4275,26 +4240,26 @@ W: http://www.one-eyed-alien.net/~mdharm/linux-usb/
|
||||
USB OHCI DRIVER
|
||||
P: David Brownell
|
||||
M: dbrownell@users.sourceforge.net
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Odd Fixes
|
||||
|
||||
USB OPTION-CARD DRIVER
|
||||
P: Matthias Urlichs
|
||||
M: smurf@smurf.noris.de
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
USB OV511 DRIVER
|
||||
P: Mark McClelland
|
||||
M: mmcclell@bigfoot.com
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
W: http://alpha.dyndns.org/ov511/
|
||||
S: Maintained
|
||||
|
||||
USB PEGASUS DRIVER
|
||||
P: Petko Manolov
|
||||
M: petkan@users.sourceforge.net
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: netdev@vger.kernel.org
|
||||
W: http://pegasus2.sourceforge.net/
|
||||
S: Maintained
|
||||
@ -4302,13 +4267,13 @@ S: Maintained
|
||||
USB PRINTER DRIVER (usblp)
|
||||
P: Pete Zaitcev
|
||||
M: zaitcev@redhat.com
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Supported
|
||||
|
||||
USB RTL8150 DRIVER
|
||||
P: Petko Manolov
|
||||
M: petkan@users.sourceforge.net
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: netdev@vger.kernel.org
|
||||
W: http://pegasus2.sourceforge.net/
|
||||
S: Maintained
|
||||
@ -4316,20 +4281,20 @@ S: Maintained
|
||||
USB SE401 DRIVER
|
||||
P: Jeroen Vreeken
|
||||
M: pe1rxq@amsat.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
W: http://www.chello.nl/~j.vreeken/se401/
|
||||
S: Maintained
|
||||
|
||||
USB SERIAL BELKIN F5U103 DRIVER
|
||||
P: William Greathouse
|
||||
M: wgreathouse@smva.com
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
USB SERIAL CYPRESS M8 DRIVER
|
||||
P: Lonnie Mendez
|
||||
M: dignome@gmail.com
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Maintained
|
||||
W: http://geocities.com/i0xox0i
|
||||
W: http://firstlight.net/cvs
|
||||
@ -4344,39 +4309,39 @@ USB SERIAL DIGI ACCELEPORT DRIVER
|
||||
P: Peter Berger and Al Borchers
|
||||
M: pberger@brimson.com
|
||||
M: alborchers@steinerpoint.com
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
USB SERIAL DRIVER
|
||||
P: Greg Kroah-Hartman
|
||||
M: gregkh@suse.de
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Supported
|
||||
|
||||
USB SERIAL EMPEG EMPEG-CAR MARK I/II DRIVER
|
||||
P: Gary Brubaker
|
||||
M: xavyer@ix.netcom.com
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
USB SERIAL KEYSPAN DRIVER
|
||||
P: Greg Kroah-Hartman
|
||||
M: greg@kroah.com
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
W: http://www.kroah.com/linux/
|
||||
S: Maintained
|
||||
|
||||
USB SERIAL WHITEHEAT DRIVER
|
||||
P: Support Department
|
||||
M: support@connecttech.com
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
W: http://www.connecttech.com
|
||||
S: Supported
|
||||
|
||||
USB SN9C1xx DRIVER
|
||||
P: Luca Risolia
|
||||
M: luca.risolia@studio.unibo.it
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: video4linux-list@redhat.com
|
||||
W: http://www.linux-projects.org
|
||||
S: Maintained
|
||||
@ -4384,7 +4349,7 @@ S: Maintained
|
||||
USB SUBSYSTEM
|
||||
P: Greg Kroah-Hartman
|
||||
M: gregkh@suse.de
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
W: http://www.linux-usb.org
|
||||
T: quilt kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
|
||||
S: Supported
|
||||
@ -4392,7 +4357,7 @@ S: Supported
|
||||
USB UHCI DRIVER
|
||||
P: Alan Stern
|
||||
M: stern@rowland.harvard.edu
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
USB "USBNET" DRIVER FRAMEWORK
|
||||
@ -4405,7 +4370,7 @@ S: Maintained
|
||||
USB VIDEO CLASS
|
||||
P: Laurent Pinchart
|
||||
M: laurent.pinchart@skynet.be
|
||||
L: linx-uvc-devel@berlios.de
|
||||
L: linux-uvc-devel@lists.berlios.de
|
||||
L: video4linux-list@redhat.com
|
||||
W: http://linux-uvc.berlios.de
|
||||
S: Maintained
|
||||
@ -4413,7 +4378,7 @@ S: Maintained
|
||||
USB W996[87]CF DRIVER
|
||||
P: Luca Risolia
|
||||
M: luca.risolia@studio.unibo.it
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: video4linux-list@redhat.com
|
||||
W: http://www.linux-projects.org
|
||||
S: Maintained
|
||||
@ -4427,7 +4392,7 @@ S: Maintained
|
||||
USB ZC0301 DRIVER
|
||||
P: Luca Risolia
|
||||
M: luca.risolia@studio.unibo.it
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: video4linux-list@redhat.com
|
||||
W: http://www.linux-projects.org
|
||||
S: Maintained
|
||||
@ -4435,14 +4400,14 @@ S: Maintained
|
||||
USB ZD1201 DRIVER
|
||||
P: Jeroen Vreeken
|
||||
M: pe1rxq@amsat.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
W: http://linux-lc100020.sourceforge.net
|
||||
S: Maintained
|
||||
|
||||
USB ZR364XX DRIVER
|
||||
P: Antoine Jacquet
|
||||
M: royale@zerezo.com
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: video4linux-list@redhat.com
|
||||
W: http://royale.zerezo.com/zr364xx/
|
||||
S: Maintained
|
||||
@ -4509,6 +4474,15 @@ M: kaber@trash.net
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
VOLTAGE AND CURRENT REGULATOR FRAMEWORK
|
||||
P: Liam Girdwood
|
||||
M: lg@opensource.wolfsonmicro.com
|
||||
P: Mark Brown
|
||||
M: broonie@opensource.wolfsonmicro.com
|
||||
W: http://opensource.wolfsonmicro.com/node/15
|
||||
T: git kernel.org/pub/scm/linux/kernel/git/lrg/voltage-2.6.git
|
||||
S: Supported
|
||||
|
||||
VT1211 HARDWARE MONITOR DRIVER
|
||||
P: Juerg Haefliger
|
||||
M: juergh@gmail.com
|
||||
@ -4663,12 +4637,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 = -rc7
|
||||
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)/system.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 New Issue
Block a user