Linux 2.6.24

Before transmission of the last word in PIO RX_ONLY mode rx+tx mode
is enabled:

	/* prevent last RX_ONLY read from triggering
	 * more word i/o: switch to rx+tx
	 */
	if (c == 0 && tx == NULL)
		mcspi_write_cs_reg(spi,
				OMAP2_MCSPI_CHCONF0, l);

But because c is decremented after the test, c will never be zero and
rx+tx will not be enabled. This breaks RX_ONLY mode PIO transfers.

Fix it by decrementing c in the beginning of the various I/O loops.

Signed-off-by: Kalle Valo <kalle.valo@nokia.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Documentation/00-INDEX

@@ -262,6 +262,8 @@ mtrr.txt
 	- how to use PPro Memory Type Range Registers to increase performance.
 mutex-design.txt
 	- info on the generic mutex subsystem.
+namespaces/
+	- directory with various information about namespaces
 nbd.txt
 	- info on a TCP implementation of a network block device.
 netlabel/

Documentation/ABI/testing/sysfs-kernel-uids

@@ -0,0 +1,14 @@
+What:		/sys/kernel/uids/<uid>/cpu_shares
+Date:		December 2007
+Contact:	Dhaval Giani <dhaval@linux.vnet.ibm.com>
+		Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
+Description:
+		The /sys/kernel/uids/<uid>/cpu_shares tunable is used
+		to set the cpu bandwidth a user is allowed. This is a
+		propotional value. What that means is that if there
+		are two users logged in, each with an equal number of
+		shares, then they will get equal CPU bandwidth. Another
+		example would be, if User A has shares = 1024 and user
+		B has shares = 2048, User B will get twice the CPU
+		bandwidth user A will. For more details refer
+		Documentation/sched-design-CFS.txt

Documentation/DocBook/Makefile

@@ -11,7 +11,7 @@ DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \
 	    procfs-guide.xml writing_usb_driver.xml \
 	    kernel-api.xml filesystems.xml lsm.xml usb.xml \
 	    gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
-	    genericirq.xml s390-drivers.xml
+	    genericirq.xml s390-drivers.xml uio-howto.xml
 
 ###
 # The build process is as follows (targets):

Documentation/DocBook/uio-howto.tmpl

@@ -29,6 +29,12 @@
 </abstract>
 
 <revhistory>
+	<revision>
+	<revnumber>0.4</revnumber>
+	<date>2007-11-26</date>
+	<authorinitials>hjk</authorinitials>
+	<revremark>Removed section about uio_dummy.</revremark>
+	</revision>
 	<revision>
 	<revnumber>0.3</revnumber>
 	<date>2007-04-29</date>
@@ -94,6 +100,26 @@ interested in translating it, please email me
 	user space. This simplifies development and reduces the risk of
 	serious bugs within a kernel module.
 	</para>
+	<para>
+	Please note that UIO is not an universal driver interface. Devices
+	that are already handled well by other kernel subsystems (like
+	networking or serial or USB) are no candidates for an UIO driver.
+	Hardware that is ideally suited for an UIO driver fulfills all of
+	the following:
+	</para>
+<itemizedlist>
+<listitem>
+	<para>The device has memory that can be mapped. The device can be
+	controlled completely by writing to this memory.</para>
+</listitem>
+<listitem>
+	<para>The device usually generates interrupts.</para>
+</listitem>
+<listitem>
+	<para>The device does not fit into one of the standard kernel
+	subsystems.</para>
+</listitem>
+</itemizedlist>
 </sect1>
 
 <sect1 id="thanks">
@@ -174,8 +200,9 @@ interested in translating it, please email me
 	For cards that don't generate interrupts but need to be
 	polled, there is the possibility to set up a timer that
 	triggers the interrupt handler at configurable time intervals.
-	See <filename>drivers/uio/uio_dummy.c</filename> for an
-	example of this technique.
+	This interrupt simulation is done by calling
+	<function>uio_event_notify()</function>
+	from the timer's event handler.
 	</para>
 
 	<para>
@@ -263,63 +290,11 @@ offset = N * getpagesize();
 </sect1>
 </chapter>
 
-<chapter id="using-uio_dummy" xreflabel="Using uio_dummy">
-<?dbhtml filename="using-uio_dummy.html"?>
-<title>Using uio_dummy</title>
-	<para>
-	Well, there is no real use for uio_dummy. Its only purpose is
-	to test most parts of the UIO system (everything except
-	hardware interrupts), and to serve as an example for the
-	kernel module that you will have to write yourself.
-	</para>
-
-<sect1 id="what_uio_dummy_does">
-<title>What uio_dummy does</title>
-	<para>
-	The kernel module <filename>uio_dummy.ko</filename> creates a
-	device that uses a timer to generate periodic interrupts. The
-	interrupt handler does nothing but increment a counter. The
-	driver adds two custom attributes, <varname>count</varname>
-	and <varname>freq</varname>, that appear under
-	<filename>/sys/devices/platform/uio_dummy/</filename>.
-	</para>
-
-	<para>
-	The attribute <varname>count</varname> can be read and
-	written.  The associated file
-	<filename>/sys/devices/platform/uio_dummy/count</filename>
-	appears as a normal text file and contains the total number of
-	timer interrupts. If you look at it (e.g. using
-	<function>cat</function>), you'll notice it is slowly counting
-	up.
-	</para>
-
-	<para>
-	The attribute <varname>freq</varname> can be read and written.
-	The content of
-	<filename>/sys/devices/platform/uio_dummy/freq</filename>
-	represents the number of system timer ticks between two timer
-	interrupts. The default value of <varname>freq</varname> is
-	the value of the kernel variable <varname>HZ</varname>, which
-	gives you an interval of one second. Lower values will
-	increase the frequency. Try the following:
-	</para>
-<programlisting format="linespecific">
-cd /sys/devices/platform/uio_dummy/
-echo 100 > freq
-</programlisting>
-	<para>
-	Use <function>cat count</function> to see how the interrupt
-	frequency changes.
-	</para>
-</sect1>
-</chapter>
-
 <chapter id="custom_kernel_module" xreflabel="Writing your own kernel module">
 <?dbhtml filename="custom_kernel_module.html"?>
 <title>Writing your own kernel module</title>
 	<para>
-	Please have a look at <filename>uio_dummy.c</filename> as an
+	Please have a look at <filename>uio_cif.c</filename> as an
 	example. The following paragraphs explain the different
 	sections of this file.
 	</para>
@@ -354,9 +329,8 @@ See the description below for details.
 interrupt, it's your modules task to determine the irq number during
 initialization. If you don't have a hardware generated interrupt but
 want to trigger the interrupt handler in some other way, set
-<varname>irq</varname> to <varname>UIO_IRQ_CUSTOM</varname>. The
-uio_dummy module does this as it triggers the event mechanism in a timer
-routine. If you had no interrupt at all, you could set
+<varname>irq</varname> to <varname>UIO_IRQ_CUSTOM</varname>.
+If you had no interrupt at all, you could set
 <varname>irq</varname> to <varname>UIO_IRQ_NONE</varname>, though this
 rarely makes sense.
 </para></listitem>

Documentation/accounting/getdelays.c

@@ -25,6 +25,7 @@
 
 #include <linux/genetlink.h>
 #include <linux/taskstats.h>
