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 'master' into for-2.6.34
This commit is contained in:
Jens Axboe
@@ -37,6 +37,7 @@ modules.builtin
|
||||
tags
|
||||
TAGS
|
||||
vmlinux
|
||||
vmlinuz
|
||||
System.map
|
||||
Module.markers
|
||||
Module.symvers
|
||||
|
||||
@@ -20,7 +20,7 @@ Description:
|
||||
lsm: [[subj_user=] [subj_role=] [subj_type=]
|
||||
[obj_user=] [obj_role=] [obj_type=]]
|
||||
|
||||
base: func:= [BPRM_CHECK][FILE_MMAP][INODE_PERMISSION]
|
||||
base: func:= [BPRM_CHECK][FILE_MMAP][FILE_CHECK]
|
||||
mask:= [MAY_READ] [MAY_WRITE] [MAY_APPEND] [MAY_EXEC]
|
||||
fsmagic:= hex value
|
||||
uid:= decimal value
|
||||
@@ -40,11 +40,11 @@ Description:
|
||||
|
||||
measure func=BPRM_CHECK
|
||||
measure func=FILE_MMAP mask=MAY_EXEC
|
||||
measure func=INODE_PERM mask=MAY_READ uid=0
|
||||
measure func=FILE_CHECK mask=MAY_READ uid=0
|
||||
|
||||
The default policy measures all executables in bprm_check,
|
||||
all files mmapped executable in file_mmap, and all files
|
||||
open for read by root in inode_permission.
|
||||
open for read by root in do_filp_open.
|
||||
|
||||
Examples of LSM specific definitions:
|
||||
|
||||
@@ -54,8 +54,8 @@ Description:
|
||||
|
||||
dont_measure obj_type=var_log_t
|
||||
dont_measure obj_type=auditd_log_t
|
||||
measure subj_user=system_u func=INODE_PERM mask=MAY_READ
|
||||
measure subj_role=system_r func=INODE_PERM mask=MAY_READ
|
||||
measure subj_user=system_u func=FILE_CHECK mask=MAY_READ
|
||||
measure subj_role=system_r func=FILE_CHECK mask=MAY_READ
|
||||
|
||||
Smack:
|
||||
measure subj_user=_ func=INODE_PERM mask=MAY_READ
|
||||
measure subj_user=_ func=FILE_CHECK mask=MAY_READ
|
||||
|
||||
@@ -174,7 +174,7 @@
|
||||
</para>
|
||||
<programlisting>
|
||||
static struct mtd_info *board_mtd;
|
||||
static unsigned long baseaddr;
|
||||
static void __iomem *baseaddr;
|
||||
</programlisting>
|
||||
<para>
|
||||
Static example
|
||||
@@ -182,7 +182,7 @@ static unsigned long baseaddr;
|
||||
<programlisting>
|
||||
static struct mtd_info board_mtd;
|
||||
static struct nand_chip board_chip;
|
||||
static unsigned long baseaddr;
|
||||
static void __iomem *baseaddr;
|
||||
</programlisting>
|
||||
</sect1>
|
||||
<sect1 id="Partition_defines">
|
||||
@@ -283,8 +283,8 @@ int __init board_init (void)
|
||||
}
|
||||
|
||||
/* map physical address */
|
||||
baseaddr = (unsigned long)ioremap(CHIP_PHYSICAL_ADDRESS, 1024);
|
||||
if(!baseaddr){
|
||||
baseaddr = ioremap(CHIP_PHYSICAL_ADDRESS, 1024);
|
||||
if (!baseaddr) {
|
||||
printk("Ioremap to access NAND chip failed\n");
|
||||
err = -EIO;
|
||||
goto out_mtd;
|
||||
@@ -316,7 +316,7 @@ int __init board_init (void)
|
||||
goto out;
|
||||
|
||||
out_ior:
|
||||
iounmap((void *)baseaddr);
|
||||
iounmap(baseaddr);
|
||||
out_mtd:
|
||||
kfree (board_mtd);
|
||||
out:
|
||||
@@ -341,7 +341,7 @@ static void __exit board_cleanup (void)
|
||||
nand_release (board_mtd);
|
||||
|
||||
/* unmap physical address */
|
||||
iounmap((void *)baseaddr);
|
||||
iounmap(baseaddr);
|
||||
|
||||
/* Free the MTD device structure */
|
||||
kfree (board_mtd);
|
||||
|
||||
@@ -157,7 +157,7 @@ For such memory, you can do things like
|
||||
* access only the 640k-1MB area, so anything else
|
||||
* has to be remapped.
|
||||
*/
|
||||
char * baseptr = ioremap(0xFC000000, 1024*1024);
|
||||
void __iomem *baseptr = ioremap(0xFC000000, 1024*1024);
|
||||
|
||||
/* write a 'A' to the offset 10 of the area */
|
||||
writeb('A',baseptr+10);
|
||||
|
||||
@@ -186,7 +186,7 @@ a virtual address mapping (unlike the earlier scheme of virtual address
|
||||
do not have a corresponding kernel virtual address space mapping) and
|
||||
low-memory pages.
|
||||
|
||||
Note: Please refer to Documentation/DMA-mapping.txt for a discussion
|
||||
Note: Please refer to Documentation/PCI/PCI-DMA-mapping.txt for a discussion
|
||||
on PCI high mem DMA aspects and mapping of scatter gather lists, and support
|
||||
for 64 bit PCI.
|
||||
|
||||
|
||||
@@ -145,8 +145,8 @@ show_sampling_rate_max: THIS INTERFACE IS DEPRECATED, DON'T USE IT.
|
||||
up_threshold: defines what the average CPU usage between the samplings
|
||||
of 'sampling_rate' needs to be for the kernel to make a decision on
|
||||
whether it should increase the frequency. For example when it is set
|
||||
to its default value of '80' it means that between the checking
|
||||
intervals the CPU needs to be on average more than 80% in use to then
|
||||
to its default value of '95' it means that between the checking
|
||||
intervals the CPU needs to be on average more than 95% in use to then
|
||||
decide that the CPU frequency needs to be increased.
|
||||
|
||||
ignore_nice_load: this parameter takes a value of '0' or '1'. When
|
||||
|
||||
@@ -143,8 +143,8 @@ o provide a way to configure fault attributes
|
||||
failslab, fail_page_alloc, and fail_make_request use this way.
|
||||
Helper functions:
|
||||
|
||||
init_fault_attr_entries(entries, attr, name);
|
||||
void cleanup_fault_attr_entries(entries);
|
||||
init_fault_attr_dentries(entries, attr, name);
|
||||
void cleanup_fault_attr_dentries(entries);
|
||||
|
||||
- module parameters
|
||||
|
||||
|
||||
@@ -493,3 +493,52 @@ Why: These two features use non-standard interfaces. There are the
|
||||
Who: Corentin Chary <corentin.chary@gmail.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: usbvideo quickcam_messenger driver
|
||||
When: 2.6.35
|
||||
Files: drivers/media/video/usbvideo/quickcam_messenger.[ch]
|
||||
Why: obsolete v4l1 driver replaced by gspca_stv06xx
|
||||
Who: Hans de Goede <hdegoede@redhat.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: ov511 v4l1 driver
|
||||
When: 2.6.35
|
||||
Files: drivers/media/video/ov511.[ch]
|
||||
Why: obsolete v4l1 driver replaced by gspca_ov519
|
||||
Who: Hans de Goede <hdegoede@redhat.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: w9968cf v4l1 driver
|
||||
When: 2.6.35
|
||||
Files: drivers/media/video/w9968cf*.[ch]
|
||||
Why: obsolete v4l1 driver replaced by gspca_ov519
|
||||
Who: Hans de Goede <hdegoede@redhat.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: ovcamchip sensor framework
|
||||
When: 2.6.35
|
||||
Files: drivers/media/video/ovcamchip/*
|
||||
Why: Only used by obsoleted v4l1 drivers
|
||||
Who: Hans de Goede <hdegoede@redhat.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: stv680 v4l1 driver
|
||||
When: 2.6.35
|
||||
Files: drivers/media/video/stv680.[ch]
|
||||
Why: obsolete v4l1 driver replaced by gspca_stv0680
|
||||
Who: Hans de Goede <hdegoede@redhat.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: zc0301 v4l driver
|
||||
When: 2.6.35
|
||||
Files: drivers/media/video/zc0301/*
|
||||
Why: Duplicate functionality with the gspca_zc3xx driver, zc0301 only
|
||||
supports 2 USB-ID's (because it only supports a limited set of
|
||||
sensors) wich are also supported by the gspca_zc3xx driver
|
||||
(which supports 53 USB-ID's in total)
|
||||
Who: Hans de Goede <hdegoede@redhat.com>
|
||||
|
||||
@@ -28,7 +28,7 @@ described in the man pages included in the package.
|
||||
Project web page: http://www.nilfs.org/en/
|
||||
Download page: http://www.nilfs.org/en/download.html
|
||||
Git tree web page: http://www.nilfs.org/git/
|
||||
NILFS mailing lists: http://www.nilfs.org/mailman/listinfo/users
|
||||
List info: http://vger.kernel.org/vger-lists.html#linux-nilfs
|
||||
|
||||
Caveats
|
||||
=======
|
||||
|
||||
@@ -177,7 +177,6 @@ read the file /proc/PID/status:
|
||||
CapBnd: ffffffffffffffff
|
||||
voluntary_ctxt_switches: 0
|
||||
nonvoluntary_ctxt_switches: 1
|
||||
Stack usage: 12 kB
|
||||
|
||||
This shows you nearly the same information you would get if you viewed it with
|
||||
the ps command. In fact, ps uses the proc file system to obtain its
|
||||
@@ -231,7 +230,6 @@ Table 1-2: Contents of the statm files (as of 2.6.30-rc7)
|
||||
Mems_allowed_list Same as previous, but in "list format"
|
||||
voluntary_ctxt_switches number of voluntary context switches
|
||||
nonvoluntary_ctxt_switches number of non voluntary context switches
|
||||
Stack usage: stack usage high water mark (round up to page size)
|
||||
..............................................................................
|
||||
|
||||
Table 1-3: Contents of the statm files (as of 2.6.8-rc3)
|
||||
|
||||
@@ -0,0 +1,102 @@
|
||||
Kernel driver amc6821
|
||||
=====================
|
||||
|
||||
Supported chips:
|
||||
Texas Instruments AMC6821
|
||||
Prefix: 'amc6821'
|
||||
Addresses scanned: 0x18, 0x19, 0x1a, 0x2c, 0x2d, 0x2e, 0x4c, 0x4d, 0x4e
|
||||
Datasheet: http://focus.ti.com/docs/prod/folders/print/amc6821.html
|
||||
|
||||
Authors:
|
||||
Tomaz Mertelj <tomaz.mertelj@guest.arnes.si>
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
This driver implements support for the Texas Instruments amc6821 chip.
|
||||
The chip has one on-chip and one remote temperature sensor and one pwm fan
|
||||
regulator.
|
||||
The pwm can be controlled either from software or automatically.
|
||||
|
||||
The driver provides the following sensor accesses in sysfs:
|
||||
|
||||
temp1_input ro on-chip temperature
|
||||
temp1_min rw "
|
||||
temp1_max rw "
|
||||
temp1_crit rw "
|
||||
temp1_min_alarm ro "
|
||||
temp1_max_alarm ro "
|
||||
temp1_crit_alarm ro "
|
||||
|
||||
temp2_input ro remote temperature
|
||||
temp2_min rw "
|
||||
temp2_max rw "
|
||||
temp2_crit rw "
|
||||
temp2_min_alarm ro "
|
||||
temp2_max_alarm ro "
|
||||
temp2_crit_alarm ro "
|
||||
temp2_fault ro "
|
||||
|
||||
fan1_input ro tachometer speed
|
||||
fan1_min rw "
|
||||
fan1_max rw "
|
||||
fan1_fault ro "
|
||||
fan1_div rw Fan divisor can be either 2 or 4.
|
||||
|
||||
pwm1 rw pwm1
|
||||
pwm1_enable rw regulator mode, 1=open loop, 2=fan controlled
|
||||
by remote temperature, 3=fan controlled by
|
||||
combination of the on-chip temperature and
|
||||
remote-sensor temperature,
|
||||
pwm1_auto_channels_temp ro 1 if pwm_enable==2, 3 if pwm_enable==3
|
||||
pwm1_auto_point1_pwm ro Hardwired to 0, shared for both
|
||||
temperature channels.
|
||||
pwm1_auto_point2_pwm rw This value is shared for both temperature
|
||||
channels.
|
||||
pwm1_auto_point3_pwm rw Hardwired to 255, shared for both
|
||||
temperature channels.
|
||||
|
||||
temp1_auto_point1_temp ro Hardwired to temp2_auto_point1_temp
|
||||
which is rw. Below this temperature fan stops.
|
||||
temp1_auto_point2_temp rw The low-temperature limit of the proportional
|
||||
range. Below this temperature
|
||||
pwm1 = pwm1_auto_point2_pwm. It can go from
|
||||
0 degree C to 124 degree C in steps of
|
||||
4 degree C. Read it out after writing to get
|
||||
the actual value.
|
||||
temp1_auto_point3_temp rw Above this temperature fan runs at maximum
|
||||
speed. It can go from temp1_auto_point2_temp.
|
||||
It can only have certain discrete values
|
||||
which depend on temp1_auto_point2_temp and
|
||||
pwm1_auto_point2_pwm. Read it out after
|
||||
writing to get the actual value.
|
||||
|
||||
temp2_auto_point1_temp rw Must be between 0 degree C and 63 degree C and
|
||||
it defines the passive cooling temperature.
|
||||
Below this temperature the fan stops in
|
||||
the closed loop mode.
|
||||
temp2_auto_point2_temp rw The low-temperature limit of the proportional
|
||||
range. Below this temperature
|
||||
pwm1 = pwm1_auto_point2_pwm. It can go from
|
||||
0 degree C to 124 degree C in steps
|
||||
of 4 degree C.
|
||||
|
||||
temp2_auto_point3_temp rw Above this temperature fan runs at maximum
|
||||
speed. It can only have certain discrete
|
||||
values which depend on temp2_auto_point2_temp
|
||||
and pwm1_auto_point2_pwm. Read it out after
|
||||
writing to get actual value.
|
||||
|
||||
|
||||
Module parameters
|
||||
-----------------
|
||||
|
||||
If your board has a BIOS that initializes the amc6821 correctly, you should
|
||||
load the module with: init=0.
|
||||
|
||||
If your board BIOS doesn't initialize the chip, or you want
|
||||
different settings, you can set the following parameters:
|
||||
init=1,
|
||||
pwminv: 0 default pwm output, 1 inverts pwm output.
|
||||
|
||||
@@ -3,8 +3,8 @@ Kernel driver k10temp
|
||||
|
||||
Supported chips:
|
||||
* AMD Family 10h processors:
|
||||
Socket F: Quad-Core/Six-Core/Embedded Opteron
|
||||
Socket AM2+: Opteron, Phenom (II) X3/X4
|
||||
Socket F: Quad-Core/Six-Core/Embedded Opteron (but see below)
|
||||
Socket AM2+: Quad-Core Opteron, Phenom (II) X3/X4, Athlon X2 (but see below)
|
||||
Socket AM3: Quad-Core Opteron, Athlon/Phenom II X2/X3/X4, Sempron II
|
||||
Socket S1G3: Athlon II, Sempron, Turion II
|
||||
* AMD Family 11h processors:
|
||||
@@ -36,10 +36,15 @@ Description
|
||||
This driver permits reading of the internal temperature sensor of AMD
|
||||
Family 10h and 11h processors.
|
||||
|
||||
All these processors have a sensor, but on older revisions of Family 10h
|
||||
processors, the sensor may return inconsistent values (erratum 319). The
|
||||
driver will refuse to load on these revisions unless you specify the
|
||||
"force=1" module parameter.
|
||||
All these processors have a sensor, but on those for Socket F or AM2+,
|
||||
the sensor may return inconsistent values (erratum 319). The driver
|
||||
will refuse to load on these revisions unless you specify the "force=1"
|
||||
module parameter.
|
||||
|
||||
Due to technical reasons, the driver can detect only the mainboard's
|
||||
socket type, not the processor's actual capabilities. Therefore, if you
|
||||
are using an AM3 processor on an AM2+ mainboard, you can safely use the
|
||||
"force=1" parameter.
|
||||
|
||||
There is one temperature measurement value, available as temp1_input in
|
||||
sysfs. It is measured in degrees Celsius with a resolution of 1/8th degree.
|
||||
|
||||
@@ -27,12 +27,30 @@ set of events/packets.
|
||||
|
||||
A set of ABS_MT events with the desired properties is defined. The events
|
||||
are divided into categories, to allow for partial implementation. The
|
||||
minimum set consists of ABS_MT_TOUCH_MAJOR, ABS_MT_POSITION_X and
|
||||
ABS_MT_POSITION_Y, which allows for multiple fingers to be tracked. If the
|
||||
device supports it, the ABS_MT_WIDTH_MAJOR may be used to provide the size
|
||||
of the approaching finger. Anisotropy and direction may be specified with
|
||||
ABS_MT_TOUCH_MINOR, ABS_MT_WIDTH_MINOR and ABS_MT_ORIENTATION. The
|
||||
ABS_MT_TOOL_TYPE may be used to specify whether the touching tool is a
|
||||
minimum set consists of ABS_MT_POSITION_X and ABS_MT_POSITION_Y, which
|
||||
allows for multiple fingers to be tracked. If the device supports it, the
|
||||
ABS_MT_TOUCH_MAJOR and ABS_MT_WIDTH_MAJOR may be used to provide the size
|
||||
of the contact area and approaching finger, respectively.
|
||||
|
||||
The TOUCH and WIDTH parameters have a geometrical interpretation; imagine
|
||||
looking through a window at someone gently holding a finger against the
|
||||
glass. You will see two regions, one inner region consisting of the part
|
||||
of the finger actually touching the glass, and one outer region formed by
|
||||
the perimeter of the finger. The diameter of the inner region is the
|
||||
ABS_MT_TOUCH_MAJOR, the diameter of the outer region is
|
||||
ABS_MT_WIDTH_MAJOR. Now imagine the person pressing the finger harder
|
||||
against the glass. The inner region will increase, and in general, the
|
||||
ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR, which is always smaller than
|
||||
unity, is related to the finger pressure. For pressure-based devices,
|
||||
ABS_MT_PRESSURE may be used to provide the pressure on the contact area
|
||||
instead.
|
||||
|
||||
In addition to the MAJOR parameters, the oval shape of the finger can be
|
||||
described by adding the MINOR parameters, such that MAJOR and MINOR are the
|
||||
major and minor axis of an ellipse. Finally, the orientation of the oval
|
||||
shape can be describe with the ORIENTATION parameter.
|
||||
|
||||
The ABS_MT_TOOL_TYPE may be used to specify whether the touching tool is a
|
||||
finger or a pen or something else. Devices with more granular information
|
||||
may specify general shapes as blobs, i.e., as a sequence of rectangular
|
||||
shapes grouped together by an ABS_MT_BLOB_ID. Finally, for the few devices
|
||||
@@ -42,11 +60,9 @@ report finger tracking from hardware [5].
|
||||
Here is what a minimal event sequence for a two-finger touch would look
|
||||
like:
|
||||
|
||||
ABS_MT_TOUCH_MAJOR
|
||||
ABS_MT_POSITION_X
|
||||
ABS_MT_POSITION_Y
|
||||
SYN_MT_REPORT
|
||||
ABS_MT_TOUCH_MAJOR
|
||||
ABS_MT_POSITION_X
|
||||
ABS_MT_POSITION_Y
|
||||
SYN_MT_REPORT
|
||||
@@ -87,6 +103,12 @@ the contact. The ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR approximates
|
||||
the notion of pressure. The fingers of the hand and the palm all have
|
||||
different characteristic widths [1].
|
||||
|
||||
ABS_MT_PRESSURE
|
||||
|
||||
The pressure, in arbitrary units, on the contact area. May be used instead
|
||||
of TOUCH and WIDTH for pressure-based devices or any device with a spatial
|
||||
signal intensity distribution.
|
||||
|
||||
ABS_MT_ORIENTATION
|
||||
|
||||
The orientation of the ellipse. The value should describe a signed quarter
|
||||
@@ -170,6 +192,16 @@ There are a few devices that support trackingID in hardware. User space can
|
||||
make use of these native identifiers to reduce bandwidth and cpu usage.
|
||||
|
||||
|
||||
Gestures
|
||||
--------
|
||||
|
||||
In the specific application of creating gesture events, the TOUCH and WIDTH
|
||||
parameters can be used to, e.g., approximate finger pressure or distinguish
|
||||
between index finger and thumb. With the addition of the MINOR parameters,
|
||||
one can also distinguish between a sweeping finger and a pointing finger,
|
||||
and with ORIENTATION, one can detect twisting of fingers.
|
||||
|
||||
|
||||
Notes
|
||||
-----
|
||||
|
||||
|
||||
@@ -56,10 +56,11 @@ Following this convention is good because:
|
||||
(5) When following the convention, the driver code can use generic
|
||||
code to copy the parameters between user and kernel space.
|
||||
|
||||
This table lists ioctls visible from user land for Linux/i386. It contains
|
||||
most drivers up to 2.3.14, but I know I am missing some.
|
||||
This table lists ioctls visible from user land for Linux/x86. It contains
|
||||
most drivers up to 2.6.31, but I know I am missing some. There has been
|
||||
no attempt to list non-X86 architectures or ioctls from drivers/staging/.
|
||||
|
||||
Code Seq# Include File Comments
|
||||
Code Seq#(hex) Include File Comments
|
||||
========================================================
|
||||
0x00 00-1F linux/fs.h conflict!
|
||||
0x00 00-1F scsi/scsi_ioctl.h conflict!
|
||||
@@ -69,119 +70,228 @@ Code Seq# Include File Comments
|
||||
0x03 all linux/hdreg.h
|
||||
0x04 D2-DC linux/umsdos_fs.h Dead since 2.6.11, but don't reuse these.
|
||||
0x06 all linux/lp.h
|
||||
0x09 all linux/md.h
|
||||
0x09 all linux/raid/md_u.h
|
||||
0x10 00-0F drivers/char/s390/vmcp.h
|
||||
0x12 all linux/fs.h
|
||||
linux/blkpg.h
|
||||
0x1b all InfiniBand Subsystem <http://www.openib.org/>
|
||||
0x20 all drivers/cdrom/cm206.h
|
||||
0x22 all scsi/sg.h
|
||||
'#' 00-3F IEEE 1394 Subsystem Block for the entire subsystem
|
||||
'$' 00-0F linux/perf_counter.h, linux/perf_event.h
|
||||
'1' 00-1F <linux/timepps.h> PPS kit from Ulrich Windl
|
||||
<ftp://ftp.de.kernel.org/pub/linux/daemons/ntp/PPS/>
|
||||
'2' 01-04 linux/i2o.h
|
||||
'3' 00-0F drivers/s390/char/raw3270.h conflict!
|
||||
'3' 00-1F linux/suspend_ioctls.h conflict!
|
||||
and kernel/power/user.c
|
||||
'8' all SNP8023 advanced NIC card
|
||||
<mailto:mcr@solidum.com>
|
||||
'A' 00-1F linux/apm_bios.h
|
||||
'@' 00-0F linux/radeonfb.h conflict!
|
||||
'@' 00-0F drivers/video/aty/aty128fb.c conflict!
|
||||
'A' 00-1F linux/apm_bios.h conflict!
|
||||
'A' 00-0F linux/agpgart.h conflict!
|
||||
and drivers/char/agp/compat_ioctl.h
|
||||
'A' 00-7F sound/asound.h conflict!
|
||||
'B' 00-1F linux/cciss_ioctl.h conflict!
|
||||
'B' 00-0F include/linux/pmu.h conflict!
|
||||
'B' C0-FF advanced bbus
|
||||
<mailto:maassen@uni-freiburg.de>
|
||||
'C' all linux/soundcard.h
|
||||
'C' all linux/soundcard.h conflict!
|
||||
'C' 01-2F linux/capi.h conflict!
|
||||
'C' F0-FF drivers/net/wan/cosa.h conflict!
|
||||
'D' all arch/s390/include/asm/dasd.h
|
||||
'E' all linux/input.h
|
||||
'F' all linux/fb.h
|
||||
'H' all linux/hiddev.h
|
||||
'I' all linux/isdn.h
|
||||
'D' 40-5F drivers/scsi/dpt/dtpi_ioctl.h
|
||||
'D' 05 drivers/scsi/pmcraid.h
|
||||
'E' all linux/input.h conflict!
|
||||
'E' 00-0F xen/evtchn.h conflict!
|
||||
'F' all linux/fb.h conflict!
|
||||
'F' 01-02 drivers/scsi/pmcraid.h conflict!
|
||||
'F' 20 drivers/video/fsl-diu-fb.h conflict!
|
||||
'F' 20 drivers/video/intelfb/intelfb.h conflict!
|
||||
'F' 20 linux/ivtvfb.h conflict!
|
||||
'F' 20 linux/matroxfb.h conflict!
|
||||
'F' 20 drivers/video/aty/atyfb_base.c conflict!
|
||||
'F' 00-0F video/da8xx-fb.h conflict!
|
||||
'F' 80-8F linux/arcfb.h conflict!
|
||||
'F' DD video/sstfb.h conflict!
|
||||
'G' 00-3F drivers/misc/sgi-gru/grulib.h conflict!
|
||||
'G' 00-0F linux/gigaset_dev.h conflict!
|
||||
'H' 00-7F linux/hiddev.h conflict!
|
||||
'H' 00-0F linux/hidraw.h conflict!
|
||||
'H' 00-0F sound/asound.h conflict!
|
||||
'H' 20-40 sound/asound_fm.h conflict!
|
||||
'H' 80-8F sound/sfnt_info.h conflict!
|
||||
'H' 10-8F sound/emu10k1.h conflict!
|
||||
'H' 10-1F sound/sb16_csp.h conflict!
|
||||
'H' 10-1F sound/hda_hwdep.h conflict!
|
||||
'H' 40-4F sound/hdspm.h conflict!
|
||||
'H' 40-4F sound/hdsp.h conflict!
|
||||
'H' 90 sound/usb/usx2y/usb_stream.h
|
||||
'H' C0-F0 net/bluetooth/hci.h conflict!
|
||||
'H' C0-DF net/bluetooth/hidp/hidp.h conflict!
|
||||
'H' C0-DF net/bluetooth/cmtp/cmtp.h conflict!
|
||||
'H' C0-DF net/bluetooth/bnep/bnep.h conflict!
|
||||
'I' all linux/isdn.h conflict!
|
||||
'I' 00-0F drivers/isdn/divert/isdn_divert.h conflict!
|
||||
'I' 40-4F linux/mISDNif.h conflict!
|
||||
'J' 00-1F drivers/scsi/gdth_ioctl.h
|
||||
'K' all linux/kd.h
|
||||
'L' 00-1F linux/loop.h
|
||||
'L' 20-2F driver/usb/misc/vstusb.h
|
||||
'L' 00-1F linux/loop.h conflict!
|
||||
'L' 10-1F drivers/scsi/mpt2sas/mpt2sas_ctl.h conflict!
|
||||
'L' 20-2F linux/usb/vstusb.h
|
||||
'L' E0-FF linux/ppdd.h encrypted disk device driver
|
||||
<http://linux01.gwdg.de/~alatham/ppdd.html>
|
||||
'M' all linux/soundcard.h
|
||||
'M' all linux/soundcard.h conflict!
|
||||
'M' 01-16 mtd/mtd-abi.h conflict!
|
||||
and drivers/mtd/mtdchar.c
|
||||
'M' 01-03 drivers/scsi/megaraid/megaraid_sas.h
|
||||
'M' 00-0F drivers/video/fsl-diu-fb.h conflict!
|
||||
'N' 00-1F drivers/usb/scanner.h
|
||||
'O' 00-02 include/mtd/ubi-user.h UBI
|
||||
'P' all linux/soundcard.h
|
||||
'O' 00-06 mtd/ubi-user.h UBI
|
||||
'P' all linux/soundcard.h conflict!
|
||||
'P' 60-6F sound/sscape_ioctl.h conflict!
|
||||
'P' 00-0F drivers/usb/class/usblp.c conflict!
|
||||
'Q' all linux/soundcard.h
|
||||
'R' 00-1F linux/random.h
|
||||
'R' 00-1F linux/random.h conflict!
|
||||
'R' 01 linux/rfkill.h conflict!
|
||||
'R' 01-0F media/rds.h conflict!
|
||||
'R' C0-DF net/bluetooth/rfcomm.h
|
||||
'S' all linux/cdrom.h conflict!
|
||||
'S' 80-81 scsi/scsi_ioctl.h conflict!
|
||||
'S' 82-FF scsi/scsi.h conflict!
|
||||
'S' 00-7F sound/asequencer.h conflict!
|
||||
'T' all linux/soundcard.h conflict!
|
||||
'T' 00-AF sound/asound.h conflict!
|
||||
'T' all arch/x86/include/asm/ioctls.h conflict!
|
||||
'U' 00-EF linux/drivers/usb/usb.h
|
||||
'V' all linux/vt.h
|
||||
'T' C0-DF linux/if_tun.h conflict!
|
||||
'U' all sound/asound.h conflict!
|
||||
'U' 00-0F drivers/media/video/uvc/uvcvideo.h conflict!
|
||||
'U' 00-CF linux/uinput.h conflict!
|
||||
'U' 00-EF linux/usbdevice_fs.h
|
||||
'U' C0-CF drivers/bluetooth/hci_uart.h
|
||||
'V' all linux/vt.h conflict!
|
||||
'V' all linux/videodev2.h conflict!
|
||||
'V' C0 linux/ivtvfb.h conflict!
|
||||
'V' C0 linux/ivtv.h conflict!
|
||||
'V' C0 media/davinci/vpfe_capture.h conflict!
|
||||
'V' C0 media/si4713.h conflict!
|
||||
'V' C0-CF drivers/media/video/mxb.h conflict!
|
||||
'W' 00-1F linux/watchdog.h conflict!
|
||||
'W' 00-1F linux/wanrouter.h conflict!
|
||||
'X' all linux/xfs_fs.h
|
||||
'W' 00-3F sound/asound.h conflict!
|
||||
'X' all fs/xfs/xfs_fs.h conflict!
|
||||
and fs/xfs/linux-2.6/xfs_ioctl32.h
|
||||
and include/linux/falloc.h
|
||||
and linux/fs.h
|
||||
'X' all fs/ocfs2/ocfs_fs.h conflict!
|
||||
'X' 01 linux/pktcdvd.h conflict!
|
||||
'Y' all linux/cyclades.h
|
||||
'[' 00-07 linux/usb/usbtmc.h USB Test and Measurement Devices
|
||||
'Z' 14-15 drivers/message/fusion/mptctl.h
|
||||
'[' 00-07 linux/usb/tmc.h USB Test and Measurement Devices
|
||||
<mailto:gregkh@suse.de>
|
||||
'a' all ATM on linux
|
||||
'a' all linux/atm*.h, linux/sonet.h ATM on linux
|
||||
<http://lrcwww.epfl.ch/linux-atm/magic.html>
|
||||
'b' 00-FF bit3 vme host bridge
|
||||
'b' 00-FF conflict! bit3 vme host bridge
|
||||
<mailto:natalia@nikhefk.nikhef.nl>
|
||||
'b' 00-0F media/bt819.h conflict!
|
||||
'c' all linux/cm4000_cs.h conflict!
|
||||
'c' 00-7F linux/comstats.h conflict!
|
||||
'c' 00-7F linux/coda.h conflict!
|
||||
'c' 80-9F arch/s390/include/asm/chsc.h
|
||||
'c' A0-AF arch/x86/include/asm/msr.h
|
||||
'c' 00-1F linux/chio.h conflict!
|
||||
'c' 80-9F arch/s390/include/asm/chsc.h conflict!
|
||||
'c' A0-AF arch/x86/include/asm/msr.h conflict!
|
||||
'd' 00-FF linux/char/drm/drm/h conflict!
|
||||
'd' 02-40 pcmcia/ds.h conflict!
|
||||
'd' 10-3F drivers/media/video/dabusb.h conflict!
|
||||
'd' C0-CF drivers/media/video/saa7191.h conflict!
|
||||
'd' F0-FF linux/digi1.h
|
||||
'e' all linux/digi1.h conflict!
|
||||
'e' 00-1F net/irda/irtty.h conflict!
|
||||
'f' 00-1F linux/ext2_fs.h
|
||||
'h' 00-7F Charon filesystem
|
||||
'e' 00-1F drivers/net/irda/irtty-sir.h conflict!
|
||||
'f' 00-1F linux/ext2_fs.h conflict!
|
||||
'f' 00-1F linux/ext3_fs.h conflict!
|
||||
'f' 00-0F fs/jfs/jfs_dinode.h conflict!
|
||||
'f' 00-0F fs/ext4/ext4.h conflict!
|
||||
'f' 00-0F linux/fs.h conflict!
|
||||
'f' 00-0F fs/ocfs2/ocfs2_fs.h conflict!
|
||||
'g' 00-0F linux/usb/gadgetfs.h
|
||||
'g' 20-2F linux/usb/g_printer.h
|
||||
'h' 00-7F conflict! Charon filesystem
|
||||
<mailto:zapman@interlan.net>
|
||||
'i' 00-3F linux/i2o.h
|
||||
'h' 00-1F linux/hpet.h conflict!
|
||||
'i' 00-3F linux/i2o-dev.h conflict!
|
||||
'i' 0B-1F linux/ipmi.h conflict!
|
||||
'i' 80-8F linux/i8k.h
|
||||
'j' 00-3F linux/joystick.h
|
||||
'k' 00-0F linux/spi/spidev.h conflict!
|
||||
'k' 00-05 video/kyro.h conflict!
|
||||
'l' 00-3F linux/tcfs_fs.h transparent cryptographic file system
|
||||
<http://mikonos.dia.unisa.it/tcfs>
|
||||
'l' 40-7F linux/udf_fs_i.h in development:
|
||||
<http://sourceforge.net/projects/linux-udf/>
|
||||
'm' 00-09 linux/mmtimer.h
|
||||
'm' 00-09 linux/mmtimer.h conflict!
|
||||
'm' all linux/mtio.h conflict!
|
||||
'm' all linux/soundcard.h conflict!
|
||||
'm' all linux/synclink.h conflict!
|
||||
'm' 00-19 drivers/message/fusion/mptctl.h conflict!
|
||||
'm' 00 drivers/scsi/megaraid/megaraid_ioctl.h conflict!
|
||||
'm' 00-1F net/irda/irmod.h conflict!
|
||||
'n' 00-7F linux/ncp_fs.h
|
||||
'n' 00-7F linux/ncp_fs.h and fs/ncpfs/ioctl.c
|
||||
'n' 80-8F linux/nilfs2_fs.h NILFS2
|
||||
'n' E0-FF video/matrox.h matroxfb
|
||||
'n' E0-FF linux/matroxfb.h matroxfb
|
||||
'o' 00-1F fs/ocfs2/ocfs2_fs.h OCFS2
|
||||
'o' 00-03 include/mtd/ubi-user.h conflict! (OCFS2 and UBI overlaps)
|
||||
'o' 40-41 include/mtd/ubi-user.h UBI
|
||||
'o' 01-A1 include/linux/dvb/*.h DVB
|
||||
'o' 00-03 mtd/ubi-user.h conflict! (OCFS2 and UBI overlaps)
|
||||
'o' 40-41 mtd/ubi-user.h UBI
|
||||
'o' 01-A1 linux/dvb/*.h DVB
|
||||
'p' 00-0F linux/phantom.h conflict! (OpenHaptics needs this)
|
||||
'p' 00-1F linux/rtc.h conflict!
|
||||
'p' 00-3F linux/mc146818rtc.h conflict!
|
||||
'p' 40-7F linux/nvram.h
|
||||
'p' 80-9F user-space parport
|
||||
'p' 80-9F linux/ppdev.h user-space parport
|
||||
<mailto:tim@cyberelk.net>
|
||||
'p' a1-a4 linux/pps.h LinuxPPS
|
||||
'p' A1-A4 linux/pps.h LinuxPPS
|
||||
<mailto:giometti@linux.it>
|
||||
'q' 00-1F linux/serio.h
|
||||
'q' 80-FF Internet PhoneJACK, Internet LineJACK
|
||||
<http://www.quicknet.net>
|
||||
'r' 00-1F linux/msdos_fs.h
|
||||
'q' 80-FF linux/telephony.h Internet PhoneJACK, Internet LineJACK
|
||||
linux/ixjuser.h <http://www.quicknet.net>
|
||||
'r' 00-1F linux/msdos_fs.h and fs/fat/dir.c
|
||||
's' all linux/cdk.h
|
||||
't' 00-7F linux/if_ppp.h
|
||||
't' 80-8F linux/isdn_ppp.h
|
||||
't' 90 linux/toshiba.h
|
||||
'u' 00-1F linux/smb_fs.h
|
||||
'v' 00-1F linux/ext2_fs.h conflict!
|
||||
'v' all linux/videodev.h conflict!
|
||||
'v' 00-1F linux/ext2_fs.h conflict!
|
||||
'v' 00-1F linux/fs.h conflict!
|
||||
'v' 00-0F linux/sonypi.h conflict!
|
||||
'v' C0-CF drivers/media/video/ov511.h conflict!
|
||||
'v' C0-DF media/pwc-ioctl.h conflict!
|
||||
'v' C0-FF linux/meye.h conflict!
|
||||
'v' C0-CF drivers/media/video/zoran/zoran.h conflict!
|
||||
'v' D0-DF drivers/media/video/cpia2/cpia2dev.h conflict!
|
||||
'w' all CERN SCI driver
|
||||
'y' 00-1F packet based user level communications
|
||||
<mailto:zapman@interlan.net>
|
||||
'z' 00-3F CAN bus card
|
||||
'z' 00-3F CAN bus card conflict!
|
||||
<mailto:hdstich@connectu.ulm.circular.de>
|
||||
'z' 40-7F CAN bus card
|
||||
'z' 40-7F CAN bus card conflict!
|
||||
<mailto:oe@port.de>
|
||||
'z' 10-4F drivers/s390/crypto/zcrypt_api.h conflict!
|
||||
0x80 00-1F linux/fb.h
|
||||
0x81 00-1F linux/videotext.h
|
||||
0x88 00-3F media/ovcamchip.h
|
||||
0x89 00-06 arch/x86/include/asm/sockios.h
|
||||
0x89 0B-DF linux/sockios.h
|
||||
0x89 E0-EF linux/sockios.h SIOCPROTOPRIVATE range
|
||||
0x89 E0-EF linux/dn.h PROTOPRIVATE range
|
||||
0x89 F0-FF linux/sockios.h SIOCDEVPRIVATE range
|
||||
0x8B all linux/wireless.h
|
||||
0x8C 00-3F WiNRADiO driver
|
||||
<http://www.proximity.com.au/~brian/winradio/>
|
||||
0x90 00 drivers/cdrom/sbpcd.h
|
||||
0x92 00-0F drivers/usb/mon/mon_bin.c
|
||||
0x93 60-7F linux/auto_fs.h
|
||||
0x94 all fs/btrfs/ioctl.h
|
||||
0x99 00-0F 537-Addinboard driver
|
||||
<mailto:buk@buks.ipn.de>
|
||||
0xA0 all linux/sdp/sdp.h Industrial Device Project
|
||||
@@ -192,17 +302,22 @@ Code Seq# Include File Comments
|
||||
0xAB 00-1F linux/nbd.h
|
||||
0xAC 00-1F linux/raw.h
|
||||
0xAD 00 Netfilter device in development:
|
||||
<mailto:rusty@rustcorp.com.au>
|
||||
<mailto:rusty@rustcorp.com.au>
|
||||
0xAE all linux/kvm.h Kernel-based Virtual Machine
|
||||
<mailto:kvm@vger.kernel.org>
|
||||
0xB0 all RATIO devices in development:
|
||||
<mailto:vgo@ratio.de>
|
||||
0xB1 00-1F PPPoX <mailto:mostrows@styx.uwaterloo.ca>
|
||||
0xC0 00-0F linux/usb/iowarrior.h
|
||||
0xCB 00-1F CBM serial IEC bus in development:
|
||||
<mailto:michael.klein@puffin.lb.shuttle.de>
|
||||
0xCD 01 linux/reiserfs_fs.h
|
||||
0xCF 02 fs/cifs/ioctl.c
|
||||
0xDB 00-0F drivers/char/mwave/mwavepub.h
|
||||
0xDD 00-3F ZFCP device driver see drivers/s390/scsi/
|
||||
<mailto:aherrman@de.ibm.com>
|
||||
0xF3 00-3F video/sisfb.h sisfb (in development)
|
||||
0xF3 00-3F drivers/usb/misc/sisusbvga/sisusb.h sisfb (in development)
|
||||
<mailto:thomas@winischhofer.net>
|
||||
0xF4 00-1F video/mbxfb.h mbxfb
|
||||
<mailto:raph@8d.com>
|
||||
0xFD all linux/dm-ioctl.h
|
||||
|
||||
@@ -214,11 +214,13 @@ The format of the block comment is like this:
|
||||
* (section header: (section description)? )*
|
||||
(*)?*/
|
||||
|
||||
The short function description ***cannot be multiline***, but the other
|
||||
descriptions can be (and they can contain blank lines). If you continue
|
||||
that initial short description onto a second line, that second line will
|
||||
appear further down at the beginning of the description section, which is
|
||||
almost certainly not what you had in mind.
|
||||
All "description" text can span multiple lines, although the
|
||||
function_name & its short description are traditionally on a single line.
|
||||
Description text may also contain blank lines (i.e., lines that contain
|
||||
only a "*").
|
||||
|
||||
"section header:" names must be unique per function (or struct,
|
||||
union, typedef, enum).
|
||||
|
||||
Avoid putting a spurious blank line after the function name, or else the
|
||||
description will be repeated!
|
||||
|
||||
@@ -199,6 +199,10 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
acpi_display_output=video
|
||||
See above.
|
||||
|
||||
acpi_early_pdc_eval [HW,ACPI] Evaluate processor _PDC methods
|
||||
early. Needed on some platforms to properly
|
||||
initialize the EC.
|
||||
|
||||
acpi_irq_balance [HW,ACPI]
|
||||
ACPI will balance active IRQs
|
||||
default in APIC mode
|
||||
@@ -311,6 +315,11 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
aic79xx= [HW,SCSI]
|
||||
See Documentation/scsi/aic79xx.txt.
|
||||
|
||||
alignment= [KNL,ARM]
|
||||
Allow the default userspace alignment fault handler
|
||||
behaviour to be specified. Bit 0 enables warnings,
|
||||
bit 1 enables fixups, and bit 2 sends a segfault.
|
||||
|
||||
amd_iommu= [HW,X86-84]
|
||||
Pass parameters to the AMD IOMMU driver in the system.
|
||||
Possible values are:
|
||||
|
||||
@@ -48,11 +48,11 @@ for LILO parameters for doing this:
|
||||
This configures the first found 3c509 card for IRQ 10, base I/O 0x310, and
|
||||
transceiver type 3 (10base2). The flag "0x3c509" must be set to avoid conflicts
|
||||
with other card types when overriding the I/O address. When the driver is
|
||||
loaded as a module, only the IRQ and transceiver setting may be overridden.
|
||||
For example, setting two cards to 10base2/IRQ10 and AUI/IRQ11 is done by using
|
||||
the xcvr and irq module options:
|
||||
loaded as a module, only the IRQ may be overridden. For example,
|
||||
setting two cards to IRQ10 and IRQ11 is done by using the irq module
|
||||
option:
|
||||
|
||||
options 3c509 xcvr=3,1 irq=10,11
|
||||
options 3c509 irq=10,11
|
||||
|
||||
|
||||
(2) Full-duplex mode
|
||||
@@ -77,6 +77,8 @@ operation.
|
||||
itself full-duplex capable. This is almost certainly one of two things: a full-
|
||||
duplex-capable Ethernet switch (*not* a hub), or a full-duplex-capable NIC on
|
||||
another system that's connected directly to the 3c509B via a crossover cable.
|
||||
|
||||
Full-duplex mode can be enabled using 'ethtool'.
|
||||
|
||||
/////Extremely important caution concerning full-duplex mode/////
|
||||
Understand that the 3c509B's hardware's full-duplex support is much more
|
||||
@@ -113,6 +115,8 @@ This insured that merely upgrading the driver from an earlier version would
|
||||
never automatically enable full-duplex mode in an existing installation;
|
||||
it must always be explicitly enabled via one of these code in order to be
|
||||
activated.
|
||||
|
||||
The transceiver type can be changed using 'ethtool'.
|
||||
|
||||
|
||||
(4a) Interpretation of error messages and common problems
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
function tracer guts
|
||||
====================
|
||||
By Mike Frysinger
|
||||
|
||||
Introduction
|
||||
------------
|
||||
@@ -53,14 +54,14 @@ size of the mcount call that is embedded in the function).
|
||||
For example, if the function foo() calls bar(), when the bar() function calls
|
||||
mcount(), the arguments mcount() will pass to the tracer are:
|
||||
"frompc" - the address bar() will use to return to foo()
|
||||
"selfpc" - the address bar() (with _mcount() size adjustment)
|
||||
"selfpc" - the address bar() (with mcount() size adjustment)
|
||||
|
||||
Also keep in mind that this mcount function will be called *a lot*, so
|
||||
optimizing for the default case of no tracer will help the smooth running of
|
||||
your system when tracing is disabled. So the start of the mcount function is
|
||||
typically the bare min with checking things before returning. That also means
|
||||
the code flow should usually kept linear (i.e. no branching in the nop case).
|
||||
This is of course an optimization and not a hard requirement.
|
||||
typically the bare minimum with checking things before returning. That also
|
||||
means the code flow should usually be kept linear (i.e. no branching in the nop
|
||||
case). This is of course an optimization and not a hard requirement.
|
||||
|
||||
Here is some pseudo code that should help (these functions should actually be
|
||||
implemented in assembly):
|
||||
@@ -131,10 +132,10 @@ some functions to save (hijack) and restore the return address.
|
||||
|
||||
The mcount function should check the function pointers ftrace_graph_return
|
||||
(compare to ftrace_stub) and ftrace_graph_entry (compare to
|
||||
ftrace_graph_entry_stub). If either of those are not set to the relevant stub
|
||||
ftrace_graph_entry_stub). If either of those is not set to the relevant stub
|
||||
function, call the arch-specific function ftrace_graph_caller which in turn
|
||||
calls the arch-specific function prepare_ftrace_return. Neither of these
|
||||
function names are strictly required, but you should use them anyways to stay
|
||||
function names is strictly required, but you should use them anyway to stay
|
||||
consistent across the architecture ports -- easier to compare & contrast
|
||||
things.
|
||||
|
||||
@@ -144,7 +145,7 @@ but the first argument should be a pointer to the "frompc". Typically this is
|
||||
located on the stack. This allows the function to hijack the return address
|
||||
temporarily to have it point to the arch-specific function return_to_handler.
|
||||
That function will simply call the common ftrace_return_to_handler function and
|
||||
that will return the original return address with which, you can return to the
|
||||
that will return the original return address with which you can return to the
|
||||
original call site.
|
||||
|
||||
Here is the updated mcount pseudo code:
|
||||
@@ -173,14 +174,16 @@ void ftrace_graph_caller(void)
|
||||
|
||||
unsigned long *frompc = &...;
|
||||
unsigned long selfpc = <return address> - MCOUNT_INSN_SIZE;
|
||||
prepare_ftrace_return(frompc, selfpc);
|
||||
/* passing frame pointer up is optional -- see below */
|
||||
prepare_ftrace_return(frompc, selfpc, frame_pointer);
|
||||
|
||||
/* restore all state needed by the ABI */
|
||||
}
|
||||
#endif
|
||||
|
||||
For information on how to implement prepare_ftrace_return(), simply look at
|
||||
the x86 version. The only architecture-specific piece in it is the setup of
|
||||
For information on how to implement prepare_ftrace_return(), simply look at the
|
||||
x86 version (the frame pointer passing is optional; see the next section for
|
||||
more information). The only architecture-specific piece in it is the setup of
|
||||
the fault recovery table (the asm(...) code). The rest should be the same
|
||||
across architectures.
|
||||
|
||||
@@ -205,6 +208,23 @@ void return_to_handler(void)
|
||||
#endif
|
||||
|
||||
|
||||
HAVE_FUNCTION_GRAPH_FP_TEST
|
||||
---------------------------
|
||||
|
||||
An arch may pass in a unique value (frame pointer) to both the entering and
|
||||
exiting of a function. On exit, the value is compared and if it does not
|
||||
match, then it will panic the kernel. This is largely a sanity check for bad
|
||||
code generation with gcc. If gcc for your port sanely updates the frame
|
||||
pointer under different opitmization levels, then ignore this option.
|
||||
|
||||
However, adding support for it isn't terribly difficult. In your assembly code
|
||||
that calls prepare_ftrace_return(), pass the frame pointer as the 3rd argument.
|
||||
Then in the C version of that function, do what the x86 port does and pass it
|
||||
along to ftrace_push_return_trace() instead of a stub value of 0.
|
||||
|
||||
Similarly, when you call ftrace_return_to_handler(), pass it the frame pointer.
|
||||
|
||||
|
||||
HAVE_FTRACE_NMI_ENTER
|
||||
---------------------
|
||||
|
||||
|
||||
@@ -1625,7 +1625,7 @@ If I am only interested in sys_nanosleep and hrtimer_interrupt:
|
||||
|
||||
# echo sys_nanosleep hrtimer_interrupt \
|
||||
> set_ftrace_filter
|
||||
# echo ftrace > current_tracer
|
||||
# echo function > current_tracer
|
||||
# echo 1 > tracing_enabled
|
||||
# usleep 1
|
||||
# echo 0 > tracing_enabled
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user