Skip to content

Commit a5e8546

Browse files
committed
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6 into lvs-next-2.6
2 parents cb7f6a7 + c700448 commit a5e8546

File tree

636 files changed

+14959
-9928
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

636 files changed

+14959
-9928
lines changed

.mailmap

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -96,4 +96,6 @@ Tejun Heo <[email protected]>
9696
Thomas Graf <[email protected]>
9797
Tony Luck <[email protected]>
9898
Tsuneo Yoshioka <[email protected]>
99+
Uwe Kleine-König <[email protected]>
100+
Uwe Kleine-König <[email protected]>
99101
Valdis Kletnieks <[email protected]>
Lines changed: 26 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,26 @@
1+
What: /sys/class/gpio/
2+
Date: July 2008
3+
KernelVersion: 2.6.27
4+
Contact: David Brownell <[email protected]>
5+
Description:
6+
7+
As a Kconfig option, individual GPIO signals may be accessed from
8+
userspace. GPIOs are only made available to userspace by an explicit
9+
"export" operation. If a given GPIO is not claimed for use by
10+
kernel code, it may be exported by userspace (and unexported later).
11+
Kernel code may export it for complete or partial access.
12+
13+
GPIOs are identified as they are inside the kernel, using integers in
14+
the range 0..INT_MAX. See Documentation/gpio.txt for more information.
15+
16+
/sys/class/gpio
17+
/export ... asks the kernel to export a GPIO to userspace
18+
/unexport ... to return a GPIO to the kernel
19+
/gpioN ... for each exported GPIO #N
20+
/value ... always readable, writes fail for input GPIOs
21+
/direction ... r/w as: in, out (default low); write: high, low
22+
/gpiochipN ... for each gpiochip; #N is its first GPIO
23+
/base ... (r/o) same as N
24+
/label ... (r/o) descriptive, not necessarily unique
25+
/ngpio ... (r/o) number of GPIOs; numbered N to N + (ngpio - 1)
26+

Documentation/DMA-mapping.txt

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -740,7 +740,7 @@ failure can be determined by:
740740
dma_addr_t dma_handle;
741741

742742
dma_handle = pci_map_single(pdev, addr, size, direction);
743-
if (pci_dma_mapping_error(dma_handle)) {
743+
if (pci_dma_mapping_error(pdev, dma_handle)) {
744744
/*
745745
* reduce current DMA mapping usage,
746746
* delay and try again later or

Documentation/cpusets.txt

Lines changed: 10 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -635,14 +635,16 @@ prior 'mems' setting, will not be moved.
635635

636636
There is an exception to the above. If hotplug functionality is used
637637
to remove all the CPUs that are currently assigned to a cpuset,
638-
then the kernel will automatically update the cpus_allowed of all
639-
tasks attached to CPUs in that cpuset to allow all CPUs. When memory
640-
hotplug functionality for removing Memory Nodes is available, a
641-
similar exception is expected to apply there as well. In general,
642-
the kernel prefers to violate cpuset placement, over starving a task
643-
that has had all its allowed CPUs or Memory Nodes taken offline. User
644-
code should reconfigure cpusets to only refer to online CPUs and Memory
645-
Nodes when using hotplug to add or remove such resources.
638+
then all the tasks in that cpuset will be moved to the nearest ancestor
639+
with non-empty cpus. But the moving of some (or all) tasks might fail if
640+
cpuset is bound with another cgroup subsystem which has some restrictions
641+
on task attaching. In this failing case, those tasks will stay
642+
in the original cpuset, and the kernel will automatically update
643+
their cpus_allowed to allow all online CPUs. When memory hotplug
644+
functionality for removing Memory Nodes is available, a similar exception
645+
is expected to apply there as well. In general, the kernel prefers to
646+
violate cpuset placement, over starving a task that has had all
647+
its allowed CPUs or Memory Nodes taken offline.
646648

647649
There is a second exception to the above. GFP_ATOMIC requests are
648650
kernel internal allocations that must be satisfied, immediately.

Documentation/feature-removal-schedule.txt

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -340,3 +340,11 @@ Why: Accounting can now be enabled/disabled without kernel recompilation.
340340
controlled by a kernel/module/sysfs/sysctl parameter.
341341
Who: Krzysztof Piotr Oledzki <[email protected]>
342342

343+
---------------------------
344+
345+
What: ide-scsi (BLK_DEV_IDESCSI)
346+
When: 2.6.29
347+
Why: The 2.6 kernel supports direct writing to ide CD drives, which
348+
eliminates the need for ide-scsi. The new method is more
349+
efficient in every way.
350+
Who: FUJITA Tomonori <[email protected]>

Documentation/filesystems/Locking

Lines changed: 4 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -144,8 +144,8 @@ prototypes:
144144
void (*kill_sb) (struct super_block *);
145145
locking rules:
146146
may block BKL
147-
get_sb yes yes
148-
kill_sb yes yes
147+
get_sb yes no
148+
kill_sb yes no
149149

150150
->get_sb() returns error or 0 with locked superblock attached to the vfsmount
151151
(exclusive on ->s_umount).
@@ -409,12 +409,12 @@ ioctl: yes (see below)
409409
unlocked_ioctl: no (see below)
410410
compat_ioctl: no
411411
mmap: no
412-
open: maybe (see below)
412+
open: no
413413
flush: no
414414
release: no
415415
fsync: no (see below)
416416
aio_fsync: no
417-
fasync: yes (see below)
417+
fasync: no
418418
lock: yes
419419
readv: no
420420
writev: no
@@ -431,13 +431,6 @@ For many filesystems, it is probably safe to acquire the inode
431431
semaphore. Note some filesystems (i.e. remote ones) provide no
432432
protection for i_size so you will need to use the BKL.
433433

434-
->open() locking is in-transit: big lock partially moved into the methods.
435-
The only exception is ->open() in the instances of file_operations that never
436-
end up in ->i_fop/->proc_fops, i.e. ones that belong to character devices
437-
(chrdev_open() takes lock before replacing ->f_op and calling the secondary
438-
method. As soon as we fix the handling of module reference counters all
439-
instances of ->open() will be called without the BKL.
440-
441434
Note: ext2_release() was *the* source of contention on fs-intensive
442435
loads and dropping BKL on ->release() helps to get rid of that (we still
443436
grab BKL for cases when we close a file that had been opened r/w, but that

Documentation/filesystems/proc.txt

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2413,6 +2413,8 @@ The following 4 memory types are supported:
24132413
- (bit 1) anonymous shared memory
24142414
- (bit 2) file-backed private memory
24152415
- (bit 3) file-backed shared memory
2416+
- (bit 4) ELF header pages in file-backed private memory areas (it is
2417+
effective only if the bit 2 is cleared)
24162418

24172419
Note that MMIO pages such as frame buffer are never dumped and vDSO pages
24182420
are always dumped regardless of the bitmask status.

Documentation/ioctl/cdrom.txt

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -271,14 +271,14 @@ CDROMCLOSETRAY pendant of CDROMEJECT
271271

272272
usage:
273273

274-
ioctl(fd, CDROMEJECT, 0);
274+
ioctl(fd, CDROMCLOSETRAY, 0);
275275

276276
inputs: none
277277

278278
outputs: none
279279

280280
error returns:
281-
ENOSYS cd drive not capable of ejecting
281+
ENOSYS cd drive not capable of closing the tray
282282
EBUSY other processes are accessing drive, or door is locked
283283

284284
notes:

Documentation/networking/can.txt

Lines changed: 40 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -35,8 +35,9 @@ This file contains
3535
6.1 general settings
3636
6.2 local loopback of sent frames
3737
6.3 CAN controller hardware filters
38-
6.4 currently supported CAN hardware
39-
6.5 todo
38+
6.4 The virtual CAN driver (vcan)
39+
6.5 currently supported CAN hardware
40+
6.6 todo
4041

4142
7 Credits
4243

@@ -584,7 +585,42 @@ solution for a couple of reasons:
584585
@133MHz with four SJA1000 CAN controllers from 2002 under heavy bus
585586
load without any problems ...
586587

587-
6.4 currently supported CAN hardware (September 2007)
588+
6.4 The virtual CAN driver (vcan)
589+
590+
Similar to the network loopback devices, vcan offers a virtual local
591+
CAN interface. A full qualified address on CAN consists of
592+
593+
- a unique CAN Identifier (CAN ID)
594+
- the CAN bus this CAN ID is transmitted on (e.g. can0)
595+
596+
so in common use cases more than one virtual CAN interface is needed.
597+
598+
The virtual CAN interfaces allow the transmission and reception of CAN
599+
frames without real CAN controller hardware. Virtual CAN network
600+
devices are usually named 'vcanX', like vcan0 vcan1 vcan2 ...
601+
When compiled as a module the virtual CAN driver module is called vcan.ko
602+
603+
Since Linux Kernel version 2.6.24 the vcan driver supports the Kernel
604+
netlink interface to create vcan network devices. The creation and
605+
removal of vcan network devices can be managed with the ip(8) tool:
606+
607+
- Create a virtual CAN network interface:
608+
ip link add type vcan
609+
610+
- Create a virtual CAN network interface with a specific name 'vcan42':
611+
ip link add dev vcan42 type vcan
612+
613+
- Remove a (virtual CAN) network interface 'vcan42':
614+
ip link del vcan42
615+
616+
The tool 'vcan' from the SocketCAN SVN repository on BerliOS is obsolete.
617+
618+
Virtual CAN network device creation in older Kernels:
619+
In Linux Kernel versions < 2.6.24 the vcan driver creates 4 vcan
620+
netdevices at module load time by default. This value can be changed
621+
with the module parameter 'numdev'. E.g. 'modprobe vcan numdev=8'
622+
623+
6.5 currently supported CAN hardware
588624

589625
On the project website http://developer.berlios.de/projects/socketcan
590626
there are different drivers available:
@@ -603,7 +639,7 @@ solution for a couple of reasons:
603639

604640
Please check the Mailing Lists on the berlios OSS project website.
605641

606-
6.5 todo (September 2007)
642+
6.6 todo
607643

608644
The configuration interface for CAN network drivers is still an open
609645
issue that has not been finalized in the socketcan project. Also the
Lines changed: 175 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,175 @@
1+
Linux Phonet protocol family
2+
============================
3+
4+
Introduction
5+
------------
6+
7+
Phonet is a packet protocol used by Nokia cellular modems for both IPC
8+
and RPC. With the Linux Phonet socket family, Linux host processes can
9+
receive and send messages from/to the modem, or any other external
10+
device attached to the modem. The modem takes care of routing.
11+
12+
Phonet packets can be exchanged through various hardware connections
13+
depending on the device, such as:
14+
- USB with the CDC Phonet interface,
15+
- infrared,
16+
- Bluetooth,
17+
- an RS232 serial port (with a dedicated "FBUS" line discipline),
18+
- the SSI bus with some TI OMAP processors.
19+
20+
21+
Packets format
22+
--------------
23+
24+
Phonet packets have a common header as follows:
25+
26+
struct phonethdr {
27+
uint8_t pn_media; /* Media type (link-layer identifier) */
28+
uint8_t pn_rdev; /* Receiver device ID */
29+
uint8_t pn_sdev; /* Sender device ID */
30+
uint8_t pn_res; /* Resource ID or function */
31+
uint16_t pn_length; /* Big-endian message byte length (minus 6) */
32+
uint8_t pn_robj; /* Receiver object ID */
33+
uint8_t pn_sobj; /* Sender object ID */
34+
};
35+
36+
On Linux, the link-layer header includes the pn_media byte (see below).
37+
The next 7 bytes are part of the network-layer header.
38+
39+
The device ID is split: the 6 higher-order bits consitute the device
40+
address, while the 2 lower-order bits are used for multiplexing, as are
41+
the 8-bit object identifiers. As such, Phonet can be considered as a
42+
network layer with 6 bits of address space and 10 bits for transport
43+
protocol (much like port numbers in IP world).
44+
45+
The modem always has address number zero. All other device have a their
46+
own 6-bit address.
47+
48+
49+
Link layer
50+
----------
51+
52+
Phonet links are always point-to-point links. The link layer header
53+
consists of a single Phonet media type byte. It uniquely identifies the
54+
link through which the packet is transmitted, from the modem's
55+
perspective. Each Phonet network device shall prepend and set the media
56+
type byte as appropriate. For convenience, a common phonet_header_ops
57+
link-layer header operations structure is provided. It sets the
58+
media type according to the network device hardware address.
59+
60+
Linux Phonet network interfaces support a dedicated link layer packets
61+
type (ETH_P_PHONET) which is out of the Ethernet type range. They can
62+
only send and receive Phonet packets.
63+
64+
The virtual TUN tunnel device driver can also be used for Phonet. This
65+
requires IFF_TUN mode, _without_ the IFF_NO_PI flag. In this case,
66+
there is no link-layer header, so there is no Phonet media type byte.
67+
68+
Note that Phonet interfaces are not allowed to re-order packets, so
69+
only the (default) Linux FIFO qdisc should be used with them.
70+
71+
72+
Network layer
73+
-------------
74+
75+
The Phonet socket address family maps the Phonet packet header:
76+
77+
struct sockaddr_pn {
78+
sa_family_t spn_family; /* AF_PHONET */
79+
uint8_t spn_obj; /* Object ID */
80+
uint8_t spn_dev; /* Device ID */
81+
uint8_t spn_resource; /* Resource or function */
82+
uint8_t spn_zero[...]; /* Padding */
83+
};
84+
85+
The resource field is only used when sending and receiving;
86+
It is ignored by bind() and getsockname().
87+
88+
89+
Low-level datagram protocol
90+
---------------------------
91+
92+
Applications can send Phonet messages using the Phonet datagram socket
93+
protocol from the PF_PHONET family. Each socket is bound to one of the
94+
2^10 object IDs available, and can send and receive packets with any
95+
other peer.
96+
97+
struct sockaddr_pn addr = { .spn_family = AF_PHONET, };
98+
ssize_t len;
99+
socklen_t addrlen = sizeof(addr);
100+
int fd;
101+
102+
fd = socket(PF_PHONET, SOCK_DGRAM, 0);
103+
bind(fd, (struct sockaddr *)&addr, sizeof(addr));
104+
/* ... */
105+
106+
sendto(fd, msg, msglen, 0, (struct sockaddr *)&addr, sizeof(addr));
107+
len = recvfrom(fd, buf, sizeof(buf), 0,
108+
(struct sockaddr *)&addr, &addrlen);
109+
110+
This protocol follows the SOCK_DGRAM connection-less semantics.
111+
However, connect() and getpeername() are not supported, as they did
112+
not seem useful with Phonet usages (could be added easily).
113+
114+
115+
Phonet Pipe protocol
116+
--------------------
117+
118+
The Phonet Pipe protocol is a simple sequenced packets protocol
119+
with end-to-end congestion control. It uses the passive listening
120+
socket paradigm. The listening socket is bound to an unique free object
121+
ID. Each listening socket can handle up to 255 simultaneous
122+
connections, one per accept()'d socket.
123+
124+
int lfd, cfd;
125+
126+
lfd = socket(PF_PHONET, SOCK_SEQPACKET, PN_PROTO_PIPE);
127+
listen (lfd, INT_MAX);
128+
129+
/* ... */
130+
cfd = accept(lfd, NULL, NULL);
131+
for (;;)
132+
{
133+
char buf[...];
134+
ssize_t len = read(cfd, buf, sizeof(buf));
135+
136+
/* ... */
137+
138+
write(cfd, msg, msglen);
139+
}
140+
141+
Connections are established between two endpoints by a "third party"
142+
application. This means that both endpoints are passive; so connect()
143+
is not possible.
144+
145+
WARNING:
146+
When polling a connected pipe socket for writability, there is an
147+
intrinsic race condition whereby writability might be lost between the
148+
polling and the writing system calls. In this case, the socket will
149+
block until write because possible again, unless non-blocking mode
150+
becomes enabled.
151+
152+
153+
The pipe protocol provides two socket options at the SOL_PNPIPE level:
154+
155+
PNPIPE_ENCAP accepts one integer value (int) of:
156+
157+
PNPIPE_ENCAP_NONE: The socket operates normally (default).
158+
159+
PNPIPE_ENCAP_IP: The socket is used as a backend for a virtual IP
160+
interface. This requires CAP_NET_ADMIN capability. GPRS data
161+
support on Nokia modems can use this. Note that the socket cannot
162+
be reliably poll()'d or read() from while in this mode.
163+
164+
PNPIPE_IFINDEX is a read-only integer value. It contains the
165+
interface index of the network interface created by PNPIPE_ENCAP,
166+
or zero if encapsulation is off.
167+
168+
169+
Authors
170+
-------
171+
172+
Linux Phonet was initially written by Sakari Ailus.
173+
Other contributors include Mikä Liljeberg, Andras Domokos,
174+
Carlos Chinea and Rémi Denis-Courmont.
175+
Copyright (C) 2008 Nokia Corporation.

0 commit comments

Comments
 (0)