03 Sep, 2019

1 commit

  • In acpi_pci_irq_enable(), 'entry' is allocated by kzalloc() in
    acpi_pci_irq_check_entry() (invoked from acpi_pci_irq_lookup()). However,
    it is not deallocated if acpi_pci_irq_valid() returns false, leading to a
    memory leak. To fix this issue, free 'entry' before returning 0.

    Fixes: e237a5518425 ("x86/ACPI/PCI: Recognize that Interrupt Line 255 means "not connected"")
    Signed-off-by: Wenwen Wang
    Signed-off-by: Rafael J. Wysocki

    Wenwen Wang
     

31 May, 2019

1 commit

  • Based on 3 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 of the license or at
    your option any later version this program is distributed in the
    hope that it will be useful but without any warranty without even
    the implied warranty of merchantability or fitness for a particular
    purpose see the gnu general public license for more details

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 of the license or at
    your option any later version [author] [kishon] [vijay] [abraham]
    [i] [kishon]@[ti] [com] this program is distributed in the hope that
    it will be useful but without any warranty without even the implied
    warranty of merchantability or fitness for a particular purpose see
    the gnu general public license for more details

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 of the license or at
    your option any later version [author] [graeme] [gregory]
    [gg]@[slimlogic] [co] [uk] [author] [kishon] [vijay] [abraham] [i]
    [kishon]@[ti] [com] [based] [on] [twl6030]_[usb] [c] [author] [hema]
    [hk] [hemahk]@[ti] [com] this program is distributed in the hope
    that it will be useful but without any warranty without even the
    implied warranty of merchantability or fitness for a particular
    purpose see the gnu general public license for more details

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-or-later

    has been chosen to replace the boilerplate/reference in 1105 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Reviewed-by: Richard Fontana
    Reviewed-by: Kate Stewart
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190527070033.202006027@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

10 Sep, 2016

1 commit

  • On ACPI ARM based systems the GIC interrupt controller
    and corresponding interrupt model permit only the high
    polarity for level interrupts.

    ACPI firmware describes PCI legacy IRQs through entries
    in the _PRT objects. Entries in the _PRT can be of two types:

    - Static: not configurable, trigger/polarity default to level-low,
    _PRT entry defines the global GSI interrupt number
    - Configurable: _PRT interrupt entry contains a reference to the
    corresponding PCI interrupt link device (that in turn provides the
    interrupt descriptor through its _CRS/_PRS methods)

    Configurable IRQ entries are not currently allowed by the ACPI
    specification on ARM since they can only be used for interrupt pins that
    are routable, as per ACPI specifications (version 6.1, 6.2.13):

    "[...] There are two ways that _PRT can be used. Typically, the
    interrupt input that a given PCI interrupt is on is configurable. For
    example, a given PCI interrupt might be configured for either IRQ 10 or
    11 on an 8259 interrupt controller. In this model, each interrupt is
    represented in the ACPI namespace as a PCI Interrupt Link Device. [...]"

    ARM platforms GIC configurations do not allow dynamic IRQ routing,
    since routing is statically laid out at synthesis time; therefore PCI
    interrupt links cannot be used for PCI legacy IRQ descriptions in the
    _PRT on ARM systems.

    On the other hand, current core ACPI code handling PCI legacy IRQs
    consider IRQ trigger/polarity for static _PRT entries as level-low.

    On ARM systems with a GIC interrupt controller and corresponding
    ACPI interrupt model this does not work in that GIC interrupt
    controller is only capable of handling level interrupts whose
    polarity is high (for PCI legacy IRQs - that are level-low by
    specification - this means that the legacy IRQs are inverted before
    reaching the interrupt controller pin), resulting in IRQ allocation
    failures such as:

    genirq: Setting trigger mode 8 for irq 18 failed (gic_set_type+0x0/0x48)

    Change the default polarity for PCI legacy IRQs to high on systems
    booting wth ACPI on platforms with a GIC interrupt controller model,
    fixing the discrepancy between specification and HW behaviour.

    Signed-off-by: Lorenzo Pieralisi
    Acked-by: Marc Zyngier
    Tested-by: Duc Dang
    Signed-off-by: Rafael J. Wysocki

    Lorenzo Pieralisi
     

09 Mar, 2016

1 commit

  • Per the x86-specific footnote to PCI spec r3.0, sec 6.2.4, the value 255 in
    the Interrupt Line register means "unknown" or "no connection."
    Previously, when we couldn't derive an IRQ from the _PRT, we fell back to
    using the value from Interrupt Line as an IRQ. It's questionable whether
    we should do that at all, but the spec clearly suggests we shouldn't do it
    for the value 255 on x86.

    Calling request_irq() with IRQ 255 may succeed, but the driver won't
    receive any interrupts. Or, if IRQ 255 is shared with another device, it
    may succeed, and the driver's ISR will be called at random times when the
    *other* device interrupts. Or it may fail if another device is using IRQ
    255 with incompatible flags. What we *want* is for request_irq() to fail
    predictably so the driver can fall back to polling.

    On x86, assume 255 in the Interrupt Line means the INTx line is not
    connected. In that case, set dev->irq to IRQ_NOTCONNECTED so request_irq()
    will fail gracefully with -ENOTCONN.

    We found this problem on a system where Secure Boot firmware assigned
    Interrupt Line 255 to an i801_smbus device and another device was already
    using MSI-X IRQ 255. This was in v3.10, where i801_probe() fails if
    request_irq() fails:

    i801_smbus 0000:00:1f.3: enabling device (0140 -> 0143)
    i801_smbus 0000:00:1f.3: can't derive routing for PCI INT C
    i801_smbus 0000:00:1f.3: PCI INT C: no GSI
    genirq: Flags mismatch irq 255. 00000080 (i801_smbus) vs. 00000000 (megasa)
    CPU: 0 PID: 2487 Comm: kworker/0:1 Not tainted 3.10.0-229.el7.x86_64 #1
    Hardware name: FUJITSU PRIMEQUEST 2800E2/D3736, BIOS PRIMEQUEST 2000 Serie5
    Call Trace:
    dump_stack+0x19/0x1b
    __setup_irq+0x54a/0x570
    request_threaded_irq+0xcc/0x170
    i801_probe+0x32f/0x508 [i2c_i801]
    local_pci_probe+0x45/0xa0
    i801_smbus 0000:00:1f.3: Failed to allocate irq 255: -16
    i801_smbus: probe of 0000:00:1f.3 failed with error -16

    After aeb8a3d16ae0 ("i2c: i801: Check if interrupts are disabled"),
    i801_probe() will fall back to polling if request_irq() fails. But we
    still need this patch because request_irq() may succeed or fail depending
    on other devices in the system. If request_irq() fails, i801_smbus will
    work by falling back to polling, but if it succeeds, i801_smbus won't work
    because it expects interrupts that it may not receive.

    Signed-off-by: Chen Fan
    Acked-by: Thomas Gleixner
    Acked-by: Bjorn Helgaas
    Signed-off-by: Rafael J. Wysocki

    Chen Fan
     

