1. 30 7月, 2013 1 次提交
  2. 25 6月, 2013 1 次提交
    • A
      libata-acpi: add back ACPI based hotplug functionality · 44521527
      Aaron Lu 提交于
      Commit 30dcf76a "libata: migrate ACPI code over to new bindings"
      mistakenly dropped the code to register hotplug notificaion handler
      for ATA port/devices, causing regression for people using ATA bay,
      as kernel bug #59871 shows.
      
      Fix this by adding back the hotplug notification handler registration
      code.  Since this code has to be run once and notification needs to
      be installed on every ATA port/devices handle no matter if there is
      actual device attached, we can't do this in binding time for ATA
      device ACPI handle, as the binding only occurs when a SCSI device is
      created, i.e. there is device attached.  So introduce the
      ata_acpi_hotplug_init() function to loop scan all ATA ACPI handles
      and if it is available, install the notificaion handler for it during
      ATA init time.
      
      With the ATA ACPI handle binding to SCSI device tree, it is possible
      now that when the SCSI hotplug work removes the SCSI device, the ACPI
      unbind function will find that the corresponding ACPI device has
      already been deleted by dock driver, causing a scaring message like:
      [  128.263966] scsi 4:0:0:0: Oops, 'acpi_handle' corrupt
      Fix this by waiting for SCSI hotplug task finish in our notificaion
      handler, so that the removal of ACPI device done in ACPI unbind
      function triggered by the removal of SCSI device is run earlier when
      ACPI device is still available.
      
      [rjw: Rebased]
      References: https://bugzilla.kernel.org/show_bug.cgi?id=59871Reported-bisected-and-tested-by: NDirk Griesbach <spamthis@freenet.de>
      Signed-off-by: NAaron Lu <aaron.lu@intel.com>
      Acked-by: NTejun Heo <tj@kernel.org>
      Cc: 3.6+ <stable@vger.kernel.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      44521527
  3. 01 5月, 2013 2 次提交
    • L
      ACPI/libata: Restore libata.noacpi support · 19ccee76
      Lv Zheng 提交于
      This patch restores libata.noacpi support to libata-acpi.c.
      There are broken optional control methods for ATA controller devices in the
      real world.  The libata.noacpi has been used for a long time as a
      workaround to deal with issues caused by the broken ASL codes.
      1. The "noacpi" option is introduced by the following commit:
         commit 11ef697b
         Date: Thu, 28 Sep 2006 11:29:01 -0700
         Subject: libata: ACPI and _GTF support
      2. The "noacpi" option is renamed to "libata_noacpi" by the following
         commit:
         commit d7d0dad6
         Date: Wed, 28 Mar 2007 01:57:37 -0400
         Subject: [libata] Disable ACPI by default; fix namespace problems
      3. Some of its logics are changed over time - becomes relying on the
         "acpi_handle" bound to the ATA devices since this commit:
         commit fafbae87
         Date: Tue, 15 May 2007 03:28:16 +0900
         Subject: libata-acpi: implement ata_acpi_associate()
      4. The option is deleted by the following commit:
         commit 30dcf76a
         Date: Mon, 25 Jun 2012 16:13:04 +0800
         Subject: libata: migrate ACPI code over to new bindings
      But the libata.noacpi setup is still left in the kernel without codes to
      implement it.  So the deletion introduces a regression to the Linux.
      This patch disables ATA_ACPI support at runtime by stopping acpi binding
      on the ATA devices to fix this regression.
      This patch is tested by booting a SATA x86-64 kernel or a PATA x86 kernel
      with or without "libata.noacpi=1" kernel command line argument.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NAaron Lu <aaron.lu@intel.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      19ccee76
    • A
      [libata] acpi: make ata_ap_acpi_handle not block · d66af4df
      Aaron Lu 提交于
      Since commit 30dcf76a, ata_ap_acpi_handle will always do a namespace
      walk, which requires acquiring an acpi namespace mutex. This made it
      impossible to be used when calling path has held a spinlock.
      
      For example, it can occur in the following code path for pata_acpi:
      ata_scsi_queuecmd (ap->lock is acquired)
        __ata_scsi_queuecmd
          ata_scsi_translate
            ata_qc_issue
              pacpi_qc_issue
                ata_acpi_stm
                  ata_ap_acpi_handle
                    acpi_get_child
                      acpi_walk_namespace
                        acpi_ut_acquire_mutex (acquire mutex while holding lock)
      This caused scheduling while atomic bug, as reported in bug #56781.
      
      Actually, ata_ap_acpi_handle doesn't have to walk the namespace every
      time it is called, it can simply return the bound acpi handle on the
      corresponding SCSI host. The reason previously it is not done this way
      is, ata_ap_acpi_handle is used in the binding function
      ata_acpi_bind_host by ata_acpi_gtm when the handle is not bound to the
      SCSI host yet. Since we already have the ATA port's handle in its
      binding function, we can simply use it instead of calling
      ata_ap_acpi_handle there. So introduce a new function __ata_acpi_gtm,
      where it will receive an acpi handle param in addition to the ATA port
      which is solely used for debug statement. With this change, we can make
      ata_ap_acpi_handle simply return the bound handle for SCSI host instead
      of walking the acpi namespace now.
      
      Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=56781
      Reported-and-tested-by: <kenzopl@o2.pl>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAaron Lu <aaron.lu@intel.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      d66af4df
  4. 04 4月, 2013 1 次提交
    • A
      libata-acpi: remove redundent code for power resource handling · 7381fe73
      Aaron Lu 提交于
      With commit:
      bc9b6407
      ACPI / PM: Rework the handling of devices depending on power resources
      
      The ACPI core now takes care of the power resources an acpi device
      depends on in that when the power resources are turned on, any devices
      that are bound to or in the dependent list of this acpi device will be
      runtime resumed. So there is no need for ata acpi code to duplicate this
      effort, and thus, the ata_acpi_(un)register_power_resource functions are
      no longer needed.
      
      The above commit thinks the scsi device is not bound to the acpi device,
      so needs to be added to the dependent list. But actually, it is. So
      there is no need to add it to the dependent list, or it will be runtime
      resumed twice(though this wouldn't cause any problem).
      
      This patch fixes it, and as a result, the
      ata_acpi_(un)register_power_resource and ata_acpi_(un)bind functions
      are removed.
      Signed-off-by: NAaron Lu <aaron.lu@intel.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      7381fe73
  5. 05 3月, 2013 1 次提交
  6. 04 3月, 2013 2 次提交
  7. 26 1月, 2013 1 次提交
    • A
      [libata] pm: differentiate system and runtime pm for ata port · a7ff60db
      Aaron Lu 提交于
      We need to do different things for system PM and runtime PM, e.g. we do
      not need to enable runtime wake for ZPODD when we are doing system
      suspend, etc.
      
      Currently, we use PMSG_SUSPEND for both system suspend and runtime
      suspend and PMSG_ON for both system resume and runtime resume. Change
      this by using PMSG_AUTO_SUSPEND for runtime suspend and PMSG_AUTO_RESUME
      for runtime resume. And since PMSG_ON means no transition, it is changed
      to PMSG_RESUME for ata port's system resume.
      
      The ata_acpi_set_state is modified accordingly, and the sata case and
      pata case is seperated for easy reading.
      Signed-off-by: NAaron Lu <aaron.lu@intel.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      a7ff60db
  8. 22 1月, 2013 3 次提交
    • A
      libata: expose pm qos flags for ata device · a59b9aae
      Aaron Lu 提交于
      Expose pm qos flags to user space so that user has a chance to disable
      ZPODD feature, if he/she has a broken platform or devices or simply does
      not like this feature.
      
      This flag is exposed to user space only for ZPODD devices.
      
      Due to this flag, it is possible the ODD is ZP ready but we didn't power
      it off. So the zp_ready flag will need to be cleared whenever we found
      the ODD is not in ZP ready state. Previously, once zp_ready is set, the
      ODD will always be powered off and the flag will be cleared in
      post_poweron. But this is no longer the case now.
      Signed-off-by: NAaron Lu <aaron.lu@intel.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      a59b9aae
    • A
      libata: handle power transition of ODD · 21334205
      Aaron Lu 提交于
      When ata port is runtime suspended, it will check if the ODD attched to
      it is a zero power(ZP) capable ODD and if the ZP capable ODD is in zero
      power ready state. And if this is not the case, the highest acpi state
      will be limited to ACPI_STATE_D3_HOT to avoid powering off the ODD. And
      if the ODD can be powered off, runtime wake capability needs to be
      enabled and powered_off flag will be set to let resume code knows that
      the ODD was in powered off state.
      
      And on resume, before it is powered on, if it was powered off during
      suspend, runtime wake capability needs to be disabled. After it is
      recovered, the ODD is considered functional, post power on processing
      like eject tray if the ODD is drawer type is done, and several ZPODD
      related fields will also be reset.
      Signed-off-by: NAaron Lu <aaron.lu@intel.com>
      Acked-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      21334205
    • A
      libata: move acpi notification code to zpodd · f064a20d
      Aaron Lu 提交于
      Since the ata acpi notification code introduced in commit
      3bd46600 is solely for ZPODD, and we
      now have a dedicated place for it, move these code there.
      
      And the ata_acpi_add_pm_notifier code is changed a little bit in that it
      is now invoked when scsi device is not bound with ACPI yet, so the way
      to get the acpi handle is different with the previous version. And the
      ata_acpi_add/remove_pm_notifier is also simplified a little bit in that
      it doesn't check if the acpi_device for the handle exists or not as the
      odd_can_poweroff function already checked that.
      Signed-off-by: NAaron Lu <aaron.lu@intel.com>
      Acked-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      f064a20d
  9. 17 1月, 2013 1 次提交
    • R
      ACPI / PM: Rework the handling of devices depending on power resources · bc9b6407
      Rafael J. Wysocki 提交于
      Commit 0090def6 (ACPI: Add interface to register/unregister device
      to/from power resources) made it possible to indicate to the ACPI
      core that if the given device depends on any power resources, then
      it should be resumed as soon as all of the power resources required
      by it to transition to the D0 power state have been turned on.
      
      Unfortunately, however, this was a mistake, because all devices
      depending on power resources should be treated this way (i.e. they
      should be resumed when all power resources required by their D0
      state have been turned on) and for the majority of those devices
      the ACPI core can figure out by itself which (physical) devices
      depend on what power resources.
      
      For this reason, replace the code added by commit 0090def6 with a
      new, much more straightforward, mechanism that will be used
      internally by the ACPI core and remove all references to that code
      from kernel subsystems using ACPI.
      
      For the cases when there are (physical) devices that should be
      resumed whenever a not directly related ACPI device node goes into
      D0 as a result of power resources configuration changes, like in
      the SATA case, add two new routines, acpi_dev_pm_add_dependent()
      and acpi_dev_pm_remove_dependent(), allowing subsystems to manage
      such dependencies.  Convert the SATA subsystem to use the new
      functions accordingly.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      bc9b6407
  10. 03 12月, 2012 1 次提交
    • A
      libata: restore acpi disable functionality · 0d0cdb02
      Aaron Lu 提交于
      Commit 66fa7f21 "libata-acpi: improve ACPI disabling" introdcued the
      behaviour of disabling ATA ACPI if ata_acpi_on_devcfg failed the 2nd
      time, but commit 30dcf76a dropped this behaviour and this caused
      problem for Dimitris Damigos, where his laptop can not resume correctly.
      
      The bugzilla page for it is:
      https://bugzilla.kernel.org/show_bug.cgi?id=49331
      
      The problem is, ata_dev_push_id will fail the 2nd time it is invoked,
      and due to disabling ACPI code is dropped, ata_acpi_on_devcfg which
      calls ata_dev_push_id will keep failing and eventually made the device
      disabled.
      
      This patch restores the original behaviour, if acpi failed the 2nd time,
      disable acpi functionality for the device(and we do not event need to
      add a debug message for this as it is still there ;-).
      Reported-by: NDimitris Damigos <damigos@freemail.gr>
      Signed-off-by: NAaron Lu <aaron.lu@intel.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      0d0cdb02
  11. 16 11月, 2012 1 次提交
  12. 18 8月, 2012 1 次提交
  13. 26 7月, 2012 1 次提交
    • S
      libata-acpi: fix up for acpi_pm_device_sleep_state API · 354b2eac
      Stephen Rothwell 提交于
      After merging the libata tree, today's [2012-07-01] linux-next build (x86_64
      allmodconfig) failed like this:
      
      drivers/ata/libata-acpi.c: In function 'ata_acpi_set_state':
      drivers/ata/libata-acpi.c:872:5: error: too few arguments to function 'acpi_pm_device_sleep_state'
      include/acpi/acpi_bus.h:418:5: note: declared here
      
      Caused by commit 3bd46600 ("libata-acpi: add ata port runtime D3Cold
      support") from the libata tree interacting with commit ee85f543
      ("ACPI/PM: specify lowest allowed state for device sleep state") from the
      pci tree.
      
      This patch adds ACPI_STATE_D3 as the new third parameter to
      acpi_pm_device_sleep_state()
      Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      354b2eac
  14. 29 6月, 2012 6 次提交
  15. 24 7月, 2011 1 次提交
    • J
      ata: Convert ata_<foo>_printk(KERN_<LEVEL> to ata_<foo>_<level> · a9a79dfe
      Joe Perches 提交于
      Saves text by removing nearly duplicated text format strings by
      creating ata_<foo>_printk functions and printf extension %pV.
      
      ata defconfig size shrinks ~5% (~8KB), allyesconfig ~2.5% (~13KB)
      
      Format string duplication comes from:
      
       #define ata_link_printk(link, lv, fmt, args...) do { \
             if (sata_pmp_attached((link)->ap) || (link)->ap->slave_link)    \
                     printk("%sata%u.%02u: "fmt, lv, (link)->ap->print_id,   \
                            (link)->pmp , ##args); \
             else \
                     printk("%sata%u: "fmt, lv, (link)->ap->print_id , ##args); \
             } while(0)
      
      Coalesce long formats.
      
      $ size drivers/ata/built-in.*
         text	   data	    bss	    dec	    hex	filename
       544969	  73893	 116584	 735446	  b38d6	drivers/ata/built-in.allyesconfig.ata.o
       558429	  73893	 117864	 750186	  b726a	drivers/ata/built-in.allyesconfig.dev_level.o
       141328	  14689	   4220	 160237	  271ed	drivers/ata/built-in.defconfig.ata.o
       149567	  14689	   4220	 168476	  2921c	drivers/ata/built-in.defconfig.dev_level.o
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NJeff Garzik <jgarzik@pobox.com>
      a9a79dfe
  16. 17 7月, 2011 1 次提交
  17. 02 3月, 2011 1 次提交
  18. 15 8月, 2010 1 次提交
  19. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  20. 28 1月, 2010 1 次提交
  21. 03 12月, 2009 1 次提交
  22. 06 10月, 2009 3 次提交
  23. 02 9月, 2009 1 次提交
    • R
      libata: add command name parsing for error output · 6521148c
      Robert Hancock 提交于
      This patch improve libata's output for error/notification messages
      to allow easier comprehension and debugging:
      
      When ATAPI commands issued through the SCSI layer fail, use SCSI
      functions to print the CDB in human-readable form instead of just
      dumping out the CDB in hex.
      
      Print out the name of the failed command (as defined by the ATA
      specification) in error handling output along with the raw register
      contents.
      
      When reporting status of ACPI taskfile commands executed on resume,
      also output the names of the commands being executed (or not) in
      readable form.
      
      Since the extra data for printing command names increases kernel
      size slightly, a config option has been added to allow disabling
      command name output (as well as some of the error register parsing)
      for those highly sensitive to kernel text size.
      Signed-off-by: NRobert Hancock <hancockrwd@gmail.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      6521148c
  24. 13 6月, 2009 1 次提交
  25. 31 12月, 2008 1 次提交
  26. 29 12月, 2008 1 次提交
    • T
      libata: beef up iterators · 1eca4365
      Tejun Heo 提交于
      There currently are the following looping constructs.
      
      * __ata_port_for_each_link() for all available links
      * ata_port_for_each_link() for edge links
      * ata_link_for_each_dev() for all devices
      * ata_link_for_each_dev_reverse() for all devices in reverse order
      
      Now there's a need for looping construct which is similar to
      __ata_port_for_each_link() but iterates over PMP links before the host
      link.  Instead of adding another one with long name, do the following
      cleanup.
      
      * Implement and export ata_link_next() and ata_dev_next() which take
        @mode parameter and can be used to build custom loop.
      * Implement ata_for_each_link() and ata_for_each_dev() which take
        looping mode explicitly.
      
      The following iteration modes are implemented.
      
      * ATA_LITER_EDGE		: loop over edge links
      * ATA_LITER_HOST_FIRST		: loop over all links, host link first
      * ATA_LITER_PMP_FIRST		: loop over all links, PMP links first
      
      * ATA_DITER_ENABLED		: loop over enabled devices
      * ATA_DITER_ENABLED_REVERSE	: loop over enabled devices in reverse order
      * ATA_DITER_ALL			: loop over all devices
      * ATA_DITER_ALL_REVERSE		: loop over all devices in reverse order
      
      This change removes exlicit device enabledness checks from many loops
      and makes it clear which ones are iterated over in which direction.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      1eca4365
  27. 11 10月, 2008 1 次提交
  28. 24 9月, 2008 2 次提交