+#include <linux/cgroupstats.h>
 
 /*
  * Generic macros for dealing with netlink sockets. Might be duplicated
@@ -78,6 +79,7 @@ static void usage(void)
 	fprintf(stderr, "  -i: print IO accounting (works only with -p)\n");
 	fprintf(stderr, "  -l: listen forever\n");
 	fprintf(stderr, "  -v: debug on\n");
+	fprintf(stderr, "  -C: container path\n");
 }
 
 /*
@@ -212,6 +214,14 @@ void task_context_switch_counts(struct taskstats *t)
 	       t->nvcsw, t->nivcsw);
 }
 
+void print_cgroupstats(struct cgroupstats *c)
+{
+	printf("sleeping %llu, blocked %llu, running %llu, stopped %llu, "
+		"uninterruptible %llu\n", c->nr_sleeping, c->nr_io_wait,
+		c->nr_running, c->nr_stopped, c->nr_uninterruptible);
+}
+
+
 void print_ioacct(struct taskstats *t)
 {
 	printf("%s: read=%llu, write=%llu, cancelled_write=%llu\n",
@@ -239,11 +249,14 @@ int main(int argc, char *argv[])
 	int maskset = 0;
 	char *logfile = NULL;
 	int loop = 0;
+	int containerset = 0;
+	char containerpath[1024];
+	int cfd = 0;
 
 	struct msgtemplate msg;
 
 	while (1) {
-		c = getopt(argc, argv, "qdiw:r:m:t:p:vl");
+		c = getopt(argc, argv, "qdiw:r:m:t:p:vlC:");
 		if (c < 0)
 			break;
 
@@ -260,6 +273,10 @@ int main(int argc, char *argv[])
 			printf("printing task/process context switch rates\n");
 			print_task_context_switch_counts = 1;
 			break;
+		case 'C':
+			containerset = 1;
+			strncpy(containerpath, optarg, strlen(optarg) + 1);
+			break;
 		case 'w':
 			logfile = strdup(optarg);
 			printf("write to file %s\n", logfile);
@@ -334,6 +351,11 @@ int main(int argc, char *argv[])
 		}
 	}
 
+	if (tid && containerset) {
+		fprintf(stderr, "Select either -t or -C, not both\n");
+		goto err;
+	}
+
 	if (tid) {
 		rc = send_cmd(nl_sd, id, mypid, TASKSTATS_CMD_GET,
 			      cmd_type, &tid, sizeof(__u32));
@@ -344,6 +366,20 @@ int main(int argc, char *argv[])
 		}
 	}
 
+	if (containerset) {
+		cfd = open(containerpath, O_RDONLY);
+		if (cfd < 0) {
+			perror("error opening container file");
+			goto err;
+		}
+		rc = send_cmd(nl_sd, id, mypid, CGROUPSTATS_CMD_GET,
+			      CGROUPSTATS_CMD_ATTR_FD, &cfd, sizeof(__u32));
+		if (rc < 0) {
+			perror("error sending cgroupstats command");
+			goto err;
+		}
+	}
+
 	do {
 		int i;
 
@@ -422,6 +458,9 @@ int main(int argc, char *argv[])
 				}
 				break;
 
+			case CGROUPSTATS_TYPE_CGROUP_STATS:
+				print_cgroupstats(NLA_DATA(na));
+				break;
 			default:
 				fprintf(stderr, "Unknown nla_type %d\n",
 					na->nla_type);
@@ -443,5 +482,7 @@ err:
 	close(nl_sd);
 	if (fd)
 		close(fd);
+	if (cfd)
+		close(cfd);
 	return 0;
 }

Documentation/feature-removal-schedule.txt

@@ -181,15 +181,6 @@ Who:	Nick Piggin <npiggin@suse.de>
 
 ---------------------------
 
-What:	Interrupt only SA_* flags
-When:	September 2007
-Why:	The interrupt related SA_* flags are replaced by IRQF_* to move them
-	out of the signal namespace.
-
-Who:	Thomas Gleixner <tglx@linutronix.de>
-
----------------------------
-
 What:	PHYSDEVPATH, PHYSDEVBUS, PHYSDEVDRIVER in the uevent environment
 When:	October 2008
 Why:	The stacking of class devices makes these values misleading and

Documentation/hwmon/sysfs-interface

@@ -328,6 +328,37 @@ curr[1-*]_input	Current input value
 		Unit: milliampere
 		RO
 
+*********
+* Power *
+*********
+
+power[1-*]_average		Average power use
+				Unit: microWatt
+				RO
+
+power[1-*]_average_highest	Historical average maximum power use
+				Unit: microWatt
+				RO
+
+power[1-*]_average_lowest	Historical average minimum power use
+				Unit: microWatt
+				RO
+
+power[1-*]_input		Instantaneous power use
+				Unit: microWatt
+				RO
+
+power[1-*]_input_highest	Historical maximum power use
+				Unit: microWatt
+				RO
+
+power[1-*]_input_lowest		Historical minimum power use
+				Unit: microWatt
+				RO
+
+power[1-*]_reset_history	Reset input_highest, input_lowest,
+				average_highest and average_lowest.
+				WO
 
 **********
 * Alarms *

Documentation/i2c/summary

@@ -1,5 +1,3 @@
-This is an explanation of what i2c is, and what is supported in this package.
-
 I2C and SMBus
 =============
 
@@ -33,52 +31,17 @@ When we talk about I2C, we use the following terms:
             Client
 
 An Algorithm driver contains general code that can be used for a whole class
-of I2C adapters. Each specific adapter driver depends on one algorithm
-driver.
+of I2C adapters. Each specific adapter driver either depends on one algorithm
+driver, or includes its own implementation.
 
 A Driver driver (yes, this sounds ridiculous, sorry) contains the general
 code to access some type of device. Each detected device gets its own
 data in the Client structure. Usually, Driver and Client are more closely
 integrated than Algorithm and Adapter.
 
-For a given configuration, you will need a driver for your I2C bus (usually
-a separate Adapter and Algorithm driver), and drivers for your I2C devices
-(usually one driver for each device). There are no I2C device drivers
-in this package. See the lm_sensors project http://www.lm-sensors.nu
-for device drivers.
+For a given configuration, you will need a driver for your I2C bus, and
+drivers for your I2C devices (usually one driver for each device).
 
 At this time, Linux only operates I2C (or SMBus) in master mode; you can't
 use these APIs to make a Linux system behave as a slave/device, either to
 speak a custom protocol or to emulate some other device.
-
-
-Included Bus Drivers
-====================
-Note that only stable drivers are patched into the kernel by 'mkpatch'.
-
-
-Base modules
-------------
-
-i2c-core: The basic I2C code, including the /proc/bus/i2c* interface
-i2c-dev:  The /dev/i2c-* interface
-i2c-proc: The /proc/sys/dev/sensors interface for device (client) drivers
-
-Algorithm drivers
------------------
-
-i2c-algo-bit:    A bit-banging algorithm
-i2c-algo-pcf:    A PCF 8584 style algorithm
-i2c-algo-ibm_ocp: An algorithm for the I2C device in IBM 4xx processors (NOT BUILT BY DEFAULT)
-
-Adapter drivers
----------------
-
-i2c-elektor:     Elektor ISA card (uses i2c-algo-pcf)
-i2c-elv:         ELV parallel port adapter (uses i2c-algo-bit)
-i2c-pcf-epp:     PCF8584 on a EPP parallel port (uses i2c-algo-pcf) (NOT mkpatched)
-i2c-philips-par: Philips style parallel port adapter (uses i2c-algo-bit)
-i2c-adap-ibm_ocp: IBM 4xx processor I2C device (uses i2c-algo-ibm_ocp) (NOT BUILT BY DEFAULT)
-i2c-pport:       Primitive parallel port adapter (uses i2c-algo-bit)
-i2c-velleman:    Velleman K8000 parallel port adapter (uses i2c-algo-bit)
-

Documentation/ja_JP/HOWTO

@@ -11,14 +11,14 @@ for non English (read: Japanese) speakers and is not intended as a
 fork. So if you have any comments or updates for this file, please try
 to update the original English file first.
 
-Last Updated: 2007/09/23
+Last Updated: 2007/11/16
 ==================================
 これは、
-linux-2.6.23/Documentation/HOWTO
+linux-2.6.24/Documentation/HOWTO
 の和訳です。
 
 翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ >
-翻訳日： 2007/09/19
+翻訳日： 2007/11/10
 翻訳者： Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com>
 校正者： 松倉さん <nbh--mats at nifty dot com>
          小林 雅典さん (Masanori Kobayasi) <zap03216 at nifty dot ne dot jp>
@@ -110,7 +110,7 @@ Linux カーネルソースツリーは幅広い範囲のドキュメントを
 新しいドキュメントファイルも追加することを勧めます。
 カーネルの変更が、カーネルがユーザ空間に公開しているインターフェイスの
 変更を引き起こす場合、その変更を説明するマニュアルページのパッチや情報
-をマニュアルページのメンテナ mtk-manpages@gmx.net に送ることを勧めま
+をマニュアルページのメンテナ mtk.manpages@gmail.com に送ることを勧めま
 す。
 
 以下はカーネルソースツリーに含まれている読んでおくべきファイルの一覧で

Documentation/kernel-parameters.txt

@@ -527,29 +527,30 @@ and is between 256 and 4096 characters. It is defined in the file
 			Format: <area>[,<node>]
 			See also Documentation/networking/decnet.txt.
 
-	default_blu=	[VT]
+	vt.default_blu=	[VT]
 			Format: <blue0>,<blue1>,<blue2>,...,<blue15>
 			Change the default blue palette of the console.
 			This is a 16-member array composed of values
 			ranging from 0-255.
 
-	default_grn=	[VT]
+	vt.default_grn=	[VT]
 			Format: <green0>,<green1>,<green2>,...,<green15>
 			Change the default green palette of the console.
 			This is a 16-member array composed of values
 			ranging from 0-255.
 
-	default_red=	[VT]
+	vt.default_red=	[VT]
 			Format: <red0>,<red1>,<red2>,...,<red15>
 			Change the default red palette of the console.
 			This is a 16-member array composed of values
 			ranging from 0-255.
 
-	default_utf8=   [VT]
+	vt.default_utf8=
+			[VT]
 			Format=<0|1>
 			Set system-wide default UTF-8 mode for all tty's.
-			Default is 0 and by setting to 1, it enables UTF-8
-			mode for all newly opened or allocated terminals.
+			Default is 1, i.e. UTF-8 mode is enabled for all
+			newly opened terminals.
 
 	dhash_entries=	[KNL]
 			Set number of hash buckets for dentry cache.
@@ -882,6 +883,14 @@ and is between 256 and 4096 characters. It is defined in the file
 	lapic_timer_c2_ok	[X86-32,x86-64,APIC] trust the local apic timer in
 			C2 power state.
 
+	libata.dma=	[LIBATA] DMA control
+			libata.dma=0	  Disable all PATA and SATA DMA
+			libata.dma=1	  PATA and SATA Disk DMA only
+			libata.dma=2	  ATAPI (CDROM) DMA only
+			libata.dma=4	  Compact Flash DMA only 
+			Combinations also work, so libata.dma=3 enables DMA
+			for disks and CDROMs, but not CFs.
+
 	libata.noacpi	[LIBATA] Disables use of ACPI in libata suspend/resume
 			when set.
 			Format: <int>

Documentation/ko_KR/HOWTO

@@ -1,6 +1,6 @@
 NOTE:
 This is a version of Documentation/HOWTO translated into korean
-This document is maintained by minchan Kim < minchan.kim@gmail.com>
+This document is maintained by minchan Kim <minchan.kim@gmail.com>
 If you find any difference between this document and the original file or
 a problem with the translation, please contact the maintainer of this file.
 
@@ -14,7 +14,7 @@ try to update the original English file first.
 Documentation/HOWTO
 의 한글 번역입니다.
 
-역자： 김민찬 <minchan.kim@gmail.com >
+역자： 김민찬 <minchan.kim@gmail.com>
 감수： 이제이미 <jamee.lee@samsung.com>
 ==================================
 
@@ -23,11 +23,11 @@ Documentation/HOWTO
 
 이 문서는 커널 개발에 있어 가장 중요한 문서이다. 이 문서는
 리눅스 커널 개발자가 되는 법과 리눅스 커널 개발 커뮤니티와 일하는
-법을 담고있다. 커널 프로그래밍의기술적인 측면과 관련된 내용들은
-포함하지 않으려고 하였지만 올바으로 여러분을 안내하는 데 도움이
+법을 담고있다. 커널 프로그래밍의 기술적인 측면과 관련된 내용들은
+포함하지 않으려고 하였지만 올바른 길로 여러분을 안내하는 데는 도움이
 될 것이다.
 
-이 문서에서 오래된 것을 발견하면 문서의 아래쪽에 나열된 메인트너에게
+이 문서에서 오래된 것을 발견하면 문서의 아래쪽에 나열된 메인테이너에게
 패치를 보내달라.
 
 
@@ -36,12 +36,12 @@ Documentation/HOWTO
 
 자, 여러분은 리눅스 커널 개발자가 되는 법을 배우고 싶은가? 아니면
 상사로부터"이 장치를 위한 리눅스 드라이버를 작성하시오"라는 말을
-들었는가? 이 문서는 여러분이 겪게 될 과정과 커뮤니티와 일하는 법을
-조언하여 여러분의 목적을 달성하기 위해 필요한 것 모두를 알려주는
-것이다.
+들었는가? 이 문서의 목적은 여러분이 겪게 될 과정과 커뮤니티와 협력하는
+법을 조언하여 여러분의 목적을 달성하기 위해 필요한 것 모두를 알려주기
+위함이다.
 
-커널은 대부분은 C로 작성되었어고 몇몇 아키텍쳐의 의존적인 부분은
-어셈블리로 작성되었다. 커널 개발을 위해 C를 잘 이해하고 있어야 한다.
+커널은 대부분은 C로 작성되어 있고 몇몇 아키텍쳐의 의존적인 부분은
+어셈블리로 작성되어 있다. 커널 개발을 위해 C를 잘 이해하고 있어야 한다.
 여러분이 특정 아키텍쳐의 low-level 개발을 할 것이 아니라면
 어셈블리(특정 아키텍쳐)는 잘 알아야 할 필요는 없다.
 다음의 참고서적들은 기본에 충실한 C 교육이나 수년간의 경험에 견주지는
@@ -59,11 +59,11 @@ Documentation/HOWTO
 어떤 참고문서도 있지 않다. 정보를 얻기 위해서는 gcc info (`info gcc`)페이지를
 살펴보라.
 
-여러분은 기존의 개발 커뮤니티와 일하는 법을 배우려고 하고 있다는 것을
-기억하라. 코딩, 스타일, 절차에 관한 훌륭한 표준을 가진 사람들이 모인
+여러분은 기존의 개발 커뮤니티와 협력하는 법을 배우려고 하고 있다는 것을
+기억하라. 코딩, 스타일, 함수에 관한 훌륭한 표준을 가진 사람들이 모인
 다양한 그룹이 있다. 이 표준들은 오랜동안 크고 지역적으로 분산된 팀들에
-의해 가장 좋은 방법으로 일하기위하여 찾은 것을 기초로 만들어져왔다.
-그 표준들은 문서화가 잘 되어 있기 때문에 가능한한 미리 많은 표준들에
+의해 가장 좋은 방법으로 일하기 위하여 찾은 것을 기초로 만들어져 왔다.
+그 표준들은 문서화가 잘 되어있기 때문에 가능한한 미리 많은 표준들에
 관하여 배우려고 시도하라. 다른 사람들은 여러분이나 여러분의 회사가
 일하는 방식에 적응하는 것을 원하지는 않는다.
 
@@ -73,7 +73,7 @@ Documentation/HOWTO
 
 리눅스 커널 소스 코드는 GPL로 배포(release)되었다. 소스트리의 메인
 디렉토리에 있는 라이센스에 관하여 상세하게 쓰여 있는 COPYING이라는
-파일을 봐라.여러분이 라이센스에 관한 더 깊은 문제를 가지고 있다면
+파일을 봐라. 여러분이 라이센스에 관한 더 깊은 문제를 가지고 있다면
 리눅스 커널 메일링 리스트에 묻지말고 변호사와 연락하라. 메일링
 리스트들에 있는 사람들은 변호사가 아니기 때문에 법적 문제에 관하여
 그들의 말에 의지해서는 안된다.
@@ -85,12 +85,12 @@ GPL에 관한 잦은 질문들과 답변들은 다음을 참조하라.
 문서
 ----
 
-리눅스 커널 소스 트리는 커널 커뮤니티와 일하는 법을 배우기 위한 많은
-귀중한 문서들을 가지고 있다. 새로운 기능들이 커널에 들어가게 될 때,
+리눅스 커널 소스 트리는 커널 커뮤니티와 협력하는 법을 배우기위해 훌륭한
+다양한 문서들을 가지고 있다. 새로운 기능들이 커널에 들어가게 될 때,
 그 기능을 어떻게 사용하는지에 관한 설명을 위하여 새로운 문서 파일을
 추가하는 것을 권장한다. 커널이 유저스페이스로 노출하는 인터페이스를
 변경하게 되면 변경을 설명하는 메뉴얼 페이지들에 대한 패치나 정보를
-mtk-manpages@gmx.net의 메인트너에게 보낼 것을 권장한다.
+mtk.manpages@gmail.com의 메인테이너에게 보낼 것을 권장한다.
 
 다음은 커널 소스 트리에 있는 읽어야 할 파일들의 리스트이다.
   README
@@ -105,7 +105,7 @@ mtk-manpages@gmx.net의 메인트너에게 보낼 것을 권장한다.
   Documentation/CodingStyle
     이 문서는 리눅스 커널 코딩 스타일과 그렇게 한 몇몇 이유를 설명한다.
     모든 새로운 코드는 이 문서에 가이드라인들을 따라야 한다. 대부분의
-    메인트너들은 이 규칙을 따르는 패치들만을 받아들일 것이고 많은 사람들이
+    메인테이너들은 이 규칙을 따르는 패치들만을 받아들일 것이고 많은 사람들이
     그 패치가 올바른 스타일일 경우만 코드를 검토할 것이다.
 
   Documentation/SubmittingPatches
@@ -115,9 +115,10 @@ mtk-manpages@gmx.net의 메인트너에게 보낼 것을 권장한다.
        - Email 내용들
        - Email 양식
        - 그것을 누구에게 보낼지
-    이러한 규칙들을 따르는 것이 성공을 보장하진 않는다(왜냐하면 모든
-    패치들은 내용과 스타일에 관하여 면밀히 검토되기 때문이다).
-    그러나 규칙을 따르지 않는다면 거의 성공하지도 못할 것이다.
+    이러한 규칙들을 따르는 것이 성공(역자주: 패치가 받아들여 지는 것)을
+    보장하진 않는다(왜냐하면 모든 패치들은 내용과 스타일에 관하여
+    면밀히 검토되기 때문이다). 그러나 규칙을 따르지 않는다면 거의
+    성공하지도 못할 것이다.
 
     올바른 패치들을 만드는 법에 관한 훌륭한 다른 문서들이 있다.
     "The Perfect Patch"
@@ -126,13 +127,13 @@ mtk-manpages@gmx.net의 메인트너에게 보낼 것을 권장한다.
         http://linux.yyz.us/patch-format.html
 
    Documentation/stable_api_nonsense.txt
-    이 문서는 의도적으로 커널이 변하지 않는 API를 갖지 않도록 결정한
+    이 문서는 의도적으로 커널이 불변하는 API를 갖지 않도록 결정한
     이유를 설명하며 다음과 같은 것들을 포함한다.
        - 서브시스템 shim-layer(호환성을 위해?)
-       - 운영 체제들 간의 드라이버 이식성
+       - 운영체제들간의 드라이버 이식성
        - 커널 소스 트리내에 빠른 변화를 늦추는 것(또는 빠른 변화를 막는 것)
     이 문서는 리눅스 개발 철학을 이해하는데 필수적이며 다른 운영체제에서
-    리눅스로 옮겨오는 사람들에게는 매우 중요하다.
+    리눅스로 전향하는 사람들에게는 매우 중요하다.
 
 
   Documentation/SecurityBugs
@@ -141,10 +142,10 @@ mtk-manpages@gmx.net의 메인트너에게 보낼 것을 권장한다.
     도와 달라.
 
   Documentation/ManagementStyle
-    이 문서는 리눅스 커널 메인트너들이 어떻게 그들의 방법론의 정신을
-    어떻게 공유하고 운영하는지를 설명한다. 이것은 커널 개발에 입문하는
+    이 문서는 리눅스 커널 메인테이너들이 그들의 방법론에 녹아 있는
+    정신을 어떻게 공유하고 운영하는지를 설명한다. 이것은 커널 개발에 입문하는
     모든 사람들(또는 커널 개발에 작은 호기심이라도 있는 사람들)이
-    읽어야 할 중요한 문서이다. 왜냐하면 이 문서는 커널 메인트너들의
+    읽어야 할 중요한 문서이다. 왜냐하면 이 문서는 커널 메인테이너들의
     독특한 행동에 관하여 흔히 있는 오해들과 혼란들을 해소하고 있기
     때문이다.
 
@@ -160,7 +161,7 @@ mtk-manpages@gmx.net의 메인트너에게 보낼 것을 권장한다.
 
   Documentation/applying-patches.txt
     패치가 무엇이며 그것을 커널의 다른 개발 브랜치들에 어떻게
-    적용하는지에 관하여 자세히 설명 하고 있는 좋은 입문서이다.
+    적용하는지에 관하여 자세히 설명하고 있는 좋은 입문서이다.
 
 커널은 소스 코드 그 자체에서 자동적으로 만들어질 수 있는 많은 문서들을
 가지고 있다. 이것은 커널 내의 API에 대한 모든 설명, 그리고 락킹을
@@ -192,7 +193,7 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H
 여러분이 어디서 시작해야 할진 모르지만 커널 개발 커뮤니티에 참여할 수
 있는 일들을 찾길 원한다면 리눅스 커널 Janitor 프로젝트를 살펴봐라.
          http://janitor.kernelnewbies.org/
-그곳은 시작하기에 아주 딱 좋은 곳이다. 그곳은 리눅스 커널 소스 트리내에
+그곳은 시작하기에 훌륭한 장소이다. 그곳은 리눅스 커널 소스 트리내에
 간단히 정리되고 수정될 수 있는 문제들에 관하여 설명한다. 여러분은 이
 프로젝트를 대표하는 개발자들과 일하면서 자신의 패치를 리눅스 커널 트리에
 반영하기 위한 기본적인 것들을 배우게 될것이며 여러분이 아직 아이디어를
@@ -212,7 +213,7 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H
 것은 Linux Cross-Reference project이며 그것은 자기 참조 방식이며
 소스코드를 인덱스된 웹 페이지들의 형태로 보여준다. 최신의 멋진 커널
 코드 저장소는 다음을 통하여 참조할 수 있다.
-      http://sosdg.org/~coywolf/lxr/
+      http://users.sosdg.org/~qiyong/lxr/
 
 
 개발 프로세스
@@ -233,44 +234,45 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H
 2.6.x 커널들은 Linux Torvalds가 관리하며 kernel.org의 pub/linux/kernel/v2.6/
 디렉토리에서 참조될 수 있다.개발 프로세스는 다음과 같다.
   - 새로운 커널이 배포되자마자 2주의 시간이 주어진다. 이 기간동은
-    메인트너들은 큰 diff들을 Linus에게 제출할 수 있다. 대개 이 패치들은
+    메인테이너들은 큰 diff들을 Linus에게 제출할 수 있다. 대개 이 패치들은
     몇 주 동안 -mm 커널내에 이미 있었던 것들이다. 큰 변경들을 제출하는 데
     선호되는 방법은  git(커널의 소스 관리 툴, 더 많은 정보들은 http://git.or.cz/
-    에서 참조할 수 있다)를 사용하는 것이지만 순수한 패치파일의 형식으로 보내도
+    에서 참조할 수 있다)를 사용하는 것이지만 순수한 패치파일의 형식으로 보내는
     것도 무관하다.
   - 2주 후에 -rc1 커널이 배포되며 지금부터는 전체 커널의 안정성에 영향을
-    미칠수 있는 새로운 기능들을 포함하지 않는 패치들만을 추가될 수 있다.
+    미칠수 있는 새로운 기능들을 포함하지 않는 패치들만이 추가될 수 있다.
     완전히 새로운 드라이버(혹은 파일시스템)는 -rc1 이후에만 받아들여진다는
     것을 기억해라. 왜냐하면 변경이 자체내에서만 발생하고 추가된 코드가
     드라이버 외부의 다른 부분에는 영향을 주지 않으므로 그런 변경은
-    퇴보(regression)를 일으킬 만한 위험을 가지고 있지 않기 때문이다. -rc1이
+    회귀(역자주: 이전에는 존재하지 않았지만 새로운 기능추가나 변경으로 인해
+		생겨난 버그)를 일으킬 만한 위험을 가지고 있지 않기 때문이다. -rc1이
     배포된 이후에 git를 사용하여 패치들을 Linus에게 보낼수 있지만 패치들은
     공식적인 메일링 리스트로 보내서 검토를 받을 필요가 있다.
-  - 새로운 -rc는 Linus는 현재 git tree가 테스트 하기에 충분히 안정된 상태에
+  - 새로운 -rc는 Linus가 현재 git tree가 테스트 하기에 충분히 안정된 상태에
     있다고 판단될 때마다 배포된다. 목표는 새로운 -rc 커널을 매주 배포하는
     것이다.
-  - 이러한 프로세스는 커널이 "준비"되었다고 여겨질때까지 계속된다.
+  - 이러한 프로세스는 커널이 "준비(ready)"되었다고 여겨질때까지 계속된다.
     프로세스는 대체로 6주간 지속된다.
-    - 각 -rc 배포에 있는 알려진 퇴보의 목록들은 다음 URI에 남겨진다.
+  - 각 -rc 배포에 있는 알려진 회귀의 목록들은 다음 URI에 남겨진다.
     http://kernelnewbies.org/known_regressions
 
 커널 배포에 있어서 언급할만한 가치가 있는 리눅스 커널 메일링 리스트의
 Andrew Morton의 글이 있다.
-        "커널이 언제 배포될지는 아무로 모른다. 왜냐하면 배포는 알려진
+        "커널이 언제 배포될지는 아무도 모른다. 왜냐하면 배포는 알려진
          버그의 상황에 따라 배포되는 것이지 미리정해 놓은 시간에 따라
-          배포되는 것은 아니기 때문이다."
+         배포되는 것은 아니기 때문이다."
 
 2.6.x.y - 안정 커널 트리
 ------------------------
 
 4 자리 숫자로 이루어진 버젼의 커널들은 -stable 커널들이다. 그것들은 2.6.x
-커널에서 발견된 큰 퇴보들이나 보안 문제들 중 비교적 작고 중요한 수정들을
+커널에서 발견된 큰 회귀들이나 보안 문제들 중 비교적 작고 중요한 수정들을
 포함한다.
 
 이것은 가장 최근의 안정적인 커널을 원하는 사용자에게 추천되는 브랜치이며,
-개발/실험적 버젼을 테스트하는 것을 돕는데는 별로 관심이 없다.
+개발/실험적 버젼을 테스트하는 것을 돕고자 하는 사용자들과는 별로 관련이 없다.
 
-어떤 2.6.x.y 커널도 사용가능하지 않다면 그때는 가장 높은 숫자의 2.6.x
+어떤 2.6.x.y 커널도 사용할 수 없다면 그때는 가장 높은 숫자의 2.6.x
 커널이 현재의 안정 커널이다.
 
 2.6.x.y는 "stable" 팀<stable@kernel.org>에 의해 관리되며 거의 매번 격주로
@@ -294,7 +296,7 @@ Andrew Morton에 의해 배포된 실험적인 커널 패치들이다. Andrew는
 서브시스템 커널 트리와 패치들을 가져와서 리눅스 커널 메일링 리스트로
 온 많은 패치들과 한데 묶는다. 이 트리는 새로운 기능들과 패치들을 위한
 장소를 제공하는 역할을 한다. 하나의 패치가 -mm에 한동안 있으면서 그 가치가
-증명되게 되면 Andrew나 서브시스템 메인트너는 그것을 메인라인에 포함시키기
+증명되게 되면 Andrew나 서브시스템 메인테이너는 그것을 메인라인에 포함시키기
 위하여 Linus에게 보낸다.
 
 커널 트리에 포함하고 싶은 모든 새로운 패치들은 Linus에게 보내지기 전에
@@ -327,7 +329,7 @@ Andrew Morton에 의해 배포된 실험적인 커널 패치들이다. Andrew는
     - ACPI development tree, Len Brown <len.brown@intel.com >
     git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
 
-    - Block development tree, Jens Axboe <axboe@suse.de>
+    - Block development tree, Jens Axboe <jens.axboe@oracle.com>
     git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
 
     - DRM development tree, Dave Airlie <airlied@linux.ie>
@@ -367,8 +369,8 @@ bugzilla.kernel.org는 리눅스 커널 개발자들이 커널의 버그를 추
 kernel bugzilla를 사용하는 자세한 방법은 다음을 참조하라.
     http://test.kernel.org/bugzilla/faq.html
 
-메인 커널 소스 디렉토리에 있는 REPORTING-BUGS 파일은 커널 버그일 것 같은
-것을 보고하는는 법에 관한 좋은 템플릿이고 문제를 추적하기 위해서 커널
+메인 커널 소스 디렉토리에 있는 REPORTING-BUGS 파일은 커널 버그라고 생각되는
+것을 보고하는 방법에 관한 좋은 템플릿이며 문제를 추적하기 위해서 커널
 개발자들이 필요로 하는 정보가 무엇들인지를 상세히 설명하고 있다.
 
 
@@ -383,7 +385,7 @@ kernel bugzilla를 사용하는 자세한 방법은 다음을 참조하라.
 점수를 얻을 수 있는 가장 좋은 방법중의 하나이다. 왜냐하면 많은 사람들은
 다른 사람들의 버그들을 수정하기 위하여 시간을 낭비하지 않기 때문이다.
 
-이미 보고된 버그 리포트들을 가지고 작업하기 위해서 http://bugzilla.kernelorg를
+이미 보고된 버그 리포트들을 가지고 작업하기 위해서 http://bugzilla.kernel.org를
 참조하라. 여러분이 앞으로 생겨날 버그 리포트들의 조언자가 되길 원한다면
 bugme-new 메일링 리스트나(새로운 버그 리포트들만이 이곳에서 메일로 전해진다)
 bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메일로 전해진다)
@@ -404,8 +406,8 @@ bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메
 웹상의 많은 다른 곳에도 메일링 리스트의 아카이브들이 있다.
 이러한 아카이브들을 찾으려면 검색 엔진을 사용하라. 예를 들어:
       http://dir.gmane.org/gmane.linux.kernel
-여러분이 새로운 문제에 관해 리스트에 올리기 전에 말하고 싶은 주제에 대한
-것을 아카이브에서 먼저 찾기를 강력히 권장한다. 이미 상세하게 토론된 많은
+여러분이 새로운 문제에 관해 리스트에 올리기 전에 말하고 싶은 주제에 관한
+것을 아카이브에서 먼저 찾아보기를 강력히 권장한다. 이미 상세하게 토론된 많은
 것들이 메일링 리스트의 아카이브에 기록되어 있다.
 
 각각의 커널 서브시스템들의 대부분은 자신들의 개발에 관한 노력들로 이루어진
@@ -443,7 +445,7 @@ bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메
 무엇보다도 메일링 리스트의 다른 구독자들에게 보여주려 한다는 것을 기억하라.
 
 
-커뮤니티와 일하는 법
+커뮤니티와 협력하는 법
 --------------------
 
 커널 커뮤니티의 목적은 가능한한 가장 좋은 커널을 제공하는 것이다. 여러분이
@@ -474,7 +476,7 @@ bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메
 올바른 방향의 해결책으로 이끌어갈 의지가 있다면 받아들여질 것이라는 점을
 기억하라.
 
-여러분의 첫 패치에  여러분이 수정해야하는 십여개 정도의 회신이 오는
+여러분의 첫 패치에 여러분이 수정해야하는 십여개 정도의 회신이 오는
 경우도 흔하다. 이것은 여러분의 패치가 받아들여지지 않을 것이라는 것을
 의미하는 것이 아니고 개인적으로 여러분에게 감정이 있어서 그러는 것도
 아니다. 간단히 여러분의 패치에 제기된 문제들을 수정하고 그것을 다시
@@ -486,12 +488,12 @@ bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메
 커널 커뮤니티는 가장 전통적인 회사의 개발 환경과는 다르다. 여기에 여러분들의
 문제를 피하기 위한 목록이 있다.
   여러분들이 제안한 변경들에 관하여 말할 때 좋은 것들 :
-    - " 이것은 여러 문제들을 해겹합니다."
+    - "이것은 여러 문제들을 해겹합니다."
     - "이것은 2000 라인의 코드를 제거합니다."
     - "이것은 내가 말하려는 것에 관해 설명하는 패치입니다."
     - "나는 5개의 다른 아키텍쳐에서 그것을 테스트했슴으로..."
-    - "여기에 일련의 작은 패치들이 있습음로..."
-    - "이것은 일반적인 머신에서 성능을 향상시키므로..."
+    - "여기에 일련의 작은 패치들이 있슴음로..."
+    - "이것은 일반적인 머신에서 성능을 향상시킴으로..."
 
   여러분들이 말할 때 피해야 할 좋지 않은 것들 :
     - "우리를 그것을 AIT/ptx/Solaris에서 이러한 방법으로 했다. 그러므로 그것은 좋은 것임에 틀립없다..."
@@ -500,7 +502,7 @@ bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메
     - "이것은 우리의 엔터프라이즈 상품 라인을 위한 것이다."
     - "여기에 나의 생각을 말하고 있는 1000 페이지 설계 문서가 있다."
     - "나는 6달동안 이것을 했으니..."
-    - "여기세 5000라인 짜리 패치가 있으니..."
+    - "여기에 5000라인 짜리 패치가 있으니..."
     - "나는 현재 뒤죽박죽인 것을 재작성했다. 그리고 여기에..."
     - "나는 마감시한을 가지고 있으므로 이 패치는 지금 적용될 필요가 있다."
 
@@ -510,13 +512,13 @@ bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메
 없다는 것이다. 리눅스 커널의 작업 환경에서는 단지 이메일 주소만
 알수 있기 때문에 여성과 소수 민족들도 모두 받아들여진다. 국제적으로
 일하게 되는 측면은 사람의 이름에 근거하여 성별을 추측할 수 없게
-하기때문에  차별을 없애는 데 도움을 준다. Andrea라는 이름을 가진 남자와
+하기때문에 차별을 없애는 데 도움을 준다. Andrea라는 이름을 가진 남자와
 Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅스 커널에서
 작업하며 생각을 표현해왔던 대부분의 여성들은 긍정적인 경험을 가지고
 있다.
 
 언어 장벽은 영어에 익숙하지 않은 몇몇 사람들에게 문제가 될 수도 있다.
- 언어의 훌륭한 구사는 메일링 리스트에서 올바르게 자신의 생각을
+언어의 훌륭한 구사는 메일링 리스트에서 올바르게 자신의 생각을
 표현하기 위하여 필요하다. 그래서 여러분은 이메일을 보내기 전에
 영어를 올바르게 사용하고 있는지를 체크하는 것이 바람직하다.
 
@@ -524,13 +526,13 @@ Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅
 여러분의 변경을 나누어라
 ------------------------
 
-리눅스 커널 커뮤니티는 한꺼번에 굉장히 큰 코드의 묶음을 쉽게
+리눅스 커널 커뮤니티는 한꺼번에 굉장히 큰 코드의 묶음(chunk)을 쉽게
 받아들이지 않는다. 변경은 적절하게 소개되고, 검토되고, 각각의
 부분으로 작게 나누어져야 한다. 이것은 회사에서 하는 것과는 정확히
 반대되는 것이다. 여러분들의 제안은 개발 초기에 일찍이 소개되야 한다.
 그래서 여러분들은 자신이 하고 있는 것에 관하여 피드백을 받을 수 있게
 된다. 커뮤니티가 여러분들이 커뮤니티와 함께 일하고 있다는 것을
-느끼도록 만들고 커뮤니티가 여러분의 기능을 위한 쓰레기 장으로서
+느끼도록 만들고 커뮤니티가 여러분의 기능을 위한 쓰레기 장으로써
 사용되지 않고 있다는 것을 느끼게 하자. 그러나 메일링 리스트에 한번에
 50개의 이메일을 보내지는 말아라. 여러분들의 일련의 패치들은 항상
 더 작아야 한다.
@@ -539,7 +541,7 @@ Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅
 
 1) 작은 패치들은 여러분의 패치들이 적용될 수 있는 확률을 높여준다.
    왜냐하면 다른 사람들은 정확성을 검증하기 위하여 많은 시간과 노력을
-   들이기를 원하지 않는다. 5줄의 패치는 메인트너가 거의 몇 초간 힐끗
+   들이기를 원하지 않는다. 5줄의 패치는 메인테이너가 거의 몇 초간 힐끗
    보면 적용될 수 있다. 그러나 500 줄의 패치는 정확성을 검토하기 위하여
    몇시간이 걸릴 수도 있다(걸리는 시간은 패치의 크기 혹은 다른 것에
    비례하여 기하급수적으로 늘어난다).
@@ -558,18 +560,18 @@ Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅
     간결하고 가장 뛰어난 답을 보길 원한다. 훌륭한 학생은 이것을 알고
     마지막으로 답을 얻기 전 중간 과정들을 제출하진 않는다.
 
-    커널 개발도 마찬가지이다. 메인트너들과 검토하는 사람들은 문제를
+    커널 개발도 마찬가지이다. 메인테이너들과 검토하는 사람들은 문제를
     풀어나가는 과정속에 숨겨진 과정을 보길 원하진 않는다. 그들은
     간결하고 멋진 답을 보길 원한다."
 
-커뮤니티와 함께 일하며 뛰어난 답을 찾고 여러분들의 완성되지 않은 일들
-사이에 균형을 유지해야 하는 어려움이 있을 수 있다. 그러므로 프로세스의
-초반에 여러분의 일을 향상시키기위한 피드백을 얻는 것 뿐만 아니라
+커뮤니티와 협력하며 뛰어난 답을 찾는 것과 여러분들의 끝마치지 못한 작업들
+사이에 균형을 유지해야 하는 것은 어려울지도 모른다. 그러므로 프로세스의
+초반에 여러분의 작업을 향상시키기위한 피드백을 얻는 것 뿐만 아니라
 여러분들의 변경들을 작은 묶음으로 유지해서 심지어는 여러분의 작업의
-모든 부분이 지금은 포함될 준비가 되어있지 않지만 작은 부분은 이미
+모든 부분이 지금은 포함될 준비가 되어있지 않지만 작은 부분은 벌써
 받아들여질 수 있도록 유지하는 것이 바람직하다.
 
-또한 완성되지 않았고 "나중에 수정될 것이다." 와 같은 것들은 포함하는
+또한 완성되지 않았고 "나중에 수정될 것이다." 와 같은 것들을 포함하는
 패치들은 받아들여지지 않을 것이라는 점을 유념하라.
 
 변경을 정당화해라
@@ -577,7 +579,7 @@ Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅
 
 여러분들의 나누어진 패치들을 리눅스 커뮤니티가 왜 반영해야 하는지를
 알도록 하는 것은 매우 중요하다. 새로운 기능들이 필요하고 유용하다는
-것은 반드시 그에 맞는 이유가 있어야 한다.
+것은 반드시 그에 합당한 이유가 있어야 한다.
 
 
 변경을 문서화해라
@@ -588,7 +590,7 @@ Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅
 것이다. 그리고 항상 그 내용을 보길 원하는 모든 사람들을 위해 보존될
 것이다. 패치는 완벽하게 다음과 같은 내용들을 포함하여 설명해야 한다.
   - 변경이 왜 필요한지
-  - 패치에 관한 전체 설계 어프로치
+  - 패치에 관한 전체 설계 접근(approach)
   - 구현 상세들
   - 테스트 결과들
 
@@ -600,7 +602,7 @@ Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅
 
 
 이 모든 것을 하는 것은 매우 어려운 일이다. 완벽히 소화하는 데는 적어도 몇년이
-걸릴 수도 있다. 많은 인내와 결의가 필요한 계속되는 개선의 과정이다. 그러나
+걸릴 수도 있다. 많은 인내와 결심이 필요한 계속되는 개선의 과정이다. 그러나
 가능한한 포기하지 말라. 많은 사람들은 이전부터 해왔던 것이고 그 사람들도
 정확하게 여러분들이 지금 서 있는 그 곳부터  시작했었다.
 
@@ -620,4 +622,4 @@ David A. Wheeler, Junio Hamano, Michael Kerrisk, and Alex Shepard에게도 감
 
 
 
-메인트너: Greg Kroah-Hartman <greg@kroah.com>
+메인테이너: Greg Kroah-Hartman <greg@kroah.com>

Documentation/ko_KR/stable_api_nonsense.txt

@@ -0,0 +1,195 @@
+NOTE:
+This is a version of Documentation/stable_api_nonsense.txt translated
+into korean
+This document is maintained by barrios <minchan.kim@gmail.com>
+If you find any difference between this document and the original file or
+a problem with the translation, please contact the maintainer of this file.
+
+Please also note that the purpose of this file is to be easier to
+read for non English (read: korean) speakers and is not intended as
+a fork. So if you have any comments or updates for this file please
+try to update the original English file first.
+
+==================================
+이 문서는
+Documentation/stable_api_nonsense.txt
+의 한글 번역입니다.
+
+역자： 김민찬 <minchan.kim@gmail.com>
+감수： 이제이미 <jamee.lee@samsung.com>
+==================================
+
+리눅스 커널 드라이버 인터페이스
+(여러분들의 모든 질문에 대한 답 그리고 다른 몇가지)
+
+Greg Kroah-Hartman <greg@kroah.com>
+
+이 문서는 리눅스가 왜 바이너리 커널 인터페이스를 갖지 않는지, 왜 변하지
+않는(stable) 커널 인터페이스를 갖지 않는지를 설명하기 위해 쓰여졌다.
+이 문서는 커널과 유저공간 사이의 인터페이스가 아니라 커널 내부의
+인터페이스들을 설명하고 있다는 것을 유념하라. 커널과 유저공간 사이의
+인터페이스는 응용프로그램이 사용하는 syscall 인터페이스이다. 그 인터페이스는
+오랫동안 거의 변하지 않았고 앞으로도 변하지 않을 것이다. 나는 pre 0.9에서
+만들어졌지만 최신의 2.6 커널 배포에서도 잘 동작하는 프로그램을 가지고
+있다. 이 인터페이스는 사용자와 응용프로그램 개발자들이 변하지 않을 것이라고
+여길수 있는 것이다.
+
+
+초록
+----
+여러분은 변하지 않는 커널 인터페이스를 원한다고 생각하지만 실제로는
+그렇지 않으며 심지어는 그것을 알아채지 못한다. 여러분이 원하는 것은
+안정되게 실행되는 드라이버이며 드라이버가 메인 커널 트리에 있을 때
+그런 안정적인 드라이버를 얻을 수 있게 된다. 또한 여러분의 드라이버가
+메인 커널 트리에 있다면 다른 많은 좋은 이점들을 얻게 된다. 그러한 것들이
+리눅스를 강건하고, 안정적이며, 성숙한 운영체제로 만들어 놓음으로써
+여러분들로 하여금 바로 리눅스를 사용하게 만드는 이유이다.
+
+
+소개
+----
+
+커널 내부의 인터페이스가 바뀌는 것을 걱정하며 커널 드라이버를 작성하고
+싶어하는 사람은 정말 이상한 사람이다. 세상의 대다수의 사람들은 이 인터페이스를
+보지못할 것이며 전혀 걱정하지도 않는다.
+
+먼저, 나는 closed 소스, hidden 소스, binary blobs, 소스 wrappers, 또는 GPL로
+배포되었지만 소스 코드를 갖고 있지 않은 커널 드라이버들을 설명하는 어떤 다른
+용어들에 관한 어떤 법적인 문제에 관해서는 언급하지 않을 것이다. 어떤 법적인
+질문들을 가지고 있다면 변호사와 연락하라. 나는 프로그래머이므로 여기서 기술적인
+문제들만을 설명하려고 한다. (법적인 문제를 경시하는 것은 아니다. 그런 문제들은
+엄연히 현실에 있고 여러분들은 항상 그 문제들을 인식하고 있을 필요는 있다.)
+
+자, 두가지의 주요 주제가 있다. 바이너리 커널 인터페이스들과 변하지 않는
+커널 소스 인터페이들. 그것들은 서로 의존성을 가지고 있지만 바이너리
+문제를 먼저 풀고 넘어갈 것이다.
+
+
+
+바이너리 커널 인터페이스
+------------------------
+우리가 변하지 않는 커널 소스 인터페이스를 가지고 있다고 가정하자. 그러면
+바이너리 인터페이스 또한 자연적으로 변하지 않을까? 틀렸다. 리눅스 커널에
+관한 다음 사실들을 생각해보라.
+   - 여러분들이 사용하는 C 컴파일러의 버젼에 따라 다른 커널 자료 구조들은
+     다른 alignmnet들을 갖게 될것이고 다른 방법으로(함수들을 inline으로
+     했느냐, 아니냐) 다른 함수들을 포함하는 것도 가능한다. 중요한 것은
+     개별적인 함수 구성이 아니라 자료 구조 패딩이 달라진다는 점이다.
+   - 여러분이 선택한 커널 빌드 옵션에 따라서 커널은 다양한 것들을 가정할
+     수 있다.
+      - 다른 구조체들은 다른 필드들을 포함할 수 있다.
+      - 몇몇 함수들은 전혀 구현되지 않을 수도 있다(즉, 몇몇 lock들은
+        non-SMP 빌드에서는 사라져 버릴수도 있다).
+      - 커널내에 메모리는 build optoin들에 따라 다른 방법으로 align될수
+        있다.
+      - 리눅스는 많은 다양한 프로세서 아키텍쳐에서 실행된다. 한 아키텍쳐의
+        바이너리 드라이버를 다른 아키텍쳐에서 정상적으로 실행시킬 방법은
+        없다.
+
+커널을 빌드했던 C 컴파일러와 정확하게 같은 것을 사용하고 정확하게 같은
+커널 구성(configuration)을 사용하여 여러분들의 모듈을 빌드하면 간단히
+많은 문제들을 해결할 수 있다. 이렇게 하는 것은 여러분들이 하나의 리눅스
+배포판의 하나의 배포 버젼을 위한 모듈만을 제공한다면 별일 아닐 것이다.
+그러나 각기 다른 리눅스 배포판마다 한번씩 빌드하는 수를 각 리눅스 배포판마다
+제공하는 다른 릴리즈의 수와 곱하게 되면 이번에는 각 릴리즈들의 다른 빌드
+옵션의 악몽과 마주하게  것이다. 또한 각 리눅스 배포판들은 다른 하드웨어
+종류에(다른 프로세서 타입과 다른 옵션들) 맞춰져 있는 많은 다른 커널들을
+배포한다. 그러므로 한번의 배포에서조차 여러분들의 모듈은 여러 버젼을
+만들 필요가 있다.
+
+나를 믿어라. 여러분들은 이러한 종류의 배포를 지원하려고 시도한다면 시간이
+지나면 미칠지경이 될 것이다. 난 이러한 것을 오래전에 아주 어렵게 배웠다...
+
+
+
+변하지않는 커널 소스 인터페이스들
+---------------------------------
+
+리눅스 커널 드라이버를 계속해서 메인 커널 트리에 반영하지 않고
+유지보수하려고 하는 사름들과 이 문제를 논의하게 되면 훨씬 더
+"논란의 여지가 많은" 주제가 될 것이다.
+
+리눅스 커널 개발은 끊임없이 빠른 속도로 이루어지고 있으며 결코
+느슨해진 적이 없다. 커널 개발자들이 현재 인터페이스들에서 버그를
+발견하거나 무엇인가 할수 있는 더 좋은 방법을 찾게 되었다고 하자.
+그들이 발견한 것을 실행한다면 아마도 더 잘 동작하도록 현재 인터페이스들을
+수정하게 될 것이다. 그들이 그런 일을 하게되면 함수 이름들은 변하게 되고,
+구조체들은 늘어나거나 줄어들게 되고, 함수 파라미터들은 재작업될 것이다.
+이러한 일이 발생되면 커널 내에 이 인터페이스를 사용했던 인스턴스들이 동시에
+수정될 것이며 이러한 과정은 모든 것이 계속해서 올바르게 동작할 것이라는
+것을 보장한다.
+
+이러한 것의 한 예로써, 커널 내부의 USB 인터페이스들은 이 서브시스템이
+생긴 이후로 적어도 3번의 다른 재작업을 겪었다. 이 재작업들은 많은 다른
+문제들을 풀었다.
+   - 데이터 스트림들의 동기적인 모델에서 비동기적인 모델로의 변화. 이것은
+     많은 드라이버들의 복잡성을 줄이고 처리량을 향상시켜 현재는 거의 모든
+     USB 장치들의 거의 최대 속도로 실행되고 있다.
+   - USB 드라이버가 USB 코어로부터 데이터 패킷들을 할당받로록 한 변경으로
+     인해서 지금의 모든 드라이버들은 많은 문서화된 데드락을 수정하기 위하여
+     USB 코어에게 더 많은 정보를 제공해야만 한다.
+
+이것은 오랫동안 자신의 오래된 USB 인터페이스들을 유지해야 하는 closed 운영체제들과는
+완전히 반대되는 것이다. closed된 운영체제들은 새로운 개발자들에게 우연히 낡은
+인터페이스를 사용하게 할 기회를 주게되며, 적절하지 못한 방법으로 처리하게 되어
+운영체제의 안정성을 해치는 문제를 야기하게 된다.
+
+이 두가지의 예들 모두, 모든 개발자들은 꼭 이루어져야 하는 중요한 변화들이라고
+동의를 하였고 비교적 적은 고통으로 변경되어졌다. 리눅스가 변하지 않는 소스
+인터페이스를 고집한다면, 새로운 인터페이스가 만들어지게 되며 반면 기존의 오래된
+것들, 그리고 깨진 것들은 계속해서 유지되어야 하며 이러한 일들은 USB 개발자들에게
+또 다른 일거리를 주게 된다. 모든 리눅스 USB 개발자들에게 자신의 그들의 업무를
+마친 후 시간을 투자하여 아무 득도 없는 무료 봉사를 해달라고 하는 것은 가능성이
+희박한 일이다.
+
+보안 문제 역시 리눅스에게는 매우 중요하다. 보안 문제가 발견되면 그것은
+매우 짧은 시간 안에 수정된다. 보안 문제는 그 문제를 해결하기 위하여
+여러번 내부 커널 인터페이스들을 재작업하게 만들었다. 이러한 문제가
+발생하였을 때 그 인터페이스들을 사용하는 모든 드라이버들도 동시에
+수정되어 보안 문제가 앞으로 갑작스럽게 생기지는 않을 것이라는 것을
+보장한다. 내부 인터페이스들의 변경이 허락되지 않으면 이러한 종류의 보안
+문제를 수정하고 그것이 다시 발생하지 않을 것이라고 보장하는 것은 가능하지
+않을 것이다.
+
+커널 인터페이스들은 계속해서 정리되고 있다. 현재 인터페이스를 사용하는
+사람이 한명도 없다면 그것은 삭제된다. 이것은 커널이 가능한한 가장 작게
+유지되며 존재하는 모든 가능성이 있는 인터페이스들이 테스트된다는 것을
+보장한다(사용되지 않는 인터페이스들은 유효성 검증을 하기가 거의 불가능하다).
+
+
+무엇을 해야 하나
+---------------
+자, 여러분이 메인 커널 트리에 있지 않은 리눅스 커널 드라이버를 가지고
+있다면 여러분은 즉, 개발자는 무엇을 해야 하나? 모든 배포판마다 다른
+커널 버젼을 위한 바이너리 드라이버를 배포하는 것은 악몽이며 계속해서
+변하고 있는 커널 인터페이스들의 맞처 유지보수하려고 시도하는 것은 힘든
+일이다.
+
+간단하다. 여러분의 커널 드라이버를 메인 커널 트리에 반영하라(우리는 여기서
+GPL을 따르는 배포 드라이버에 관해 얘기하고 있다는 것을 상기하라. 여러분의
+코드가 이러한 분류에 해당되지 않는다면 행운을 빈다. 여러분 스스로 어떻게든
+해야만 한다). 여러분의 드라이버가 트리에 있게되면 커널 인터페이스가
+변경되더라도 가장 먼저 커널에 변경을 가했던 사람에 의해서 수정될 것이다.
+이것은 여러분의 드라이버가 여러분의 별다른 노력없이 항상 빌드가 가능하며
+동작하는 것을 보장한다.
+
+메인 커널 트리에 여러분의 드라이버를 반영하면 얻게 되는 장점들은 다음과 같다.
+   - 관리의 드는 비용(원래 개발자의)은 줄어줄면서 드라이버의 질은 향상될 것이다.
+   - 다른 개발자들이 여러분의 드라이버에 기능들을 추가 할 것이다.
+   - 다른 사람들은 여러분의 드라이버에 버그를 발견하고 수정할 것이다.
+   - 다른 사람들은 여러분의 드라이버의 개선점을 찾을 줄 것이다.
+   - 외부 인터페이스 변경으로 인해 여러분의 드라이버의 수정이 필요하다면 다른
+     사람들이 드라이버를 업데이트할 것이다.
+   - 여러분의 드라이버는 별다른 노력 없이 모든 리눅스 배포판에  자동적으로
+     추가될 것이다.
+
+리눅스는 다른 운영 체제보다 "쉽게 쓸수 있는(out of the box)" 많은 다른 장치들을
+지원하고 어떤 다른 운영 체제보다 다양한 아키텍쳐위에서 이러한 장치들을 지원하기 때문에
+이러한 증명된 개발 모델은 틀림없이 바로 가고 있는 것이다.
+
+
+
+------
+
+이 문서의 초안을 검토해주고 코멘트 해준 Randy Dunlap, Andrew Morton, David Brownell,
+Hanna Linder, Robert Love, 그리고 Nishanth Aravamudan에게 감사한다.

Documentation/lguest/lguest.c

@@ -62,8 +62,8 @@ typedef uint8_t u8;
 #endif
 /* We can have up to 256 pages for devices. */
 #define DEVICE_PAGES 256
-/* This fits nicely in a single 4096-byte page. */
-#define VIRTQUEUE_NUM 127
+/* This will occupy 2 pages: it must be a power of 2. */
+#define VIRTQUEUE_NUM 128
 
 /*L:120 verbose is both a global flag and a macro.  The C preprocessor allows
  * this, and although I wouldn't recommend it, it works quite nicely here. */
