You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge branch 'linus' into x86/core
Conflicts: arch/x86/kernel/genapic_64.c include/asm-x86/kvm_host.h Signed-off-by: Ingo Molnar <mingo@elte.hu>
This commit is contained in:
Ingo Molnar
@@ -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/
|
||||
|
||||
@@ -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'
|
||||
@@ -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>
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -0,0 +1,3 @@
|
||||
obj-m := DocBook/ accounting/ auxdisplay/ connector/ \
|
||||
filesystems/configfs/ ia64/ networking/ \
|
||||
pcmcia/ spi/ video4linux/ vm/ watchdog/src/
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -16,13 +16,13 @@ Introduction
|
||||
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.
|
||||
|
||||
@@ -36,7 +36,7 @@ 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
|
||||
|
||||
|
||||
Machines
|
||||
|
||||
@@ -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 .
|
||||
|
||||
|
||||
@@ -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
|
||||
+6
-15
@@ -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"
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user