27 Feb, 2016

1 commit

  • 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and
    pcibios_free_irq()") appeared in v4.3 and helps support IOAPIC hotplug.

    Олег reported that the Elcus-1553 TA1-PCI driver worked in v4.2 but not
    v4.3 and bisected it to 991de2e59090. Sunjin reported that the RocketRAID
    272x driver worked in v4.2 but not v4.3. In both cases booting with
    "pci=routirq" is a workaround.

    I think the problem is that after 991de2e59090, we no longer call
    pcibios_enable_irq() for upstream bridges. Prior to 991de2e59090, when a
    driver called pci_enable_device(), we recursively called
    pcibios_enable_irq() for upstream bridges via pci_enable_bridge().

    After 991de2e59090, we call pcibios_enable_irq() from pci_device_probe()
    instead of the pci_enable_device() path, which does *not* call
    pcibios_enable_irq() for upstream bridges.

    Revert 991de2e59090 to fix these driver regressions.

    Link: https://bugzilla.kernel.org/show_bug.cgi?id=111211
    Fixes: 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()")
    Reported-and-tested-by: Олег Мороз
    Reported-by: Sunjin Yang
    Signed-off-by: Bjorn Helgaas
    Acked-by: Rafael J. Wysocki
    CC: Jiang Liu

    Bjorn Helgaas
     

18 Feb, 2016

1 commit

  • Revert 811a4e6fce09 ("PCI: Add helpers to manage pci_dev->irq and
    pci_dev->irq_managed").

    This is part of reverting 991de2e59090 ("PCI, x86: Implement
    pcibios_alloc_irq() and pcibios_free_irq()") to fix regressions it
    introduced.

    Link: https://bugzilla.kernel.org/show_bug.cgi?id=111211
    Fixes: 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()")
    Signed-off-by: Bjorn Helgaas
    Acked-by: Rafael J. Wysocki
    CC: Jiang Liu

    Bjorn Helgaas
     

05 Jan, 2016

1 commit


26 Sep, 2015

1 commit

  • Avoid IRQs occupied by ISA IRQs when allocating IRQs for PCI link devices,
    otherwise it may cause interrupt storm due to incompatible pin attributes.

    This issue was triggered on a KVM virtual machine, which
    1) uses IRQ9 for SCI in high level mode.
    2) defines an PCI interrupt link device (LNKS) with IRQ9 as the only
    possible irq.
    3) has an PCI device referring to link device LNKS.
    So it causes interrupt storm when enabling the PCI device because PCI IRQ
    works in low level mode.

    Signed-off-by: Jiang Liu
    Acked-by: Bjorn Helgaas
    Signed-off-by: Rafael J. Wysocki

    Jiang Liu
     

02 Sep, 2015

