1. 10 10月, 2011 8 次提交
  2. 06 10月, 2011 1 次提交
  3. 30 9月, 2011 2 次提交
    • B
      powerpc: Fix device-tree matching for Apple U4 bridge · 16fa42af
      Benjamin Herrenschmidt 提交于
      Apple Quad G5 has some oddity in it's device-tree which causes the new
      generic matching code to fail to relate nodes for PCI-E devices below U4
      with their respective struct pci_dev.  This breaks graphics on those
      machines among others.
      
      This fixes it using a quirk which copies the node pointer from the host
      bridge for the root complex, which makes the generic code work for the
      children afterward.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      16fa42af
    • D
      sparc64: Force the execute bit in OpenFirmware's translation entries. · f4142cba
      David S. Miller 提交于
      In the OF 'translations' property, the template TTEs in the mappings
      never specify the executable bit.  This is the case even though some
      of these mappings are for OF's code segment.
      
      Therefore, we need to force the execute bit on in every mapping.
      
      This problem can only really trigger on Niagara/sun4v machines and the
      history behind this is a little complicated.
      
      Previous to sun4v, the sun4u TTE entries lacked a hardware execute
      permission bit.  So OF didn't have to ever worry about setting
      anything to handle executable pages.  Any valid TTE loaded into the
      I-TLB would be respected by the chip.
      
      But sun4v Niagara chips have a real hardware enforced executable bit
      in their TTEs.  So it has to be set or else the I-TLB throws an
      instruction access exception with type code 6 (protection violation).
      
      We've been extremely fortunate to not get bitten by this in the past.
      
      The best I can tell is that the OF's mappings for it's executable code
      were mapped using permanent locked mappings on sun4v in the past.
      Therefore, the fact that we didn't have the exec bit set in the OF
      translations we would use did not matter in practice.
      
      Thanks to Greg Onufer for helping me track this down.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f4142cba
  4. 28 9月, 2011 1 次提交
  5. 27 9月, 2011 2 次提交
  6. 26 9月, 2011 9 次提交
  7. 22 9月, 2011 1 次提交
    • D
      sparc: Make '-p' boot option meaningful again. · 11032c17
      David S. Miller 提交于
      If "-p" is given on the command line, clear the CON_BOOT
      flag for the initial early boot PROM console.
      
      This is necessary to try and see crash messages that occur
      between the registry of the VT console and the probing of
      the first framebuffer or serial console.  During this time
      no console messages are emitted because the VT console
      registry (even if no backend is registered to it) removes
      the early console if CON_BOOT is set.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      11032c17
  8. 21 9月, 2011 5 次提交
    • M
      x86/rtc: Don't recursively acquire rtc_lock · 47997d75
      Matt Fleming 提交于
      A deadlock was introduced on x86 in commit ef68c8f8 ("x86:
      Serialize EFI time accesses on rtc_lock") because efi_get_time()
      and friends can be called with rtc_lock already held by
      read_persistent_time(), e.g.:
      
       timekeeping_init()
          read_persistent_clock()     <-- acquire rtc_lock
              efi_get_time()
                  phys_efi_get_time() <-- acquire rtc_lock <DEADLOCK>
      
      To fix this let's push the locking down into the get_wallclock()
      and set_wallclock() implementations.  Only the clock
      implementations that access the x86 RTC directly need to acquire
      rtc_lock, so it makes sense to push the locking down into the
      rtc, vrtc and efi code.
      
      The virtualization implementations don't require rtc_lock to be
      held because they provide their own serialization.
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      Acked-by: NJan Beulich <jbeulich@novell.com>
      Acked-by: Avi Kivity <avi@redhat.com> [for the virtualization aspect]
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Zhang Rui <rui.zhang@intel.com>
      Cc: Josh Boyer <jwboyer@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      47997d75
    • M
      sparc, exec: remove redundant addr_limit assignment · ddd53bf1
      Mathias Krause 提交于
      The address limit is already set in flush_old_exec() so this assignment of
      USER_DS is redundant.
      Signed-off-by: NMathias Krause <minipli@googlemail.com>
      Cc: David Miller <davem@davemloft.net>
      Signed-off-by: NAndrew Morton <akpm@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ddd53bf1
    • R
      ARM: fix vmlinux.lds.S discarding sections · 6760b109
      Russell King 提交于
      We are seeing linker errors caused by sections being discarded, despite
      the linker script trying to keep them.  The result is (eg):
      
      `.exit.text' referenced in section `.alt.smp.init' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
      `.exit.text' referenced in section `.alt.smp.init' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o
      
      This is the relevent part of the linker script (reformatted to make it
      clearer):
      | SECTIONS
      | {
      | /*
      | * unwind exit sections must be discarded before the rest of the
      | * unwind sections get included.
      | */
      | /DISCARD/ : {
      | *(.ARM.exidx.exit.text)
      | *(.ARM.extab.exit.text)
      | }
      | ...
      | .exit.text : {
      | *(.exit.text)
      | *(.memexit.text)
      | }
      | ...
      | /DISCARD/ : {
      | *(.exit.text)
      | *(.memexit.text)
      | *(.exit.data)
      | *(.memexit.data)
      | *(.memexit.rodata)
      | *(.exitcall.exit)
      | *(.discard)
      | *(.discard.*)
      | }
      | }
      
      Now, this is what the linker manual says about discarded output sections:
      
      |    The special output section name `/DISCARD/' may be used to discard
      | input sections.  Any input sections which are assigned to an output
      | section named `/DISCARD/' are not included in the output file.
      
      No questions, no exceptions. It doesn't say "unless they are listed
      before the /DISCARD/ section." Now, this is what asn-generic/vmlinux.lds.S
      says:
      | /*
      |  * Default discarded sections.
      |  *
      |  * Some archs want to discard exit text/data at runtime rather than
      |  * link time due to cross-section references such as alt instructions,
      |  * bug table, eh_frame, etc. DISCARDS must be the last of output
      |  * section definitions so that such archs put those in earlier section
      |  * definitions.
      |  */
      
      And guess what - the list _always_ includes .exit.text etc.
      
      Now, what's actually happening is that the linker is reading the script,
      and it finds the first /DISCARD/ output section at the beginning of the
      script. It continues reading the script, and finds the 'DISCARD' macro
      at the end, which having been postprocessed results in another
      /DISCARD/ output section. As the linker already contains the earlier
      /DISCARD/ output section, it adds it to that existing section, so it
      effectively is placed at the start. This can be seen by using the -M
      option to ld:
      
      | Linker script and memory map
      |
      |                 0xc037c080                jiffies = jiffies_64
      |
      | /DISCARD/
      |  *(.ARM.exidx.exit.text)
      |  *(.ARM.extab.exit.text)
      |  *(.exit.text)
      |  *(.memexit.text)
      |  *(.exit.data)
      |  *(.memexit.data)
      |  *(.memexit.rodata)
      |  *(.exitcall.exit)
      |  *(.discard)
      |  *(.discard.*)
      |
      |                 0xc0008000                . = 0xc0008000
      |
      | .head.text      0xc0008000      0x1d0
      |                 0xc0008000                _text = .
      |  *(.head.text)
      |  .head.text     0xc0008000      0x1d0 arch/arm/kernel/head.o
      |                 0xc0008000                stext
      |
      | .text           0xc0008200   0x2d78d0
      |                 0xc0008200                _stext = .
      |                 0xc0008200                __exception_text_start = .
      |  *(.exception.text)
      |  .exception.text
      | ...
      
      As you can see, all the discarded sections are grouped together - and
      as a result of it being the first output section, they all appear before
      any other section.
      
      The result is that not only is the unwind information discarded (as
      intended), but also the .exit.text, despite us wanting to have the
      .exit.text preserved.
      
      We can't move the unwind information elsewhere, because it'll then be
      included even when we do actually discard the .exit.text (and similar)
      sections.
      
      So, work around this by avoiding the generic DISCARDS macro, and instead
      conditionalize the sections to be discarded ourselves.  This avoids the
      ambiguity in how the linker assigns input sections to output sections,
      making our script less dependent on undocumented linker behaviour.
      Reported-by: NRob Herring <robherring2@gmail.com>
      Tested-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      6760b109
    • L
      mach-integrator: fix VGA base regression · b71d8429
      Linus Walleij 提交于
      The changes introduced in commit
      cc22b4c1
      "ARM: set vga memory base at run-time"
      
      Makes the Integrator/AP freeze completely. I appears that
      this is due to the VGA base address being assigned at PCI
      init time, while this base is needed earlier than that.
      Moving the initialization of the base address to the
      .map_io function solves this problem.
      
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: NLinus Walleij <linus.walleij@stericsson.com>
      Acked-by: NRob Herring <rob.herring@calxeda.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      b71d8429
    • S
      arm/dt: Tegra: Update SDHCI nodes to match bindings · a0638eb6
      Stephen Warren 提交于
      The bindings were recently updated to have separate properties for each
      type of GPIO. Update the Device Tree source to match that.
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Acked-by: NOlof Johansson <olof@lixom.net>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      a0638eb6
  9. 20 9月, 2011 2 次提交
  10. 17 9月, 2011 3 次提交
  11. 16 9月, 2011 1 次提交
    • L
      asm alternatives: remove incorrect alignment notes · a7f934d4
      Linus Torvalds 提交于
      On x86-64, they were just wasteful: with the explicitly added (now
      unnecessary) padding, the size of the alternatives structure was 16
      bytes, and an alignment of 8 bytes didn't hurt much.
      
      However, it was still silly, since the natural size and alignment for
      the structure is actually just 12 bytes, 4-byte aligned since commit
      59e97e4d ("x86: Make alternative instruction pointers relative").
      So removing the padding, and removing the extra alignment is just a good
      idea.
      
      On x86-32, the alignment of 4 bytes was correct, but was incorrectly
      hardcoded as 8 bytes in <asm/alternative-asm.h>.  That header file had
      used to be an x86-64 only header file, but various unification efforts
      have made it be used for x86-32 too (ie the unification of rwlock and
      rwsem).
      
      That in turn caused x86-32 boot failures, because the extra alignment
      would result in random zero-filled words in the altinstructions section,
      causing oopses early at boot when doing alternative instruction
      replacement.
      
      So just remove all the alignment noise entirely.  It's wrong, and it's
      unnecessary.  The section itself is already properly aligned by the
      linker scripts, and all additions to the section had better be of the
      proper 12-byte format, keeping it aligned.  So if the align directive
      were to ever make a difference, that would be an indication of a serious
      bug to begin with.
      Reported-by: NWerner Landgraf <w.landgraf@ru.r>
      Acked-by: NAndrew Lutomirski <luto@mit.edu>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a7f934d4
  12. 15 9月, 2011 5 次提交