1. 03 Jan, 2013 1 commit
    • Greg Kroah-Hartman's avatar
      X86: drivers: remove __dev* attributes. · a18e3690
      Greg Kroah-Hartman authored
      CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
      markings need to be removed.
      
      This change removes the use of __devinit, __devexit_p, __devinitconst,
      and __devexit from these drivers.
      
      Based on patches originally written by Bill Pemberton, but redone by me
      in order to handle some of the coding style issues better, by hand.
      
      Cc: Bill Pemberton <wfp5p@virginia.edu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Daniel Drake <dsd@laptop.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a18e3690
  2. 18 Dec, 2012 1 commit
  3. 15 Dec, 2012 1 commit
  4. 14 Nov, 2012 1 commit
  5. 30 Oct, 2012 4 commits
    • Jan Beulich's avatar
      x86-64/efi: Use EFI to deal with platform wall clock (again) · bd52276f
      Jan Beulich authored
      Other than ix86, x86-64 on EFI so far didn't set the
      {g,s}et_wallclock accessors to the EFI routines, thus
      incorrectly using raw RTC accesses instead.
      
      Simply removing the #ifdef around the respective code isn't
      enough, however: While so far early get-time calls were done in
      physical mode, this doesn't work properly for x86-64, as virtual
      addresses would still need to be set up for all runtime regions
      (which wasn't the case on the system I have access to), so
      instead the patch moves the call to efi_enter_virtual_mode()
      ahead (which in turn allows to drop all code related to calling
      efi-get-time in physical mode).
      
      Additionally the earlier calling of efi_set_executable()
      requires the CPA code to cope, i.e. during early boot it must be
      avoided to call cpa_flush_array(), as the first thing this
      function does is a BUG_ON(irqs_disabled()).
      
      Also make the two EFI functions in question here static -
      they're not being referenced elsewhere.
      
      History:
      
          This commit was originally merged as bacef661 ("x86-64/efi:
          Use EFI to deal with platform wall clock") but it resulted in some
          ASUS machines no longer booting due to a firmware bug, and so was
          reverted in f026cfa8. A pre-emptive fix for the buggy ASUS
          firmware was merged in 03a1c254975e ("x86, efi: 1:1 pagetable
          mapping for virtual EFI calls") so now this patch can be
          reapplied.
      Signed-off-by: default avatarJan Beulich <jbeulich@suse.com>
      Tested-by: default avatarMatt Fleming <matt.fleming@intel.com>
      Acked-by: default avatarMatthew Garrett <mjg@redhat.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Signed-off-by: Matt Fleming <matt.fleming@intel.com> [added commit history]
      bd52276f
    • Matt Fleming's avatar
      x86, efi: 1:1 pagetable mapping for virtual EFI calls · 185034e7
      Matt Fleming authored
      Some firmware still needs a 1:1 (virt->phys) mapping even after we've
      called SetVirtualAddressMap(). So install the mapping alongside our
      existing kernel mapping whenever we make EFI calls in virtual mode.
      
      This bug was discovered on ASUS machines where the firmware
      implementation of GetTime() accesses the RTC device via physical
      addresses, even though that's bogus per the UEFI spec since we've
      informed the firmware via SetVirtualAddressMap() that the boottime
      memory map is no longer valid.
      
      This bug seems to be present in a lot of consumer devices, so there's
      not a lot we can do about this spec violation apart from workaround
      it.
      
      Cc: JérômeCarretero <cJ-ko@zougloub.eu>
      Cc: Vasco Dias <rafa.vasco@gmail.com>
      Acked-by: default avatarJan Beulich <jbeulich@suse.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      185034e7
    • Maxime Bizon's avatar
      x86/ce4100: Fix reboot by forcing the reboot method to be KBD · d7959916
      Maxime Bizon authored
      The default reboot is via ACPI for this platform, and the CEFDK
      bootloader actually supports this, but will issue a system power
      off instead of a real reboot. Setting the reboot method to be
      KBD instead of ACPI ensures proper system reboot.
      Acked-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarMaxime Bizon <mbizon@freebox.fr>
      Signed-off-by: default avatarFlorian Fainelli <ffainelli@freebox.fr>
      Cc: rui.zhang@intel.com
      Cc: alan@linux.intel.com
      Link: http://lkml.kernel.org/r/1351518020-25556-3-git-send-email-ffainelli@freebox.frSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      d7959916
    • Florian Fainelli's avatar
      x86/ce4100: Fix pm_poweroff · f49f4ab9
      Florian Fainelli authored
      The CE4100 platform is currently missing a proper pm_poweroff
      implementation leading to poweroff making the CPU spin forever
      and the CE4100 platform does not enter a low-power mode where
      the external Power Management Unit can properly power off the
      system. Power off on this platform is implemented pretty much
      like reboot, by writing to the SoC built-in 8051 microcontroller
      mapped at I/O port 0xcf9, the value 0x4.
      Signed-off-by: default avatarFlorian Fainelli <ffainelli@freebox.fr>
      Acked-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Cc: rui.zhang@intel.com
      Cc: alan@linux.intel.com
      Link: http://lkml.kernel.org/r/1351518020-25556-2-git-send-email-ffainelli@freebox.frSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      f49f4ab9
  6. 25 Oct, 2012 1 commit
  7. 24 Oct, 2012 2 commits
    • Maxime Bizon's avatar
      x86: ce4100: allow second UART usage · 08ec212c
      Maxime Bizon authored
      The current CE4100 and 8250_pci code have both a limitation preventing the
      registration and usage of CE4100's second UART. This patch changes the
      platform code fixing up the UART port to work on a relative UART port
      base address, as well as the 8250_pci code to make it register 2 UART ports
      for CE4100 and pass the port index down to all consumers.
      Signed-off-by: default avatarFlorian Fainelli <ffainelli@freebox.fr>
      Acked-by: default avatarAlan Cox <alan@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      08ec212c
    • Matt Fleming's avatar
      x86/efi: Fix oops caused by incorrect set_memory_uc() usage · 3e8fa263
      Matt Fleming authored
      Calling __pa() with an ioremap'd address is invalid. If we
      encounter an efi_memory_desc_t without EFI_MEMORY_WB set in
      ->attribute we currently call set_memory_uc(), which in turn
      calls __pa() on a potentially ioremap'd address.
      
      On CONFIG_X86_32 this results in the following oops:
      
        BUG: unable to handle kernel paging request at f7f22280
        IP: [<c10257b9>] reserve_ram_pages_type+0x89/0x210
        *pdpt = 0000000001978001 *pde = 0000000001ffb067 *pte = 0000000000000000
        Oops: 0000 [#1] PREEMPT SMP
        Modules linked in:
      
        Pid: 0, comm: swapper Not tainted 3.0.0-acpi-efi-0805 #3
         EIP: 0060:[<c10257b9>] EFLAGS: 00010202 CPU: 0
         EIP is at reserve_ram_pages_type+0x89/0x210
         EAX: 0070e280 EBX: 38714000 ECX: f7814000 EDX: 00000000
         ESI: 00000000 EDI: 38715000 EBP: c189fef0 ESP: c189fea8
         DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
        Process swapper (pid: 0, ti=c189e000 task=c18bbe60 task.ti=c189e000)
        Stack:
         80000200 ff108000 00000000 c189ff00 00038714 00000000 00000000 c189fed0
         c104f8ca 00038714 00000000 00038715 00000000 00000000 00038715 00000000
         00000010 38715000 c189ff48 c1025aff 38715000 00000000 00000010 00000000
        Call Trace:
         [<c104f8ca>] ? page_is_ram+0x1a/0x40
         [<c1025aff>] reserve_memtype+0xdf/0x2f0
         [<c1024dc9>] set_memory_uc+0x49/0xa0
         [<c19334d0>] efi_enter_virtual_mode+0x1c2/0x3aa
         [<c19216d4>] start_kernel+0x291/0x2f2
         [<c19211c7>] ? loglevel+0x1b/0x1b
         [<c19210bf>] i386_start_kernel+0xbf/0xc8
      
      The only time we can call set_memory_uc() for a memory region is
      when it is part of the direct kernel mapping. For the case where
      we ioremap a memory region we must leave it alone.
      
      This patch reimplements the fix from e8c71062 ("x86, efi:
      Calling __pa() with an ioremap()ed address is invalid") which
      was reverted in e1ad783b because it caused a regression on
      some MacBooks (they hung at boot). The regression was caused
      because the commit only marked EFI_RUNTIME_SERVICES_DATA as
      E820_RESERVED_EFI, when it should have marked all regions that
      have the EFI_MEMORY_RUNTIME attribute.
      
      Despite first impressions, it's not possible to use
      ioremap_cache() to map all cached memory regions on
      CONFIG_X86_64 because of the way that the memory map might be
      configured as detailed in the following bug report,
      
      	https://bugzilla.redhat.com/show_bug.cgi?id=748516
      
      e.g. some of the EFI memory regions *need* to be mapped as part
      of the direct kernel mapping.
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      Cc: Matthew Garrett <mjg@redhat.com>
      Cc: Zhang Rui <rui.zhang@intel.com>
      Cc: Huang Ying <huang.ying.caritas@gmail.com>
      Cc: Keith Packard <keithp@keithp.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Link: http://lkml.kernel.org/r/1350649546-23541-1-git-send-email-matt@console-pimps.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      3e8fa263
  8. 29 Sep, 2012 3 commits
  9. 17 Sep, 2012 1 commit
  10. 14 Aug, 2012 1 commit
  11. 31 Jul, 2012 5 commits
  12. 12 Jul, 2012 1 commit
  13. 27 Jun, 2012 1 commit
    • Alex Shi's avatar
      x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range · e7b52ffd
      Alex Shi authored
      x86 has no flush_tlb_range support in instruction level. Currently the
      flush_tlb_range just implemented by flushing all page table. That is not
      the best solution for all scenarios. In fact, if we just use 'invlpg' to
      flush few lines from TLB, we can get the performance gain from later
      remain TLB lines accessing.
      
      But the 'invlpg' instruction costs much of time. Its execution time can
      compete with cr3 rewriting, and even a bit more on SNB CPU.
      
      So, on a 512 4KB TLB entries CPU, the balance points is at:
      	(512 - X) * 100ns(assumed TLB refill cost) =
      		X(TLB flush entries) * 100ns(assumed invlpg cost)
      
      Here, X is 256, that is 1/2 of 512 entries.
      
      But with the mysterious CPU pre-fetcher and page miss handler Unit, the
      assumed TLB refill cost is far lower then 100ns in sequential access. And
      2 HT siblings in one core makes the memory access more faster if they are
      accessing the same memory. So, in the patch, I just do the change when
      the target entries is less than 1/16 of whole active tlb entries.
      Actually, I have no data support for the percentage '1/16', so any
      suggestions are welcomed.
      
      As to hugetlb, guess due to smaller page table, and smaller active TLB
      entries, I didn't see benefit via my benchmark, so no optimizing now.
      
      My micro benchmark show in ideal scenarios, the performance improves 70
      percent in reading. And in worst scenario, the reading/writing
      performance is similar with unpatched 3.4-rc4 kernel.
      
      Here is the reading data on my 2P * 4cores *HT NHM EP machine, with THP
      'always':
      
      multi thread testing, '-t' paramter is thread number:
      	       	        with patch   unpatched 3.4-rc4
      ./mprotect -t 1           14ns		24ns
      ./mprotect -t 2           13ns		22ns
      ./mprotect -t 4           12ns		19ns
      ./mprotect -t 8           14ns		16ns
      ./mprotect -t 16          28ns		26ns
      ./mprotect -t 32          54ns		51ns
      ./mprotect -t 128         200ns		199ns
      
      Single process with sequencial flushing and memory accessing:
      
      		       	with patch   unpatched 3.4-rc4
      ./mprotect		    7ns			11ns
      ./mprotect -p 4096  -l 8 -n 10240
      			    21ns		21ns
      
      [ hpa: http://lkml.kernel.org/r/1B4B44D9196EFF41AE41FDA404FC0A100BFF94@SHSMSX101.ccr.corp.intel.com
        has additional performance numbers. ]
      Signed-off-by: default avatarAlex Shi <alex.shi@intel.com>
      Link: http://lkml.kernel.org/r/1340845344-27557-3-git-send-email-alex.shi@intel.comSigned-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      e7b52ffd
  14. 25 Jun, 2012 3 commits
    • Cliff Wickman's avatar
      x86/uv: Work around UV2 BAU hangs · 8b6e511e
      Cliff Wickman authored
      On SGI's UV2 the BAU (Broadcast Assist Unit) driver can hang
      under a heavy load. To cure this:
      
      - Disable the UV2 extended status mode (see UV2_EXT_SHFT), as
        this mode changes BAU behavior in more ways then just delivering
        an extra bit of status.  Revert status to just two meaningful bits,
        like UV1.
      
      - Use no IPI-style resets on UV2.  Just give up the request for
        whatever the reason it failed and let it be accomplished with
        the legacy IPI method.
      
      - Use no alternate sending descriptor (the former UV2 workaround
        bcp->using_desc and handle_uv2_busy() stuff).  Just disable the
        use of the BAU for a period of time in favor of the legacy IPI
        method when the h/w bug leaves a descriptor busy.
      
        -- new tunable: giveup_limit determines the threshold at which a hub is
           so plugged that it should do all requests with the legacy IPI method for a
           period of time
        -- generalize disable_for_congestion() (renamed disable_for_period()) for
           use whenever a hub should avoid using the BAU for a period of time
      
      Also:
      
       - Fix find_another_by_swack(), which is part of the UV2 bug workaround
      
       - Correct and clarify the statistics (new stats s_overipilimit, s_giveuplimit,
         s_enters, s_ipifordisabled, s_plugged, s_congested)
      Signed-off-by: default avatarCliff Wickman <cpw@sgi.com>
      Link: http://lkml.kernel.org/r/20120622131459.GC31884@sgi.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      8b6e511e
    • Cliff Wickman's avatar
      x86/uv: Implement UV BAU runtime enable and disable control via /proc/sgi_uv/ · 26ef8577
      Cliff Wickman authored
      This patch enables the BAU to be turned on or off dynamically.
      
        echo "on"  > /proc/sgi_uv/ptc_statistics
        echo "off" > /proc/sgi_uv/ptc_statistics
      
      The system may be booted with or without the nobau option.
      
      Whether the system currently has the BAU off can be seen in
      the /proc file -- normally with the baustats script.
      Each cpu will have a 1 in the bauoff field if the BAU was turned
      off, so baustats will give a count of cpus that have it off.
      Signed-off-by: default avatarCliff Wickman <cpw@sgi.com>
      Link: http://lkml.kernel.org/r/20120622131330.GB31884@sgi.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      26ef8577
    • Cliff Wickman's avatar
      x86/uv: Fix the UV BAU destination timeout period · 11cab711
      Cliff Wickman authored
      Correct the calculation of a destination timeout period, which
      is used to distinguish between a destination timeout and the
      situation where all the target software ack resources are full
      and a request is returned immediately.
      
      The problem is that integer arithmetic was overflowing, yielding
      a very large result.
      
      Without this fix destination timeouts are identified as resource
      'plugged' events and an ipi method of resource releasing is
      unnecessarily employed.
      Signed-off-by: default avatarCliff Wickman <cpw@sgi.com>
      Link: http://lkml.kernel.org/r/20120622131212.GA31884@sgi.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      11cab711
  15. 15 Jun, 2012 1 commit
  16. 14 Jun, 2012 1 commit
  17. 08 Jun, 2012 2 commits
    • Cliff Wickman's avatar
      x86/uv: Fix UV2 BAU legacy mode · d5d2d2ee
      Cliff Wickman authored
      The SGI Altix UV2 BAU (Broadcast Assist Unit) as used for
      tlb-shootdown (selective broadcast mode) always uses UV2
      broadcast descriptor format. There is no need to clear the
      'legacy' (UV1) mode, because the hardware always uses UV2 mode
      for selective broadcast.
      
      But the BIOS uses general broadcast and legacy mode, and the
      hardware pays attention to the legacy mode bit for general
      broadcast. So the kernel must not clear that mode bit.
      Signed-off-by: default avatarCliff Wickman <cpw@sgi.com>
      Cc: <stable@kernel.org>
      Link: http://lkml.kernel.org/r/E1SccoO-0002Lh-Cb@eag09.americas.sgi.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      d5d2d2ee
    • Alexander Gordeev's avatar
      x86/apic: Make cpu_mask_to_apicid() operations return error code · ff164324
      Alexander Gordeev authored
      Current cpu_mask_to_apicid() and cpu_mask_to_apicid_and()
      implementations have few shortcomings:
      
      1. A value returned by cpu_mask_to_apicid() is written to
      hardware registers unconditionally. Should BAD_APICID get ever
      returned it will be written to a hardware too. But the value of
      BAD_APICID is not universal across all hardware in all modes and
      might cause unexpected results, i.e. interrupts might get routed
      to CPUs that are not configured to receive it.
      
      2. Because the value of BAD_APICID is not universal it is
      counter- intuitive to return it for a hardware where it does not
      make sense (i.e. x2apic).
      
      3. cpu_mask_to_apicid_and() operation is thought as an
      complement to cpu_mask_to_apicid() that only applies a AND mask
      on top of a cpumask being passed. Yet, as consequence of 18374d89
      commit the two operations are inconsistent in that of:
        cpu_mask_to_apicid() should not get a offline CPU with the cpumask
        cpu_mask_to_apicid_and() should not fail and return BAD_APICID
      These limitations are impossible to realize just from looking at
      the operations prototypes.
      
      Most of these shortcomings are resolved by returning a error
      code instead of BAD_APICID. As the result, faults are reported
      back early rather than possibilities to cause a unexpected
      behaviour exist (in case of [1]).
      
      The only exception is setup_timer_IRQ0_pin() routine. Although
      obviously controversial to this fix, its existing behaviour is
      preserved to not break the fragile check_timer() and would
      better addressed in a separate fix.
      Signed-off-by: default avatarAlexander Gordeev <agordeev@redhat.com>
      Acked-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Link: http://lkml.kernel.org/r/20120607131559.GF4759@dhcp-26-207.brq.redhat.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      ff164324
  18. 06 Jun, 2012 2 commits
  19. 24 May, 2012 1 commit
  20. 18 May, 2012 1 commit
  21. 07 May, 2012 2 commits
  22. 04 May, 2012 1 commit
  23. 25 Apr, 2012 1 commit
  24. 27 Mar, 2012 1 commit
  25. 20 Mar, 2012 1 commit