1 commit

  • Pull power management and ACPI updates from Rafael Wysocki:
    "From the number of commits perspective, the biggest items are ACPICA
    and cpufreq changes with the latter taking the lead (over 50 commits).

    On the cpufreq front, there are many cleanups and minor fixes in the
    core and governors, driver updates etc. We also have a new cpufreq
    driver for Mediatek MT8173 chips.

    ACPICA mostly updates its debug infrastructure and adds a number of
    fixes and cleanups for a good measure.

    The Operating Performance Points (OPP) framework is updated with new
    DT bindings and support for them among other things.

    We have a few updates of the generic power domains framework and a
    reorganization of the ACPI device enumeration code and bus type
    operations.

    And a lot of fixes and cleanups all over.

    Included is one branch from the MFD tree as it contains some
    PM-related driver core and ACPI PM changes a few other commits are
    based on.

    Specifics:

    - ACPICA update to upstream revision 20150818 including method
    tracing extensions to allow more in-depth AML debugging in the
    kernel and a number of assorted fixes and cleanups (Bob Moore, Lv
    Zheng, Markus Elfring).

    - ACPI sysfs code updates and a documentation update related to AML
    method tracing (Lv Zheng).

    - ACPI EC driver fix related to serialized evaluations of _Qxx
    methods and ACPI tools updates allowing the EC userspace tool to be
    built from the kernel source (Lv Zheng).

    - ACPI processor driver updates preparing it for future introduction
    of CPPC support and ACPI PCC mailbox driver updates (Ashwin
    Chaugule).

    - ACPI interrupts enumeration fix for a regression related to the
    handling of IRQ attribute conflicts between MADT and the ACPI
    namespace (Jiang Liu).

    - Fixes related to ACPI device PM (Mika Westerberg, Srinidhi
    Kasagar).

    - ACPI device registration code reorganization to separate the
    sysfs-related code and bus type operations from the rest (Rafael J
    Wysocki).

    - Assorted cleanups in the ACPI core (Jarkko Nikula, Mathias Krause,
    Andy Shevchenko, Rafael J Wysocki, Nicolas Iooss).

    - ACPI cpufreq driver and ia64 cpufreq driver fixes and cleanups (Pan
    Xinhui, Rafael J Wysocki).

    - cpufreq core cleanups on top of the previous changes allowing it to
    preseve its sysfs directories over system suspend/resume (Viresh
    Kumar, Rafael J Wysocki, Sebastian Andrzej Siewior).

    - cpufreq fixes and cleanups related to governors (Viresh Kumar).

    - cpufreq updates (core and the cpufreq-dt driver) related to the
    turbo/boost mode support (Viresh Kumar, Bartlomiej Zolnierkiewicz).

    - New DT bindings for Operating Performance Points (OPP), support for
    them in the OPP framework and in the cpufreq-dt driver plus related
    OPP framework fixes and cleanups (Viresh Kumar).

    - cpufreq powernv driver updates (Shilpasri G Bhat).

    - New cpufreq driver for Mediatek MT8173 (Pi-Cheng Chen).

    - Assorted cpufreq driver (speedstep-lib, sfi, integrator) cleanups
    and fixes (Abhilash Jindal, Andrzej Hajda, Cristian Ardelean).

    - intel_pstate driver updates including Skylake-S support, support
    for enabling HW P-states per CPU and an additional vendor bypass
    list entry (Kristen Carlson Accardi, Chen Yu, Ethan Zhao).

    - cpuidle core fixes related to the handling of coupled idle states
    (Xunlei Pang).

    - intel_idle driver updates including Skylake Client support and
    support for freeze-mode-specific idle states (Len Brown).

    - Driver core updates related to power management (Andy Shevchenko,
    Rafael J Wysocki).

    - Generic power domains framework fixes and cleanups (Jon Hunter,
    Geert Uytterhoeven, Rajendra Nayak, Ulf Hansson).

    - Device PM QoS framework update to allow the latency tolerance
    setting to be exposed to user space via sysfs (Mika Westerberg).

    - devfreq support for PPMUv2 in Exynos5433 and a fix for an incorrect
    exynos-ppmu DT binding (Chanwoo Choi, Javier Martinez Canillas).

    - System sleep support updates (Alan Stern, Len Brown, SungEun Kim).

    - rockchip-io AVS support updates (Heiko Stuebner).

    - PM core clocks support fixup (Colin Ian King).

    - Power capping RAPL driver update including support for Skylake H/S
    and Broadwell-H (Radivoje Jovanovic, Seiichi Ikarashi).

    - Generic device properties framework fixes related to the handling
    of static (driver-provided) property sets (Andy Shevchenko).

    - turbostat and cpupower updates (Len Brown, Shilpasri G Bhat,
    Shreyas B Prabhu)"

    * tag 'pm+acpi-4.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (180 commits)
    cpufreq: speedstep-lib: Use monotonic clock
    cpufreq: powernv: Increase the verbosity of OCC console messages
    cpufreq: sfi: use kmemdup rather than duplicating its implementation
    cpufreq: drop !cpufreq_driver check from cpufreq_parse_governor()
    cpufreq: rename cpufreq_real_policy as cpufreq_user_policy
    cpufreq: remove redundant 'policy' field from user_policy
    cpufreq: remove redundant 'governor' field from user_policy
    cpufreq: update user_policy.* on success
    cpufreq: use memcpy() to copy policy
    cpufreq: remove redundant CPUFREQ_INCOMPATIBLE notifier event
    cpufreq: mediatek: Add MT8173 cpufreq driver
    dt-bindings: mediatek: Add MT8173 CPU DVFS clock bindings
    PM / Domains: Fix typo in description of genpd_dev_pm_detach()
    PM / Domains: Remove unusable governor dummies
    PM / Domains: Make pm_genpd_init() available to modules
    PM / domains: Align column headers and data in pm_genpd_summary output
    powercap / RAPL: disable the 2nd power limit properly
    tools: cpupower: Fix error when running cpupower monitor
    PM / OPP: Drop unlikely before IS_ERR(_OR_NULL)
    PM / OPP: Fix static checker warning (broken 64bit big endian systems)
    ...

    Linus Torvalds
     

31 Jul, 2015

2 commits


08 Jul, 2015

1 commit


24 Jun, 2015

