mirror of
https://github.com/armbian/linux.git
synced 2026-01-06 10:13:00 -08:00
Bump version to 3.4.113
This commit is contained in:
zador-blood-stained
@@ -345,14 +345,14 @@ the named feature on.
|
||||
The implementation is simple.
|
||||
|
||||
Setting the flag 'cpuset.memory_spread_page' turns on a per-process flag
|
||||
PF_SPREAD_PAGE for each task that is in that cpuset or subsequently
|
||||
PFA_SPREAD_PAGE for each task that is in that cpuset or subsequently
|
||||
joins that cpuset. The page allocation calls for the page cache
|
||||
is modified to perform an inline check for this PF_SPREAD_PAGE task
|
||||
is modified to perform an inline check for this PFA_SPREAD_PAGE task
|
||||
flag, and if set, a call to a new routine cpuset_mem_spread_node()
|
||||
returns the node to prefer for the allocation.
|
||||
|
||||
Similarly, setting 'cpuset.memory_spread_slab' turns on the flag
|
||||
PF_SPREAD_SLAB, and appropriately marked slab caches will allocate
|
||||
PFA_SPREAD_SLAB, and appropriately marked slab caches will allocate
|
||||
pages from the node returned by cpuset_mem_spread_node().
|
||||
|
||||
The cpuset_mem_spread_node() routine is also simple. It uses the
|
||||
|
||||
@@ -10,8 +10,8 @@ Required properties:
|
||||
|
||||
Optional properties:
|
||||
- fsl,card-wired : Indicate the card is wired to host permanently
|
||||
- fsl,cd-internal : Indicate to use controller internal card detection
|
||||
- fsl,wp-internal : Indicate to use controller internal write protection
|
||||
- fsl,cd-controller : Indicate to use controller internal card detection
|
||||
- fsl,wp-controller : Indicate to use controller internal write protection
|
||||
- cd-gpios : Specify GPIOs for card detection
|
||||
- wp-gpios : Specify GPIOs for write protection
|
||||
|
||||
@@ -21,8 +21,8 @@ esdhc@70004000 {
|
||||
compatible = "fsl,imx51-esdhc";
|
||||
reg = <0x70004000 0x4000>;
|
||||
interrupts = <1>;
|
||||
fsl,cd-internal;
|
||||
fsl,wp-internal;
|
||||
fsl,cd-controller;
|
||||
fsl,wp-controller;
|
||||
};
|
||||
|
||||
esdhc@70008000 {
|
||||
|
||||
@@ -10,6 +10,9 @@ Required properties:
|
||||
- "ns16850"
|
||||
- "nvidia,tegra20-uart"
|
||||
- "ibm,qpace-nwp-serial"
|
||||
- "altr,16550-FIFO32"
|
||||
- "altr,16550-FIFO64"
|
||||
- "altr,16550-FIFO128"
|
||||
- "serial" if the port type is unknown.
|
||||
- reg : offset and length of the register set for the device.
|
||||
- interrupts : should contain uart interrupt.
|
||||
|
||||
@@ -6,7 +6,9 @@ Supported chips:
|
||||
Prefix: 'coretemp'
|
||||
CPUID: family 0x6, models 0xe (Pentium M DC), 0xf (Core 2 DC 65nm),
|
||||
0x16 (Core 2 SC 65nm), 0x17 (Penryn 45nm),
|
||||
0x1a (Nehalem), 0x1c (Atom), 0x1e (Lynnfield)
|
||||
0x1a (Nehalem), 0x1c (Atom), 0x1e (Lynnfield),
|
||||
0x26 (Tunnel Creek Atom), 0x27 (Medfield Atom),
|
||||
0x36 (Cedar Trail Atom)
|
||||
Datasheet: Intel 64 and IA-32 Architectures Software Developer's Manual
|
||||
Volume 3A: System Programming Guide
|
||||
http://softwarecommunity.intel.com/Wiki/Mobility/720.htm
|
||||
@@ -65,6 +67,11 @@ Process Processor TjMax(C)
|
||||
U3400 105
|
||||
P4505/P4500 90
|
||||
|
||||
32nm Atom Processors
|
||||
Z2460 90
|
||||
D2700/2550/2500 100
|
||||
N2850/2800/2650/2600 100
|
||||
|
||||
45nm Xeon Processors 5400 Quad-Core
|
||||
X5492, X5482, X5472, X5470, X5460, X5450 85
|
||||
E5472, E5462, E5450/40/30/20/10/05 85
|
||||
@@ -85,6 +92,9 @@ Process Processor TjMax(C)
|
||||
N475/470/455/450 100
|
||||
N280/270 90
|
||||
330/230 125
|
||||
E680/660/640/620 90
|
||||
E680T/660T/640T/620T 110
|
||||
CE4170/4150/4110 110
|
||||
|
||||
45nm Core2 Processors
|
||||
Solo ULV SU3500/3300 100
|
||||
|
||||
@@ -22,6 +22,7 @@ Supported adapters:
|
||||
* Intel Panther Point (PCH)
|
||||
* Intel Lynx Point (PCH)
|
||||
* Intel Lynx Point-LP (PCH)
|
||||
* Intel Avoton (SOC)
|
||||
Datasheets: Publicly available at the Intel website
|
||||
|
||||
On Intel Patsburg and later chipsets, both the normal host SMBus controller
|
||||
|
||||
@@ -8,7 +8,7 @@ Supported adapters:
|
||||
Datasheet: Only available via NDA from ServerWorks
|
||||
* ATI IXP200, IXP300, IXP400, SB600, SB700 and SB800 southbridges
|
||||
Datasheet: Not publicly available
|
||||
* AMD Hudson-2
|
||||
* AMD Hudson-2, CZ
|
||||
Datasheet: Not publicly available
|
||||
* Standard Microsystems (SMSC) SLC90E66 (Victory66) southbridge
|
||||
Datasheet: Publicly available at the SMSC website http://www.smsc.com
|
||||
|
||||
@@ -315,7 +315,7 @@ Andrew Morton が Linux-kernel メーリングリストにカーネルリリー
|
||||
もし、2.6.x.y カーネルが存在しない場合には、番号が一番大きい 2.6.x が
|
||||
最新の安定版カーネルです。
|
||||
|
||||
2.6.x.y は "stable" チーム <stable@kernel.org> でメンテされており、必
|
||||
2.6.x.y は "stable" チーム <stable@vger.kernel.org> でメンテされており、必
|
||||
要に応じてリリースされます。通常のリリース期間は 2週間毎ですが、差し迫っ
|
||||
た問題がなければもう少し長くなることもあります。セキュリティ関連の問題
|
||||
の場合はこれに対してだいたいの場合、すぐにリリースがされます。
|
||||
|
||||
@@ -50,16 +50,16 @@ linux-2.6.29/Documentation/stable_kernel_rules.txt
|
||||
|
||||
-stable ツリーにパッチを送付する手続き-
|
||||
|
||||
- 上記の規則に従っているかを確認した後に、stable@kernel.org にパッチ
|
||||
- 上記の規則に従っているかを確認した後に、stable@vger.kernel.org にパッチ
|
||||
を送る。
|
||||
- 送信者はパッチがキューに受け付けられた際には ACK を、却下された場合
|
||||
には NAK を受け取る。この反応は開発者たちのスケジュールによって、数
|
||||
日かかる場合がある。
|
||||
- もし受け取られたら、パッチは他の開発者たちと関連するサブシステムの
|
||||
メンテナーによるレビューのために -stable キューに追加される。
|
||||
- パッチに stable@kernel.org のアドレスが付加されているときには、それ
|
||||
- パッチに stable@vger.kernel.org のアドレスが付加されているときには、それ
|
||||
が Linus のツリーに入る時に自動的に stable チームに email される。
|
||||
- セキュリティパッチはこのエイリアス (stable@kernel.org) に送られるべ
|
||||
- セキュリティパッチはこのエイリアス (stable@vger.kernel.org) に送られるべ
|
||||
きではなく、代わりに security@kernel.org のアドレスに送られる。
|
||||
|
||||
レビューサイクル-
|
||||
|
||||
@@ -782,6 +782,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||
edd= [EDD]
|
||||
Format: {"off" | "on" | "skip[mbr]"}
|
||||
|
||||
efi_no_storage_paranoia [EFI; X86]
|
||||
Using this parameter you can use more than 50% of
|
||||
your efi variable storage. Use this parameter only if
|
||||
you are really sure that your UEFI does sane gc and
|
||||
fulfills the spec otherwise your board may brick.
|
||||
|
||||
eisa_irq_edge= [PARISC,HW]
|
||||
See header of drivers/parisc/eisa.c.
|
||||
|
||||
@@ -982,6 +988,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||
i8042.notimeout [HW] Ignore timeout condition signalled by controller
|
||||
i8042.reset [HW] Reset the controller during init and cleanup
|
||||
i8042.unlock [HW] Unlock (ignore) the keylock
|
||||
i8042.kbdreset [HW] Reset device connected to KBD port
|
||||
|
||||
i810= [HW,DRM]
|
||||
|
||||
@@ -996,6 +1003,20 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||
i8k.restricted [HW] Allow controlling fans only if SYS_ADMIN
|
||||
capability is set.
|
||||
|
||||
i915.invert_brightness=
|
||||
[DRM] Invert the sense of the variable that is used to
|
||||
set the brightness of the panel backlight. Normally a
|
||||
brightness value of 0 indicates backlight switched off,
|
||||
and the maximum of the brightness value sets the backlight
|
||||
to maximum brightness. If this parameter is set to 0
|
||||
(default) and the machine requires it, or this parameter
|
||||
is set to 1, a brightness value of 0 sets the backlight
|
||||
to maximum brightness, and the maximum of the brightness
|
||||
value switches the backlight off.
|
||||
-1 -- never invert brightness
|
||||
0 -- machine default
|
||||
1 -- force brightness inversion
|
||||
|
||||
icn= [HW,ISDN]
|
||||
Format: <io>[,<membase>[,<icn_id>[,<icn_id2>]]]
|
||||
|
||||
|
||||
164
Documentation/lzo.txt
Normal file
164
Documentation/lzo.txt
Normal file
@@ -0,0 +1,164 @@
|
||||
|
||||
LZO stream format as understood by Linux's LZO decompressor
|
||||
===========================================================
|
||||
|
||||
Introduction
|
||||
|
||||
This is not a specification. No specification seems to be publicly available
|
||||
for the LZO stream format. This document describes what input format the LZO
|
||||
decompressor as implemented in the Linux kernel understands. The file subject
|
||||
of this analysis is lib/lzo/lzo1x_decompress_safe.c. No analysis was made on
|
||||
the compressor nor on any other implementations though it seems likely that
|
||||
the format matches the standard one. The purpose of this document is to
|
||||
better understand what the code does in order to propose more efficient fixes
|
||||
for future bug reports.
|
||||
|
||||
Description
|
||||
|
||||
The stream is composed of a series of instructions, operands, and data. The
|
||||
instructions consist in a few bits representing an opcode, and bits forming
|
||||
the operands for the instruction, whose size and position depend on the
|
||||
opcode and on the number of literals copied by previous instruction. The
|
||||
operands are used to indicate :
|
||||
|
||||
- a distance when copying data from the dictionary (past output buffer)
|
||||
- a length (number of bytes to copy from dictionary)
|
||||
- the number of literals to copy, which is retained in variable "state"
|
||||
as a piece of information for next instructions.
|
||||
|
||||
Optionally depending on the opcode and operands, extra data may follow. These
|
||||
extra data can be a complement for the operand (eg: a length or a distance
|
||||
encoded on larger values), or a literal to be copied to the output buffer.
|
||||
|
||||
The first byte of the block follows a different encoding from other bytes, it
|
||||
seems to be optimized for literal use only, since there is no dictionary yet
|
||||
prior to that byte.
|
||||
|
||||
Lengths are always encoded on a variable size starting with a small number
|
||||
of bits in the operand. If the number of bits isn't enough to represent the
|
||||
length, up to 255 may be added in increments by consuming more bytes with a
|
||||
rate of at most 255 per extra byte (thus the compression ratio cannot exceed
|
||||
around 255:1). The variable length encoding using #bits is always the same :
|
||||
|
||||
length = byte & ((1 << #bits) - 1)
|
||||
if (!length) {
|
||||
length = ((1 << #bits) - 1)
|
||||
length += 255*(number of zero bytes)
|
||||
length += first-non-zero-byte
|
||||
}
|
||||
length += constant (generally 2 or 3)
|
||||
|
||||
For references to the dictionary, distances are relative to the output
|
||||
pointer. Distances are encoded using very few bits belonging to certain
|
||||
ranges, resulting in multiple copy instructions using different encodings.
|
||||
Certain encodings involve one extra byte, others involve two extra bytes
|
||||
forming a little-endian 16-bit quantity (marked LE16 below).
|
||||
|
||||
After any instruction except the large literal copy, 0, 1, 2 or 3 literals
|
||||
are copied before starting the next instruction. The number of literals that
|
||||
were copied may change the meaning and behaviour of the next instruction. In
|
||||
practice, only one instruction needs to know whether 0, less than 4, or more
|
||||
literals were copied. This is the information stored in the <state> variable
|
||||
in this implementation. This number of immediate literals to be copied is
|
||||
generally encoded in the last two bits of the instruction but may also be
|
||||
taken from the last two bits of an extra operand (eg: distance).
|
||||
|
||||
End of stream is declared when a block copy of distance 0 is seen. Only one
|
||||
instruction may encode this distance (0001HLLL), it takes one LE16 operand
|
||||
for the distance, thus requiring 3 bytes.
|
||||
|
||||
IMPORTANT NOTE : in the code some length checks are missing because certain
|
||||
instructions are called under the assumption that a certain number of bytes
|
||||
follow because it has already been garanteed before parsing the instructions.
|
||||
They just have to "refill" this credit if they consume extra bytes. This is
|
||||
an implementation design choice independant on the algorithm or encoding.
|
||||
|
||||
Byte sequences
|
||||
|
||||
First byte encoding :
|
||||
|
||||
0..17 : follow regular instruction encoding, see below. It is worth
|
||||
noting that codes 16 and 17 will represent a block copy from
|
||||
the dictionary which is empty, and that they will always be
|
||||
invalid at this place.
|
||||
|
||||
18..21 : copy 0..3 literals
|
||||
state = (byte - 17) = 0..3 [ copy <state> literals ]
|
||||
skip byte
|
||||
|
||||
22..255 : copy literal string
|
||||
length = (byte - 17) = 4..238
|
||||
state = 4 [ don't copy extra literals ]
|
||||
skip byte
|
||||
|
||||
Instruction encoding :
|
||||
|
||||
0 0 0 0 X X X X (0..15)
|
||||
Depends on the number of literals copied by the last instruction.
|
||||
If last instruction did not copy any literal (state == 0), this
|
||||
encoding will be a copy of 4 or more literal, and must be interpreted
|
||||
like this :
|
||||
|
||||
0 0 0 0 L L L L (0..15) : copy long literal string
|
||||
length = 3 + (L ?: 15 + (zero_bytes * 255) + non_zero_byte)
|
||||
state = 4 (no extra literals are copied)
|
||||
|
||||
If last instruction used to copy between 1 to 3 literals (encoded in
|
||||
the instruction's opcode or distance), the instruction is a copy of a
|
||||
2-byte block from the dictionary within a 1kB distance. It is worth
|
||||
noting that this instruction provides little savings since it uses 2
|
||||
bytes to encode a copy of 2 other bytes but it encodes the number of
|
||||
following literals for free. It must be interpreted like this :
|
||||
|
||||
0 0 0 0 D D S S (0..15) : copy 2 bytes from <= 1kB distance
|
||||
length = 2
|
||||
state = S (copy S literals after this block)
|
||||
Always followed by exactly one byte : H H H H H H H H
|
||||
distance = (H << 2) + D + 1
|
||||
|
||||
If last instruction used to copy 4 or more literals (as detected by
|
||||
state == 4), the instruction becomes a copy of a 3-byte block from the
|
||||
dictionary from a 2..3kB distance, and must be interpreted like this :
|
||||
|
||||
0 0 0 0 D D S S (0..15) : copy 3 bytes from 2..3 kB distance
|
||||
length = 3
|
||||
state = S (copy S literals after this block)
|
||||
Always followed by exactly one byte : H H H H H H H H
|
||||
distance = (H << 2) + D + 2049
|
||||
|
||||
0 0 0 1 H L L L (16..31)
|
||||
Copy of a block within 16..48kB distance (preferably less than 10B)
|
||||
length = 2 + (L ?: 7 + (zero_bytes * 255) + non_zero_byte)
|
||||
Always followed by exactly one LE16 : D D D D D D D D : D D D D D D S S
|
||||
distance = 16384 + (H << 14) + D
|
||||
state = S (copy S literals after this block)
|
||||
End of stream is reached if distance == 16384
|
||||
|
||||
0 0 1 L L L L L (32..63)
|
||||
Copy of small block within 16kB distance (preferably less than 34B)
|
||||
length = 2 + (L ?: 31 + (zero_bytes * 255) + non_zero_byte)
|
||||
Always followed by exactly one LE16 : D D D D D D D D : D D D D D D S S
|
||||
distance = D + 1
|
||||
state = S (copy S literals after this block)
|
||||
|
||||
0 1 L D D D S S (64..127)
|
||||
Copy 3-4 bytes from block within 2kB distance
|
||||
state = S (copy S literals after this block)
|
||||
length = 3 + L
|
||||
Always followed by exactly one byte : H H H H H H H H
|
||||
distance = (H << 3) + D + 1
|
||||
|
||||
1 L L D D D S S (128..255)
|
||||
Copy 5-8 bytes from block within 2kB distance
|
||||
state = S (copy S literals after this block)
|
||||
length = 5 + L
|
||||
Always followed by exactly one byte : H H H H H H H H
|
||||
distance = (H << 3) + D + 1
|
||||
|
||||
Authors
|
||||
|
||||
This document was written by Willy Tarreau <w@1wt.eu> on 2014/07/19 during an
|
||||
analysis of the decompression code available in Linux 3.16-rc5. The code is
|
||||
tricky, it is possible that this document contains mistakes or that a few
|
||||
corner cases were overlooked. In any case, please report any doubt, fix, or
|
||||
proposed updates to the author(s) so that the document can be updated.
|
||||
@@ -24,17 +24,33 @@ For monitoring and control pktgen creates:
|
||||
/proc/net/pktgen/ethX
|
||||
|
||||
|
||||
Viewing threads
|
||||
===============
|
||||
/proc/net/pktgen/kpktgend_0
|
||||
Name: kpktgend_0 max_before_softirq: 10000
|
||||
Running:
|
||||
Stopped: eth1
|
||||
Result: OK: max_before_softirq=10000
|
||||
Kernel threads
|
||||
==============
|
||||
Pktgen creates a thread for each CPU with affinity to that CPU.
|
||||
Which is controlled through procfile /proc/net/pktgen/kpktgend_X.
|
||||
|
||||
Most important the devices assigned to thread. Note! A device can only belong
|
||||
to one thread.
|
||||
Example: /proc/net/pktgen/kpktgend_0
|
||||
|
||||
Running:
|
||||
Stopped: eth4@0
|
||||
Result: OK: add_device=eth4@0
|
||||
|
||||
Most important are the devices assigned to the thread.
|
||||
|
||||
The two basic thread commands are:
|
||||
* add_device DEVICE@NAME -- adds a single device
|
||||
* rem_device_all -- remove all associated devices
|
||||
|
||||
When adding a device to a thread, a corrosponding procfile is created
|
||||
which is used for configuring this device. Thus, device names need to
|
||||
be unique.
|
||||
|
||||
To support adding the same device to multiple threads, which is useful
|
||||
with multi queue NICs, a the device naming scheme is extended with "@":
|
||||
device@something
|
||||
|
||||
The part after "@" can be anything, but it is custom to use the thread
|
||||
number.
|
||||
|
||||
Viewing devices
|
||||
===============
|
||||
@@ -42,29 +58,32 @@ Viewing devices
|
||||
Parm section holds configured info. Current hold running stats.
|
||||
Result is printed after run or after interruption. Example:
|
||||
|
||||
/proc/net/pktgen/eth1
|
||||
/proc/net/pktgen/eth4@0
|
||||
|
||||
Params: count 10000000 min_pkt_size: 60 max_pkt_size: 60
|
||||
frags: 0 delay: 0 clone_skb: 1000000 ifname: eth1
|
||||
Params: count 100000 min_pkt_size: 60 max_pkt_size: 60
|
||||
frags: 0 delay: 0 clone_skb: 64 ifname: eth4@0
|
||||
flows: 0 flowlen: 0
|
||||
dst_min: 10.10.11.2 dst_max:
|
||||
src_min: src_max:
|
||||
src_mac: 00:00:00:00:00:00 dst_mac: 00:04:23:AC:FD:82
|
||||
udp_src_min: 9 udp_src_max: 9 udp_dst_min: 9 udp_dst_max: 9
|
||||
src_mac_count: 0 dst_mac_count: 0
|
||||
Flags:
|
||||
Current:
|
||||
pkts-sofar: 10000000 errors: 39664
|
||||
started: 1103053986245187us stopped: 1103053999346329us idle: 880401us
|
||||
seq_num: 10000011 cur_dst_mac_offset: 0 cur_src_mac_offset: 0
|
||||
cur_saddr: 0x10a0a0a cur_daddr: 0x20b0a0a
|
||||
cur_udp_dst: 9 cur_udp_src: 9
|
||||
queue_map_min: 0 queue_map_max: 0
|
||||
dst_min: 192.168.81.2 dst_max:
|
||||
src_min: src_max:
|
||||
src_mac: 90:e2:ba:0a:56:b4 dst_mac: 00:1b:21:3c:9d:f8
|
||||
udp_src_min: 9 udp_src_max: 109 udp_dst_min: 9 udp_dst_max: 9
|
||||
src_mac_count: 0 dst_mac_count: 0
|
||||
Flags: UDPSRC_RND NO_TIMESTAMP QUEUE_MAP_CPU
|
||||
Current:
|
||||
pkts-sofar: 100000 errors: 0
|
||||
started: 623913381008us stopped: 623913396439us idle: 25us
|
||||
seq_num: 100001 cur_dst_mac_offset: 0 cur_src_mac_offset: 0
|
||||
cur_saddr: 192.168.8.3 cur_daddr: 192.168.81.2
|
||||
cur_udp_dst: 9 cur_udp_src: 42
|
||||
cur_queue_map:
|
||||
flows: 0
|
||||
Result: OK: 13101142(c12220741+d880401) usec, 10000000 (60byte,0frags)
|
||||
763292pps 390Mb/sec (390805504bps) errors: 39664
|
||||
Result: OK: 15430(c15405d25) usec, 100000 (60byte,0frags)
|
||||
6480562pps 3110Mb/sec (3110669760bps) errors: 0
|
||||
|
||||
Configuring threads and devices
|
||||
================================
|
||||
|
||||
Configuring devices
|
||||
===================
|
||||
This is done via the /proc interface easiest done via pgset in the scripts
|
||||
|
||||
Examples:
|
||||
@@ -177,6 +196,8 @@ Note when adding devices to a specific CPU there good idea to also assign
|
||||
/proc/irq/XX/smp_affinity so the TX-interrupts gets bound to the same CPU.
|
||||
as this reduces cache bouncing when freeing skb's.
|
||||
|
||||
Plus using the device flag QUEUE_MAP_CPU, which maps the SKBs TX queue
|
||||
to the running threads CPU (directly from smp_processor_id()).
|
||||
|
||||
Current commands and configuration options
|
||||
==========================================
|
||||
|
||||
@@ -62,11 +62,10 @@ Socket Interface
|
||||
================
|
||||
|
||||
AF_RDS, PF_RDS, SOL_RDS
|
||||
These constants haven't been assigned yet, because RDS isn't in
|
||||
mainline yet. Currently, the kernel module assigns some constant
|
||||
and publishes it to user space through two sysctl files
|
||||
/proc/sys/net/rds/pf_rds
|
||||
/proc/sys/net/rds/sol_rds
|
||||
AF_RDS and PF_RDS are the domain type to be used with socket(2)
|
||||
to create RDS sockets. SOL_RDS is the socket-level to be used
|
||||
with setsockopt(2) and getsockopt(2) for RDS specific socket
|
||||
options.
|
||||
|
||||
fd = socket(PF_RDS, SOCK_SEQPACKET, 0);
|
||||
This creates a new, unbound RDS socket.
|
||||
|
||||
@@ -72,7 +72,6 @@ static struct pinctrl_desc foo_desc = {
|
||||
.name = "foo",
|
||||
.pins = foo_pins,
|
||||
.npins = ARRAY_SIZE(foo_pins),
|
||||
.maxpin = 63,
|
||||
.owner = THIS_MODULE,
|
||||
};
|
||||
|
||||
@@ -166,8 +165,8 @@ static const char *foo_get_group_name(struct pinctrl_dev *pctldev,
|
||||
}
|
||||
|
||||
static int foo_get_group_pins(struct pinctrl_dev *pctldev, unsigned selector,
|
||||
unsigned ** const pins,
|
||||
unsigned * const num_pins)
|
||||
const unsigned **pins,
|
||||
unsigned *num_pins)
|
||||
{
|
||||
*pins = (unsigned *) foo_groups[selector].pins;
|
||||
*num_pins = foo_groups[selector].num_pins;
|
||||
@@ -1043,7 +1042,7 @@ The semantics of the pinctrl APIs are:
|
||||
|
||||
Usually the pin control core handled the get/put pair and call out to the
|
||||
device drivers bookkeeping operations, like checking available functions and
|
||||
the associated pins, whereas the enable/disable pass on to the pin controller
|
||||
the associated pins, whereas select_state pass on to the pin controller
|
||||
driver which takes care of activating and/or deactivating the mux setting by
|
||||
quickly poking some registers.
|
||||
|
||||
@@ -1089,8 +1088,9 @@ function, but with different named in the mapping as described under
|
||||
"Advanced mapping" above. So that for an SPI device, we have two states named
|
||||
"pos-A" and "pos-B".
|
||||
|
||||
This snippet first muxes the function in the pins defined by group A, enables
|
||||
it, disables and releases it, and muxes it in on the pins defined by group B:
|
||||
This snippet first initializes a state object for both groups (in foo_probe()),
|
||||
then muxes the function in the pins defined by group A, and finally muxes it in
|
||||
on the pins defined by group B:
|
||||
|
||||
#include <linux/pinctrl/consumer.h>
|
||||
|
||||
|
||||
@@ -29,6 +29,9 @@ Rules on what kind of patches are accepted, and which ones are not, into the
|
||||
|
||||
Procedure for submitting patches to the -stable tree:
|
||||
|
||||
- If the patch covers files in net/ or drivers/net please follow netdev stable
|
||||
submission guidelines as described in
|
||||
Documentation/networking/netdev-FAQ.txt
|
||||
- Send the patch, after verifying that it follows the above rules, to
|
||||
stable@vger.kernel.org. You must note the upstream commit ID in the
|
||||
changelog of your submission, as well as the kernel version you wish
|
||||
|
||||
@@ -284,13 +284,24 @@ Default value is "/sbin/hotplug".
|
||||
kptr_restrict:
|
||||
|
||||
This toggle indicates whether restrictions are placed on
|
||||
exposing kernel addresses via /proc and other interfaces. When
|
||||
kptr_restrict is set to (0), there are no restrictions. When
|
||||
kptr_restrict is set to (1), the default, kernel pointers
|
||||
printed using the %pK format specifier will be replaced with 0's
|
||||
unless the user has CAP_SYSLOG. When kptr_restrict is set to
|
||||
(2), kernel pointers printed using %pK will be replaced with 0's
|
||||
regardless of privileges.
|
||||
exposing kernel addresses via /proc and other interfaces.
|
||||
|
||||
When kptr_restrict is set to (0), the default, there are no restrictions.
|
||||
|
||||
When kptr_restrict is set to (1), kernel pointers printed using the %pK
|
||||
format specifier will be replaced with 0's unless the user has CAP_SYSLOG
|
||||
and effective user and group ids are equal to the real ids. This is
|
||||
because %pK checks are done at read() time rather than open() time, so
|
||||
if permissions are elevated between the open() and the read() (e.g via
|
||||
a setuid binary) then %pK will not leak kernel pointers to unprivileged
|
||||
users. Note, this is a temporary solution only. The correct long-term
|
||||
solution is to do the permission checks at open() time. Consider removing
|
||||
world read permissions from files that use %pK, and using dmesg_restrict
|
||||
to protect against uses of %pK in dmesg(8) if leaking kernel pointer
|
||||
values to unprivileged users is a concern.
|
||||
|
||||
When kptr_restrict is set to (2), kernel pointers printed using
|
||||
%pK will be replaced with 0's regardless of privileges.
|
||||
|
||||
==============================================================
|
||||
|
||||
|
||||
@@ -12,6 +12,8 @@ ffffc90000000000 - ffffe8ffffffffff (=45 bits) vmalloc/ioremap space
|
||||
ffffe90000000000 - ffffe9ffffffffff (=40 bits) hole
|
||||
ffffea0000000000 - ffffeaffffffffff (=40 bits) virtual memory map (1TB)
|
||||
... unused hole ...
|
||||
ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp fixup stacks
|
||||
... unused hole ...
|
||||
ffffffff80000000 - ffffffffa0000000 (=512 MB) kernel text mapping, from phys 0
|
||||
ffffffffa0000000 - fffffffffff00000 (=1536 MB) module mapping space
|
||||
|
||||
|
||||
@@ -237,7 +237,7 @@ kernel.org网站的pub/linux/kernel/v2.6/目录下找到它。它的开发遵循
|
||||
如果没有2.6.x.y版本内核存在，那么最新的2.6.x版本内核就相当于是当前的稳定
|
||||
版内核。
|
||||
|
||||
2.6.x.y版本由“稳定版”小组（邮件地址<stable@kernel.org>）维护，一般隔周发
|
||||
2.6.x.y版本由“稳定版”小组（邮件地址<stable@vger.kernel.org>）维护，一般隔周发
|
||||
布新版本。
|
||||
|
||||
内核源码中的Documentation/stable_kernel_rules.txt文件具体描述了可被稳定
|
||||
|
||||
@@ -42,7 +42,7 @@ Documentation/stable_kernel_rules.txt 的中文翻译
|
||||
|
||||
向稳定版代码树提交补丁的过程：
|
||||
|
||||
- 在确认了补丁符合以上的规则后，将补丁发送到stable@kernel.org。
|
||||
- 在确认了补丁符合以上的规则后，将补丁发送到stable@vger.kernel.org。
|
||||
- 如果补丁被接受到队列里，发送者会收到一个ACK回复，如果没有被接受，收
|
||||
到的是NAK回复。回复需要几天的时间，这取决于开发者的时间安排。
|
||||
- 被接受的补丁会被加到稳定版本队列里，等待其他开发者的审查。
|
||||
|
||||
@@ -6390,6 +6390,7 @@ STABLE BRANCH
|
||||
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
L: stable@vger.kernel.org
|
||||
S: Supported
|
||||
F: Documentation/stable_kernel_rules.txt
|
||||
|
||||
STAGING SUBSYSTEM
|
||||
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
|
||||
4
Makefile
4
Makefile
@@ -1,6 +1,6 @@
|
||||
VERSION = 3
|
||||
PATCHLEVEL = 4
|
||||
SUBLEVEL = 39
|
||||
SUBLEVEL = 113
|
||||
EXTRAVERSION =
|
||||
NAME = Saber-toothed Squirrel
|
||||
|
||||
@@ -593,6 +593,8 @@ KBUILD_CFLAGS += -fomit-frame-pointer
|
||||
endif
|
||||
endif
|
||||
|
||||
KBUILD_CFLAGS += $(call cc-option, -fno-var-tracking-assignments)
|
||||
|
||||
ifdef CONFIG_DEBUG_INFO
|
||||
KBUILD_CFLAGS += -g
|
||||
KBUILD_AFLAGS += -gdwarf-2
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user