From: kernel test robot <lkp@intel.com>
To: Raag Jadav <raag.jadav@intel.com>,
rafael@kernel.org, mahesh@linux.ibm.com, oohall@gmail.com,
bhelgaas@google.com
Cc: oe-kbuild-all@lists.linux.dev, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, ilpo.jarvinen@linux.intel.com,
lukas@wunner.de, aravind.iddamsetty@linux.intel.com,
Raag Jadav <raag.jadav@intel.com>
Subject: Re: [PATCH v2] PCI/PM: Avoid suspending the device with errors
Date: Wed, 23 Apr 2025 02:01:46 +0800 [thread overview]
Message-ID: <202504230101.o7uTJFn5-lkp@intel.com> (raw)
In-Reply-To: <20250422135341.2780925-1-raag.jadav@intel.com>
Hi Raag,
kernel test robot noticed the following build errors:
[auto build test ERROR on pci/next]
[also build test ERROR on pci/for-linus linus/master v6.15-rc3 next-20250422]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Raag-Jadav/PCI-PM-Avoid-suspending-the-device-with-errors/20250422-215734
base: https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git next
patch link: https://lore.kernel.org/r/20250422135341.2780925-1-raag.jadav%40intel.com
patch subject: [PATCH v2] PCI/PM: Avoid suspending the device with errors
config: loongarch-randconfig-002-20250422 (https://download.01.org/0day-ci/archive/20250423/202504230101.o7uTJFn5-lkp@intel.com/config)
compiler: loongarch64-linux-gcc (GCC) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250423/202504230101.o7uTJFn5-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202504230101.o7uTJFn5-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from include/linux/array_size.h:5,
from include/linux/string.h:6,
from include/linux/uuid.h:11,
from include/linux/mod_devicetable.h:14,
from include/linux/pci.h:27,
from drivers/pci/pci-driver.c:7:
drivers/pci/pci-driver.c: In function 'pci_pm_suspend_noirq':
>> drivers/pci/pci-driver.c:887:14: error: implicit declaration of function 'pci_aer_in_progress' [-Wimplicit-function-declaration]
887 | if (!pci_aer_in_progress(pci_dev) && !pci_dev->state_saved) {
| ^~~~~~~~~~~~~~~~~~~
include/linux/compiler.h:57:52: note: in definition of macro '__trace_if_var'
57 | #define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : __trace_if_value(cond))
| ^~~~
drivers/pci/pci-driver.c:887:9: note: in expansion of macro 'if'
887 | if (!pci_aer_in_progress(pci_dev) && !pci_dev->state_saved) {
| ^~
vim +/pci_aer_in_progress +887 drivers/pci/pci-driver.c
851
852 static int pci_pm_suspend_noirq(struct device *dev)
853 {
854 struct pci_dev *pci_dev = to_pci_dev(dev);
855 const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
856
857 if (dev_pm_skip_suspend(dev))
858 return 0;
859
860 if (pci_has_legacy_pm_support(pci_dev))
861 return pci_legacy_suspend_late(dev);
862
863 if (!pm) {
864 pci_save_state(pci_dev);
865 goto Fixup;
866 }
867
868 if (pm->suspend_noirq) {
869 pci_power_t prev = pci_dev->current_state;
870 int error;
871
872 error = pm->suspend_noirq(dev);
873 suspend_report_result(dev, pm->suspend_noirq, error);
874 if (error)
875 return error;
876
877 if (!pci_dev->state_saved && pci_dev->current_state != PCI_D0
878 && pci_dev->current_state != PCI_UNKNOWN) {
879 pci_WARN_ONCE(pci_dev, pci_dev->current_state != prev,
880 "PCI PM: State of device not saved by %pS\n",
881 pm->suspend_noirq);
882 goto Fixup;
883 }
884 }
885
886 /* Avoid suspending the device with errors */
> 887 if (!pci_aer_in_progress(pci_dev) && !pci_dev->state_saved) {
888 pci_save_state(pci_dev);
889
890 /*
891 * If the device is a bridge with a child in D0 below it,
892 * it needs to stay in D0, so check skip_bus_pm to avoid
893 * putting it into a low-power state in that case.
894 */
895 if (!pci_dev->skip_bus_pm && pci_power_manageable(pci_dev))
896 pci_prepare_to_sleep(pci_dev);
897 }
898
899 pci_dbg(pci_dev, "PCI PM: Suspend power state: %s\n",
900 pci_power_name(pci_dev->current_state));
901
902 if (pci_dev->current_state == PCI_D0) {
903 pci_dev->skip_bus_pm = true;
904 /*
905 * Per PCI PM r1.2, table 6-1, a bridge must be in D0 if any
906 * downstream device is in D0, so avoid changing the power state
907 * of the parent bridge by setting the skip_bus_pm flag for it.
908 */
909 if (pci_dev->bus->self)
910 pci_dev->bus->self->skip_bus_pm = true;
911 }
912
913 if (pci_dev->skip_bus_pm && pm_suspend_no_platform()) {
914 pci_dbg(pci_dev, "PCI PM: Skipped\n");
915 goto Fixup;
916 }
917
918 pci_pm_set_unknown_state(pci_dev);
919
920 /*
921 * Some BIOSes from ASUS have a bug: If a USB EHCI host controller's
922 * PCI COMMAND register isn't 0, the BIOS assumes that the controller
923 * hasn't been quiesced and tries to turn it off. If the controller
924 * is already in D3, this can hang or cause memory corruption.
925 *
926 * Since the value of the COMMAND register doesn't matter once the
927 * device has been suspended, we can safely set it to 0 here.
928 */
929 if (pci_dev->class == PCI_CLASS_SERIAL_USB_EHCI)
930 pci_write_config_word(pci_dev, PCI_COMMAND, 0);
931
932 Fixup:
933 pci_fixup_device(pci_fixup_suspend_late, pci_dev);
934
935 /*
936 * If the target system sleep state is suspend-to-idle, it is sufficient
937 * to check whether or not the device's wakeup settings are good for
938 * runtime PM. Otherwise, the pm_resume_via_firmware() check will cause
939 * pci_pm_complete() to take care of fixing up the device's state
940 * anyway, if need be.
941 */
942 if (device_can_wakeup(dev) && !device_may_wakeup(dev))
943 dev->power.may_skip_resume = false;
944
945 return 0;
946 }
947
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
next prev parent reply other threads:[~2025-04-22 18:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-22 13:53 [PATCH v2] PCI/PM: Avoid suspending the device with errors Raag Jadav
2025-04-22 18:01 ` kernel test robot [this message]
2025-04-22 19:45 ` Bjorn Helgaas
2025-04-24 5:12 ` Raag Jadav
2025-04-24 10:59 ` Rafael J. Wysocki
2025-04-26 19:24 ` Raag Jadav
2025-04-22 23:39 ` kernel test robot
2025-04-23 12:41 ` Rafael J. Wysocki
2025-04-24 5:38 ` Raag Jadav
2025-04-24 11:02 ` Rafael J. Wysocki
2025-04-26 20:18 ` Raag Jadav
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202504230101.o7uTJFn5-lkp@intel.com \
--to=lkp@intel.com \
--cc=aravind.iddamsetty@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mahesh@linux.ibm.com \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=oohall@gmail.com \
--cc=raag.jadav@intel.com \
--cc=rafael@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.