1 commit

  • Pull power management and ACPI updates from Rafael Wysocki:
    "The rework of backlight interface selection API from Hans de Goede
    stands out from the number of commits and the number of affected
    places perspective. The cpufreq core fixes from Viresh Kumar are
    quite significant too as far as the number of commits goes and because
    they should reduce CPU online/offline overhead quite a bit in the
    majority of cases.

    From the new featues point of view, the ACPICA update (to upstream
    revision 20150515) adding support for new ACPI 6 material to ACPICA is
    the one that matters the most as some new significant features will be
    based on it going forward. Also included is an update of the ACPI
    device power management core to follow ACPI 6 (which in turn reflects
    the Windows' device PM implementation), a PM core extension to support
    wakeup interrupts in a more generic way and support for the ACPI _CCA
    device configuration object.

    The rest is mostly fixes and cleanups all over and some documentation
    updates, including new DT bindings for Operating Performance Points.

    There is one fix for a regression introduced in the 4.1 cycle, but it
    adds quite a number of lines of code, it wasn't really ready before
    Thursday and you were on vacation, so I refrained from pushing it on
    the last minute for 4.1.

    Specifics:

    - ACPICA update to upstream revision 20150515 including basic support
    for ACPI 6 features: new ACPI tables introduced by ACPI 6 (STAO,
    XENV, WPBT, NFIT, IORT), changes related to the other tables (DTRM,
    FADT, LPIT, MADT), new predefined names (_BTH, _CR3, _DSD, _LPI,
    _MTL, _PRR, _RDI, _RST, _TFP, _TSN), fixes and cleanups (Bob Moore,
    Lv Zheng).

    - ACPI device power management core code update to follow ACPI 6
    which reflects the ACPI device power management implementation in
    Windows (Rafael J Wysocki).

    - rework of the backlight interface selection logic to reduce the
    number of kernel command line options and improve the handling of
    DMI quirks that may be involved in that and to make the code
    generally more straightforward (Hans de Goede).

    - fixes for the ACPI Embedded Controller (EC) driver related to the
    handling of EC transactions (Lv Zheng).

    - fix for a regression related to the ACPI resources management and
    resulting from a recent change of ACPI initialization code ordering
    (Rafael J Wysocki).

    - fix for a system initialization regression related to ACPI
    introduced during the 3.14 cycle and caused by running the code
    that switches the platform over to the ACPI mode too early in the
    initialization sequence (Rafael J Wysocki).

    - support for the ACPI _CCA device configuration object related to
    DMA cache coherence (Suravee Suthikulpanit).

    - ACPI/APEI fixes and cleanups (Jiri Kosina, Borislav Petkov).

    - ACPI battery driver cleanups (Luis Henriques, Mathias Krause).

    - ACPI processor driver cleanups (Hanjun Guo).

    - cleanups and documentation update related to the ACPI device
    properties interface based on _DSD (Rafael J Wysocki).

    - ACPI device power management fixes (Rafael J Wysocki).

    - assorted cleanups related to ACPI (Dominik Brodowski, Fabian
    Frederick, Lorenzo Pieralisi, Mathias Krause, Rafael J Wysocki).

    - fix for a long-standing issue causing General Protection Faults to
    be generated occasionally on return to user space after resume from
    ACPI-based suspend-to-RAM on 32-bit x86 (Ingo Molnar).

    - fix to make the suspend core code return -EBUSY consistently in all
    cases when system suspend is aborted due to wakeup detection (Ruchi
    Kandoi).

    - support for automated device wakeup IRQ handling allowing drivers
    to make their PM support more starightforward (Tony Lindgren).

    - new tracepoints for suspend-to-idle tracing and rework of the
    prepare/complete callbacks tracing in the PM core (Todd E Brandt,
    Rafael J Wysocki).

    - wakeup sources framework enhancements (Jin Qian).

    - new macro for noirq system PM callbacks (Grygorii Strashko).

    - assorted cleanups related to system suspend (Rafael J Wysocki).

    - cpuidle core cleanups to make the code more efficient (Rafael J
    Wysocki).

    - powernv/pseries cpuidle driver update (Shilpasri G Bhat).

    - cpufreq core fixes related to CPU online/offline that should reduce
    the overhead of these operations quite a bit, unless the CPU in
    question is physically going away (Viresh Kumar, Saravana Kannan).

    - serialization of cpufreq governor callbacks to avoid race
    conditions in some cases (Viresh Kumar).

    - intel_pstate driver fixes and cleanups (Doug Smythies, Prarit
    Bhargava, Joe Konno).

    - cpufreq driver (arm_big_little, cpufreq-dt, qoriq) updates (Sudeep
    Holla, Felipe Balbi, Tang Yuantian).

    - assorted cleanups in cpufreq drivers and core (Shailendra Verma,
    Fabian Frederick, Wang Long).

    - new Device Tree bindings for representing Operating Performance
    Points (Viresh Kumar).

    - updates for the common clock operations support code in the PM core
    (Rajendra Nayak, Geert Uytterhoeven).

    - PM domains core code update (Geert Uytterhoeven).

    - Intel Knights Landing support for the RAPL (Running Average Power
    Limit) power capping driver (Dasaratharaman Chandramouli).

    - fixes related to the floor frequency setting on Atom SoCs in the
    RAPL power capping driver (Ajay Thomas).

    - runtime PM framework documentation update (Ben Dooks).

    - cpupower tool fix (Herton R Krzesinski)"

    * tag 'pm+acpi-4.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (194 commits)
    cpuidle: powernv/pseries: Auto-promotion of snooze to deeper idle state
    x86: Load __USER_DS into DS/ES after resume
    PM / OPP: Add binding for 'opp-suspend'
    PM / OPP: Allow multiple OPP tables to be passed via DT
    PM / OPP: Add new bindings to address shortcomings of existing bindings
    ACPI: Constify ACPI device IDs in documentation
    ACPI / enumeration: Document the rules regarding the PRP0001 device ID
    ACPI / video: Make acpi_video_unregister_backlight() private
    acpi-video-detect: Remove old API
    toshiba-acpi: Port to new backlight interface selection API
    thinkpad-acpi: Port to new backlight interface selection API
    sony-laptop: Port to new backlight interface selection API
    samsung-laptop: Port to new backlight interface selection API
    msi-wmi: Port to new backlight interface selection API
    msi-laptop: Port to new backlight interface selection API
    intel-oaktrail: Port to new backlight interface selection API
    ideapad-laptop: Port to new backlight interface selection API
    fujitsu-laptop: Port to new backlight interface selection API
    eeepc-laptop: Port to new backlight interface selection API
    dell-wmi: Port to new backlight interface selection API
    ...

    Linus Torvalds
     

31 May, 2015

1 commit

  • The PCIe specification, rev 3.0, section 2.2.8.1, contains the following
    implementation note:

    Virtual Wire Mapping for INTx Interrupts From ARI Devices

    The implied Device Number for an ARI Device is 0. When ARI-aware
    software (including BIOS and operating system) enables ARI Forwarding in
    the Downstream Port immediately above an ARI Device in order to access
    its Extended Functions, software must comprehend that the Downstream Port
    will use Device Number 0 for the virtual wire mappings of INTx interrupts
    coming from all Functions of the ARI Device. If non-ARI-aware software
    attempts to determine the virtual wire mappings for Extended Functions,
    it can come up with incorrect mappings by examining the traditional
    Device Number field and finding it to be non-0.

    We account for this in pci_swizzle_interrupt_pin(), but it looks like we
    miss it here, looking for a _PRT entry with a slot matching the ARI device
    slot number. This can cause errors like:

    pcieport 0000:80:03.0: can't derive routing for PCI INT B
    sfc 0000:82:01.1: PCI INT B: no GSI

    pci_dev.irq is then invalid, resulting in errors for drivers that attempt
    to enable INTx on the device. Fix by using slot 0 for ARI enabled devices.

    Signed-off-by: Alex Williamson
    Signed-off-by: Bjorn Helgaas
    Reviewed-by: Don Dutile
    Acked-by: Rafael J. Wysocki

    Alex Williamson
     

22 May, 2015

1 commit

  • list_head "list" in struct acpi_prt_entry was used to connect
    _PRT entries for PCI irq, but after commit 181380b702ee ("PCI/ACPI:
    Don't cache _PRT, and don't associate them with bus numbers"),
    the list head for _PRT entries was removed, but left "list" in
    struct acpi_prt_entry which is useless and stale, remove it now.

    Signed-off-by: Hanjun Guo
    Acked-by: Bjorn Helgaas
    Signed-off-by: Rafael J. Wysocki

    Hanjun Guo
     

20 Mar, 2015

1 commit

  • Commit b4b55cda5874 (Refine the way to release PCI IRQ resources)
    introduced a regression in the PCI IRQ resource management by causing
    the IRQ resource of a device, established when pci_enabled_device()
    is called on a fully disabled device, to be released when the driver
    is unbound from the device, regardless of the enable_cnt.

    This leads to the situation that an ill-behaved driver can now make a
    device unusable to subsequent drivers by an imbalance in their use of
    pci_enable/disable_device(). That is a serious problem for secondary
    drivers like vfio-pci, which are innocent of the transgressions of
    the previous driver.

    Since the solution of this problem is not immediate and requires
    further discussion, revert commit b4b55cda5874 and the issue it was
    supposed to address (a bug related to xen-pciback) will be taken
    care of in a different way going forward.

    Reported-by: Alex Williamson
    Signed-off-by: Rafael J. Wysocki

    Rafael J. Wysocki
     

05 Feb, 2015

1 commit

  • Some PCI device drivers assume that pci_dev->irq won't change after
    calling pci_disable_device() and pci_enable_device() during suspend and
    resume.

    Commit c03b3b0738a5 ("x86, irq, mpparse: Release IOAPIC pin when
    PCI device is disabled") frees PCI IRQ resources when pci_disable_device()
    is called and reallocate IRQ resources when pci_enable_device() is
    called again. This breaks above assumption. So commit 3eec595235c1
    ("x86, irq, PCI: Keep IRQ assignment for PCI devices during
    suspend/hibernation") and 9eabc99a635a ("x86, irq, PCI: Keep IRQ
    assignment for runtime power management") fix the issue by avoiding
    freeing/reallocating IRQ resources during PCI device suspend/resume.
    They achieve this by checking dev.power.is_prepared and
    dev.power.runtime_status. PM maintainer, Rafael, then pointed out that
    it's really an ugly fix which leaking PM internal state information to
    IRQ subsystem.

    Recently David Vrabel also reports an
    regression in pciback driver caused by commit cffe0a2b5a34 ("x86, irq:
    Keep balance of IOAPIC pin reference count"). Please refer to:
    http://lkml.org/lkml/2015/1/14/546

    So this patch refine the way to release PCI IRQ resources. Instead of
    releasing PCI IRQ resources in pci_disable_device()/
    pcibios_disable_device(), we now release it at driver unbinding
    notification BUS_NOTIFY_UNBOUND_DRIVER. In other word, we only release
    PCI IRQ resources when there's no driver bound to the PCI device, and
    it keeps the assumption that pci_dev->irq won't through multiple
    invocation of pci_enable_device()/pci_disable_device().

    Signed-off-by: Jiang Liu
    Signed-off-by: Rafael J. Wysocki

    Jiang Liu
     

20 Jan, 2015

1 commit

  • Xen pciback driver assumes that pci_dev->irq won't change after calling
    pci_disable_device(). But commit cffe0a2b5a34c95a4dadc9ec7132690a5b0f6687
    ("x86, irq: Keep balance of IOAPIC pin reference count") frees irq
    resources and resets pci_dev->irq to zero when pci_disable_device() is
    called.

    So this is a hotfix for 3.19 to avoid resetting pci_dev->irq, and
    another proper fix will be prepared for next merging window.

    Signed-off-by: Jiang Liu
    Tested-by: Sander Eikelenboom
    Cc: Tony Luck
    Cc: Konrad Rzeszutek Wilk
    Cc: David Vrabel
    Cc: Rafael J. Wysocki
    Cc: Len Brown
    Link: http://lkml.kernel.org/r/1421720467-7709-3-git-send-email-jiang.liu@linux.intel.com
    Signed-off-by: Thomas Gleixner

    Jiang Liu
     

20 Dec, 2014

1 commit

  • Pull x86 apic updates from Thomas Gleixner:
    "After stopping the full x86/apic branch, I took some time to go
    through the first block of patches again, which are mostly cleanups
    and preparatory work for the irqdomain conversion and ioapic hotplug
    support.

    Unfortunaly one of the real problematic commits was right at the
    beginning, so I rebased this portion of the pending patches without
    the offenders.

    It would be great to get this into 3.19. That makes reworking the
    problematic parts simpler. The usual tip testing did not unearth any
    issues and it is fully bisectible now.

    I'm pretty confident that this wont affect the calmness of the xmas
    season.

    Changes:
    - Split the convoluted io_apic.c code into domain specific parts
    (vector, ioapic, msi, htirq)
    - Introduce proper helper functions to retrieve irq specific data
    instead of open coded dereferencing of pointers
    - Preparatory work for ioapic hotplug and irqdomain conversion
    - Removal of the non functional pci-ioapic driver
    - Removal of unused irq entry stubs
    - Make native_smp_prepare_cpus() preemtible to avoid GFP_ATOMIC
    allocations for everything which is called from there.
    - Small cleanups and fixes"

    * 'x86-apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (36 commits)
    iommu/amd: Use helpers to access irq_cfg data structure associated with IRQ
    iommu/vt-d: Use helpers to access irq_cfg data structure associated with IRQ
    x86: irq_remapping: Use helpers to access irq_cfg data structure associated with IRQ
    x86, irq: Use helpers to access irq_cfg data structure associated with IRQ
    x86, irq: Make MSI and HT_IRQ indepenent of X86_IO_APIC
    x86, irq: Move IRQ initialization routines from io_apic.c into vector.c
    x86, irq: Move IOAPIC related declarations from hw_irq.h into io_apic.h
    x86, irq: Move HT IRQ related code from io_apic.c into htirq.c
    x86, irq: Move PCI MSI related code from io_apic.c into msi.c
    x86, irq: Replace printk(KERN_LVL) with pr_lvl() utilities
    x86, irq: Make UP version of irq_complete_move() an inline stub
    x86, irq: Move local APIC related code from io_apic.c into vector.c
    x86, irq: Introduce helpers to access struct irq_cfg
    x86, irq: Protect __clear_irq_vector() with vector_lock
    x86, irq: Rename local APIC related functions in io_apic.c as apic_xxx()
    x86, irq: Refine hw_irq.h to prepare for irqdomain support
    x86, irq: Convert irq_2_pin list to generic list
    x86, irq: Kill useless parameter 'irq_attr' of IO_APIC_get_PCI_irq_vector()
    x86, irq, acpi: Get rid of special handling of GSI for ACPI SCI
    x86, irq: Introduce helper to check whether an IOAPIC has been registered
    ...

    Linus Torvalds
     

16 Dec, 2014

1 commit

  • To keep balance of IOAPIC pin reference count, we need to protect
    pirq_enable_irq(), acpi_pci_irq_enable() and intel_mid_pci_irq_enable()
    from reentrance. There are two cases which will cause reentrance.

    The first case is caused by suspend/hibernation. If pcibios_disable_irq
    is called during suspending/hibernating, we don't release the assigned
    IRQ number, otherwise it may break the suspend/hibernation. So late when
    pcibios_enable_irq is called during resume, we shouldn't allocate IRQ
    number again.

    The second case is that function acpi_pci_irq_enable() may be called
    twice for PCI devices present at boot time as below:
    1) pci_acpi_init()
    --> acpi_pci_irq_enable() if pci_routeirq is true
    2) pci_enable_device()
    --> pcibios_enable_device()
    --> acpi_pci_irq_enable()
    We can't kill kernel parameter pci_routeirq yet because it's still
    needed for debugging purpose.

    So flag irq_managed is introduced to track whether IRQ number is
    assigned by OS and to protect pirq_enable_irq(), acpi_pci_irq_enable()
    and intel_mid_pci_irq_enable() from reentrance.

    Signed-off-by: Jiang Liu
    Cc: Konrad Rzeszutek Wilk
    Cc: Tony Luck
    Cc: Joerg Roedel
    Cc: Greg Kroah-Hartman
    Cc: Benjamin Herrenschmidt
    Cc: Rafael J. Wysocki
    Cc: Bjorn Helgaas
    Cc: Randy Dunlap
    Cc: Yinghai Lu
    Cc: Borislav Petkov
    Cc: Len Brown
    Link: http://lkml.kernel.org/r/1414387308-27148-13-git-send-email-jiang.liu@linux.intel.com
    Signed-off-by: Thomas Gleixner

    Jiang Liu
     

04 Dec, 2014

1 commit


29 Aug, 2014

1 commit

  • Now IOAPIC driver dynamically allocates IRQ numbers for IOAPIC pins.
    We need to keep IRQ assignment for PCI devices during runtime power
    management, otherwise it may cause failure of device wakeups.

    Commit 3eec595235c17a7 "x86, irq, PCI: Keep IRQ assignment for PCI
    devices during suspend/hibernation" has fixed the issue for suspend/
    hibernation, we also need the same fix for runtime device sleep too.

    Fix: https://bugzilla.kernel.org/show_bug.cgi?id=83271
    Reported-and-Tested-by: EmanueL Czirai
    Signed-off-by: Jiang Liu
    Cc: Konrad Rzeszutek Wilk
    Cc: Tony Luck
    Cc: Joerg Roedel
    Cc: Greg Kroah-Hartman
    Cc: EmanueL Czirai
    Cc: Benjamin Herrenschmidt
    Cc: Rafael J. Wysocki
    Cc: Bjorn Helgaas
    Cc: Randy Dunlap
    Cc: Yinghai Lu
    Cc: Borislav Petkov
    Cc: Grant Likely
    Link: http://lkml.kernel.org/r/1409304383-18806-1-git-send-email-jiang.liu@linux.intel.com
    Signed-off-by: Thomas Gleixner

    Jiang Liu
     

08 Aug, 2014

1 commit

  • Now IOAPIC driver dynamically allocates IRQ numbers for IOAPIC pins.
    We need to keep IRQ assignment for PCI devices during suspend/hibernation,
    otherwise it may cause failure of suspend/hibernation due to:
    1) Device driver calls pci_enable_device() to allocate an IRQ number
    and register interrupt handler on the returned IRQ.
    2) Device driver's suspend callback calls pci_disable_device() and
    release assigned IRQ in turn.
    3) Device driver's resume callback calls pci_enable_device() to
    allocate IRQ number again. A different IRQ number may be assigned
    by IOAPIC driver this time.
    4) Now the hardware delivers interrupt to the new IRQ but interrupt
    handler is still registered against the old IRQ, so it breaks
    suspend/hibernation.

    To fix this issue, we keep IRQ assignment during suspend/hibernation.
    Flag pci_dev.dev.power.is_prepared is used to detect that
    pci_disable_device() is called during suspend/hibernation.

    Reported-and-Tested-by: Borislav Petkov
    Signed-off-by: Jiang Liu
    Cc: Konrad Rzeszutek Wilk
    Cc: Tony Luck
    Cc: Joerg Roedel
    Cc: Greg Kroah-Hartman
    Cc: Benjamin Herrenschmidt
    Cc: Rafael J. Wysocki
    Cc: Bjorn Helgaas
    Cc: Randy Dunlap
    Cc: Yinghai Lu
    Cc: Grant Likely
    Cc: Len Brown
    Link: http://lkml.kernel.org/r/1407478071-29399-1-git-send-email-jiang.liu@linux.intel.com
    Signed-off-by: Thomas Gleixner

    Jiang Liu
     

22 Jun, 2014

1 commit

  • Release IOAPIC pin associated with PCI device when the PCI device
    is disabled.

    Signed-off-by: Jiang Liu
    Cc: Konrad Rzeszutek Wilk
    Cc: Tony Luck
    Cc: Joerg Roedel
    Cc: Paul Gortmaker
    Cc: Greg Kroah-Hartman
    Cc: Benjamin Herrenschmidt
    Cc: Grant Likely
    Cc: Rafael J. Wysocki
    Cc: Bjorn Helgaas
    Cc: Randy Dunlap
    Cc: Yinghai Lu
    Cc: Len Brown
    Cc: Pavel Machek
    Link: http://lkml.kernel.org/r/1402380987-32577-1-git-send-email-jiang.liu@linux.intel.com
    Signed-off-by: Thomas Gleixner

    Jiang Liu
     

21 Feb, 2014

1 commit


18 Feb, 2014

1 commit


07 Dec, 2013

1 commit

  • Replace direct inclusions of , and
    , which are incorrect, with
    inclusions and remove some inclusions of those files that aren't
    necessary.

    First of all, , and
    should not be included directly from any files that are built for
    CONFIG_ACPI unset, because that generally leads to build warnings about
    undefined symbols in !CONFIG_ACPI builds. For CONFIG_ACPI set,
    includes those files and for CONFIG_ACPI unset it
    provides stub ACPI symbols to be used in that case.

    Second, there are ordering dependencies between those files that always
    have to be met. Namely, it is required that be included
    prior to so that the acpi_pci_root declarations the
    latter depends on are always there. And which provides
    basic ACPICA type declarations should always be included prior to any other
    ACPI headers in CONFIG_ACPI builds. That also is taken care of including
    as appropriate.

    Signed-off-by: Lv Zheng
    Cc: Greg Kroah-Hartman
    Cc: Matthew Garrett
    Cc: Tony Luck
    Cc: "H. Peter Anvin"
    Acked-by: Bjorn Helgaas (drivers/pci stuff)
    Acked-by: Konrad Rzeszutek Wilk (Xen stuff)
    Signed-off-by: Rafael J. Wysocki

    Lv Zheng
     

