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 branches 'upstream/core', 'upstream/xenfs' and 'upstream/evtchn' into upstream/for-linus
* upstream/core: xen/events: Use PIRQ instead of GSI value when unmapping MSI/MSI-X irqs. xen: set IO permission early (before early_cpu_init()) xen: re-enable boot-time ballooning xen/balloon: make sure we only include remaining extra ram xen/balloon: the balloon_lock is useless xen: add extra pages to balloon xen/events: use locked set|clear_bit() for cpu_evtchn_mask xen/evtchn: clear secondary CPUs' cpu_evtchn_mask[] after restore xen: implement XENMEM_machphys_mapping * upstream/xenfs: Revert "xen/privcmd: create address space to allow writable mmaps" xen/xenfs: update xenfs_mount for new prototype xen: fix header export to userspace xen: set vma flag VM_PFNMAP in the privcmd mmap file_op xen: xenfs: privcmd: check put_user() return code * upstream/evtchn: xen: make evtchn's name less generic xen/evtchn: the evtchn device is non-seekable xen/evtchn: add missing static xen/evtchn: Fix name of Xen event-channel device xen/evtchn: don't do unbind_from_irqhandler under spinlock xen/evtchn: remove spurious barrier xen/evtchn: ports start enabled xen/evtchn: dynamically allocate port_user array xen/evtchn: track enabled state for each port
This commit is contained in:
@@ -0,0 +1,22 @@
|
||||
What: /proc/<pid>/oom_adj
|
||||
When: August 2012
|
||||
Why: /proc/<pid>/oom_adj allows userspace to influence the oom killer's
|
||||
badness heuristic used to determine which task to kill when the kernel
|
||||
is out of memory.
|
||||
|
||||
The badness heuristic has since been rewritten since the introduction of
|
||||
this tunable such that its meaning is deprecated. The value was
|
||||
implemented as a bitshift on a score generated by the badness()
|
||||
function that did not have any precise units of measure. With the
|
||||
rewrite, the score is given as a proportion of available memory to the
|
||||
task allocating pages, so using a bitshift which grows the score
|
||||
exponentially is, thus, impossible to tune with fine granularity.
|
||||
|
||||
A much more powerful interface, /proc/<pid>/oom_score_adj, was
|
||||
introduced with the oom killer rewrite that allows users to increase or
|
||||
decrease the badness() score linearly. This interface will replace
|
||||
/proc/<pid>/oom_adj.
|
||||
|
||||
A warning will be emitted to the kernel log if an application uses this
|
||||
deprecated interface. After it is printed once, future warnings will be
|
||||
suppressed until the kernel is rebooted.
|
||||
@@ -710,7 +710,18 @@ Task Addr Pid Parent [*] cpu State Thread Command
|
||||
<listitem><para>A simple shell</para></listitem>
|
||||
<listitem><para>The kdb core command set</para></listitem>
|
||||
<listitem><para>A registration API to register additional kdb shell commands.</para>
|
||||
<para>A good example of a self-contained kdb module is the "ftdump" command for dumping the ftrace buffer. See: kernel/trace/trace_kdb.c</para></listitem>
|
||||
<itemizedlist>
|
||||
<listitem><para>A good example of a self-contained kdb module
|
||||
is the "ftdump" command for dumping the ftrace buffer. See:
|
||||
kernel/trace/trace_kdb.c</para></listitem>
|
||||
<listitem><para>For an example of how to dynamically register
|
||||
a new kdb command you can build the kdb_hello.ko kernel module
|
||||
from samples/kdb/kdb_hello.c. To build this example you can
|
||||
set CONFIG_SAMPLES=y and CONFIG_SAMPLE_KDB=m in your kernel
|
||||
config. Later run "modprobe kdb_hello" and the next time you
|
||||
enter the kdb shell, you can run the "hello"
|
||||
command.</para></listitem>
|
||||
</itemizedlist></listitem>
|
||||
<listitem><para>The implementation for kdb_printf() which
|
||||
emits messages directly to I/O drivers, bypassing the kernel
|
||||
log.</para></listitem>
|
||||
|
||||
@@ -255,9 +255,10 @@ framebuffer parameters.
|
||||
Kernel boot arguments
|
||||
---------------------
|
||||
|
||||
vram=<size>
|
||||
- Amount of total VRAM to preallocate. For example, "10M". omapfb
|
||||
allocates memory for framebuffers from VRAM.
|
||||
vram=<size>[,<physaddr>]
|
||||
- Amount of total VRAM to preallocate and optionally a physical start
|
||||
memory address. For example, "10M". omapfb allocates memory for
|
||||
framebuffers from VRAM.
|
||||
|
||||
omapfb.mode=<display>:<mode>[,...]
|
||||
- Default video mode for specified displays. For example,
|
||||
|
||||
@@ -16,7 +16,7 @@ you can do so by typing:
|
||||
As of the Linux 2.6.10 kernel, it is now possible to change the
|
||||
IO scheduler for a given block device on the fly (thus making it possible,
|
||||
for instance, to set the CFQ scheduler for the system default, but
|
||||
set a specific device to use the anticipatory or noop schedulers - which
|
||||
set a specific device to use the deadline or noop schedulers - which
|
||||
can improve that device's throughput).
|
||||
|
||||
To set a specific scheduler, simply do this:
|
||||
@@ -31,7 +31,7 @@ a "cat /sys/block/DEV/queue/scheduler" - the list of valid names
|
||||
will be displayed, with the currently selected scheduler in brackets:
|
||||
|
||||
# cat /sys/block/hda/queue/scheduler
|
||||
noop anticipatory deadline [cfq]
|
||||
# echo anticipatory > /sys/block/hda/queue/scheduler
|
||||
noop deadline [cfq]
|
||||
# echo deadline > /sys/block/hda/queue/scheduler
|
||||
# cat /sys/block/hda/queue/scheduler
|
||||
noop [anticipatory] deadline cfq
|
||||
noop [deadline] cfq
|
||||
|
||||
@@ -554,3 +554,13 @@ Why: This is a legacy interface which have been replaced by a more
|
||||
Who: NeilBrown <neilb@suse.de>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: i2c_adapter.id
|
||||
When: June 2011
|
||||
Why: This field is deprecated. I2C device drivers shouldn't change their
|
||||
behavior based on the underlying I2C adapter. Instead, the I2C
|
||||
adapter driver should instantiate the I2C devices and provide the
|
||||
needed platform-specific information.
|
||||
Who: Jean Delvare <khali@linux-fr.org>
|
||||
|
||||
----------------------------
|
||||
|
||||
@@ -322,7 +322,6 @@ fl_release_private: yes yes
|
||||
prototypes:
|
||||
int (*fl_compare_owner)(struct file_lock *, struct file_lock *);
|
||||
void (*fl_notify)(struct file_lock *); /* unblock callback */
|
||||
void (*fl_copy_lock)(struct file_lock *, struct file_lock *);
|
||||
void (*fl_release_private)(struct file_lock *);
|
||||
void (*fl_break)(struct file_lock *); /* break_lease callback */
|
||||
|
||||
@@ -330,7 +329,6 @@ locking rules:
|
||||
BKL may block
|
||||
fl_compare_owner: yes no
|
||||
fl_notify: yes no
|
||||
fl_copy_lock: yes no
|
||||
fl_release_private: yes yes
|
||||
fl_break: yes no
|
||||
|
||||
|
||||
@@ -794,17 +794,6 @@ designed.
|
||||
|
||||
Roadmap:
|
||||
|
||||
2.6.37 Remove experimental tag from mount option
|
||||
=> should be roughly 6 months after initial merge
|
||||
=> enough time to:
|
||||
=> gain confidence and fix problems reported by early
|
||||
adopters (a.k.a. guinea pigs)
|
||||
=> address worst performance regressions and undesired
|
||||
behaviours
|
||||
=> start tuning/optimising code for parallelism
|
||||
=> start tuning/optimising algorithms consuming
|
||||
excessive CPU time
|
||||
|
||||
2.6.39 Switch default mount option to use delayed logging
|
||||
=> should be roughly 12 months after initial merge
|
||||
=> enough time to shake out remaining problems before next round of
|
||||
|
||||
@@ -15,10 +15,14 @@ Supported adapters:
|
||||
* Intel 82801I (ICH9)
|
||||
* Intel EP80579 (Tolapai)
|
||||
* Intel 82801JI (ICH10)
|
||||
* Intel 3400/5 Series (PCH)
|
||||
* Intel 5/3400 Series (PCH)
|
||||
* Intel Cougar Point (PCH)
|
||||
* Intel Patsburg (PCH)
|
||||
Datasheets: Publicly available at the Intel website
|
||||
|
||||
On Intel Patsburg and later chipsets, both the normal host SMBus controller
|
||||
and the additional 'Integrated Device Function' controllers are supported.
|
||||
|
||||
Authors:
|
||||
Mark Studebaker <mdsxyz123@yahoo.com>
|
||||
Jean Delvare <khali@linux-fr.org>
|
||||
|
||||
@@ -706,7 +706,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
arch/x86/kernel/cpu/cpufreq/elanfreq.c.
|
||||
|
||||
elevator= [IOSCHED]
|
||||
Format: {"anticipatory" | "cfq" | "deadline" | "noop"}
|
||||
Format: {"cfq" | "deadline" | "noop"}
|
||||
See Documentation/block/as-iosched.txt and
|
||||
Documentation/block/deadline-iosched.txt for details.
|
||||
|
||||
|
||||
@@ -60,15 +60,18 @@ Hardware accelerated blink of LEDs
|
||||
|
||||
Some LEDs can be programmed to blink without any CPU interaction. To
|
||||
support this feature, a LED driver can optionally implement the
|
||||
blink_set() function (see <linux/leds.h>). If implemented, triggers can
|
||||
attempt to use it before falling back to software timers. The blink_set()
|
||||
function should return 0 if the blink setting is supported, or -EINVAL
|
||||
otherwise, which means that LED blinking will be handled by software.
|
||||
blink_set() function (see <linux/leds.h>). To set an LED to blinking,
|
||||
however, it is better to use use the API function led_blink_set(),
|
||||
as it will check and implement software fallback if necessary.
|
||||
|
||||
The blink_set() function should choose a user friendly blinking
|
||||
value if it is called with *delay_on==0 && *delay_off==0 parameters. In
|
||||
this case the driver should give back the chosen value through delay_on
|
||||
and delay_off parameters to the leds subsystem.
|
||||
To turn off blinking again, use the API function led_brightness_set()
|
||||
as that will not just set the LED brightness but also stop any software
|
||||
timers that may have been required for blinking.
|
||||
|
||||
The blink_set() function should choose a user friendly blinking value
|
||||
if it is called with *delay_on==0 && *delay_off==0 parameters. In this
|
||||
case the driver should give back the chosen value through delay_on and
|
||||
delay_off parameters to the leds subsystem.
|
||||
|
||||
Setting the brightness to zero with brightness_set() callback function
|
||||
should completely turn off the LED and cancel the previously programmed
|
||||
|
||||
@@ -0,0 +1,88 @@
|
||||
Kernel driver for lp5521
|
||||
========================
|
||||
|
||||
* National Semiconductor LP5521 led driver chip
|
||||
* Datasheet: http://www.national.com/pf/LP/LP5521.html
|
||||
|
||||
Authors: Mathias Nyman, Yuri Zaporozhets, Samu Onkalo
|
||||
Contact: Samu Onkalo (samu.p.onkalo-at-nokia.com)
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
LP5521 can drive up to 3 channels. Leds can be controlled directly via
|
||||
the led class control interface. Channels have generic names:
|
||||
lp5521:channelx, where x is 0 .. 2
|
||||
|
||||
All three channels can be also controlled using the engine micro programs.
|
||||
More details of the instructions can be found from the public data sheet.
|
||||
|
||||
Control interface for the engines:
|
||||
x is 1 .. 3
|
||||
enginex_mode : disabled, load, run
|
||||
enginex_load : store program (visible only in engine load mode)
|
||||
|
||||
Example (start to blink the channel 2 led):
|
||||
cd /sys/class/leds/lp5521:channel2/device
|
||||
echo "load" > engine3_mode
|
||||
echo "037f4d0003ff6000" > engine3_load
|
||||
echo "run" > engine3_mode
|
||||
|
||||
stop the engine:
|
||||
echo "disabled" > engine3_mode
|
||||
|
||||
sysfs contains a selftest entry.
|
||||
The test communicates with the chip and checks that
|
||||
the clock mode is automatically set to the requested one.
|
||||
|
||||
Each channel has its own led current settings.
|
||||
/sys/class/leds/lp5521:channel0/led_current - RW
|
||||
/sys/class/leds/lp5521:channel0/max_current - RO
|
||||
Format: 10x mA i.e 10 means 1.0 mA
|
||||
|
||||
example platform data:
|
||||
|
||||
Note: chan_nr can have values between 0 and 2.
|
||||
|
||||
static struct lp5521_led_config lp5521_led_config[] = {
|
||||
{
|
||||
.chan_nr = 0,
|
||||
.led_current = 50,
|
||||
.max_current = 130,
|
||||
}, {
|
||||
.chan_nr = 1,
|
||||
.led_current = 0,
|
||||
.max_current = 130,
|
||||
}, {
|
||||
.chan_nr = 2,
|
||||
.led_current = 0,
|
||||
.max_current = 130,
|
||||
}
|
||||
};
|
||||
|
||||
static int lp5521_setup(void)
|
||||
{
|
||||
/* setup HW resources */
|
||||
}
|
||||
|
||||
static void lp5521_release(void)
|
||||
{
|
||||
/* Release HW resources */
|
||||
}
|
||||
|
||||
static void lp5521_enable(bool state)
|
||||
{
|
||||
/* Control of chip enable signal */
|
||||
}
|
||||
|
||||
static struct lp5521_platform_data lp5521_platform_data = {
|
||||
.led_config = lp5521_led_config,
|
||||
.num_channels = ARRAY_SIZE(lp5521_led_config),
|
||||
.clock_mode = LP5521_CLOCK_EXT,
|
||||
.setup_resources = lp5521_setup,
|
||||
.release_resources = lp5521_release,
|
||||
.enable = lp5521_enable,
|
||||
};
|
||||
|
||||
If the current is set to 0 in the platform data, that channel is
|
||||
disabled and it is not visible in the sysfs.
|
||||
@@ -0,0 +1,83 @@
|
||||
Kernel driver for lp5523
|
||||
========================
|
||||
|
||||
* National Semiconductor LP5523 led driver chip
|
||||
* Datasheet: http://www.national.com/pf/LP/LP5523.html
|
||||
|
||||
Authors: Mathias Nyman, Yuri Zaporozhets, Samu Onkalo
|
||||
Contact: Samu Onkalo (samu.p.onkalo-at-nokia.com)
|
||||
|
||||
Description
|
||||
-----------
|
||||
LP5523 can drive up to 9 channels. Leds can be controlled directly via
|
||||
the led class control interface. Channels have generic names:
|
||||
lp5523:channelx where x is 0...8
|
||||
|
||||
The chip provides 3 engines. Each engine can control channels without
|
||||
interaction from the main CPU. Details of the micro engine code can be found
|
||||
from the public data sheet. Leds can be muxed to different channels.
|
||||
|
||||
Control interface for the engines:
|
||||
x is 1 .. 3
|
||||
enginex_mode : disabled, load, run
|
||||
enginex_load : microcode load (visible only in load mode)
|
||||
enginex_leds : led mux control (visible only in load mode)
|
||||
|
||||
cd /sys/class/leds/lp5523:channel2/device
|
||||
echo "load" > engine3_mode
|
||||
echo "9d80400004ff05ff437f0000" > engine3_load
|
||||
echo "111111111" > engine3_leds
|
||||
echo "run" > engine3_mode
|
||||
|
||||
sysfs contains a selftest entry. It measures each channel
|
||||
voltage level and checks if it looks reasonable. If the level is too high,
|
||||
the led is missing; if the level is too low, there is a short circuit.
|
||||
|
||||
Selftest uses always the current from the platform data.
|
||||
|
||||
Each channel contains led current settings.
|
||||
/sys/class/leds/lp5523:channel2/led_current - RW
|
||||
/sys/class/leds/lp5523:channel2/max_current - RO
|
||||
Format: 10x mA i.e 10 means 1.0 mA
|
||||
|
||||
Example platform data:
|
||||
|
||||
Note - chan_nr can have values between 0 and 8.
|
||||
|
||||
static struct lp5523_led_config lp5523_led_config[] = {
|
||||
{
|
||||
.chan_nr = 0,
|
||||
.led_current = 50,
|
||||
.max_current = 130,
|
||||
},
|
||||
...
|
||||
}, {
|
||||
.chan_nr = 8,
|
||||
.led_current = 50,
|
||||
.max_current = 130,
|
||||
}
|
||||
};
|
||||
|
||||
static int lp5523_setup(void)
|
||||
{
|
||||
/* Setup HW resources */
|
||||
}
|
||||
|
||||
static void lp5523_release(void)
|
||||
{
|
||||
/* Release HW resources */
|
||||
}
|
||||
|
||||
static void lp5523_enable(bool state)
|
||||
{
|
||||
/* Control chip enable signal */
|
||||
}
|
||||
|
||||
static struct lp5523_platform_data lp5523_platform_data = {
|
||||
.led_config = lp5523_led_config,
|
||||
.num_channels = ARRAY_SIZE(lp5523_led_config),
|
||||
.clock_mode = LP5523_CLOCK_EXT,
|
||||
.setup_resources = lp5523_setup,
|
||||
.release_resources = lp5523_release,
|
||||
.enable = lp5523_enable,
|
||||
};
|
||||
@@ -20,6 +20,15 @@ ip_no_pmtu_disc - BOOLEAN
|
||||
min_pmtu - INTEGER
|
||||
default 562 - minimum discovered Path MTU
|
||||
|
||||
route/max_size - INTEGER
|
||||
Maximum number of routes allowed in the kernel. Increase
|
||||
this when using large numbers of interfaces and/or routes.
|
||||
|
||||
neigh/default/gc_thresh3 - INTEGER
|
||||
Maximum number of neighbor entries allowed. Increase this
|
||||
when using large numbers of interfaces and when communicating
|
||||
with large numbers of directly-connected peers.
|
||||
|
||||
mtu_expires - INTEGER
|
||||
Time, in seconds, that cached PMTU information is kept.
|
||||
|
||||
|
||||
@@ -21,8 +21,8 @@ three rotations, respectively, to balance the tree), with slightly slower
|
||||
To quote Linux Weekly News:
|
||||
|
||||
There are a number of red-black trees in use in the kernel.
|
||||
The anticipatory, deadline, and CFQ I/O schedulers all employ
|
||||
rbtrees to track requests; the packet CD/DVD driver does the same.
|
||||
The deadline and CFQ I/O schedulers employ rbtrees to
|
||||
track requests; the packet CD/DVD driver does the same.
|
||||
The high-resolution timer code uses an rbtree to organize outstanding
|
||||
timer requests. The ext3 filesystem tracks directory entries in a
|
||||
red-black tree. Virtual memory areas (VMAs) are tracked with red-black
|
||||
|
||||
@@ -1,3 +1,50 @@
|
||||
1 Release Date : Thur. May 03, 2010 09:12:45 PST 2009 -
|
||||
(emaild-id:megaraidlinux@lsi.com)
|
||||
Bo Yang
|
||||
|
||||
2 Current Version : 00.00.04.31-rc1
|
||||
3 Older Version : 00.00.04.17.1-rc1
|
||||
|
||||
1. Add the Online Controller Reset (OCR) to the Driver.
|
||||
OCR is the new feature for megaraid_sas driver which
|
||||
will allow the fw to do the chip reset which will not
|
||||
affact the OS behavious.
|
||||
|
||||
To add the OCR support, driver need to do:
|
||||
a). reset the controller chips -- Xscale and Gen2 which
|
||||
will change the function calls and add the reset function
|
||||
related to this two chips.
|
||||
|
||||
b). during the reset, driver will store the pending cmds
|
||||
which not returned by FW to driver's pending queue. Driver
|
||||
will re-issue those pending cmds again to FW after the OCR
|
||||
finished.
|
||||
|
||||
c). In driver's timeout routine, driver will report to
|
||||
OS as reset. Also driver's queue routine will block the
|
||||
cmds until the OCR finished.
|
||||
|
||||
d). in Driver's ISR routine, if driver get the FW state as
|
||||
state change, FW in Failure status and FW support online controller
|
||||
reset (OCR), driver will start to do the controller reset.
|
||||
|
||||
e). In driver's IOCTL routine, the application cmds will wait for the
|
||||
OCR to finish, then issue the cmds to FW.
|
||||
|
||||
f). Before driver kill adapter, driver will do last chance of
|
||||
OCR to see if driver can bring back the FW.
|
||||
|
||||
2. Add the support update flag to the driver to tell LSI megaraid_sas
|
||||
application which driver will support the device update. So application
|
||||
will not need to do the device update after application add/del the device
|
||||
from the system.
|
||||
3. In driver's timeout routine, driver will do three time reset if fw is in
|
||||
failed state. Driver will kill adapter if can't bring back FW after the
|
||||
this three times reset.
|
||||
4. Add the input parameter max_sectors to 1MB support to our GEN2 controller.
|
||||
customer can use the input paramenter max_sectors to add 1MB support to GEN2
|
||||
controller.
|
||||
|
||||
1 Release Date : Thur. Oct 29, 2009 09:12:45 PST 2009 -
|
||||
(emaild-id:megaraidlinux@lsi.com)
|
||||
Bo Yang
|
||||
|
||||
@@ -28,6 +28,7 @@ show up in /proc/sys/kernel:
|
||||
- core_uses_pid
|
||||
- ctrl-alt-del
|
||||
- dentry-state
|
||||
- dmesg_restrict
|
||||
- domainname
|
||||
- hostname
|
||||
- hotplug
|
||||
@@ -213,6 +214,19 @@ to decide what to do with it.
|
||||
|
||||
==============================================================
|
||||
|
||||
dmesg_restrict:
|
||||
|
||||
This toggle indicates whether unprivileged users are prevented from using
|
||||
dmesg(8) to view messages from the kernel's log buffer. When
|
||||
dmesg_restrict is set to (0) there are no restrictions. When
|
||||
dmesg_restrict is set set to (1), users must have CAP_SYS_ADMIN to use
|
||||
dmesg(8).
|
||||
|
||||
The kernel config option CONFIG_SECURITY_DMESG_RESTRICT sets the default
|
||||
value of dmesg_restrict.
|
||||
|
||||
==============================================================
|
||||
|
||||
domainname & hostname:
|
||||
|
||||
These files can be used to set the NIS/YP domainname and the
|
||||
|
||||
+11
-9
@@ -161,7 +161,7 @@ M: Greg Kroah-Hartman <gregkh@suse.de>
|
||||
L: linux-serial@vger.kernel.org
|
||||
W: http://serial.sourceforge.net
|
||||
S: Maintained
|
||||
T: quilt kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6.git
|
||||
F: drivers/serial/8250*
|
||||
F: include/linux/serial_8250.h
|
||||
|
||||
@@ -945,7 +945,7 @@ M: Magnus Damm <magnus.damm@gmail.com>
|
||||
L: linux-sh@vger.kernel.org
|
||||
W: http://oss.renesas.com
|
||||
Q: http://patchwork.kernel.org/project/linux-sh/list/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/lethal/genesis-2.6.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6.git rmobile-latest
|
||||
S: Supported
|
||||
F: arch/arm/mach-shmobile/
|
||||
F: drivers/sh/
|
||||
@@ -1757,6 +1757,7 @@ L: linux-cris-kernel@axis.com
|
||||
W: http://developer.axis.com
|
||||
S: Maintained
|
||||
F: arch/cris/
|
||||
F: drivers/serial/crisv10.*
|
||||
|
||||
CRYPTO API
|
||||
M: Herbert Xu <herbert@gondor.apana.org.au>
|
||||
@@ -2434,6 +2435,7 @@ F: drivers/net/wan/sdla.c
|
||||
FRAMEBUFFER LAYER
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
W: http://linux-fbdev.sourceforge.net/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/lethal/fbdev-2.6.git
|
||||
S: Orphan
|
||||
F: Documentation/fb/
|
||||
F: drivers/video/fb*
|
||||
@@ -5675,7 +5677,7 @@ S: Maintained
|
||||
|
||||
STAGING SUBSYSTEM
|
||||
M: Greg Kroah-Hartman <gregkh@suse.de>
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-next-2.6.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6.git
|
||||
L: devel@driverdev.osuosl.org
|
||||
S: Maintained
|
||||
F: drivers/staging/
|
||||
@@ -5704,7 +5706,7 @@ M: Paul Mundt <lethal@linux-sh.org>
|
||||
L: linux-sh@vger.kernel.org
|
||||
W: http://www.linux-sh.org
|
||||
Q: http://patchwork.kernel.org/project/linux-sh/list/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6.git sh-latest
|
||||
S: Supported
|
||||
F: Documentation/sh/
|
||||
F: arch/sh/
|
||||
@@ -5909,7 +5911,7 @@ S: Maintained
|
||||
TTY LAYER
|
||||
M: Greg Kroah-Hartman <gregkh@suse.de>
|
||||
S: Maintained
|
||||
T: quilt kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6.git
|
||||
F: drivers/char/tty_*
|
||||
F: drivers/serial/serial_core.c
|
||||
F: include/linux/serial_core.h
|
||||
@@ -6232,7 +6234,7 @@ USB SUBSYSTEM
|
||||
M: Greg Kroah-Hartman <gregkh@suse.de>
|
||||
L: linux-usb@vger.kernel.org
|
||||
W: http://www.linux-usb.org
|
||||
T: quilt kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6.git
|
||||
S: Supported
|
||||
F: Documentation/usb/
|
||||
F: drivers/net/usb/
|
||||
@@ -6597,14 +6599,14 @@ F: drivers/platform/x86
|
||||
|
||||
XEN PCI SUBSYSTEM
|
||||
M: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
L: xen-devel@lists.xensource.com
|
||||
L: xen-devel@lists.xensource.com (moderated for non-subscribers)
|
||||
S: Supported
|
||||
F: arch/x86/pci/*xen*
|
||||
F: drivers/pci/*xen*
|
||||
|
||||
XEN SWIOTLB SUBSYSTEM
|
||||
M: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
L: xen-devel@lists.xensource.com
|
||||
L: xen-devel@lists.xensource.com (moderated for non-subscribers)
|
||||
S: Supported
|
||||
F: arch/x86/xen/*swiotlb*
|
||||
F: drivers/xen/*swiotlb*
|
||||
@@ -6612,7 +6614,7 @@ F: drivers/xen/*swiotlb*
|
||||
XEN HYPERVISOR INTERFACE
|
||||
M: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
|
||||
M: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
L: xen-devel@lists.xen.org
|
||||
L: xen-devel@lists.xensource.com (moderated for non-subscribers)
|
||||
L: virtualization@lists.osdl.org
|
||||
S: Supported
|
||||
F: arch/x86/xen/
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
VERSION = 2
|
||||
PATCHLEVEL = 6
|
||||
SUBLEVEL = 36
|
||||
EXTRAVERSION =
|
||||
SUBLEVEL = 37
|
||||
EXTRAVERSION = -rc2
|
||||
NAME = Flesh-Eating Bats with Fangs
|
||||
|
||||
# *DOCUMENTATION*
|
||||
@@ -204,6 +204,9 @@ ifeq ($(ARCH),x86_64)
|
||||
endif
|
||||
|
||||
# Additional ARCH settings for sparc
|
||||
ifeq ($(ARCH),sparc32)
|
||||
SRCARCH := sparc
|
||||
endif
|
||||
ifeq ($(ARCH),sparc64)
|
||||
SRCARCH := sparc
|
||||
endif
|
||||
|
||||
@@ -42,6 +42,20 @@ config KPROBES
|
||||
for kernel debugging, non-intrusive instrumentation and testing.
|
||||
If in doubt, say "N".
|
||||
|
||||
config JUMP_LABEL
|
||||
bool "Optimize trace point call sites"
|
||||
depends on HAVE_ARCH_JUMP_LABEL
|
||||
help
|
||||
If it is detected that the compiler has support for "asm goto",
|
||||
the kernel will compile trace point locations with just a
|
||||
nop instruction. When trace points are enabled, the nop will
|
||||
be converted to a jump to the trace function. This technique
|
||||
lowers overhead and stress on the branch prediction of the
|
||||
processor.
|
||||
|
||||
On i386, options added to the compiler flags may increase
|
||||
the size of the kernel slightly.
|
||||
|
||||
config OPTPROBES
|
||||
def_bool y
|
||||
depends on KPROBES && HAVE_OPTPROBES
|
||||
|
||||
+26
-14
@@ -6,7 +6,7 @@ config ARM
|
||||
select HAVE_MEMBLOCK
|
||||
select RTC_LIB
|
||||
select SYS_SUPPORTS_APM_EMULATION
|
||||
select GENERIC_ATOMIC64 if (!CPU_32v6K)
|
||||
select GENERIC_ATOMIC64 if (!CPU_32v6K || !AEABI)
|
||||
select HAVE_OPROFILE if (HAVE_PERF_EVENTS)
|
||||
select HAVE_ARCH_KGDB
|
||||
select HAVE_KPROBES if (!XIP_KERNEL)
|
||||
@@ -646,7 +646,7 @@ config ARCH_S3C2410
|
||||
select ARCH_HAS_CPUFREQ
|
||||
select HAVE_CLK
|
||||
select ARCH_USES_GETTIMEOFFSET
|
||||
select HAVE_S3C2410_I2C
|
||||
select HAVE_S3C2410_I2C if I2C
|
||||
help
|
||||
Samsung S3C2410X CPU based systems, such as the Simtec Electronics
|
||||
BAST (<http://www.simtec.co.uk/products/EB110ITX/>), the IPAQ 1940 or
|
||||
@@ -676,8 +676,8 @@ config ARCH_S3C64XX
|
||||
select S3C_DEV_NAND
|
||||
select USB_ARCH_HAS_OHCI
|
||||
select SAMSUNG_GPIOLIB_4BIT
|
||||
select HAVE_S3C2410_I2C
|
||||
select HAVE_S3C2410_WATCHDOG
|
||||
select HAVE_S3C2410_I2C if I2C
|
||||
select HAVE_S3C2410_WATCHDOG if WATCHDOG
|
||||
help
|
||||
Samsung S3C64XX series based systems
|
||||
|
||||
@@ -686,10 +686,10 @@ config ARCH_S5P64X0
|
||||
select CPU_V6
|
||||
select GENERIC_GPIO
|
||||
select HAVE_CLK
|
||||
select HAVE_S3C2410_WATCHDOG
|
||||
select HAVE_S3C2410_WATCHDOG if WATCHDOG
|
||||
select ARCH_USES_GETTIMEOFFSET
|
||||
select HAVE_S3C2410_I2C
|
||||
select HAVE_S3C_RTC
|
||||
select HAVE_S3C2410_I2C if I2C
|
||||
select HAVE_S3C_RTC if RTC_CLASS
|
||||
help
|
||||
Samsung S5P64X0 CPU based systems, such as the Samsung SMDK6440,
|
||||
SMDK6450.
|
||||
@@ -700,7 +700,7 @@ config ARCH_S5P6442
|
||||
select GENERIC_GPIO
|
||||
select HAVE_CLK
|
||||
select ARCH_USES_GETTIMEOFFSET
|
||||
select HAVE_S3C2410_WATCHDOG
|
||||
select HAVE_S3C2410_WATCHDOG if WATCHDOG
|
||||
help
|
||||
Samsung S5P6442 CPU based systems
|
||||
|
||||
@@ -711,31 +711,37 @@ config ARCH_S5PC100
|
||||
select CPU_V7
|
||||
select ARM_L1_CACHE_SHIFT_6
|
||||
select ARCH_USES_GETTIMEOFFSET
|
||||
select HAVE_S3C2410_I2C
|
||||
select HAVE_S3C_RTC
|
||||
select HAVE_S3C2410_WATCHDOG
|
||||
select HAVE_S3C2410_I2C if I2C
|
||||
select HAVE_S3C_RTC if RTC_CLASS
|
||||
select HAVE_S3C2410_WATCHDOG if WATCHDOG
|
||||
help
|
||||
Samsung S5PC100 series based systems
|
||||
|
||||
config ARCH_S5PV210
|
||||
bool "Samsung S5PV210/S5PC110"
|
||||
select CPU_V7
|
||||
select ARCH_SPARSEMEM_ENABLE
|
||||
select GENERIC_GPIO
|
||||
select HAVE_CLK
|
||||
select ARM_L1_CACHE_SHIFT_6
|
||||
select ARCH_HAS_CPUFREQ
|
||||
select ARCH_USES_GETTIMEOFFSET
|
||||
select HAVE_S3C2410_I2C
|
||||
select HAVE_S3C_RTC
|
||||
select HAVE_S3C2410_WATCHDOG
|
||||
select HAVE_S3C2410_I2C if I2C
|
||||
select HAVE_S3C_RTC if RTC_CLASS
|
||||
select HAVE_S3C2410_WATCHDOG if WATCHDOG
|
||||
help
|
||||
Samsung S5PV210/S5PC110 series based systems
|
||||
|
||||
config ARCH_S5PV310
|
||||
bool "Samsung S5PV310/S5PC210"
|
||||
select CPU_V7
|
||||
select ARCH_SPARSEMEM_ENABLE
|
||||
select GENERIC_GPIO
|
||||
select HAVE_CLK
|
||||
select GENERIC_CLOCKEVENTS
|
||||
select HAVE_S3C_RTC if RTC_CLASS
|
||||
select HAVE_S3C2410_I2C if I2C
|
||||
select HAVE_S3C2410_WATCHDOG if WATCHDOG
|
||||
help
|
||||
Samsung S5PV310 series based systems
|
||||
|
||||
@@ -1662,6 +1668,12 @@ if ARCH_HAS_CPUFREQ
|
||||
|
||||
source "drivers/cpufreq/Kconfig"
|
||||
|
||||
config CPU_FREQ_IMX
|
||||
tristate "CPUfreq driver for i.MX CPUs"
|
||||
depends on ARCH_MXC && CPU_FREQ
|
||||
help
|
||||
This enables the CPUfreq driver for i.MX CPUs.
|
||||
|
||||
config CPU_FREQ_SA1100
|
||||
bool
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user