diff --git a/[refs] b/[refs] index 37a3bebff08a..1caacabdbe1a 100644 --- a/[refs] +++ b/[refs] @@ -1,2 +1,2 @@ --- -refs/heads/master: 84c48e6f43ae1771fc67fd8fcd777ff4b3b4465b +refs/heads/master: faea56c9bb44f539da1ae0194184873fc2720b20 diff --git a/trunk/Documentation/Changes b/trunk/Documentation/Changes index d21b3b5aa543..b95082be4d5e 100644 --- a/trunk/Documentation/Changes +++ b/trunk/Documentation/Changes @@ -48,7 +48,6 @@ o procps 3.2.0 # ps --version o oprofile 0.9 # oprofiled --version o udev 081 # udevinfo -V o grub 0.93 # grub --version -o mcelog 0.6 Kernel compilation ================== @@ -277,16 +276,6 @@ before running exportfs or mountd. It is recommended that all NFS services be protected from the internet-at-large by a firewall where that is possible. -mcelog ------- - -In Linux 2.6.31+ the i386 kernel needs to run the mcelog utility -as a regular cronjob similar to the x86-64 kernel to process and log -machine check events when CONFIG_X86_NEW_MCE is enabled. Machine check -events are errors reported by the CPU. Processing them is strongly encouraged. -All x86-64 kernels since 2.6.4 require the mcelog utility to -process machine checks. - Getting updated software ======================== @@ -376,10 +365,6 @@ FUSE ---- o -mcelog ------- -o - Networking ********** diff --git a/trunk/Documentation/SubmittingPatches b/trunk/Documentation/SubmittingPatches index 6c456835c1fd..f309d3c6221c 100644 --- a/trunk/Documentation/SubmittingPatches +++ b/trunk/Documentation/SubmittingPatches @@ -91,10 +91,6 @@ Be as specific as possible. The WORST descriptions possible include things like "update driver X", "bug fix for driver X", or "this patch includes updates for subsystem X. Please apply." -The maintainer will thank you if you write your patch description in a -form which can be easily pulled into Linux's source code management -system, git, as a "commit log". See #15, below. - If your description starts to get long, that's a sign that you probably need to split up your patch. See #3, next. @@ -409,14 +405,7 @@ person it names. This tag documents that potentially interested parties have been included in the discussion -14) Using Reported-by:, Tested-by: and Reviewed-by: - -If this patch fixes a problem reported by somebody else, consider adding a -Reported-by: tag to credit the reporter for their contribution. Please -note that this tag should not be added without the reporter's permission, -especially if the problem was not reported in a public forum. That said, -if we diligently credit our bug reporters, they will, hopefully, be -inspired to help us again in the future. +14) Using Tested-by: and Reviewed-by: A Tested-by: tag indicates that the patch has been successfully tested (in some environment) by the person named. This tag informs maintainers that @@ -455,7 +444,7 @@ offer a Reviewed-by tag for a patch. This tag serves to give credit to reviewers and to inform maintainers of the degree of review which has been done on the patch. Reviewed-by: tags, when supplied by reviewers known to understand the subject area and to perform thorough reviews, will normally -increase the likelihood of your patch getting into the kernel. +increase the liklihood of your patch getting into the kernel. 15) The canonical patch format @@ -496,33 +485,12 @@ phrase" should not be a filename. Do not use the same "summary phrase" for every patch in a whole patch series (where a "patch series" is an ordered sequence of multiple, related patches). -Bear in mind that the "summary phrase" of your email becomes a -globally-unique identifier for that patch. It propagates all the way -into the git changelog. The "summary phrase" may later be used in -developer discussions which refer to the patch. People will want to -google for the "summary phrase" to read discussion regarding that -patch. It will also be the only thing that people may quickly see -when, two or three months later, they are going through perhaps -thousands of patches using tools such as "gitk" or "git log ---oneline". - -For these reasons, the "summary" must be no more than 70-75 -characters, and it must describe both what the patch changes, as well -as why the patch might be necessary. It is challenging to be both -succinct and descriptive, but that is what a well-written summary -should do. - -The "summary phrase" may be prefixed by tags enclosed in square -brackets: "Subject: [PATCH tag] ". The tags are not -considered part of the summary phrase, but describe how the patch -should be treated. Common tags might include a version descriptor if -the multiple versions of the patch have been sent out in response to -comments (i.e., "v1, v2, v3"), or "RFC" to indicate a request for -comments. If there are four patches in a patch series the individual -patches may be numbered like this: 1/4, 2/4, 3/4, 4/4. This assures -that developers understand the order in which the patches should be -applied and that they have reviewed or applied all of the patches in -the patch series. +Bear in mind that the "summary phrase" of your email becomes +a globally-unique identifier for that patch. It propagates +all the way into the git changelog. The "summary phrase" may +later be used in developer discussions which refer to the patch. +People will want to google for the "summary phrase" to read +discussion regarding that patch. A couple of example Subjects: @@ -542,31 +510,19 @@ the patch author in the changelog. The explanation body will be committed to the permanent source changelog, so should make sense to a competent reader who has long since forgotten the immediate details of the discussion that might -have led to this patch. Including symptoms of the failure which the -patch addresses (kernel log messages, oops messages, etc.) is -especially useful for people who might be searching the commit logs -looking for the applicable patch. If a patch fixes a compile failure, -it may not be necessary to include _all_ of the compile failures; just -enough that it is likely that someone searching for the patch can find -it. As in the "summary phrase", it is important to be both succinct as -well as descriptive. +have led to this patch. The "---" marker line serves the essential purpose of marking for patch handling tools where the changelog message ends. One good use for the additional comments after the "---" marker is for -a diffstat, to show what files have changed, and the number of -inserted and deleted lines per file. A diffstat is especially useful -on bigger patches. Other comments relevant only to the moment or the -maintainer, not suitable for the permanent changelog, should also go -here. A good example of such comments might be "patch changelogs" -which describe what has changed between the v1 and v2 version of the -patch. - -If you are going to include a diffstat after the "---" marker, please -use diffstat options "-p 1 -w 70" so that filenames are listed from -the top of the kernel source tree and don't use too much horizontal -space (easily fit in 80 columns, maybe with some indentation). +a diffstat, to show what files have changed, and the number of inserted +and deleted lines per file. A diffstat is especially useful on bigger +patches. Other comments relevant only to the moment or the maintainer, +not suitable for the permanent changelog, should also go here. +Use diffstat options "-p 1 -w 70" so that filenames are listed from the +top of the kernel source tree and don't use too much horizontal space +(easily fit in 80 columns, maybe with some indentation). See more details on the proper patch format in the following references. diff --git a/trunk/Documentation/development-process/5.Posting b/trunk/Documentation/development-process/5.Posting index f622c1e9f0f9..dd48132a74dd 100644 --- a/trunk/Documentation/development-process/5.Posting +++ b/trunk/Documentation/development-process/5.Posting @@ -119,7 +119,7 @@ which takes quite a bit of time and thought after the "real work" has been done. When done properly, though, it is time well spent. -5.4: PATCH FORMATTING AND CHANGELOGS +5.4: PATCH FORMATTING So now you have a perfect series of patches for posting, but the work is not done quite yet. Each patch needs to be formatted into a message which @@ -146,33 +146,8 @@ that end, each patch will be composed of the following: - One or more tag lines, with, at a minimum, one Signed-off-by: line from the author of the patch. Tags will be described in more detail below. -The items above, together, form the changelog for the patch. Writing good -changelogs is a crucial but often-neglected art; it's worth spending -another moment discussing this issue. When writing a changelog, you should -bear in mind that a number of different people will be reading your words. -These include subsystem maintainers and reviewers who need to decide -whether the patch should be included, distributors and other maintainers -trying to decide whether a patch should be backported to other kernels, bug -hunters wondering whether the patch is responsible for a problem they are -chasing, users who want to know how the kernel has changed, and more. A -good changelog conveys the needed information to all of these people in the -most direct and concise way possible. - -To that end, the summary line should describe the effects of and motivation -for the change as well as possible given the one-line constraint. The -detailed description can then amplify on those topics and provide any -needed additional information. If the patch fixes a bug, cite the commit -which introduced the bug if possible. If a problem is associated with -specific log or compiler output, include that output to help others -searching for a solution to the same problem. If the change is meant to -support other changes coming in later patch, say so. If internal APIs are -changed, detail those changes and how other developers should respond. In -general, the more you can put yourself into the shoes of everybody who will -be reading your changelog, the better that changelog (and the kernel as a -whole) will be. - -Needless to say, the changelog should be the text used when committing the -change to a revision control system. It will be followed by: +The above three items should, normally, be the text used when committing +the change to a revision control system. They are followed by: - The patch itself, in the unified ("-u") patch format. Using the "-p" option to diff will associate function names with changes, making the diff --git a/trunk/Documentation/feature-removal-schedule.txt b/trunk/Documentation/feature-removal-schedule.txt index ec9ef5d0d7b3..de491a3e2313 100644 --- a/trunk/Documentation/feature-removal-schedule.txt +++ b/trunk/Documentation/feature-removal-schedule.txt @@ -437,13 +437,3 @@ Why: Superseded by tdfxfb. I2C/DDC support used to live in a separate driver but this caused driver conflicts. Who: Jean Delvare Krzysztof Helt - ----------------------------- - -What: CONFIG_X86_OLD_MCE -When: 2.6.32 -Why: Remove the old legacy 32bit machine check code. This has been - superseded by the newer machine check code from the 64bit port, - but the old version has been kept around for easier testing. Note this - doesn't impact the old P5 and WinChip machine check handlers. -Who: Andi Kleen diff --git a/trunk/Documentation/filesystems/debugfs.txt b/trunk/Documentation/filesystems/debugfs.txt deleted file mode 100644 index ed52af60c2d8..000000000000 --- a/trunk/Documentation/filesystems/debugfs.txt +++ /dev/null @@ -1,158 +0,0 @@ -Copyright 2009 Jonathan Corbet - -Debugfs exists as a simple way for kernel developers to make information -available to user space. Unlike /proc, which is only meant for information -about a process, or sysfs, which has strict one-value-per-file rules, -debugfs has no rules at all. Developers can put any information they want -there. The debugfs filesystem is also intended to not serve as a stable -ABI to user space; in theory, there are no stability constraints placed on -files exported there. The real world is not always so simple, though [1]; -even debugfs interfaces are best designed with the idea that they will need -to be maintained forever. - -Debugfs is typically mounted with a command like: - - mount -t debugfs none /sys/kernel/debug - -(Or an equivalent /etc/fstab line). - -Note that the debugfs API is exported GPL-only to modules. - -Code using debugfs should include . Then, the first order -of business will be to create at least one directory to hold a set of -debugfs files: - - struct dentry *debugfs_create_dir(const char *name, struct dentry *parent); - -This call, if successful, will make a directory called name underneath the -indicated parent directory. If parent is NULL, the directory will be -created in the debugfs root. On success, the return value is a struct -dentry pointer which can be used to create files in the directory (and to -clean it up at the end). A NULL return value indicates that something went -wrong. If ERR_PTR(-ENODEV) is returned, that is an indication that the -kernel has been built without debugfs support and none of the functions -described below will work. - -The most general way to create a file within a debugfs directory is with: - - struct dentry *debugfs_create_file(const char *name, mode_t mode, - struct dentry *parent, void *data, - const struct file_operations *fops); - -Here, name is the name of the file to create, mode describes the access -permissions the file should have, parent indicates the directory which -should hold the file, data will be stored in the i_private field of the -resulting inode structure, and fops is a set of file operations which -implement the file's behavior. At a minimum, the read() and/or write() -operations should be provided; others can be included as needed. Again, -the return value will be a dentry pointer to the created file, NULL for -error, or ERR_PTR(-ENODEV) if debugfs support is missing. - -In a number of cases, the creation of a set of file operations is not -actually necessary; the debugfs code provides a number of helper functions -for simple situations. Files containing a single integer value can be -created with any of: - - struct dentry *debugfs_create_u8(const char *name, mode_t mode, - struct dentry *parent, u8 *value); - struct dentry *debugfs_create_u16(const char *name, mode_t mode, - struct dentry *parent, u16 *value); - struct dentry *debugfs_create_u32(const char *name, mode_t mode, - struct dentry *parent, u32 *value); - struct dentry *debugfs_create_u64(const char *name, mode_t mode, - struct dentry *parent, u64 *value); - -These files support both reading and writing the given value; if a specific -file should not be written to, simply set the mode bits accordingly. The -values in these files are in decimal; if hexadecimal is more appropriate, -the following functions can be used instead: - - struct dentry *debugfs_create_x8(const char *name, mode_t mode, - struct dentry *parent, u8 *value); - struct dentry *debugfs_create_x16(const char *name, mode_t mode, - struct dentry *parent, u16 *value); - struct dentry *debugfs_create_x32(const char *name, mode_t mode, - struct dentry *parent, u32 *value); - -Note that there is no debugfs_create_x64(). - -These functions are useful as long as the developer knows the size of the -value to be exported. Some types can have different widths on different -architectures, though, complicating the situation somewhat. There is a -function meant to help out in one special case: - - struct dentry *debugfs_create_size_t(const char *name, mode_t mode, - struct dentry *parent, - size_t *value); - -As might be expected, this function will create a debugfs file to represent -a variable of type size_t. - -Boolean values can be placed in debugfs with: - - struct dentry *debugfs_create_bool(const char *name, mode_t mode, - struct dentry *parent, u32 *value); - -A read on the resulting file will yield either Y (for non-zero values) or -N, followed by a newline. If written to, it will accept either upper- or -lower-case values, or 1 or 0. Any other input will be silently ignored. - -Finally, a block of arbitrary binary data can be exported with: - - struct debugfs_blob_wrapper { - void *data; - unsigned long size; - }; - - struct dentry *debugfs_create_blob(const char *name, mode_t mode, - struct dentry *parent, - struct debugfs_blob_wrapper *blob); - -A read of this file will return the data pointed to by the -debugfs_blob_wrapper structure. Some drivers use "blobs" as a simple way -to return several lines of (static) formatted text output. This function -can be used to export binary information, but there does not appear to be -any code which does so in the mainline. Note that all files created with -debugfs_create_blob() are read-only. - -There are a couple of other directory-oriented helper functions: - - struct dentry *debugfs_rename(struct dentry *old_dir, - struct dentry *old_dentry, - struct dentry *new_dir, - const char *new_name); - - struct dentry *debugfs_create_symlink(const char *name, - struct dentry *parent, - const char *target); - -A call to debugfs_rename() will give a new name to an existing debugfs -file, possibly in a different directory. The new_name must not exist prior -to the call; the return value is old_dentry with updated information. -Symbolic links can be created with debugfs_create_symlink(). - -There is one important thing that all debugfs users must take into account: -there is no automatic cleanup of any directories created in debugfs. If a -module is unloaded without explicitly removing debugfs entries, the result -will be a lot of stale pointers and no end of highly antisocial behavior. -So all debugfs users - at least those which can be built as modules - must -be prepared to remove all files and directories they create there. A file -can be removed with: - - void debugfs_remove(struct dentry *dentry); - -The dentry value can be NULL, in which case nothing will be removed. - -Once upon a time, debugfs users were required to remember the dentry -pointer for every debugfs file they created so that all files could be -cleaned up. We live in more civilized times now, though, and debugfs users -can call: - - void debugfs_remove_recursive(struct dentry *dentry); - -If this function is passed a pointer for the dentry corresponding to the -top-level directory, the entire hierarchy below that directory will be -removed. - -Notes: - [1] http://lwn.net/Articles/309298/ diff --git a/trunk/Documentation/i2c/busses/i2c-ocores b/trunk/Documentation/i2c/busses/i2c-ocores index c269aaa2f26a..cfcebb10d14e 100644 --- a/trunk/Documentation/i2c/busses/i2c-ocores +++ b/trunk/Documentation/i2c/busses/i2c-ocores @@ -20,8 +20,6 @@ platform_device with the base address and interrupt number. The dev.platform_data of the device should also point to a struct ocores_i2c_platform_data (see linux/i2c-ocores.h) describing the distance between registers and the input clock speed. -There is also a possibility to attach a list of i2c_board_info which -the i2c-ocores driver will add to the bus upon creation. E.G. something like: @@ -38,24 +36,9 @@ static struct resource ocores_resources[] = { }, }; -/* optional board info */ -struct i2c_board_info ocores_i2c_board_info[] = { - { - I2C_BOARD_INFO("tsc2003", 0x48), - .platform_data = &tsc2003_platform_data, - .irq = TSC_IRQ - }, - { - I2C_BOARD_INFO("adv7180", 0x42 >> 1), - .irq = ADV_IRQ - } -}; - static struct ocores_i2c_platform_data myi2c_data = { .regstep = 2, /* two bytes between registers */ .clock_khz = 50000, /* input clock of 50MHz */ - .devices = ocores_i2c_board_info, /* optional table of devices */ - .num_devices = ARRAY_SIZE(ocores_i2c_board_info), /* table size */ }; static struct platform_device myi2c = { diff --git a/trunk/Documentation/x86/x86_64/boot-options.txt b/trunk/Documentation/x86/x86_64/boot-options.txt index 29a6ff8bc7d3..2db5893d6c97 100644 --- a/trunk/Documentation/x86/x86_64/boot-options.txt +++ b/trunk/Documentation/x86/x86_64/boot-options.txt @@ -5,51 +5,21 @@ only the AMD64 specific ones are listed here. Machine check - Please see Documentation/x86/x86_64/machinecheck for sysfs runtime tunables. - - mce=off - Disable machine check - mce=no_cmci - Disable CMCI(Corrected Machine Check Interrupt) that - Intel processor supports. Usually this disablement is - not recommended, but it might be handy if your hardware - is misbehaving. - Note that you'll get more problems without CMCI than with - due to the shared banks, i.e. you might get duplicated - error logs. - mce=dont_log_ce - Don't make logs for corrected errors. All events reported - as corrected are silently cleared by OS. - This option will be useful if you have no interest in any - of corrected errors. - mce=ignore_ce - Disable features for corrected errors, e.g. polling timer - and CMCI. All events reported as corrected are not cleared - by OS and remained in its error banks. - Usually this disablement is not recommended, however if - there is an agent checking/clearing corrected errors - (e.g. BIOS or hardware monitoring applications), conflicting - with OS's error handling, and you cannot deactivate the agent, - then this option will be a help. - mce=bootlog - Enable logging of machine checks left over from booting. - Disabled by default on AMD because some BIOS leave bogus ones. - If your BIOS doesn't do that it's a good idea to enable though - to make sure you log even machine check events that result - in a reboot. On Intel systems it is enabled by default. + mce=off disable machine check + mce=bootlog Enable logging of machine checks left over from booting. + Disabled by default on AMD because some BIOS leave bogus ones. + If your BIOS doesn't do that it's a good idea to enable though + to make sure you log even machine check events that result + in a reboot. On Intel systems it is enabled by default. mce=nobootlog Disable boot machine check logging. - mce=tolerancelevel[,monarchtimeout] (number,number) - tolerance levels: + mce=tolerancelevel (number) 0: always panic on uncorrected errors, log corrected errors 1: panic or SIGBUS on uncorrected errors, log corrected errors 2: SIGBUS or log uncorrected errors, log corrected errors 3: never panic or SIGBUS, log all errors (for testing only) Default is 1 Can be also set using sysfs which is preferable. - monarchtimeout: - Sets the time in us to wait for other CPUs on machine checks. 0 - to disable. nomce (for compatibility with i386): same as mce=off diff --git a/trunk/Documentation/x86/x86_64/machinecheck b/trunk/Documentation/x86/x86_64/machinecheck index b1fb30273286..a05e58e7b159 100644 --- a/trunk/Documentation/x86/x86_64/machinecheck +++ b/trunk/Documentation/x86/x86_64/machinecheck @@ -41,9 +41,7 @@ check_interval the polling interval. When the poller stops finding MCEs, it triggers an exponential backoff (poll less often) on the polling interval. The check_interval variable is both the initial and - maximum polling interval. 0 means no polling for corrected machine - check errors (but some corrected errors might be still reported - in other ways) + maximum polling interval. tolerant Tolerance level. When a machine check exception occurs for a non @@ -69,10 +67,6 @@ trigger Program to run when a machine check event is detected. This is an alternative to running mcelog regularly from cron and allows to detect events faster. -monarch_timeout - How long to wait for the other CPUs to machine check too on a - exception. 0 to disable waiting for other CPUs. - Unit: us TBD document entries for AMD threshold interrupt configuration diff --git a/trunk/arch/avr32/boards/atngw100/Kconfig b/trunk/arch/avr32/boards/atngw100/Kconfig index be27a0218ab4..b3f99477bbeb 100644 --- a/trunk/arch/avr32/boards/atngw100/Kconfig +++ b/trunk/arch/avr32/boards/atngw100/Kconfig @@ -2,15 +2,8 @@ if BOARD_ATNGW100 -choice - prompt "Select an NGW100 add-on board to support" - default BOARD_ATNGW100_ADDON_NONE - -config BOARD_ATNGW100_ADDON_NONE - bool "None" - config BOARD_ATNGW100_EVKLCD10X - bool "EVKLCD10X addon board" + bool "Add support for EVKLCD10X addon board" help This enables support for the EVKLCD100 (QVGA) or EVKLCD101 (VGA) addon board for the NGW100. By enabling this the LCD controller and @@ -21,19 +14,7 @@ config BOARD_ATNGW100_EVKLCD10X The MCI pins can be reenabled by editing the "add device function" but this may break the setup for other displays that use these pins. -config BOARD_ATNGW100_MRMT - bool "Mediama RMT1/2 add-on board" - help - This enables support for the Mediama RMT1 or RMT2 board. - RMT provides LCD support, AC97 codec and other - optional peripherals to the Atmel NGW100. - - This choice disables the detect pin and the write-protect pin for the - MCI platform device, since it conflicts with the LCD platform device. - The MCI pins can be reenabled by editing the "add device function" but - this may break the setup for other displays that use these pins. - -endchoice + Choose 'Y' here if you have a EVKLCD100/101 connected to the NGW100. choice prompt "LCD panel resolution on EVKLCD10X" @@ -51,8 +32,4 @@ config BOARD_ATNGW100_EVKLCD10X_POW_QVGA endchoice -if BOARD_ATNGW100_MRMT -source "arch/avr32/boards/atngw100/Kconfig_mrmt" -endif - endif # BOARD_ATNGW100 diff --git a/trunk/arch/avr32/boards/atngw100/Kconfig_mrmt b/trunk/arch/avr32/boards/atngw100/Kconfig_mrmt deleted file mode 100644 index 9a199a207f3c..000000000000 --- a/trunk/arch/avr32/boards/atngw100/Kconfig_mrmt +++ /dev/null @@ -1,80 +0,0 @@ -# RMT for NGW100 customization - -choice - prompt "RMT Version" - help - Select the RMTx board version. - -config BOARD_MRMT_REV1 - bool "RMT1" -config BOARD_MRMT_REV2 - bool "RMT2" - -endchoice - -config BOARD_MRMT_AC97 - bool "Enable AC97 CODEC" - help - Enable the UCB1400 AC97 CODEC driver. - -choice - prompt "Touchscreen Driver" - default BOARD_MRMT_ADS7846_TS - -config BOARD_MRMT_UCB1400_TS - bool "Use UCB1400 Touchscreen" - -config BOARD_MRMT_ADS7846_TS - bool "Use ADS7846 Touchscreen" - -endchoice - -choice - prompt "RMTx LCD Selection" - default BOARD_MRMT_LCD_DISABLE - -config BOARD_MRMT_LCD_DISABLE - bool "LCD Disabled" - -config BOARD_MRMT_LCD_LQ043T3DX0X - bool "Sharp LQ043T3DX0x or compatible" - help - If using RMT2, be sure to load the resistor pack selectors accordingly - -if BOARD_MRMT_REV2 -config BOARD_MRMT_LCD_KWH043GM08 - bool "Formike KWH043GM08 or compatible" - help - Be sure to load the RMT2 resistor pack selectors accordingly -endif - -endchoice - -if !BOARD_MRMT_LCD_DISABLE -config BOARD_MRMT_BL_PWM - bool "Use PWM control for LCD Backlight" - help - Use PWM driver for controlling LCD Backlight. - Otherwise, LCD Backlight is always on. -endif - -config BOARD_MRMT_RTC_I2C - bool "Use External RTC on I2C Bus" - help - RMT1 has an optional RTC device on the I2C bus. - It is a SII S35390A. Be sure to select the - matching RTC driver. - -choice - prompt "Wireless Module on ttyS2" - default BOARD_MRMT_WIRELESS_ZB - -config BOARD_MRMT_WIRELESS_ZB - bool "Use ZigBee/802.15.4 Module" - -config BOARD_MRMT_WIRELESS_BT - bool "Use Bluetooth (HCI) Module" - -config BOARD_MRMT_WIRELESS_NONE - bool "Not Installed" -endchoice diff --git a/trunk/arch/avr32/boards/atngw100/Makefile b/trunk/arch/avr32/boards/atngw100/Makefile index f4ebe42a8254..6376f5322e4d 100644 --- a/trunk/arch/avr32/boards/atngw100/Makefile +++ b/trunk/arch/avr32/boards/atngw100/Makefile @@ -1,3 +1,2 @@ obj-y += setup.o flash.o obj-$(CONFIG_BOARD_ATNGW100_EVKLCD10X) += evklcd10x.o -obj-$(CONFIG_BOARD_ATNGW100_MRMT) += mrmt.o diff --git a/trunk/arch/avr32/boards/atngw100/mrmt.c b/trunk/arch/avr32/boards/atngw100/mrmt.c deleted file mode 100644 index bf78e516a85f..000000000000 --- a/trunk/arch/avr32/boards/atngw100/mrmt.c +++ /dev/null @@ -1,373 +0,0 @@ -/* - * Board-specific setup code for Remote Media Terminal 1 (RMT1) - * add-on board for the ATNGW100 Network Gateway - * - * Copyright (C) 2008 Mediama Technologies - * Based on ATNGW100 Network Gateway (Copyright (C) Atmel) - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - */ -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include