17 Feb, 2013

1 commit

  • Previously, we cached _PRT (PCI routing table, ACPI 5.0 sec 6.2.12)
    contents and associated each _PRT entry with a PCI bus number. The bus
    number association means dependencies on PCI device enumeration and bus
    number assignment, as well as on the PCI/ACPI binding process.

    After 4f535093cf ("PCI: Put pci_dev in device tree as early as possible"),
    these dependencies caused the IRQ issues reported by Peter:

    pci 0000:00:1e.0: PCI bridge to [bus 09] (subtractive decode)
    pci 0000:00:1e.0: can't derive routing for PCI INT A
    snd_ctxfi 0000:09:02.0: PCI INT A: no GSI - using ISA IRQ 5
    irq 18: nobody cared (try booting with the "irqpoll" option)

    This patch removes _PRT caching. Instead, we evaluate _PRT as needed
    in the pci_enable_device() path. This also removes the dependency on
    PCI bus numbers: we can simply look at the _PRT associated with each
    bridge as we walk upstream toward the root.

    [bhelgaas: changelog]
    Reference: https://bugzilla.kernel.org/show_bug.cgi?id=53561
    Reported-and-tested-by: Peter Hurley
    Suggested-by: Bjorn Helgaas
    Signed-off-by: Yinghai Lu
    Signed-off-by: Bjorn Helgaas

    Yinghai Lu
     

14 Dec, 2012

1 commit

  • Pull PCI update from Bjorn Helgaas:
    "Host bridge hotplug:
    - Untangle _PRT from struct pci_bus (Bjorn Helgaas)
    - Request _OSC control before scanning root bus (Taku Izumi)
    - Assign resources when adding host bridge (Yinghai Lu)
    - Remove root bus when removing host bridge (Yinghai Lu)
    - Remove _PRT during hot remove (Yinghai Lu)

    SRIOV
    - Add sysfs knobs to control numVFs (Don Dutile)

    Power management
    - Notify devices when power resource turned on (Huang Ying)

    Bug fixes
    - Work around broken _SEG on HP xw9300 (Bjorn Helgaas)
    - Keep runtime PM enabled for unbound PCI devices (Huang Ying)
    - Fix Optimus dual-GPU runtime D3 suspend issue (Dave Airlie)
    - Fix xen frontend shutdown issue (David Vrabel)
    - Work around PLX PCI 9050 BAR alignment erratum (Ian Abbott)

    Miscellaneous
    - Add GPL license for drivers/pci/ioapic (Andrew Cooks)
    - Add standard PCI-X, PCIe ASPM register #defines (Bjorn Helgaas)
    - NumaChip remote PCI support (Daniel Blueman)
    - Fix PCIe Link Capabilities Supported Link Speed definition (Jingoo
    Han)
    - Convert dev_printk() to dev_info(), etc (Joe Perches)
    - Add support for non PCI BAR ROM data (Matthew Garrett)
    - Add x86 support for host bridge translation offset (Mike Yoknis)
    - Report success only when every driver supports AER (Vijay
    Pandarathil)"

    Fix up trivial conflicts.

    * tag 'for-3.8' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: (48 commits)
    PCI: Use phys_addr_t for physical ROM address
    x86/PCI: Add NumaChip remote PCI support
    ath9k: Use standard #defines for PCIe Capability ASPM fields
    iwlwifi: Use standard #defines for PCIe Capability ASPM fields
    iwlwifi: collapse wrapper for pcie_capability_read_word()
    iwlegacy: Use standard #defines for PCIe Capability ASPM fields
    iwlegacy: collapse wrapper for pcie_capability_read_word()
    cxgb3: Use standard #defines for PCIe Capability ASPM fields
    PCI: Add standard PCIe Capability Link ASPM field names
    PCI/portdrv: Use PCI Express Capability accessors
    PCI: Use standard PCIe Capability Link register field names
    x86: Use PCI setup data
    PCI: Add support for non-BAR ROMs
    PCI: Add pcibios_add_device
    EFI: Stash ROMs if they're not in the PCI BAR
    PCI: Add and use standard PCI-X Capability register names
    PCI/PM: Keep runtime PM enabled for unbound PCI devices
    xen-pcifront: Handle backend CLOSED without CLOSING
    PCI: SRIOV control and status via sysfs (documentation)
    PCI/AER: Report success only when every device has AER-aware driver
    ...

    Linus Torvalds
     

