mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2024-08-23 01:10:04 +00:00
Merge remote branch 'rmk/for-linus' into for-linus
* rmk/for-linus: (1557 commits) ARM: 6806/1: irq: introduce entry and exit functions for chained handlers ARM: 6781/1: Thumb-2: Work around buggy Thumb-2 short branch relocations in gas ARM: 6747/1: P2V: Thumb2 support ARM: 6798/1: aout-core: zero thread debug registers in a.out core dump ARM: 6796/1: Footbridge: Fix I/O mappings for NOMMU mode ARM: 6784/1: errata: no automatic Store Buffer drain on Cortex-A9 ARM: 6772/1: errata: possible fault MMU translations following an ASID switch ARM: 6776/1: mach-ux500: activate fix for errata 753970 ARM: 6794/1: SPEAr: Append UL to device address macros. ARM: 6793/1: SPEAr: Remove unused *_SIZE macros from spear*.h files ARM: 6792/1: SPEAr: Replace SIZE macro's with SZ_4K macros ARM: 6791/1: SPEAr3xx: Declare device structures after shirq code ARM: 6790/1: SPEAr: Clock Framework: Rename usbd clock and align apb_clk entry ARM: 6789/1: SPEAr3xx: Rename sdio to sdhci ARM: 6788/1: SPEAr: Include mach/hardware.h instead of mach/spear.h ARM: 6787/1: SPEAr: Reorder #includes in .h & .c files. ARM: 6681/1: SPEAr: add debugfs support to clk API ARM: 6703/1: SPEAr: update clk API support ARM: 6679/1: SPEAr: make clk API functions more generic ARM: 6737/1: SPEAr: formalized timer support ... Conflicts: arch/arm/mach-msm/board-msm7x27.c arch/arm/mach-msm/board-msm7x30.c arch/arm/mach-msm/board-qsd8x50.c arch/arm/mach-msm/board-sapphire.c arch/arm/mach-msm/include/mach/memory.h
This commit is contained in:
commit
92c260f755
1728 changed files with 26211 additions and 14185 deletions
1
.gitignore
vendored
1
.gitignore
vendored
|
@ -28,6 +28,7 @@ modules.builtin
|
|||
*.gz
|
||||
*.bz2
|
||||
*.lzma
|
||||
*.xz
|
||||
*.lzo
|
||||
*.patch
|
||||
*.gcno
|
||||
|
|
1
.mailmap
1
.mailmap
|
@ -23,6 +23,7 @@ Andy Adamson <andros@citi.umich.edu>
|
|||
Arnaud Patard <arnaud.patard@rtp-net.org>
|
||||
Arnd Bergmann <arnd@arndb.de>
|
||||
Axel Dyks <xl@xlsigned.net>
|
||||
Axel Lin <axel.lin@gmail.com>
|
||||
Ben Gardner <bgardner@wabtec.com>
|
||||
Ben M Cahill <ben.m.cahill@intel.com>
|
||||
Björn Steinbrink <B.Steinbrink@gmx.de>
|
||||
|
|
25
Documentation/ABI/testing/sysfs-platform-at91
Normal file
25
Documentation/ABI/testing/sysfs-platform-at91
Normal file
|
@ -0,0 +1,25 @@
|
|||
What: /sys/devices/platform/at91_can/net/<iface>/mb0_id
|
||||
Date: January 2011
|
||||
KernelVersion: 2.6.38
|
||||
Contact: Marc Kleine-Budde <kernel@pengutronix.de>
|
||||
Description:
|
||||
Value representing the can_id of mailbox 0.
|
||||
|
||||
Default: 0x7ff (standard frame)
|
||||
|
||||
Due to a chip bug (errata 50.2.6.3 & 50.3.5.3 in
|
||||
"AT91SAM9263 Preliminary 6249H-ATARM-27-Jul-09") the
|
||||
contents of mailbox 0 may be send under certain
|
||||
conditions (even if disabled or in rx mode).
|
||||
|
||||
The workaround in the errata suggests not to use the
|
||||
mailbox and load it with an unused identifier.
|
||||
|
||||
In order to use an extended can_id add the
|
||||
CAN_EFF_FLAG (0x80000000U) to the can_id. Example:
|
||||
|
||||
- standard id 0x7ff:
|
||||
echo 0x7ff > /sys/class/net/can0/mb0_id
|
||||
|
||||
- extended id 0x1fffffff:
|
||||
echo 0x9fffffff > /sys/class/net/can0/mb0_id
|
|
@ -217,8 +217,8 @@ X!Isound/sound_firmware.c
|
|||
<chapter id="uart16x50">
|
||||
<title>16x50 UART Driver</title>
|
||||
!Iinclude/linux/serial_core.h
|
||||
!Edrivers/serial/serial_core.c
|
||||
!Edrivers/serial/8250.c
|
||||
!Edrivers/tty/serial/serial_core.c
|
||||
!Edrivers/tty/serial/8250.c
|
||||
</chapter>
|
||||
|
||||
<chapter id="fbdev">
|
||||
|
|
|
@ -73,8 +73,8 @@
|
|||
services.
|
||||
</para>
|
||||
<para>
|
||||
The core of every DRM driver is struct drm_device. Drivers
|
||||
will typically statically initialize a drm_device structure,
|
||||
The core of every DRM driver is struct drm_driver. Drivers
|
||||
will typically statically initialize a drm_driver structure,
|
||||
then pass it to drm_init() at load time.
|
||||
</para>
|
||||
|
||||
|
@ -84,7 +84,7 @@
|
|||
<title>Driver initialization</title>
|
||||
<para>
|
||||
Before calling the DRM initialization routines, the driver must
|
||||
first create and fill out a struct drm_device structure.
|
||||
first create and fill out a struct drm_driver structure.
|
||||
</para>
|
||||
<programlisting>
|
||||
static struct drm_driver driver = {
|
||||
|
|
|
@ -82,6 +82,11 @@
|
|||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="fs_events">
|
||||
<title>Events based on file descriptors</title>
|
||||
!Efs/eventfd.c
|
||||
</chapter>
|
||||
|
||||
<chapter id="sysfs">
|
||||
<title>The Filesystem for Exporting Kernel Objects</title>
|
||||
!Efs/sysfs/file.c
|
||||
|
|
8
Documentation/arm/SH-Mobile/Makefile
Normal file
8
Documentation/arm/SH-Mobile/Makefile
Normal file
|
@ -0,0 +1,8 @@
|
|||
BIN := vrl4
|
||||
|
||||
.PHONY: all
|
||||
all: $(BIN)
|
||||
|
||||
.PHONY: clean
|
||||
clean:
|
||||
rm -f *.o $(BIN)
|
169
Documentation/arm/SH-Mobile/vrl4.c
Normal file
169
Documentation/arm/SH-Mobile/vrl4.c
Normal file
|
@ -0,0 +1,169 @@
|
|||
/*
|
||||
* vrl4 format generator
|
||||
*
|
||||
* Copyright (C) 2010 Simon Horman
|
||||
*
|
||||
* This file is subject to the terms and conditions of the GNU General Public
|
||||
* License. See the file "COPYING" in the main directory of this archive
|
||||
* for more details.
|
||||
*/
|
||||
|
||||
/*
|
||||
* usage: vrl4 < zImage > out
|
||||
* dd if=out of=/dev/sdx bs=512 seek=1 # Write the image to sector 1
|
||||
*
|
||||
* Reads a zImage from stdin and writes a vrl4 image to stdout.
|
||||
* In practice this means writing a padded vrl4 header to stdout followed
|
||||
* by the zImage.
|
||||
*
|
||||
* The padding places the zImage at ALIGN bytes into the output.
|
||||
* The vrl4 uses ALIGN + START_BASE as the start_address.
|
||||
* This is where the mask ROM will jump to after verifying the header.
|
||||
*
|
||||
* The header sets copy_size to min(sizeof(zImage), MAX_BOOT_PROG_LEN) + ALIGN.
|
||||
* That is, the mask ROM will load the padded header (ALIGN bytes)
|
||||
* And then MAX_BOOT_PROG_LEN bytes of the image, or the entire image,
|
||||
* whichever is smaller.
|
||||
*
|
||||
* The zImage is not modified in any way.
|
||||
*/
|
||||
|
||||
#define _BSD_SOURCE
|
||||
#include <endian.h>
|
||||
#include <unistd.h>
|
||||
#include <stdint.h>
|
||||
#include <stdio.h>
|
||||
#include <errno.h>
|
||||
|
||||
struct hdr {
|
||||
uint32_t magic1;
|
||||
uint32_t reserved1;
|
||||
uint32_t magic2;
|
||||
uint32_t reserved2;
|
||||
uint16_t copy_size;
|
||||
uint16_t boot_options;
|
||||
uint32_t reserved3;
|
||||
uint32_t start_address;
|
||||
uint32_t reserved4;
|
||||
uint32_t reserved5;
|
||||
char reserved6[308];
|
||||
};
|
||||
|
||||
#define DECLARE_HDR(h) \
|
||||
struct hdr (h) = { \
|
||||
.magic1 = htole32(0xea000000), \
|
||||
.reserved1 = htole32(0x56), \
|
||||
.magic2 = htole32(0xe59ff008), \
|
||||
.reserved3 = htole16(0x1) }
|
||||
|
||||
/* Align to 512 bytes, the MMCIF sector size */
|
||||
#define ALIGN_BITS 9
|
||||
#define ALIGN (1 << ALIGN_BITS)
|
||||
|
||||
#define START_BASE 0xe55b0000
|
||||
|
||||
/*
|
||||
* With an alignment of 512 the header uses the first sector.
|
||||
* There is a 128 sector (64kbyte) limit on the data loaded by the mask ROM.
|
||||
* So there are 127 sectors left for the boot programme. But in practice
|
||||
* Only a small portion of a zImage is needed, 16 sectors should be more
|
||||
* than enough.
|
||||
*
|
||||
* Note that this sets how much of the zImage is copied by the mask ROM.
|
||||
* The entire zImage is present after the header and is loaded
|
||||
* by the code in the boot program (which is the first portion of the zImage).
|
||||
*/
|
||||
#define MAX_BOOT_PROG_LEN (16 * 512)
|
||||
|
||||
#define ROUND_UP(x) ((x + ALIGN - 1) & ~(ALIGN - 1))
|
||||
|
||||
ssize_t do_read(int fd, void *buf, size_t count)
|
||||
{
|
||||
size_t offset = 0;
|
||||
ssize_t l;
|
||||
|
||||
while (offset < count) {
|
||||
l = read(fd, buf + offset, count - offset);
|
||||
if (!l)
|
||||
break;
|
||||
if (l < 0) {
|
||||
if (errno == EAGAIN || errno == EWOULDBLOCK)
|
||||
continue;
|
||||
perror("read");
|
||||
return -1;
|
||||
}
|
||||
offset += l;
|
||||
}
|
||||
|
||||
return offset;
|
||||
}
|
||||
|
||||
ssize_t do_write(int fd, const void *buf, size_t count)
|
||||
{
|
||||
size_t offset = 0;
|
||||
ssize_t l;
|
||||
|
||||
while (offset < count) {
|
||||
l = write(fd, buf + offset, count - offset);
|
||||
if (l < 0) {
|
||||
if (errno == EAGAIN || errno == EWOULDBLOCK)
|
||||
continue;
|
||||
perror("write");
|
||||
return -1;
|
||||
}
|
||||
offset += l;
|
||||
}
|
||||
|
||||
return offset;
|
||||
}
|
||||
|
||||
ssize_t write_zero(int fd, size_t len)
|
||||
{
|
||||
size_t i = len;
|
||||
|
||||
while (i--) {
|
||||
const char x = 0;
|
||||
if (do_write(fd, &x, 1) < 0)
|
||||
return -1;
|
||||
}
|
||||
|
||||
return len;
|
||||
}
|
||||
|
||||
int main(void)
|
||||
{
|
||||
DECLARE_HDR(hdr);
|
||||
char boot_program[MAX_BOOT_PROG_LEN];
|
||||
size_t aligned_hdr_len, alligned_prog_len;
|
||||
ssize_t prog_len;
|
||||
|
||||
prog_len = do_read(0, boot_program, sizeof(boot_program));
|
||||
if (prog_len <= 0)
|
||||
return -1;
|
||||
|
||||
aligned_hdr_len = ROUND_UP(sizeof(hdr));
|
||||
hdr.start_address = htole32(START_BASE + aligned_hdr_len);
|
||||
alligned_prog_len = ROUND_UP(prog_len);
|
||||
hdr.copy_size = htole16(aligned_hdr_len + alligned_prog_len);
|
||||
|
||||
if (do_write(1, &hdr, sizeof(hdr)) < 0)
|
||||
return -1;
|
||||
if (write_zero(1, aligned_hdr_len - sizeof(hdr)) < 0)
|
||||
return -1;
|
||||
|
||||
if (do_write(1, boot_program, prog_len) < 0)
|
||||
return 1;
|
||||
|
||||
/* Write out the rest of the kernel */
|
||||
while (1) {
|
||||
prog_len = do_read(0, boot_program, sizeof(boot_program));
|
||||
if (prog_len < 0)
|
||||
return 1;
|
||||
if (prog_len == 0)
|
||||
break;
|
||||
if (do_write(1, boot_program, prog_len) < 0)
|
||||
return 1;
|
||||
}
|
||||
|
||||
return 0;
|
||||
}
|
29
Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt
Normal file
29
Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt
Normal file
|
@ -0,0 +1,29 @@
|
|||
ROM-able zImage boot from MMC
|
||||
-----------------------------
|
||||
|
||||
An ROM-able zImage compiled with ZBOOT_ROM_MMCIF may be written to MMC and
|
||||
SuperH Mobile ARM will to boot directly from the MMCIF hardware block.
|
||||
|
||||
This is achieved by the mask ROM loading the first portion of the image into
|
||||
MERAM and then jumping to it. This portion contains loader code which
|
||||
copies the entire image to SDRAM and jumps to it. From there the zImage
|
||||
boot code proceeds as normal, uncompressing the image into its final
|
||||
location and then jumping to it.
|
||||
|
||||
This code has been tested on an AP4EB board using the developer 1A eMMC
|
||||
boot mode which is configured using the following jumper settings.
|
||||
The board used for testing required a patched mask ROM in order for
|
||||
this mode to function.
|
||||
|
||||
8 7 6 5 4 3 2 1
|
||||
x|x|x|x|x| |x|
|
||||
S4 -+-+-+-+-+-+-+-
|
||||
| | | | |x| |x on
|
||||
|
||||
The zImage must be written to the MMC card at sector 1 (512 bytes) in
|
||||
vrl4 format. A utility vrl4 is supplied to accomplish this.
|
||||
|
||||
e.g.
|
||||
vrl4 < zImage | dd of=/dev/sdX bs=512 seek=1
|
||||
|
||||
A dual-voltage MMC 4.0 card was used for testing.
|
|
@ -13,7 +13,6 @@ Table of Contents
|
|||
|
||||
I - Introduction
|
||||
1) Entry point for arch/powerpc
|
||||
2) Board support
|
||||
|
||||
II - The DT block format
|
||||
1) Header
|
||||
|
@ -41,13 +40,6 @@ Table of Contents
|
|||
VI - System-on-a-chip devices and nodes
|
||||
1) Defining child nodes of an SOC
|
||||
2) Representing devices without a current OF specification
|
||||
a) PHY nodes
|
||||
b) Interrupt controllers
|
||||
c) 4xx/Axon EMAC ethernet nodes
|
||||
d) Xilinx IP cores
|
||||
e) USB EHCI controllers
|
||||
f) MDIO on GPIOs
|
||||
g) SPI busses
|
||||
|
||||
VII - Specifying interrupt information for devices
|
||||
1) interrupts property
|
||||
|
@ -123,7 +115,7 @@ Revision Information
|
|||
I - Introduction
|
||||
================
|
||||
|
||||
During the recent development of the Linux/ppc64 kernel, and more
|
||||
During the development of the Linux/ppc64 kernel, and more
|
||||
specifically, the addition of new platform types outside of the old
|
||||
IBM pSeries/iSeries pair, it was decided to enforce some strict rules
|
||||
regarding the kernel entry and bootloader <-> kernel interfaces, in
|
||||
|
@ -146,7 +138,7 @@ section III, but, for example, the kernel does not require you to
|
|||
create a node for every PCI device in the system. It is a requirement
|
||||
to have a node for PCI host bridges in order to provide interrupt
|
||||
routing informations and memory/IO ranges, among others. It is also
|
||||
recommended to define nodes for on chip devices and other busses that
|
||||
recommended to define nodes for on chip devices and other buses that
|
||||
don't specifically fit in an existing OF specification. This creates a
|
||||
great flexibility in the way the kernel can then probe those and match
|
||||
drivers to device, without having to hard code all sorts of tables. It
|
||||
|
@ -158,7 +150,7 @@ it with special cases.
|
|||
1) Entry point for arch/powerpc
|
||||
-------------------------------
|
||||
|
||||
There is one and one single entry point to the kernel, at the start
|
||||
There is one single entry point to the kernel, at the start
|
||||
of the kernel image. That entry point supports two calling
|
||||
conventions:
|
||||
|
||||
|
@ -210,12 +202,6 @@ it with special cases.
|
|||
with all CPUs. The way to do that with method b) will be
|
||||
described in a later revision of this document.
|
||||
|
||||
|
||||
2) Board support
|
||||
----------------
|
||||
|
||||
64-bit kernels:
|
||||
|
||||
Board supports (platforms) are not exclusive config options. An
|
||||
arbitrary set of board supports can be built in a single kernel
|
||||
image. The kernel will "know" what set of functions to use for a
|
||||
|
@ -234,48 +220,11 @@ it with special cases.
|
|||
containing the various callbacks that the generic code will
|
||||
use to get to your platform specific code
|
||||
|
||||
c) Add a reference to your "ppc_md" structure in the
|
||||
"machines" table in arch/powerpc/kernel/setup_64.c if you are
|
||||
a 64-bit platform.
|
||||
|
||||
d) request and get assigned a platform number (see PLATFORM_*
|
||||
constants in arch/powerpc/include/asm/processor.h
|
||||
|
||||
32-bit embedded kernels:
|
||||
|
||||
Currently, board support is essentially an exclusive config option.
|
||||
The kernel is configured for a single platform. Part of the reason
|
||||
for this is to keep kernels on embedded systems small and efficient;
|
||||
part of this is due to the fact the code is already that way. In the
|
||||
future, a kernel may support multiple platforms, but only if the
|
||||
A kernel image may support multiple platforms, but only if the
|
||||
platforms feature the same core architecture. A single kernel build
|
||||
cannot support both configurations with Book E and configurations
|
||||
with classic Powerpc architectures.
|
||||
|
||||
32-bit embedded platforms that are moved into arch/powerpc using a
|
||||
flattened device tree should adopt the merged tree practice of
|
||||
setting ppc_md up dynamically, even though the kernel is currently
|
||||
built with support for only a single platform at a time. This allows
|
||||
unification of the setup code, and will make it easier to go to a
|
||||
multiple-platform-support model in the future.
|
||||
|
||||
NOTE: I believe the above will be true once Ben's done with the merge
|
||||
of the boot sequences.... someone speak up if this is wrong!
|
||||
|
||||
To add a 32-bit embedded platform support, follow the instructions
|
||||
for 64-bit platforms above, with the exception that the Kconfig
|
||||
option should be set up such that the kernel builds exclusively for
|
||||
the platform selected. The processor type for the platform should
|
||||
enable another config option to select the specific board
|
||||
supported.
|
||||
|
||||
NOTE: If Ben doesn't merge the setup files, may need to change this to
|
||||
point to setup_32.c
|
||||
|
||||
|
||||
I will describe later the boot process and various callbacks that
|
||||
your platform should implement.
|
||||
|
||||
|
||||
II - The DT block format
|
||||
========================
|
||||
|
@ -300,8 +249,8 @@ the block to RAM before passing it to the kernel.
|
|||
1) Header
|
||||
---------
|
||||
|
||||
The kernel is entered with r3 pointing to an area of memory that is
|
||||
roughly described in arch/powerpc/include/asm/prom.h by the structure
|
||||
The kernel is passed the physical address pointing to an area of memory
|
||||
that is roughly described in include/linux/of_fdt.h by the structure
|
||||
boot_param_header:
|
||||
|
||||
struct boot_param_header {
|
||||
|
@ -339,7 +288,7 @@ struct boot_param_header {
|
|||
All values in this header are in big endian format, the various
|
||||
fields in this header are defined more precisely below. All
|
||||
"offset" values are in bytes from the start of the header; that is
|
||||
from the value of r3.
|
||||
from the physical base address of the device tree block.
|
||||
|
||||
- magic
|
||||
|
||||
|
@ -437,7 +386,7 @@ struct boot_param_header {
|
|||
|
||||
|
||||
------------------------------
|
||||
r3 -> | struct boot_param_header |
|
||||
base -> | struct boot_param_header |
|
||||
------------------------------
|
||||
| (alignment gap) (*) |
|
||||
------------------------------
|
||||
|
@ -457,7 +406,7 @@ struct boot_param_header {
|
|||
-----> ------------------------------
|
||||
|
|
||||
|
|
||||
--- (r3 + totalsize)
|
||||
--- (base + totalsize)
|
||||
|
||||
(*) The alignment gaps are not necessarily present; their presence
|
||||
and size are dependent on the various alignment requirements of
|
||||
|
@ -500,7 +449,7 @@ the device-tree structure. It is typically used to represent "path" in
|
|||
the device-tree. More details about the actual format of these will be
|
||||
below.
|
||||
|
||||
The kernel powerpc generic code does not make any formal use of the
|
||||
The kernel generic code does not make any formal use of the
|
||||
unit address (though some board support code may do) so the only real
|
||||
requirement here for the unit address is to ensure uniqueness of
|
||||
the node unit name at a given level of the tree. Nodes with no notion
|
||||
|
@ -518,20 +467,21 @@ path to the root node is "/".
|
|||
|
||||
Every node which actually represents an actual device (that is, a node
|
||||
which isn't only a virtual "container" for more nodes, like "/cpus"
|
||||
is) is also required to have a "device_type" property indicating the
|
||||
type of node .
|
||||
is) is also required to have a "compatible" property indicating the
|
||||
specific hardware and an optional list of devices it is fully
|
||||
backwards compatible with.
|
||||
|
||||
Finally, every node that can be referenced from a property in another
|
||||
node is required to have a "linux,phandle" property. Real open
|
||||
firmware implementations provide a unique "phandle" value for every
|
||||
node that the "prom_init()" trampoline code turns into
|
||||
"linux,phandle" properties. However, this is made optional if the
|
||||
flattened device tree is used directly. An example of a node
|
||||
node is required to have either a "phandle" or a "linux,phandle"
|
||||
property. Real Open Firmware implementations provide a unique
|
||||
"phandle" value for every node that the "prom_init()" trampoline code
|
||||
turns into "linux,phandle" properties. However, this is made optional
|
||||
if the flattened device tree is used directly. An example of a node
|
||||
referencing another node via "phandle" is when laying out the
|
||||
interrupt tree which will be described in a further version of this
|
||||
document.
|
||||
|
||||
This "linux, phandle" property is a 32-bit value that uniquely
|
||||
The "phandle" property is a 32-bit value that uniquely
|
||||
identifies a node. You are free to use whatever values or system of
|
||||
values, internal pointers, or whatever to generate these, the only
|
||||
requirement is that every node for which you provide that property has
|
||||
|
@ -694,7 +644,7 @@ made of 3 cells, the bottom two containing the actual address itself
|
|||
while the top cell contains address space indication, flags, and pci
|
||||
bus & device numbers.
|
||||
|
||||
For busses that support dynamic allocation, it's the accepted practice
|
||||
For buses that support dynamic allocation, it's the accepted practice
|
||||
to then not provide the address in "reg" (keep it 0) though while
|
||||
providing a flag indicating the address is dynamically allocated, and
|
||||
then, to provide a separate "assigned-addresses" property that
|
||||
|
@ -711,7 +661,7 @@ prom_parse.c file of the recent kernels for your bus type.
|
|||
The "reg" property only defines addresses and sizes (if #size-cells is
|
||||
non-0) within a given bus. In order to translate addresses upward
|
||||
(that is into parent bus addresses, and possibly into CPU physical
|
||||
addresses), all busses must contain a "ranges" property. If the
|
||||
addresses), all buses must contain a "ranges" property. If the
|
||||
"ranges" property is missing at a given level, it's assumed that
|
||||
translation isn't possible, i.e., the registers are not visible on the
|
||||
parent bus. The format of the "ranges" property for a bus is a list
|
||||
|
@ -727,9 +677,9 @@ example, for a PCI host controller, that would be a CPU address. For a
|
|||
PCI<->ISA bridge, that would be a PCI address. It defines the base
|
||||
address in the parent bus where the beginning of that range is mapped.
|
||||
|
||||
For a new 64-bit powerpc board, I recommend either the 2/2 format or
|
||||
For new 64-bit board support, I recommend either the 2/2 format or
|
||||
Apple's 2/1 format which is slightly more compact since sizes usually
|
||||
fit in a single 32-bit word. New 32-bit powerpc boards should use a
|
||||
fit in a single 32-bit word. New 32-bit board support should use a
|
||||
1/1 format, unless the processor supports physical addresses greater
|
||||
than 32-bits, in which case a 2/1 format is recommended.
|
||||
|
||||
|
@ -754,7 +704,7 @@ of their actual names.
|
|||
While earlier users of Open Firmware like OldWorld macintoshes tended
|
||||
to use the actual device name for the "name" property, it's nowadays
|
||||
considered a good practice to use a name that is closer to the device
|
||||
class (often equal to device_type). For example, nowadays, ethernet
|
||||
class (often equal to device_type). For example, nowadays, Ethernet
|
||||
controllers are named "ethernet", an additional "model" property
|
||||
defining precisely the chip type/model, and "compatible" property
|
||||
defining the family in case a single driver can driver more than one
|
||||
|
@ -772,7 +722,7 @@ is present).
|
|||
4) Note about node and property names and character set
|
||||
-------------------------------------------------------
|
||||
|
||||
While open firmware provides more flexible usage of 8859-1, this
|
||||
While Open Firmware provides more flexible usage of 8859-1, this
|
||||
specification enforces more strict rules. Nodes and properties should
|
||||
be comprised only of ASCII characters 'a' to 'z', '0' to
|
||||
'9', ',', '.', '_', '+', '#', '?', and '-'. Node names additionally
|
||||
|
@ -792,7 +742,7 @@ address which can extend beyond that limit.
|
|||
--------------------------------
|
||||
These are all that are currently required. However, it is strongly
|
||||
recommended that you expose PCI host bridges as documented in the
|
||||
PCI binding to open firmware, and your interrupt tree as documented
|
||||
PCI binding to Open Firmware, and your interrupt tree as documented
|
||||
in OF interrupt tree specification.
|
||||
|
||||
a) The root node
|
||||
|
@ -802,20 +752,12 @@ address which can extend beyond that limit.
|
|||
- model : this is your board name/model
|
||||
- #address-cells : address representation for "root" devices
|
||||
- #size-cells: the size representation for "root" devices
|
||||
- device_type : This property shouldn't be necessary. However, if
|
||||
you decide to create a device_type for your root node, make sure it
|
||||
is _not_ "chrp" unless your platform is a pSeries or PAPR compliant
|
||||
one for 64-bit, or a CHRP-type machine for 32-bit as this will
|
||||
matched by the kernel this way.
|
||||
|
||||
Additionally, some recommended properties are:
|
||||
|
||||
- compatible : the board "family" generally finds its way here,
|
||||
for example, if you have 2 board models with a similar layout,
|
||||
that typically get driven by the same platform code in the
|
||||
kernel, you would use a different "model" property but put a
|
||||
value in "compatible". The kernel doesn't directly use that
|
||||
value but it is generally useful.
|
||||
kernel, you would specify the exact board model in the
|
||||
compatible property followed by an entry that represents the SoC
|
||||
model.
|
||||
|
||||
The root node is also generally where you add additional properties
|
||||
specific to your board like the serial number if any, that sort of
|
||||
|
@ -841,8 +783,11 @@ address which can extend beyond that limit.
|
|||
|
||||
So under /cpus, you are supposed to create a node for every CPU on
|
||||
the machine. There is no specific restriction on the name of the
|
||||
CPU, though It's common practice to call it PowerPC,<name>. For
|
||||
CPU, though it's common to call it <architecture>,<core>. For
|
||||
example, Apple uses PowerPC,G5 while IBM uses PowerPC,970FX.
|
||||
However, the Generic Names convention suggests that it would be
|
||||
better to simply use 'cpu' for each cpu node and use the compatible
|
||||
property to identify the specific cpu core.
|
||||
|
||||
Required properties:
|
||||
|
||||
|
@ -923,7 +868,7 @@ compatibility.
|
|||
|
||||
e) The /chosen node
|
||||
|
||||
This node is a bit "special". Normally, that's where open firmware
|
||||
This node is a bit "special". Normally, that's where Open Firmware
|
||||
puts some variable environment information, like the arguments, or
|
||||
the default input/output devices.
|
||||
|
||||
|
@ -940,11 +885,7 @@ compatibility.
|
|||
console device if any. Typically, if you have serial devices on
|
||||
your board, you may want to put the full path to the one set as
|
||||
the default console in the firmware here, for the kernel to pick
|
||||
it up as its own default console. If you look at the function
|
||||
set_preferred_console() in arch/ppc64/kernel/setup.c, you'll see
|
||||
that the kernel tries to find out the default console and has
|
||||
knowledge of various types like 8250 serial ports. You may want
|
||||
to extend this function to add your own.
|
||||
it up as its own default console.
|
||||
|
||||
Note that u-boot creates and fills in the chosen node for platforms
|
||||
that use it.
|
||||
|
@ -955,23 +896,23 @@ compatibility.
|
|||
|
||||
f) the /soc<SOCname> node
|
||||
|
||||
This node is used to represent a system-on-a-chip (SOC) and must be
|
||||
present if the processor is a SOC. The top-level soc node contains
|
||||
information that is global to all devices on the SOC. The node name
|
||||
should contain a unit address for the SOC, which is the base address
|
||||
of the memory-mapped register set for the SOC. The name of an soc
|
||||
This node is used to represent a system-on-a-chip (SoC) and must be
|
||||
present if the processor is a SoC. The top-level soc node contains
|
||||
information that is global to all devices on the SoC. The node name
|
||||
should contain a unit address for the SoC, which is the base address
|
||||
of the memory-mapped register set for the SoC. The name of an SoC
|
||||
node should start with "soc", and the remainder of the name should
|
||||
represent the part number for the soc. For example, the MPC8540's
|
||||
soc node would be called "soc8540".
|
||||
|
||||
Required properties:
|
||||
|
||||
- device_type : Should be "soc"
|
||||
- ranges : Should be defined as specified in 1) to describe the
|
||||
translation of SOC addresses for memory mapped SOC registers.
|
||||
- bus-frequency: Contains the bus frequency for the SOC node.
|
||||
translation of SoC addresses for memory mapped SoC registers.
|
||||
- bus-frequency: Contains the bus frequency for the SoC node.
|
||||
Typically, the value of this field is filled in by the boot
|
||||
loader.
|
||||
- compatible : Exact model of the SoC
|
||||
|
||||
|
||||
Recommended properties:
|
||||
|
@ -1155,12 +1096,13 @@ while all this has been defined and implemented.
|
|||
|
||||
- An example of code for iterating nodes & retrieving properties
|
||||
directly from the flattened tree format can be found in the kernel
|
||||
file arch/ppc64/kernel/prom.c, look at scan_flat_dt() function,
|
||||
file drivers/of/fdt.c. Look at the of_scan_flat_dt() function,
|
||||
its usage in early_init_devtree(), and the corresponding various
|
||||
early_init_dt_scan_*() callbacks. That code can be re-used in a
|
||||
GPL bootloader, and as the author of that code, I would be happy
|
||||
to discuss possible free licensing to any vendor who wishes to
|
||||
integrate all or part of this code into a non-GPL bootloader.
|
||||
(reference needed; who is 'I' here? ---gcl Jan 31, 2011)
|
||||
|
||||
|
||||
|
||||
|
@ -1203,18 +1145,19 @@ MPC8540.
|
|||
2) Representing devices without a current OF specification
|
||||
----------------------------------------------------------
|
||||
|
||||
Currently, there are many devices on SOCs that do not have a standard
|
||||
representation pre-defined as part of the open firmware
|
||||
specifications, mainly because the boards that contain these SOCs are
|
||||
not currently booted using open firmware. This section contains
|
||||
descriptions for the SOC devices for which new nodes have been
|
||||
defined; this list will expand as more and more SOC-containing
|
||||
platforms are moved over to use the flattened-device-tree model.
|
||||
Currently, there are many devices on SoCs that do not have a standard
|
||||
representation defined as part of the Open Firmware specifications,
|
||||
mainly because the boards that contain these SoCs are not currently
|
||||
booted using Open Firmware. Binding documentation for new devices
|
||||
should be added to the Documentation/devicetree/bindings directory.
|
||||
That directory will expand as device tree support is added to more and
|
||||
more SoCs.
|
||||
|
||||
|
||||
VII - Specifying interrupt information for devices
|
||||
===================================================
|
||||
|
||||
The device tree represents the busses and devices of a hardware
|
||||
The device tree represents the buses and devices of a hardware
|
||||
system in a form similar to the physical bus topology of the
|
||||
hardware.
|
||||
|
|
@ -603,3 +603,19 @@ Why: The adm9240, w83792d and w83793 hardware monitoring drivers have
|
|||
Who: Jean Delvare <khali@linux-fr.org>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: noswapaccount kernel command line parameter
|
||||
When: 2.6.40
|
||||
Why: The original implementation of memsw feature enabled by
|
||||
CONFIG_CGROUP_MEM_RES_CTLR_SWAP could be disabled by the noswapaccount
|
||||
kernel parameter (introduced in 2.6.29-rc1). Later on, this decision
|
||||
turned out to be not ideal because we cannot have the feature compiled
|
||||
in and disabled by default and let only interested to enable it
|
||||
(e.g. general distribution kernels might need it). Therefore we have
|
||||
added swapaccount[=0|1] parameter (introduced in 2.6.37) which provides
|
||||
the both possibilities. If we remove noswapaccount we will have
|
||||
less command line parameters with the same functionality and we
|
||||
can also cleanup the parameter handling a bit ().
|
||||
Who: Michal Hocko <mhocko@suse.cz>
|
||||
|
||||
----------------------------
|
||||
|
|
|
@ -460,6 +460,8 @@ Note, a technical ChangeLog aimed at kernel hackers is in fs/ntfs/ChangeLog.
|
|||
2.1.30:
|
||||
- Fix writev() (it kept writing the first segment over and over again
|
||||
instead of moving onto subsequent segments).
|
||||
- Fix crash in ntfs_mft_record_alloc() when mapping the new extent mft
|
||||
record failed.
|
||||
2.1.29:
|
||||
- Fix a deadlock when mounting read-write.
|
||||
2.1.28:
|
||||
|
|
|
@ -51,7 +51,8 @@ Supported chips:
|
|||
* JEDEC JC 42.4 compliant temperature sensor chips
|
||||
Prefix: 'jc42'
|
||||
Addresses scanned: I2C 0x18 - 0x1f
|
||||
Datasheet: -
|
||||
Datasheet:
|
||||
http://www.jedec.org/sites/default/files/docs/4_01_04R19.pdf
|
||||
|
||||
Author:
|
||||
Guenter Roeck <guenter.roeck@ericsson.com>
|
||||
|
@ -60,7 +61,11 @@ Author:
|
|||
Description
|
||||
-----------
|
||||
|
||||
This driver implements support for JEDEC JC 42.4 compliant temperature sensors.
|
||||
This driver implements support for JEDEC JC 42.4 compliant temperature sensors,
|
||||
which are used on many DDR3 memory modules for mobile devices and servers. Some
|
||||
systems use the sensor to prevent memory overheating by automatically throttling
|
||||
the memory controller.
|
||||
|
||||
The driver auto-detects the chips listed above, but can be manually instantiated
|
||||
to support other JC 42.4 compliant chips.
|
||||
|
||||
|
@ -81,15 +86,19 @@ limits. The chip supports only a single register to configure the hysteresis,
|
|||
which applies to all limits. This register can be written by writing into
|
||||
temp1_crit_hyst. Other hysteresis attributes are read-only.
|
||||
|
||||
If the BIOS has configured the sensor for automatic temperature management, it
|
||||
is likely that it has locked the registers, i.e., that the temperature limits
|
||||
cannot be changed.
|
||||
|
||||
Sysfs entries
|
||||
-------------
|
||||
|
||||
temp1_input Temperature (RO)
|
||||
temp1_min Minimum temperature (RW)
|
||||
temp1_max Maximum temperature (RW)
|
||||
temp1_crit Critical high temperature (RW)
|
||||
temp1_min Minimum temperature (RO or RW)
|
||||
temp1_max Maximum temperature (RO or RW)
|
||||
temp1_crit Critical high temperature (RO or RW)
|
||||
|
||||
temp1_crit_hyst Critical hysteresis temperature (RW)
|
||||
temp1_crit_hyst Critical hysteresis temperature (RO or RW)
|
||||
temp1_max_hyst Maximum hysteresis temperature (RO)
|
||||
|
||||
temp1_min_alarm Temperature low alarm
|
||||
|
|
|
@ -9,6 +9,8 @@ Supported chips:
|
|||
Socket S1G3: Athlon II, Sempron, Turion II
|
||||
* AMD Family 11h processors:
|
||||
Socket S1G2: Athlon (X2), Sempron (X2), Turion X2 (Ultra)
|
||||
* AMD Family 12h processors: "Llano"
|
||||
* AMD Family 14h processors: "Brazos" (C/E/G-Series)
|
||||
|
||||
Prefix: 'k10temp'
|
||||
Addresses scanned: PCI space
|
||||
|
@ -17,10 +19,14 @@ Supported chips:
|
|||
http://support.amd.com/us/Processor_TechDocs/31116.pdf
|
||||
BIOS and Kernel Developer's Guide (BKDG) for AMD Family 11h Processors:
|
||||
http://support.amd.com/us/Processor_TechDocs/41256.pdf
|
||||
BIOS and Kernel Developer's Guide (BKDG) for AMD Family 14h Models 00h-0Fh Processors:
|
||||
http://support.amd.com/us/Processor_TechDocs/43170.pdf
|
||||
Revision Guide for AMD Family 10h Processors:
|
||||
http://support.amd.com/us/Processor_TechDocs/41322.pdf
|
||||
Revision Guide for AMD Family 11h Processors:
|
||||
http://support.amd.com/us/Processor_TechDocs/41788.pdf
|
||||
Revision Guide for AMD Family 14h Models 00h-0Fh Processors:
|
||||
http://support.amd.com/us/Processor_TechDocs/47534.pdf
|
||||
AMD Family 11h Processor Power and Thermal Data Sheet for Notebooks:
|
||||
http://support.amd.com/us/Processor_TechDocs/43373.pdf
|
||||
AMD Family 10h Server and Workstation Processor Power and Thermal Data Sheet:
|
||||
|
@ -34,7 +40,7 @@ Description
|
|||
-----------
|
||||
|
||||
This driver permits reading of the internal temperature sensor of AMD
|
||||
Family 10h and 11h processors.
|
||||
Family 10h/11h/12h/14h processors.
|
||||
|
||||
All these processors have a sensor, but on those for Socket F or AM2+,
|
||||
the sensor may return inconsistent values (erratum 319). The driver
|
||||
|
|
|
@ -43,11 +43,11 @@ parameter is applicable:
|
|||
AVR32 AVR32 architecture is enabled.
|
||||
AX25 Appropriate AX.25 support is enabled.
|
||||
BLACKFIN Blackfin architecture is enabled.
|
||||
DRM Direct Rendering Management support is enabled.
|
||||
DYNAMIC_DEBUG Build in debug messages and enable them at runtime
|
||||
EDD BIOS Enhanced Disk Drive Services (EDD) is enabled
|
||||
EFI EFI Partitioning (GPT) is enabled
|
||||
EIDE EIDE/ATAPI support is enabled.
|
||||
DRM Direct Rendering Management support is enabled.
|
||||
DYNAMIC_DEBUG Build in debug messages and enable them at runtime
|
||||
FB The frame buffer device is enabled.
|
||||
GCOV GCOV profiling is enabled.
|
||||
HW Appropriate hardware is enabled.
|
||||
|
@ -144,6 +144,11 @@ a fixed number of characters. This limit depends on the architecture
|
|||
and is between 256 and 4096 characters. It is defined in the file
|
||||
./include/asm/setup.h as COMMAND_LINE_SIZE.
|
||||
|
||||
Finally, the [KMG] suffix is commonly described after a number of kernel
|
||||
parameter values. These 'K', 'M', and 'G' letters represent the _binary_
|
||||
multipliers 'Kilo', 'Mega', and 'Giga', equalling 2^10, 2^20, and 2^30
|
||||
bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||
|
||||
|
||||
acpi= [HW,ACPI,X86]
|
||||
Advanced Configuration and Power Interface
|
||||
|
@ -545,16 +550,20 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
Format:
|
||||
<first_slot>,<last_slot>,<port>,<enum_bit>[,<debug>]
|
||||
|
||||
crashkernel=nn[KMG]@ss[KMG]
|
||||
[KNL] Reserve a chunk of physical memory to
|
||||
hold a kernel to switch to with kexec on panic.
|
||||
crashkernel=size[KMG][@offset[KMG]]
|
||||
[KNL] Using kexec, Linux can switch to a 'crash kernel'
|
||||
upon panic. This parameter reserves the physical
|
||||
memory region [offset, offset + size] for that kernel
|
||||
image. If '@offset' is omitted, then a suitable offset
|
||||
is selected automatically. Check
|
||||
Documentation/kdump/kdump.txt for further details.
|
||||
|
||||
crashkernel=range1:size1[,range2:size2,...][@offset]
|
||||
[KNL] Same as above, but depends on the memory
|
||||
in the running system. The syntax of range is
|
||||
start-[end] where start and end are both
|
||||
a memory unit (amount[KMG]). See also
|
||||
Documentation/kdump/kdump.txt for a example.
|
||||
Documentation/kdump/kdump.txt for an example.
|
||||
|
||||
cs89x0_dma= [HW,NET]
|
||||
Format: <dma>
|
||||
|
@ -1262,10 +1271,9 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
6 (KERN_INFO) informational
|
||||
7 (KERN_DEBUG) debug-level messages
|
||||
|
||||
log_buf_len=n Sets the size of the printk ring buffer, in bytes.
|
||||
Format: { n | nk | nM }
|
||||
n must be a power of two. The default size
|
||||
is set in the kernel config file.
|
||||
log_buf_len=n[KMG] Sets the size of the printk ring buffer,
|
||||
in bytes. n must be a power of two. The default
|
||||
size is set in the kernel config file.
|
||||
|
||||
logo.nologo [FB] Disables display of the built-in Linux logo.
|
||||
This may be used to provide more screen space for
|
||||
|
|
|
@ -40,8 +40,6 @@ decnet.txt
|
|||
- info on using the DECnet networking layer in Linux.
|
||||
depca.txt
|
||||
- the Digital DEPCA/EtherWORKS DE1?? and DE2?? LANCE Ethernet driver
|
||||
dgrs.txt
|
||||
- the Digi International RightSwitch SE-X Ethernet driver
|
||||
dmfe.txt
|
||||
- info on the Davicom DM9102(A)/DM9132/DM9801 fast ethernet driver.
|
||||
e100.txt
|
||||
|
@ -50,8 +48,6 @@ e1000.txt
|
|||
- info on Intel's E1000 line of gigabit ethernet boards
|
||||
eql.txt
|
||||
- serial IP load balancing
|
||||
ethertap.txt
|
||||
- the Ethertap user space packet reception and transmission driver
|
||||
ewrk3.txt
|
||||
- the Digital EtherWORKS 3 DE203/4/5 Ethernet driver
|
||||
filter.txt
|
||||
|
@ -104,8 +100,6 @@ tuntap.txt
|
|||
- TUN/TAP device driver, allowing user space Rx/Tx of packets.
|
||||
vortex.txt
|
||||
- info on using 3Com Vortex (3c590, 3c592, 3c595, 3c597) Ethernet cards.
|
||||
wavelan.txt
|
||||
- AT&T GIS (nee NCR) WaveLAN card: An Ethernet-like radio transceiver
|
||||
x25.txt
|
||||
- general info on X.25 development.
|
||||
x25-iface.txt
|
||||
|
|
|
@ -4,6 +4,8 @@ obj- := dummy.o
|
|||
# List of programs to build
|
||||
hostprogs-y := ifenslave
|
||||
|
||||
HOSTCFLAGS_ifenslave.o += -I$(objtree)/usr/include
|
||||
|
||||
# Tell kbuild to always build the programs
|
||||
always := $(hostprogs-y)
|
||||
|
||||
|
|
|
@ -49,7 +49,8 @@ Table of Contents
|
|||
3.3 Configuring Bonding Manually with Ifenslave
|
||||
3.3.1 Configuring Multiple Bonds Manually
|
||||
3.4 Configuring Bonding Manually via Sysfs
|
||||
3.5 Overriding Configuration for Special Cases
|
||||
3.5 Configuration with Interfaces Support
|
||||
3.6 Overriding Configuration for Special Cases
|
||||
|
||||
4. Querying Bonding Configuration
|
||||
4.1 Bonding Configuration
|
||||
|
@ -161,8 +162,8 @@ onwards) do not have /usr/include/linux symbolically linked to the
|
|||
default kernel source include directory.
|
||||
|
||||
SECOND IMPORTANT NOTE:
|
||||
If you plan to configure bonding using sysfs, you do not need
|
||||
to use ifenslave.
|
||||
If you plan to configure bonding using sysfs or using the
|
||||
/etc/network/interfaces file, you do not need to use ifenslave.
|
||||
|
||||
2. Bonding Driver Options
|
||||
=========================
|
||||
|
@ -779,22 +780,26 @@ resend_igmp
|
|||
|
||||
You can configure bonding using either your distro's network
|
||||
initialization scripts, or manually using either ifenslave or the
|
||||
sysfs interface. Distros generally use one of two packages for the
|
||||
network initialization scripts: initscripts or sysconfig. Recent
|
||||
versions of these packages have support for bonding, while older
|
||||
sysfs interface. Distros generally use one of three packages for the
|
||||
network initialization scripts: initscripts, sysconfig or interfaces.
|
||||
Recent versions of these packages have support for bonding, while older
|
||||
versions do not.
|
||||
|
||||
We will first describe the options for configuring bonding for
|
||||
distros using versions of initscripts and sysconfig with full or
|
||||
partial support for bonding, then provide information on enabling
|
||||
distros using versions of initscripts, sysconfig and interfaces with full
|
||||
or partial support for bonding, then provide information on enabling
|
||||
bonding without support from the network initialization scripts (i.e.,
|
||||
older versions of initscripts or sysconfig).
|
||||
|
||||
If you're unsure whether your distro uses sysconfig or
|
||||
initscripts, or don't know if it's new enough, have no fear.
|
||||
If you're unsure whether your distro uses sysconfig,
|
||||
initscripts or interfaces, or don't know if it's new enough, have no fear.
|
||||
Determining this is fairly straightforward.
|
||||
|
||||
First, issue the command:
|
||||
First, look for a file called interfaces in /etc/network directory.
|
||||
If this file is present in your system, then your system use interfaces. See
|
||||
Configuration with Interfaces Support.
|
||||
|
||||
Else, issue the command:
|
||||
|
||||
$ rpm -qf /sbin/ifup
|
||||
|
||||
|
@ -1327,8 +1332,62 @@ echo 2000 > /sys/class/net/bond1/bonding/arp_interval
|
|||
echo +eth2 > /sys/class/net/bond1/bonding/slaves
|
||||
echo +eth3 > /sys/class/net/bond1/bonding/slaves
|
||||
|
||||
3.5 Overriding Configuration for Special Cases
|
||||
3.5 Configuration with Interfaces Support
|
||||
-----------------------------------------
|
||||
|
||||
This section applies to distros which use /etc/network/interfaces file
|
||||
to describe network interface configuration, most notably Debian and it's
|
||||
derivatives.
|
||||
|
||||
The ifup and ifdown commands on Debian don't support bonding out of
|
||||
the box. The ifenslave-2.6 package should be installed to provide bonding
|
||||
support. Once installed, this package will provide bond-* options to be used
|
||||
into /etc/network/interfaces.
|
||||
|
||||
Note that ifenslave-2.6 package will load the bonding module and use
|
||||
the ifenslave command when appropriate.
|
||||
|
||||
Example Configurations
|
||||
----------------------
|
||||
|
||||
In /etc/network/interfaces, the following stanza will configure bond0, in
|
||||
active-backup mode, with eth0 and eth1 as slaves.
|
||||
|
||||
auto bond0
|
||||
iface bond0 inet dhcp
|
||||
bond-slaves eth0 eth1
|
||||
bond-mode active-backup
|
||||
bond-miimon 100
|
||||
bond-primary eth0 eth1
|
||||
|
||||
If the above configuration doesn't work, you might have a system using
|
||||
upstart for system startup. This is most notably true for recent
|
||||
Ubuntu versions. The following stanza in /etc/network/interfaces will
|
||||
produce the same result on those systems.
|
||||
|
||||
auto bond0
|
||||
iface bond0 inet dhcp
|
||||
bond-slaves none
|
||||
bond-mode active-backup
|
||||
bond-miimon 100
|
||||
|
||||
auto eth0
|
||||
iface eth0 inet manual
|
||||
bond-master bond0
|
||||
bond-primary eth0 eth1
|
||||
|
||||
auto eth1
|
||||
iface eth1 inet manual
|
||||
bond-master bond0
|
||||
bond-primary eth0 eth1
|
||||
|
||||
For a full list of bond-* supported options in /etc/network/interfaces and some
|
||||
more advanced examples tailored to you particular distros, see the files in
|
||||
/usr/share/doc/ifenslave-2.6.
|
||||
|
||||
3.6 Overriding Configuration for Special Cases
|
||||
----------------------------------------------
|
||||
|
||||
When using the bonding driver, the physical port which transmits a frame is
|
||||
typically selected by the bonding driver, and is not relevant to the user or
|
||||
system administrator. The output port is simply selected using the policies of
|
||||
|
|
|
@ -61,7 +61,6 @@ before the more general line given above as the first match is the one taken.
|
|||
create dns_resolver foo:* * /usr/sbin/dns.foo %k
|
||||
|
||||
|
||||
|
||||
=====
|
||||
USAGE
|
||||
=====
|
||||
|
@ -104,6 +103,14 @@ implemented in the module can be called after doing:
|
|||
returned also.
|
||||
|
||||
|
||||
===============================
|
||||
READING DNS KEYS FROM USERSPACE
|
||||
===============================
|
||||
|
||||
Keys of dns_resolver type can be read from userspace using keyctl_read() or
|
||||
"keyctl read/print/pipe".
|
||||
|
||||
|
||||
=========
|
||||
MECHANISM
|
||||
=========
|
||||
|
|
|
@ -187,7 +187,7 @@ tcp_cookie_size - INTEGER
|
|||
tcp_dsack - BOOLEAN
|
||||
Allows TCP to send "duplicate" SACKs.
|
||||
|
||||
tcp_ecn - BOOLEAN
|
||||
tcp_ecn - INTEGER
|
||||
Enable Explicit Congestion Notification (ECN) in TCP. ECN is only
|
||||
used when both ends of the TCP flow support it. It is useful to
|
||||
avoid losses due to congestion (when the bottleneck router supports
|
||||
|
|
|
@ -1,3 +1,7 @@
|
|||
Version 15 of schedstats dropped counters for some sched_yield:
|
||||
yld_exp_empty, yld_act_empty and yld_both_empty. Otherwise, it is
|
||||
identical to version 14.
|
||||
|
||||
Version 14 of schedstats includes support for sched_domains, which hit the
|
||||
mainline kernel in 2.6.20 although it is identical to the stats from version
|
||||
12 which was in the kernel from 2.6.13-2.6.19 (version 13 never saw a kernel
|
||||
|
@ -28,32 +32,25 @@ to write their own scripts, the fields are described here.
|
|||
|
||||
CPU statistics
|
||||
--------------
|
||||
cpu<N> 1 2 3 4 5 6 7 8 9 10 11 12
|
||||
cpu<N> 1 2 3 4 5 6 7 8 9
|
||||
|
||||
NOTE: In the sched_yield() statistics, the active queue is considered empty
|
||||
if it has only one process in it, since obviously the process calling
|
||||
sched_yield() is that process.
|
||||
|
||||
First four fields are sched_yield() statistics:
|
||||
1) # of times both the active and the expired queue were empty
|
||||
2) # of times just the active queue was empty
|
||||
3) # of times just the expired queue was empty
|
||||
4) # of times sched_yield() was called
|
||||
First field is a sched_yield() statistic:
|
||||
1) # of times sched_yield() was called
|
||||
|
||||
Next three are schedule() statistics:
|
||||
5) # of times we switched to the expired queue and reused it
|
||||
6) # of times schedule() was called
|
||||
7) # of times schedule() left the processor idle
|
||||
2) # of times we switched to the expired queue and reused it
|
||||
3) # of times schedule() was called
|
||||
4) # of times schedule() left the processor idle
|
||||
|
||||
Next two are try_to_wake_up() statistics:
|
||||
8) # of times try_to_wake_up() was called
|
||||
9) # of times try_to_wake_up() was called to wake up the local cpu
|
||||
5) # of times try_to_wake_up() was called
|
||||
6) # of times try_to_wake_up() was called to wake up the local cpu
|
||||
|
||||
Next three are statistics describing scheduling latency:
|
||||
10) sum of all time spent running by tasks on this processor (in jiffies)
|
||||
11) sum of all time spent waiting to run by tasks on this processor (in
|
||||
7) sum of all time spent running by tasks on this processor (in jiffies)
|
||||
8) sum of all time spent waiting to run by tasks on this processor (in
|
||||
jiffies)
|
||||
12) # of timeslices run on this cpu
|
||||
9) # of timeslices run on this cpu
|
||||
|
||||
|
||||
Domain statistics
|
||||
|
|
|
@ -296,6 +296,7 @@ Conexant 5066
|
|||
=============
|
||||
laptop Basic Laptop config (default)
|
||||
hp-laptop HP laptops, e g G60
|
||||
asus Asus K52JU, Lenovo G560
|
||||
dell-laptop Dell laptops
|
||||
dell-vostro Dell Vostro
|
||||
olpc-xo-1_5 OLPC XO 1.5
|
||||
|
|
|
@ -190,9 +190,9 @@ resources, scheduled and executed.
|
|||
* Long running CPU intensive workloads which can be better
|
||||
managed by the system scheduler.
|
||||
|
||||
WQ_FREEZEABLE
|
||||
WQ_FREEZABLE
|
||||
|
||||
A freezeable wq participates in the freeze phase of the system
|
||||
A freezable wq participates in the freeze phase of the system
|
||||
suspend operations. Work items on the wq are drained and no
|
||||
new work item starts execution until thawed.
|
||||
|
||||
|
|
109
MAINTAINERS
109
MAINTAINERS
|
@ -885,7 +885,7 @@ S: Supported
|
|||
|
||||
ARM/QUALCOMM MSM MACHINE SUPPORT
|
||||
M: David Brown <davidb@codeaurora.org>
|
||||
M: Daniel Walker <dwalker@codeaurora.org>
|
||||
M: Daniel Walker <dwalker@fifo99.com>
|
||||
M: Bryan Huntsman <bryanh@codeaurora.org>
|
||||
L: linux-arm-msm@vger.kernel.org
|
||||
F: arch/arm/mach-msm/
|
||||
|
@ -978,6 +978,8 @@ S: Maintained
|
|||
F: arch/arm/plat-samsung/
|
||||
F: arch/arm/plat-s3c24xx/
|
||||
F: arch/arm/plat-s5p/
|
||||
F: drivers/*/*s3c2410*
|
||||
F: drivers/*/*/*s3c2410*
|
||||
|
||||
ARM/S3C2410 ARM ARCHITECTURE
|
||||
M: Ben Dooks <ben-linux@fluff.org>
|
||||
|
@ -1008,6 +1010,15 @@ L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers)
|
|||
S: Maintained
|
||||
F: arch/arm/mach-s5p*/
|
||||
|
||||
ARM/SAMSUNG MOBILE MACHINE SUPPORT
|
||||
M: Kyungmin Park <kyungmin.park@samsung.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
F: arch/arm/mach-s5pv210/mach-aquila.c
|
||||
F: arch/arm/mach-s5pv210/mach-goni.c
|
||||
F: arch/arm/mach-exynos4/mach-universal_c210.c
|
||||
F: arch/arm/mach-exynos4/mach-nuri.c
|
||||
|
||||
ARM/SAMSUNG S5P SERIES FIMC SUPPORT
|
||||
M: Kyungmin Park <kyungmin.park@samsung.com>
|
||||
M: Sylwester Nawrocki <s.nawrocki@samsung.com>
|
||||
|
@ -1465,6 +1476,7 @@ F: include/net/bluetooth/
|
|||
|
||||
BONDING DRIVER
|
||||
M: Jay Vosburgh <fubar@us.ibm.com>
|
||||
M: Andy Gospodarek <andy@greyhouse.net>
|
||||
L: netdev@vger.kernel.org
|
||||
W: http://sourceforge.net/projects/bonding/
|
||||
S: Supported
|
||||
|
@ -1690,6 +1702,13 @@ M: Andy Whitcroft <apw@canonical.com>
|
|||
S: Supported
|
||||
F: scripts/checkpatch.pl
|
||||
|
||||
CHINESE DOCUMENTATION
|
||||
M: Harry Wei <harryxiyou@gmail.com>
|
||||
L: xiyoulinuxkernelgroup@googlegroups.com
|
||||
L: linux-kernel@zh-kernel.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
F: Documentation/zh_CN/
|
||||
|
||||
CISCO VIC ETHERNET NIC DRIVER
|
||||
M: Vasanthy Kolluri <vkolluri@cisco.com>
|
||||
M: Roopa Prabhu <roprabhu@cisco.com>
|
||||
|
@ -2024,7 +2043,7 @@ F: Documentation/scsi/dc395x.txt
|
|||
F: drivers/scsi/dc395x.*
|
||||
|
||||
DCCP PROTOCOL
|
||||
M: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
|
||||
M: Gerrit Renker <gerrit@erg.abdn.ac.uk>
|
||||
L: dccp@vger.kernel.org
|
||||
W: http://www.linuxfoundation.org/collaborate/workgroups/networking/dccp
|
||||
S: Maintained
|
||||
|
@ -2124,6 +2143,7 @@ S: Supported
|
|||
F: fs/dlm/
|
||||
|
||||
DMA GENERIC OFFLOAD ENGINE SUBSYSTEM
|
||||
M: Vinod Koul <vinod.koul@intel.com>
|
||||
M: Dan Williams <dan.j.williams@intel.com>
|
||||
S: Supported
|
||||
F: drivers/dma/
|
||||
|
@ -2772,6 +2792,15 @@ F: Documentation/isdn/README.gigaset
|
|||
F: drivers/isdn/gigaset/
|
||||
F: include/linux/gigaset_dev.h
|
||||
|
||||
GPIO SUBSYSTEM
|
||||
M: Grant Likely <grant.likely@secretlab.ca>
|
||||
L: linux-kernel@vger.kernel.org
|
||||
S: Maintained
|
||||
T: git git://git.secretlab.ca/git/linux-2.6.git
|
||||
F: Documentation/gpio/gpio.txt
|
||||
F: drivers/gpio/
|
||||
F: include/linux/gpio*
|
||||
|
||||
GRETH 10/100/1G Ethernet MAC device driver
|
||||
M: Kristoffer Glembo <kristoffer@gaisler.com>
|
||||
L: netdev@vger.kernel.org
|
||||
|
@ -2861,7 +2890,6 @@ M: Guenter Roeck <guenter.roeck@ericsson.com>
|
|||
L: lm-sensors@lm-sensors.org
|
||||
W: http://www.lm-sensors.org/
|
||||
T: quilt kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-hwmon/
|
||||
T: quilt kernel.org/pub/linux/kernel/people/groeck/linux-staging/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git
|
||||
S: Maintained
|
||||
F: Documentation/hwmon/
|
||||
|
@ -3139,6 +3167,12 @@ S: Maintained
|
|||
F: net/ieee802154/
|
||||
F: drivers/ieee802154/
|
||||
|
||||
IKANOS/ADI EAGLE ADSL USB DRIVER
|
||||
M: Matthieu Castet <castet.matthieu@free.fr>
|
||||
M: Stanislaw Gruszka <stf_xl@wp.pl>
|
||||
S: Maintained
|
||||
F: drivers/usb/atm/ueagle-atm.c
|
||||
|
||||
INTEGRITY MEASUREMENT ARCHITECTURE (IMA)
|
||||
M: Mimi Zohar <zohar@us.ibm.com>
|
||||
S: Supported
|
||||
|
@ -3327,7 +3361,6 @@ F: drivers/net/wimax/i2400m/
|
|||
F: include/linux/wimax/i2400m.h
|
||||
|
||||
INTEL WIRELESS WIFI LINK (iwlwifi)
|
||||
M: Reinette Chatre <reinette.chatre@intel.com>
|
||||
M: Wey-Yi Guy <wey-yi.w.guy@intel.com>
|
||||
M: Intel Linux Wireless <ilw@linux.intel.com>
|
||||
L: linux-wireless@vger.kernel.org
|
||||
|
@ -3496,7 +3529,7 @@ F: drivers/hwmon/jc42.c
|
|||
F: Documentation/hwmon/jc42
|
||||
|
||||
JFS FILESYSTEM
|
||||
M: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
|
||||
M: Dave Kleikamp <shaggy@kernel.org>
|
||||
L: jfs-discussion@lists.sourceforge.net
|
||||
W: http://jfs.sourceforge.net/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/shaggy/jfs-2.6.git
|
||||
|
@ -3674,6 +3707,28 @@ F: include/linux/key-type.h
|
|||
F: include/keys/
|
||||
F: security/keys/
|
||||
|
||||
KEYS-TRUSTED
|
||||
M: David Safford <safford@watson.ibm.com>
|
||||
M: Mimi Zohar <zohar@us.ibm.com>
|
||||
L: linux-security-module@vger.kernel.org
|
||||
L: keyrings@linux-nfs.org
|
||||
S: Supported
|
||||
F: Documentation/keys-trusted-encrypted.txt
|
||||
F: include/keys/trusted-type.h
|
||||
F: security/keys/trusted.c
|
||||
F: security/keys/trusted.h
|
||||
|
||||
KEYS-ENCRYPTED
|
||||
M: Mimi Zohar <zohar@us.ibm.com>
|
||||
M: David Safford <safford@watson.ibm.com>
|
||||
L: linux-security-module@vger.kernel.org
|
||||
L: keyrings@linux-nfs.org
|
||||
S: Supported
|
||||
F: Documentation/keys-trusted-encrypted.txt
|
||||
F: include/keys/encrypted-type.h
|
||||
F: security/keys/encrypted.c
|
||||
F: security/keys/encrypted.h
|
||||
|
||||
KGDB / KDB /debug_core
|
||||
M: Jason Wessel <jason.wessel@windriver.com>
|
||||
W: http://kgdb.wiki.kernel.org/
|
||||
|
@ -4562,7 +4617,7 @@ F: drivers/i2c/busses/i2c-ocores.c
|
|||
|
||||
OPEN FIRMWARE AND FLATTENED DEVICE TREE
|
||||
M: Grant Likely <grant.likely@secretlab.ca>
|
||||
L: devicetree-discuss@lists.ozlabs.org
|
||||
L: devicetree-discuss@lists.ozlabs.org (moderated for non-subscribers)
|
||||
W: http://fdt.secretlab.ca
|
||||
T: git git://git.secretlab.ca/git/linux-2.6.git
|
||||
S: Maintained
|
||||
|
@ -5126,6 +5181,7 @@ F: drivers/char/random.c
|
|||
|
||||
RAPIDIO SUBSYSTEM
|
||||
M: Matt Porter <mporter@kernel.crashing.org>
|
||||
M: Alexandre Bounine <alexandre.bounine@idt.com>
|
||||
S: Maintained
|
||||
F: drivers/rapidio/
|
||||
|
||||
|
@ -5228,7 +5284,7 @@ S: Maintained
|
|||
F: drivers/net/wireless/rtl818x/rtl8180/
|
||||
|
||||
RTL8187 WIRELESS DRIVER
|
||||
M: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
|
||||
M: Herton Ronaldo Krzesinski <herton@canonical.com>
|
||||
M: Hin-Tak Leung <htl10@users.sourceforge.net>
|
||||
M: Larry Finger <Larry.Finger@lwfinger.net>
|
||||
L: linux-wireless@vger.kernel.org
|
||||
|
@ -5522,12 +5578,11 @@ S: Supported
|
|||
F: drivers/scsi/be2iscsi/
|
||||
|
||||
SERVER ENGINES 10Gbps NIC - BladeEngine 2 DRIVER
|
||||
M: Sathya Perla <sathyap@serverengines.com>
|
||||
M: Subbu Seetharaman <subbus@serverengines.com>
|
||||
M: Sarveshwar Bandi <sarveshwarb@serverengines.com>
|
||||
M: Ajit Khaparde <ajitk@serverengines.com>
|
||||
M: Sathya Perla <sathya.perla@emulex.com>
|
||||
M: Subbu Seetharaman <subbu.seetharaman@emulex.com>
|
||||
M: Ajit Khaparde <ajit.khaparde@emulex.com>
|
||||
L: netdev@vger.kernel.org
|
||||
W: http://www.serverengines.com
|
||||
W: http://www.emulex.com
|
||||
S: Supported
|
||||
F: drivers/net/benet/
|
||||
|
||||
|
@ -5587,18 +5642,20 @@ F: include/linux/sfi*.h
|
|||
|
||||
SIMTEC EB110ATX (Chalice CATS)
|
||||
P: Ben Dooks
|
||||
M: Vincent Sanders <support@simtec.co.uk>
|
||||
P: Vincent Sanders <vince@simtec.co.uk>
|
||||
M: Simtec Linux Team <linux@simtec.co.uk>
|
||||
W: http://www.simtec.co.uk/products/EB110ATX/
|
||||
S: Supported
|
||||
|
||||
SIMTEC EB2410ITX (BAST)
|
||||
P: Ben Dooks
|
||||
M: Vincent Sanders <support@simtec.co.uk>
|
||||
P: Vincent Sanders <vince@simtec.co.uk>
|
||||
M: Simtec Linux Team <linux@simtec.co.uk>
|
||||
W: http://www.simtec.co.uk/products/EB2410ITX/
|
||||
S: Supported
|
||||
F: arch/arm/mach-s3c2410/
|
||||
F: drivers/*/*s3c2410*
|
||||
F: drivers/*/*/*s3c2410*
|
||||
F: arch/arm/mach-s3c2410/mach-bast.c
|
||||
F: arch/arm/mach-s3c2410/bast-ide.c
|
||||
F: arch/arm/mach-s3c2410/bast-irq.c
|
||||
|
||||
TI DAVINCI MACHINE SUPPORT
|
||||
M: Kevin Hilman <khilman@deeprootsystems.com>
|
||||
|
@ -6065,7 +6122,7 @@ S: Maintained
|
|||
F: security/tomoyo/
|
||||
|
||||
TOPSTAR LAPTOP EXTRAS DRIVER
|
||||
M: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
|
||||
M: Herton Ronaldo Krzesinski <herton@canonical.com>
|
||||
L: platform-driver-x86@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/platform/x86/topstar-laptop.c
|
||||
|
@ -6573,6 +6630,16 @@ S: Maintained
|
|||
F: drivers/char/virtio_console.c
|
||||
F: include/linux/virtio_console.h
|
||||
|
||||
VIRTIO CORE, NET AND BLOCK DRIVERS
|
||||
M: Rusty Russell <rusty@rustcorp.com.au>
|
||||
M: "Michael S. Tsirkin" <mst@redhat.com>
|
||||
L: virtualization@lists.linux-foundation.org
|
||||
S: Maintained
|
||||
F: drivers/virtio/
|
||||
F: drivers/net/virtio_net.c
|
||||
F: drivers/block/virtio_blk.c
|
||||
F: include/linux/virtio_*.h
|
||||
|
||||
VIRTIO HOST (VHOST)
|
||||
M: "Michael S. Tsirkin" <mst@redhat.com>
|
||||
L: kvm@vger.kernel.org
|
||||
|
@ -6746,12 +6813,12 @@ S: Maintained
|
|||
F: drivers/net/wireless/wl1251/*
|
||||
|
||||
WL1271 WIRELESS DRIVER
|
||||
M: Luciano Coelho <luciano.coelho@nokia.com>
|
||||
M: Luciano Coelho <coelho@ti.com>
|
||||
L: linux-wireless@vger.kernel.org
|
||||
W: http://wireless.kernel.org
|
||||
W: http://wireless.kernel.org/en/users/Drivers/wl12xx
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/luca/wl12xx.git
|
||||
S: Maintained
|
||||
F: drivers/net/wireless/wl12xx/wl1271*
|
||||
F: drivers/net/wireless/wl12xx/
|
||||
F: include/linux/wl12xx.h
|
||||
|
||||
WL3501 WIRELESS PCMCIA CARD DRIVER
|
||||
|
|
2
Makefile
2
Makefile
|
@ -1,7 +1,7 @@
|
|||
VERSION = 2
|
||||
PATCHLEVEL = 6
|
||||
SUBLEVEL = 38
|
||||
EXTRAVERSION = -rc2
|
||||
EXTRAVERSION = -rc8
|
||||
NAME = Flesh-Eating Bats with Fangs
|
||||
|
||||
# *DOCUMENTATION*
|
||||
|
|
|
@ -11,6 +11,7 @@ config ALPHA
|
|||
select HAVE_GENERIC_HARDIRQS
|
||||
select GENERIC_IRQ_PROBE
|
||||
select AUTO_IRQ_AFFINITY if SMP
|
||||
select GENERIC_HARDIRQS_NO_DEPRECATED
|
||||
help
|
||||
The Alpha is a 64-bit general-purpose processor designed and
|
||||
marketed by the Digital Equipment Corporation of blessed memory,
|
||||
|
|
|
@ -44,11 +44,16 @@ static char irq_user_affinity[NR_IRQS];
|
|||
|
||||
int irq_select_affinity(unsigned int irq)
|
||||
{
|
||||
struct irq_desc *desc = irq_to_desc[irq];
|
||||
struct irq_data *data = irq_get_irq_data(irq);
|
||||
struct irq_chip *chip;
|
||||
static int last_cpu;
|
||||
int cpu = last_cpu + 1;
|
||||
|
||||
if (!desc || !get_irq_desc_chip(desc)->set_affinity || irq_user_affinity[irq])
|
||||
if (!data)
|
||||
return 1;
|
||||
chip = irq_data_get_irq_chip(data);
|
||||
|
||||
if (!chip->irq_set_affinity || irq_user_affinity[irq])
|
||||
return 1;
|
||||
|
||||
while (!cpu_possible(cpu) ||
|
||||
|
@ -56,8 +61,8 @@ int irq_select_affinity(unsigned int irq)
|
|||
cpu = (cpu < (NR_CPUS-1) ? cpu + 1 : 0);
|
||||
last_cpu = cpu;
|
||||
|
||||
cpumask_copy(desc->affinity, cpumask_of(cpu));
|
||||
get_irq_desc_chip(desc)->set_affinity(irq, cpumask_of(cpu));
|
||||
cpumask_copy(data->affinity, cpumask_of(cpu));
|
||||
chip->irq_set_affinity(data, cpumask_of(cpu), false);
|
||||
return 0;
|
||||
}
|
||||
#endif /* CONFIG_SMP */
|
||||
|
|
|
@ -228,14 +228,9 @@ struct irqaction timer_irqaction = {
|
|||
void __init
|
||||
init_rtc_irq(void)
|
||||
{
|
||||
struct irq_desc *desc = irq_to_desc(RTC_IRQ);
|
||||
|
||||
if (desc) {
|
||||
desc->status |= IRQ_DISABLED;
|
||||
set_irq_chip_and_handler_name(RTC_IRQ, &no_irq_chip,
|
||||
handle_simple_irq, "RTC");
|
||||
setup_irq(RTC_IRQ, &timer_irqaction);
|
||||
}
|
||||
set_irq_chip_and_handler_name(RTC_IRQ, &no_irq_chip,
|
||||
handle_simple_irq, "RTC");
|
||||
setup_irq(RTC_IRQ, &timer_irqaction);
|
||||
}
|
||||
|
||||
/* Dummy irqactions. */
|
||||
|
|
|
@ -33,10 +33,10 @@ i8259_update_irq_hw(unsigned int irq, unsigned long mask)
|
|||
}
|
||||
|
||||
inline void
|
||||
i8259a_enable_irq(unsigned int irq)
|
||||
i8259a_enable_irq(struct irq_data *d)
|
||||
{
|
||||
spin_lock(&i8259_irq_lock);
|
||||
i8259_update_irq_hw(irq, cached_irq_mask &= ~(1 << irq));
|
||||
i8259_update_irq_hw(d->irq, cached_irq_mask &= ~(1 << d->irq));
|
||||
spin_unlock(&i8259_irq_lock);
|
||||
}
|
||||
|
||||
|
@ -47,16 +47,18 @@ __i8259a_disable_irq(unsigned int irq)
|
|||
}
|
||||
|
||||
void
|
||||
i8259a_disable_irq(unsigned int irq)
|
||||
i8259a_disable_irq(struct irq_data *d)
|
||||
{
|
||||
spin_lock(&i8259_irq_lock);
|
||||
__i8259a_disable_irq(irq);
|
||||
__i8259a_disable_irq(d->irq);
|
||||
spin_unlock(&i8259_irq_lock);
|
||||
}
|
||||
|
||||
void
|
||||
i8259a_mask_and_ack_irq(unsigned int irq)
|
||||
i8259a_mask_and_ack_irq(struct irq_data *d)
|
||||
{
|
||||
unsigned int irq = d->irq;
|
||||
|
||||
spin_lock(&i8259_irq_lock);
|
||||
__i8259a_disable_irq(irq);
|
||||
|
||||
|
@ -71,9 +73,9 @@ i8259a_mask_and_ack_irq(unsigned int irq)
|
|||
|
||||
struct irq_chip i8259a_irq_type = {
|
||||
.name = "XT-PIC",
|
||||
.unmask = i8259a_enable_irq,
|
||||
.mask = i8259a_disable_irq,
|
||||
.mask_ack = i8259a_mask_and_ack_irq,
|
||||
.irq_unmask = i8259a_enable_irq,
|
||||
.irq_mask = i8259a_disable_irq,
|
||||
.irq_mask_ack = i8259a_mask_and_ack_irq,
|
||||
};
|
||||
|
||||
void __init
|
||||
|
|
|
@ -31,11 +31,9 @@ extern void init_rtc_irq(void);
|
|||
|
||||
extern void common_init_isa_dma(void);
|
||||
|
||||
extern void i8259a_enable_irq(unsigned int);
|
||||
extern void i8259a_disable_irq(unsigned int);
|
||||
extern void i8259a_mask_and_ack_irq(unsigned int);
|
||||
extern unsigned int i8259a_startup_irq(unsigned int);
|
||||
extern void i8259a_end_irq(unsigned int);
|
||||
extern void i8259a_enable_irq(struct irq_data *d);
|
||||
extern void i8259a_disable_irq(struct irq_data *d);
|
||||
extern void i8259a_mask_and_ack_irq(struct irq_data *d);
|
||||
extern struct irq_chip i8259a_irq_type;
|
||||
extern void init_i8259a_irqs(void);
|
||||
|
||||
|
|
|
@ -29,21 +29,21 @@ pyxis_update_irq_hw(unsigned long mask)
|
|||
}
|
||||
|
||||
static inline void
|
||||
pyxis_enable_irq(unsigned int irq)
|
||||
pyxis_enable_irq(struct irq_data *d)
|
||||
{
|
||||
pyxis_update_irq_hw(cached_irq_mask |= 1UL << (irq - 16));
|
||||
pyxis_update_irq_hw(cached_irq_mask |= 1UL << (d->irq - 16));
|
||||
}
|
||||
|
||||
static void
|
||||
pyxis_disable_irq(unsigned int irq)
|
||||
pyxis_disable_irq(struct irq_data *d)
|
||||
{
|
||||
pyxis_update_irq_hw(cached_irq_mask &= ~(1UL << (irq - 16)));
|
||||
pyxis_update_irq_hw(cached_irq_mask &= ~(1UL << (d->irq - 16)));
|
||||
}
|
||||
|
||||
static void
|
||||
pyxis_mask_and_ack_irq(unsigned int irq)
|
||||
pyxis_mask_and_ack_irq(struct irq_data *d)
|
||||
{
|
||||
unsigned long bit = 1UL << (irq - 16);
|
||||
unsigned long bit = 1UL << (d->irq - 16);
|
||||
unsigned long mask = cached_irq_mask &= ~bit;
|
||||
|
||||
/* Disable the interrupt. */
|
||||
|
@ -58,9 +58,9 @@ pyxis_mask_and_ack_irq(unsigned int irq)
|
|||
|
||||
static struct irq_chip pyxis_irq_type = {
|
||||
.name = "PYXIS",
|
||||
.mask_ack = pyxis_mask_and_ack_irq,
|
||||
.mask = pyxis_disable_irq,
|
||||
.unmask = pyxis_enable_irq,
|
||||
.irq_mask_ack = pyxis_mask_and_ack_irq,
|
||||
.irq_mask = pyxis_disable_irq,
|
||||
.irq_unmask = pyxis_enable_irq,
|
||||
};
|
||||
|
||||
void
|
||||
|
@ -103,7 +103,7 @@ init_pyxis_irqs(unsigned long ignore_mask)
|
|||
if ((ignore_mask >> i) & 1)
|
||||
continue;
|
||||
set_irq_chip_and_handler(i, &pyxis_irq_type, handle_level_irq);
|
||||
irq_to_desc(i)->status |= IRQ_LEVEL;
|
||||
irq_set_status_flags(i, IRQ_LEVEL);
|
||||
}
|
||||
|
||||
setup_irq(16+7, &isa_cascade_irqaction);
|
||||
|
|
|
@ -18,27 +18,27 @@
|
|||
DEFINE_SPINLOCK(srm_irq_lock);
|
||||
|
||||
static inline void
|
||||
srm_enable_irq(unsigned int irq)
|
||||
srm_enable_irq(struct irq_data *d)
|
||||
{
|
||||
spin_lock(&srm_irq_lock);
|
||||
cserve_ena(irq - 16);
|
||||
cserve_ena(d->irq - 16);
|
||||
spin_unlock(&srm_irq_lock);
|
||||
}
|
||||
|
||||
static void
|
||||
srm_disable_irq(unsigned int irq)
|
||||
srm_disable_irq(struct irq_data *d)
|
||||
{
|
||||
spin_lock(&srm_irq_lock);
|
||||
cserve_dis(irq - 16);
|
||||
cserve_dis(d->irq - 16);
|
||||
spin_unlock(&srm_irq_lock);
|
||||
}
|
||||
|
||||
/* Handle interrupts from the SRM, assuming no additional weirdness. */
|
||||
static struct irq_chip srm_irq_type = {
|
||||
.name = "SRM",
|
||||
.unmask = srm_enable_irq,
|
||||
.mask = srm_disable_irq,
|
||||
.mask_ack = srm_disable_irq,
|
||||
.irq_unmask = srm_enable_irq,
|
||||
.irq_mask = srm_disable_irq,
|
||||
.irq_mask_ack = srm_disable_irq,
|
||||
};
|
||||
|
||||
void __init
|
||||
|
@ -52,7 +52,7 @@ init_srm_irqs(long max, unsigned long ignore_mask)
|
|||
if (i < 64 && ((ignore_mask >> i) & 1))
|
||||
continue;
|
||||
set_irq_chip_and_handler(i, &srm_irq_type, handle_level_irq);
|
||||
irq_to_desc(i)->status |= IRQ_LEVEL;
|
||||
irq_set_status_flags(i, IRQ_LEVEL);
|
||||
}
|
||||
}
|
||||
|
||||
|
|
|
@ -44,31 +44,31 @@ alcor_update_irq_hw(unsigned long mask)
|
|||
}
|
||||
|
||||
static inline void
|
||||
alcor_enable_irq(unsigned int irq)
|
||||
alcor_enable_irq(struct irq_data *d)
|
||||
{
|
||||
alcor_update_irq_hw(cached_irq_mask |= 1UL << (irq - 16));
|
||||
alcor_update_irq_hw(cached_irq_mask |= 1UL << (d->irq - 16));
|
||||
}
|
||||
|
||||
static void
|
||||
alcor_disable_irq(unsigned int irq)
|
||||
alcor_disable_irq(struct irq_data *d)
|
||||
{
|
||||
alcor_update_irq_hw(cached_irq_mask &= ~(1UL << (irq - 16)));
|
||||
alcor_update_irq_hw(cached_irq_mask &= ~(1UL << (d->irq - 16)));
|
||||
}
|
||||
|
||||
static void
|
||||
alcor_mask_and_ack_irq(unsigned int irq)
|
||||
alcor_mask_and_ack_irq(struct irq_data *d)
|
||||
{
|
||||
alcor_disable_irq(irq);
|
||||
alcor_disable_irq(d);
|
||||
|
||||
/* On ALCOR/XLT, need to dismiss interrupt via GRU. */
|
||||
*(vuip)GRU_INT_CLEAR = 1 << (irq - 16); mb();
|
||||
*(vuip)GRU_INT_CLEAR = 1 << (d->irq - 16); mb();
|
||||
*(vuip)GRU_INT_CLEAR = 0; mb();
|
||||
}
|
||||
|
||||
static void
|
||||
alcor_isa_mask_and_ack_irq(unsigned int irq)
|
||||
alcor_isa_mask_and_ack_irq(struct irq_data *d)
|
||||
{
|
||||
i8259a_mask_and_ack_irq(irq);
|
||||
i8259a_mask_and_ack_irq(d);
|
||||
|
||||
/* On ALCOR/XLT, need to dismiss interrupt via GRU. */
|
||||
*(vuip)GRU_INT_CLEAR = 0x80000000; mb();
|
||||
|
@ -77,9 +77,9 @@ alcor_isa_mask_and_ack_irq(unsigned int irq)
|
|||
|
||||
static struct irq_chip alcor_irq_type = {
|
||||
.name = "ALCOR",
|
||||
.unmask = alcor_enable_irq,
|
||||
.mask = alcor_disable_irq,
|
||||
.mask_ack = alcor_mask_and_ack_irq,
|
||||
.irq_unmask = alcor_enable_irq,
|
||||
.irq_mask = alcor_disable_irq,
|
||||
.irq_mask_ack = alcor_mask_and_ack_irq,
|
||||
};
|
||||
|
||||
static void
|
||||
|
@ -126,9 +126,9 @@ alcor_init_irq(void)
|
|||
if (i >= 16+20 && i <= 16+30)
|
||||
continue;
|
||||
set_irq_chip_and_handler(i, &alcor_irq_type, handle_level_irq);
|
||||
irq_to_desc(i)->status |= IRQ_LEVEL;
|
||||
irq_set_status_flags(i, IRQ_LEVEL);
|
||||
}
|
||||
i8259a_irq_type.ack = alcor_isa_mask_and_ack_irq;
|
||||
i8259a_irq_type.irq_ack = alcor_isa_mask_and_ack_irq;
|
||||
|
||||
init_i8259a_irqs();
|
||||
common_init_isa_dma();
|
||||
|
|
|
@ -46,22 +46,22 @@ cabriolet_update_irq_hw(unsigned int irq, unsigned long mask)
|
|||
}
|
||||
|
||||
static inline void
|
||||
cabriolet_enable_irq(unsigned int irq)
|
||||
cabriolet_enable_irq(struct irq_data *d)
|
||||
{
|
||||
cabriolet_update_irq_hw(irq, cached_irq_mask &= ~(1UL << irq));
|
||||
cabriolet_update_irq_hw(d->irq, cached_irq_mask &= ~(1UL << d->irq));
|
||||
}
|
||||
|
||||
static void
|
||||
cabriolet_disable_irq(unsigned int irq)
|
||||
cabriolet_disable_irq(struct irq_data *d)
|
||||
{
|
||||
cabriolet_update_irq_hw(irq, cached_irq_mask |= 1UL << irq);
|
||||
cabriolet_update_irq_hw(d->irq, cached_irq_mask |= 1UL << d->irq);
|
||||
}
|
||||
|
||||
static struct irq_chip cabriolet_irq_type = {
|
||||
.name = "CABRIOLET",
|
||||
.unmask = cabriolet_enable_irq,
|
||||
.mask = cabriolet_disable_irq,
|
||||
.mask_ack = cabriolet_disable_irq,
|
||||
.irq_unmask = cabriolet_enable_irq,
|
||||
.irq_mask = cabriolet_disable_irq,
|
||||
.irq_mask_ack = cabriolet_disable_irq,
|
||||
};
|
||||
|
||||
static void
|
||||
|
@ -107,7 +107,7 @@ common_init_irq(void (*srm_dev_int)(unsigned long v))
|
|||
for (i = 16; i < 35; ++i) {
|
||||
set_irq_chip_and_handler(i, &cabriolet_irq_type,
|
||||
handle_level_irq);
|
||||
irq_to_desc(i)->status |= IRQ_LEVEL;
|
||||
irq_set_status_flags(i, IRQ_LEVEL);
|
||||
}
|
||||
}
|
||||
|
||||
|
|
|
@ -98,37 +98,37 @@ tsunami_update_irq_hw(unsigned long mask)
|
|||
}
|
||||
|
||||
static void
|
||||
dp264_enable_irq(unsigned int irq)
|
||||
dp264_enable_irq(struct irq_data *d)
|
||||
{
|
||||
spin_lock(&dp264_irq_lock);
|
||||
cached_irq_mask |= 1UL << irq;
|
||||
cached_irq_mask |= 1UL << d->irq;
|
||||
tsunami_update_irq_hw(cached_irq_mask);
|
||||
spin_unlock(&dp264_irq_lock);
|
||||
}
|
||||
|
||||
static void
|
||||
dp264_disable_irq(unsigned int irq)
|
||||
dp264_disable_irq(struct irq_data *d)
|
||||
{
|
||||
spin_lock(&dp264_irq_lock);
|
||||
cached_irq_mask &= ~(1UL << irq);
|
||||
cached_irq_mask &= ~(1UL << d->irq);
|
||||
tsunami_update_irq_hw(cached_irq_mask);
|
||||
spin_unlock(&dp264_irq_lock);
|
||||
}
|
||||
|
||||
static void
|
||||
clipper_enable_irq(unsigned int irq)
|
||||
clipper_enable_irq(struct irq_data *d)
|
||||
{
|
||||
spin_lock(&dp264_irq_lock);
|
||||
cached_irq_mask |= 1UL << (irq - 16);
|
||||
cached_irq_mask |= 1UL << (d->irq - 16);
|
||||
tsunami_update_irq_hw(cached_irq_mask);
|
||||
spin_unlock(&dp264_irq_lock);
|
||||
}
|
||||
|
||||
static void
|
||||
clipper_disable_irq(unsigned int irq)
|
||||
clipper_disable_irq(struct irq_data *d)
|
||||
{
|
||||
spin_lock(&dp264_irq_lock);
|
||||
cached_irq_mask &= ~(1UL << (irq - 16));
|
||||
cached_irq_mask &= ~(1UL << (d->irq - 16));
|
||||
tsunami_update_irq_hw(cached_irq_mask);
|
||||
spin_unlock(&dp264_irq_lock);
|
||||
}
|
||||
|
@ -149,10 +149,11 @@ cpu_set_irq_affinity(unsigned int irq, cpumask_t affinity)
|
|||
}
|
||||
|
||||
static int
|
||||
dp264_set_affinity(unsigned int irq, const struct cpumask *affinity)
|
||||
{
|
||||
dp264_set_affinity(struct irq_data *d, const struct cpumask *affinity,
|
||||
bool force)
|
||||
{
|
||||
spin_lock(&dp264_irq_lock);
|
||||
cpu_set_irq_affinity(irq, *affinity);
|
||||
cpu_set_irq_affinity(d->irq, *affinity);
|
||||
tsunami_update_irq_hw(cached_irq_mask);
|
||||
spin_unlock(&dp264_irq_lock);
|
||||
|
||||
|
@ -160,10 +161,11 @@ dp264_set_affinity(unsigned int irq, const struct cpumask *affinity)
|
|||
}
|
||||
|
||||
static int
|
||||
clipper_set_affinity(unsigned int irq, const struct cpumask *affinity)
|
||||
{
|
||||
clipper_set_affinity(struct irq_data *d, const struct cpumask *affinity,
|
||||
bool force)
|
||||
{
|
||||
spin_lock(&dp264_irq_lock);
|
||||
cpu_set_irq_affinity(irq - 16, *affinity);
|
||||
cpu_set_irq_affinity(d->irq - 16, *affinity);
|
||||
tsunami_update_irq_hw(cached_irq_mask);
|
||||
spin_unlock(&dp264_irq_lock);
|
||||
|
||||
|
@ -171,19 +173,19 @@ clipper_set_affinity(unsigned int irq, const struct cpumask *affinity)
|
|||
}
|
||||
|
||||
static struct irq_chip dp264_irq_type = {
|
||||
.name = "DP264",
|
||||
.unmask = dp264_enable_irq,
|
||||
.mask = dp264_disable_irq,
|
||||
.mask_ack = dp264_disable_irq,
|
||||
.set_affinity = dp264_set_affinity,
|
||||
.name = "DP264",
|
||||
.irq_unmask = dp264_enable_irq,
|
||||
.irq_mask = dp264_disable_irq,
|
||||
.irq_mask_ack = dp264_disable_irq,
|
||||
.irq_set_affinity = dp264_set_affinity,
|
||||
};
|
||||
|
||||
static struct irq_chip clipper_irq_type = {
|
||||
.name = "CLIPPER",
|
||||
.unmask = clipper_enable_irq,
|
||||
.mask = clipper_disable_irq,
|
||||
.mask_ack = clipper_disable_irq,
|
||||
.set_affinity = clipper_set_affinity,
|
||||
.name = "CLIPPER",
|
||||
.irq_unmask = clipper_enable_irq,
|
||||
.irq_mask = clipper_disable_irq,
|
||||
.irq_mask_ack = clipper_disable_irq,
|
||||
.irq_set_affinity = clipper_set_affinity,
|
||||
};
|
||||
|
||||
static void
|
||||
|
@ -268,8 +270,8 @@ init_tsunami_irqs(struct irq_chip * ops, int imin, int imax)
|
|||
{
|
||||
long i;
|
||||
for (i = imin; i <= imax; ++i) {
|
||||
irq_to_desc(i)->status |= IRQ_LEVEL;
|
||||
set_irq_chip_and_handler(i, ops, handle_level_irq);
|
||||
irq_set_status_flags(i, IRQ_LEVEL);
|
||||
}
|
||||
}
|
||||
|
||||
|
|
|
@ -44,22 +44,22 @@ eb64p_update_irq_hw(unsigned int irq, unsigned long mask)
|
|||
}
|
||||
|
||||
static inline void
|
||||
eb64p_enable_irq(unsigned int irq)
|
||||
eb64p_enable_irq(struct irq_data *d)
|
||||
{
|
||||
eb64p_update_irq_hw(irq, cached_irq_mask &= ~(1 << irq));
|
||||
eb64p_update_irq_hw(d->irq, cached_irq_mask &= ~(1 << d->irq));
|
||||
}
|
||||
|
||||
static void
|
||||
eb64p_disable_irq(unsigned int irq)
|
||||
eb64p_disable_irq(struct irq_data *d)
|
||||
{
|
||||
eb64p_update_irq_hw(irq, cached_irq_mask |= 1 << irq);
|
||||
eb64p_update_irq_hw(d->irq, cached_irq_mask |= 1 << d->irq);
|
||||
}
|
||||
|
||||
static struct irq_chip eb64p_irq_type = {
|
||||
.name = "EB64P",
|
||||
.unmask = eb64p_enable_irq,
|
||||
.mask = eb64p_disable_irq,
|
||||
.mask_ack = eb64p_disable_irq,
|
||||
.irq_unmask = eb64p_enable_irq,
|
||||
.irq_mask = eb64p_disable_irq,
|
||||
.irq_mask_ack = eb64p_disable_irq,
|
||||
};
|
||||
|
||||
static void
|
||||
|
@ -118,9 +118,9 @@ eb64p_init_irq(void)
|
|||
init_i8259a_irqs();
|
||||
|
||||
for (i = 16; i < 32; ++i) {
|
||||
irq_to_desc(i)->status |= IRQ_LEVEL;
|
||||
set_irq_chip_and_handler(i, &eb64p_irq_type, handle_level_irq);
|
||||
}
|
||||
irq_set_status_flags(i, IRQ_LEVEL);
|
||||
}
|
||||
|
||||
common_init_isa_dma();
|
||||
setup_irq(16+5, &isa_cascade_irqaction);
|
||||
|
|
|
@ -51,16 +51,18 @@ eiger_update_irq_hw(unsigned long irq, unsigned long mask)
|
|||
}
|
||||
|
||||
static inline void
|
||||
eiger_enable_irq(unsigned int irq)
|
||||
eiger_enable_irq(struct irq_data *d)
|
||||
{
|
||||
unsigned int irq = d->irq;
|
||||
unsigned long mask;
|
||||
mask = (cached_irq_mask[irq >= 64] &= ~(1UL << (irq & 63)));
|
||||
eiger_update_irq_hw(irq, mask);
|
||||
}
|
||||
|
||||
static void
|
||||
eiger_disable_irq(unsigned int irq)
|
||||
eiger_disable_irq(struct irq_data *d)
|
||||
{
|
||||
unsigned int irq = d->irq;
|
||||
unsigned long mask;
|
||||
mask = (cached_irq_mask[irq >= 64] |= 1UL << (irq & 63));
|
||||
eiger_update_irq_hw(irq, mask);
|
||||
|
@ -68,9 +70,9 @@ eiger_disable_irq(unsigned int irq)
|
|||
|
||||
static struct irq_chip eiger_irq_type = {
|
||||
.name = "EIGER",
|
||||
.unmask = eiger_enable_irq,
|
||||
.mask = eiger_disable_irq,
|
||||
.mask_ack = eiger_disable_irq,
|
||||
.irq_unmask = eiger_enable_irq,
|
||||
.irq_mask = eiger_disable_irq,
|
||||
.irq_mask_ack = eiger_disable_irq,
|
||||
};
|
||||
|
||||
static void
|
||||
|
@ -136,8 +138,8 @@ eiger_init_irq(void)
|
|||
init_i8259a_irqs();
|
||||
|
||||
for (i = 16; i < 128; ++i) {
|
||||
irq_to_desc(i)->status |= IRQ_LEVEL;
|
||||
set_irq_chip_and_handler(i, &eiger_irq_type, handle_level_irq);
|
||||
irq_set_status_flags(i, IRQ_LEVEL);
|
||||
}
|
||||
}
|
||||
|
||||
|
|
|
@ -63,34 +63,34 @@
|
|||
*/
|
||||
|
||||
static void
|
||||
jensen_local_enable(unsigned int irq)
|
||||
jensen_local_enable(struct irq_data *d)
|
||||
{
|
||||
/* the parport is really hw IRQ 1, silly Jensen. */
|
||||
if (irq == 7)
|
||||
i8259a_enable_irq(1);
|
||||
if (d->irq == 7)
|
||||
i8259a_enable_irq(d);
|
||||
}
|
||||
|
||||
static void
|
||||
jensen_local_disable(unsigned int irq)
|
||||
jensen_local_disable(struct irq_data *d)
|
||||
{
|
||||
/* the parport is really hw IRQ 1, silly Jensen. */
|
||||
if (irq == 7)
|
||||
i8259a_disable_irq(1);
|
||||
if (d->irq == 7)
|
||||
i8259a_disable_irq(d);
|
||||
}
|
||||
|
||||
static void
|
||||
jensen_local_mask_ack(unsigned int irq)
|
||||
jensen_local_mask_ack(struct irq_data *d)
|
||||
{
|
||||
/* the parport is really hw IRQ 1, silly Jensen. */
|
||||
if (irq == 7)
|
||||
i8259a_mask_and_ack_irq(1);
|
||||
if (d->irq == 7)
|
||||
i8259a_mask_and_ack_irq(d);
|
||||
}
|
||||
|
||||
static struct irq_chip jensen_local_irq_type = {
|
||||
.name = "LOCAL",
|
||||
.unmask = jensen_local_enable,
|
||||
.mask = jensen_local_disable,
|
||||
.mask_ack = jensen_local_mask_ack,
|
||||
.irq_unmask = jensen_local_enable,
|
||||
.irq_mask = jensen_local_disable,
|
||||
.irq_mask_ack = jensen_local_mask_ack,
|
||||
};
|
||||
|
||||
static void
|
||||
|
|
|
@ -104,9 +104,10 @@ io7_get_irq_ctl(unsigned int irq, struct io7 **pio7)
|
|||
}
|
||||
|
||||
static void
|
||||
io7_enable_irq(unsigned int irq)
|
||||
io7_enable_irq(struct irq_data *d)
|
||||
{
|
||||
volatile unsigned long *ctl;
|
||||
unsigned int irq = d->irq;
|
||||
struct io7 *io7;
|
||||
|
||||
ctl = io7_get_irq_ctl(irq, &io7);
|
||||
|
@ -115,7 +116,7 @@ io7_enable_irq(unsigned int irq)
|
|||
__func__, irq);
|
||||
return;
|
||||
}
|
||||
|
||||
|
||||
spin_lock(&io7->irq_lock);
|
||||
*ctl |= 1UL << 24;
|
||||
mb();
|
||||
|
@ -124,9 +125,10 @@ io7_enable_irq(unsigned int irq)
|
|||
}
|
||||
|
||||
static void
|
||||
io7_disable_irq(unsigned int irq)
|
||||
io7_disable_irq(struct irq_data *d)
|
||||
{
|
||||
volatile unsigned long *ctl;
|
||||
unsigned int irq = d->irq;
|
||||
struct io7 *io7;
|
||||
|
||||
ctl = io7_get_irq_ctl(irq, &io7);
|
||||
|
@ -135,7 +137,7 @@ io7_disable_irq(unsigned int irq)
|
|||
__func__, irq);
|
||||
return;
|
||||
}
|
||||
|
||||
|
||||
spin_lock(&io7->irq_lock);
|
||||
*ctl &= ~(1UL << 24);
|
||||
mb();
|
||||
|
@ -144,35 +146,29 @@ io7_disable_irq(unsigned int irq)
|
|||
}
|
||||
|
||||
static void
|
||||
marvel_irq_noop(unsigned int irq)
|
||||
{
|
||||
return;
|
||||
}
|
||||
|
||||
static unsigned int
|
||||
marvel_irq_noop_return(unsigned int irq)
|
||||
{
|
||||
return 0;
|
||||
marvel_irq_noop(struct irq_data *d)
|
||||
{
|
||||
return;
|
||||
}
|
||||
|
||||
static struct irq_chip marvel_legacy_irq_type = {
|
||||
.name = "LEGACY",
|
||||
.mask = marvel_irq_noop,
|
||||
.unmask = marvel_irq_noop,
|
||||
.irq_mask = marvel_irq_noop,
|
||||
.irq_unmask = marvel_irq_noop,
|
||||
};
|
||||
|
||||
static struct irq_chip io7_lsi_irq_type = {
|
||||
.name = "LSI",
|
||||
.unmask = io7_enable_irq,
|
||||
.mask = io7_disable_irq,
|
||||
.mask_ack = io7_disable_irq,
|
||||
.irq_unmask = io7_enable_irq,
|
||||
.irq_mask = io7_disable_irq,
|
||||
.irq_mask_ack = io7_disable_irq,
|
||||
};
|
||||
|
||||
static struct irq_chip io7_msi_irq_type = {
|
||||
.name = "MSI",
|
||||
.unmask = io7_enable_irq,
|
||||
.mask = io7_disable_irq,
|
||||
.ack = marvel_irq_noop,
|
||||
.irq_unmask = io7_enable_irq,
|
||||
.irq_mask = io7_disable_irq,
|
||||
.irq_ack = marvel_irq_noop,
|
||||
};
|
||||
|
||||
static void
|
||||
|
@ -280,8 +276,8 @@ init_io7_irqs(struct io7 *io7,
|
|||
|
||||
/* Set up the lsi irqs. */
|
||||
for (i = 0; i < 128; ++i) {
|
||||
irq_to_desc(base + i)->status |= IRQ_LEVEL;
|
||||
set_irq_chip_and_handler(base + i, lsi_ops, handle_level_irq);
|
||||
irq_set_status_flags(i, IRQ_LEVEL);
|
||||
}
|
||||
|
||||
/* Disable the implemented irqs in hardware. */
|
||||
|
@ -294,8 +290,8 @@ init_io7_irqs(struct io7 *io7,
|
|||
|
||||
/* Set up the msi irqs. */
|
||||
for (i = 128; i < (128 + 512); ++i) {
|
||||
irq_to_desc(base + i)->status |= IRQ_LEVEL;
|
||||
set_irq_chip_and_handler(base + i, msi_ops, handle_level_irq);
|
||||
irq_set_status_flags(i, IRQ_LEVEL);
|
||||
}
|
||||
|
||||
for (i = 0; i < 16; ++i)
|
||||
|
|
|
@ -43,22 +43,22 @@ mikasa_update_irq_hw(int mask)
|
|||
}
|
||||
|
||||
static inline void
|
||||
mikasa_enable_irq(unsigned int irq)
|
||||
mikasa_enable_irq(struct irq_data *d)
|
||||
{
|
||||
mikasa_update_irq_hw(cached_irq_mask |= 1 << (irq - 16));
|
||||
mikasa_update_irq_hw(cached_irq_mask |= 1 << (d->irq - 16));
|
||||
}
|
||||
|
||||
static void
|
||||
mikasa_disable_irq(unsigned int irq)
|
||||
mikasa_disable_irq(struct irq_data *d)
|
||||
{
|
||||
mikasa_update_irq_hw(cached_irq_mask &= ~(1 << (irq - 16)));
|
||||
mikasa_update_irq_hw(cached_irq_mask &= ~(1 << (d->irq - 16)));
|
||||
}
|
||||
|
||||
static struct irq_chip mikasa_irq_type = {
|
||||
.name = "MIKASA",
|
||||
.unmask = mikasa_enable_irq,
|
||||
.mask = mikasa_disable_irq,
|
||||
.mask_ack = mikasa_disable_irq,
|
||||
.irq_unmask = mikasa_enable_irq,
|
||||
.irq_mask = mikasa_disable_irq,
|
||||
.irq_mask_ack = mikasa_disable_irq,
|
||||
};
|
||||
|
||||
static void
|
||||
|
@ -98,8 +98,8 @@ mikasa_init_irq(void)
|
|||
mikasa_update_irq_hw(0);
|
||||
|
||||
for (i = 16; i < 32; ++i) {
|
||||
irq_to_desc(i)->status |= IRQ_LEVEL;
|
||||
set_irq_chip_and_handler(i, &mikasa_irq_type, handle_level_irq);
|
||||
irq_set_status_flags(i, IRQ_LEVEL);
|
||||
}
|
||||
|
||||
init_i8259a_irqs();
|
||||
|
|
|
@ -48,22 +48,22 @@ noritake_update_irq_hw(int irq, int mask)
|
|||
}
|
||||
|
||||
static void
|
||||
noritake_enable_irq(unsigned int irq)
|
||||
noritake_enable_irq(struct irq_data *d)
|
||||
{
|
||||
noritake_update_irq_hw(irq, cached_irq_mask |= 1 << (irq - 16));
|
||||
noritake_update_irq_hw(d->irq, cached_irq_mask |= 1 << (d->irq - 16));
|
||||
}
|
||||
|
||||
static void
|
||||
noritake_disable_irq(unsigned int irq)
|
||||
noritake_disable_irq(struct irq_data *d)
|
||||
{
|
||||
noritake_update_irq_hw(irq, cached_irq_mask &= ~(1 << (irq - 16)));
|
||||
noritake_update_irq_hw(d->irq, cached_irq_mask &= ~(1 << (d->irq - 16)));
|
||||
}
|
||||
|
||||
static struct irq_chip noritake_irq_type = {
|
||||
.name = "NORITAKE",
|
||||
.unmask = noritake_enable_irq,
|
||||
.mask = noritake_disable_irq,
|
||||
.mask_ack = noritake_disable_irq,
|
||||
.irq_unmask = noritake_enable_irq,
|
||||
.irq_mask = noritake_disable_irq,
|
||||
.irq_mask_ack = noritake_disable_irq,
|
||||
};
|
||||
|
||||
static void
|
||||
|
@ -127,8 +127,8 @@ noritake_init_irq(void)
|
|||
outw(0, 0x54c);
|
||||
|
||||
for (i = 16; i < 48; ++i) {
|
||||
irq_to_desc(i)->status |= IRQ_LEVEL;
|
||||
set_irq_chip_and_handler(i, &noritake_irq_type, handle_level_irq);
|
||||
irq_set_status_flags(i, IRQ_LEVEL);
|
||||
}
|
||||
|
||||
init_i8259a_irqs();
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue