You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
Conflicts: drivers/mtd/Kconfig Signed-off-by: David Woodhouse <dwmw2@infradead.org>
This commit is contained in:
David Woodhouse
@@ -317,6 +317,12 @@ S: 2322 37th Ave SW
|
||||
S: Seattle, Washington 98126-2010
|
||||
S: USA
|
||||
|
||||
N: Johannes Berg
|
||||
E: johannes@sipsolutions.net
|
||||
W: http://johannes.sipsolutions.net/
|
||||
P: 1024D/9AB78CA5 AD02 0176 4E29 C137 1DF6 08D2 FC44 CF86 9AB7 8CA5
|
||||
D: powerpc & 802.11 hacker
|
||||
|
||||
N: Stephen R. van den Berg (AKA BuGless)
|
||||
E: berg@pool.informatik.rwth-aachen.de
|
||||
D: General kernel, gcc, and libc hacker
|
||||
@@ -2286,14 +2292,14 @@ S: D-90453 Nuernberg
|
||||
S: Germany
|
||||
|
||||
N: Arnaldo Carvalho de Melo
|
||||
E: acme@mandriva.com
|
||||
E: acme@ghostprotocols.net
|
||||
E: arnaldo.melo@gmail.com
|
||||
E: acme@redhat.com
|
||||
W: http://oops.ghostprotocols.net:81/blog/
|
||||
P: 1024D/9224DF01 D5DF E3BB E3C8 BCBB F8AD 841A B6AB 4681 9224 DF01
|
||||
D: IPX, LLC, DCCP, cyc2x, wl3501_cs, net/ hacks
|
||||
S: Mandriva
|
||||
S: R. Tocantins, 89 - Cristo Rei
|
||||
S: 80050-430 - Curitiba - Paraná
|
||||
S: R. Brasílio Itiberê, 4270/1010 - Água Verde
|
||||
S: 80240-060 - Curitiba - Paraná
|
||||
S: Brazil
|
||||
|
||||
N: Karsten Merker
|
||||
|
||||
@@ -211,15 +211,6 @@ Who: Adrian Bunk <bunk@stusta.de>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: IPv4 only connection tracking/NAT/helpers
|
||||
When: 2.6.22
|
||||
Why: The new layer 3 independant connection tracking replaces the old
|
||||
IPv4 only version. After some stabilization of the new code the
|
||||
old one will be removed.
|
||||
Who: Patrick McHardy <kaber@trash.net>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: ACPI hooks (X86_SPEEDSTEP_CENTRINO_ACPI) in speedstep-centrino driver
|
||||
When: December 2006
|
||||
Why: Speedstep-centrino driver with ACPI hooks and acpi-cpufreq driver are
|
||||
@@ -294,18 +285,6 @@ Who: Richard Purdie <rpurdie@rpsys.net>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: Wireless extensions over netlink (CONFIG_NET_WIRELESS_RTNETLINK)
|
||||
When: with the merge of wireless-dev, 2.6.22 or later
|
||||
Why: The option/code is
|
||||
* not enabled on most kernels
|
||||
* not required by any userspace tools (except an experimental one,
|
||||
and even there only for some parts, others use ioctl)
|
||||
* pointless since wext is no longer evolving and the ioctl
|
||||
interface needs to be kept
|
||||
Who: Johannes Berg <johannes@sipsolutions.net>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: i8xx_tco watchdog driver
|
||||
When: in 2.6.22
|
||||
Why: the i8xx_tco watchdog driver has been replaced by the iTCO_wdt
|
||||
@@ -313,3 +292,22 @@ Why: the i8xx_tco watchdog driver has been replaced by the iTCO_wdt
|
||||
Who: Wim Van Sebroeck <wim@iguana.be>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: Multipath cached routing support in ipv4
|
||||
When: in 2.6.23
|
||||
Why: Code was merged, then submitter immediately disappeared leaving
|
||||
us with no maintainer and lots of bugs. The code should not have
|
||||
been merged in the first place, and many aspects of it's
|
||||
implementation are blocking more critical core networking
|
||||
development. It's marked EXPERIMENTAL and no distribution
|
||||
enables it because it cause obscure crashes due to unfixable bugs
|
||||
(interfaces don't return errors so memory allocation can't be
|
||||
handled, calling contexts of these interfaces make handling
|
||||
errors impossible too because they get called after we've
|
||||
totally commited to creating a route object, for example).
|
||||
This problem has existed for years and no forward progress
|
||||
has ever been made, and nobody steps up to try and salvage
|
||||
this code, so we're going to finally just get rid of it.
|
||||
Who: David S. Miller <davem@davemloft.net>
|
||||
|
||||
---------------------------
|
||||
|
||||
@@ -1,31 +1,82 @@
|
||||
====================
|
||||
kAFS: AFS FILESYSTEM
|
||||
====================
|
||||
|
||||
ABOUT
|
||||
Contents:
|
||||
|
||||
- Overview.
|
||||
- Usage.
|
||||
- Mountpoints.
|
||||
- Proc filesystem.
|
||||
- The cell database.
|
||||
- Security.
|
||||
- Examples.
|
||||
|
||||
|
||||
========
|
||||
OVERVIEW
|
||||
========
|
||||
|
||||
This filesystem provides a fairly simple secure AFS filesystem driver. It is
|
||||
under development and does not yet provide the full feature set. The features
|
||||
it does support include:
|
||||
|
||||
(*) Security (currently only AFS kaserver and KerberosIV tickets).
|
||||
|
||||
(*) File reading.
|
||||
|
||||
(*) Automounting.
|
||||
|
||||
It does not yet support the following AFS features:
|
||||
|
||||
(*) Write support.
|
||||
|
||||
(*) Local caching.
|
||||
|
||||
(*) pioctl() system call.
|
||||
|
||||
|
||||
===========
|
||||
COMPILATION
|
||||
===========
|
||||
|
||||
The filesystem should be enabled by turning on the kernel configuration
|
||||
options:
|
||||
|
||||
CONFIG_AF_RXRPC - The RxRPC protocol transport
|
||||
CONFIG_RXKAD - The RxRPC Kerberos security handler
|
||||
CONFIG_AFS - The AFS filesystem
|
||||
|
||||
Additionally, the following can be turned on to aid debugging:
|
||||
|
||||
CONFIG_AF_RXRPC_DEBUG - Permit AF_RXRPC debugging to be enabled
|
||||
CONFIG_AFS_DEBUG - Permit AFS debugging to be enabled
|
||||
|
||||
They permit the debugging messages to be turned on dynamically by manipulating
|
||||
the masks in the following files:
|
||||
|
||||
/sys/module/af_rxrpc/parameters/debug
|
||||
/sys/module/afs/parameters/debug
|
||||
|
||||
|
||||
=====
|
||||
|
||||
This filesystem provides a fairly simple AFS filesystem driver. It is under
|
||||
development and only provides very basic facilities. It does not yet support
|
||||
the following AFS features:
|
||||
|
||||
(*) Write support.
|
||||
(*) Communications security.
|
||||
(*) Local caching.
|
||||
(*) pioctl() system call.
|
||||
(*) Automatic mounting of embedded mountpoints.
|
||||
|
||||
|
||||
USAGE
|
||||
=====
|
||||
|
||||
When inserting the driver modules the root cell must be specified along with a
|
||||
list of volume location server IP addresses:
|
||||
|
||||
insmod rxrpc.o
|
||||
insmod af_rxrpc.o
|
||||
insmod rxkad.o
|
||||
insmod kafs.o rootcell=cambridge.redhat.com:172.16.18.73:172.16.18.91
|
||||
|
||||
The first module is a driver for the RxRPC remote operation protocol, and the
|
||||
second is the actual filesystem driver for the AFS filesystem.
|
||||
The first module is the AF_RXRPC network protocol driver. This provides the
|
||||
RxRPC remote operation protocol and may also be accessed from userspace. See:
|
||||
|
||||
Documentation/networking/rxrpc.txt
|
||||
|
||||
The second module is the kerberos RxRPC security driver, and the third module
|
||||
is the actual filesystem driver for the AFS filesystem.
|
||||
|
||||
Once the module has been loaded, more modules can be added by the following
|
||||
procedure:
|
||||
@@ -33,7 +84,7 @@ procedure:
|
||||
echo add grand.central.org 18.7.14.88:128.2.191.224 >/proc/fs/afs/cells
|
||||
|
||||
Where the parameters to the "add" command are the name of a cell and a list of
|
||||
volume location servers within that cell.
|
||||
volume location servers within that cell, with the latter separated by colons.
|
||||
|
||||
Filesystems can be mounted anywhere by commands similar to the following:
|
||||
|
||||
@@ -42,11 +93,6 @@ Filesystems can be mounted anywhere by commands similar to the following:
|
||||
mount -t afs "#root.afs." /afs
|
||||
mount -t afs "#root.cell." /afs/cambridge
|
||||
|
||||
NB: When using this on Linux 2.4, the mount command has to be different,
|
||||
since the filesystem doesn't have access to the device name argument:
|
||||
|
||||
mount -t afs none /afs -ovol="#root.afs."
|
||||
|
||||
Where the initial character is either a hash or a percent symbol depending on
|
||||
whether you definitely want a R/W volume (hash) or whether you'd prefer a R/O
|
||||
volume, but are willing to use a R/W volume instead (percent).
|
||||
@@ -60,55 +106,66 @@ named volume will be looked up in the cell specified during insmod.
|
||||
Additional cells can be added through /proc (see later section).
|
||||
|
||||
|
||||
===========
|
||||
MOUNTPOINTS
|
||||
===========
|
||||
|
||||
AFS has a concept of mountpoints. These are specially formatted symbolic links
|
||||
(of the same form as the "device name" passed to mount). kAFS presents these
|
||||
to the user as directories that have special properties:
|
||||
AFS has a concept of mountpoints. In AFS terms, these are specially formatted
|
||||
symbolic links (of the same form as the "device name" passed to mount). kAFS
|
||||
presents these to the user as directories that have a follow-link capability
|
||||
(ie: symbolic link semantics). If anyone attempts to access them, they will
|
||||
automatically cause the target volume to be mounted (if possible) on that site.
|
||||
|
||||
(*) They cannot be listed. Running a program like "ls" on them will incur an
|
||||
EREMOTE error (Object is remote).
|
||||
Automatically mounted filesystems will be automatically unmounted approximately
|
||||
twenty minutes after they were last used. Alternatively they can be unmounted
|
||||
directly with the umount() system call.
|
||||
|
||||
(*) Other objects can't be looked up inside of them. This also incurs an
|
||||
EREMOTE error.
|
||||
Manually unmounting an AFS volume will cause any idle submounts upon it to be
|
||||
culled first. If all are culled, then the requested volume will also be
|
||||
unmounted, otherwise error EBUSY will be returned.
|
||||
|
||||
(*) They can be queried with the readlink() system call, which will return
|
||||
the name of the mountpoint to which they point. The "readlink" program
|
||||
will also work.
|
||||
This can be used by the administrator to attempt to unmount the whole AFS tree
|
||||
mounted on /afs in one go by doing:
|
||||
|
||||
(*) They can be mounted on (which symbolic links can't).
|
||||
umount /afs
|
||||
|
||||
|
||||
===============
|
||||
PROC FILESYSTEM
|
||||
===============
|
||||
|
||||
The rxrpc module creates a number of files in various places in the /proc
|
||||
filesystem:
|
||||
|
||||
(*) Firstly, some information files are made available in a directory called
|
||||
"/proc/net/rxrpc/". These list the extant transport endpoint, peer,
|
||||
connection and call records.
|
||||
|
||||
(*) Secondly, some control files are made available in a directory called
|
||||
"/proc/sys/rxrpc/". Currently, all these files can be used for is to
|
||||
turn on various levels of tracing.
|
||||
|
||||
The AFS modules creates a "/proc/fs/afs/" directory and populates it:
|
||||
|
||||
(*) A "cells" file that lists cells currently known to the afs module.
|
||||
(*) A "cells" file that lists cells currently known to the afs module and
|
||||
their usage counts:
|
||||
|
||||
[root@andromeda ~]# cat /proc/fs/afs/cells
|
||||
USE NAME
|
||||
3 cambridge.redhat.com
|
||||
|
||||
(*) A directory per cell that contains files that list volume location
|
||||
servers, volumes, and active servers known within that cell.
|
||||
|
||||
[root@andromeda ~]# cat /proc/fs/afs/cambridge.redhat.com/servers
|
||||
USE ADDR STATE
|
||||
4 172.16.18.91 0
|
||||
[root@andromeda ~]# cat /proc/fs/afs/cambridge.redhat.com/vlservers
|
||||
ADDRESS
|
||||
172.16.18.91
|
||||
[root@andromeda ~]# cat /proc/fs/afs/cambridge.redhat.com/volumes
|
||||
USE STT VLID[0] VLID[1] VLID[2] NAME
|
||||
1 Val 20000000 20000001 20000002 root.afs
|
||||
|
||||
|
||||
=================
|
||||
THE CELL DATABASE
|
||||
=================
|
||||
|
||||
The filesystem maintains an internal database of all the cells it knows and
|
||||
the IP addresses of the volume location servers for those cells. The cell to
|
||||
which the computer belongs is added to the database when insmod is performed
|
||||
by the "rootcell=" argument.
|
||||
The filesystem maintains an internal database of all the cells it knows and the
|
||||
IP addresses of the volume location servers for those cells. The cell to which
|
||||
the system belongs is added to the database when insmod is performed by the
|
||||
"rootcell=" argument or, if compiled in, using a "kafs.rootcell=" argument on
|
||||
the kernel command line.
|
||||
|
||||
Further cells can be added by commands similar to the following:
|
||||
|
||||
@@ -118,20 +175,65 @@ Further cells can be added by commands similar to the following:
|
||||
No other cell database operations are available at this time.
|
||||
|
||||
|
||||
========
|
||||
SECURITY
|
||||
========
|
||||
|
||||
Secure operations are initiated by acquiring a key using the klog program. A
|
||||
very primitive klog program is available at:
|
||||
|
||||
http://people.redhat.com/~dhowells/rxrpc/klog.c
|
||||
|
||||
This should be compiled by:
|
||||
|
||||
make klog LDLIBS="-lcrypto -lcrypt -lkrb4 -lkeyutils"
|
||||
|
||||
And then run as:
|
||||
|
||||
./klog
|
||||
|
||||
Assuming it's successful, this adds a key of type RxRPC, named for the service
|
||||
and cell, eg: "afs@<cellname>". This can be viewed with the keyctl program or
|
||||
by cat'ing /proc/keys:
|
||||
|
||||
[root@andromeda ~]# keyctl show
|
||||
Session Keyring
|
||||
-3 --alswrv 0 0 keyring: _ses.3268
|
||||
2 --alswrv 0 0 \_ keyring: _uid.0
|
||||
111416553 --als--v 0 0 \_ rxrpc: afs@CAMBRIDGE.REDHAT.COM
|
||||
|
||||
Currently the username, realm, password and proposed ticket lifetime are
|
||||
compiled in to the program.
|
||||
|
||||
It is not required to acquire a key before using AFS facilities, but if one is
|
||||
not acquired then all operations will be governed by the anonymous user parts
|
||||
of the ACLs.
|
||||
|
||||
If a key is acquired, then all AFS operations, including mounts and automounts,
|
||||
made by a possessor of that key will be secured with that key.
|
||||
|
||||
If a file is opened with a particular key and then the file descriptor is
|
||||
passed to a process that doesn't have that key (perhaps over an AF_UNIX
|
||||
socket), then the operations on the file will be made with key that was used to
|
||||
open the file.
|
||||
|
||||
|
||||
========
|
||||
EXAMPLES
|
||||
========
|
||||
|
||||
Here's what I use to test this. Some of the names and IP addresses are local
|
||||
to my internal DNS. My "root.afs" partition has a mount point within it for
|
||||
Here's what I use to test this. Some of the names and IP addresses are local
|
||||
to my internal DNS. My "root.afs" partition has a mount point within it for
|
||||
some public volumes volumes.
|
||||
|
||||
insmod -S /tmp/rxrpc.o
|
||||
insmod -S /tmp/kafs.o rootcell=cambridge.redhat.com:172.16.18.73:172.16.18.91
|
||||
insmod /tmp/rxrpc.o
|
||||
insmod /tmp/rxkad.o
|
||||
insmod /tmp/kafs.o rootcell=cambridge.redhat.com:172.16.18.91
|
||||
|
||||
mount -t afs \%root.afs. /afs
|
||||
mount -t afs \%cambridge.redhat.com:root.cell. /afs/cambridge.redhat.com/
|
||||
|
||||
echo add grand.central.org 18.7.14.88:128.2.191.224 > /proc/fs/afs/cells
|
||||
echo add grand.central.org 18.7.14.88:128.2.191.224 > /proc/fs/afs/cells
|
||||
mount -t afs "#grand.central.org:root.cell." /afs/grand.central.org/
|
||||
mount -t afs "#grand.central.org:root.archive." /afs/grand.central.org/archive
|
||||
mount -t afs "#grand.central.org:root.contrib." /afs/grand.central.org/contrib
|
||||
@@ -141,15 +243,7 @@ mount -t afs "#grand.central.org:root.service." /afs/grand.central.org/service
|
||||
mount -t afs "#grand.central.org:root.software." /afs/grand.central.org/software
|
||||
mount -t afs "#grand.central.org:root.user." /afs/grand.central.org/user
|
||||
|
||||
umount /afs/grand.central.org/user
|
||||
umount /afs/grand.central.org/software
|
||||
umount /afs/grand.central.org/service
|
||||
umount /afs/grand.central.org/project
|
||||
umount /afs/grand.central.org/doc
|
||||
umount /afs/grand.central.org/contrib
|
||||
umount /afs/grand.central.org/archive
|
||||
umount /afs/grand.central.org
|
||||
umount /afs/cambridge.redhat.com
|
||||
umount /afs
|
||||
rmmod kafs
|
||||
rmmod rxkad
|
||||
rmmod rxrpc
|
||||
|
||||
@@ -1421,6 +1421,15 @@ fewer messages that will be written. Message_burst controls when messages will
|
||||
be dropped. The default settings limit warning messages to one every five
|
||||
seconds.
|
||||
|
||||
warnings
|
||||
--------
|
||||
|
||||
This controls console messages from the networking stack that can occur because
|
||||
of problems on the network like duplicate address or bad checksums. Normally,
|
||||
this should be enabled, but if the problem persists the messages can be
|
||||
disabled.
|
||||
|
||||
|
||||
netdev_max_backlog
|
||||
------------------
|
||||
|
||||
|
||||
@@ -91,6 +91,14 @@ Sending MADs
|
||||
if (ret != sizeof *mad + mad_length)
|
||||
perror("write");
|
||||
|
||||
Transaction IDs
|
||||
|
||||
Users of the umad devices can use the lower 32 bits of the
|
||||
transaction ID field (that is, the least significant half of the
|
||||
field in network byte order) in MADs being sent to match
|
||||
request/response pairs. The upper 32 bits are reserved for use by
|
||||
the kernel and will be overwritten before a MAD is sent.
|
||||
|
||||
Setting IsSM Capability Bit
|
||||
|
||||
To set the IsSM capability bit for a port, simply open the
|
||||
|
||||
@@ -859,6 +859,18 @@ payload contents" for more information.
|
||||
void unregister_key_type(struct key_type *type);
|
||||
|
||||
|
||||
Under some circumstances, it may be desirable to desirable to deal with a
|
||||
bundle of keys. The facility provides access to the keyring type for managing
|
||||
such a bundle:
|
||||
|
||||
struct key_type key_type_keyring;
|
||||
|
||||
This can be used with a function such as request_key() to find a specific
|
||||
keyring in a process's keyrings. A keyring thus found can then be searched
|
||||
with keyring_search(). Note that it is not possible to use request_key() to
|
||||
search a specific keyring, so using keyrings in this way is of limited utility.
|
||||
|
||||
|
||||
===================================
|
||||
NOTES ON ACCESSING PAYLOAD CONTENTS
|
||||
===================================
|
||||
|
||||
@@ -920,40 +920,9 @@ options, you may wish to use the "max_bonds" module parameter,
|
||||
documented above.
|
||||
|
||||
To create multiple bonding devices with differing options, it
|
||||
is necessary to load the bonding driver multiple times. Note that
|
||||
current versions of the sysconfig network initialization scripts
|
||||
handle this automatically; if your distro uses these scripts, no
|
||||
special action is needed. See the section Configuring Bonding
|
||||
Devices, above, if you're not sure about your network initialization
|
||||
scripts.
|
||||
is necessary to use bonding parameters exported by sysfs, documented
|
||||
in the section below.
|
||||
|
||||
To load multiple instances of the module, it is necessary to
|
||||
specify a different name for each instance (the module loading system
|
||||
requires that every loaded module, even multiple instances of the same
|
||||
module, have a unique name). This is accomplished by supplying
|
||||
multiple sets of bonding options in /etc/modprobe.conf, for example:
|
||||
|
||||
alias bond0 bonding
|
||||
options bond0 -o bond0 mode=balance-rr miimon=100
|
||||
|
||||
alias bond1 bonding
|
||||
options bond1 -o bond1 mode=balance-alb miimon=50
|
||||
|
||||
will load the bonding module two times. The first instance is
|
||||
named "bond0" and creates the bond0 device in balance-rr mode with an
|
||||
miimon of 100. The second instance is named "bond1" and creates the
|
||||
bond1 device in balance-alb mode with an miimon of 50.
|
||||
|
||||
In some circumstances (typically with older distributions),
|
||||
the above does not work, and the second bonding instance never sees
|
||||
its options. In that case, the second options line can be substituted
|
||||
as follows:
|
||||
|
||||
install bond1 /sbin/modprobe --ignore-install bonding -o bond1 \
|
||||
mode=balance-alb miimon=50
|
||||
|
||||
This may be repeated any number of times, specifying a new and
|
||||
unique name in place of bond1 for each subsequent instance.
|
||||
|
||||
3.4 Configuring Bonding Manually via Sysfs
|
||||
------------------------------------------
|
||||
|
||||
@@ -57,6 +57,16 @@ DCCP_SOCKOPT_SEND_CSCOV is for the receiver and has a different meaning: it
|
||||
coverage value are also acceptable. The higher the number, the more
|
||||
restrictive this setting (see [RFC 4340, sec. 9.2.1]).
|
||||
|
||||
The following two options apply to CCID 3 exclusively and are getsockopt()-only.
|
||||
In either case, a TFRC info struct (defined in <linux/tfrc.h>) is returned.
|
||||
DCCP_SOCKOPT_CCID_RX_INFO
|
||||
Returns a `struct tfrc_rx_info' in optval; the buffer for optval and
|
||||
optlen must be set to at least sizeof(struct tfrc_rx_info).
|
||||
DCCP_SOCKOPT_CCID_TX_INFO
|
||||
Returns a `struct tfrc_tx_info' in optval; the buffer for optval and
|
||||
optlen must be set to at least sizeof(struct tfrc_tx_info).
|
||||
|
||||
|
||||
Sysctl variables
|
||||
================
|
||||
Several DCCP default parameters can be managed by the following sysctls
|
||||
|
||||
@@ -179,11 +179,31 @@ tcp_fin_timeout - INTEGER
|
||||
because they eat maximum 1.5K of memory, but they tend
|
||||
to live longer. Cf. tcp_max_orphans.
|
||||
|
||||
tcp_frto - BOOLEAN
|
||||
tcp_frto - INTEGER
|
||||
Enables F-RTO, an enhanced recovery algorithm for TCP retransmission
|
||||
timeouts. It is particularly beneficial in wireless environments
|
||||
where packet loss is typically due to random radio interference
|
||||
rather than intermediate router congestion.
|
||||
rather than intermediate router congestion. If set to 1, basic
|
||||
version is enabled. 2 enables SACK enhanced F-RTO, which is
|
||||
EXPERIMENTAL. The basic version can be used also when SACK is
|
||||
enabled for a flow through tcp_sack sysctl.
|
||||
|
||||
tcp_frto_response - INTEGER
|
||||
When F-RTO has detected that a TCP retransmission timeout was
|
||||
spurious (i.e, the timeout would have been avoided had TCP set a
|
||||
longer retransmission timeout), TCP has several options what to do
|
||||
next. Possible values are:
|
||||
0 Rate halving based; a smooth and conservative response,
|
||||
results in halved cwnd and ssthresh after one RTT
|
||||
1 Very conservative response; not recommended because even
|
||||
though being valid, it interacts poorly with the rest of
|
||||
Linux TCP, halves cwnd and ssthresh immediately
|
||||
2 Aggressive response; undoes congestion control measures
|
||||
that are now known to be unnecessary (ignoring the
|
||||
possibility of a lost retransmission that would require
|
||||
TCP to be more cautious), cwnd and ssthresh are restored
|
||||
to the values prior timeout
|
||||
Default: 0 (rate halving based)
|
||||
|
||||
tcp_keepalive_time - INTEGER
|
||||
How often TCP sends out keepalive messages when keepalive is enabled.
|
||||
@@ -995,7 +1015,12 @@ bridge-nf-call-ip6tables - BOOLEAN
|
||||
Default: 1
|
||||
|
||||
bridge-nf-filter-vlan-tagged - BOOLEAN
|
||||
1 : pass bridged vlan-tagged ARP/IP traffic to arptables/iptables.
|
||||
1 : pass bridged vlan-tagged ARP/IP/IPv6 traffic to {arp,ip,ip6}tables.
|
||||
0 : disable this.
|
||||
Default: 1
|
||||
|
||||
bridge-nf-filter-pppoe-tagged - BOOLEAN
|
||||
1 : pass bridged pppoe-tagged IP/IPv6 traffic to {ip,ip6}tables.
|
||||
0 : disable this.
|
||||
Default: 1
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -250,7 +250,6 @@ PRODUCT COMPONENTS AND RELATED FILES
|
||||
sdladrv.h SDLA support module API definitions
|
||||
sdlasfm.h SDLA firmware module definitions
|
||||
if_wanpipe.h WANPIPE Socket definitions
|
||||
if_wanpipe_common.h WANPIPE Socket/Driver common definitions.
|
||||
sdlapci.h WANPIPE PCI definitions
|
||||
|
||||
|
||||
|
||||
@@ -1,83 +0,0 @@
|
||||
crypto-API support for z990 Message Security Assist (MSA) instructions
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
AUTHOR: Thomas Spatzier (tspat@de.ibm.com)
|
||||
|
||||
|
||||
1. Introduction crypto-API
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
See Documentation/crypto/api-intro.txt for an introduction/description of the
|
||||
kernel crypto API.
|
||||
According to api-intro.txt support for z990 crypto instructions has been added
|
||||
in the algorithm api layer of the crypto API. Several files containing z990
|
||||
optimized implementations of crypto algorithms are placed in the
|
||||
arch/s390/crypto directory.
|
||||
|
||||
|
||||
2. Probing for availability of MSA
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
It should be possible to use Kernels with the z990 crypto implementations both
|
||||
on machines with MSA available and on those without MSA (pre z990 or z990
|
||||
without MSA). Therefore a simple probing mechanism has been implemented:
|
||||
In the init function of each crypto module the availability of MSA and of the
|
||||
respective crypto algorithm in particular will be tested. If the algorithm is
|
||||
available the module will load and register its algorithm with the crypto API.
|
||||
|
||||
If the respective crypto algorithm is not available, the init function will
|
||||
return -ENOSYS. In that case a fallback to the standard software implementation
|
||||
of the crypto algorithm must be taken ( -> the standard crypto modules are
|
||||
also built when compiling the kernel).
|
||||
|
||||
|
||||
3. Ensuring z990 crypto module preference
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
If z990 crypto instructions are available the optimized modules should be
|
||||
preferred instead of standard modules.
|
||||
|
||||
3.1. compiled-in modules
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
For compiled-in modules it has to be ensured that the z990 modules are linked
|
||||
before the standard crypto modules. Then, on system startup the init functions
|
||||
of z990 crypto modules will be called first and query for availability of z990
|
||||
crypto instructions. If instruction is available, the z990 module will register
|
||||
its crypto algorithm implementation -> the load of the standard module will fail
|
||||
since the algorithm is already registered.
|
||||
If z990 crypto instruction is not available the load of the z990 module will
|
||||
fail -> the standard module will load and register its algorithm.
|
||||
|
||||
3.2. dynamic modules
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
A system administrator has to take care of giving preference to z990 crypto
|
||||
modules. If MSA is available appropriate lines have to be added to
|
||||
/etc/modprobe.conf.
|
||||
|
||||
Example: z990 crypto instruction for SHA1 algorithm is available
|
||||
|
||||
add the following line to /etc/modprobe.conf (assuming the
|
||||
z990 crypto modules for SHA1 is called sha1_z990):
|
||||
|
||||
alias sha1 sha1_z990
|
||||
|
||||
-> when the sha1 algorithm is requested through the crypto API
|
||||
(which has a module autoloader) the z990 module will be loaded.
|
||||
|
||||
TBD: a userspace module probing mechanism
|
||||
something like 'probe sha1 sha1_z990 sha1' in modprobe.conf
|
||||
-> try module sha1_z990, if it fails to load standard module sha1
|
||||
the 'probe' statement is currently not supported in modprobe.conf
|
||||
|
||||
|
||||
4. Currently implemented z990 crypto algorithms
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
The following crypto algorithms with z990 MSA support are currently implemented.
|
||||
The name of each algorithm under which it is registered in crypto API and the
|
||||
name of the respective module is given in square brackets.
|
||||
|
||||
- SHA1 Digest Algorithm [sha1 -> sha1_z990]
|
||||
- DES Encrypt/Decrypt Algorithm (64bit key) [des -> des_z990]
|
||||
- Triple DES Encrypt/Decrypt Algorithm (128bit key) [des3_ede128 -> des_z990]
|
||||
- Triple DES Encrypt/Decrypt Algorithm (192bit key) [des3_ede -> des_z990]
|
||||
|
||||
In order to load, for example, the sha1_z990 module when the sha1 algorithm is
|
||||
requested (see 3.2.) add 'alias sha1 sha1_z990' to /etc/modprobe.conf.
|
||||
|
||||
@@ -0,0 +1,87 @@
|
||||
s390 SCSI dump tool (zfcpdump)
|
||||
|
||||
System z machines (z900 or higher) provide hardware support for creating system
|
||||
dumps on SCSI disks. The dump process is initiated by booting a dump tool, which
|
||||
has to create a dump of the current (probably crashed) Linux image. In order to
|
||||
not overwrite memory of the crashed Linux with data of the dump tool, the
|
||||
hardware saves some memory plus the register sets of the boot cpu before the
|
||||
dump tool is loaded. There exists an SCLP hardware interface to obtain the saved
|
||||
memory afterwards. Currently 32 MB are saved.
|
||||
|
||||
This zfcpdump implementation consists of a Linux dump kernel together with
|
||||
a userspace dump tool, which are loaded together into the saved memory region
|
||||
below 32 MB. zfcpdump is installed on a SCSI disk using zipl (as contained in
|
||||
the s390-tools package) to make the device bootable. The operator of a Linux
|
||||
system can then trigger a SCSI dump by booting the SCSI disk, where zfcpdump
|
||||
resides on.
|
||||
|
||||
The kernel part of zfcpdump is implemented as a debugfs file under "zcore/mem",
|
||||
which exports memory and registers of the crashed Linux in an s390
|
||||
standalone dump format. It can be used in the same way as e.g. /dev/mem. The
|
||||
dump format defines a 4K header followed by plain uncompressed memory. The
|
||||
register sets are stored in the prefix pages of the respective cpus. To build a
|
||||
dump enabled kernel with the zcore driver, the kernel config option
|
||||
CONFIG_ZFCPDUMP has to be set. When reading from "zcore/mem", the part of
|
||||
memory, which has been saved by hardware is read by the driver via the SCLP
|
||||
hardware interface. The second part is just copied from the non overwritten real
|
||||
memory.
|
||||
|
||||
The userspace application of zfcpdump can reside e.g. in an intitramfs or an
|
||||
initrd. It reads from zcore/mem and writes the system dump to a file on a
|
||||
SCSI disk.
|
||||
|
||||
To build a zfcpdump kernel use the following settings in your kernel
|
||||
configuration:
|
||||
* CONFIG_ZFCPDUMP=y
|
||||
* Enable ZFCP driver
|
||||
* Enable SCSI driver
|
||||
* Enable ext2 and ext3 filesystems
|
||||
* Disable as many features as possible to keep the kernel small.
|
||||
E.g. network support is not needed at all.
|
||||
|
||||
To use the zfcpdump userspace application in an initramfs you have to do the
|
||||
following:
|
||||
|
||||
* Copy the zfcpdump executable somewhere into your Linux tree.
|
||||
E.g. to "arch/s390/boot/zfcpdump. If you do not want to include
|
||||
shared libraries, compile the tool with the "-static" gcc option.
|
||||
* If you want to include e2fsck, add it to your source tree, too. The zfcpdump
|
||||
application attempts to start /sbin/e2fsck from the ramdisk.
|
||||
* Use an initramfs config file like the following:
|
||||
|
||||
dir /dev 755 0 0
|
||||
nod /dev/console 644 0 0 c 5 1
|
||||
nod /dev/null 644 0 0 c 1 3
|
||||
nod /dev/sda1 644 0 0 b 8 1
|
||||
nod /dev/sda2 644 0 0 b 8 2
|
||||
nod /dev/sda3 644 0 0 b 8 3
|
||||
nod /dev/sda4 644 0 0 b 8 4
|
||||
nod /dev/sda5 644 0 0 b 8 5
|
||||
nod /dev/sda6 644 0 0 b 8 6
|
||||
nod /dev/sda7 644 0 0 b 8 7
|
||||
nod /dev/sda8 644 0 0 b 8 8
|
||||
nod /dev/sda9 644 0 0 b 8 9
|
||||
nod /dev/sda10 644 0 0 b 8 10
|
||||
nod /dev/sda11 644 0 0 b 8 11
|
||||
nod /dev/sda12 644 0 0 b 8 12
|
||||
nod /dev/sda13 644 0 0 b 8 13
|
||||
nod /dev/sda14 644 0 0 b 8 14
|
||||
nod /dev/sda15 644 0 0 b 8 15
|
||||
file /init arch/s390/boot/zfcpdump 755 0 0
|
||||
file /sbin/e2fsck arch/s390/boot/e2fsck 755 0 0
|
||||
dir /proc 755 0 0
|
||||
dir /sys 755 0 0
|
||||
dir /mnt 755 0 0
|
||||
dir /sbin 755 0 0
|
||||
|
||||
* Issue "make image" to build the zfcpdump image with initramfs.
|
||||
|
||||
In a Linux distribution the zfcpdump enabled kernel image must be copied to
|
||||
/usr/share/zfcpdump/zfcpdump.image, where the s390 zipl tool is looking for the
|
||||
dump kernel when preparing a SCSI dump disk.
|
||||
|
||||
If you use a ramdisk copy it to "/usr/share/zfcpdump/zfcpdump.rd".
|
||||
|
||||
For more information on how to use zfcpdump refer to the s390 'Using the Dump
|
||||
Tools book', which is available from
|
||||
http://www.ibm.com/developerworks/linux/linux390.
|
||||
+37
-13
@@ -384,7 +384,7 @@ S: Supported
|
||||
|
||||
APPLETALK NETWORK LAYER
|
||||
P: Arnaldo Carvalho de Melo
|
||||
M: acme@conectiva.com.br
|
||||
M: acme@ghostprotocols.net
|
||||
S: Maintained
|
||||
|
||||
ARC FRAMEBUFFER DRIVER
|
||||
@@ -656,6 +656,7 @@ S: Supported
|
||||
ATMEL WIRELESS DRIVER
|
||||
P: Simon Kelley
|
||||
M: simon@thekelleys.org.uk
|
||||
L: linux-wireless@vger.kernel.org
|
||||
W: http://www.thekelleys.org.uk/atmel
|
||||
W: http://atmelwlandriver.sourceforge.net/
|
||||
S: Maintained
|
||||
@@ -711,6 +712,7 @@ P: Larry Finger
|
||||
M: Larry.Finger@lwfinger.net
|
||||
P: Stefano Brivio
|
||||
M: st3@riseup.net
|
||||
L: linux-wireless@vger.kernel.org
|
||||
W: http://bcm43xx.berlios.de/
|
||||
S: Maintained
|
||||
|
||||
@@ -892,6 +894,12 @@ M: maxextreme@gmail.com
|
||||
L: linux-kernel@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
CFG80211 and NL80211
|
||||
P: Johannes Berg
|
||||
M: johannes@sipsolutions.net
|
||||
L: linux-wireless@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
COMMON INTERNET FILE SYSTEM (CIFS)
|
||||
P: Steve French
|
||||
M: sfrench@samba.org
|
||||
@@ -1034,9 +1042,8 @@ S: Maintained
|
||||
|
||||
CYCLADES 2X SYNC CARD DRIVER
|
||||
P: Arnaldo Carvalho de Melo
|
||||
M: acme@conectiva.com.br
|
||||
W: http://advogato.org/person/acme
|
||||
L: cycsyn-devel@bazar.conectiva.com.br
|
||||
M: acme@ghostprotocols.net
|
||||
W: http://oops.ghostprotocols.net:81/blog
|
||||
S: Maintained
|
||||
|
||||
CYCLADES ASYNC MUX DRIVER
|
||||
@@ -1077,7 +1084,7 @@ S: Maintained
|
||||
|
||||
DCCP PROTOCOL
|
||||
P: Arnaldo Carvalho de Melo
|
||||
M: acme@mandriva.com
|
||||
M: acme@ghostprotocols.net
|
||||
L: dccp@vger.kernel.org
|
||||
W: http://linux-net.osdl.org/index.php/DCCP
|
||||
S: Maintained
|
||||
@@ -1558,6 +1565,7 @@ S: Supported
|
||||
HOST AP DRIVER
|
||||
P: Jouni Malinen
|
||||
M: jkmaline@cc.hut.fi
|
||||
L: linux-wireless@vger.kernel.org
|
||||
L: hostap@shmoo.com
|
||||
W: http://hostap.epitest.fi/
|
||||
S: Maintained
|
||||
@@ -1830,6 +1838,7 @@ P: Yi Zhu
|
||||
M: yi.zhu@intel.com
|
||||
P: James Ketrenos
|
||||
M: jketreno@linux.intel.com
|
||||
L: linux-wireless@vger.kernel.org
|
||||
L: ipw2100-devel@lists.sourceforge.net
|
||||
L: http://lists.sourceforge.net/mailman/listinfo/ipw2100-devel
|
||||
W: http://ipw2100.sourceforge.net
|
||||
@@ -1840,6 +1849,7 @@ P: Yi Zhu
|
||||
M: yi.zhu@intel.com
|
||||
P: James Ketrenos
|
||||
M: jketreno@linux.intel.com
|
||||
L: linux-wireless@vger.kernel.org
|
||||
L: ipw2100-devel@lists.sourceforge.net
|
||||
L: http://lists.sourceforge.net/mailman/listinfo/ipw2100-devel
|
||||
W: http://ipw2200.sourceforge.net
|
||||
@@ -1871,7 +1881,7 @@ S: Supported
|
||||
|
||||
IPX NETWORK LAYER
|
||||
P: Arnaldo Carvalho de Melo
|
||||
M: acme@conectiva.com.br
|
||||
M: acme@ghostprotocols.net
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
@@ -2108,7 +2118,7 @@ S: Supported
|
||||
|
||||
LLC (802.2)
|
||||
P: Arnaldo Carvalho de Melo
|
||||
M: acme@conectiva.com.br
|
||||
M: acme@ghostprotocols.net
|
||||
S: Maintained
|
||||
|
||||
LINUX FOR 64BIT POWERPC
|
||||
@@ -2236,6 +2246,14 @@ L: linux-mtd@lists.infradead.org
|
||||
T: git git://git.infradead.org/mtd-2.6.git
|
||||
S: Maintained
|
||||
|
||||
UNSORTED BLOCK IMAGES (UBI)
|
||||
P: Artem Bityutskiy
|
||||
M: dedekind@infradead.org
|
||||
W: http://www.linux-mtd.infradead.org/
|
||||
L: linux-mtd@lists.infradead.org
|
||||
T: git git://git.infradead.org/ubi-2.6.git
|
||||
S: Maintained
|
||||
|
||||
MICROTEK X6 SCANNER
|
||||
P: Oliver Neukum
|
||||
M: oliver@neukum.name
|
||||
@@ -2532,6 +2550,7 @@ P: Pavel Roskin
|
||||
M: proski@gnu.org
|
||||
P: David Gibson
|
||||
M: hermes@gibson.dropbear.id.au
|
||||
L: linux-wireless@vger.kernel.org
|
||||
L: orinoco-users@lists.sourceforge.net
|
||||
L: orinoco-devel@lists.sourceforge.net
|
||||
W: http://www.nongnu.org/orinoco/
|
||||
@@ -2711,7 +2730,7 @@ S: Supported
|
||||
PRISM54 WIRELESS DRIVER
|
||||
P: Prism54 Development Team
|
||||
M: developers@islsm.org
|
||||
L: netdev@vger.kernel.org
|
||||
L: linux-wireless@vger.kernel.org
|
||||
W: http://prism54.org
|
||||
S: Maintained
|
||||
|
||||
@@ -2782,7 +2801,7 @@ S: Maintained
|
||||
RAYLINK/WEBGEAR 802.11 WIRELESS LAN DRIVER
|
||||
P: Corey Thomas
|
||||
M: corey@world.std.com
|
||||
L: linux-kernel@vger.kernel.org
|
||||
L: linux-wireless@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
RANDOM NUMBER DRIVER
|
||||
@@ -2961,8 +2980,10 @@ P: Stephen Smalley
|
||||
M: sds@tycho.nsa.gov
|
||||
P: James Morris
|
||||
M: jmorris@namei.org
|
||||
P: Eric Paris
|
||||
M: eparis@parisplace.org
|
||||
L: linux-kernel@vger.kernel.org (kernel issues)
|
||||
L: selinux@tycho.nsa.gov (general discussion)
|
||||
L: selinux@tycho.nsa.gov (subscribers-only, general discussion)
|
||||
W: http://www.nsa.gov/selinux
|
||||
S: Supported
|
||||
|
||||
@@ -3045,7 +3066,7 @@ M: josejx@gentoo.org
|
||||
P: Daniel Drake
|
||||
M: dsd@gentoo.org
|
||||
W: http://softmac.sipsolutions.net/
|
||||
L: netdev@vger.kernel.org
|
||||
L: linux-wireless@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
SOFTWARE RAID (Multiple Disks) SUPPORT
|
||||
@@ -3750,6 +3771,7 @@ S: Maintained
|
||||
WAVELAN NETWORK DRIVER & WIRELESS EXTENSIONS
|
||||
P: Jean Tourrilhes
|
||||
M: jt@hpl.hp.com
|
||||
L: linux-wireless@vger.kernel.org
|
||||
W: http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/
|
||||
S: Maintained
|
||||
|
||||
@@ -3766,8 +3788,9 @@ S: Maintained
|
||||
|
||||
WL3501 WIRELESS PCMCIA CARD DRIVER
|
||||
P: Arnaldo Carvalho de Melo
|
||||
M: acme@conectiva.com.br
|
||||
W: http://advogato.org/person/acme
|
||||
M: acme@ghostprotocols.net
|
||||
L: linux-wireless@vger.kernel.org
|
||||
W: http://oops.ghostprotocols.net:81/blog
|
||||
S: Maintained
|
||||
|
||||
X.25 NETWORK LAYER
|
||||
@@ -3830,6 +3853,7 @@ M: dsd@gentoo.org
|
||||
P: Ulrich Kunitz
|
||||
M: kune@deine-taler.de
|
||||
W: http://zd1211.ath.cx/wiki/DriverRewrite
|
||||
L: linux-wireless@vger.kernel.org
|
||||
L: zd1211-devs@lists.sourceforge.net (subscribers-only)
|
||||
S: Maintained
|
||||
|
||||
|
||||
@@ -36,7 +36,6 @@ lib-y = __divqu.o __remqu.o __divlu.o __remlu.o \
|
||||
$(ev6-y)csum_ipv6_magic.o \
|
||||
$(ev6-y)clear_page.o \
|
||||
$(ev6-y)copy_page.o \
|
||||
strcasecmp.o \
|
||||
fpreg.o \
|
||||
callback_srm.o srm_puts.o srm_printk.o
|
||||
|
||||
|
||||
@@ -1,26 +0,0 @@
|
||||
/*
|
||||
* linux/arch/alpha/lib/strcasecmp.c
|
||||
*/
|
||||
|
||||
#include <linux/string.h>
|
||||
|
||||
|
||||
/* We handle nothing here except the C locale. Since this is used in
|
||||
only one place, on strings known to contain only 7 bit ASCII, this
|
||||
is ok. */
|
||||
|
||||
int strcasecmp(const char *a, const char *b)
|
||||
{
|
||||
int ca, cb;
|
||||
|
||||
do {
|
||||
ca = *a++ & 0xff;
|
||||
cb = *b++ & 0xff;
|
||||
if (ca >= 'A' && ca <= 'Z')
|
||||
ca += 'a' - 'A';
|
||||
if (cb >= 'A' && cb <= 'Z')
|
||||
cb += 'a' - 'A';
|
||||
} while (ca == cb && ca != '\0');
|
||||
|
||||
return ca - cb;
|
||||
}
|
||||
+10
-3
@@ -57,9 +57,6 @@ config ARCH_HAS_ILOG2_U64
|
||||
bool
|
||||
default n
|
||||
|
||||
config GENERIC_BUST_SPINLOCK
|
||||
bool
|
||||
|
||||
config GENERIC_HWEIGHT
|
||||
bool
|
||||
default y
|
||||
@@ -68,6 +65,11 @@ config GENERIC_CALIBRATE_DELAY
|
||||
bool
|
||||
default y
|
||||
|
||||
config GENERIC_BUG
|
||||
bool
|
||||
default y
|
||||
depends on BUG
|
||||
|
||||
source "init/Kconfig"
|
||||
|
||||
menu "System Type and features"
|
||||
@@ -106,6 +108,9 @@ choice
|
||||
config BOARD_ATSTK1000
|
||||
bool "ATSTK1000 evaluation board"
|
||||
select BOARD_ATSTK1002 if CPU_AT32AP7000
|
||||
|
||||
config BOARD_ATNGW100
|
||||
bool "ATNGW100 Network Gateway"
|
||||
endchoice
|
||||
|
||||
choice
|
||||
@@ -116,6 +121,8 @@ config LOADER_U_BOOT
|
||||
bool "U-Boot (or similar) bootloader"
|
||||
endchoice
|
||||
|
||||
source "arch/avr32/mach-at32ap/Kconfig"
|
||||
|
||||
config LOAD_ADDRESS
|
||||
hex
|
||||
default 0x10000000 if LOADER_U_BOOT=y && CPU_AT32AP7000=y
|
||||
|
||||
@@ -27,6 +27,7 @@ head-$(CONFIG_LOADER_U_BOOT) += arch/avr32/boot/u-boot/head.o
|
||||
head-y += arch/avr32/kernel/head.o
|
||||
core-$(CONFIG_PLATFORM_AT32AP) += arch/avr32/mach-at32ap/
|
||||
core-$(CONFIG_BOARD_ATSTK1000) += arch/avr32/boards/atstk1000/
|
||||
core-$(CONFIG_BOARD_ATNGW100) += arch/avr32/boards/atngw100/
|
||||
core-$(CONFIG_LOADER_U_BOOT) += arch/avr32/boot/u-boot/
|
||||
core-y += arch/avr32/kernel/
|
||||
core-y += arch/avr32/mm/
|
||||
|
||||
@@ -0,0 +1 @@
|
||||
obj-y += setup.o flash.o
|
||||
@@ -0,0 +1,95 @@
|
||||
/*
|
||||
* ATNGW100 board-specific flash initialization
|
||||
*
|
||||
* Copyright (C) 2005-2006 Atmel Corporation
|
||||
*
|
||||
* This program is free software; you can redistribute it and/or modify
|
||||
* it under the terms of the GNU General Public License version 2 as
|
||||
* published by the Free Software Foundation.
|
||||
*/
|
||||
#include <linux/init.h>
|
||||
#include <linux/platform_device.h>
|
||||
#include <linux/mtd/mtd.h>
|
||||
#include <linux/mtd/partitions.h>
|
||||
#include <linux/mtd/physmap.h>
|
||||
|
||||
#include <asm/arch/smc.h>
|
||||
|
||||
static struct smc_config flash_config __initdata = {
|
||||
.ncs_read_setup = 0,
|
||||
.nrd_setup = 40,
|
||||
.ncs_write_setup = 0,
|
||||
.nwe_setup = 10,
|
||||
|
||||
.ncs_read_pulse = 80,
|
||||
.nrd_pulse = 40,
|
||||
.ncs_write_pulse = 65,
|
||||
.nwe_pulse = 55,
|
||||
|
||||
.read_cycle = 120,
|
||||
.write_cycle = 120,
|
||||
|
||||
.bus_width = 2,
|
||||
.nrd_controlled = 1,
|
||||
.nwe_controlled = 1,
|
||||
.byte_write = 1,
|
||||
};
|
||||
|
||||
static struct mtd_partition flash_parts[] = {
|
||||
{
|
||||
.name = "u-boot",
|
||||
.offset = 0x00000000,
|
||||
.size = 0x00020000, /* 128 KiB */
|
||||
.mask_flags = MTD_WRITEABLE,
|
||||
},
|
||||
{
|
||||
.name = "root",
|
||||
.offset = 0x00020000,
|
||||
.size = 0x007d0000,
|
||||
},
|
||||
{
|
||||
.name = "env",
|
||||
.offset = 0x007f0000,
|
||||
.size = 0x00010000,
|
||||
.mask_flags = MTD_WRITEABLE,
|
||||
},
|
||||
};
|
||||
|
||||
static struct physmap_flash_data flash_data = {
|
||||
.width = 2,
|
||||
.nr_parts = ARRAY_SIZE(flash_parts),
|
||||
.parts = flash_parts,
|
||||
};
|
||||
|
||||
static struct resource flash_resource = {
|
||||
.start = 0x00000000,
|
||||
.end = 0x007fffff,
|
||||
.flags = IORESOURCE_MEM,
|
||||
};
|
||||
|
||||
static struct platform_device flash_device = {
|
||||
.name = "physmap-flash",
|
||||
.id = 0,
|
||||
.resource = &flash_resource,
|
||||
.num_resources = 1,
|
||||
.dev = {
|
||||
.platform_data = &flash_data,
|
||||
},
|
||||
};
|
||||
|
||||
/* This needs to be called after the SMC has been initialized */
|
||||
static int __init atngw100_flash_init(void)
|
||||
{
|
||||
int ret;
|
||||
|
||||
ret = smc_set_configuration(0, &flash_config);
|
||||
if (ret < 0) {
|
||||
printk(KERN_ERR "atngw100: failed to set NOR flash timing\n");
|
||||
return ret;
|
||||
}
|
||||
|
||||
platform_device_register(&flash_device);
|
||||
|
||||
return 0;
|
||||
}
|
||||
device_initcall(atngw100_flash_init);
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user