1. 22 Jun, 2013 7 commits
  2. 21 Jun, 2013 8 commits
  3. 20 Jun, 2013 17 commits
  4. 19 Jun, 2013 8 commits
    • Anders Hammarquist's avatar
      USB: serial: ti_usb_3410_5052: new device id for Abbot strip port cable · 35a2fbc9
      Anders Hammarquist authored
      Add product id for Abbott strip port cable for Precision meter which
      uses the TI 3410 chip.
      Signed-off-by: default avatarAnders Hammarquist <iko@iko.pp.se>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      35a2fbc9
    • Rafael J. Wysocki's avatar
      ACPI / LPSS: Power up LPSS devices during enumeration · b9e95fc6
      Rafael J. Wysocki authored
      Commit 7cd8407d (ACPI / PM: Do not execute _PS0 for devices without
      _PSC during initialization) introduced a regression on some systems
      with Intel Lynxpoint Low-Power Subsystem (LPSS) where some devices
      need to be powered up during initialization, but their device objects
      in the ACPI namespace have _PS0 and _PS3 only (without _PSC or power
      resources).
      
      To work around this problem, make the ACPI LPSS driver power up
      devices it knows about by using a new helper function
      acpi_device_fix_up_power() that does all of the necessary
      sanity checks and calls acpi_dev_pm_explicit_set() to put the
      device into D0.
      Reported-and-tested-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b9e95fc6
    • Rafael J. Wysocki's avatar
      ACPI / PM: Fix error code path for power resources initialization · 6ee22e9d
      Rafael J. Wysocki authored
      Commit 781d737c (ACPI: Drop power resources driver) introduced a
      bug in the power resources initialization error code path causing
      a NULL pointer to be referenced in acpi_release_power_resource()
      if there's an error triggering a jump to the 'err' label in
      acpi_add_power_resource().  This happens because the list_node
      field of struct acpi_power_resource has not been initialized yet
      at this point and doing a list_del() on it is a bad idea.
      
      To prevent this problem from occuring, initialize the list_node
      field of struct acpi_power_resource upfront.
      Reported-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Tested-by: default avatarLan Tianyu <tianyu.lan@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: 3.9+ <stable@vger.kernel.org>
      Acked-by: default avatarYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Reviewed-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      6ee22e9d
    • Rafael J. Wysocki's avatar
      ACPI / dock: Take ACPI scan lock in write_undock() · 8112006f
      Rafael J. Wysocki authored
      Since commit 3757b948 (ACPI / hotplug: Fix concurrency issues and
      memory leaks) acpi_bus_scan() and acpi_bus_trim() must always be
      called under acpi_scan_lock, but currently the following scenario
      violating that requirement is possible:
      
       write_undock()
        handle_eject_request()
         hotplug_dock_devices()
          dock_remove_acpi_device()
           acpi_bus_trim()
      
      Fix that by making write_undock() acquire acpi_scan_lock before
      calling handle_eject_request() as appropriate (begin_undock() is
      under the lock too in analogy with acpi_dock_deferred_cb()).
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: 3.9+ <stable@vger.kernel.org>
      Acked-by: default avatarToshi Kani <toshi.kani@hp.com>
      8112006f
    • Mika Westerberg's avatar
      ACPI / resources: call acpi_get_override_irq() only for legacy IRQ resources · 204ebc0a
      Mika Westerberg authored
      acpi_get_override_irq() was added because there was a problem with
      buggy BIOSes passing wrong IRQ() resource for the RTC IRQ.  The
      commit that added the workaround was 61fd47e0 (ACPI: fix two
      IRQ8 issues in IOAPIC mode).
      
      With ACPI 5 enumerated devices there are typically one or more
      extended IRQ resources per device (and these IRQs can be shared).
      However, the acpi_get_override_irq() workaround forces all IRQs in
      range 0 - 15 (the legacy ISA IRQs) to be edge triggered, active high
      as can be seen from the dmesg below:
      
      	ACPI: IRQ 6 override to edge, high
      	ACPI: IRQ 7 override to edge, high
      	ACPI: IRQ 7 override to edge, high
      	ACPI: IRQ 13 override to edge, high
      
      Also /proc/interrupts for the I2C controllers (INT33C2 and INT33C3) shows
      the same thing:
      
      	7:          4          0          0          0   IO-APIC-edge INT33C2:00, INT33C3:00
      
      The _CSR method for INT33C2 (and INT33C3) device returns following
      resource:
      
      	Interrupt (ResourceConsumer, Level, ActiveLow, Shared,,, )
      	{
      		0x00000007,
      	}
      
      which states that this is supposed to be level triggered, active low,
      shared IRQ instead.
      
      Fix this by making sure that acpi_get_override_irq() gets only called
      when we are dealing with legacy IRQ() or IRQNoFlags() descriptors.
      
      While we are there, correct pr_warning() to print the right triggering
      value.
      
      This change turns out to be necessary to make DMA work correctly on
      systems based on the Intel Lynxpoint PCH (Platform Controller Hub).
      
      [rjw: Changelog]
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Cc: 3.9+ <stable@vger.kernel.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      204ebc0a
    • Paul Gortmaker's avatar
      x86: Fix section mismatch on load_ucode_ap · 94978599
      Paul Gortmaker authored
      We are in the process of removing all the __cpuinit annotations.
      While working on making that change, an existing problem was
      made evident:
      
        WARNING: arch/x86/kernel/built-in.o(.text+0x198f2): Section mismatch
        in reference from the function cpu_init() to the function
        .init.text:load_ucode_ap()   The function cpu_init() references
        the function __init load_ucode_ap().  This is often because cpu_init
        lacks a __init annotation or the annotation of load_ucode_ap is wrong.
      
      This now appears because in my working tree, cpu_init() is no longer
      tagged as __cpuinit, and so the audit picks up the mismatch.  The 2nd
      hypothesis from the audit is the correct one, as there was an incorrect
      __init tag on the prototype in the header (but __cpuinit was used on
      the function itself.)
      
      The audit is telling us that the prototype's __init annotation took
      effect and the function did land in the .init.text section.  Checking
      with objdump on a mainline tree that still has __cpuinit shows that
      the __cpuinit on the function takes precedence over the __init on the
      prototype, but that won't be true once we make __cpuinit a no-op.
      
      Even though we are removing __cpuinit, we temporarily align both
      the function and the prototype on __cpuinit so that the changeset
      can be applied to stable trees  if desired.
      
      [ hpa: build fix only, no object code change ]
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: stable <stable@vger.kernel.org> # 3.9+
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Link: http://lkml.kernel.org/r/1371654926-11729-1-git-send-email-paul.gortmaker@windriver.comSigned-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      94978599
    • David Daney's avatar
      mn10300: Fix include dependency in irqflags.h et al. · c0691143
      David Daney authored
      We need to pick up the definition of raw_smp_processor_id() from
      asm/smp.h.  For the !SMP case, we need to supply a definition of
      raw_smp_processor_id().
      
      Because of the include dependencies we cannot use smp_call_func_t in
      asm/smp.h, but we do need linux/thread_info.h
      Signed-off-by: default avatarDavid Daney <david.daney@cavium.com>
      Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Acked-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c0691143
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc · b9e763cd
      Linus Torvalds authored
      Pull sparc fixes from David Miller:
       "Various sparc bug fixes, in particular:
      
        1) TSB hashes have to be flushed before TLB on sparc64, from Dave
           Kleikamp.
      
        2) LEON timer interrupts can get stuck, from Andreas Larsson.
      
        3) Sparc64 needs to handle lack of address-congruence devicetree
           property, from Bob Picco"
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
        sparc: tsb must be flushed before tlb
        sparc,leon: Convert to use devm_ioremap_resource
        sparc64 address-congruence property
        sparc32, leon: Enable interrupts before going idle to avoid getting stuck
        sparc32, leon: Remove separate "ticker" timer for SMP
        sparc: kernel: using strlcpy() instead of strcpy()
        arch: sparc: prom: looping issue, need additional length check in the outside looping
        sparc: remove inline marking of EXPORT_SYMBOL functions
        sparc: Switch to asm-generic/linkage.h
      b9e763cd