@@ -1036,16 +1036,22 @@ static void add_virtqueue(struct device *dev, unsigned int num_descs,
 	void *p;
 
 	/* First we need some pages for this virtqueue. */
-	pages = (vring_size(num_descs) + getpagesize() - 1) / getpagesize();
+	pages = (vring_size(num_descs, getpagesize()) + getpagesize() - 1)
+		/ getpagesize();
 	p = get_pages(pages);
 
+	/* Initialize the virtqueue */
+	vq->next = NULL;
+	vq->last_avail_idx = 0;
+	vq->dev = dev;
+
 	/* Initialize the configuration. */
 	vq->config.num = num_descs;
 	vq->config.irq = devices.next_irq++;
 	vq->config.pfn = to_guest_phys(p) / getpagesize();
 
 	/* Initialize the vring. */
-	vring_init(&vq->vring, num_descs, p);
+	vring_init(&vq->vring, num_descs, p, getpagesize());
 
 	/* Add the configuration information to this device's descriptor. */
 	add_desc_field(dev, VIRTIO_CONFIG_F_VIRTQUEUE,
@@ -1056,9 +1062,6 @@ static void add_virtqueue(struct device *dev, unsigned int num_descs,
 	for (i = &dev->vq; *i; i = &(*i)->next);
 	*i = vq;
 
-	/* Link virtqueue back to device. */
-	vq->dev = dev;
-
 	/* Set the routine to call when the Guest does something to this
 	 * virtqueue. */
 	vq->handle_output = handle_output;
@@ -1092,6 +1095,7 @@ static struct device *new_device(const char *name, u16 type, int fd,
 	dev->desc = new_dev_desc(type);
 	dev->handle_input = handle_input;
 	dev->name = name;
+	dev->vq = NULL;
 	return dev;
 }
 
@@ -1342,7 +1346,7 @@ static bool service_io(struct device *dev)
 	if (out->type & VIRTIO_BLK_T_SCSI_CMD) {
 		fprintf(stderr, "Scsi commands unsupported\n");
 		in->status = VIRTIO_BLK_S_UNSUPP;
-		wlen = sizeof(in);
+		wlen = sizeof(*in);
 	} else if (out->type & VIRTIO_BLK_T_OUT) {
 		/* Write */
 
@@ -1363,7 +1367,7 @@ static bool service_io(struct device *dev)
 			/* Die, bad Guest, die. */
 			errx(1, "Write past end %llu+%u", off, ret);
 		}
-		wlen = sizeof(in);
+		wlen = sizeof(*in);
 		in->status = (ret >= 0 ? VIRTIO_BLK_S_OK : VIRTIO_BLK_S_IOERR);
 	} else {
 		/* Read */
@@ -1376,10 +1380,10 @@ static bool service_io(struct device *dev)
 		ret = readv(vblk->fd, iov+1, in_num-1);
 		verbose("READ from sector %llu: %i\n", out->sector, ret);
 		if (ret >= 0) {
-			wlen = sizeof(in) + ret;
+			wlen = sizeof(*in) + ret;
 			in->status = VIRTIO_BLK_S_OK;
 		} else {
-			wlen = sizeof(in);
+			wlen = sizeof(*in);
 			in->status = VIRTIO_BLK_S_IOERR;
 		}
 	}

Documentation/lguest/lguest.txt

@@ -109,10 +109,6 @@ Running Lguest:
   See http://linux-net.osdl.org/index.php/Bridge for general information
   on how to get bridging working.
 
-- You can also create an inter-guest network using
-  "--sharenet=<filename>": any two guests using the same file are on
-  the same network.  This file is created if it does not exist.
-
 There is a helpful mailing list at http://ozlabs.org/mailman/listinfo/lguest
 
 Good luck!

Documentation/local_ops.txt

@@ -45,29 +45,6 @@ long fails. The definition looks like :
 typedef struct { atomic_long_t a; } local_t;
 
 
-* Rules to follow when using local atomic operations
-
-- Variables touched by local ops must be per cpu variables.
-- _Only_ the CPU owner of these variables must write to them.
-- This CPU can use local ops from any context (process, irq, softirq, nmi, ...)
-  to update its local_t variables.
-- Preemption (or interrupts) must be disabled when using local ops in
-  process context to   make sure the process won't be migrated to a
-  different CPU between getting the per-cpu variable and doing the
-  actual local op.
-- When using local ops in interrupt context, no special care must be
-  taken on a mainline kernel, since they will run on the local CPU with
-  preemption already disabled. I suggest, however, to explicitly
-  disable preemption anyway to make sure it will still work correctly on
-  -rt kernels.
-- Reading the local cpu variable will provide the current copy of the
-  variable.
-- Reads of these variables can be done from any CPU, because updates to
-  "long", aligned, variables are always atomic. Since no memory
-  synchronization is done by the writer CPU, an outdated copy of the
-  variable can be read when reading some _other_ cpu's variables.
-
-
 * Rules to follow when using local atomic operations
 
 - Variables touched by local ops must be per cpu variables.

Documentation/markers.txt

@@ -35,12 +35,14 @@ In order to use the macro trace_mark, you should include linux/marker.h.
 
 And,
 
-trace_mark(subsystem_event, "%d %s", someint, somestring);
+trace_mark(subsystem_event, "myint %d mystring %s", someint, somestring);
 Where :
 - subsystem_event is an identifier unique to your event
     - subsystem is the name of your subsystem.
     - event is the name of the event to mark.
-- "%d %s" is the formatted string for the serializer.
+- "myint %d mystring %s" is the formatted string for the serializer. "myint" and
+  "mystring" are repectively the field names associated with the first and
+  second parameter.
 - someint is an integer.
 - somestring is a char pointer.
 

Documentation/namespaces/compatibility-list.txt

@@ -0,0 +1,39 @@
+	Namespaces compatibility list
+
+This document contains the information about the problems user
+may have when creating tasks living in different namespaces.
+
+Here's the summary. This matrix shows the known problems, that
+occur when tasks share some namespace (the columns) while living
+in different other namespaces (the rows):
+
+	UTS	IPC	VFS	PID	User	Net
+UTS	 X
+IPC		 X	 1
+VFS			 X
+PID		 1	 1	 X
+User		 2	 2		 X
+Net						 X
+
+1. Both the IPC and the PID namespaces provide IDs to address
+   object inside the kernel. E.g. semaphore with IPCID or
+   process group with pid.
+
+   In both cases, tasks shouldn't try exposing this ID to some
+   other task living in a different namespace via a shared filesystem
+   or IPC shmem/message. The fact is that this ID is only valid
+   within the namespace it was obtained in and may refer to some
+   other object in another namespace.
+
+2. Intentionally, two equal user IDs in different user namespaces
+   should not be equal from the VFS point of view. In other
+   words, user 10 in one user namespace shouldn't have the same
+   access permissions to files, belonging to user 10 in another
+   namespace.
+
+   The same is true for the IPC namespaces being shared - two users
+   from different user namespaces should not access the same IPC objects
+   even having equal UIDs.
+
+   But currently this is not so.
+

Documentation/networking/00-INDEX

@@ -4,8 +4,6 @@
 	- information on the 3Com EtherLink Plus (3c505) driver.
 6pack.txt
 	- info on the 6pack protocol, an alternative to KISS for AX.25
-Configurable
-	- info on some of the configurable network parameters
 DLINK.txt
 	- info on the D-Link DE-600/DE-620 parallel port pocket adapters
 PLIP.txt
@@ -26,8 +24,6 @@ baycom.txt
 	- info on the driver for Baycom style amateur radio modems
 bridge.txt
 	- where to get user space programs for ethernet bridging with Linux.
-comx.txt
-	- info on drivers for COMX line of synchronous serial adapters.
 cops.txt
 	- info on the COPS LocalTalk Linux driver
 cs89x0.txt
@@ -78,20 +74,14 @@ ltpc.txt
 	- the Apple or Farallon LocalTalk PC card driver
 multicast.txt
 	- Behaviour of cards under Multicast
-ncsa-telnet
-	- notes on how NCSA telnet (DOS) breaks with MTU discovery enabled.
 netdevices.txt
 	- info on network device driver functions exported to the kernel.
 olympic.txt
 	- IBM PCI Pit/Pit-Phy/Olympic Token Ring driver info.
 policy-routing.txt
 	- IP policy-based routing
-pt.txt
-	- the Gracilis Packetwin AX.25 device driver
 ray_cs.txt
 	- Raylink Wireless LAN card driver info.
-routing.txt
-	- the new routing mechanism
 shaper.txt
 	- info on the module that can shape/limit transmitted traffic.
 sk98lin.txt

Documentation/networking/3c505.txt

@@ -14,8 +14,7 @@ If no base address is given at boot time, the driver will autoprobe
 ports 0x300, 0x280 and 0x310 (in that order).  If no IRQ is given, the driver
 will try to probe for it.
 
-The driver can be used as a loadable module.  See net-modules.txt for details
-of the parameters it can take.  
+The driver can be used as a loadable module.
 
 Theoretically, one instance of the driver can now run multiple cards,
 in the standard way (when loading a module, say "modprobe 3c505

Documentation/networking/Configurable

@@ -1,34 +0,0 @@
-
-There are a few network parameters that can be tuned to better match
-the kernel to your system hardware and intended usage. The defaults
-are usually a good choice for 99% of the people 99% of the time, but
-you should be aware they do exist and can be changed.
-
-The current list of parameters can be found in the files:
-
-	linux/net/TUNABLE
-	Documentation/networking/ip-sysctl.txt
-
-Some of these are accessible via the sysctl interface, and many more are
-scheduled to be added in this way. For example, some parameters related 
-to Address Resolution Protocol (ARP) are very easily viewed and altered.
-
-	# cat /proc/sys/net/ipv4/arp_timeout
-	6000
-	# echo 7000 > /proc/sys/net/ipv4/arp_timeout
-	# cat /proc/sys/net/ipv4/arp_timeout
-	7000
-
-Others are already accessible via the related user space programs.
-For example, MAX_WINDOW has a default of 32 k which is a good choice for
-modern hardware, but if you have a slow (8 bit) Ethernet card and/or a slow
-machine, then this will be far too big for the card to keep up with fast 
-machines transmitting on the same net, resulting in overruns and receive errors.
-A value of about 4 k would be more appropriate, which can be set via:
-
-	# route add -net 192.168.3.0 window 4096
-
-The remainder of these can only be presently changed by altering a #define
-in the related header file. This means an edit and recompile cycle.
-
-						Paul Gortmaker 06/96

Documentation/networking/bonding.txt

@@ -554,6 +554,30 @@ xmit_hash_policy
 
 		This algorithm is 802.3ad compliant.
 
+	layer2+3
+
+		This policy uses a combination of layer2 and layer3
+		protocol information to generate the hash.
+
+		Uses XOR of hardware MAC addresses and IP addresses to
+		generate the hash.  The formula is
+
+		(((source IP XOR dest IP) AND 0xffff) XOR
+			( source MAC XOR destination MAC ))
+				modulo slave count
+
+		This algorithm will place all traffic to a particular
+		network peer on the same slave.  For non-IP traffic,
+		the formula is the same as for the layer2 transmit
+		hash policy.
+
+		This policy is intended to provide a more balanced
+		distribution of traffic than layer2 alone, especially
+		in environments where a layer3 gateway device is
+		required to reach most destinations.
+
+		This algorithm is 802.3ad complient.
+
 	layer3+4
 
 		This policy uses upper layer protocol information,
@@ -589,8 +613,9 @@ xmit_hash_policy
 		or may not tolerate this noncompliance.
 
 	The default value is layer2.  This option was added in bonding
-version 2.6.3.  In earlier versions of bonding, this parameter does
-not exist, and the layer2 policy is the only policy.
+	version 2.6.3.  In earlier versions of bonding, this parameter
+	does not exist, and the layer2 policy is the only policy.  The
+	layer2+3 value was added for bonding version 3.2.2.
 
 
 3. Configuring Bonding Devices

Documentation/networking/comx.txt

@@ -1,248 +0,0 @@
-
-		COMX drivers for the 2.2 kernel
-
-Originally written by: Tivadar Szemethy, <tiv@itc.hu>
-Currently maintained by: Gergely Madarasz <gorgo@itc.hu>
-
-Last change: 21/06/1999.
-
-INTRODUCTION
-
-This document describes the software drivers and their use for the 
-COMX line of synchronous serial adapters for Linux version 2.2.0 and
-above.
-The cards are produced and sold by ITC-Pro Ltd. Budapest, Hungary
-For further info contact <info@itc.hu> 
-or http://www.itc.hu (mostly in Hungarian).
-The firmware files and software are available from ftp://ftp.itc.hu
-
-Currently, the drivers support the following cards and protocols:
-
-COMX (2x64 kbps intelligent board)
-CMX (1x256 + 1x128 kbps intelligent board)
-HiCOMX (2x2Mbps intelligent board)
-LoCOMX (1x512 kbps passive board)
-MixCOM (1x512 or 2x512kbps passive board with a hardware watchdog an
-	optional BRI interface and optional flashROM (1-32M))
-SliceCOM	(1x2Mbps channelized E1 board)
-PciCOM	(X21)
-
-At the moment of writing this document, the (Cisco)-HDLC, LAPB, SyncPPP and
-Frame Relay (DTE, rfc1294 IP encapsulation with partially implemented Q933a 
-LMI) protocols are available as link-level protocol. 
-X.25 support is being worked on.
-
-USAGE
-
-Load the comx.o module and the hardware-specific and protocol-specific 
-modules you'll need into the running kernel using the insmod utility.
-This creates the /proc/comx directory.
-See the example scripts in the 'etc' directory.
-
-/proc INTERFACE INTRO
-
-The COMX driver set has a new type of user interface based on the /proc 
-filesystem which eliminates the need for external user-land software doing 
-IOCTL calls. 
-Each network interface or device (i.e. those ones you configure with 'ifconfig'
-and 'route' etc.) has a corresponding directory under /proc/comx. You can
-dynamically create a new interface by saying 'mkdir /proc/comx/comx0' (or you
-can name it whatever you want up to 8 characters long, comx[n] is just a 
-convention).
-Generally the files contained in these directories are text files, which can
-be viewed by 'cat filename' and you can write a string to such a file by
-saying 'echo _string_ >filename'. This is very similar to the sysctl interface.
-Don't use a text editor to edit these files, always use 'echo' (or 'cat'
-where appropriate).
-When you've created the comx[n] directory, two files are created automagically
-in it: 'boardtype' and 'protocol'. You have to fill in these files correctly
-for your board and protocol you intend to use (see the board and protocol 
-descriptions in this file below or the example scripts in the 'etc' directory).
-After filling in these files, other files will appear in the directory for 
-setting the various hardware- and protocol-related informations (for example
-irq and io addresses, keepalive values etc.) These files are set to default 
-values upon creation, so you don't necessarily have to change all of them.
-
-When you're ready with filling in the files in the comx[n] directory, you can
-configure the corresponding network interface with the standard network 
-configuration utilities. If you're unable to bring the interfaces up, look up
-the various kernel log files on your system, and consult the messages for
-a probable reason.
-
-EXAMPLE
-
-To create the interface 'comx0' which is the first channel of a COMX card:
-
-insmod comx 
-# insmod comx-hw-comx ; insmod comx-proto-ppp  (these are usually
-autoloaded if you use the kernel module loader)
-
-mkdir /proc/comx/comx0
-echo comx >/proc/comx/comx0/boardtype
-echo 0x360 >/proc/comx/comx0/io		<- jumper-selectable I/O port 
-echo 0x0a >/proc/comx/comx0/irq		<- jumper-selectable IRQ line
-echo 0xd000 >/proc/comx/comx0/memaddr	<- software-configurable memory
-					   address. COMX uses 64 KB, and this
-					   can be: 0xa000, 0xb000, 0xc000, 
-					   0xd000, 0xe000. Avoid conflicts
-					   with other hardware.
-cat </etc/siol1.rom >/proc/comx/comx0/firmware <- the firmware for the card
-echo HDLC >/proc/comx/comx0/protocol	<- the data-link protocol
-echo 10 >/proc/comx/comx0/keepalive	<- the keepalive for the protocol
-ifconfig comx0 1.2.3.4 pointopoint 5.6.7.8 netmask 255.255.255.255 <-
-					   finally configure it with ifconfig
-Check its status:
-cat /proc/comx/comx0/status
-
-If you want to use the second channel of this board:
-
-mkdir /proc/comx/comx1
-echo comx >/proc/comx/comx1/boardtype
-echo 0x360 >/proc/comx/comx1/io	
-echo 10 >/proc/comx/comx1/irq		
-echo 0xd000 >/proc/comx/comx1/memaddr
-echo 1 >/proc/comx/comx1/channel	<- channels are numbered 
-					   as 0 (default) and 1
-
-Now, check if the driver recognized that you're going to use the other
-channel of the same adapter:
-
-cat /proc/comx/comx0/twin
-comx1
-cat /proc/comx/comx1/twin
-comx0
-
-You don't have to load the firmware twice, if you use both channels of
-an adapter, just write it into the channel 0's /proc firmware file.
-
-Default values: io 0x360 for COMX, 0x320 (HICOMX), irq 10, memaddr 0xd0000
-
-THE LOCOMX HARDWARE DRIVER
-
-The LoCOMX driver doesn't require firmware, and it doesn't use memory either,
-but it uses DMA channels 1 and 3. You can set the clock rate (if enabled by
-jumpers on the board) by writing the kbps value into the file named 'clock'.
-Set it to 'external' (it is the default) if you have external clock source.
-
-(Note: currently the LoCOMX driver does not support the internal clock)
-
-THE COMX, CMX AND HICOMX DRIVERS
-
-On the HICOMX, COMX and CMX, you have to load the firmware (it is different for
-the three cards!). All these adapters can share the same memory
-address (we usually use 0xd0000). On the CMX you can set the internal
-clock rate (if enabled by jumpers on the small adapter boards) by writing
-the kbps value into the 'clock' file. You have to do this before initializing
-the card. If you use both HICOMX and CMX/COMX cards, initialize the HICOMX
-first. The I/O address of the HICOMX board is not configurable by any
-method available to the user: it is hardwired to 0x320, and if you have to 
-change it, consult ITC-Pro Ltd.
-
-THE MIXCOM DRIVER
-
-The MixCOM board doesn't require firmware, the driver communicates with
-it through I/O ports. You can have three of these cards in one machine.
-
-THE SLICECOM DRIVER
-
-The SliceCOM board doesn't require firmware. You can have 4 of these cards
-in one machine. The driver doesn't (yet) support shared interrupts, so
-you will need a separate IRQ line for every board.
-Read Documentation/networking/slicecom.txt for help on configuring
-this adapter.
-
-THE HDLC/PPP LINE PROTOCOL DRIVER
-
-The HDLC/SyncPPP line protocol driver uses the kernel's built-in syncppp
-driver (syncppp.o). You don't have to manually select syncppp.o when building
-the kernel, the dependencies compile it in automatically.
-
-
-
-
-EXAMPLE
-(setting up hw parameters, see above)
-
-# using HDLC:
-echo hdlc >/proc/comx/comx0/protocol
-echo 10 >/proc/comx/comx0/keepalive	<- not necessary, 10 is the default
-ifconfig comx0 1.2.3.4 pointopoint 5.6.7.8 netmask 255.255.255.255
-
-(setting up hw parameters, see above)
-
-# using PPP:
-echo ppp >/proc/comx/comx0/protocol
-ifconfig comx0 up
-ifconfig comx0 1.2.3.4 pointopoint 5.6.7.8 netmask 255.255.255.255
-
-
-THE LAPB LINE PROTOCOL DRIVER
-
-For this, you'll need to configure LAPB support (See 'LAPB Data Link Driver' in
-'Network options' section) into your kernel (thanks to Jonathan Naylor for his 
-excellent implementation). 
-comx-proto-lapb.o provides the following files in the appropriate directory
-(the default values in parens): t1 (5), t2 (1), n2 (20), mode (DTE, STD) and
-window (7). Agree with the administrator of your peer router on these
-settings (most people use defaults, but you have to know if you are DTE or
-DCE).
-
-EXAMPLE
-
-(setting up hw parameters, see above)
-echo lapb >/proc/comx/comx0/protocol
-echo dce >/proc/comx/comx0/mode		<- DCE interface in this example
-ifconfig comx0 1.2.3.4 pointopoint 5.6.7.8 netmask 255.255.255.255
-
-
-THE FRAME RELAY PROTOCOL DRIVER
-
-You DON'T need any other frame relay related modules from the kernel to use
-COMX-Frame Relay. This protocol is a bit more complicated than the others, 
-because it allows to use 'subinterfaces' or DLCIs within one physical device.
-First you have to create the 'master' device (the actual physical interface)
-as you would do for other protocols. Specify 'frad' as protocol type.
-Now you can bring this interface up by saying 'ifconfig comx0 up' (or whatever
-you've named the interface). Do not assign any IP address to this interface
-and do not set any routes through it.
-Then, set up your DLCIs the following way: create a comx interface for each
-DLCI you intend to use (with mkdir), and write 'dlci' to the 'boardtype' file, 
-and 'ietf-ip' to the 'protocol' file. Currently, the only supported 
-encapsulation type is this (also called as RFC1294/1490 IP encapsulation).
-Write the DLCI number to the 'dlci' file, and write the name of the physical
-COMX device to the file called 'master'. 
-Now you can assign an IP address to this interface and set routes using it.
-See the example file for further info and example config script.
-Notes: this driver implements a DTE interface with partially implemented
-Q933a LMI.
-You can find an extensively commented example in the 'etc' directory.
-
-FURTHER /proc FILES
-
-boardtype:
-Type of the hardware. Valid values are:
- 'comx', 'hicomx', 'locomx', 'cmx', 'slicecom'.
-
-protocol:
-Data-link protocol on this channel. Can be: HDLC, LAPB, PPP, FRAD
-
-status:
-You can read the channel's actual status from the 'status' file, for example
-'cat /proc/comx/comx3/status'.
-
-lineup_delay:
-Interpreted in seconds (default is 1). Used to avoid line jitter: the system
-will consider the line status 'UP' only if it is up for at least this number
-of seconds.
-
-debug: 
-You can set various debug options through this file. Valid options are:
-'comx_events', 'comx_tx', 'comx_rx', 'hw_events', 'hw_tx', 'hw_rx'.
-You can enable a debug options by writing its name prepended by a '+' into
-the debug file, for example 'echo +comx_rx >comx0/debug'. 
-Disabling an option happens similarly, use the '-' prefix 
-(e.g. 'echo -hw_rx >debug').
-Debug results can be read from the debug file, for example: 
-tail -f /proc/comx/comx2/debug
-
-

Documentation/networking/driver.txt

@@ -61,7 +61,10 @@ Transmit path guidelines:
 2) Do not forget to update netdev->trans_start to jiffies after
    each new tx packet is given to the hardware.
 
-3) Do not forget that once you return 0 from your hard_start_xmit
+3) A hard_start_xmit method must not modify the shared parts of a
+   cloned SKB.
+
+4) Do not forget that once you return 0 from your hard_start_xmit
    method, it is your driver's responsibility to free up the SKB
    and in some finite amount of time.
 

Documentation/networking/ncsa-telnet

@@ -1,16 +0,0 @@
-NCSA telnet doesn't work with path MTU discovery enabled. This is due to a
-bug in NCSA that also stops it working with other modern networking code
-such as Solaris.
-
-The following information is courtesy of 
-Marek <marekm@i17linuxb.ists.pwr.wroc.pl>
-
-There is a fixed version somewhere on ftp.upe.ac.za (sorry, I don't
-remember the exact pathname, and this site is very slow from here).
-It may or may not be faster for you to get it from
-ftp://ftp.ists.pwr.wroc.pl/pub/msdos/telnet/ncsa_upe/tel23074.zip
-(source is in v230704s.zip).  I have tested it with 1.3.79 (with
-path mtu discovery enabled - ncsa 2.3.08 didn't work) and it seems
-to work.  I don't know if anyone is working on this code - this
-version is over a year old.  Too bad - it's faster and often more
-stable than these windoze telnets, and runs on almost anything...

Documentation/networking/pt.txt

@@ -1,58 +0,0 @@
-This is the README for the Gracilis Packetwin device driver, version 0.5
-ALPHA for Linux 1.3.43.
-
-These files will allow you to talk to the PackeTwin (now know as PT) and
-connect through it just like a pair of TNCs.  To do this you will also
-require the AX.25 code in the kernel enabled.
-
-There are four files in this archive; this readme, a patch file, a .c file
-and finally a .h file.  The two program files need to be put into the
-drivers/net directory in the Linux source tree, for me this is the
-directory /usr/src/linux/drivers/net.  The patch file needs to be patched in
-at the top of the Linux source tree (/usr/src/linux in my case).
-
-You will most probably have to edit the pt.c file to suit your own setup,
-this should just involve changing some of the defines at the top of the file. 
-Please note that if you run an external modem you must specify a speed of 0.
-
-The program is currently setup to run a 4800 baud external modem on port A
-and a Kantronics DE-9600 daughter board on port B so if you have this (or
-something similar) then you're right.
-
-To compile in the driver, put the files in the correct place and patch in
-the diff.  You will have to re-configure the kernel again before you
-recompile it. 
-
-The driver is not real good at the moment for finding the card.  You can
-'help' it by changing the order of the potential addresses in the structure
-found in the pt_init() function so the address of where the card is is put
-first.
-
-After compiling, you have to get them going, they are pretty well like any
-other net device and just need ifconfig to get them going.
-As an example, here is my /etc/rc.net
---------------------------
-
-#
-# Configure the PackeTwin, port A.
-/sbin/ifconfig pt0a 44.136.8.87 hw ax25 vk2xlz mtu 512 
-/sbin/ifconfig pt0a 44.136.8.87 broadcast 44.136.8.255 netmask 255.255.255.0
-/sbin/route add -net 44.136.8.0 netmask 255.255.255.0 dev pt0a
-/sbin/route add -net 44.0.0.0 netmask 255.0.0.0 gw 44.136.8.68 dev pt0a
-/sbin/route add -net 138.25.16.0 netmask 255.255.240.0 dev pt0a
-/sbin/route add -host 44.136.8.255 dev pt0a
-#
-# Configure the PackeTwin, port B.
-/sbin/ifconfig pt0b 44.136.8.87 hw ax25 vk2xlz-1 mtu 512
-/sbin/ifconfig pt0b 44.136.8.87 broadcast 44.255.255.255 netmask 255.0.0.0
-/sbin/route add -host 44.136.8.216 dev pt0b
-/sbin/route add -host 44.136.8.95  dev pt0b
-/sbin/route add -host 44.255.255.255 dev pt0b
-
-This version of the driver comes under the GNU GPL.  If you have one of my
-previous (non-GPL) versions of the driver, please update to this one.
-
-I hope that this all works well for you.  I would be pleased to hear how
-many people use the driver and if it does its job.
-
-  - Craig vk2xlz <csmall@small.dropbear.id.au>

Documentation/networking/routing.txt

@@ -1,46 +0,0 @@
-The directory ftp.inr.ac.ru:/ip-routing contains:
-
-- iproute.c - "professional" routing table maintenance utility.
-
-- rdisc.tar.gz - rdisc daemon, ported from Sun.
-	STRONGLY RECOMMENDED FOR ALL HOSTS.
-
-- routing.tgz - original Mike McLagan's route by source patch.
-		Currently it is obsolete.
-
-- gated.dif-ss<NEWEST>.gz - gated-R3_6Alpha_2 fixes.
-	        Look at README.gated
-
-- mrouted-3.8.dif.gz - mrouted-3.8 fixes.
-
-- rtmon.c - trivial debugging utility: reads and stores netlink.
-
-
-NEWS for user.
-
-- Policy based routing. Routing decisions are made on the basis
-  not only of destination address, but also source address,
-  TOS and incoming interface.
-- Complete set of IP level control messages.
-  Now Linux is the only OS in the world complying to RFC requirements.
-  Great win 8)
-- New interface addressing paradigm.
-  Assignment of address ranges to interface,
-  multiple prefixes etc. etc.
-  Do not bother, it is compatible with the old one. Moreover:
-- You don't need to do "route add aaa.bbb.ccc... eth0" anymore,
-  it is done automatically.
-- "Abstract" UNIX sockets and security enhancements.
-  This is necessary to use TIRPC and TLI emulation library.
-
-NEWS for hacker.
-
-- New destination cache. Flexible, robust and just beautiful.
-- Network stack is reordered, simplified, optimized, a lot of bugs fixed.
-  (well, and new bugs were introduced, but I haven't seen them yet 8))
-  It is difficult to describe all the changes, look into source.
-
-If you see this file, then this patch works 8)
-
-Alexey Kuznetsov.
-kuznet@ms2.inr.ac.ru

Documentation/networking/slicecom.hun

@@ -1,371 +0,0 @@
-
-SliceCOM adapter felhasznaloi dokumentacioja - 0.51 verziohoz
-
-Bartók István <bartoki@itc.hu>
-Utolso modositas: Wed Aug 29 17:26:58 CEST 2001
-
------------------------------------------------------------------
-
-Hasznalata:
-
-Forditas:
-
-Code maturity level options
-	[*] Prompt for development and/or incomplete code/drivers
-
-Network device support
-	Wan interfaces
-		<M> MultiGate (COMX) synchronous
-			<M> Support for MUNICH based boards: SliceCOM, PCICOM (NEW)
-			<M> Support for HDLC and syncPPP...
-
-
-A modulok betoltese:
-
-modprobe comx
-
-modprobe comx-proto-ppp		# a Cisco-HDLC es a SyncPPP protokollt is
-				# ez a modul adja
-
-modprobe comx-hw-munich		# a modul betoltodeskor azonnal jelent a
-				# syslogba a detektalt kartyakrol
-
-
-Konfiguralas:
-
-# Ezen az interfeszen Cisco-HDLC vonali protokoll fog futni
-# Az interfeszhez rendelt idoszeletek: 1,2 (128 kbit/sec-es vonal)
-# (a G.703 keretben az elso adatot vivo idoszelet az 1-es)
-#
-mkdir /proc/comx/comx0.1/
-echo slicecom	>/proc/comx/comx0.1/boardtype
-echo hdlc	>/proc/comx/comx0.1/protocol
-echo 1 2	>/proc/comx/comx0.1/timeslots
-
-
-# Ezen az interfeszen SyncPPP vonali protokoll fog futni
-# Az interfeszhez rendelt idoszelet: 3 (64 kbit/sec-es vonal)
-#
-mkdir /proc/comx/comx0.2/
-echo slicecom	>/proc/comx/comx0.2/boardtype
-echo ppp	>/proc/comx/comx0.2/protocol
-echo 3		>/proc/comx/comx0.2/timeslots
-
-...
-
-ifconfig comx0.1 up
-ifconfig comx0.2 up
-
------------------------------------------------------------------
-
-A COMX driverek default 20 csomagnyi transmit queue-t rendelnek a halozati
-interfeszekhez. WAN halozatokban ennel hosszabbat is szokas hasznalni
-(20 es 100 kozott), hogy a vonal kihasznaltsaga nagy terheles eseten jobb
-legyen (bar ezzel megno a varhato kesleltetes a csomagok sorban allasa miatt):
-
-# ifconfig comx0 txqueuelen 50
-
-Ezt a beallitasi lehetoseget csak az ujabb disztribuciok ifconfig parancsa
-tamogatja (amik mar a 2.2 kernelekhez keszultek, mint a RedHat 6.1 vagy a
-Debian 2.2).
-
-A 2.1-es Debian disztribuciohoz a http://www.debian.org/~rcw/2.2/netbase/
-cimrol toltheto le ujabb netbase csomag, ami mar ilyet tamogato ifconfig
-parancsot tartalmaz. Bovebben a 2.2 kernel hasznalatarol Debian 2.1 alatt:
-http://www.debian.org/releases/stable/running-kernel-2.2
-
------------------------------------------------------------------
-
-A kartya LED-jeinek jelentese:
-
-piros	- eg, ha Remote Alarm-ot kuld a tuloldal
-zold	- eg, ha a vett jelben megtalalja a keretszinkront
-
-Reszletesebben:
-
-piros:	zold:	jelentes:
-
--	-	nincs keretszinkron (nincs jel, vagy rossz a jel)
--	eg	"minden rendben"
-eg	eg	a vetel OK, de a tuloldal Remote Alarm-ot kuld
-eg	-	ez nincs ertelmezve, egyelore funkcio nelkul
-
------------------------------------------------------------------
-
-Reszletesebb leiras a hardver beallitasi lehetosegeirol:
-
-Az altalanos,- es a protokoll-retegek beallitasi lehetosegeirol a 'comx.txt'
-fajlban leirtak SliceCOM kartyanal is ervenyesek, itt csak a hardver-specifikus
-beallitasi lehetosegek vannak osszefoglalva:
-
-Konfiguralasi interfesz a /proc/comx/ alatt:
-
-Minden timeslot-csoportnak kulon comx* interfeszt kell letrehozni mkdir-rel:
-comx0, comx1, .. stb. Itt beallithato, hogy az adott interfesz hanyadik kartya
-melyik timeslotja(i)bol alljon ossze. A Cisco-fele serial3:1 elnevezesek
-(serial3:1 = a 3. kartyaban az 1-es idoszelet-csoport) Linuxon aliasing-ot
-jelentenenek, ezert mi nem tudunk ilyen elnevezest hasznalni.
-
-Tobb kartya eseten a comx0.1, comx0.2, ... vagy slice0.1, slice0.2 nevek
-hasznalhatoak.
-
-Tobb SliceCOM kartya is lehet egy gepben, de sajat interrupt kell mindegyiknek,
-nem tud meg megosztott interruptot kezelni.
-
-Az egesz kartyat erinto beallitasok:
-
-Az ioport es irq beallitas nincs: amit a PCI BIOS kioszt a rendszernek,
-azt hasznalja a driver.
-
-
-comx0/boardnum	- hanyadik SliceCOM kartya a gepben (a 'termeszetes' PCI
-		sorrendben ertve: ahogyan a /proc/pci-ban vagy az 'lspci'
-		kimeneteben megjelenik, altalaban az alaplapi PCI meghajto
-		aramkorokhoz kozelebb eso kartyak a kisebb sorszamuak)
-
-		Default: 0 (0-tol kezdodik a szamolas)
-
-
-Bar a kovetkezoket csak egy-egy interfeszen allitjuk at, megis az egesz kartya
-mukodeset egyszerre allitjak. A megkotes hogy csak UP-ban levo interfeszen
-hasznalhatoak, azert van, mert kulonben nem vart eredmenyekre vezetne egy ilyen
-paranccsorozat:
-
-	echo 0        >boardnum
-	echo internal >clock_source
-	echo 1        >boardnum
-
-- Ez a 0-s board clock_source-at allitana at.
-
-Ezek a beallitasok megmaradnak az osszes interfesz torlesekor, de torlodnek
-a driver modul ki/betoltesekor.
-
-
-comx0/clock_source - A Tx orajelforrasa, a Cisco-val hasonlatosra keszult.
-	Hasznalata:
-
-	papaya:# echo line     >/proc/comx/comx0/clock_source
-	papaya:# echo internal >/proc/comx/comx0/clock_source
-
-	line     - A Tx orajelet a vett adatfolyambol dekodolja, igyekszik
-		igazodni hozza. Ha nem lat orajelet az inputon, akkor
-		atall a sajat orajelgeneratorara.
-	internal - A Tx orajelet a sajat orajelgeneratora szolgaltatja.
-
-	Default: line
-
-	Normal osszeallitas eseten a tavkozlesi szolgaltato eszkoze
-	(pl. HDSL modem) adja az orajelet, ezert ez a default.
-
-
-comx0/framing	- A CRC4 ki/be kapcsolasa
-
-	A CRC4: 16 PCM keretet (A PCM keret az, amibe a 32 darab 64
-	kilobites csatorna van bemultiplexalva. Nem osszetevesztendo a HDLC
-	kerettel.) 2x8 -as csoportokra osztanak, es azokhoz 4-4 bites CRC-t
-	szamolnak. Elsosorban a vonal minosegenek a monitorozasara szolgal.
-
-	papaya:~# echo crc4	>/proc/comx/comx0/framing
-	papaya:~# echo no-crc4	>/proc/comx/comx0/framing
-
-	Default a 'crc4', a MATAV vonalak altalaban igy futnak. De ha nem
-	egyforma is a beallitas a vonal ket vegen, attol a forgalom altalaban
-	at tud menni.
-
-
-comx0/linecode	- A vonali kodolas beallitasa
-
-	papaya:~# echo hdb3	>/proc/comx/comx0/linecode
-	papaya:~# echo ami	>/proc/comx/comx0/linecode
-
-	Default a 'hdb3', a MATAV vonalak igy futnak.
-	
-	(az AMI kodolas igen ritka E1-es vonalaknal). Ha ez a beallitas nem
-	egyezik a vonal ket vegen, akkor elofordulhat hogy a keretszinkron
-	osszejon, de CRC4-hibak es a vonalakon atvitt adatokban is hibak
-	keletkeznek (amit a HDLC/SyncPPP szinten CRC-hibaval jelez)
-
-
-comx0/reg	- a kartya aramkoreinek, a MUNICH (reg) es a FALC (lbireg)
-comx0/lbireg	regisztereinek kozvetlen elerese. Hasznalata:
-
-		echo >reg 0x04 0x0	- a 4-es regiszterbe 0-t ir
-		echo >reg 0x104		- printk()-val kiirja a 4-es regiszter
-					tartalmat a syslogba.
-
-		WARNING: ezek csak a fejleszteshez keszultek, sok galibat
-		lehet veluk okozni!
-
-
-comx0/loopback - A kartya G.703 jelenek a visszahurkolasara is van lehetoseg:
-
-	papaya:# echo none   >/proc/comx/comx0/loopback
-	papaya:# echo local  >/proc/comx/comx0/loopback
-	papaya:# echo remote >/proc/comx/comx0/loopback
-
-	none   - nincs visszahurkolas, normal mukodes
-	local  - a kartya a sajat maga altal adott jelet kapja vissza
-	remote - a kartya a kivulrol vett jelet adja kifele
-
-	Default: none
-
------------------------------------------------------------------
-
-Az interfeszhez (Cisco terminologiaban 'channel-group') kapcsolodo beallitasok:
-
-comx0/timeslots	- mely timeslotok (idoszeletek) tartoznak az adott interfeszhez.
-
-	papaya:~# cat /proc/comx/comx0/timeslots
-	1 3 4 5 6
-	papaya:~#
-
-	Egy timeslot megkeresese (hanyas interfeszbe tartozik nalunk):
-
-	papaya:~# grep ' 4' /proc/comx/comx*/timeslots
-	/proc/comx/comx0/timeslots:1 3 4 5 6
-	papaya:~#
-
-	Beallitasa:
-	papaya:~# echo '1 5 2 6 7 8' >/proc/comx/comx0/timeslots
-	
-	A timeslotok sorrendje nem szamit, '1 3 2' ugyanaz mint az '1 2 3'.
-
-	Beallitashoz az adott interfesznek DOWN-ban kell lennie
-	(ifconfig comx0 down), de ugyanannak a kartyanak a tobbi interfesze
-	uzemelhet kozben.
-
-	Beallitaskor leellenorzi, hogy az uj timeslotok nem utkoznek-e egy
-	masik interfesz timeslotjaival. Ha utkoznek, akkor nem allitja at.
-
-	Mindig 10-es szamrendszerben tortenik a timeslotok ertelmezese, nehogy
-	a 08, 09 alaku felirast rosszul ertelmezze.
-
------------------------------------------------------------------
-
-Az interfeszek es a kartya allapotanak lekerdezese:
-
-- A ' '-szel kezdodo sorok az eredeti kimenetet, a //-rel kezdodo sorok a
-magyarazatot jelzik.
-
- papaya:~$ cat /proc/comx/comx1/status
- Interface administrative status is UP, modem status is UP, protocol is UP
- Modem status changes: 0, Transmitter status is IDLE, tbusy: 0
- Interface load (input): 978376 / 947808 / 951024 bits/s (5s/5m/15m)
-               (output): 978376 / 947848 / 951024 bits/s (5s/5m/15m)
- Debug flags: none
- RX errors: len: 22, overrun: 1, crc: 0, aborts: 0
-            buffer overrun: 0, pbuffer overrun: 0
- TX errors: underrun: 0
- Line keepalive (value: 10) status UP [0]
-
-// Itt kezdodik a hardver-specifikus resz:
- Controller status:
-         No alarms
-
-// Alarm: hibajelzes:
-//
-// No alarms - minden rendben
-//
-// LOS  - Loss Of Signal - nem erzekel jelet a bemeneten.
-// AIS  - Alarm Indication Signal - csak egymas utani 1-esek jonnek
-//	a bemeneten, a tuloldal igy is jelezheti hogy meghibasodott vagy
-//	nincs inicializalva.
-// AUXP - Auxiliary Pattern Indication - 01010101.. sorozat jon a bemeneten.
-// LFA  - Loss of Frame Alignment - nincs keretszinkron
-// RRA  - Receive Remote Alarm - a tuloldal el, de hibat jelez.
-// LMFA - Loss of CRC4 Multiframe Alignment - nincs CRC4-multikeret-szinkron
-// NMF  - No Multiframe alignment Found after 400 msec - ilyen alarm a no-crc4
-//	es crc4 keretezesek eseten nincs, lasd lentebb
-//
-// Egyeb lehetseges hibajelzesek:
-//
-// Transmit Line Short - a kartya ugy erzi hogy az adasi kimenete rovidre
-//	van zarva, ezert kikapcsolta az adast. (nem feltetlenul veszi eszre
-//	a kulso rovidzarat)
-
-// A veteli oldal csomagjainak lancolt listai, debug celokra:
-
- Rx ring:
-         rafutott: 0
-         lastcheck: 50845731, jiffies: 51314281
-         base: 017b1858
-         rx_desc_ptr: 0
-         rx_desc_ptr: 017b1858
-         hw_curr_ptr: 017b1858
-         06040000 017b1868 017b1898 c016ff00
-         06040000 017b1878 017b1e9c c016ff00
-         46040000 017b1888 017b24a0 c016ff00
-         06040000 017b1858 017b2aa4 c016ff00
-
-// A kartyat hasznalo tobbi interfesz: a 0-s channel-group a comx1 interfesz,
-// es az 1,2,...,16 timeslotok tartoznak hozza:
-
- Interfaces using this board: (channel-group, interface, timeslots)
-          0 comx1: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
-          1 comx2: 17
-          2 comx3: 18
-          3 comx4: 19
-          4 comx5: 20
-          5 comx6: 21
-          6 comx7: 22
-          7 comx8: 23
-          8 comx9: 24
-          9 comx10: 25
-         10 comx11: 26
-         11 comx12: 27
-         12 comx13: 28
-         13 comx14: 29
-         14 comx15: 30
-         15 comx16: 31
-
-// Hany esemenyt kezelt le a driver egy-egy hardver-interrupt kiszolgalasanal:
-
- Interrupt work histogram:
- hist[ 0]:        0 hist[ 1]:        2 hist[ 2]:    18574 hist[ 3]:       79
- hist[ 4]:       14 hist[ 5]:        1 hist[ 6]:        0 hist[ 7]:        1
- hist[ 8]:        0 hist[ 9]:        7
-
-// Hany kikuldendo csomag volt mar a Tx-ringben amikor ujabb lett irva bele:
-
- Tx ring histogram:
- hist[ 0]:     2329 hist[ 1]:        0 hist[ 2]:        0 hist[ 3]:        0
-
-// Az E1-interfesz hiba-szamlaloi, az rfc2495-nek megfeleloen:
-// (kb. a Cisco routerek "show controllers e1" formatumaban: http://www.cisco.com/univercd/cc/td/doc/product/software/ios11/rbook/rinterfc.htm#xtocid25669126)
-
-Data in current interval (91 seconds elapsed):
-   9516 Line Code Violations, 65 Path Code Violations, 2 E-Bit Errors
-   0 Slip Secs, 2 Fr Loss Secs, 2 Line Err Secs, 0 Degraded Mins
-   0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 11 Unavail Secs
-Data in Interval 1 (15 minutes):
-   0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors
-   0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
-   0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
-Data in last 4 intervals (1 hour):
-   0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors
-   0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
-   0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
-Data in last 96 intervals (24 hours):
-   0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors
-   0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
-   0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
-
------------------------------------------------------------------
-
-Nehany kulonlegesebb beallitasi lehetoseg (idovel beepulhetnek majd a driverbe):
-Ezekkel sok galibat lehet okozni, nagyon ovatosan kell oket hasznalni!
-
-	modified CRC-4, for improved interworking of CRC-4 and non-CRC-4
-	devices: (lasd page 107 es g706 Annex B)
-		lbireg[ 0x1b ] |= 0x08
-		lbireg[ 0x1c ] |= 0xc0
-	- ilyenkor ertelmezett az NMF - 'No Multiframe alignment Found after
-	400 msec' alarm.
-
-	FALC - a vonali meghajto IC
-	local loop - a sajat adasomat halljam vissza
-	remote loop - a kivulrol jovo adast adom vissza
-
-	Egy hibakeresesre hasznalhato dolog:
-		- 1-es timeslot local loop a FALC-ban:	echo >lbireg 0x1d 0x21
-		- local loop kikapcsolasa:		echo >lbireg 0x1d 0x00