30 Nov, 2012

1 commit

  • * acpi-general: (38 commits)
    ACPI / thermal: _TMP and _CRT/_HOT/_PSV/_ACx dependency fix
    ACPI: drop unnecessary local variable from acpi_system_write_wakeup_device()
    ACPI: Fix logging when no pci_irq is allocated
    ACPI: Update Dock hotplug error messages
    ACPI: Update Container hotplug error messages
    ACPI: Update Memory hotplug error messages
    ACPI: Update CPU hotplug error messages
    ACPI: Add acpi_handle_() interfaces
    ACPI: remove use of __devexit
    ACPI / PM: Add Sony Vaio VPCEB1S1E to nonvs blacklist.
    ACPI / battery: Correct battery capacity values on Thinkpads
    Revert "ACPI / x86: Add quirk for "CheckPoint P-20-00" to not use bridge _CRS_ info"
    ACPI: create _SUN sysfs file
    ACPI / memhotplug: bind the memory device when the driver is being loaded
    ACPI / memhotplug: don't allow to eject the memory device if it is being used
    ACPI / memhotplug: free memory device if acpi_memory_enable_device() failed
    ACPI / memhotplug: fix memory leak when memory device is unbound from acpi_memhotplug
    ACPI / memhotplug: deal with eject request in hotplug queue
    ACPI / memory-hotplug: add memory offline code to acpi_memory_device_remove()
    ACPI / memory-hotplug: call acpi_bus_trim() to remove memory device
    ...

    Conflicts:
    include/linux/acpi.h (two additions at the end of the same file)

    Rafael J. Wysocki
     

22 Nov, 2012

1 commit


15 Nov, 2012

1 commit

  • These functions might be called from modules as well so make sure
    they are exported.

    In addition, implement empty version of acpi_unregister_gsi() and
    remove the one from pci_irq.c.

    Signed-off-by: Andy Shevchenko
    Signed-off-by: Mika Westerberg
    Acked-by: Greg Kroah-Hartman
    Acked-by: H. Peter Anvin
    Acked-by: Tony Luck
    Signed-off-by: Rafael J. Wysocki

    Andy Shevchenko
     

06 Nov, 2012

1 commit

  • This effectively reverts 859a3f86ca8 ("ACPI: simplify
    acpi_pci_irq_add_prt() API") and d9efae3688a ("ACPI: simplify
    acpi_pci_irq_del_prt() API").

    The reason is to disentangle these routines from the struct pci_bus.
    We want to be able to add the _PRT before the struct pci_bus
    exists, and delete the _PRT after we've removed the pci_bus.

    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Taku Izumi

    Bjorn Helgaas
     

07 Jan, 2012

1 commit

  • When the runtime PM is activated on PCI, if a device switches state
    frequently (e.g. an EHCI controller with autosuspending USB devices
    connected) the PCI configuration traces might be very verbose in the
    kernel log. Let's guard those traces with DEBUG condition.

    Acked-by: "Rafael J. Wysocki"
    Signed-off-by: Vincent Palatin
    Signed-off-by: Jesse Barnes

    Vincent Palatin
     

17 Jul, 2011

1 commit

  • The following was observed by Steve Rostedt on 3.0.0-rc5
    Backtrace:
    irq 16: nobody cared (try booting with the "irqpoll" option)
    Pid: 65, comm: irq/16-uhci_hcd Not tainted 3.0.0-rc5-test+ #94
    Call Trace:
    [] __report_bad_irq+0x37/0xc1
    [] note_interrupt+0x14e/0x1c9
    [] ? irq_thread_fn+0x3c/0x3c
    [] irq_thread+0xf6/0x1b1
    [] ? irq_finalize_oneshot+0xb3/0xb3
    [] kthread+0x9f/0xa7
    [] kernel_thread_helper+0x4/0x10
    [] ? finish_task_switch+0x7b/0xc0
    [] ? retint_restore_args+0x13/0x13
    [] ? __init_kthread_worker+0x5a/0x5a
    [] ? gs_change+0x13/0x13
    handlers:
    [] irq_default_primary_handler threaded [] usb_hcd_irq
    [] irq_default_primary_handler threaded [] usb_hcd_irq
    Disabling IRQ #16

    The problem being that a device triggers boot interrupts (due to threaded
    interrupt handling and masking of the IO-APIC), which are forwarded
    to the PIRQ line of the device. These interrupts are not handled on the PIRQ
    line because the interrupt handler is not present there.
    This should have already been fixed by CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS.
    However some parts of the quirk got lost in the ACPI merge. This is a resent of
    the patch proposed in 2009.
    See http://lkml.org/lkml/2009/9/7/192

    Signed-off-by: Stefan Assmann
    Tested-by: Steven Rostedt
    Signed-off-by: Len Brown

    Stefan Assmann
     

16 Oct, 2010

1 commit


05 May, 2010

1 commit


30 Mar, 2010

1 commit

  • …it 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: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

29 Aug, 2009

1 commit

  • Linux/ACPI core files using internal.h all PREFIX "ACPI: ",
    however, not all ACPI drivers use/want it -- and they
    should not have to #undef PREFIX to define their own.

    Add GPL commment to internal.h while we are there.

    This does not change any actual console output,
    asside from a whitespace fix.

    Signed-off-by: Len Brown

    Len Brown
     

24 Jun, 2009

1 commit