From ed9d6607019bcb577a533adff961cbff1180fe53 Mon Sep 17 00:00:00 2001 From: Tejun Heo Date: Fri, 18 Nov 2005 14:09:05 +0900 Subject: [PATCH] --- yaml --- r: 14417 b: refs/heads/master c: 7d1ce682d08625258524d23ef5eb9e7ae261c1d0 h: refs/heads/master i: 14415: 3b4b8bf5becd08f0736004fc71ed41b329bb1bae v: v3 --- [refs] | 2 +- trunk/Documentation/00-INDEX | 6 - trunk/Documentation/HOWTO | 618 -------------------------------- trunk/MAINTAINERS | 16 - trunk/arch/ia64/kernel/ivt.S | 133 ++++--- trunk/drivers/scsi/sata_sil24.c | 35 +- 6 files changed, 95 insertions(+), 715 deletions(-) delete mode 100644 trunk/Documentation/HOWTO diff --git a/[refs] b/[refs] index 6f57d65e0e96..ec9ccbbe3419 100644 --- a/[refs] +++ b/[refs] @@ -1,2 +1,2 @@ --- -refs/heads/master: 8907e94be2661be940c622232d6ce5ae938f10c3 +refs/heads/master: 7d1ce682d08625258524d23ef5eb9e7ae261c1d0 diff --git a/trunk/Documentation/00-INDEX b/trunk/Documentation/00-INDEX index 5f7f7d7f77d2..433cf5e9ae04 100644 --- a/trunk/Documentation/00-INDEX +++ b/trunk/Documentation/00-INDEX @@ -24,8 +24,6 @@ DMA-mapping.txt - info for PCI drivers using DMA portably across all platforms. DocBook/ - directory with DocBook templates etc. for kernel documentation. -HOWTO - - The process and procedures of how to do Linux kernel development. IO-mapping.txt - how to access I/O mapped memory from within device drivers. IPMI.txt @@ -258,10 +256,6 @@ specialix.txt - info on hardware/driver for specialix IO8+ multiport serial card. spinlocks.txt - info on using spinlocks to provide exclusive access in kernel. -stable_api_nonsense.txt - - info on why the kernel does not have a stable in-kernel api or abi. -stable_kernel_rules.txt - - rules and procedures for the -stable kernel releases. stallion.txt - info on using the Stallion multiport serial driver. svga.txt diff --git a/trunk/Documentation/HOWTO b/trunk/Documentation/HOWTO deleted file mode 100644 index 6c9e746267da..000000000000 --- a/trunk/Documentation/HOWTO +++ /dev/null @@ -1,618 +0,0 @@ -HOWTO do Linux kernel development ---------------------------------- - -This is the be-all, end-all document on this topic. It contains -instructions on how to become a Linux kernel developer and how to learn -to work with the Linux kernel development community. It tries to not -contain anything related to the technical aspects of kernel programming, -but will help point you in the right direction for that. - -If anything in this document becomes out of date, please send in patches -to the maintainer of this file, who is listed at the bottom of the -document. - - -Introduction ------------- - -So, you want to learn how to become a Linux kernel developer? Or you -have been told by your manager, "Go write a Linux driver for this -device." This document's goal is to teach you everything you need to -know to achieve this by describing the process you need to go through, -and hints on how to work with the community. It will also try to -explain some of the reasons why the community works like it does. - -The kernel is written mostly in C, with some architecture-dependent -parts written in assembly. A good understanding of C is required for -kernel development. Assembly (any architecture) is not required unless -you plan to do low-level development for that architecture. Though they -are not a good substitute for a solid C education and/or years of -experience, the following books are good for, if anything, reference: - - "The C Programming Language" by Kernighan and Ritchie [Prentice Hall] - - "Practical C Programming" by Steve Oualline [O'Reilly] - -The kernel is written using GNU C and the GNU toolchain. While it -adheres to the ISO C89 standard, it uses a number of extensions that are -not featured in the standard. The kernel is a freestanding C -environment, with no reliance on the standard C library, so some -portions of the C standard are not supported. Arbitrary long long -divisions and floating point are not allowed. It can sometimes be -difficult to understand the assumptions the kernel has on the toolchain -and the extensions that it uses, and unfortunately there is no -definitive reference for them. Please check the gcc info pages (`info -gcc`) for some information on them. - -Please remember that you are trying to learn how to work with the -existing development community. It is a diverse group of people, with -high standards for coding, style and procedure. These standards have -been created over time based on what they have found to work best for -such a large and geographically dispersed team. Try to learn as much as -possible about these standards ahead of time, as they are well -documented; do not expect people to adapt to you or your company's way -of doing things. - - -Legal Issues ------------- - -The Linux kernel source code is released under the GPL. Please see the -file, COPYING, in the main directory of the source tree, for details on -the license. If you have further questions about the license, please -contact a lawyer, and do not ask on the Linux kernel mailing list. The -people on the mailing lists are not lawyers, and you should not rely on -their statements on legal matters. - -For common questions and answers about the GPL, please see: - http://www.gnu.org/licenses/gpl-faq.html - - -Documentation ------------- - -The Linux kernel source tree has a large range of documents that are -invaluable for learning how to interact with the kernel community. When -new features are added to the kernel, it is recommended that new -documentation files are also added which explain how to use the feature. -When a kernel change causes the interface that the kernel exposes to -userspace to change, it is recommended that you send the information or -a patch to the manual pages explaining the change to the manual pages -maintainer at mtk-manpages@gmx.net. - -Here is a list of files that are in the kernel source tree that are -required reading: - README - This file gives a short background on the Linux kernel and describes - what is necessary to do to configure and build the kernel. People - who are new to the kernel should start here. - - Documentation/Changes - This file gives a list of the minimum levels of various software - packages that are necessary to build and run the kernel - successfully. - - Documentation/CodingStyle - This describes the Linux kernel coding style, and some of the - rationale behind it. All new code is expected to follow the - guidelines in this document. Most maintainers will only accept - patches if these rules are followed, and many people will only - review code if it is in the proper style. - - Documentation/SubmittingPatches - Documentation/SubmittingDrivers - These files describe in explicit detail how to successfully create - and send a patch, including (but not limited to): - - Email contents - - Email format - - Who to send it to - Following these rules will not guarantee success (as all patches are - subject to scrutiny for content and style), but not following them - will almost always prevent it. - - Other excellent descriptions of how to create patches properly are: - "The Perfect Patch" - http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt - "Linux kernel patch submission format" - http://linux.yyz.us/patch-format.html - - Documentation/stable_api_nonsense.txt - This file describes the rationale behind the conscious decision to - not have a stable API within the kernel, including things like: - - Subsystem shim-layers (for compatibility?) - - Driver portability between Operating Systems. - - Mitigating rapid change within the kernel source tree (or - preventing rapid change) - This document is crucial for understanding the Linux development - philosophy and is very important for people moving to Linux from - development on other Operating Systems. - - Documentation/SecurityBugs - If you feel you have found a security problem in the Linux kernel, - please follow the steps in this document to help notify the kernel - developers, and help solve the issue. - - Documentation/ManagementStyle - This document describes how Linux kernel maintainers operate and the - shared ethos behind their methodologies. This is important reading - for anyone new to kernel development (or anyone simply curious about - it), as it resolves a lot of common misconceptions and confusion - about the unique behavior of kernel maintainers. - - Documentation/stable_kernel_rules.txt - This file describes the rules on how the stable kernel releases - happen, and what to do if you want to get a change into one of these - releases. - - Documentation/kernel-docs.txt - A list of external documentation that pertains to kernel - development. Please consult this list if you do not find what you - are looking for within the in-kernel documentation. - - Documentation/applying-patches.txt - A good introduction describing exactly what a patch is and how to - apply it to the different development branches of the kernel. - -The kernel also has a large number of documents that can be -automatically generated from the source code itself. This includes a -full description of the in-kernel API, and rules on how to handle -locking properly. The documents will be created in the -Documentation/DocBook/ directory and can be generated as PDF, -Postscript, HTML, and man pages by running: - make pdfdocs - make psdocs - make htmldocs - make mandocs -respectively from the main kernel source directory. - - -Becoming A Kernel Developer ---------------------------- - -If you do not know anything about Linux kernel development, you should -look at the Linux KernelNewbies project: - http://kernelnewbies.org -It consists of a helpful mailing list where you can ask almost any type -of basic kernel development question (make sure to search the archives -first, before asking something that has already been answered in the -past.) It also has an IRC channel that you can use to ask questions in -real-time, and a lot of helpful documentation that is useful for -learning about Linux kernel development. - -The website has basic information about code organization, subsystems, -and current projects (both in-tree and out-of-tree). It also describes -some basic logistical information, like how to compile a kernel and -apply a patch. - -If you do not know where you want to start, but you want to look for -some task to start doing to join into the kernel development community, -go to the Linux Kernel Janitor's project: - http://janitor.kernelnewbies.org/ -It is a great place to start. It describes a list of relatively simple -problems that need to be cleaned up and fixed within the Linux kernel -source tree. Working with the developers in charge of this project, you -will learn the basics of getting your patch into the Linux kernel tree, -and possibly be pointed in the direction of what to go work on next, if -you do not already have an idea. - -If you already have a chunk of code that you want to put into the kernel -tree, but need some help getting it in the proper form, the -kernel-mentors project was created to help you out with this. It is a -mailing list, and can be found at: - http://selenic.com/mailman/listinfo/kernel-mentors - -Before making any actual modifications to the Linux kernel code, it is -imperative to understand how the code in question works. For this -purpose, nothing is better than reading through it directly (most tricky -bits are commented well), perhaps even with the help of specialized -tools. One such tool that is particularly recommended is the Linux -Cross-Reference project, which is able to present source code in a -self-referential, indexed webpage format. An excellent up-to-date -repository of the kernel code may be found at: - http://sosdg.org/~coywolf/lxr/ - - -The development process ------------------------ - -Linux kernel development process currently consists of a few different -main kernel "branches" and lots of different subsystem-specific kernel -branches. These different branches are: - - main 2.6.x kernel tree - - 2.6.x.y -stable kernel tree - - 2.6.x -git kernel patches - - 2.6.x -mm kernel patches - - subsystem specific kernel trees and patches - -2.6.x kernel tree ------------------ -2.6.x kernels are maintained by Linus Torvalds, and can be found on -kernel.org in the pub/linux/kernel/v2.6/ directory. Its development -process is as follows: - - As soon as a new kernel is released a two weeks window is open, - during this period of time maintainers can submit big diffs to - Linus, usually the patches that have already been included in the - -mm kernel for a few weeks. The preferred way to submit big changes - is using git (the kernel's source management tool, more information - can be found at http://git.or.cz/) but plain patches are also just - fine. - - After two weeks a -rc1 kernel is released it is now possible to push - only patches that do not include new features that could affect the - stability of the whole kernel. Please note that a whole new driver - (or filesystem) might be accepted after -rc1 because there is no - risk of causing regressions with such a change as long as the change - is self-contained and does not affect areas outside of the code that - is being added. git can be used to send patches to Linus after -rc1 - is released, but the patches need to also be sent to a public - mailing list for review. - - A new -rc is released whenever Linus deems the current git tree to - be in a reasonably sane state adequate for testing. The goal is to - release a new -rc kernel every week. - - Process continues until the kernel is considered "ready", the - process should last around 6 weeks. - -It is worth mentioning what Andrew Morton wrote on the linux-kernel -mailing list about kernel releases: - "Nobody knows when a kernel will be released, because it's - released according to perceived bug status, not according to a - preconceived timeline." - -2.6.x.y -stable kernel tree ---------------------------- -Kernels with 4 digit versions are -stable kernels. They contain -relatively small and critical fixes for security problems or significant -regressions discovered in a given 2.6.x kernel. - -This is the recommended branch for users who want the most recent stable -kernel and are not interested in helping test development/experimental -versions. - -If no 2.6.x.y kernel is available, then the highest numbered 2.6.x -kernel is the current stable kernel. - -2.6.x.y are maintained by the "stable" team , and are -released almost every other week. - -The file Documentation/stable_kernel_rules.txt in the kernel tree -documents what kinds of changes are acceptable for the -stable tree, and -how the release process works. - -2.6.x -git patches ------------------- -These are daily snapshots of Linus' kernel tree which are managed in a -git repository (hence the name.) These patches are usually released -daily and represent the current state of Linus' tree. They are more -experimental than -rc kernels since they are generated automatically -without even a cursory glance to see if they are sane. - -2.6.x -mm kernel patches ------------------------- -These are experimental kernel patches released by Andrew Morton. Andrew -takes all of the different subsystem kernel trees and patches and mushes -them together, along with a lot of patches that have been plucked from -the linux-kernel mailing list. This tree serves as a proving ground for -new features and patches. Once a patch has proved its worth in -mm for -a while Andrew or the subsystem maintainer pushes it on to Linus for -inclusion in mainline. - -It is heavily encouraged that all new patches get tested in the -mm tree -before they are sent to Linus for inclusion in the main kernel tree. - -These kernels are not appropriate for use on systems that are supposed -to be stable and they are more risky to run than any of the other -branches. - -If you wish to help out with the kernel development process, please test -and use these kernel releases and provide feedback to the linux-kernel -mailing list if you have any problems, and if everything works properly. - -In addition to all the other experimental patches, these kernels usually -also contain any changes in the mainline -git kernels available at the -time of release. - -The -mm kernels are not released on a fixed schedule, but usually a few --mm kernels are released in between each -rc kernel (1 to 3 is common). - -Subsystem Specific kernel trees and patches -------------------------------------------- -A number of the different kernel subsystem developers expose their -development trees so that others can see what is happening in the -different areas of the kernel. These trees are pulled into the -mm -kernel releases as described above. - -Here is a list of some of the different kernel trees available: - git trees: - - Kbuild development tree, Sam Ravnborg - kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git - - - ACPI development tree, Len Brown - kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git - - - Block development tree, Jens Axboe - kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git - - - DRM development tree, Dave Airlie - kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git - - - ia64 development tree, Tony Luck - kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git - - - ieee1394 development tree, Jody McIntyre - kernel.org:/pub/scm/linux/kernel/git/scjody/ieee1394.git - - - infiniband, Roland Dreier - kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git - - - libata, Jeff Garzik - kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git - - - network drivers, Jeff Garzik - kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git - - - pcmcia, Dominik Brodowski - kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git - - - SCSI, James Bottomley - kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git - - Other git kernel trees can be found listed at http://kernel.org/git - - quilt trees: - - USB, PCI, Driver Core, and I2C, Greg Kroah-Hartman - kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/ - - -Bug Reporting -------------- - -bugzilla.kernel.org is where the Linux kernel developers track kernel -bugs. Users are encouraged to report all bugs that they find in this -tool. For details on how to use the kernel bugzilla, please see: - http://test.kernel.org/bugzilla/faq.html - -The file REPORTING-BUGS in the main kernel source directory has a good -template for how to report a possible kernel bug, and details what kind -of information is needed by the kernel developers to help track down the -problem. - - -Mailing lists -------------- - -As some of the above documents describe, the majority of the core kernel -developers participate on the Linux Kernel Mailing list. Details on how -to subscribe and unsubscribe from the list can be found at: - http://vger.kernel.org/vger-lists.html#linux-kernel -There are archives of the mailing list on the web in many different -places. Use a search engine to find these archives. For example: - http://dir.gmane.org/gmane.linux.kernel -It is highly recommended that you search the archives about the topic -you want to bring up, before you post it to the list. A lot of things -already discussed in detail are only recorded at the mailing list -archives. - -Most of the individual kernel subsystems also have their own separate -mailing list where they do their development efforts. See the -MAINTAINERS file for a list of what these lists are for the different -groups. - -Many of the lists are hosted on kernel.org. Information on them can be -found at: - http://vger.kernel.org/vger-lists.html - -Please remember to follow good behavioral habits when using the lists. -Though a bit cheesy, the following URL has some simple guidelines for -interacting with the list (or any list): - http://www.albion.com/netiquette/ - -If multiple people respond to your mail, the CC: list of recipients may -get pretty large. Don't remove anybody from the CC: list without a good -reason, or don't reply only to the list address. Get used to receiving the -mail twice, one from the sender and the one from the list, and don't try -to tune that by adding fancy mail-headers, people will not like it. - -Remember to keep the context and the attribution of your replies intact, -keep the "John Kernelhacker wrote ...:" lines at the top of your reply, and -add your statements between the individual quoted sections instead of -writing at the top of the mail. - -If you add patches to your mail, make sure they are plain readable text -as stated in Documentation/SubmittingPatches. Kernel developers don't -want to deal with attachments or compressed patches; they may want -to comment on individual lines of your patch, which works only that way. -Make sure you use a mail program that does not mangle spaces and tab -characters. A good first test is to send the mail to yourself and try -to apply your own patch by yourself. If that doesn't work, get your -mail program fixed or change it until it works. - -Above all, please remember to show respect to other subscribers. - - -Working with the community --------------------------- - -The goal of the kernel community is to provide the best possible kernel -there is. When you submit a patch for acceptance, it will be reviewed -on its technical merits and those alone. So, what should you be -expecting? - - criticism - - comments - - requests for change - - requests for justification - - silence - -Remember, this is part of getting your patch into the kernel. You have -to be able to take criticism and comments about your patches, evaluate -them at a technical level and either rework your patches or provide -clear and concise reasoning as to why those changes should not be made. -If there are no responses to your posting, wait a few days and try -again, sometimes things get lost in the huge volume. - -What should you not do? - - expect your patch to be accepted without question - - become defensive - - ignore comments - - resubmit the patch without making any of the requested changes - -In a community that is looking for the best technical solution possible, -there will always be differing opinions on how beneficial a patch is. -You have to be cooperative, and willing to adapt your idea to fit within -the kernel. Or at least be willing to prove your idea is worth it. -Remember, being wrong is acceptable as long as you are willing to work -toward a solution that is right. - -It is normal that the answers to your first patch might simply be a list -of a dozen things you should correct. This does _not_ imply that your -patch will not be accepted, and it is _not_ meant against you -personally. Simply correct all issues raised against your patch and -resend it. - - -Differences between the kernel community and corporate structures ------------------------------------------------------------------ - -The kernel community works differently than most traditional corporate -development environments. Here are a list of things that you can try to -do to try to avoid problems: - Good things to say regarding your proposed changes: - - "This solves multiple problems." - - "This deletes 2000 lines of code." - - "Here is a patch that explains what I am trying to describe." - - "I tested it on 5 different architectures..." - - "Here is a series of small patches that..." - - "This increases performance on typical machines..." - - Bad things you should avoid saying: - - "We did it this way in AIX/ptx/Solaris, so therefore it must be - good..." - - "I've being doing this for 20 years, so..." - - "This is required for my company to make money" - - "This is for our Enterprise product line." - - "Here is my 1000 page design document that describes my idea" - - "I've been working on this for 6 months..." - - "Here's a 5000 line patch that..." - - "I rewrote all of the current mess, and here it is..." - - "I have a deadline, and this patch needs to be applied now." - -Another way the kernel community is different than most traditional -software engineering work environments is the faceless nature of -interaction. One benefit of using email and irc as the primary forms of -communication is the lack of discrimination based on gender or race. -The Linux kernel work environment is accepting of women and minorities -because all you are is an email address. The international aspect also -helps to level the playing field because you can't guess gender based on -a person's name. A man may be named Andrea and a woman may be named Pat. -Most women who have worked in the Linux kernel and have expressed an -opinion have had positive experiences. - -The language barrier can cause problems for some people who are not -comfortable with English. A good grasp of the language can be needed in -order to get ideas across properly on mailing lists, so it is -recommended that you check your emails to make sure they make sense in -English before sending them. - - -Break up your changes ---------------------- - -The Linux kernel community does not gladly accept large chunks of code -dropped on it all at once. The changes need to be properly introduced, -discussed, and broken up into tiny, individual portions. This is almost -the exact opposite of what companies are used to doing. Your proposal -should also be introduced very early in the development process, so that -you can receive feedback on what you are doing. It also lets the -community feel that you are working with them, and not simply using them -as a dumping ground for your feature. However, don't send 50 emails at -one time to a mailing list, your patch series should be smaller than -that almost all of the time. - -The reasons for breaking things up are the following: - -1) Small patches increase the likelihood that your patches will be - applied, since they don't take much time or effort to verify for - correctness. A 5 line patch can be applied by a maintainer with - barely a second glance. However, a 500 line patch may take hours to - review for correctness (the time it takes is exponentially - proportional to the size of the patch, or something). - - Small patches also make it very easy to debug when something goes - wrong. It's much easier to back out patches one by one than it is - to dissect a very large patch after it's been applied (and broken - something). - -2) It's important not only to send small patches, but also to rewrite - and simplify (or simply re-order) patches before submitting them. - -Here is an analogy from kernel developer Al Viro: - "Think of a teacher grading homework from a math student. The - teacher does not want to see the student's trials and errors - before they came up with the solution. They want to see the - cleanest, most elegant answer. A good student knows this, and - would never submit her intermediate work before the final - solution." - - The same is true of kernel development. The maintainers and - reviewers do not want to see the thought process behind the - solution to the problem one is solving. They want to see a - simple and elegant solution." - -It may be challenging to keep the balance between presenting an elegant -solution and working together with the community and discussing your -unfinished work. Therefore it is good to get early in the process to -get feedback to improve your work, but also keep your changes in small -chunks that they may get already accepted, even when your whole task is -not ready for inclusion now. - -Also realize that it is not acceptable to send patches for inclusion -that are unfinished and will be "fixed up later." - - -Justify your change -------------------- - -Along with breaking up your patches, it is very important for you to let -the Linux community know why they should add this change. New features -must be justified as being needed and useful. - - -Document your change --------------------- - -When sending in your patches, pay special attention to what you say in -the text in your email. This information will become the ChangeLog -information for the patch, and will be preserved for everyone to see for -all time. It should describe the patch completely, containing: - - why the change is necessary - - the overall design approach in the patch - - implementation details - - testing results - -For more details on what this should all look like, please see the -ChangeLog section of the document: - "The Perfect Patch" - http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt - - - - -All of these things are sometimes very hard to do. It can take years to -perfect these practices (if at all). It's a continuous process of -improvement that requires a lot of patience and determination. But -don't give up, it's possible. Many have done it before, and each had to -start exactly where you are now. - - - - ----------- -Thanks to Paolo Ciarrocchi who allowed the "Development Process" section -to be based on text he had written, and to Randy Dunlap and Gerrit -Huizenga for some of the list of things you should and should not say. -Also thanks to Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers, -Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi -Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk, Keri Harris, Frans Pop, -David A. Wheeler, Junio Hamano, Michael Kerrisk, and Alex Shepard for -their review, comments, and contributions. Without their help, this -document would not have been possible. - - - -Maintainer: Greg Kroah-Hartman diff --git a/trunk/MAINTAINERS b/trunk/MAINTAINERS index f239ac4762dd..509927e40bbb 100644 --- a/trunk/MAINTAINERS +++ b/trunk/MAINTAINERS @@ -58,7 +58,6 @@ P: Person M: Mail patches to L: Mailing list that is relevant to this area W: Web-page with status/info -T: SCM tree type and URL. Type is one of: git, hg, quilt. S: Status, one of the following: Supported: Someone is actually paid to look after this. @@ -184,7 +183,6 @@ P: Len Brown M: len.brown@intel.com L: acpi-devel@lists.sourceforge.net W: http://acpi.sourceforge.net/ -T: git kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git S: Maintained AD1816 SOUND DRIVER @@ -420,7 +418,6 @@ BLOCK LAYER P: Jens Axboe M: axboe@suse.de L: linux-kernel@vger.kernel.org -T: git kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git S: Maintained BLUETOOTH SUBSYSTEM @@ -806,14 +803,12 @@ DRIVER CORE, KOBJECTS, AND SYSFS P: Greg Kroah-Hartman M: gregkh@suse.de L: linux-kernel@vger.kernel.org -T: quilt kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/ S: Supported DRM DRIVERS P: David Airlie M: airlied@linux.ie L: dri-devel@lists.sourceforge.net -T: git kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git S: Maintained DSCC4 DRIVER @@ -1118,7 +1113,6 @@ P: Jean Delvare M: khali@linux-fr.org L: lm-sensors@lm-sensors.org W: http://www.lm-sensors.nu/ -T: quilt kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/ S: Maintained I2O @@ -1151,7 +1145,6 @@ P: Tony Luck M: tony.luck@intel.com L: linux-ia64@vger.kernel.org W: http://www.ia64-linux.org/ -T: git kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git S: Maintained SN-IA64 (Itanium) SUB-PLATFORM @@ -1219,7 +1212,6 @@ P: Jody McIntyre M: scjody@steamballoon.com L: linux1394-devel@lists.sourceforge.net W: http://www.linux1394.org/ -T: git kernel.org:/pub/scm/linux/kernel/git/scjody/ieee1394.git S: Maintained IEEE 1394 OHCI DRIVER @@ -1271,7 +1263,6 @@ P: Hal Rosenstock M: halr@voltaire.com L: openib-general@openib.org W: http://www.openib.org/ -T: git kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git S: Supported INPUT (KEYBOARD, MOUSE, JOYSTICK) DRIVERS @@ -1445,7 +1436,6 @@ P: Kai Germaschewski M: kai@germaschewski.name P: Sam Ravnborg M: sam@ravnborg.org -T: git kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git S: Maintained KERNEL JANITORS @@ -1792,7 +1782,6 @@ M: akpm@osdl.org P: Jeff Garzik M: jgarzik@pobox.com L: netdev@vger.kernel.org -T: git kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git S: Maintained NETWORKING [GENERAL] @@ -1970,7 +1959,6 @@ P: Greg Kroah-Hartman M: gregkh@suse.de L: linux-kernel@vger.kernel.org L: linux-pci@atrey.karlin.mff.cuni.cz -T: quilt kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/ S: Supported PCI HOTPLUG CORE @@ -1992,7 +1980,6 @@ S: Maintained PCMCIA SUBSYSTEM P: Linux PCMCIA Team L: http://lists.infradead.org/mailman/listinfo/linux-pcmcia -T: git kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git S: Maintained PCNET32 NETWORK DRIVER @@ -2202,7 +2189,6 @@ SCSI SUBSYSTEM P: James E.J. Bottomley M: James.Bottomley@SteelEye.com L: linux-scsi@vger.kernel.org -T: git kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git S: Maintained SCSI TAPE DRIVER @@ -2242,7 +2228,6 @@ SERIAL ATA (SATA) SUBSYSTEM: P: Jeff Garzik M: jgarzik@pobox.com L: linux-ide@vger.kernel.org -T: git kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git S: Supported SGI SN-IA64 (Altix) SERIAL CONSOLE DRIVER @@ -2764,7 +2749,6 @@ M: gregkh@suse.de L: linux-usb-users@lists.sourceforge.net L: linux-usb-devel@lists.sourceforge.net W: http://www.linux-usb.org -T: quilt kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/ S: Supported USB UHCI DRIVER diff --git a/trunk/arch/ia64/kernel/ivt.S b/trunk/arch/ia64/kernel/ivt.S index 301f2e9d262e..e06f21f60dc5 100644 --- a/trunk/arch/ia64/kernel/ivt.S +++ b/trunk/arch/ia64/kernel/ivt.S @@ -91,17 +91,16 @@ ENTRY(vhpt_miss) * (the "original") TLB miss, which may either be caused by an instruction * fetch or a data access (or non-access). * - * What we do here is normal TLB miss handing for the _original_ miss, - * followed by inserting the TLB entry for the virtual page table page - * that the VHPT walker was attempting to access. The latter gets - * inserted as long as page table entry above pte level have valid - * mappings for the faulting address. The TLB entry for the original - * miss gets inserted only if the pte entry indicates that the page is - * present. + * What we do here is normal TLB miss handing for the _original_ miss, followed + * by inserting the TLB entry for the virtual page table page that the VHPT + * walker was attempting to access. The latter gets inserted as long + * as both L1 and L2 have valid mappings for the faulting address. + * The TLB entry for the original miss gets inserted only if + * the L3 entry indicates that the page is present. * * do_page_fault gets invoked in the following cases: * - the faulting virtual address uses unimplemented address bits - * - the faulting virtual address has no valid page table mapping + * - the faulting virtual address has no L1, L2, or L3 mapping */ mov r16=cr.ifa // get address that caused the TLB miss #ifdef CONFIG_HUGETLB_PAGE @@ -127,7 +126,7 @@ ENTRY(vhpt_miss) #endif ;; cmp.eq p6,p7=5,r17 // is IFA pointing into to region 5? - shr.u r18=r22,PGDIR_SHIFT // get bottom portion of pgd index bit + shr.u r18=r22,PGDIR_SHIFT // get bits 33-63 of the faulting address ;; (p7) dep r17=r17,r19,(PAGE_SHIFT-3),3 // put region number bits in place @@ -138,38 +137,38 @@ ENTRY(vhpt_miss) (p6) shr.u r21=r21,PGDIR_SHIFT+PAGE_SHIFT (p7) shr.u r21=r21,PGDIR_SHIFT+PAGE_SHIFT-3 ;; -(p6) dep r17=r18,r19,3,(PAGE_SHIFT-3) // r17=pgd_offset for region 5 -(p7) dep r17=r18,r17,3,(PAGE_SHIFT-6) // r17=pgd_offset for region[0-4] +(p6) dep r17=r18,r19,3,(PAGE_SHIFT-3) // r17=PTA + IFA(33,42)*8 +(p7) dep r17=r18,r17,3,(PAGE_SHIFT-6) // r17=PTA + (((IFA(61,63) << 7) | IFA(33,39))*8) cmp.eq p7,p6=0,r21 // unused address bits all zeroes? #ifdef CONFIG_PGTABLE_4 - shr.u r28=r22,PUD_SHIFT // shift pud index into position + shr.u r28=r22,PUD_SHIFT // shift L2 index into position #else - shr.u r18=r22,PMD_SHIFT // shift pmd index into position + shr.u r18=r22,PMD_SHIFT // shift L3 index into position #endif ;; - ld8 r17=[r17] // get *pgd (may be 0) + ld8 r17=[r17] // fetch the L1 entry (may be 0) ;; -(p7) cmp.eq p6,p7=r17,r0 // was pgd_present(*pgd) == NULL? +(p7) cmp.eq p6,p7=r17,r0 // was L1 entry NULL? #ifdef CONFIG_PGTABLE_4 - dep r28=r28,r17,3,(PAGE_SHIFT-3) // r28=pud_offset(pgd,addr) + dep r28=r28,r17,3,(PAGE_SHIFT-3) // compute address of L2 page table entry ;; - shr.u r18=r22,PMD_SHIFT // shift pmd index into position -(p7) ld8 r29=[r28] // get *pud (may be 0) + shr.u r18=r22,PMD_SHIFT // shift L3 index into position +(p7) ld8 r29=[r28] // fetch the L2 entry (may be 0) ;; -(p7) cmp.eq.or.andcm p6,p7=r29,r0 // was pud_present(*pud) == NULL? - dep r17=r18,r29,3,(PAGE_SHIFT-3) // r17=pmd_offset(pud,addr) +(p7) cmp.eq.or.andcm p6,p7=r29,r0 // was L2 entry NULL? + dep r17=r18,r29,3,(PAGE_SHIFT-3) // compute address of L3 page table entry #else - dep r17=r18,r17,3,(PAGE_SHIFT-3) // r17=pmd_offset(pgd,addr) + dep r17=r18,r17,3,(PAGE_SHIFT-3) // compute address of L3 page table entry #endif ;; -(p7) ld8 r20=[r17] // get *pmd (may be 0) - shr.u r19=r22,PAGE_SHIFT // shift pte index into position +(p7) ld8 r20=[r17] // fetch the L3 entry (may be 0) + shr.u r19=r22,PAGE_SHIFT // shift L4 index into position ;; -(p7) cmp.eq.or.andcm p6,p7=r20,r0 // was pmd_present(*pmd) == NULL? - dep r21=r19,r20,3,(PAGE_SHIFT-3) // r21=pte_offset(pmd,addr) +(p7) cmp.eq.or.andcm p6,p7=r20,r0 // was L3 entry NULL? + dep r21=r19,r20,3,(PAGE_SHIFT-3) // compute address of L4 page table entry ;; -(p7) ld8 r18=[r21] // read *pte - mov r19=cr.isr // cr.isr bit 32 tells us if this is an insn miss +(p7) ld8 r18=[r21] // read the L4 PTE + mov r19=cr.isr // cr.isr bit 0 tells us if this is an insn miss ;; (p7) tbit.z p6,p7=r18,_PAGE_P_BIT // page present bit cleared? mov r22=cr.iha // get the VHPT address that caused the TLB miss @@ -203,33 +202,25 @@ ENTRY(vhpt_miss) dv_serialize_data /* - * Re-check pagetable entry. If they changed, we may have received a ptc.g + * Re-check L2 and L3 pagetable. If they changed, we may have received a ptc.g * between reading the pagetable and the "itc". If so, flush the entry we - * inserted and retry. At this point, we have: - * - * r28 = equivalent of pud_offset(pgd, ifa) - * r17 = equivalent of pmd_offset(pud, ifa) - * r21 = equivalent of pte_offset(pmd, ifa) - * - * r29 = *pud - * r20 = *pmd - * r18 = *pte + * inserted and retry. */ - ld8 r25=[r21] // read *pte again - ld8 r26=[r17] // read *pmd again + ld8 r25=[r21] // read L4 entry again + ld8 r26=[r17] // read L3 PTE again #ifdef CONFIG_PGTABLE_4 - ld8 r19=[r28] // read *pud again + ld8 r18=[r28] // read L2 entry again #endif cmp.ne p6,p7=r0,r0 ;; - cmp.ne.or.andcm p6,p7=r26,r20 // did *pmd change + cmp.ne.or.andcm p6,p7=r26,r20 // did L3 entry change #ifdef CONFIG_PGTABLE_4 - cmp.ne.or.andcm p6,p7=r19,r29 // did *pud change + cmp.ne.or.andcm p6,p7=r29,r18 // did L4 PTE change #endif mov r27=PAGE_SHIFT<<2 ;; (p6) ptc.l r22,r27 // purge PTE page translation -(p7) cmp.ne.or.andcm p6,p7=r25,r18 // did *pte change +(p7) cmp.ne.or.andcm p6,p7=r25,r18 // did L4 PTE change ;; (p6) ptc.l r16,r27 // purge translation #endif @@ -244,19 +235,19 @@ END(vhpt_miss) ENTRY(itlb_miss) DBG_FAULT(1) /* - * The ITLB handler accesses the PTE via the virtually mapped linear + * The ITLB handler accesses the L3 PTE via the virtually mapped linear * page table. If a nested TLB miss occurs, we switch into physical - * mode, walk the page table, and then re-execute the PTE read and - * go on normally after that. + * mode, walk the page table, and then re-execute the L3 PTE read + * and go on normally after that. */ mov r16=cr.ifa // get virtual address mov r29=b0 // save b0 mov r31=pr // save predicates .itlb_fault: - mov r17=cr.iha // get virtual address of PTE + mov r17=cr.iha // get virtual address of L3 PTE movl r30=1f // load nested fault continuation point ;; -1: ld8 r18=[r17] // read *pte +1: ld8 r18=[r17] // read L3 PTE ;; mov b0=r29 tbit.z p6,p0=r18,_PAGE_P_BIT // page present bit cleared? @@ -271,7 +262,7 @@ ENTRY(itlb_miss) */ dv_serialize_data - ld8 r19=[r17] // read *pte again and see if same + ld8 r19=[r17] // read L3 PTE again and see if same mov r20=PAGE_SHIFT<<2 // setup page size for purge ;; cmp.ne p7,p0=r18,r19 @@ -288,19 +279,19 @@ END(itlb_miss) ENTRY(dtlb_miss) DBG_FAULT(2) /* - * The DTLB handler accesses the PTE via the virtually mapped linear + * The DTLB handler accesses the L3 PTE via the virtually mapped linear * page table. If a nested TLB miss occurs, we switch into physical - * mode, walk the page table, and then re-execute the PTE read and - * go on normally after that. + * mode, walk the page table, and then re-execute the L3 PTE read + * and go on normally after that. */ mov r16=cr.ifa // get virtual address mov r29=b0 // save b0 mov r31=pr // save predicates dtlb_fault: - mov r17=cr.iha // get virtual address of PTE + mov r17=cr.iha // get virtual address of L3 PTE movl r30=1f // load nested fault continuation point ;; -1: ld8 r18=[r17] // read *pte +1: ld8 r18=[r17] // read L3 PTE ;; mov b0=r29 tbit.z p6,p0=r18,_PAGE_P_BIT // page present bit cleared? @@ -315,7 +306,7 @@ dtlb_fault: */ dv_serialize_data - ld8 r19=[r17] // read *pte again and see if same + ld8 r19=[r17] // read L3 PTE again and see if same mov r20=PAGE_SHIFT<<2 // setup page size for purge ;; cmp.ne p7,p0=r18,r19 @@ -429,7 +420,7 @@ ENTRY(nested_dtlb_miss) * r30: continuation address * r31: saved pr * - * Output: r17: physical address of PTE of faulting address + * Output: r17: physical address of L3 PTE of faulting address * r29: saved b0 * r30: continuation address * r31: saved pr @@ -459,33 +450,33 @@ ENTRY(nested_dtlb_miss) (p6) shr.u r21=r21,PGDIR_SHIFT+PAGE_SHIFT (p7) shr.u r21=r21,PGDIR_SHIFT+PAGE_SHIFT-3 ;; -(p6) dep r17=r18,r19,3,(PAGE_SHIFT-3) // r17=pgd_offset for region 5 -(p7) dep r17=r18,r17,3,(PAGE_SHIFT-6) // r17=pgd_offset for region[0-4] +(p6) dep r17=r18,r19,3,(PAGE_SHIFT-3) // r17=PTA + IFA(33,42)*8 +(p7) dep r17=r18,r17,3,(PAGE_SHIFT-6) // r17=PTA + (((IFA(61,63) << 7) | IFA(33,39))*8) cmp.eq p7,p6=0,r21 // unused address bits all zeroes? #ifdef CONFIG_PGTABLE_4 - shr.u r18=r22,PUD_SHIFT // shift pud index into position + shr.u r18=r22,PUD_SHIFT // shift L2 index into position #else - shr.u r18=r22,PMD_SHIFT // shift pmd index into position + shr.u r18=r22,PMD_SHIFT // shift L3 index into position #endif ;; - ld8 r17=[r17] // get *pgd (may be 0) + ld8 r17=[r17] // fetch the L1 entry (may be 0) ;; -(p7) cmp.eq p6,p7=r17,r0 // was pgd_present(*pgd) == NULL? - dep r17=r18,r17,3,(PAGE_SHIFT-3) // r17=p[u|m]d_offset(pgd,addr) +(p7) cmp.eq p6,p7=r17,r0 // was L1 entry NULL? + dep r17=r18,r17,3,(PAGE_SHIFT-3) // compute address of L2 page table entry ;; #ifdef CONFIG_PGTABLE_4 -(p7) ld8 r17=[r17] // get *pud (may be 0) - shr.u r18=r22,PMD_SHIFT // shift pmd index into position +(p7) ld8 r17=[r17] // fetch the L2 entry (may be 0) + shr.u r18=r22,PMD_SHIFT // shift L3 index into position ;; -(p7) cmp.eq.or.andcm p6,p7=r17,r0 // was pud_present(*pud) == NULL? - dep r17=r18,r17,3,(PAGE_SHIFT-3) // r17=pmd_offset(pud,addr) +(p7) cmp.eq.or.andcm p6,p7=r17,r0 // was L2 entry NULL? + dep r17=r18,r17,3,(PAGE_SHIFT-3) // compute address of L2 page table entry ;; #endif -(p7) ld8 r17=[r17] // get *pmd (may be 0) - shr.u r19=r22,PAGE_SHIFT // shift pte index into position +(p7) ld8 r17=[r17] // fetch the L3 entry (may be 0) + shr.u r19=r22,PAGE_SHIFT // shift L4 index into position ;; -(p7) cmp.eq.or.andcm p6,p7=r17,r0 // was pmd_present(*pmd) == NULL? - dep r17=r19,r17,3,(PAGE_SHIFT-3) // r17=pte_offset(pmd,addr); +(p7) cmp.eq.or.andcm p6,p7=r17,r0 // was L3 entry NULL? + dep r17=r19,r17,3,(PAGE_SHIFT-3) // compute address of L4 page table entry (p6) br.cond.spnt page_fault mov b0=r30 br.sptk.many b0 // return to continuation point diff --git a/trunk/drivers/scsi/sata_sil24.c b/trunk/drivers/scsi/sata_sil24.c index cb1933a3bd55..a6836a07a9eb 100644 --- a/trunk/drivers/scsi/sata_sil24.c +++ b/trunk/drivers/scsi/sata_sil24.c @@ -486,6 +486,31 @@ static void sil24_irq_clear(struct ata_port *ap) /* unused */ } +static int __sil24_restart_controller(void __iomem *port) +{ + u32 tmp; + int cnt; + + writel(PORT_CS_INIT, port + PORT_CTRL_STAT); + + /* Max ~10ms */ + for (cnt = 0; cnt < 10000; cnt++) { + tmp = readl(port + PORT_CTRL_STAT); + if (tmp & PORT_CS_RDY) + return 0; + udelay(1); + } + + return -1; +} + +static void sil24_restart_controller(struct ata_port *ap) +{ + if (__sil24_restart_controller((void __iomem *)ap->ioaddr.cmd_addr)) + printk(KERN_ERR DRV_NAME + " ata%u: failed to restart controller\n", ap->id); +} + static int __sil24_reset_controller(void __iomem *port) { int cnt; @@ -505,7 +530,11 @@ static int __sil24_reset_controller(void __iomem *port) if (tmp & PORT_CS_DEV_RST) return -1; - return 0; + + if (tmp & PORT_CS_RDY) + return 0; + + return __sil24_restart_controller(port); } static void sil24_reset_controller(struct ata_port *ap) @@ -577,6 +606,7 @@ static void sil24_error_intr(struct ata_port *ap, u32 slot_stat) */ sil24_update_tf(ap); err_mask = ac_err_mask(pp->tf.command); + sil24_restart_controller(ap); } else { /* * Other errors. libata currently doesn't have any @@ -584,12 +614,11 @@ static void sil24_error_intr(struct ata_port *ap, u32 slot_stat) * ATA_ERR. */ err_mask = AC_ERR_OTHER; + sil24_reset_controller(ap); } if (qc) ata_qc_complete(qc, err_mask); - - sil24_reset_controller(ap); } static inline void sil24_host_intr(struct ata_port *ap)