Documentation/networking/slicecom.txt

@@ -1,369 +0,0 @@
-
-SliceCOM adapter user's documentation - for the 0.51 driver version
-
-Written by Bartók István <bartoki@itc.hu>
-
-English translation: Lakatos György <gyuri@itc.hu>
-Mon Dec 11 15:28:42 CET 2000
-
-Last modified: Wed Aug 29 17:25:37 CEST 2001
-
------------------------------------------------------------------
-
-Usage:
-
-Compiling the kernel:
-
-Code maturity level options
-	[*] Prompt for development and/or incomplete code/drivers
-
-Network device support
-	Wan interfaces
-		<M> MultiGate (COMX) synchronous
-			<M> Support for MUNICH based boards: SliceCOM, PCICOM (NEW)
-			<M> Support for HDLC and syncPPP...
-
-
-Loading the modules:
-
-modprobe comx
-
-modprobe comx-proto-ppp		# module for  Cisco-HDLC and SyncPPP protocols
-
-modprobe comx-hw-munich		# the module logs information by the kernel
-				# about the detected boards
-
-
-Configuring the board:
-
-# This interface will use the Cisco-HDLC line protocol,
-# the timeslices assigned are 1,2 (128 KiBit line speed)
-# (the first data timeslice in the G.703 frame is no. 1)
-#
-mkdir /proc/comx/comx0.1/
-echo slicecom	>/proc/comx/comx0.1/boardtype
-echo hdlc	>/proc/comx/comx0.1/protocol
-echo 1 2	>/proc/comx/comx0.1/timeslots
-
-
-# This interface uses SyncPPP line protocol, the assigned 
-# is no. 3 (64 KiBit line speed)
-#
-mkdir /proc/comx/comx0.2/
-echo slicecom	>/proc/comx/comx0.2/boardtype
-echo ppp	>/proc/comx/comx0.2/protocol
-echo 3		>/proc/comx/comx0.2/timeslots
-
-...
-
-ifconfig comx0.1 up
-ifconfig comx0.2 up
-
------------------------------------------------------------------
-
-The COMX interfaces use a 10 packet transmit queue by default, however WAN
-networks sometimes use bigger values (20 to 100), to utilize the line better
-by large traffic (though the line delay increases because of more packets
-join the queue).
-
-# ifconfig comx0 txqueuelen 50
-
-This option is only supported by the ifconfig command of the later 
-distributions, which came with 2.2 kernels, such as RedHat 6.1 or Debian 2.2.
-
-You can download a newer netbase packet from 
-http://www.debian.org/~rcw/2.2/netbase/ for Debian 2.1, which has a new
-ifconfig. You can get further information about using 2.2 kernel with
-Debian 2.1 from http://www.debian.org/releases/stable/running-kernel-2.2
-
------------------------------------------------------------------
-
-The SliceCom LEDs:
-
-red	- on, if the interface is unconfigured, or it gets Remote Alarm-s
-green	- on, if the board finds frame-sync in the received signal 	
-
-A bit more detailed:
-
-red:	green:	meaning:
-
--	-	no frame-sync, no signal received, or signal SNAFU.
--	on	"Everything is OK"
-on	on	Reception is ok, but the remote end sends Remote Alarm
-on	-	The interface is unconfigured
-
------------------------------------------------------------------
-
-A more detailed description of the hardware setting options:
-
-The general and the protocol layer options described in the 'comx.txt' file
-apply to the SliceCom as well, I only summarize the SliceCom hardware specific
-settings below.
-
-The '/proc/comx' configuring interface:
-
-An interface directory should be created for every timeslot group with
-'mkdir', e,g: 'comx0', 'comx1' etc. The timeslots can be assigned here to the
-specific interface. The Cisco-like naming convention (serial3:1 - first
-timeslot group of the 3rd. board) can't be used here, because these mean IP
-aliasing in Linux.
-
-You can give any meaningful name to keep the configuration clear; 
-e.g: 'comx0.1', 'comx0.2', 'comx1.1', comx1.2', if you have two boards
-with two interfaces each.
-
-Settings, which apply to the board:
-
-Neither 'io' nor 'irq' settings required, the driver uses the resources
-given by the PCI BIOS.
-
-comx0/boardnum	- board number of the SliceCom in the PC (using the 'natural'
-		PCI order) as listed in '/proc/pci' or the output of the
-	 	'lspci' command, generally the slots nearer to the motherboard
-		PCI driver chips have the lower numbers.
-		
-		Default: 0 (the counting starts with 0)
-
-Though the options below are to be set on a single interface, they apply to the
-whole board. The restriction, to use them on 'UP' interfaces, is because the 
-command sequence below could lead to unpredictable results.
-
-	# echo 0        >boardnum
-	# echo internal >clock_source
-	# echo 1        >boardnum
-
-The sequence would set the clock source of board 0.
-
-These settings will persist after all the interfaces are cleared, but are
-cleared when the driver module is unloaded and loaded again.
-
-comx0/clock_source - source of the transmit clock
-	Usage:
-
-	# echo line     >/proc/comx/comx0/clock_source
-	# echo internal >/proc/comx/comx0/clock_source
-
-	line	- The Tx clock is being decoded if the input data stream,
-		if no clock seen on the input, then the board will use it's
-		own clock generator.
-
-	internal - The Tx clock is supplied by the builtin clock generator. 	
-
-	Default: line
-
-	Normally, the telecommunication company's end device (the HDSL
-	modem) provides the Tx clock, that's why 'line' is the default.
-
-comx0/framing	- Switching CRC4 off/on
-
-	CRC4: 16 PCM frames (The 32 64Kibit channels are multiplexed into a
-	PCM frame, nothing to do with HDLC frames) are divided into 2x8
-	groups, each group has a 4 bit CRC.
-
-	# echo crc4	>/proc/comx/comx0/framing
-	# echo no-crc4	>/proc/comx/comx0/framing
-
-	Default is 'crc4', the Hungarian MATAV lines behave like this. 
-	The traffic generally passes if this setting on both ends don't match.
-
-comx0/linecode	- Setting the line coding
-
-	# echo hdb3	>/proc/comx/comx0/linecode
-	# echo ami	>/proc/comx/comx0/linecode
-
-	Default a 'hdb3', MATAV lines use this.
-	
-	(AMI coding is rarely used with E1 lines). Frame sync may occur, if
-	this setting doesn't match the other end's, but CRC4 and data errors
-	will come, which will result in CRC errors on HDLC/SyncPPP level. 
-
-comx0/reg	- direct access to the board's MUNICH (reg) and FALC (lbireg)
-comx0/lbireg	circuit's registers  
-
-	# echo >reg 0x04 0x0	- write 0 to register 4
-	# echo >reg 0x104	- write the contents of register 4 with
-				printk() to syslog
-
-WARNING! These are only for development purposes, messing with this will
-	result much trouble!
-
-comx0/loopback - Places a loop to the board's G.703 signals
-
-	# echo none   >/proc/comx/comx0/loopback
-	# echo local  >/proc/comx/comx0/loopback
-	# echo remote >/proc/comx/comx0/loopback
-
-	none   - normal operation, no loop
-	local  - the board receives it's own output
-	remote - the board sends the received data to the remote side
-
-	Default: none
-
------------------------------------------------------------------
-
-Interface (channel group in Cisco terms) settings: 
-
-comx0/timeslots	- which timeslots belong to the given interface
-
-	Setting:
-
-	# echo '1 5 2 6 7 8' >/proc/comx/comx0/timeslots
-
-	# cat /proc/comx/comx0/timeslots
-	1 2 5 6 7 8 
-	#
-
-	Finding a timeslot: 
-
-	# grep ' 4' /proc/comx/comx*/timeslots
-	/proc/comx/comx0/timeslots:1 3 4 5 6
-	#
-
-	The timeslots can be in any order, '1 2 3' is the same as '1 3 2'.
-
-	The interface has to be DOWN during the setting ('ifconfig comx0
-	down'), but the other interfaces could operate normally.
-
-	The driver checks if the assigned timeslots are vacant, if not, then
-	the setting won't be applied.
-
-	The timeslot values are treated as decimal numbers, not to misunderstand
-	values of 08, 09 form.
-
------------------------------------------------------------------
-
-Checking the interface and board status:
-
-- Lines beginning with ' ' (space) belong to the original output, the lines
-which begin with '//' are the comments.
-
- papaya:~$ cat /proc/comx/comx1/status
- Interface administrative status is UP, modem status is UP, protocol is UP
- Modem status changes: 0, Transmitter status is IDLE, tbusy: 0
- Interface load (input): 978376 / 947808 / 951024 bits/s (5s/5m/15m)
-               (output): 978376 / 947848 / 951024 bits/s (5s/5m/15m)
- Debug flags: none
- RX errors: len: 22, overrun: 1, crc: 0, aborts: 0
-            buffer overrun: 0, pbuffer overrun: 0
- TX errors: underrun: 0
- Line keepalive (value: 10) status UP [0]
-
-// The hardware specific part starts here:
- Controller status:
-         No alarms
-
-// Alarm: 
-//
-// No alarms - Everything OK
-//
-// LOS  - Loss Of Signal - No signal sensed on the input
-// AIS  - Alarm Indication Signal - The remote side sends '11111111'-s, 
-//	it tells, that there's an error condition, or it's not
-//	initialised.
-// AUXP - Auxiliary Pattern Indication - 01010101.. received.
-// LFA  - Loss of Frame Alignment - no frame sync received.
-// RRA  - Receive Remote Alarm - the remote end's OK, but signals error cond.
-// LMFA - Loss of CRC4 Multiframe Alignment - no CRC4 multiframe sync.
-// NMF  - No Multiframe alignment Found after 400 msec - no such alarm using
-//	no-crc4 or crc4 framing, see below.
-//
-// Other possible error messages:
-//
-// Transmit Line Short - the board felt, that it's output is short-circuited,
-// 	so it switched the transmission off. (The board can't definitely tell,
-//	that it's output is short-circuited.)
-
-// Chained list of the received packets, for debug purposes:
-
- Rx ring:
-         rafutott: 0
-         lastcheck: 50845731, jiffies: 51314281
-         base: 017b1858
-         rx_desc_ptr: 0
-         rx_desc_ptr: 017b1858
-         hw_curr_ptr: 017b1858
-         06040000 017b1868 017b1898 c016ff00
-         06040000 017b1878 017b1e9c c016ff00
-         46040000 017b1888 017b24a0 c016ff00
-         06040000 017b1858 017b2aa4 c016ff00
-
-// All the interfaces using the board: comx1, using the 1,2,...16 timeslots,
-// comx2, using timeslot 17, etc.
-
- Interfaces using this board: (channel-group, interface, timeslots)
-          0 comx1: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
-          1 comx2: 17
-          2 comx3: 18
-          3 comx4: 19
-          4 comx5: 20
-          5 comx6: 21
-          6 comx7: 22
-          7 comx8: 23
-          8 comx9: 24
-          9 comx10: 25
-         10 comx11: 26
-         11 comx12: 27
-         12 comx13: 28
-         13 comx14: 29
-         14 comx15: 30
-         15 comx16: 31
-
-// The number of events handled by the driver during an interrupt cycle:
-
- Interrupt work histogram:
- hist[ 0]:        0 hist[ 1]:        2 hist[ 2]:    18574 hist[ 3]:       79
- hist[ 4]:       14 hist[ 5]:        1 hist[ 6]:        0 hist[ 7]:        1
- hist[ 8]:        0 hist[ 9]:        7
-
-// The number of packets to send in the Tx ring, when a new one arrived:
-
- Tx ring histogram:
- hist[ 0]:     2329 hist[ 1]:        0 hist[ 2]:        0 hist[ 3]:        0
-
-// The error counters of the E1 interface, according to the RFC2495,
-// (similar to the Cisco "show controllers e1" command's output:
-// http://www.cisco.com/univercd/cc/td/doc/product/software/ios11/rbook/rinterfc.htm#xtocid25669126)
-
-Data in current interval (91 seconds elapsed):
-   9516 Line Code Violations, 65 Path Code Violations, 2 E-Bit Errors
-   0 Slip Secs, 2 Fr Loss Secs, 2 Line Err Secs, 0 Degraded Mins
-   0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 11 Unavail Secs
-Data in Interval 1 (15 minutes):
-   0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors
-   0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
-   0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
-Data in last 4 intervals (1 hour):
-   0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors
-   0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
-   0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
-Data in last 96 intervals (24 hours):
-   0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors
-   0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
-   0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
-
------------------------------------------------------------------
-
-Some unique options, (may get into the driver later):
-Treat them very carefully, these can cause much trouble!
-
-	modified CRC-4, for improved interworking of CRC-4 and non-CRC-4
-	devices: (see page 107 and g706 Annex B)
-		lbireg[ 0x1b ] |= 0x08
-		lbireg[ 0x1c ] |= 0xc0
-
-	- The NMF - 'No Multiframe alignment Found after 400 msec' alarm 
-	comes into account.
-
-	FALC - the line driver chip.
-	local loop - I hear my transmission back.
-	remote loop - I echo the remote transmission back.
-
-	Something useful for finding errors:
-	
-		- local loop for timeslot 1 in the FALC chip:
-
-	# echo >lbireg 0x1d 0x21
-
-		- Switching the loop off:
-
-	# echo >lbireg 0x1d 0x00

Documentation/networking/wavelan.txt

@@ -12,8 +12,8 @@ and many Linux driver to support it.
 "wavelan" driver (old ISA Wavelan)
 ----------------
 	o Config :	Network device -> Wireless LAN -> AT&T WaveLAN
-	o Location :	.../drivers/net/wavelan*
-	o in-line doc :	.../drivers/net/wavelan.p.h
+	o Location :	.../drivers/net/wireless/wavelan*
+	o in-line doc :	.../drivers/net/wireless/wavelan.p.h
 	o on-line doc :
 	    http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Wavelan.html
 

Documentation/nfsroot.txt

@@ -92,8 +92,10 @@ ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>
   autoconfiguration.
 
   The <autoconf> parameter can appear alone as the value to the `ip'
-  parameter (without all the ':' characters before) in which case auto-
-  configuration is used.
+  parameter (without all the ':' characters before).  If the value is
+  "ip=off" or "ip=none", no autoconfiguration will take place, otherwise
+  autoconfiguration will take place.  The most common way to use this
+  is "ip=dhcp".
 
   <client-ip>	IP address of the client.
 
@@ -142,8 +144,10 @@ ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>
 		into the kernel will be used, regardless of the value of
 		this option.
 
-                  off or none: don't use autoconfiguration (default)
+                  off or none: don't use autoconfiguration
+				(do static IP assignment instead)
 		  on or any:   use any protocol available in the kernel
+			       (default)
 		  dhcp:        use DHCP
 		  bootp:       use BOOTP
 		  rarp:        use RARP

Documentation/parport-lowlevel.txt

@@ -339,6 +339,10 @@ Use this function to register your device driver on a parallel port
 ('port').  Once you have done that, you will be able to use
 parport_claim and parport_release in order to use the port.
 
+The ('name') argument is the name of the device that appears in /proc
+filesystem. The string must be valid for the whole lifetime of the
+device (until parport_unregister_device is called).
+
 This function will register three callbacks into your driver:
 'preempt', 'wakeup' and 'irq'.  Each of these may be NULL in order to
 indicate that you do not want a callback.

Documentation/powerpc/booting-without-of.txt

@@ -52,6 +52,7 @@ Table of Contents
       i) Freescale QUICC Engine module (QE)
       j) CFI or JEDEC memory-mapped NOR flash
       k) Global Utilities Block
+      l) Xilinx IP cores
 
   VII - Specifying interrupt information for devices
     1) interrupts property
@@ -851,12 +852,18 @@ address which can extend beyond that limit.
         /cpus/PowerPC,970FX@0
         /cpus/PowerPC,970FX@1
       (unit addresses do not require leading zeroes)
-    - d-cache-line-size : one cell, L1 data cache line size in bytes
-    - i-cache-line-size : one cell, L1 instruction cache line size in
+    - d-cache-block-size : one cell, L1 data cache block size in bytes (*)
+    - i-cache-block-size : one cell, L1 instruction cache block size in
       bytes
     - d-cache-size : one cell, size of L1 data cache in bytes
     - i-cache-size : one cell, size of L1 instruction cache in bytes
 
+(*) The cache "block" size is the size on which the cache management
+instructions operate. Historically, this document used the cache
+"line" size here which is incorrect. The kernel will prefer the cache
+block size and will fallback to cache line size for backward
+compatibility.
+
   Recommended properties:
 
     - timebase-frequency : a cell indicating the frequency of the
@@ -870,6 +877,10 @@ address which can extend beyond that limit.
       for the above, the common code doesn't use that property, but
       you are welcome to re-use the pSeries or Maple one. A future
       kernel version might provide a common function for this.
+    - d-cache-line-size : one cell, L1 data cache line size in bytes
+      if different from the block size
+    - i-cache-line-size : one cell, L1 instruction cache line size in
+      bytes if different from the block size
 
   You are welcome to add any property you find relevant to your board,
   like some information about the mechanism used to soft-reset the
@@ -1634,8 +1645,9 @@ platforms are moved over to use the flattened-device-tree model.
      MAC addresses passed by the firmware when no information other
      than indices is available to associate an address with a device.
    - phy-connection-type : a string naming the controller/PHY interface type,
-     i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id", "tbi",
-     or "rtbi".
+     i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id" (Internal
+     Delay), "rgmii-txid" (delay on TX only), "rgmii-rxid" (delay on RX only),
+     "tbi", or "rtbi".
 
    Example:
 	ucc@2000 {
@@ -2242,6 +2254,266 @@ platforms are moved over to use the flattened-device-tree model.
 			   available.
 			   For Axon: 0x0000012a
 
+   l) Xilinx IP cores
+
+   The Xilinx EDK toolchain ships with a set of IP cores (devices) for use
+   in Xilinx Spartan and Virtex FPGAs.  The devices cover the whole range
+   of standard device types (network, serial, etc.) and miscellanious
+   devices (gpio, LCD, spi, etc).  Also, since these devices are
+   implemented within the fpga fabric every instance of the device can be
+   synthesised with different options that change the behaviour.
+
+   Each IP-core has a set of parameters which the FPGA designer can use to
+   control how the core is synthesized.  Historically, the EDK tool would
+   extract the device parameters relevant to device drivers and copy them
+   into an 'xparameters.h' in the form of #define symbols.  This tells the
+   device drivers how the IP cores are configured, but it requres the kernel
+   to be recompiled every time the FPGA bitstream is resynthesized.
+
+   The new approach is to export the parameters into the device tree and
+   generate a new device tree each time the FPGA bitstream changes.  The
+   parameters which used to be exported as #defines will now become
+   properties of the device node.  In general, device nodes for IP-cores
+   will take the following form:
+
+	(name)@(base-address) {
+		compatible = "xlnx,(ip-core-name)-(HW_VER)"
+			     [, (list of compatible devices), ...];
+		reg = <(baseaddr) (size)>;
+		interrupt-parent = <&interrupt-controller-phandle>;
+		interrupts = < ... >;
+		xlnx,(parameter1) = "(string-value)";
+		xlnx,(parameter2) = <(int-value)>;
+	};
+
+	(ip-core-name):	the name of the ip block (given after the BEGIN
+			directive in system.mhs).  Should be in lowercase
+			and all underscores '_' converted to dashes '-'.
+	(name):		is derived from the "PARAMETER INSTANCE" value.
+	(parameter#):	C_* parameters from system.mhs.  The C_ prefix is
+			dropped from the parameter name, the name is converted
+			to lowercase and all underscore '_' characters are
+			converted to dashes '-'.
+	(baseaddr):	the C_BASEADDR parameter.
+	(HW_VER):	from the HW_VER parameter.
+	(size):		equals C_HIGHADDR - C_BASEADDR + 1
+
+   Typically, the compatible list will include the exact IP core version
+   followed by an older IP core version which implements the same
+   interface or any other device with the same interface.
+
+   'reg', 'interrupt-parent' and 'interrupts' are all optional properties.
+
+   For example, the following block from system.mhs:
+
+	BEGIN opb_uartlite
+		PARAMETER INSTANCE = opb_uartlite_0
+		PARAMETER HW_VER = 1.00.b
+		PARAMETER C_BAUDRATE = 115200
+		PARAMETER C_DATA_BITS = 8
+		PARAMETER C_ODD_PARITY = 0
+		PARAMETER C_USE_PARITY = 0
+		PARAMETER C_CLK_FREQ = 50000000
+		PARAMETER C_BASEADDR = 0xEC100000
+		PARAMETER C_HIGHADDR = 0xEC10FFFF
+		BUS_INTERFACE SOPB = opb_7
+		PORT OPB_Clk = CLK_50MHz
+		PORT Interrupt = opb_uartlite_0_Interrupt
+		PORT RX = opb_uartlite_0_RX
+		PORT TX = opb_uartlite_0_TX
+		PORT OPB_Rst = sys_bus_reset_0
+	END
+
+   becomes the following device tree node:
+
+	opb-uartlite-0@ec100000 {
+		device_type = "serial";
+		compatible = "xlnx,opb-uartlite-1.00.b";
+		reg = <ec100000 10000>;
+		interrupt-parent = <&opb-intc>;
+		interrupts = <1 0>; // got this from the opb_intc parameters
+		current-speed = <d#115200>;	// standard serial device prop
+		clock-frequency = <d#50000000>;	// standard serial device prop
+		xlnx,data-bits = <8>;
+		xlnx,odd-parity = <0>;
+		xlnx,use-parity = <0>;
+	};
+
+   Some IP cores actually implement 2 or more logical devices.  In this case,
+   the device should still describe the whole IP core with a single node
+   and add a child node for each logical device.  The ranges property can
+   be used to translate from parent IP-core to the registers of each device.
+   (Note: this makes the assumption that both logical devices have the same
+   bus binding.  If this is not true, then separate nodes should be used for
+   each logical device).  The 'cell-index' property can be used to enumerate
+   logical devices within an IP core.  For example, the following is the
+   system.mhs entry for the dual ps2 controller found on the ml403 reference
+   design.
+
+	BEGIN opb_ps2_dual_ref
+		PARAMETER INSTANCE = opb_ps2_dual_ref_0
+		PARAMETER HW_VER = 1.00.a
+		PARAMETER C_BASEADDR = 0xA9000000
+		PARAMETER C_HIGHADDR = 0xA9001FFF
+		BUS_INTERFACE SOPB = opb_v20_0
+		PORT Sys_Intr1 = ps2_1_intr
+		PORT Sys_Intr2 = ps2_2_intr
+		PORT Clkin1 = ps2_clk_rx_1
+		PORT Clkin2 = ps2_clk_rx_2
+		PORT Clkpd1 = ps2_clk_tx_1
+		PORT Clkpd2 = ps2_clk_tx_2
+		PORT Rx1 = ps2_d_rx_1
+		PORT Rx2 = ps2_d_rx_2
+		PORT Txpd1 = ps2_d_tx_1
+		PORT Txpd2 = ps2_d_tx_2
+	END
+
+   It would result in the following device tree nodes:
+
+	opb_ps2_dual_ref_0@a9000000 {
+		ranges = <0 a9000000 2000>;
+		// If this device had extra parameters, then they would
+		// go here.
+		ps2@0 {
+			compatible = "xlnx,opb-ps2-dual-ref-1.00.a";
+			reg = <0 40>;
+			interrupt-parent = <&opb-intc>;
+			interrupts = <3 0>;
+			cell-index = <0>;
+		};
+		ps2@1000 {
+			compatible = "xlnx,opb-ps2-dual-ref-1.00.a";
+			reg = <1000 40>;
+			interrupt-parent = <&opb-intc>;
+			interrupts = <3 0>;
+			cell-index = <0>;
+		};
+	};
+
+   Also, the system.mhs file defines bus attachments from the processor
+   to the devices.  The device tree structure should reflect the bus
+   attachments.  Again an example; this system.mhs fragment:
+
+	BEGIN ppc405_virtex4
+		PARAMETER INSTANCE = ppc405_0
+		PARAMETER HW_VER = 1.01.a
+		BUS_INTERFACE DPLB = plb_v34_0
+		BUS_INTERFACE IPLB = plb_v34_0
+	END
+
+	BEGIN opb_intc
+		PARAMETER INSTANCE = opb_intc_0
+		PARAMETER HW_VER = 1.00.c
+		PARAMETER C_BASEADDR = 0xD1000FC0
+		PARAMETER C_HIGHADDR = 0xD1000FDF
+		BUS_INTERFACE SOPB = opb_v20_0
+	END
+
+	BEGIN opb_uart16550
+		PARAMETER INSTANCE = opb_uart16550_0
+		PARAMETER HW_VER = 1.00.d
+		PARAMETER C_BASEADDR = 0xa0000000
+		PARAMETER C_HIGHADDR = 0xa0001FFF
+		BUS_INTERFACE SOPB = opb_v20_0
+	END
+
+	BEGIN plb_v34
+		PARAMETER INSTANCE = plb_v34_0
+		PARAMETER HW_VER = 1.02.a
+	END
+
+	BEGIN plb_bram_if_cntlr
+		PARAMETER INSTANCE = plb_bram_if_cntlr_0
+		PARAMETER HW_VER = 1.00.b
+		PARAMETER C_BASEADDR = 0xFFFF0000
+		PARAMETER C_HIGHADDR = 0xFFFFFFFF
+		BUS_INTERFACE SPLB = plb_v34_0
+	END
+
+	BEGIN plb2opb_bridge
+		PARAMETER INSTANCE = plb2opb_bridge_0
+		PARAMETER HW_VER = 1.01.a
+		PARAMETER C_RNG0_BASEADDR = 0x20000000
+		PARAMETER C_RNG0_HIGHADDR = 0x3FFFFFFF
+		PARAMETER C_RNG1_BASEADDR = 0x60000000
+		PARAMETER C_RNG1_HIGHADDR = 0x7FFFFFFF
+		PARAMETER C_RNG2_BASEADDR = 0x80000000
+		PARAMETER C_RNG2_HIGHADDR = 0xBFFFFFFF
+		PARAMETER C_RNG3_BASEADDR = 0xC0000000
+		PARAMETER C_RNG3_HIGHADDR = 0xDFFFFFFF
+		BUS_INTERFACE SPLB = plb_v34_0
+		BUS_INTERFACE MOPB = opb_v20_0
+	END
+
+   Gives this device tree (some properties removed for clarity):
+
+	plb-v34-0 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		device_type = "ibm,plb";
+		ranges; // 1:1 translation
+
+		plb-bram-if-cntrl-0@ffff0000 {
+			reg = <ffff0000 10000>;
+		}
+
+		opb-v20-0 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <20000000 20000000 20000000
+				  60000000 60000000 20000000
+				  80000000 80000000 40000000
+				  c0000000 c0000000 20000000>;
+
+			opb-uart16550-0@a0000000 {
+				reg = <a00000000 2000>;
+			};
+
+			opb-intc-0@d1000fc0 {
+				reg = <d1000fc0 20>;
+			};
+		};
+	};
+
+   That covers the general approach to binding xilinx IP cores into the
+   device tree.  The following are bindings for specific devices:
+
+      i) Xilinx ML300 Framebuffer
+
+      Simple framebuffer device from the ML300 reference design (also on the
+      ML403 reference design as well as others).
+
+      Optional properties:
+       - resolution = <xres yres> : pixel resolution of framebuffer.  Some
+                                    implementations use a different resolution.
+                                    Default is <d#640 d#480>
+       - virt-resolution = <xvirt yvirt> : Size of framebuffer in memory.
+                                           Default is <d#1024 d#480>.
+       - rotate-display (empty) : rotate display 180 degrees.
+
+      ii) Xilinx SystemACE
+
+      The Xilinx SystemACE device is used to program FPGAs from an FPGA
+      bitstream stored on a CF card.  It can also be used as a generic CF
+      interface device.
+
+      Optional properties:
+       - 8-bit (empty) : Set this property for SystemACE in 8 bit mode
+
+      iii) Xilinx EMAC and Xilinx TEMAC
+
+      Xilinx Ethernet devices.  In addition to general xilinx properties
+      listed above, nodes for these devices should include a phy-handle
+      property, and may include other common network device properties
+      like local-mac-address.
+      
+      iv) Xilinx Uartlite
+
+      Xilinx uartlite devices are simple fixed speed serial ports.
+
+      Requred properties:
+       - current-speed : Baud rate of uartlite
+
    More devices will be defined as this spec matures.
 
 VII - Specifying interrupt information for devices

Documentation/rtc.txt

@@ -180,9 +180,10 @@ driver returns ENOIOCTLCMD.  Some common examples:
     *	RTC_IRQP_SET, RTC_IRQP_READ: the irq_set_freq function will be called
 	to set the frequency while the framework will handle the read for you
 	since the frequency is stored in the irq_freq member of the rtc_device
-	structure.  Also make sure you set the max_user_freq member in your
-	initialization routines so the framework can sanity check the user
-	input for you.
+	structure.  Your driver needs to initialize the irq_freq member during
+	init.  Make sure you check the requested frequency is in range of your
+	hardware in the irq_set_freq function.  If you cannot actually change
+	the frequency, just return -ENOTTY.
 
 If all else fails, check out the rtc-test.c driver!
 

Documentation/sysctl/vm.txt

@@ -34,6 +34,8 @@ Currently, these files are in /proc/sys/vm:
 - oom_kill_allocating_task
 - mmap_min_address
 - numa_zonelist_order
+- nr_hugepages
+- nr_overcommit_hugepages
 
 ==============================================================
 
@@ -305,3 +307,20 @@ will select "node" order in following case.
 
 Otherwise, "zone" order will be selected. Default order is recommended unless
 this is causing problems for your system/application.
+
+==============================================================
+
+nr_hugepages
+
+Change the minimum size of the hugepage pool.
+
+See Documentation/vm/hugetlbpage.txt
+
+==============================================================
+
+nr_overcommit_hugepages
+
+Change the maximum size of the hugepage pool. The maximum is
+nr_hugepages + nr_overcommit_hugepages.
+
+See Documentation/vm/hugetlbpage.txt

Documentation/thinkpad-acpi.txt

@@ -1,7 +1,7 @@
 		     ThinkPad ACPI Extras Driver
 
-                            Version 0.16
-                          August 2nd, 2007
+                            Version 0.17
+                         October 04th, 2007
 
                Borislav Deianov <borislav@users.sf.net>
              Henrique de Moraes Holschuh <hmh@hmh.eng.br>
@@ -923,19 +923,34 @@ sysfs backlight device "thinkpad_screen"
 This feature allows software control of the LCD brightness on ThinkPad
 models which don't have a hardware brightness slider.
 
-It has some limitations: the LCD backlight cannot be actually turned on or off
-by this interface, and in many ThinkPad models, the "dim while on battery"
-functionality will be enabled by the BIOS when this interface is used, and
-cannot be controlled.
+It has some limitations: the LCD backlight cannot be actually turned on or
+off by this interface, and in many ThinkPad models, the "dim while on
+battery" functionality will be enabled by the BIOS when this interface is
+used, and cannot be controlled.
 
-The backlight control has eight levels, ranging from 0 to 7.  Some of the
-levels may not be distinct.
+On IBM (and some of the earlier Lenovo) ThinkPads, the backlight control
+has eight brightness levels, ranging from 0 to 7.  Some of the levels
+may not be distinct.  Later Lenovo models that implement the ACPI
+display backlight brightness control methods have 16 levels, ranging
+from 0 to 15.
 
-There are two interfaces to the firmware for brightness control, EC and CMOS.
-To select which one should be used, use the brightness_mode module parameter:
-brightness_mode=1 selects EC mode, brightness_mode=2 selects CMOS mode,
-brightness_mode=3 selects both EC and CMOS.  The driver tries to autodetect
-which interface to use.
+There are two interfaces to the firmware for direct brightness control,
+EC and CMOS.  To select which one should be used, use the
+brightness_mode module parameter: brightness_mode=1 selects EC mode,
+brightness_mode=2 selects CMOS mode, brightness_mode=3 selects both EC
+and CMOS.  The driver tries to autodetect which interface to use.
+
+When display backlight brightness controls are available through the
+standard ACPI interface, it is best to use it instead of this direct
+ThinkPad-specific interface.  The driver will disable its native
+backlight brightness control interface if it detects that the standard
+ACPI interface is available in the ThinkPad.
+
+The brightness_enable module parameter can be used to control whether
+the LCD brightness control feature will be enabled when available.
+brightness_enable=0 forces it to be disabled.  brightness_enable=1
+forces it to be enabled when available, even if the standard ACPI
+interface is also available.
 
 Procfs notes:
 
@@ -947,11 +962,11 @@ Procfs notes:
 
 Sysfs notes:
 
-The interface is implemented through the backlight sysfs class, which is poorly
-documented at this time.
+The interface is implemented through the backlight sysfs class, which is
+poorly documented at this time.
 
-Locate the thinkpad_screen device under /sys/class/backlight, and inside it
-there will be the following attributes:
+Locate the thinkpad_screen device under /sys/class/backlight, and inside
+it there will be the following attributes:
 
 	max_brightness:
 		Reads the maximum brightness the hardware can be set to.
@@ -961,17 +976,19 @@ there will be the following attributes:
 		Reads what brightness the screen is set to at this instant.
 
 	brightness:
-		Writes request the driver to change brightness to the given
-		value.  Reads will tell you what brightness the driver is trying
-		to set the display to when "power" is set to zero and the display
-		has not been dimmed by a kernel power management event.
+		Writes request the driver to change brightness to the
+		given value.  Reads will tell you what brightness the
+		driver is trying to set the display to when "power" is set
+		to zero and the display has not been dimmed by a kernel
+		power management event.
 
 	power:
-		power management mode, where 0 is "display on", and 1 to 3 will
-		dim the display backlight to brightness level 0 because
-		thinkpad-acpi cannot really turn the backlight off.  Kernel
-		power management events can temporarily increase the current
-		power management level, i.e. they can dim the display.
+		power management mode, where 0 is "display on", and 1 to 3
+		will dim the display backlight to brightness level 0
+		because thinkpad-acpi cannot really turn the backlight
+		off.  Kernel power management events can temporarily
+		increase the current power management level, i.e. they can
+		dim the display.
 
 
 Volume control -- /proc/acpi/ibm/volume

Documentation/tipar.txt

@@ -1,93 +0,0 @@
-
-		Parallel link cable for Texas Instruments handhelds
-		===================================================
-
-
-Author: Romain Lievin
-Homepage: http://lpg.ticalc.org/prj_tidev/index.html
-
-
-INTRODUCTION:
-
-This is a driver for the very common home-made parallel link cable, a cable 
-designed for connecting TI8x/9x graphing calculators (handhelds) to a computer
-or workstation (Alpha, Sparc). Given that driver is built on parport, the 
-parallel port abstraction layer, this driver is architecture-independent.
-
-It can also be used with another device plugged on the same port (such as a
-ZIP drive). I have a 100MB ZIP and both of them work fine!
-
-If you need more information, please visit the 'TI drivers' homepage at the URL
-above.
-
-WHAT YOU NEED:
-
-A TI calculator and a program capable of communicating with your calculator.
-
-TiLP will work for sure (since I am its developer!). yal92 may be able to use
-it by changing tidev for tipar (may require some hacking...).
-
-HOW TO USE IT:
-
-You must have first compiled parport support (CONFIG_PARPORT_DEV): either 
-compiled in your kernel, either as a module. 
-
-Next, (as root):
-
-       modprobe parport
-       modprobe tipar
-
-If it is not already there (it usually is), create the device:
-
-       mknod /dev/tipar0 c 115 0
-       mknod /dev/tipar1 c 115 1
-       mknod /dev/tipar2 c 115 2
-
-You will have to set permissions on this device to allow you to read/write
-from it:
-
-       chmod 666 /dev/tipar[0..2]
-       
-Now you are ready to run a linking program such as TiLP. Be sure to configure 
-it properly (RTFM).
-       
-MODULE PARAMETERS:
-
-  You can set these with:  modprobe tipar NAME=VALUE
-  There is currently no way to set these on a per-cable basis.
-
-  NAME: timeout
-  TYPE: integer
-  DEFAULT: 15
-  DESC: Timeout value in tenth of seconds. If no data is available once this 
-	time has expired then the driver will return with a timeout error.
-
-  NAME: delay
-  TYPE: integer
-  DEFAULT: 10
-  DESC: Inter-bit delay in micro-seconds. A lower value gives an higher data
-	rate but makes transmission less reliable.
-
-These parameters can be changed at run time by any program via ioctl(2) calls 
-as listed in ./include/linux/ticable.h.
-
-Rather than write 50 pages describing the ioctl() and so on, it is
-perhaps more useful you look at ticables library (dev_link.c) that demonstrates
-how to use them, and demonstrates the features of the driver. This is
-probably a lot more useful to people interested in writing applications
-that will be using this driver.
-
-QUIRKS/BUGS:
-
-None.
-
-HOW TO CONTACT US:
-
-You can email me at roms@lpg.ticalc.org. Please prefix the subject line
-with "TIPAR: " so that I am certain to notice your message.
-You can also mail JB at jb@jblache.org. He packaged these drivers for Debian.
-
-CREDITS:
-
-The code is based on tidev.c & parport.c.
-The driver has been developed independently of Texas Instruments.

Documentation/tty.txt

@@ -132,6 +132,14 @@ set_termios()		Notify the tty driver that the device's termios
 			tty->termios. Previous settings should be passed in
 			the "old" argument.
 
+			The API is defined such that the driver should return
+			the actual modes selected. This means that the
+			driver function is responsible for modifying any
+			bits in the request it cannot fulfill to indicate
+			the actual modes being used. A device with no
+			hardware capability for change (eg a USB dongle or
+			virtual port) can provide NULL for this method.
+
 throttle()		Notify the tty driver that input buffers for the
 			line discipline are close to full, and it should
 			somehow signal that no more characters should be

Documentation/usb/power-management.txt

@@ -278,6 +278,14 @@ optional.  The methods' jobs are quite simple:
 	(although the interfaces will be in the same altsettings as
 	before the suspend).
 
+If the device is disconnected or powered down while it is suspended,
+the disconnect method will be called instead of the resume or
+reset_resume method.  This is also quite likely to happen when
+waking up from hibernation, as many systems do not maintain suspend
+current to the USB host controllers during hibernation.  (It's
+possible to work around the hibernation-forces-disconnect problem by
+using the USB Persist facility.)
+
 The reset_resume method is used by the USB Persist facility (see
 Documentation/usb/persist.txt) and it can also be used under certain
 circumstances when CONFIG_USB_PERSIST is not enabled.  Currently, if a

Documentation/vm/hugetlbpage.txt

@@ -30,9 +30,10 @@ alignment and size of the arguments to the above system calls.
 The output of "cat /proc/meminfo" will have lines like:
 
 .....
-HugePages_Total: xxx
-HugePages_Free:  yyy
-HugePages_Rsvd:  www
+HugePages_Total: vvv
+HugePages_Free:  www
+HugePages_Rsvd:  xxx
+HugePages_Surp:  yyy
 Hugepagesize:    zzz kB
 
 where:
@@ -42,6 +43,10 @@ allocated.
 HugePages_Rsvd is short for "reserved," and is the number of hugepages
 for which a commitment to allocate from the pool has been made, but no
 allocation has yet been made. It's vaguely analogous to overcommit.
+HugePages_Surp is short for "surplus," and is the number of hugepages in
+the pool above the value in /proc/sys/vm/nr_hugepages. The maximum
+number of surplus hugepages is controlled by
+/proc/sys/vm/nr_overcommit_hugepages.
 
 /proc/filesystems should also show a filesystem of type "hugetlbfs" configured
 in the kernel.
@@ -71,7 +76,25 @@ or failure of allocation depends on the amount of physically contiguous
 memory that is preset in system at this time.  System administrators may want
 to put this command in one of the local rc init files.  This will enable the
 kernel to request huge pages early in the boot process (when the possibility
-of getting physical contiguous pages is still very high).
+of getting physical contiguous pages is still very high). In either
+case, adminstrators will want to verify the number of hugepages actually
+allocated by checking the sysctl or meminfo.
+
+/proc/sys/vm/nr_overcommit_hugepages indicates how large the pool of
+hugepages can grow, if more hugepages than /proc/sys/vm/nr_hugepages are
+requested by applications. echo'ing any non-zero value into this file
+indicates that the hugetlb subsystem is allowed to try to obtain
+hugepages from the buddy allocator, if the normal pool is exhausted. As
+these surplus hugepages go out of use, they are freed back to the buddy
+allocator.
+
+Caveat: Shrinking the pool via nr_hugepages while a surplus is in effect
+will allow the number of surplus huge pages to exceed the overcommit
+value, as the pool hugepages (which must have been in use for a surplus
+hugepages to be allocated) will become surplus hugepages.  As long as
+this condition holds, however, no more surplus huge pages will be
+allowed on the system until one of the two sysctls are increased
+sufficiently, or the surplus huge pages go out of use and are freed.
 
 If the user applications are going to request hugepages using mmap system
 call, then it is required that system administrator mount a file system of
@@ -94,8 +117,8 @@ provided on command line then no limits are set.  For size and nr_inodes
 options, you can use [G|g]/[M|m]/[K|k] to represent giga/mega/kilo. For
 example, size=2K has the same meaning as size=2048.
 
-read and write system calls are not supported on files that reside on hugetlb
-file systems.
+While read system calls are supported on files that reside on hugetlb
+file systems, write system calls are not.
 
 Regular chown, chgrp, and chmod commands (with right permissions) could be
 used to change the file attributes on hugetlbfs.

Documentation/watchdog/watchdog-api.txt

@@ -42,23 +42,27 @@ like this source file:  see Documentation/watchdog/src/watchdog-simple.c
 A more advanced driver could for example check that a HTTP server is
 still responding before doing the write call to ping the watchdog.
 
-When the device is closed, the watchdog is disabled.  This is not
-always such a good idea, since if there is a bug in the watchdog
-daemon and it crashes the system will not reboot.  Because of this,
-some of the drivers support the configuration option "Disable watchdog
-shutdown on close", CONFIG_WATCHDOG_NOWAYOUT.  If it is set to Y when
-compiling the kernel, there is no way of disabling the watchdog once
-it has been started.  So, if the watchdog daemon crashes, the system
-will reboot after the timeout has passed. Watchdog devices also usually
-support the nowayout module parameter so that this option can be controlled
-at runtime.
+When the device is closed, the watchdog is disabled, unless the "Magic
+Close" feature is supported (see below).  This is not always such a
+good idea, since if there is a bug in the watchdog daemon and it
+crashes the system will not reboot.  Because of this, some of the
+drivers support the configuration option "Disable watchdog shutdown on
+close", CONFIG_WATCHDOG_NOWAYOUT.  If it is set to Y when compiling
+the kernel, there is no way of disabling the watchdog once it has been
+started.  So, if the watchdog daemon crashes, the system will reboot
+after the timeout has passed. Watchdog devices also usually support
+the nowayout module parameter so that this option can be controlled at
+runtime.
 
-Drivers will not disable the watchdog, unless a specific magic character 'V'
-has been sent /dev/watchdog just before closing the file.  If the userspace
-daemon closes the file without sending this special character, the driver
-will assume that the daemon (and userspace in general) died, and will stop
-pinging the watchdog without disabling it first.  This will then cause a
-reboot if the watchdog is not re-opened in sufficient time.
+Magic Close feature:
+
+If a driver supports "Magic Close", the driver will not disable the
+watchdog unless a specific magic character 'V' has been sent to
+/dev/watchdog just before closing the file.  If the userspace daemon
+closes the file without sending this special character, the driver
+will assume that the daemon (and userspace in general) died, and will
+stop pinging the watchdog without disabling it first.  This will then
+cause a reboot if the watchdog is not re-opened in sufficient time.
 
 The ioctl API:
 

Documentation/x86_64/uefi.txt

@@ -0,0 +1,29 @@
+General note on [U]EFI x86_64 support
+-------------------------------------
+
+The nomenclature EFI and UEFI are used interchangeably in this document.
+
+Although the tools below are _not_ needed for building the kernel,
+the needed bootloader support and associated tools for x86_64 platforms
+with EFI firmware and specifications are listed below.
+
+1. UEFI specification:  http://www.uefi.org
+
+2. Booting Linux kernel on UEFI x86_64 platform requires bootloader
+   support. Elilo with x86_64 support can be used.
+
+3. x86_64 platform with EFI/UEFI firmware.
+
+Mechanics:
+---------
+- Build the kernel with the following configuration.
+	CONFIG_FB_EFI=y
+	CONFIG_FRAMEBUFFER_CONSOLE=y
+- Create a VFAT partition on the disk
+- Copy the following to the VFAT partition:
+	elilo bootloader with x86_64 support, elilo configuration file,
+	kernel image built in first step and corresponding
+	initrd. Instructions on building elilo	and its dependencies
+	can be found in the elilo sourceforge project.
+- Boot to EFI shell and invoke elilo choosing the kernel image built
+  in first step.

MAINTAINERS

@@ -88,7 +88,6 @@ S: Status, one of the following:
 P:	Mike Phillips
 M:	mikep@linuxtr.net
 L:	netdev@vger.kernel.org
-L:	linux-tr@linuxtr.net
 W:	http://www.linuxtr.net
 S:	Maintained
 
@@ -167,7 +166,6 @@ S:	Maintained
 
 A2232 SERIAL BOARD DRIVER
 P:	Enver Haase
-M:	ehaase@inf.fu-berlin.de
 M:	A2232@gmx.net
 L:	linux-m68k@lists.linux-m68k.org
 S:	Maintained
@@ -323,8 +321,7 @@ S:	Maintained
 ALCATEL SPEEDTOUCH USB DRIVER
 P:	Duncan Sands
 M:	duncan.sands@free.fr
-L:	linux-usb-users@lists.sourceforge.net
-L:	linux-usb-devel@lists.sourceforge.net
+L:	linux-usb@vger.kernel.org
 W:	http://www.linux-usb.org/SpeedTouch/
 S:	Maintained
 
@@ -668,12 +665,18 @@ S:	Maintained
 
 ATMEL AT91 MCI DRIVER
 P:	Nicolas Ferre
-M:	nicolas.ferre@rfo.atmel.com
+M:	nicolas.ferre@atmel.com
 L:	linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only)
 W:	http://www.atmel.com/products/AT91/
 W:	http://www.at91.com/
 S:	Maintained
 
+ATMEL LCDFB DRIVER
+P:	Nicolas Ferre
+M:	nicolas.ferre@atmel.com
+L:	linux-fbdev-devel@lists.sourceforge.net (subscribers-only)
+S:	Maintained
+
 ATMEL MACB ETHERNET DRIVER
 P:	Haavard Skinnemoen
 M:	hskinnemoen@atmel.com
@@ -787,23 +790,25 @@ B43 WIRELESS DRIVER
 P:	Michael Buesch
 M:	mb@bu3sch.de
 P:	Stefano Brivio
-M:	st3@riseup.net
+M:	stefano.brivio@polimi.it
 L:	linux-wireless@vger.kernel.org
-W:	http://bcm43xx.berlios.de/
+W:	http://linuxwireless.org/en/users/Drivers/b43
 S:	Maintained
 
 B43LEGACY WIRELESS DRIVER
 P:	Larry Finger
 M:	Larry.Finger@lwfinger.net
+P:	Stefano Brivio
+M:	stefano.brivio@polimi.it
 L:	linux-wireless@vger.kernel.org
-W:	http://bcm43xx.berlios.de/
+W:	http://linuxwireless.org/en/users/Drivers/b43
 S:	Maintained
 
 BCM43XX WIRELESS DRIVER (SOFTMAC BASED VERSION)
 P:	Larry Finger
 M:	Larry.Finger@lwfinger.net
 P:	Stefano Brivio
-M:	st3@riseup.net
+M:	stefano.brivio@polimi.it
 L:	linux-wireless@vger.kernel.org
 W:	http://bcm43xx.berlios.de/
 S:	Maintained
@@ -1041,7 +1046,7 @@ S:	Maintained
 CIRRUS LOGIC EP93XX OHCI USB HOST DRIVER
 P:	Lennert Buytenhek
 M:	kernel@wantstofly.org
-L:	linux-usb-devel@lists.sourceforge.net
+L:	linux-usb@vger.kernel.org
 S:	Maintained
 
 CIRRUS LOGIC CS4280/CS461x SOUNDDRIVER
@@ -1550,7 +1555,7 @@ S:	Maintained
 FREESCALE HIGHSPEED USB DEVICE DRIVER
 P:	Li Yang
 M:	leoli@freescale.com
-L:	linux-usb-devel@lists.sourceforge.net
+L:	linux-usb@vger.kernel.org
 L:	linuxppc-dev@ozlabs.org
 S:	Maintained
 
@@ -1680,8 +1685,7 @@ S:	Maintained
 HARMONY SOUND DRIVER
 P:	Kyle McMartin
 M:	kyle@parisc-linux.org
-W:	http://www.parisc-linux.org/~kyle/harmony/
-L:	parisc-linux@lists.parisc-linux.org
+L:	linux-parisc@vger.kernel.org
 S:	Maintained
 
 HAYES ESP SERIAL DRIVER
@@ -1872,8 +1876,10 @@ T:	quilt kernel.org/pub/linux/kernel/people/bart/pata-2.6/
 S:	Maintained
 
 IDE/ATAPI CDROM DRIVER
+P:	Borislav Petkov
+M:	bbpetkov@yahoo.de
 L:	linux-ide@vger.kernel.org
-S:	Unmaintained
+S:	Maintained
 
 IDE/ATAPI FLOPPY DRIVERS
 P:	Paul Bristow
@@ -1912,16 +1918,14 @@ L:	linux1394-devel@lists.sourceforge.net
 S:	Maintained
 
 IMS TWINTURBO FRAMEBUFFER DRIVER
-P:	Paul Mundt
-M:	lethal@chaoticdreams.org
 L:	linux-fbdev-devel@lists.sourceforge.net (subscribers-only)
-S:	Maintained
+S:	Orphan
 
 INFINIBAND SUBSYSTEM
 P:	Roland Dreier
 M:	rolandd@cisco.com
 P:	Sean Hefty
-M:	mshefty@ichips.intel.com
+M:	sean.hefty@intel.com
 P:	Hal Rosenstock
 M:	hal.rosenstock@gmail.com 
 L:	general@lists.openfabrics.org
@@ -1986,29 +1990,27 @@ L:	netdev@vger.kernel.org
 S:	Maintained
 
 INTEL PRO/100 ETHERNET SUPPORT
-P:	John Ronciak
-M:	john.ronciak@intel.com
+P:	Auke Kok
+M:	auke-jan.h.kok@intel.com
 P:	Jesse Brandeburg
 M:	jesse.brandeburg@intel.com
 P:	Jeff Kirsher
 M:	jeffrey.t.kirsher@intel.com
-P:	Auke Kok
-M:	auke-jan.h.kok@intel.com
+P:	John Ronciak
+M:	john.ronciak@intel.com
 L:	e1000-devel@lists.sourceforge.net
 W:	http://sourceforge.net/projects/e1000/
 S:	Supported
 
 INTEL PRO/1000 GIGABIT ETHERNET SUPPORT
-P:	Jeb Cramer
-M:	cramerj@intel.com
-P:	John Ronciak
-M:	john.ronciak@intel.com
+P:	Auke Kok
+M:	auke-jan.h.kok@intel.com
 P:	Jesse Brandeburg
 M:	jesse.brandeburg@intel.com
 P:	Jeff Kirsher
 M:	jeffrey.t.kirsher@intel.com
-P:	Auke Kok
-M:	auke-jan.h.kok@intel.com
+P:	John Ronciak
+M:	john.ronciak@intel.com
 L:	e1000-devel@lists.sourceforge.net
 W:	http://sourceforge.net/projects/e1000/
 S:	Supported
@@ -2033,7 +2035,7 @@ 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://lists.sourceforge.net/mailman/listinfo/ipw2100-devel
 W:	http://ipw2100.sourceforge.net
 S:	Supported
 
@@ -2044,7 +2046,7 @@ 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://lists.sourceforge.net/mailman/listinfo/ipw2100-devel
 W:	http://ipw2200.sourceforge.net
 S:	Supported
 
@@ -2066,7 +2068,7 @@ S:	Maintained
 IOC3 SERIAL DRIVER
 P:	Pat Gefre
 M:	pfg@sgi.com
-L:	linux-kernel@linux-mips.org
+L:	linux-mips@linux-mips.org
 S:	Maintained
 
 IP MASQUERADING:
@@ -2111,6 +2113,14 @@ L:	irda-users@lists.sourceforge.net (subscribers-only)
 W:	http://irda.sourceforge.net/
 S:	Maintained
 
+ISCSI
+P:	Mike Christie
+M:	michaelc@cs.wisc.edu
+L:	open-iscsi@googlegroups.com
+W:	www.open-iscsi.org
+T:	git kernel.org:/pub/scm/linux/kernel/mnc/linux-2.6-iscsi.git
+S:	Maintained
+
 ISAPNP
 P:	Jaroslav Kysela
 M:	perex@perex.cz
@@ -2166,7 +2176,7 @@ S:	Maintained
 
 KDUMP
 P:	Vivek Goyal
-M:	vgoyal@in.ibm.com
+M:	vgoyal@redhat.com
 P:	Haren Myneni
 M:	hbabu@us.ibm.com
 L:	kexec@lists.infradead.org
@@ -2444,7 +2454,7 @@ M68K ON APPLE MACINTOSH
 P:	Joshua Thompson
 M:	funaho@jurai.org
 W:	http://www.mac.linux-m68k.org/
-L:	linux-mac68k@mac.linux-m68k.org
+L:	linux-m68k@lists.linux-m68k.org
 S:	Maintained
 
 M68K ON HP9000/300
@@ -2485,6 +2495,12 @@ M:	mtk.manpages@gmail.com
 W:	ftp://ftp.kernel.org/pub/linux/docs/manpages
 S:	Maintained
 
+MARVELL LIBERTAS WIRELESS DRIVER
+P:	Dan Williams
+M:	dcbw@redhat.com
+L:	libertas-dev@lists.infradead.org
+S:	Maintained
+
 MARVELL MV643XX ETHERNET DRIVER
 P:	Dale Farnsworth
 M:	dale@farnsworth.org
@@ -2587,17 +2603,10 @@ S:	Maintained
 MSI LAPTOP SUPPORT
 P:	Lennart Poettering
 M:	mzxreary@0pointer.de
-L:	https://tango.0pointer.de/mailman/listinfo/s270-linux
+W:	https://tango.0pointer.de/mailman/listinfo/s270-linux
 W:	http://0pointer.de/lennart/tchibo.html
 S:	Maintained
 
-MTRR AND SIMILAR SUPPORT [i386]
-P:	Richard Gooch
-M:	rgooch@atnf.csiro.au
-L:	linux-kernel@vger.kernel.org
-W:	http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html
-S:	Maintained
-
 MULTIMEDIA CARD (MMC), SECURE DIGITAL (SD) AND SDIO SUBSYSTEM
 P:	Pierre Ossman
 M:	drzeus-mmc@drzeus.cx
@@ -2736,8 +2745,8 @@ T:	git kernel.org:/pub/scm/linux/kernel/git/linville/wireless-2.6.git
 S:	Maintained
 
 NETXEN (1/10) GbE SUPPORT
-P:	Amit S. Kale
-M:	amitkale@netxen.com
+P:	Dhananjay Phadke
+M:	dhananjay@netxen.com
 L:	netdev@vger.kernel.org
 W:	http://www.netxen.com
 S:	Supported
@@ -2754,8 +2763,10 @@ S:	Maintained
 
 NFS CLIENT
 P:	Trond Myklebust
-M:	trond.myklebust@fys.uio.no
-L:	linux-kernel@vger.kernel.org
+M:	Trond.Myklebust@netapp.com
+L:	linux-nfs@vger.kernel.org
+W:	http://client.linux-nfs.org
+T:	git git://git.linux-nfs.org/pub/linux/nfs-2.6.git
 S:	Maintained
 
 NI5010 NETWORK DRIVER
@@ -2816,7 +2827,6 @@ M:	p2@ace.ulyssis.student.kuleuven.ac.be
 P:	Mike Phillips
 M:	mikep@linuxtr.net
 L:	netdev@vger.kernel.org
-L:	linux-tr@linuxtr.net
 W:	http://www.linuxtr.net
 S:	Maintained
 
@@ -2890,16 +2900,15 @@ W:	http://www.torque.net/linux-pp.html
 S:	Maintained
 
 PARISC ARCHITECTURE
+P:	Kyle McMartin
+M:	kyle@parisc-linux.org
 P:	Matthew Wilcox
 M:	matthew@wil.cx
 P:	Grant Grundler
 M:	grundler@parisc-linux.org
-P:	Kyle McMartin
-M:	kyle@parisc-linux.org
-L:	parisc-linux@parisc-linux.org
+L:	linux-parisc@vger.kernel.org
 W:	http://www.parisc-linux.org/
 T:	git kernel.org:/pub/scm/linux/kernel/git/kyle/parisc-2.6.git
-T:	cvs cvs.parisc-linux.org:/var/cvs/linux-2.6
 S:	Maintained
 
 PARAVIRT_OPS INTERFACE
@@ -2955,7 +2964,7 @@ S:	Supported
 PCMCIA SUBSYSTEM
 P:	Linux PCMCIA Team
 L:	linux-pcmcia@lists.infradead.org
-L:	http://lists.infradead.org/mailman/listinfo/linux-pcmcia
+W:	http://lists.infradead.org/mailman/listinfo/linux-pcmcia
 T:	git kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
 S:	Maintained
 
@@ -3452,15 +3461,10 @@ L:	lm-sensors@lm-sensors.org
 S:	Maintained
 
 SOFTMAC LAYER (IEEE 802.11)
-P:	Johannes Berg
-M:	johannes@sipsolutions.net
-P:	Joe Jezak
-M:	josejx@gentoo.org
 P:	Daniel Drake
 M:	dsd@gentoo.org
-W:	http://softmac.sipsolutions.net/
 L:	linux-wireless@vger.kernel.org
-S:	Maintained
+S:	Obsolete
 
 SOFTWARE RAID (Multiple Disks) SUPPORT
 P:	Ingo Molnar
@@ -3613,8 +3617,10 @@ L:	linux-kernel@vger.kernel.org ?
 S:	Supported
 
 SPIDERNET NETWORK DRIVER for CELL
-P:	Linas Vepstas
-M:	linas@austin.ibm.com
+P:	Ishizaki Kou
+M:	kou.ishizaki@toshiba.co.jp
+P:	Jens Osterkamp
+M:	jens@de.ibm.com
 L:	netdev@vger.kernel.org
 S:	Supported
 
@@ -3639,18 +3645,12 @@ M:	laredo@gnu.org
 W:	http://www.stradis.com/
 S:	Maintained
 
-SUPERH (sh)
+SUPERH
 P:	Paul Mundt
 M:	lethal@linux-sh.org
-L:	linuxsh-dev@lists.sourceforge.net (subscribers-only)
-W:	http://www.linux-sh.org
-S:	Maintained
-
-SUPERH64 (sh64)
-P:	Paul Mundt
-M:	lethal@linux-sh.org
-L:	linuxsh-shmedia-dev@lists.sourceforge.net
+L:	linux-sh@vger.kernel.org
 W:	http://www.linux-sh.org
+T:	git kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.git
 S:	Maintained
 
 SUN3/3X
@@ -3715,11 +3715,6 @@ M:	nagar@watson.ibm.com
 L:	linux-kernel@vger.kernel.org
 S:	Maintained
 
-TI PARALLEL LINK CABLE DRIVER
-P:	Romain Lievin
-M:	roms@lpg.ticalc.org
-S:	Maintained
-
 TIPC NETWORK LAYER
 P:	Per Liden
 M:	per.liden@ericsson.com
@@ -3736,7 +3731,7 @@ S:	Maintained
 TLAN NETWORK DRIVER
 P:	Samuel Chessman
 M:	chessman@tux.org
-L:	tlan-devel@lists.sourceforge.net
+L:	tlan-devel@lists.sourceforge.net (subscribers-only)
 W:	http://sourceforge.net/projects/tlan/
 S:	Maintained
 
@@ -3744,7 +3739,6 @@ TOKEN-RING NETWORK DRIVER
 P:	Mike Phillips
 M:	mikep@linuxtr.net
 L:	netdev@vger.kernel.org
-L:	linux-tr@linuxtr.net
 W:	http://www.linuxtr.net
 S:	Maintained
 
@@ -3821,22 +3815,20 @@ S:	Maintained
 USB ACM DRIVER
 P:	Oliver Neukum
 M:	oliver@neukum.name
-L:	linux-usb-users@lists.sourceforge.net
-L:	linux-usb-devel@lists.sourceforge.net
+L:	linux-usb@vger.kernel.org
 S:	Maintained
 
 USB BLOCK DRIVER (UB ub)
 P:	Pete Zaitcev
 M:	zaitcev@redhat.com
 L:	linux-kernel@vger.kernel.org
-L:	linux-usb-devel@lists.sourceforge.net
+L:      linux-usb@vger.kernel.org
 S:	Supported
 
 USB CDC ETHERNET DRIVER
 P:	Greg Kroah-Hartman
 M:	greg@kroah.com
-L:	linux-usb-users@lists.sourceforge.net
-L:	linux-usb-devel@lists.sourceforge.net
+L:      linux-usb@vger.kernel.org
 S:	Maintained
 W:	http://www.kroah.com/linux-usb/
 
@@ -3850,13 +3842,13 @@ S:	Maintained
 USB EHCI DRIVER
 P:	David Brownell
 M:	dbrownell@users.sourceforge.net
-L:	linux-usb-devel@lists.sourceforge.net
+L:      linux-usb@vger.kernel.org
 S:	Odd Fixes
 
 USB ET61X[12]51 DRIVER
 P:	Luca Risolia
 M:	luca.risolia@studio.unibo.it
-L:	linux-usb-devel@lists.sourceforge.net
+L:      linux-usb@vger.kernel.org
 L:	video4linux-list@redhat.com
 W:	http://www.linux-projects.org
 S:	Maintained
@@ -3864,41 +3856,33 @@ S:	Maintained
 USB GADGET/PERIPHERAL SUBSYSTEM
 P:	David Brownell
 M:	dbrownell@users.sourceforge.net
-L:	linux-usb-devel@lists.sourceforge.net
+L:      linux-usb@vger.kernel.org
 W:	http://www.linux-usb.org/gadget
 S:	Maintained
 
 USB HID/HIDBP DRIVERS (USB KEYBOARDS, MICE, REMOTE CONTROLS, ...)
 P:	Jiri Kosina
 M:	jkosina@suse.cz
-L:	linux-usb-devel@lists.sourceforge.net
+L:      linux-usb@vger.kernel.org
 T:	git kernel.org:/pub/scm/linux/kernel/git/jikos/hid.git
 S:	Maintained
 
-USB HUB DRIVER
-P:	Johannes Erdfelt
-M:	johannes@erdfelt.com
-L:	linux-usb-users@lists.sourceforge.net
-L:	linux-usb-devel@lists.sourceforge.net
-S:	Maintained
-
 USB ISP116X DRIVER
 P:	Olav Kongas
 M:	ok@artecdesign.ee
-L:	linux-usb-devel@lists.sourceforge.net
+L:      linux-usb@vger.kernel.org
 S:	Maintained
 
 USB KAWASAKI LSI DRIVER
 P:	Oliver Neukum
 M:	oliver@neukum.name
-L:	linux-usb-users@lists.sourceforge.net
-L:	linux-usb-devel@lists.sourceforge.net
+L:      linux-usb@vger.kernel.org
 S:	Maintained
 
 USB MASS STORAGE DRIVER
 P:	Matthew Dharm
 M:	mdharm-usb@one-eyed-alien.net
-L:	linux-usb-users@lists.sourceforge.net
+L:      linux-usb@vger.kernel.org
 L:	usb-storage@lists.one-eyed-alien.net
 S:	Maintained
 W:	http://www.one-eyed-alien.net/~mdharm/linux-usb/
@@ -3906,28 +3890,26 @@ W:	http://www.one-eyed-alien.net/~mdharm/linux-usb/
 USB OHCI DRIVER
 P:	David Brownell
 M:	dbrownell@users.sourceforge.net
-L:	linux-usb-users@lists.sourceforge.net
-L:	linux-usb-devel@lists.sourceforge.net
+L:      linux-usb@vger.kernel.org
 S:	Odd Fixes
 
 USB OPTION-CARD DRIVER
 P:	Matthias Urlichs
 M:	smurf@smurf.noris.de
-L:	linux-usb-devel@lists.sourceforge.net
+L:      linux-usb@vger.kernel.org
 S:	Maintained
 
 USB OV511 DRIVER
 P:	Mark McClelland
 M:	mmcclell@bigfoot.com
-L:	linux-usb-users@lists.sourceforge.net
-L:	linux-usb-devel@lists.sourceforge.net
+L:      linux-usb@vger.kernel.org
 W:	http://alpha.dyndns.org/ov511/
 S:	Maintained
 
 USB PEGASUS DRIVER
 P:	Petko Manolov
 M:	petkan@users.sourceforge.net
-L:	linux-usb-devel@lists.sourceforge.net
+L:      linux-usb@vger.kernel.org
 L:	netdev@vger.kernel.org
 W:	http://pegasus2.sourceforge.net/
 S:	Maintained
@@ -3935,14 +3917,13 @@ S:	Maintained
 USB PRINTER DRIVER (usblp)
 P:	Pete Zaitcev
 M:	zaitcev@redhat.com
-L:	linux-usb-users@lists.sourceforge.net
-L:	linux-usb-devel@lists.sourceforge.net
+L:      linux-usb@vger.kernel.org
 S:	Supported
 
 USB RTL8150 DRIVER
 P:	Petko Manolov
 M:	petkan@users.sourceforge.net
-L:	linux-usb-devel@lists.sourceforge.net
+L:      linux-usb@vger.kernel.org
 L:	netdev@vger.kernel.org
 W:	http://pegasus2.sourceforge.net/
 S:	Maintained
@@ -3950,8 +3931,7 @@ S:	Maintained
 USB SE401 DRIVER
 P:	Jeroen Vreeken
 M:	pe1rxq@amsat.org
-L:	linux-usb-users@lists.sourceforge.net
-L:	linux-usb-devel@lists.sourceforge.net
+L:      linux-usb@vger.kernel.org
 W:	http://www.chello.nl/~j.vreeken/se401/
 S:	Maintained
 
@@ -3965,72 +3945,59 @@ USB SERIAL DIGI ACCELEPORT DRIVER
 P:	Peter Berger and Al Borchers
 M:	pberger@brimson.com
 M:	alborchers@steinerpoint.com
-L:	linux-usb-users@lists.sourceforge.net
-L:	linux-usb-devel@lists.sourceforge.net
+L:      linux-usb@vger.kernel.org
 S:	Maintained
 
 USB SERIAL DRIVER
 P:	Greg Kroah-Hartman
 M:	gregkh@suse.de
-L:	linux-usb-users@lists.sourceforge.net
-L:	linux-usb-devel@lists.sourceforge.net
+L:      linux-usb@vger.kernel.org
 S:	Supported
 
 USB SERIAL BELKIN F5U103 DRIVER
 P:	William Greathouse
 M:	wgreathouse@smva.com
-L:	linux-usb-users@lists.sourceforge.net
-L:	linux-usb-devel@lists.sourceforge.net
+L:      linux-usb@vger.kernel.org
 S:	Maintained
 
 USB SERIAL CYPRESS M8 DRIVER
 P:	Lonnie Mendez
 M:	dignome@gmail.com
-L:	linux-usb-users@lists.sourceforge.net
-L:	linux-usb-devel@lists.sourceforge.net
+L:      linux-usb@vger.kernel.org
 S:	Maintained
 W:	http://geocities.com/i0xox0i
 W:	http://firstlight.net/cvs
 
-USB SERIAL CYBERJACK PINPAD/E-COM DRIVER
-L:	linux-usb-users@lists.sourceforge.net
-L:	linux-usb-devel@lists.sourceforge.net
-S:	Maintained
-
 USB AUERSWALD DRIVER
 P:	Wolfgang Muees
 M:	wolfgang@iksw-muees.de
-L:	linux-usb-users@lists.sourceforge.net
-L:	linux-usb-devel@lists.sourceforge.net
+L:      linux-usb@vger.kernel.org
 S:	Maintained
 
 USB SERIAL EMPEG EMPEG-CAR MARK I/II DRIVER
 P:	Gary Brubaker
 M:	xavyer@ix.netcom.com
-L:	linux-usb-users@lists.sourceforge.net
-L:	linux-usb-devel@lists.sourceforge.net
+L:      linux-usb@vger.kernel.org
 S:	Maintained
 
 USB SERIAL KEYSPAN DRIVER
 P:	Greg Kroah-Hartman
 M:	greg@kroah.com
-L:	linux-usb-users@lists.sourceforge.net
-L:	linux-usb-devel@lists.sourceforge.net
+L:      linux-usb@vger.kernel.org
 W:	http://www.kroah.com/linux/
 S:	Maintained
 
 USB SERIAL WHITEHEAT DRIVER
 P:	Support Department
 M:	support@connecttech.com
-L:	linux-usb-users@lists.sourceforge.net
-L:	linux-usb-devel@lists.sourceforge.net
+L:      linux-usb@vger.kernel.org
 W:	http://www.connecttech.com
 S:	Supported
 
 USB SN9C1xx DRIVER
 P:	Luca Risolia
 M:	luca.risolia@studio.unibo.it
-L:	linux-usb-devel@lists.sourceforge.net
+L:      linux-usb@vger.kernel.org
 L:	video4linux-list@redhat.com
 W:	http://www.linux-projects.org
 S:	Maintained
@@ -4038,8 +4005,7 @@ S:	Maintained
 USB SUBSYSTEM
 P:	Greg Kroah-Hartman
 M:	gregkh@suse.de
-L:	linux-usb-users@lists.sourceforge.net
-L:	linux-usb-devel@lists.sourceforge.net
+L:      linux-usb@vger.kernel.org
 W:	http://www.linux-usb.org
 T:	quilt kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
 S:	Supported
@@ -4047,8 +4013,7 @@ S:	Supported
 USB UHCI DRIVER
 P:	Alan Stern
 M:	stern@rowland.harvard.edu
-L:	linux-usb-users@lists.sourceforge.net
-L:	linux-usb-devel@lists.sourceforge.net
+L:      linux-usb@vger.kernel.org
 S:	Maintained
 
 USB "USBNET" DRIVER FRAMEWORK
@@ -4061,7 +4026,7 @@ S:	Maintained
 USB W996[87]CF DRIVER
 P:	Luca Risolia
 M:	luca.risolia@studio.unibo.it
-L:	linux-usb-devel@lists.sourceforge.net
+L:      linux-usb@vger.kernel.org
 L:	video4linux-list@redhat.com
 W:	http://www.linux-projects.org
 S:	Maintained
@@ -4069,7 +4034,7 @@ S:	Maintained
 USB ZC0301 DRIVER
 P:	Luca Risolia
 M:	luca.risolia@studio.unibo.it
-L:	linux-usb-devel@lists.sourceforge.net
+L:      linux-usb@vger.kernel.org
 L:	video4linux-list@redhat.com
 W:	http://www.linux-projects.org
 S:	Maintained
@@ -4077,27 +4042,34 @@ S:	Maintained
 USB ZD1201 DRIVER
 P:	Jeroen Vreeken
 M:	pe1rxq@amsat.org
-L:	linux-usb-users@lists.sourceforge.net
-L:	linux-usb-devel@lists.sourceforge.net
+L:      linux-usb@vger.kernel.org
 W:	http://linux-lc100020.sourceforge.net
 S:	Maintained
 
 USB ZR364XX DRIVER
 P:	Antoine Jacquet
 M:	royale@zerezo.com
-L:	linux-usb-devel@lists.sourceforge.net
+L:      linux-usb@vger.kernel.org
 L:	video4linux-list@redhat.com
 W:	http://royale.zerezo.com/zr364xx/
 S:	Maintained
 
 USER-MODE LINUX
 P:	Jeff Dike
-M:	jdike@karaya.com
+M:	jdike@addtoit.com
 L:	user-mode-linux-devel@lists.sourceforge.net
 L:	user-mode-linux-user@lists.sourceforge.net
 W:	http://user-mode-linux.sourceforge.net
 S:	Maintained
 
+USERSPACE I/O (UIO)
+P:	Hans J. Koch
+M:	hjk@linutronix.de
+P:	Greg Kroah-Hartman
+M:	gregkh@suse.de
+L:	linux-kernel@vger.kernel.org
+S:	Maintained
+
 FAT/VFAT/MSDOS FILESYSTEM:
 P:	OGAWA Hirofumi
 M:	hirofumi@mail.parknet.co.jp
@@ -4323,13 +4295,6 @@ L:	mjpeg-users@lists.sourceforge.net
 W:	http://mjpeg.sourceforge.net/driver-zoran/
 S:	Maintained
 
-ZR36120 VIDEO FOR LINUX DRIVER
-P:	Pauline Middelink
-M:	middelin@polyware.nl
-W:	http://www.polyware.nl/~middelin/En/hobbies.html
-W:	http://www.polyware.nl/~middelin/hobbies.html
-S:	Maintained
-
 ZS DECSTATION Z85C30 SERIAL DRIVER
 P:	Maciej W. Rozycki
 M:	macro@linux-mips.org

Makefile

@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 6
 SUBLEVEL = 24
-EXTRAVERSION = -rc2
+EXTRAVERSION =
 NAME = Arr Matey! A Hairy Bilge Rat!
 
 # *DOCUMENTATION*
@@ -12,7 +12,7 @@ NAME = Arr Matey! A Hairy Bilge Rat!
 
 # Do not:
 # o  use make's built-in rules and variables
-#    (this increases performance and avoid hard-to-debug behavour);
+#    (this increases performance and avoids hard-to-debug behaviour);
 # o  print "Entering directory ...";
 MAKEFLAGS += -rR --no-print-directory
 
@@ -108,6 +108,9 @@ endif
 PHONY := _all
 _all:
 
+# Cancel implicit rules on top Makefile
+$(CURDIR)/Makefile Makefile: ;
+
 ifneq ($(KBUILD_OUTPUT),)
 # Invoke a second make in the output directory, passing relevant variables
 # check that the output directory actually exists
@@ -115,13 +118,10 @@ saved-output := $(KBUILD_OUTPUT)
 KBUILD_OUTPUT := $(shell cd $(KBUILD_OUTPUT) && /bin/pwd)
 $(if $(KBUILD_OUTPUT),, \
      $(error output directory "$(saved-output)" does not exist))
-# Check that OUTPUT directory is not the same as where we have kernel src
-$(if $(filter-out $(KBUILD_OUTPUT),$(shell /bin/pwd)),, \
-     $(error Output directory (O=...) specifies kernel src dir))
 
 PHONY += $(MAKECMDGOALS) sub-make
 
-$(filter-out _all sub-make,$(MAKECMDGOALS)) _all: sub-make
+$(filter-out _all sub-make $(CURDIR)/Makefile, $(MAKECMDGOALS)) _all: sub-make
 	$(Q)@:
 
 sub-make: FORCE
@@ -197,8 +197,13 @@ CROSS_COMPILE	?=
 UTS_MACHINE 	:= $(ARCH)
 SRCARCH 	:= $(ARCH)
 
-# for i386 and x86_64 we use SRCARCH equal to x86
-SRCARCH := $(if $(filter x86_64 i386,$(SRCARCH)),x86,$(SRCARCH))
+# Additional ARCH settings for x86
+ifeq ($(ARCH),i386)
+        SRCARCH := x86
+endif
+ifeq ($(ARCH),x86_64)
+        SRCARCH := x86
+endif
 
 KCONFIG_CONFIG	?= .config
 
@@ -286,7 +291,8 @@ export quiet Q KBUILD_VERBOSE
 # Look for make include files relative to root of kernel src
 MAKEFLAGS += --include-dir=$(srctree)
 
-# We need some generic definitions.
+# We need some generic definitions (do not try to remake the file).
+$(srctree)/scripts/Kbuild.include: ;
 include $(srctree)/scripts/Kbuild.include
 
 # Make variables (CC, etc...)
@@ -1323,16 +1329,11 @@ else
 ALLINCLUDE_ARCHS := $(SRCARCH)
 endif
 else
-#Allow user to specify only ALLSOURCE_PATHS on the command line, keeping existing behavour.
+#Allow user to specify only ALLSOURCE_PATHS on the command line, keeping existing behaviour.
 ALLINCLUDE_ARCHS := $(ALLSOURCE_ARCHS)
 endif
 
-# Take care of arch/x86
-ifeq ($(ARCH), $(SRCARCH))
-ALLSOURCE_ARCHS := $(ARCH)
-else
-ALLSOURCE_ARCHS := $(ARCH) $(SRCARCH)
-endif
+ALLSOURCE_ARCHS := $(SRCARCH)
 
 define find-sources
         ( for arch in $(ALLSOURCE_ARCHS) ; do \
@@ -1560,9 +1561,6 @@ endif	# skip-makefile
 PHONY += FORCE
 FORCE:
 
-# Cancel implicit rules on top Makefile, `-rR' will apply to sub-makes.
-Makefile: ;
-
 # Declare the contents of the .PHONY variable as phony.  We keep that
 # information in a variable se we can use it in if_changed and friends.
 .PHONY: $(PHONY)

arch/.gitignore

@@ -0,0 +1,2 @@
+i386
+x86_64

arch/alpha/Makefile

@@ -14,13 +14,13 @@ LDFLAGS_vmlinux	:= -static -N #-relax
 CHECKFLAGS	+= -D__alpha__ -m64
 cflags-y	:= -pipe -mno-fp-regs -ffixed-8 -msmall-data
 
-cpuflags-$(CONFIG_ALPHA_EV67)		:= -mcpu=ev67
-cpuflags-$(CONFIG_ALPHA_EV6)		:= -mcpu=ev6
+cpuflags-$(CONFIG_ALPHA_EV4)		:= -mcpu=ev4
+cpuflags-$(CONFIG_ALPHA_EV5)		:= -mcpu=ev5
+cpuflags-$(CONFIG_ALPHA_EV56)		:= -mcpu=ev56
 cpuflags-$(CONFIG_ALPHA_POLARIS)	:= -mcpu=pca56
 cpuflags-$(CONFIG_ALPHA_SX164)		:= -mcpu=pca56
-cpuflags-$(CONFIG_ALPHA_EV56)		:= -mcpu=ev56
-cpuflags-$(CONFIG_ALPHA_EV5)		:= -mcpu=ev5
-cpuflags-$(CONFIG_ALPHA_EV4)		:= -mcpu=ev4
+cpuflags-$(CONFIG_ALPHA_EV6)		:= -mcpu=ev6
+cpuflags-$(CONFIG_ALPHA_EV67)		:= -mcpu=ev67
 # If GENERIC, make sure to turn off any instruction set extensions that
 # the host compiler might have on by default.  Given that EV4 and EV5
 # have the same instruction set, prefer EV5 because an EV5 schedule is

arch/alpha/kernel/err_ev7.c

@@ -273,7 +273,7 @@ ev7_process_pal_subpacket(struct el_subpacket *header)
 struct el_subpacket_handler ev7_pal_subpacket_handler =
 	SUBPACKET_HANDLER_INIT(EL_CLASS__PAL, ev7_process_pal_subpacket);
 
-void
+void __init
 ev7_register_error_handlers(void)
 {
 	int i;

arch/alpha/kernel/err_marvel.c

@@ -1152,7 +1152,7 @@ marvel_machine_check(u64 vector, u64 la_ptr)
 	mb();
 }
 
-void
+void __init
 marvel_register_error_handlers(void)
 {
 	ev7_register_error_handlers();

arch/alpha/kernel/err_titan.c

@@ -564,7 +564,7 @@ static struct el_subpacket_handler titan_subpacket_handler =
 	SUBPACKET_HANDLER_INIT(EL_CLASS__REGATTA_FAMILY, 
 			       el_process_regatta_subpacket);
 
-void
+void __init
 titan_register_error_handlers(void)
 {
 	size_t i;

arch/alpha/kernel/machvec_impl.h

@@ -134,7 +134,7 @@
 #define __initmv __initdata
 #define ALIAS_MV(x)
 #else
-#define __initmv
+#define __initmv __initdata_refok
 
 /* GCC actually has a syntax for defining aliases, but is under some
    delusion that you shouldn't be able to declare it extern somewhere

arch/alpha/kernel/pci-noop.c

@@ -12,6 +12,7 @@
 #include <linux/errno.h>
 #include <linux/sched.h>
 #include <linux/dma-mapping.h>
+#include <linux/scatterlist.h>
 
 #include "proto.h"
 
@@ -172,18 +173,19 @@ dma_alloc_coherent(struct device *dev, size_t size,
 EXPORT_SYMBOL(dma_alloc_coherent);
 
 int
-dma_map_sg(struct device *dev, struct scatterlist *sg, int nents,
+dma_map_sg(struct device *dev, struct scatterlist *sgl, int nents,
 	   enum dma_data_direction direction)
 {
 	int i;
+	struct scatterlist *sg;
 
-	for (i = 0; i < nents; i++ ) {
+	for_each_sg(sgl, sg, nents, i) {
 		void *va;
 
-		BUG_ON(!sg[i].page);
-		va = page_address(sg[i].page) + sg[i].offset;
-		sg_dma_address(sg + i) = (dma_addr_t)virt_to_bus(va);
-		sg_dma_len(sg + i) = sg[i].length;
+		BUG_ON(!sg_page(sg));
+		va = sg_virt(sg);
+		sg_dma_address(sg) = (dma_addr_t)virt_to_bus(va);
+		sg_dma_len(sg) = sg->length;
 	}
 
 	return nents;

arch/alpha/lib/ev6-stxncpy.S

@@ -362,10 +362,10 @@ $unaligned:
 
 	extql	t2, a1, t2	# U :
 	cmpbge	zero, t1, t8	# E : is there a zero?
-	andnot	t2, t6, t12	# E : dest mask for a single word copy
+	andnot	t2, t6, t2	# E : dest mask for a single word copy
 	or	t8, t10, t5	# E : test for end-of-count too
 
-	cmpbge	zero, t12, t3	# E :
+	cmpbge	zero, t2, t3	# E :
 	cmoveq	a2, t5, t8	# E : Latency=2, extra map slot
 	nop			# E : keep with cmoveq
 	andnot	t8, t3, t8	# E : (stall)
@@ -379,13 +379,13 @@ $unaligned:
 	negq	t8, t6		# E : build bitmask of bytes <= zero
 	mskqh	t1, t4, t1	# U :
 
-	and	t6, t8, t2	# E :
-	subq	t2, 1, t6	# E : (stall)
-	or	t6, t2, t8	# E : (stall)
-	zapnot	t12, t8, t12	# U : prepare source word; mirror changes (stall)
+	and	t6, t8, t12	# E :
+	subq	t12, 1, t6	# E : (stall)
+	or	t6, t12, t8	# E : (stall)
+	zapnot	t2, t8, t2	# U : prepare source word; mirror changes (stall)
 
 	zapnot	t1, t8, t1	# U : to source validity mask
-	andnot	t0, t12, t0	# E : zero place for source to reside
+	andnot	t0, t2, t0	# E : zero place for source to reside
 	or	t0, t1, t0	# E : and put it there (stall both t0, t1)
 	stq_u	t0, 0(a0)	# L : (stall)
 

arch/alpha/lib/strncpy.S

@@ -35,7 +35,7 @@ strncpy:
 
 	or	$3, $24, $3	# clear the bits between the last
 	or	$4, $27, $4	# written byte and the last byte in COUNT
-	andnot	$4, $3, $4
+	andnot	$3, $4, $4
 	zap	$1, $4, $1
 
 	stq_u	$1, 0($16)

arch/alpha/lib/stxncpy.S

@@ -315,9 +315,9 @@ $unaligned:
 
 	extql	t2, a1, t2	# e0    :
 	cmpbge	zero, t1, t8	# .. e1 : is there a zero?
-	andnot	t2, t6, t12	# e0    : dest mask for a single word copy
+	andnot	t2, t6, t2	# e0    : dest mask for a single word copy
 	or	t8, t10, t5	# .. e1 : test for end-of-count too
-	cmpbge	zero, t12, t3	# e0    :
+	cmpbge	zero, t2, t3	# e0    :
 	cmoveq	a2, t5, t8	# .. e1 :
 	andnot	t8, t3, t8	# e0    :
 	beq	t8, $u_head	# .. e1 (zdb)
@@ -330,14 +330,14 @@ $unaligned:
 	ldq_u	t0, 0(a0)	# e0    :
 	negq	t8, t6		# .. e1 : build bitmask of bytes <= zero
 	mskqh	t1, t4, t1	# e0    :
-	and	t6, t8, t2	# .. e1 :
-	subq	t2, 1, t6	# e0    :
-	or	t6, t2, t8	# e1    :
+	and	t6, t8, t12	# .. e1 :
+	subq	t12, 1, t6	# e0    :
+	or	t6, t12, t8	# e1    :
 
-	zapnot	t12, t8, t12	# e0    : prepare source word; mirror changes
+	zapnot	t2, t8, t2	# e0    : prepare source word; mirror changes
 	zapnot	t1, t8, t1	# .. e1 : to source validity mask
 
-	andnot	t0, t12, t0	# e0    : zero place for source to reside
+	andnot	t0, t2, t0	# e0    : zero place for source to reside
 	or	t0, t1, t0	# e1    : and put it there
 	stq_u	t0, 0(a0)	# e0    :
 	ret	(t9)		# .. e1 :

arch/alpha/math-emu/math.c

@@ -225,7 +225,7 @@ alpha_fp_emul (unsigned long pc)
 				FP_UNPACK_SP(SB, &vb);
 				DR_c = DB_c;
 				DR_s = DB_s;
-				DR_e = DB_e;
+				DR_e = DB_e + (1024 - 128);
 				DR_f = SB_f << (52 - 23);
 				goto pack_d;
 			}

arch/arm/Kconfig

@@ -537,7 +537,7 @@ config ISA_DMA_API
 	bool
 
 config PCI
-	bool "PCI support" if ARCH_INTEGRATOR_AP || ARCH_VERSATILE_PB || ARCH_IXP4XX || ARCH_KS8695
+	bool "PCI support" if ARCH_INTEGRATOR_AP || ARCH_VERSATILE_PB || ARCH_IXP4XX || ARCH_KS8695 || MACH_ARMCORE
 	help
 	  Find out whether you have a PCI motherboard. PCI is the name of a
 	  bus system, i.e. the way the CPU talks to the other stuff inside
@@ -558,6 +558,12 @@ config PCI_HOST_VIA82C505
 	depends on PCI && ARCH_SHARK
 	default y
 
+config PCI_HOST_ITE8152
+	bool
+	depends on PCI && MACH_ARMCORE
+	default y
+	select DMABOUNCE
+
 source "drivers/pci/Kconfig"
 
 source "drivers/pcmcia/Kconfig"
@@ -1040,6 +1046,8 @@ source "drivers/power/Kconfig"
 
 source "drivers/hwmon/Kconfig"
 
+source "drivers/watchdog/Kconfig"
+
 source "drivers/ssb/Kconfig"
 
 #source "drivers/l3/Kconfig"
@@ -1064,11 +1072,13 @@ source "drivers/rtc/Kconfig"
 
 source "drivers/dma/Kconfig"
 
+source "drivers/dca/Kconfig"
+
 endmenu
 
 source "fs/Kconfig"
 
-source "kernel/Kconfig.instrumentation"
+source "arch/arm/Kconfig.instrumentation"
 
 source "arch/arm/Kconfig.debug"
 

arch/arm/Kconfig.instrumentation

@@ -0,0 +1,52 @@
+menuconfig INSTRUMENTATION
+	bool "Instrumentation Support"
+	default y
+	---help---
+	  Say Y here to get to see options related to performance measurement,
+	  system-wide debugging, and testing. This option alone does not add any
+	  kernel code.
+
+	  If you say N, all options in this submenu will be skipped and
+	  disabled. If you're trying to debug the kernel itself, go see the
+	  Kernel Hacking menu.
+
+if INSTRUMENTATION
+
+config PROFILING
+	bool "Profiling support (EXPERIMENTAL)"
+	help
+	  Say Y here to enable the extended profiling support mechanisms used
+	  by profilers such as OProfile.
+
+config OPROFILE
+	tristate "OProfile system profiling (EXPERIMENTAL)"
+	depends on PROFILING && !UML
+	help
+	  OProfile is a profiling system capable of profiling the
+	  whole system, include the kernel, kernel modules, libraries,
+	  and applications.
+
+	  If unsure, say N.
+
+config OPROFILE_ARMV6
+	bool
+	depends on OPROFILE && CPU_V6 && !SMP
+	default y
+	select OPROFILE_ARM11_CORE
+
+config OPROFILE_MPCORE
+	bool
+	depends on OPROFILE && CPU_V6 && SMP
+	default y
+	select OPROFILE_ARM11_CORE
+
+config OPROFILE_ARM11_CORE
+	bool
+
+config MARKERS
+	bool "Activate markers"
+	help
+	  Place an empty function call at each marker site. Can be
+	  dynamically changed for a probe function.
+
+endif # INSTRUMENTATION

arch/arm/boot/compressed/head.S

@@ -31,7 +31,7 @@
 		.macro	loadsp, rb
 		.endm
 		.macro	writeb, ch, rb
-		mcr	p14, 0, \ch, c0, c1, 0
+		mcr	p14, 0, \ch, c1, c0, 0
 		.endm
 #endif
 

arch/arm/common/it8152.c

@@ -70,8 +70,6 @@ static inline void it8152_irq(int irq)
 {
 	struct irq_desc *desc;
 
-	printk(KERN_DEBUG "===> %s: irq=%d\n", __FUNCTION__, irq);
-
 	desc = irq_desc + irq;
 	desc_handle_irq(irq, desc);
 }
@@ -106,8 +104,6 @@ void it8152_irq_demux(unsigned int irq, struct irq_desc *desc)
        int bits_pd, bits_lp, bits_ld;
        int i;
 
-       printk(KERN_DEBUG "=> %s: irq = %d\n", __FUNCTION__, irq);
-
        while (1) {
 	       /* Read all */
 	       bits_pd = __raw_readl(IT8152_INTC_PDCNIRR);
@@ -293,8 +289,7 @@ int dma_needs_bounce(struct device *dev, dma_addr_t dma_addr, size_t size)
  */
 int pci_set_dma_mask(struct pci_dev *dev, u64 mask)
 {
-	printk(KERN_DEBUG "%s: %s %llx\n",
-	       __FUNCTION__, dev->dev.bus_id, mask);
+	dev_dbg(&dev->dev, "%s: %llx\n", __FUNCTION__, mask);
 	if (mask >= PHYS_OFFSET + SZ_64M - 1)
 		return 0;
 
@@ -304,8 +299,7 @@ int pci_set_dma_mask(struct pci_dev *dev, u64 mask)
 int
 pci_set_consistent_dma_mask(struct pci_dev *dev, u64 mask)
 {
-	printk(KERN_DEBUG "%s: %s %llx\n",
-	       __FUNCTION__, dev->dev.bus_id, mask);
+	dev_dbg(&dev->dev, "%s: %llx\n", __FUNCTION__, mask);
 	if (mask >= PHYS_OFFSET + SZ_64M - 1)
 		return 0;
 

arch/arm/common/uengine.c

@@ -374,8 +374,8 @@ static int set_initial_registers(int uengine, struct ixp2000_uengine_code *c)
 	u8 *ucode;
 	int i;
 
-	gpr_a = kmalloc(128 * sizeof(u32), GFP_KERNEL);
-	gpr_b = kmalloc(128 * sizeof(u32), GFP_KERNEL);
+	gpr_a = kzalloc(128 * sizeof(u32), GFP_KERNEL);
+	gpr_b = kzalloc(128 * sizeof(u32), GFP_KERNEL);
 	ucode = kmalloc(513 * 5, GFP_KERNEL);
 	if (gpr_a == NULL || gpr_b == NULL || ucode == NULL) {
 		kfree(ucode);
@@ -388,8 +388,6 @@ static int set_initial_registers(int uengine, struct ixp2000_uengine_code *c)
 	if (c->uengine_parameters & IXP2000_UENGINE_4_CONTEXTS)
 		per_ctx_regs = 32;
 
-	memset(gpr_a, 0, sizeof(gpr_a));
-	memset(gpr_b, 0, sizeof(gpr_b));
 	for (i = 0; i < 256; i++) {
 		struct ixp2000_reg_value *r = c->initial_reg_values + i;
 		u32 *bank;

arch/arm/kernel/entry-armv.S

@@ -339,16 +339,6 @@ __pabt_svc:
 	str	r1, [sp]		@ save the "real" r0 copied
 					@ from the exception stack
 
-#if __LINUX_ARM_ARCH__ < 6 && !defined(CONFIG_NEEDS_SYSCALL_FOR_CMPXCHG)
-#ifndef CONFIG_MMU
-#warning "NPTL on non MMU needs fixing"
-#else
-	@ make sure our user space atomic helper is aborted
-	cmp	r2, #TASK_SIZE
-	bichs	r3, r3, #PSR_Z_BIT
-#endif
-#endif
-
 	@
 	@ We are now ready to fill in the remaining blanks on the stack:
 	@
@@ -372,9 +362,25 @@ __pabt_svc:
 	zero_fp
 	.endm
 
+	.macro	kuser_cmpxchg_check
+#if __LINUX_ARM_ARCH__ < 6 && !defined(CONFIG_NEEDS_SYSCALL_FOR_CMPXCHG)
+#ifndef CONFIG_MMU
+#warning "NPTL on non MMU needs fixing"
+#else
+	@ Make sure our user space atomic helper is restarted
+	@ if it was interrupted in a critical region.  Here we
+	@ perform a quick test inline since it should be false
+	@ 99.9999% of the time.  The rest is done out of line.
+	cmp	r2, #TASK_SIZE
+	blhs	kuser_cmpxchg_fixup
+#endif
+#endif
+	.endm
+
 	.align	5
 __dabt_usr:
 	usr_entry
+	kuser_cmpxchg_check
 
 	@
 	@ Call the processor-specific abort handler:
@@ -404,6 +410,7 @@ __dabt_usr:
 	.align	5
 __irq_usr:
 	usr_entry
+	kuser_cmpxchg_check
 
 #ifdef CONFIG_TRACE_IRQFLAGS
 	bl	trace_hardirqs_off
@@ -446,9 +453,9 @@ __und_usr:
 	@
 	@  r0 - instruction
 	@
-1:	ldrt	r0, [r4]
 	adr	r9, ret_from_exception
 	adr	lr, __und_usr_unknown
+1:	ldrt	r0, [r4]
 	@
 	@ fallthrough to call_fpe
 	@
@@ -669,7 +676,7 @@ __kuser_helper_start:
  *
  * Clobbered:
  *
- *	the Z flag might be lost
+ *	none
  *
  * Definition and user space usage example:
  *
@@ -730,9 +737,6 @@ __kuser_memory_barrier:				@ 0xffff0fa0
  *
  *    - This routine already includes memory barriers as needed.
  *
- *    - A failure might be transient, i.e. it is possible, although unlikely,
- *      that "failure" be returned even if *ptr == oldval.
- *
  * For example, a user space atomic_add implementation could look like this:
  *
  * #define atomic_add(ptr, val) \
@@ -769,46 +773,62 @@ __kuser_cmpxchg:				@ 0xffff0fc0
 
 #elif __LINUX_ARM_ARCH__ < 6
 
-	/*
-	 * Theory of operation:
-	 *
-	 * We set the Z flag before loading oldval. If ever an exception
-	 * occurs we can not be sure the loaded value will still be the same
-	 * when the exception returns, therefore the user exception handler
-	 * will clear the Z flag whenever the interrupted user code was
-	 * actually from the kernel address space (see the usr_entry macro).
-	 *
-	 * The post-increment on the str is used to prevent a race with an
-	 * exception happening just after the str instruction which would
-	 * clear the Z flag although the exchange was done.
-	 */
 #ifdef CONFIG_MMU
-	teq	ip, ip			@ set Z flag
-	ldr	ip, [r2]		@ load current val
-	add	r3, r2, #1		@ prepare store ptr
-	teqeq	ip, r0			@ compare with oldval if still allowed
-	streq	r1, [r3, #-1]!		@ store newval if still allowed
-	subs	r0, r2, r3		@ if r2 == r3 the str occured
+
+	/*
+	 * The only thing that can break atomicity in this cmpxchg
+	 * implementation is either an IRQ or a data abort exception
+	 * causing another process/thread to be scheduled in the middle
+	 * of the critical sequence.  To prevent this, code is added to
+	 * the IRQ and data abort exception handlers to set the pc back
+	 * to the beginning of the critical section if it is found to be
+	 * within that critical section (see kuser_cmpxchg_fixup).
+	 */
+1:	ldr	r3, [r2]			@ load current val
+	subs	r3, r3, r0			@ compare with oldval
+2:	streq	r1, [r2]			@ store newval if eq
+	rsbs	r0, r3, #0			@ set return val and C flag
+	usr_ret	lr
+
+	.text
+kuser_cmpxchg_fixup:
+	@ Called from kuser_cmpxchg_check macro.
+	@ r2 = address of interrupted insn (must be preserved).
+	@ sp = saved regs. r7 and r8 are clobbered.
+	@ 1b = first critical insn, 2b = last critical insn.
+	@ If r2 >= 1b and r2 <= 2b then saved pc_usr is set to 1b.
+	mov	r7, #0xffff0fff
+	sub	r7, r7, #(0xffff0fff - (0xffff0fc0 + (1b - __kuser_cmpxchg)))
+	subs	r8, r2, r7
+	rsbcss	r8, r8, #(2b - 1b)
+	strcs	r7, [sp, #S_PC]
+	mov	pc, lr
+	.previous
+
 #else
 #warning "NPTL on non MMU needs fixing"
 	mov	r0, #-1
 	adds	r0, r0, #0
-#endif
 	usr_ret	lr
+#endif
 
 #else
 
 #ifdef CONFIG_SMP
 	mcr	p15, 0, r0, c7, c10, 5	@ dmb
 #endif
-	ldrex	r3, [r2]
+1:	ldrex	r3, [r2]
 	subs	r3, r3, r0
 	strexeq	r3, r1, [r2]
+	teqeq	r3, #1
+	beq	1b
 	rsbs	r0, r3, #0
+	/* beware -- each __kuser slot must be 8 instructions max */
 #ifdef CONFIG_SMP
-	mcr	p15, 0, r0, c7, c10, 5	@ dmb
-#endif
+	b	__kuser_memory_barrier
+#else
 	usr_ret	lr
+#endif
 
 #endif
 
@@ -829,7 +849,7 @@ __kuser_cmpxchg:				@ 0xffff0fc0
  *
  * Clobbered:
  *
- *	the Z flag might be lost
+ *	none
  *
  * Definition and user space usage example:
  *

arch/arm/kernel/traps.c

@@ -327,7 +327,7 @@ asmlinkage void __exception do_undefinstr(struct pt_regs *regs)
 		if ((instr & hook->instr_mask) == hook->instr_val &&
 		    (regs->ARM_cpsr & hook->cpsr_mask) == hook->cpsr_val) {
 			if (hook->fn(regs, instr) == 0) {
-				spin_unlock_irq(&undef_lock);
+				spin_unlock_irqrestore(&undef_lock, flags);
 				return;
 			}
 		}
@@ -509,7 +509,7 @@ asmlinkage int arm_syscall(int no, struct pt_regs *regs)
 	 * existence.  Don't ever use this from user code.
 	 */
 	case 0xfff0:
-	{
+	for (;;) {
 		extern void do_DataAbort(unsigned long addr, unsigned int fsr,
 					 struct pt_regs *regs);
 		unsigned long val;
@@ -545,7 +545,6 @@ asmlinkage int arm_syscall(int no, struct pt_regs *regs)
 		up_read(&mm->mmap_sem);
 		/* simulate a write access fault */
 		do_DataAbort(addr, 15 + (1 << 11), regs);
-		return -1;
 	}
 #endif
 

arch/arm/mach-at91/at91rm9200_devices.c

@@ -14,6 +14,7 @@
 #include <asm/mach/map.h>
 
 #include <linux/platform_device.h>
+#include <linux/i2c-gpio.h>
 
 #include <asm/arch/board.h>
 #include <asm/arch/gpio.h>
@@ -435,7 +436,40 @@ void __init at91_add_device_nand(struct at91_nand_data *data) {}
  *  TWI (i2c)
  * -------------------------------------------------------------------- */
 
-#if defined(CONFIG_I2C_AT91) || defined(CONFIG_I2C_AT91_MODULE)
+/*
+ * Prefer the GPIO code since the TWI controller isn't robust
+ * (gets overruns and underruns under load) and can only issue
+ * repeated STARTs in one scenario (the driver doesn't yet handle them).
+ */
+#if defined(CONFIG_I2C_GPIO) || defined(CONFIG_I2C_GPIO_MODULE)
+
+static struct i2c_gpio_platform_data pdata = {
+	.sda_pin		= AT91_PIN_PA25,
+	.sda_is_open_drain	= 1,
+	.scl_pin		= AT91_PIN_PA26,
+	.scl_is_open_drain	= 1,
+	.udelay			= 2,		/* ~100 kHz */
+};
+
+static struct platform_device at91rm9200_twi_device = {
+	.name			= "i2c-gpio",
+	.id			= -1,
+	.dev.platform_data	= &pdata,
+};
+
+void __init at91_add_device_i2c(struct i2c_board_info *devices, int nr_devices)
+{
+	at91_set_GPIO_periph(AT91_PIN_PA25, 1);		/* TWD (SDA) */
+	at91_set_multi_drive(AT91_PIN_PA25, 1);
+
+	at91_set_GPIO_periph(AT91_PIN_PA26, 1);		/* TWCK (SCL) */
+	at91_set_multi_drive(AT91_PIN_PA26, 1);
+
+	i2c_register_board_info(0, devices, nr_devices);
+	platform_device_register(&at91rm9200_twi_device);
+}
+
+#elif defined(CONFIG_I2C_AT91) || defined(CONFIG_I2C_AT91_MODULE)
 
 static struct resource twi_resources[] = {
 	[0] = {
@@ -457,7 +491,7 @@ static struct platform_device at91rm9200_twi_device = {
 	.num_resources	= ARRAY_SIZE(twi_resources),
 };
 
-void __init at91_add_device_i2c(void)
+void __init at91_add_device_i2c(struct i2c_board_info *devices, int nr_devices)
 {
 	/* pins used for TWI interface */
 	at91_set_A_periph(AT91_PIN_PA25, 0);		/* TWD */
@@ -466,10 +500,11 @@ void __init at91_add_device_i2c(void)
 	at91_set_A_periph(AT91_PIN_PA26, 0);		/* TWCK */
 	at91_set_multi_drive(AT91_PIN_PA26, 1);
 
+	i2c_register_board_info(0, devices, nr_devices);
 	platform_device_register(&at91rm9200_twi_device);
 }
 #else
-void __init at91_add_device_i2c(void) {}
+void __init at91_add_device_i2c(struct i2c_board_info *devices, int nr_devices) {}
 #endif
 
 

arch/arm/mach-at91/at91sam9260_devices.c

@@ -13,6 +13,7 @@
 #include <asm/mach/map.h>
 
 #include <linux/platform_device.h>
+#include <linux/i2c-gpio.h>
 
 #include <asm/arch/board.h>
 #include <asm/arch/gpio.h>
@@ -352,7 +353,41 @@ void __init at91_add_device_nand(struct at91_nand_data *data) {}
  *  TWI (i2c)
  * -------------------------------------------------------------------- */
 
-#if defined(CONFIG_I2C_AT91) || defined(CONFIG_I2C_AT91_MODULE)
+/*
+ * Prefer the GPIO code since the TWI controller isn't robust
+ * (gets overruns and underruns under load) and can only issue
+ * repeated STARTs in one scenario (the driver doesn't yet handle them).
+ */
+
+#if defined(CONFIG_I2C_GPIO) || defined(CONFIG_I2C_GPIO_MODULE)
+
+static struct i2c_gpio_platform_data pdata = {
+	.sda_pin		= AT91_PIN_PA23,
+	.sda_is_open_drain	= 1,
+	.scl_pin		= AT91_PIN_PA24,
+	.scl_is_open_drain	= 1,
+	.udelay			= 2,		/* ~100 kHz */
+};
+
+static struct platform_device at91sam9260_twi_device = {
+	.name			= "i2c-gpio",
+	.id			= -1,
+	.dev.platform_data	= &pdata,
+};
+
+void __init at91_add_device_i2c(struct i2c_board_info *devices, int nr_devices)
+{
+	at91_set_GPIO_periph(AT91_PIN_PA23, 1);		/* TWD (SDA) */
+	at91_set_multi_drive(AT91_PIN_PA23, 1);
+
+	at91_set_GPIO_periph(AT91_PIN_PA24, 1);		/* TWCK (SCL) */
+	at91_set_multi_drive(AT91_PIN_PA24, 1);
+
+	i2c_register_board_info(0, devices, nr_devices);
+	platform_device_register(&at91sam9260_twi_device);
+}
+
+#elif defined(CONFIG_I2C_AT91) || defined(CONFIG_I2C_AT91_MODULE)
 
 static struct resource twi_resources[] = {
 	[0] = {
@@ -374,7 +409,7 @@ static struct platform_device at91sam9260_twi_device = {
 	.num_resources	= ARRAY_SIZE(twi_resources),
 };
 
-void __init at91_add_device_i2c(void)
+void __init at91_add_device_i2c(struct i2c_board_info *devices, int nr_devices)
 {
 	/* pins used for TWI interface */
 	at91_set_A_periph(AT91_PIN_PA23, 0);		/* TWD */
@@ -383,10 +418,11 @@ void __init at91_add_device_i2c(void)
 	at91_set_A_periph(AT91_PIN_PA24, 0);		/* TWCK */
 	at91_set_multi_drive(AT91_PIN_PA24, 1);
 
+	i2c_register_board_info(0, devices, nr_devices);
 	platform_device_register(&at91sam9260_twi_device);
 }
 #else
-void __init at91_add_device_i2c(void) {}
+void __init at91_add_device_i2c(struct i2c_board_info *devices, int nr_devices) {}
 #endif
 
 

arch/arm/mach-at91/at91sam9261_devices.c

@@ -14,7 +14,9 @@
 #include <asm/mach/map.h>
 
 #include <linux/platform_device.h>
+#include <linux/i2c-gpio.h>
 
+#include <linux/fb.h>
 #include <video/atmel_lcdc.h>
 
 #include <asm/arch/board.h>
@@ -275,7 +277,40 @@ void __init at91_add_device_nand(struct at91_nand_data *data) {}
  *  TWI (i2c)
  * -------------------------------------------------------------------- */
 
-#if defined(CONFIG_I2C_AT91) || defined(CONFIG_I2C_AT91_MODULE)
+/*
+ * Prefer the GPIO code since the TWI controller isn't robust
+ * (gets overruns and underruns under load) and can only issue
+ * repeated STARTs in one scenario (the driver doesn't yet handle them).
+ */
+#if defined(CONFIG_I2C_GPIO) || defined(CONFIG_I2C_GPIO_MODULE)
+
+static struct i2c_gpio_platform_data pdata = {
+	.sda_pin		= AT91_PIN_PA7,
+	.sda_is_open_drain	= 1,
+	.scl_pin		= AT91_PIN_PA8,
+	.scl_is_open_drain	= 1,
+	.udelay			= 2,		/* ~100 kHz */
+};
+
+static struct platform_device at91sam9261_twi_device = {
+	.name			= "i2c-gpio",
+	.id			= -1,
+	.dev.platform_data	= &pdata,
+};
+
+void __init at91_add_device_i2c(struct i2c_board_info *devices, int nr_devices)
+{
+	at91_set_GPIO_periph(AT91_PIN_PA7, 1);		/* TWD (SDA) */
+	at91_set_multi_drive(AT91_PIN_PA7, 1);
+
+	at91_set_GPIO_periph(AT91_PIN_PA8, 1);		/* TWCK (SCL) */
+	at91_set_multi_drive(AT91_PIN_PA8, 1);
+
+	i2c_register_board_info(0, devices, nr_devices);
+	platform_device_register(&at91sam9261_twi_device);
+}
+
+#elif defined(CONFIG_I2C_AT91) || defined(CONFIG_I2C_AT91_MODULE)
 
 static struct resource twi_resources[] = {
 	[0] = {
@@ -297,7 +332,7 @@ static struct platform_device at91sam9261_twi_device = {
 	.num_resources	= ARRAY_SIZE(twi_resources),
 };
 
-void __init at91_add_device_i2c(void)
+void __init at91_add_device_i2c(struct i2c_board_info *devices, int nr_devices)
 {
 	/* pins used for TWI interface */
 	at91_set_A_periph(AT91_PIN_PA7, 0);		/* TWD */
@@ -306,10 +341,11 @@ void __init at91_add_device_i2c(void)
 	at91_set_A_periph(AT91_PIN_PA8, 0);		/* TWCK */
 	at91_set_multi_drive(AT91_PIN_PA8, 1);
 
+	i2c_register_board_info(0, devices, nr_devices);
 	platform_device_register(&at91sam9261_twi_device);
 }
 #else
-void __init at91_add_device_i2c(void) {}
+void __init at91_add_device_i2c(struct i2c_board_info *devices, int nr_devices) {}
 #endif
 
 

arch/arm/mach-at91/at91sam9263_devices.c

@@ -13,7 +13,9 @@
 #include <asm/mach/map.h>
 
 #include <linux/platform_device.h>
+#include <linux/i2c-gpio.h>
 
+#include <linux/fb.h>
 #include <video/atmel_lcdc.h>
 
 #include <asm/arch/board.h>
@@ -421,7 +423,40 @@ void __init at91_add_device_nand(struct at91_nand_data *data) {}
  *  TWI (i2c)
  * -------------------------------------------------------------------- */
 
-#if defined(CONFIG_I2C_AT91) || defined(CONFIG_I2C_AT91_MODULE)
+/*
+ * Prefer the GPIO code since the TWI controller isn't robust
+ * (gets overruns and underruns under load) and can only issue
+ * repeated STARTs in one scenario (the driver doesn't yet handle them).
+ */
+#if defined(CONFIG_I2C_GPIO) || defined(CONFIG_I2C_GPIO_MODULE)
+
+static struct i2c_gpio_platform_data pdata = {
+	.sda_pin		= AT91_PIN_PB4,
+	.sda_is_open_drain	= 1,
+	.scl_pin		= AT91_PIN_PB5,
+	.scl_is_open_drain	= 1,
+	.udelay			= 2,		/* ~100 kHz */
+};
+
+static struct platform_device at91sam9263_twi_device = {
+	.name			= "i2c-gpio",
+	.id			= -1,
+	.dev.platform_data	= &pdata,
+};
+
+void __init at91_add_device_i2c(struct i2c_board_info *devices, int nr_devices)
+{
+	at91_set_GPIO_periph(AT91_PIN_PB4, 1);		/* TWD (SDA) */
+	at91_set_multi_drive(AT91_PIN_PB4, 1);
+
+	at91_set_GPIO_periph(AT91_PIN_PB5, 1);		/* TWCK (SCL) */
+	at91_set_multi_drive(AT91_PIN_PB5, 1);
+
+	i2c_register_board_info(0, devices, nr_devices);
+	platform_device_register(&at91sam9263_twi_device);
+}
+
+#elif defined(CONFIG_I2C_AT91) || defined(CONFIG_I2C_AT91_MODULE)
 
 static struct resource twi_resources[] = {
 	[0] = {
@@ -443,7 +478,7 @@ static struct platform_device at91sam9263_twi_device = {
 	.num_resources	= ARRAY_SIZE(twi_resources),
 };
 
-void __init at91_add_device_i2c(void)
+void __init at91_add_device_i2c(struct i2c_board_info *devices, int nr_devices)
 {
 	/* pins used for TWI interface */
 	at91_set_A_periph(AT91_PIN_PB4, 0);		/* TWD */
@@ -452,10 +487,11 @@ void __init at91_add_device_i2c(void)
 	at91_set_A_periph(AT91_PIN_PB5, 0);		/* TWCK */
 	at91_set_multi_drive(AT91_PIN_PB5, 1);
 
+	i2c_register_board_info(0, devices, nr_devices);
 	platform_device_register(&at91sam9263_twi_device);
 }
 #else
-void __init at91_add_device_i2c(void) {}
+void __init at91_add_device_i2c(struct i2c_board_info *devices, int nr_devices) {}
 #endif
 
 

arch/arm/mach-at91/at91sam9rl_devices.c

@@ -10,8 +10,9 @@
 #include <asm/mach/map.h>
 
 #include <linux/platform_device.h>
-#include <linux/fb.h>
+#include <linux/i2c-gpio.h>
 
+#include <linux/fb.h>
 #include <video/atmel_lcdc.h>
 
 #include <asm/arch/board.h>
@@ -169,7 +170,40 @@ void __init at91_add_device_nand(struct at91_nand_data *data) {}
  *  TWI (i2c)
  * -------------------------------------------------------------------- */
 
-#if defined(CONFIG_I2C_AT91) || defined(CONFIG_I2C_AT91_MODULE)
+/*
+ * Prefer the GPIO code since the TWI controller isn't robust
+ * (gets overruns and underruns under load) and can only issue
+ * repeated STARTs in one scenario (the driver doesn't yet handle them).
+ */
+#if defined(CONFIG_I2C_GPIO) || defined(CONFIG_I2C_GPIO_MODULE)
+
+static struct i2c_gpio_platform_data pdata = {
+	.sda_pin		= AT91_PIN_PA23,
+	.sda_is_open_drain	= 1,
+	.scl_pin		= AT91_PIN_PA24,
+	.scl_is_open_drain	= 1,
+	.udelay			= 2,		/* ~100 kHz */
+};
+
+static struct platform_device at91sam9rl_twi_device = {
+	.name			= "i2c-gpio",
+	.id			= -1,
+	.dev.platform_data	= &pdata,
+};
+
+void __init at91_add_device_i2c(struct i2c_board_info *devices, int nr_devices)
+{
+	at91_set_GPIO_periph(AT91_PIN_PA23, 1);		/* TWD (SDA) */
+	at91_set_multi_drive(AT91_PIN_PA23, 1);
+
+	at91_set_GPIO_periph(AT91_PIN_PA24, 1);		/* TWCK (SCL) */
+	at91_set_multi_drive(AT91_PIN_PA24, 1);
+
+	i2c_register_board_info(0, devices, nr_devices);
+	platform_device_register(&at91sam9rl_twi_device);
+}
+
+#elif defined(CONFIG_I2C_AT91) || defined(CONFIG_I2C_AT91_MODULE)
 
 static struct resource twi_resources[] = {
 	[0] = {
@@ -191,7 +225,7 @@ static struct platform_device at91sam9rl_twi_device = {
 	.num_resources	= ARRAY_SIZE(twi_resources),
 };
 
-void __init at91_add_device_i2c(void)
+void __init at91_add_device_i2c(struct i2c_board_info *devices, int nr_devices)
 {
 	/* pins used for TWI interface */
 	at91_set_A_periph(AT91_PIN_PA23, 0);		/* TWD */
@@ -200,10 +234,11 @@ void __init at91_add_device_i2c(void)
 	at91_set_A_periph(AT91_PIN_PA24, 0);		/* TWCK */
 	at91_set_multi_drive(AT91_PIN_PA24, 1);
 
+	i2c_register_board_info(0, devices, nr_devices);
 	platform_device_register(&at91sam9rl_twi_device);
 }
 #else
-void __init at91_add_device_i2c(void) {}
+void __init at91_add_device_i2c(struct i2c_board_info *devices, int nr_devices) {}
 #endif
 
 

arch/arm/mach-at91/board-carmeva.c

@@ -128,7 +128,7 @@ static void __init carmeva_board_init(void)
 	/* USB Device */
 	at91_add_device_udc(&carmeva_udc_data);
 	/* I2C */
-	at91_add_device_i2c();
+	at91_add_device_i2c(NULL, 0);
 	/* SPI */
 	at91_add_device_spi(carmeva_spi_devices, ARRAY_SIZE(carmeva_spi_devices));
 	/* Compact Flash */

arch/arm/mach-at91/board-csb337.c

@@ -23,7 +23,6 @@
 #include <linux/mm.h>
 #include <linux/module.h>
 #include <linux/platform_device.h>
-#include <linux/i2c.h>
 #include <linux/spi/spi.h>
 #include <linux/mtd/physmap.h>
 
@@ -85,12 +84,12 @@ static struct at91_udc_data __initdata csb337_udc_data = {
 };
 
 static struct i2c_board_info __initdata csb337_i2c_devices[] = {
-	{ I2C_BOARD_INFO("rtc-ds1307", 0x68),
-	  .type = "ds1307",
+	{
+		I2C_BOARD_INFO("rtc-ds1307", 0x68),
+		.type	= "ds1307",
 	},
 };
 
-
 static struct at91_cf_data __initdata csb337_cf_data = {
 	/*
 	 * connector P4 on the CSB 337 mates to
@@ -168,9 +167,7 @@ static void __init csb337_board_init(void)
 	/* USB Device */
 	at91_add_device_udc(&csb337_udc_data);
 	/* I2C */
-	at91_add_device_i2c();
-	i2c_register_board_info(0, csb337_i2c_devices,
-			ARRAY_SIZE(csb337_i2c_devices));
+	at91_add_device_i2c(csb337_i2c_devices, ARRAY_SIZE(csb337_i2c_devices));
 	/* Compact Flash */
 	at91_set_gpio_input(AT91_PIN_PB22, 1);		/* IOIS16 */
 	at91_add_device_cf(&csb337_cf_data);

arch/arm/mach-at91/board-csb637.c

@@ -129,7 +129,7 @@ static void __init csb637_board_init(void)
 	/* USB Device */
 	at91_add_device_udc(&csb637_udc_data);
 	/* I2C */
-	at91_add_device_i2c();
+	at91_add_device_i2c(NULL, 0);
 	/* SPI */
 	at91_add_device_spi(NULL, 0);
 	/* NOR flash */

arch/arm/mach-at91/board-dk.c

@@ -124,6 +124,19 @@ static struct spi_board_info dk_spi_devices[] = {
 #endif
 };
 
+static struct i2c_board_info __initdata dk_i2c_devices[] = {
+	{
+		I2C_BOARD_INFO("ics1523", 0x26),
+	},
+	{
+		I2C_BOARD_INFO("x9429", 0x28),
+	},
+	{
+		I2C_BOARD_INFO("at24c", 0x50),
+		.type	= "24c1024",
+	}
+};
+
 static struct mtd_partition __initdata dk_nand_partition[] = {
 	{
 		.name	= "NAND Partition 1",
@@ -185,7 +198,7 @@ static void __init dk_board_init(void)
 	/* Compact Flash */
 	at91_add_device_cf(&dk_cf_data);
 	/* I2C */
-	at91_add_device_i2c();
+	at91_add_device_i2c(dk_i2c_devices, ARRAY_SIZE(dk_i2c_devices));
 	/* SPI */
 	at91_add_device_spi(dk_spi_devices, ARRAY_SIZE(dk_spi_devices));
 #ifdef CONFIG_MTD_AT91_DATAFLASH_CARD

arch/arm/mach-at91/board-eb9200.c

@@ -91,6 +91,14 @@ static struct at91_mmc_data __initdata eb9200_mmc_data = {
 	.wire4		= 1,
 };
 
+static struct i2c_board_info __initdata eb9200_i2c_devices[] = {
+	{
+		I2C_BOARD_INFO("at24c", 0x50),
+		.type	= "24c512",
+	},
+};
+
+
 static void __init eb9200_board_init(void)
 {
 	/* Serial */
@@ -102,7 +110,7 @@ static void __init eb9200_board_init(void)
 	/* USB Device */
 	at91_add_device_udc(&eb9200_udc_data);
 	/* I2C */
-	at91_add_device_i2c();
+	at91_add_device_i2c(eb9200_i2c_devices, ARRAY_SIZE(eb9200_i2c_devices));
 	/* Compact Flash */
 	at91_add_device_cf(&eb9200_cf_data);
 	/* SPI */

arch/arm/mach-at91/board-ek.c

@@ -109,6 +109,15 @@ static struct spi_board_info ek_spi_devices[] = {
 #endif
 };
 
+static struct i2c_board_info __initdata ek_i2c_devices[] = {
+	{
+		I2C_BOARD_INFO("ics1523", 0x26),
+	},
+	{
+		I2C_BOARD_INFO("dac3550", 0x4d),
+	}
+};
+
 #define EK_FLASH_BASE	AT91_CHIPSELECT_0
 #define EK_FLASH_SIZE	0x200000
 
@@ -145,7 +154,7 @@ static void __init ek_board_init(void)
 	at91_add_device_udc(&ek_udc_data);
 	at91_set_multi_drive(ek_udc_data.pullup_pin, 1);	/* pullup_pin is connected to reset */
 	/* I2C */
-	at91_add_device_i2c();
+	at91_add_device_i2c(ek_i2c_devices, ARRAY_SIZE(ek_i2c_devices));
 	/* SPI */
 	at91_add_device_spi(ek_spi_devices, ARRAY_SIZE(ek_spi_devices));
 #ifdef CONFIG_MTD_AT91_DATAFLASH_CARD

arch/arm/mach-at91/board-kafa.c

@@ -92,7 +92,7 @@ static void __init kafa_board_init(void)
 	/* USB Device */
 	at91_add_device_udc(&kafa_udc_data);
 	/* I2C */
-	at91_add_device_i2c();
+	at91_add_device_i2c(NULL, 0);
 	/* SPI */
 	at91_add_device_spi(NULL, 0);
 }

arch/arm/mach-at91/board-kb9202.c

@@ -124,7 +124,7 @@ static void __init kb9202_board_init(void)
 	/* MMC */
 	at91_add_device_mmc(0, &kb9202_mmc_data);
 	/* I2C */
-	at91_add_device_i2c();
+	at91_add_device_i2c(NULL, 0);
 	/* SPI */
 	at91_add_device_spi(NULL, 0);
 	/* NAND */

arch/arm/mach-at91/board-picotux200.c

@@ -139,7 +139,7 @@ static void __init picotux200_board_init(void)
 	// at91_add_device_udc(&picotux200_udc_data);
 	// at91_set_multi_drive(picotux200_udc_data.pullup_pin, 1);	/* pullup_pin is connected to reset */
 	/* I2C */
-	at91_add_device_i2c();
+	at91_add_device_i2c(NULL, 0);
 	/* SPI */
 	// at91_add_device_spi(picotux200_spi_devices, ARRAY_SIZE(picotux200_spi_devices));
 #ifdef CONFIG_MTD_AT91_DATAFLASH_CARD

arch/arm/mach-at91/board-sam9260ek.c

@@ -189,7 +189,7 @@ static void __init ek_board_init(void)
 	/* MMC */
 	at91_add_device_mmc(0, &ek_mmc_data);
 	/* I2C */
-	at91_add_device_i2c();
+	at91_add_device_i2c(NULL, 0);
 }
 
 MACHINE_START(AT91SAM9260EK, "Atmel AT91SAM9260-EK")

arch/arm/mach-at91/board-sam9261ek.c

@@ -382,14 +382,14 @@ static struct platform_device ek_button_device = {
 
 static void __init ek_add_device_buttons(void)
 {
-	at91_set_gpio_input(AT91_PIN_PB27, 0);	/* btn0 */
-	at91_set_deglitch(AT91_PIN_PB27, 1);
-	at91_set_gpio_input(AT91_PIN_PB26, 0);	/* btn1 */
-	at91_set_deglitch(AT91_PIN_PB26, 1);
-	at91_set_gpio_input(AT91_PIN_PB25, 0);	/* btn2 */
-	at91_set_deglitch(AT91_PIN_PB25, 1);
-	at91_set_gpio_input(AT91_PIN_PB24, 0);	/* btn3 */
-	at91_set_deglitch(AT91_PIN_PB24, 1);
+	at91_set_gpio_input(AT91_PIN_PA27, 0);	/* btn0 */
+	at91_set_deglitch(AT91_PIN_PA27, 1);
+	at91_set_gpio_input(AT91_PIN_PA26, 0);	/* btn1 */
+	at91_set_deglitch(AT91_PIN_PA26, 1);
+	at91_set_gpio_input(AT91_PIN_PA25, 0);	/* btn2 */
+	at91_set_deglitch(AT91_PIN_PA25, 1);
+	at91_set_gpio_input(AT91_PIN_PA24, 0);	/* btn3 */
+	at91_set_deglitch(AT91_PIN_PA24, 1);
 
 	platform_device_register(&ek_button_device);
 }
@@ -406,7 +406,7 @@ static void __init ek_board_init(void)
 	/* USB Device */
 	at91_add_device_udc(&ek_udc_data);
 	/* I2C */
-	at91_add_device_i2c();
+	at91_add_device_i2c(NULL, 0);
 	/* NAND */
 	at91_add_device_nand(&ek_nand_data);
 	/* DM9000 ethernet */

arch/arm/mach-at91/board-sam9263ek.c

@@ -291,7 +291,7 @@ static void __init ek_board_init(void)
 	/* NAND */
 	at91_add_device_nand(&ek_nand_data);
 	/* I2C */
-	at91_add_device_i2c();
+	at91_add_device_i2c(NULL, 0);
 	/* LCD Controller */
 	at91_add_device_lcdc(&ek_lcdc_data);
 	/* AC97 */

arch/arm/mach-at91/board-sam9rlek.c

@@ -181,7 +181,7 @@ static void __init ek_board_init(void)
 	/* Serial */
 	at91_add_device_serial();
 	/* I2C */
-	at91_add_device_i2c();
+	at91_add_device_i2c(NULL, 0);
 	/* NAND */
 	at91_add_device_nand(&ek_nand_data);
 	/* SPI */

arch/arm/mach-at91/clock.c

@@ -351,7 +351,7 @@ static void init_programmable_clock(struct clk *clk)
 	pckr = at91_sys_read(AT91_PMC_PCKR(clk->id));
 	parent = at91_css_to_clk(pckr & AT91_PMC_CSS);
 	clk->parent = parent;
-	clk->rate_hz = parent->rate_hz / (1 << ((pckr >> 2) & 3));
+	clk->rate_hz = parent->rate_hz / (1 << ((pckr & AT91_PMC_PRES) >> 2));
 }
 
 #endif	/* CONFIG_AT91_PROGRAMMABLE_CLOCKS */
@@ -587,8 +587,11 @@ int __init at91_clock_init(unsigned long main_clock)
 	mckr = at91_sys_read(AT91_PMC_MCKR);
 	mck.parent = at91_css_to_clk(mckr & AT91_PMC_CSS);
 	freq = mck.parent->rate_hz;
-	freq /= (1 << ((mckr >> 2) & 3));		/* prescale */
-	mck.rate_hz = freq / (1 + ((mckr >> 8) & 3));	/* mdiv */
+	freq /= (1 << ((mckr & AT91_PMC_PRES) >> 2));				/* prescale */
+	if (cpu_is_at91rm9200())
+		mck.rate_hz = freq / (1 + ((mckr & AT91_PMC_MDIV) >> 8));	/* mdiv */
+	else
+		mck.rate_hz = freq / (1 << ((mckr & AT91_PMC_MDIV) >> 8));	/* mdiv */
 
 	/* Register the PMC's standard clocks */
 	for (i = 0; i < ARRAY_SIZE(standard_pmc_clocks); i++)

arch/arm/mach-imx/irq.c

@@ -43,12 +43,46 @@
  *
  */
 
-#define INTENNUM_OFF              0x8
-#define INTDISNUM_OFF             0xC
+#define INTCNTL_OFF               0x00
+#define NIMASK_OFF                0x04
+#define INTENNUM_OFF              0x08
+#define INTDISNUM_OFF             0x0C
+#define INTENABLEH_OFF            0x10
+#define INTENABLEL_OFF            0x14
+#define INTTYPEH_OFF              0x18
+#define INTTYPEL_OFF              0x1C
+#define NIPRIORITY_OFF(x)         (0x20+4*(7-(x)))
+#define NIVECSR_OFF               0x40
+#define FIVECSR_OFF               0x44
+#define INTSRCH_OFF               0x48
+#define INTSRCL_OFF               0x4C
+#define INTFRCH_OFF               0x50
+#define INTFRCL_OFF               0x54
+#define NIPNDH_OFF                0x58
+#define NIPNDL_OFF                0x5C
+#define FIPNDH_OFF                0x60
+#define FIPNDL_OFF                0x64
 
 #define VA_AITC_BASE              IO_ADDRESS(IMX_AITC_BASE)
-#define IMX_AITC_INTDISNUM       (VA_AITC_BASE + INTDISNUM_OFF)
+#define IMX_AITC_INTCNTL         (VA_AITC_BASE + INTCNTL_OFF)
+#define IMX_AITC_NIMASK          (VA_AITC_BASE + NIMASK_OFF)
 #define IMX_AITC_INTENNUM        (VA_AITC_BASE + INTENNUM_OFF)
+#define IMX_AITC_INTDISNUM       (VA_AITC_BASE + INTDISNUM_OFF)
+#define IMX_AITC_INTENABLEH      (VA_AITC_BASE + INTENABLEH_OFF)
+#define IMX_AITC_INTENABLEL      (VA_AITC_BASE + INTENABLEL_OFF)
+#define IMX_AITC_INTTYPEH        (VA_AITC_BASE + INTTYPEH_OFF)
+#define IMX_AITC_INTTYPEL        (VA_AITC_BASE + INTTYPEL_OFF)
+#define IMX_AITC_NIPRIORITY(x)   (VA_AITC_BASE + NIPRIORITY_OFF(x))
+#define IMX_AITC_NIVECSR         (VA_AITC_BASE + NIVECSR_OFF)
+#define IMX_AITC_FIVECSR         (VA_AITC_BASE + FIVECSR_OFF)
+#define IMX_AITC_INTSRCH         (VA_AITC_BASE + INTSRCH_OFF)
+#define IMX_AITC_INTSRCL         (VA_AITC_BASE + INTSRCL_OFF)
+#define IMX_AITC_INTFRCH         (VA_AITC_BASE + INTFRCH_OFF)
+#define IMX_AITC_INTFRCL         (VA_AITC_BASE + INTFRCL_OFF)
+#define IMX_AITC_NIPNDH          (VA_AITC_BASE + NIPNDH_OFF)
+#define IMX_AITC_NIPNDL          (VA_AITC_BASE + NIPNDL_OFF)
+#define IMX_AITC_FIPNDH          (VA_AITC_BASE + FIPNDH_OFF)
+#define IMX_AITC_FIPNDL          (VA_AITC_BASE + FIPNDL_OFF)
 
 #if 0
 #define DEBUG_IRQ(fmt...)	printk(fmt)
@@ -222,7 +256,12 @@ imx_init_irq(void)
 
 	DEBUG_IRQ("Initializing imx interrupts\n");
 
-	/* Mask all interrupts initially */
+	/* Disable all interrupts initially. */
+	/* Do not rely on the bootloader. */
+	__raw_writel(0, IMX_AITC_INTENABLEH);
+	__raw_writel(0, IMX_AITC_INTENABLEL);
+
+	/* Mask all GPIO interrupts as well */
 	IMR(0) = 0;
 	IMR(1) = 0;
 	IMR(2) = 0;
@@ -245,6 +284,6 @@ imx_init_irq(void)
 	set_irq_chained_handler(GPIO_INT_PORTC, imx_gpioc_demux_handler);
 	set_irq_chained_handler(GPIO_INT_PORTD, imx_gpiod_demux_handler);
 
-	/* Disable all interrupts initially. */
-	/* In IMX this is done in the bootloader. */
+	/* Release masking of interrupts according to priority */
+	__raw_writel(-1, IMX_AITC_NIMASK);
 }

arch/arm/mach-iop32x/n2100.c

@@ -16,6 +16,7 @@
 
 #include <linux/mm.h>
 #include <linux/init.h>
+#include <linux/f75375s.h>
 #include <linux/delay.h>
 #include <linux/kernel.h>
 #include <linux/pci.h>
@@ -200,11 +201,21 @@ static struct platform_device n2100_serial_device = {
 	.resource	= &n2100_uart_resource,
 };
 
+static struct f75375s_platform_data n2100_f75375s = {
+	.pwm		= { 255, 255 },
+	.pwm_enable = { 0, 0 },
+};
+
 static struct i2c_board_info __initdata n2100_i2c_devices[] = {
 	{
 		I2C_BOARD_INFO("rtc-rs5c372", 0x32),
 		.type = "rs5c372b",
 	},
+	{
+		I2C_BOARD_INFO("f75375", 0x2e),
+		.type = "f75375",
+		.platform_data = &n2100_f75375s,
+	},
 };
 
 /*

arch/arm/mach-ixp4xx/common.c

@@ -442,7 +442,8 @@ static int ixp4xx_set_next_event(unsigned long evt,
 static void ixp4xx_set_mode(enum clock_event_mode mode,
 			    struct clock_event_device *evt)
 {
-	unsigned long opts, osrt = *IXP4XX_OSRT1 & ~IXP4XX_OST_RELOAD_MASK;
+	unsigned long opts = *IXP4XX_OSRT1 & IXP4XX_OST_RELOAD_MASK;
+	unsigned long osrt = *IXP4XX_OSRT1 & ~IXP4XX_OST_RELOAD_MASK;
 
 	switch (mode) {
 	case CLOCK_EVT_MODE_PERIODIC:
@@ -455,12 +456,15 @@ static void ixp4xx_set_mode(enum clock_event_mode mode,
 		opts = IXP4XX_OST_ENABLE | IXP4XX_OST_ONE_SHOT;
 		break;
 	case CLOCK_EVT_MODE_SHUTDOWN:
+		opts &= ~IXP4XX_OST_ENABLE;
+		break;
+	case CLOCK_EVT_MODE_RESUME:
+		opts |= IXP4XX_OST_ENABLE;
+		break;
 	case CLOCK_EVT_MODE_UNUSED:
 	default:
 		osrt = opts = 0;
 		break;
-	case CLOCK_EVT_MODE_RESUME:
-		break;
 	}
 
 	*IXP4XX_OSRT1 = osrt | opts;

arch/arm/mach-netx/xc.c

@@ -190,15 +190,15 @@ struct xc *request_xc(int xcno, struct device *dev)
 		goto exit;
 
 	if (!request_mem_region
-	    (NETX_PA_XPEC(xcno), XPEC_MEM_SIZE, kobject_name(dev->kobj)))
+	    (NETX_PA_XPEC(xcno), XPEC_MEM_SIZE, kobject_name(&dev->kobj)))
 		goto exit_free;
 
 	if (!request_mem_region
-	    (NETX_PA_XMAC(xcno), XMAC_MEM_SIZE, kobject_name(dev->kobj)))
+	    (NETX_PA_XMAC(xcno), XMAC_MEM_SIZE, kobject_name(&dev->kobj)))
 		goto exit_release_1;
 
 	if (!request_mem_region
-	    (SRAM_INTERNAL_PHYS(xcno), SRAM_MEM_SIZE, kobject_name(dev->kobj)))
+	    (SRAM_INTERNAL_PHYS(xcno), SRAM_MEM_SIZE, kobject_name(&dev->kobj)))
 		goto exit_release_2;
 
 	x->xpec_base = (void * __iomem)io_p2v(NETX_PA_XPEC(xcno));

arch/arm/mach-omap1/board-fsample.c

@@ -40,31 +40,29 @@ static int fsample_keymap[] = {
 	KEY(0,1,KEY_RIGHT),
 	KEY(0,2,KEY_LEFT),
 	KEY(0,3,KEY_DOWN),
-	KEY(0,4,KEY_CENTER),
-	KEY(0,5,KEY_0_5),
-	KEY(1,0,KEY_SOFT2),
+	KEY(0,4,KEY_ENTER),
+	KEY(1,0,KEY_F10),
 	KEY(1,1,KEY_SEND),
 	KEY(1,2,KEY_END),
 	KEY(1,3,KEY_VOLUMEDOWN),
 	KEY(1,4,KEY_VOLUMEUP),
 	KEY(1,5,KEY_RECORD),
-	KEY(2,0,KEY_SOFT1),
+	KEY(2,0,KEY_F9),
 	KEY(2,1,KEY_3),
 	KEY(2,2,KEY_6),
 	KEY(2,3,KEY_9),
-	KEY(2,4,KEY_SHARP),
-	KEY(2,5,KEY_2_5),
+	KEY(2,4,KEY_KPDOT),
 	KEY(3,0,KEY_BACK),
 	KEY(3,1,KEY_2),
 	KEY(3,2,KEY_5),
 	KEY(3,3,KEY_8),
 	KEY(3,4,KEY_0),
-	KEY(3,5,KEY_HEADSETHOOK),
+	KEY(3,5,KEY_KPSLASH),
 	KEY(4,0,KEY_HOME),
 	KEY(4,1,KEY_1),
 	KEY(4,2,KEY_4),
 	KEY(4,3,KEY_7),
-	KEY(4,4,KEY_STAR),
+	KEY(4,4,KEY_KPASTERISK),
 	KEY(4,5,KEY_POWER),
 	0
 };

arch/arm/mach-omap1/board-nokia770.c

@@ -36,8 +36,6 @@
 #include <asm/arch/omapfb.h>
 #include <asm/arch/lcd_mipid.h>
 
-#include "../plat-omap/dsp/dsp_common.h"
-
 #define ADS7846_PENDOWN_GPIO	15
 
 static void __init omap_nokia770_init_irq(void)
@@ -318,6 +316,8 @@ static __init int omap_dsp_init(void)
  out:
 	return ret;
 }
+#else
+#define omap_dsp_init()		do {} while (0)
 #endif	/* CONFIG_OMAP_DSP */
 
 static void __init omap_nokia770_init(void)

arch/arm/mach-omap1/board-perseus2.c

@@ -39,31 +39,29 @@ static int p2_keymap[] = {
 	KEY(0,1,KEY_RIGHT),
 	KEY(0,2,KEY_LEFT),
 	KEY(0,3,KEY_DOWN),
-	KEY(0,4,KEY_CENTER),
-	KEY(0,5,KEY_0_5),
-	KEY(1,0,KEY_SOFT2),
+	KEY(0,4,KEY_ENTER),
+	KEY(1,0,KEY_F10),
 	KEY(1,1,KEY_SEND),
 	KEY(1,2,KEY_END),
 	KEY(1,3,KEY_VOLUMEDOWN),
 	KEY(1,4,KEY_VOLUMEUP),
 	KEY(1,5,KEY_RECORD),
-	KEY(2,0,KEY_SOFT1),
+	KEY(2,0,KEY_F9),
 	KEY(2,1,KEY_3),
 	KEY(2,2,KEY_6),
 	KEY(2,3,KEY_9),
-	KEY(2,4,KEY_SHARP),
-	KEY(2,5,KEY_2_5),
+	KEY(2,4,KEY_KPDOT),
 	KEY(3,0,KEY_BACK),
 	KEY(3,1,KEY_2),
 	KEY(3,2,KEY_5),
 	KEY(3,3,KEY_8),
 	KEY(3,4,KEY_0),
-	KEY(3,5,KEY_HEADSETHOOK),
+	KEY(3,5,KEY_KPSLASH),
 	KEY(4,0,KEY_HOME),
 	KEY(4,1,KEY_1),
 	KEY(4,2,KEY_4),
 	KEY(4,3,KEY_7),
-	KEY(4,4,KEY_STAR),
+	KEY(4,4,KEY_KPASTERISK),
 	KEY(4,5,KEY_POWER),
 	0
 };

arch/arm/mach-pxa/cm-x270-pci.c

@@ -40,7 +40,7 @@ void __init cmx270_pci_adjust_zones(int node, unsigned long *zone_size,
 {
 	unsigned int sz = SZ_64M >> PAGE_SHIFT;
 
-	printk(KERN_INFO "Adjusting zones for CM-x270\n");
+	pr_info("Adjusting zones for CM-x270\n");
 
 	/*
 	 * Only adjust if > 64M on current system
@@ -104,8 +104,7 @@ static int __init cmx270_pci_map_irq(struct pci_dev *dev, u8 slot, u8 pin)
 {
 	int irq;
 
-	printk(KERN_DEBUG "===> %s: %s slot=%x, pin=%x\n", __FUNCTION__,
-	       pci_name(dev), slot, pin);
+	dev_dbg(&dev->dev, "%s: slot=%x, pin=%x\n", __FUNCTION__, slot, pin);
 
 	irq = it8152_pci_map_irq(dev, slot, pin);
 	if (irq)
@@ -141,14 +140,13 @@ static int __init cmx270_pci_map_irq(struct pci_dev *dev, u8 slot, u8 pin)
 	return(0);
 }
 
-static struct pci_bus * __init
-cmx270_pci_scan_bus(int nr, struct pci_sys_data *sys)
+static void cmx270_pci_preinit(void)
 {
-	printk(KERN_INFO "Initializing CM-X270 PCI subsystem\n");
+	pr_info("Initializing CM-X270 PCI subsystem\n");
 
 	__raw_writel(0x800, IT8152_PCI_CFG_ADDR);
 	if (__raw_readl(IT8152_PCI_CFG_DATA) == 0x81521283) {
-		printk(KERN_INFO "PCI Bridge found.\n");
+		pr_info("PCI Bridge found.\n");
 
 		/* set PCI I/O base at 0 */
 		writel(0x848, IT8152_PCI_CFG_ADDR);
@@ -163,7 +161,7 @@ cmx270_pci_scan_bus(int nr, struct pci_sys_data *sys)
 		/* CardBus Controller on ATXbase baseboard */
 		writel(0x4000, IT8152_PCI_CFG_ADDR);
 		if (readl(IT8152_PCI_CFG_DATA) == 0xAC51104C) {
-			printk(KERN_INFO "CardBus Bridge found.\n");
+			pr_info("CardBus Bridge found.\n");
 
 			/* Configure socket 0 */
 			writel(0x408C, IT8152_PCI_CFG_ADDR);
@@ -196,7 +194,6 @@ cmx270_pci_scan_bus(int nr, struct pci_sys_data *sys)
 			writel(0xb0000000, IT8152_PCI_CFG_DATA);
 		}
 	}
-	return it8152_pci_scan_bus(nr, sys);
 }
 
 static struct hw_pci cmx270_pci __initdata = {
@@ -204,7 +201,8 @@ static struct hw_pci cmx270_pci __initdata = {
 	.map_irq	= cmx270_pci_map_irq,
 	.nr_controllers	= 1,
 	.setup		= it8152_pci_setup,
-	.scan		= cmx270_pci_scan_bus,
+	.scan		= it8152_pci_scan_bus,
+	.preinit	= cmx270_pci_preinit,
 };
 
 static int __init cmx270_init_pci(void)

arch/arm/mach-pxa/pxa25x.c

@@ -178,13 +178,19 @@ static void pxa25x_cpu_pm_save(unsigned long *sleep_save)
 	SAVE(GAFR1_L); SAVE(GAFR1_U);
 	SAVE(GAFR2_L); SAVE(GAFR2_U);
 
-	SAVE(ICMR);
+	SAVE(ICMR); ICMR = 0;
 	SAVE(CKEN);
 	SAVE(PSTR);
+
+	/* Clear GPIO transition detect bits */
+	GEDR0 = GEDR0; GEDR1 = GEDR1; GEDR2 = GEDR2;
 }
 
 static void pxa25x_cpu_pm_restore(unsigned long *sleep_save)
 {
+	/* ensure not to come back here if it wasn't intended */
+	PSPR = 0;
+
 	/* restore registers */
 	RESTORE_GPLEVEL(0); RESTORE_GPLEVEL(1); RESTORE_GPLEVEL(2);
 	RESTORE(GPDR0); RESTORE(GPDR1); RESTORE(GPDR2);
@@ -195,7 +201,12 @@ static void pxa25x_cpu_pm_restore(unsigned long *sleep_save)
 	RESTORE(GFER0); RESTORE(GFER1); RESTORE(GFER2);
 	RESTORE(PGSR0); RESTORE(PGSR1); RESTORE(PGSR2);
 
+	PSSR = PSSR_RDH | PSSR_PH;
+
 	RESTORE(CKEN);
+
+	ICLR = 0;
+	ICCR = 1;
 	RESTORE(ICMR);
 	RESTORE(PSTR);
 }

arch/arm/mach-pxa/pxa27x.c

@@ -146,7 +146,7 @@ static struct clk pxa27x_clks[] = {
 	INIT_CKEN("MMCCLK",  MMC,  19500000, 0, &pxa_device_mci.dev),
 	INIT_CKEN("FICPCLK", FICP, 48000000, 0, &pxa_device_ficp.dev),
 
-	INIT_CKEN("USBCLK", USB,    48000000, 0, &pxa27x_device_ohci.dev),
+	INIT_CKEN("USBCLK", USBHOST, 48000000, 0, &pxa27x_device_ohci.dev),
 	INIT_CKEN("I2CCLK", PWRI2C, 13000000, 0, &pxa27x_device_i2c_power.dev),
 	INIT_CKEN("KBDCLK", KEYPAD, 32768, 0, NULL),
 

arch/arm/mach-pxa/pxa320.c

@@ -23,8 +23,11 @@
 static struct pxa3xx_mfp_addr_map pxa320_mfp_addr_map[] __initdata = {
 
 	MFP_ADDR_X(GPIO0,  GPIO4,   0x0124),
-	MFP_ADDR_X(GPIO5,  GPIO26,  0x028C),
-	MFP_ADDR_X(GPIO27, GPIO62,  0x0400),
+	MFP_ADDR_X(GPIO5,  GPIO9,   0x028C),
+	MFP_ADDR(GPIO10, 0x0458),
+	MFP_ADDR_X(GPIO11, GPIO26,  0x02A0),
+	MFP_ADDR_X(GPIO27, GPIO48,  0x0400),
+	MFP_ADDR_X(GPIO49, GPIO62,  0x045C),
 	MFP_ADDR_X(GPIO63, GPIO73,  0x04B4),
 	MFP_ADDR_X(GPIO74, GPIO98,  0x04F0),
 	MFP_ADDR_X(GPIO99, GPIO127, 0x0600),

arch/arm/mach-pxa/pxa3xx.c

@@ -150,22 +150,45 @@ static void clk_pxa3xx_cken_disable(struct clk *clk)
 	local_irq_enable();
 }
 
+static const struct clkops clk_pxa3xx_cken_ops = {
+	.enable		= clk_pxa3xx_cken_enable,
+	.disable	= clk_pxa3xx_cken_disable,
+};
+
 static const struct clkops clk_pxa3xx_hsio_ops = {
 	.enable		= clk_pxa3xx_cken_enable,
 	.disable	= clk_pxa3xx_cken_disable,
 	.getrate	= clk_pxa3xx_hsio_getrate,
 };
 
+#define PXA3xx_CKEN(_name, _cken, _rate, _delay, _dev)	\
+	{						\
+		.name	= _name,			\
+		.dev	= _dev,				\
+		.ops	= &clk_pxa3xx_cken_ops,		\
+		.rate	= _rate,			\
+		.cken	= CKEN_##_cken,			\
+		.delay	= _delay,			\
+	}
+
+#define PXA3xx_CK(_name, _cken, _ops, _dev)		\
+	{						\
+		.name	= _name,			\
+		.dev	= _dev,				\
+		.ops	= _ops,				\
+		.cken	= CKEN_##_cken,			\
+	}
+
 static struct clk pxa3xx_clks[] = {
-	INIT_CK("LCDCLK", LCD,    &clk_pxa3xx_hsio_ops, &pxa_device_fb.dev),
-	INIT_CK("CAMCLK", CAMERA, &clk_pxa3xx_hsio_ops, NULL),
+	PXA3xx_CK("LCDCLK", LCD,    &clk_pxa3xx_hsio_ops, &pxa_device_fb.dev),
+	PXA3xx_CK("CAMCLK", CAMERA, &clk_pxa3xx_hsio_ops, NULL),
 
-	INIT_CKEN("UARTCLK", FFUART, 14857000, 1, &pxa_device_ffuart.dev),
-	INIT_CKEN("UARTCLK", BTUART, 14857000, 1, &pxa_device_btuart.dev),
-	INIT_CKEN("UARTCLK", STUART, 14857000, 1, NULL),
+	PXA3xx_CKEN("UARTCLK", FFUART, 14857000, 1, &pxa_device_ffuart.dev),
+	PXA3xx_CKEN("UARTCLK", BTUART, 14857000, 1, &pxa_device_btuart.dev),
+	PXA3xx_CKEN("UARTCLK", STUART, 14857000, 1, NULL),
 
-	INIT_CKEN("I2CCLK",  I2C,  32842000, 0, &pxa_device_i2c.dev),
-	INIT_CKEN("UDCCLK",  UDC,  48000000, 5, &pxa_device_udc.dev),
+	PXA3xx_CKEN("I2CCLK", I2C,  32842000, 0, &pxa_device_i2c.dev),
+	PXA3xx_CKEN("UDCCLK", UDC,  48000000, 5, &pxa_device_udc.dev),
 };
 
 void __init pxa3xx_init_irq(void)

arch/arm/mach-pxa/sleep.S

@@ -43,11 +43,11 @@ pxa_cpu_save_cp:
 pxa_cpu_save_sp:
 	@ preserve phys address of stack
 	mov	r0, sp
-	mov	r2, lr
+	str	lr, [sp, #-4]!
 	bl	sleep_phys_sp
 	ldr	r1, =sleep_save_sp
 	str	r0, [r1]
-	mov	pc, r2
+	ldr	pc, [sp], #4
 
 /*
  * pxa27x_cpu_suspend()
@@ -270,5 +270,3 @@ resume_after_mmu:
 	mar	acc0, r2, r3
 #endif
 	ldmfd	sp!, {r4 - r12, pc}		@ return to caller
-
-

arch/arm/mach-pxa/ssp.c

@@ -309,6 +309,7 @@ void ssp_exit(struct ssp_dev *dev)
 
     	if (dev->port > PXA_SSP_PORTS || dev->port == 0) {
 		printk(KERN_WARNING "SSP: tried to close invalid port\n");
+		mutex_unlock(&mutex);
 		return;
 	}
 

arch/arm/mach-pxa/time.c

@@ -68,6 +68,7 @@ pxa_ost0_interrupt(int irq, void *dev_id)
 	if (c->mode == CLOCK_EVT_MODE_ONESHOT) {
 		/* Disarm the compare/match, signal the event. */
 		OIER &= ~OIER_E0;
+		OSSR = OSSR_M0;
 		c->event_handler(c);
 	} else if (c->mode == CLOCK_EVT_MODE_PERIODIC) {
 		/* Call the event handler as many times as necessary
@@ -100,9 +101,9 @@ pxa_ost0_interrupt(int irq, void *dev_id)
 		 * anything that might put us "very close".
 	 */
 #define MIN_OSCR_DELTA 16
-	do {
+		do {
 			OSSR = OSSR_M0;
-		next_match = (OSMR0 += LATCH);
+			next_match = (OSMR0 += LATCH);
 			c->event_handler(c);
 		} while (((signed long)(next_match - OSCR) <= MIN_OSCR_DELTA)
 			 && (c->mode == CLOCK_EVT_MODE_PERIODIC));
@@ -114,14 +115,16 @@ pxa_ost0_interrupt(int irq, void *dev_id)
 static int
 pxa_osmr0_set_next_event(unsigned long delta, struct clock_event_device *dev)
 {
-	unsigned long irqflags;
+	unsigned long flags, next, oscr;
 
-	raw_local_irq_save(irqflags);
-	OSMR0 = OSCR + delta;
-	OSSR = OSSR_M0;
+	raw_local_irq_save(flags);
 	OIER |= OIER_E0;
-	raw_local_irq_restore(irqflags);
-	return 0;
+	next = OSCR + delta;
+	OSMR0 = next;
+	oscr = OSCR;
+	raw_local_irq_restore(flags);
+
+	return (signed)(next - oscr) <= MIN_OSCR_DELTA ? -ETIME : 0;
 }
 
 static void
@@ -132,15 +135,16 @@ pxa_osmr0_set_mode(enum clock_event_mode mode, struct clock_event_device *dev)
 	switch (mode) {
 	case CLOCK_EVT_MODE_PERIODIC:
 		raw_local_irq_save(irqflags);
-		OSMR0 = OSCR + LATCH;
 		OSSR = OSSR_M0;
 		OIER |= OIER_E0;
+		OSMR0 = OSCR + LATCH;
 		raw_local_irq_restore(irqflags);
 		break;
 
 	case CLOCK_EVT_MODE_ONESHOT:
 		raw_local_irq_save(irqflags);
 		OIER &= ~OIER_E0;
+		OSSR = OSSR_M0;
 		raw_local_irq_restore(irqflags);
 		break;
 
@@ -149,6 +153,7 @@ pxa_osmr0_set_mode(enum clock_event_mode mode, struct clock_event_device *dev)
 		/* initializing, released, or preparing for suspend */
 		raw_local_irq_save(irqflags);
 		OIER &= ~OIER_E0;
+		OSSR = OSSR_M0;
 		raw_local_irq_restore(irqflags);
 		break;
 

arch/arm/mm/consistent.c

@@ -322,7 +322,6 @@ static int dma_mmap(struct device *dev, struct vm_area_struct *vma,
 
 		if (off < kern_size &&
 		    user_size <= (kern_size - off)) {
-			vma->vm_flags |= VM_RESERVED;
 			ret = remap_pfn_range(vma, vma->vm_start,
 					      page_to_pfn(c->vm_pages) + off,
 					      user_size << PAGE_SHIFT,

arch/arm/plat-omap/fb.c

@@ -171,7 +171,7 @@ static int check_fbmem_region(int region_idx, struct omapfb_mem_region *rg,
  * Called from map_io. We need to call to this early enough so that we
  * can reserve the fixed SDRAM regions before VM could get hold of them.
  */
-void omapfb_reserve_sdram(void)
+void __init omapfb_reserve_sdram(void)
 {
 	struct bootmem_data	*bdata;
 	unsigned long		sdram_start, sdram_size;

arch/arm/vfp/vfp.h

@@ -361,10 +361,12 @@ u32 vfp_estimate_sqrt_significand(u32 exponent, u32 significand);
  *  OP_SCALAR - this operation always operates in scalar mode
  *  OP_SD - the instruction exceptionally writes to a single precision result.
  *  OP_DD - the instruction exceptionally writes to a double precision result.
+ *  OP_SM - the instruction exceptionally reads from a single precision operand.
  */
 #define OP_SCALAR	(1 << 0)
 #define OP_SD		(1 << 1)
 #define OP_DD		(1 << 1)
+#define OP_SM		(1 << 2)
 
 struct op {
 	u32 (* const fn)(int dd, int dn, int dm, u32 fpscr);

arch/arm/vfp/vfpdouble.c

@@ -668,8 +668,8 @@ static struct op fops_ext[32] = {
 	[FEXT_TO_IDX(FEXT_FCMPZ)]	= { vfp_double_fcmpz,  OP_SCALAR },
 	[FEXT_TO_IDX(FEXT_FCMPEZ)]	= { vfp_double_fcmpez, OP_SCALAR },
 	[FEXT_TO_IDX(FEXT_FCVT)]	= { vfp_double_fcvts,  OP_SCALAR|OP_SD },
-	[FEXT_TO_IDX(FEXT_FUITO)]	= { vfp_double_fuito,  OP_SCALAR },
-	[FEXT_TO_IDX(FEXT_FSITO)]	= { vfp_double_fsito,  OP_SCALAR },
+	[FEXT_TO_IDX(FEXT_FUITO)]	= { vfp_double_fuito,  OP_SCALAR|OP_SM },
+	[FEXT_TO_IDX(FEXT_FSITO)]	= { vfp_double_fsito,  OP_SCALAR|OP_SM },
 	[FEXT_TO_IDX(FEXT_FTOUI)]	= { vfp_double_ftoui,  OP_SCALAR|OP_SD },
 	[FEXT_TO_IDX(FEXT_FTOUIZ)]	= { vfp_double_ftouiz, OP_SCALAR|OP_SD },
 	[FEXT_TO_IDX(FEXT_FTOSI)]	= { vfp_double_ftosi,  OP_SCALAR|OP_SD },
@@ -1128,7 +1128,7 @@ u32 vfp_double_cpdo(u32 inst, u32 fpscr)
 	u32 exceptions = 0;
 	unsigned int dest;
 	unsigned int dn = vfp_get_dn(inst);
-	unsigned int dm = vfp_get_dm(inst);
+	unsigned int dm;
 	unsigned int vecitr, veclen, vecstride;
 	struct op *fop;
 
@@ -1145,6 +1145,14 @@ u32 vfp_double_cpdo(u32 inst, u32 fpscr)
 	else
 		dest = vfp_get_dd(inst);
 
+	/*
+	 * f[us]ito takes a sN operand, not a dN operand.
+	 */
+	if (fop->flags & OP_SM)
+		dm = vfp_get_sm(inst);
+	else
+		dm = vfp_get_dm(inst);
+
 	/*
 	 * If destination bank is zero, vector length is always '1'.
 	 * ARM DDI0100F C5.1.3, C5.3.2.

arch/avr32/Kconfig

@@ -6,8 +6,7 @@
 mainmenu "Linux Kernel Configuration"
 
 config AVR32
-	bool
-	default y
+	def_bool y
 	# With EMBEDDED=n, we get lots of stuff automatically selected
 	# that we usually don't need on AVR32.
 	select EMBEDDED
@@ -19,55 +18,50 @@ config AVR32
 	  There is an AVR32 Linux project with a web page at
 	  http://avr32linux.org/.
 
-config UID16
-	bool
-
 config GENERIC_GPIO
-	bool
-	default y
+	def_bool y
 
 config GENERIC_HARDIRQS
-	bool
-	default y
+	def_bool y
+
+config STACKTRACE_SUPPORT
+	def_bool y
+
+config LOCKDEP_SUPPORT
+	def_bool y
+
+config TRACE_IRQFLAGS_SUPPORT
+	def_bool y
 
 config HARDIRQS_SW_RESEND
-	bool
-	default y
+	def_bool y
 
 config GENERIC_IRQ_PROBE
-	bool
-	default y
+	def_bool y
 
 config RWSEM_GENERIC_SPINLOCK
-	bool
-	default y
+	def_bool y
 
 config GENERIC_TIME
-	bool
-	default y
+	def_bool y
 
 config RWSEM_XCHGADD_ALGORITHM
-	bool
+	def_bool n
 
 config ARCH_HAS_ILOG2_U32
-	bool
-	default n
+	def_bool n
 
 config ARCH_HAS_ILOG2_U64
-	bool
-	default n
+	def_bool n
 
 config GENERIC_HWEIGHT
-	bool
-	default y
+	def_bool y
 
 config GENERIC_CALIBRATE_DELAY
-	bool
-	default y
+	def_bool y
 
 config GENERIC_BUG
-	bool
-	default y
+	def_bool y
 	depends on BUG
 
 source "init/Kconfig"
@@ -142,28 +136,22 @@ config PHYS_OFFSET
 source "kernel/Kconfig.preempt"
 
 config HAVE_ARCH_BOOTMEM_NODE
-	bool
-	default n
+	def_bool n
 
 config ARCH_HAVE_MEMORY_PRESENT
-	bool
-	default n
+	def_bool n
 
 config NEED_NODE_MEMMAP_SIZE
-	bool
-	default n
+	def_bool n
 
 config ARCH_FLATMEM_ENABLE
-	bool
-	default y
+	def_bool y
 
 config ARCH_DISCONTIGMEM_ENABLE
-	bool
-	default n
+	def_bool n
 
 config ARCH_SPARSEMEM_ENABLE
-	bool
-	default n
+	def_bool n
 
 source "mm/Kconfig"