24 Oct, 2016

3 commits

  • Commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
    replaced the addition of PIRQ_PENALTY_PCI_USING in acpi_pci_link_allocate()
    with an addition in acpi_irq_pci_sharing_penalty(), but f7eca374f000
    ("ACPI,PCI,IRQ: separate ISA penalty calculation") removed the use
    of acpi_irq_pci_sharing_penalty() for ISA IRQs.

    Therefore, PIRQ_PENALTY_PCI_USING is missing from ISA IRQs used by
    interrupt links. Include that penalty by adding it in the
    acpi_pci_link_allocate() path.

    Fixes: f7eca374f000 (ACPI,PCI,IRQ: separate ISA penalty calculation)
    Signed-off-by: Sinan Kaya
    Acked-by: Bjorn Helgaas
    Tested-by: Jonathan Liu
    Signed-off-by: Rafael J. Wysocki

    Sinan Kaya
     
  • Ondrej reported that IRQs stopped working in v4.7 on several
    platforms. A typical scenario, from Ondrej's VT82C694X/694X, is:

    ACPI: Using PIC for interrupt routing
    ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 *11 12 14 15)
    ACPI: No IRQ available for PCI Interrupt Link [LNKA]
    8139too 0000:00:0f.0: PCI INT A: no GSI

    We're using PIC routing, so acpi_irq_balance == 0, and LNKA is already
    active at IRQ 11. In that case, acpi_pci_link_allocate() only tries
    to use the active IRQ (IRQ 11) which also happens to be the SCI.

    We should penalize the SCI by PIRQ_PENALTY_PCI_USING, but
    irq_get_trigger_type(11) returns something other than
    IRQ_TYPE_LEVEL_LOW, so we penalize it by PIRQ_PENALTY_ISA_ALWAYS
    instead, which makes acpi_pci_link_allocate() assume the IRQ isn't
    available and give up.

    Add acpi_penalize_sci_irq() so platforms can tell us the SCI IRQ,
    trigger, and polarity directly and we don't have to depend on
    irq_get_trigger_type().

    Fixes: 103544d86976 (ACPI,PCI,IRQ: reduce resource requirements)
    Link: http://lkml.kernel.org/r/201609251512.05657.linux@rainbow-software.org
    Reported-by: Ondrej Zary
    Acked-by: Bjorn Helgaas
    Signed-off-by: Sinan Kaya
    Tested-by: Jonathan Liu
    Signed-off-by: Rafael J. Wysocki

    Sinan Kaya
     
  • We do not want to store the SCI penalty in the acpi_isa_irq_penalty[]
    table because acpi_isa_irq_penalty[] only holds ISA IRQ penalties and
    there's no guarantee that the SCI is an ISA IRQ. We add in the SCI
    penalty as a special case in acpi_irq_get_penalty().

    But if we called acpi_penalize_isa_irq() or acpi_irq_penalty_update()
    for an SCI that happened to be an ISA IRQ, they stored the SCI
    penalty (part of the acpi_irq_get_penalty() return value) in
    acpi_isa_irq_penalty[]. Subsequent calls to acpi_irq_get_penalty()
    returned a penalty that included *two* SCI penalties.

    Fixes: 103544d86976 (ACPI,PCI,IRQ: reduce resource requirements)
    Signed-off-by: Sinan Kaya
    Acked-by: Bjorn Helgaas
    Tested-by: Jonathan Liu
    Signed-off-by: Rafael J. Wysocki

    Sinan Kaya
     

02 Jul, 2016

3 commits

  • Since commit 103544d86976 (ACPI,PCI,IRQ: reduce resource requirements)
    the penalty values are calculated on the fly rather than at boot time.

    This works fine for PCI interrupts but not so well for ISA interrupts.

    The information on whether or not an ISA interrupt is in use is not
    available to the pci_link.c code directly. That information is
    obtained from the outside via acpi_penalize_isa_irq(). [If its
    "active" argument is true, then the IRQ is in use by ISA.]

    Since the current code relies on PCI Link objects for determination
    of penalties, we are factoring in the PCI penalty twice after
    acpi_penalize_isa_irq() function is called.

    To avoid that, limit the newly added functionality to just PCI
    interrupts so that old behavior is still maintained.

    Fixes: 103544d86976 (ACPI,PCI,IRQ: reduce resource requirements)
    Signed-off-by: Sinan Kaya
    Tested-by: Wim Osterholt
    Signed-off-by: Rafael J. Wysocki

    Sinan Kaya
     
  • Trying to make the ISA and PCI init functionality common turned out
    to be a bad idea, because the ISA path depends on external
    functionality.

    Restore the previous behavior and limit the refactoring to PCI
    interrupts only.

    Fixes: 1fcb6a813c4f "ACPI,PCI,IRQ: remove redundant code in acpi_irq_penalty_init()"
    Signed-off-by: Sinan Kaya
    Tested-by: Wim Osterholt
    Signed-off-by: Rafael J. Wysocki

    Sinan Kaya
     
  • The change introduced in commit 103544d86976 (ACPI,PCI,IRQ: reduce
    resource requirements) omitted the initially applied PCI_POSSIBLE
    penalty when the IRQ is active.

    Incorrect calculation of the penalty leads the ACPI code to assigning
    a wrong interrupt number to a PCI INTx interrupt.

    This would not be as bad as it sounds in theory. It would just cause
    the interrupts to be shared and result in performance penalty.

    However, some drivers (like the parallel port driver) don't like
    interrupt sharing and in the above case they will causes all of
    the PCI drivers wanting to share the interrupt to be unable to
    request it.

    The issue has not been caught in testing because the behavior is
    platform-specific and depends on the peripherals ending up sharing
    the IRQ and their drivers.

    Before the above commit the code would add the PCI_POSSIBLE value
    divided by the number of possible IRQ users to the IRQ penalty
    during initialization.

    Later in that code path, if the IRQ is chosen as the active IRQ or
    if it is used by ISA; additional penalties are added.

    Fixes: 103544d86976 (ACPI,PCI,IRQ: reduce resource requirements)
    Signed-off-by: Sinan Kaya
    Tested-by: Wim Osterholt
    [ rjw: Changelog ]
    Signed-off-by: Rafael J. Wysocki

    Sinan Kaya
     

30 Jun, 2016

1 commit


05 May, 2016

4 commits


24 Feb, 2016

2 commits


05 Jan, 2016

1 commit


01 Jan, 2016

2 commits

  • The ACPI compiler uses the extended format when used interrupt numbers
    are greater than 15. The extended IRQ syntax is 32 bits according to the
    ACPI spec. The code supports parsing the extended interrupt numbers.
    However, due to used data structure type; the code silently truncates
    interrupt numbers greater than 256.

    Acked-by: Bjorn Helgaas
    Signed-off-by: Sinan Kaya
    Signed-off-by: Rafael J. Wysocki

    Sinan Kaya
     
  • Code currently supports 256 maximum interrupts at this moment. The patch is
    reconfiguring the penalty array as a dynamic list to remove this
    limitation.

    A new penalty linklist has been added for all other interrupts greater than
    16. If an IRQ is not found in the link list, an IRQ info structure will be
    dynamically allocated on the first access and will be placed on the list
    for further reuse. The list will grow by the number of supported interrupts
    in the ACPI table rather than having a 256 hard limitation.

    Acked-by: Bjorn Helgaas
    Signed-off-by: Sinan Kaya
    Signed-off-by: Rafael J. Wysocki

    Sinan Kaya
     

26 Sep, 2015

2 commits

  • Now we have dedicated interface acpi_penalize_sci_irq() to penalize
    ISA IRQ used by ACPI SCI, so remove duplicated code to penalize ACPI SCI
    in acpi_irq_penalty_init().

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

    Jiang Liu
     
  • 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
     

01 Sep, 2015

1 commit


27 Aug, 2015

1 commit

  • Nick Meier reported a regression with HyperV that "
    After rebooting the VM, the following messages are logged in syslog
    when trying to load the tulip driver:
    tulip: Linux Tulip drivers version 1.1.15 (Feb 27, 2007)
    tulip: 0000:00:0a.0: PCI INT A: failed to register GSI
    tulip: Cannot enable tulip board #0, aborting
    tulip: probe of 0000:00:0a.0 failed with error -16
    Errors occur in 3.19.0 kernel
    Works in 3.17 kernel.
    "

    According to the ACPI dump file posted by Nick at
    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1440072

    The ACPI MADT table includes an interrupt source overridden entry for
    ACPI SCI:
    [236h 0566 1] Subtable Type : 02
    [237h 0567 1] Length : 0A
    [238h 0568 1] Bus : 00
    [239h 0569 1] Source : 09
    [23Ah 0570 4] Interrupt : 00000009
    [23Eh 0574 2] Flags (decoded below) : 000D
    Polarity : 1
    Trigger Mode : 3

    And in DSDT table, we have _PRT method to define PCI interrupts, which
    eventually goes to:
    Name (PRSA, ResourceTemplate ()
    {
    IRQ (Level, ActiveLow, Shared, )
    {3,4,5,7,9,10,11,12,14,15}
    })
    Name (PRSB, ResourceTemplate ()
    {
    IRQ (Level, ActiveLow, Shared, )
    {3,4,5,7,9,10,11,12,14,15}
    })
    Name (PRSC, ResourceTemplate ()
    {
    IRQ (Level, ActiveLow, Shared, )
    {3,4,5,7,9,10,11,12,14,15}
    })
    Name (PRSD, ResourceTemplate ()
    {
    IRQ (Level, ActiveLow, Shared, )
    {3,4,5,7,9,10,11,12,14,15}
    })

    According to the MADT and DSDT tables, IRQ 9 may be used for:
    1) ACPI SCI in level, high mode
    2) PCI legacy IRQ in level, low mode
    So there's a conflict in polarity setting for IRQ 9.

    Prior to commit cd68f6bd53cf ("x86, irq, acpi: Get rid of special
    handling of GSI for ACPI SCI"), ACPI SCI is handled specially and
    there's no check for conflicts between ACPI SCI and PCI legagy IRQ.
    And it seems that the HyperV hypervisor doesn't make use of the
    polarity configuration in IOAPIC entry, so it just works.

    Commit cd68f6bd53cf gets rid of the specially handling of ACPI SCI,
    and then the pin attribute checking code discloses the conflicts
    between ACPI SCI and PCI legacy IRQ on HyperV virtual machine,
    and rejects the request to assign IRQ9 to PCI devices.

    So penalize legacy IRQ used by ACPI SCI and mark it unusable if ACPI
    SCI attributes conflict with PCI IRQ attributes.

    Please refer to following links for more information:
    https://bugzilla.kernel.org/show_bug.cgi?id=101301
    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1440072

    Fixes: cd68f6bd53cf ("x86, irq, acpi: Get rid of special handling of GSI for ACPI SCI")
    Reported-and-tested-by: Nick Meier
    Acked-by: Thomas Gleixner
    Cc: 3.19+ # 3.19+
    Signed-off-by: Jiang Liu
    Signed-off-by: Rafael J. Wysocki

    Jiang Liu
     

08 Jul, 2015

1 commit


19 Mar, 2014

1 commit


06 Jan, 2014

1 commit

  • Includes appropriate header file internal.h in pci_link.c
    because function acpi_pci_link_init() has its prototype declaration in
    internal.h.

    This eliminates the following warning in pci_link.c:
    drivers/acpi/pci_link.c:874:13: warning: no previous prototype for ‘acpi_pci_link_init’ [-Wmissing-prototypes]

    Signed-off-by: Rashika Kheria
    Reviewed-by: Josh Triplett
    Signed-off-by: Rafael J. Wysocki

    Rashika
     

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
     

24 Mar, 2013

1 commit

  • Found with a network device in QEMU/KVM guest not working anymore.

    Bisected to commit c13085e5
    ACPICA: Resource Mgr: Prevent infinite loops in resource walks

    That commit will check acpi_resource length strictly which causes
    acpi_set_current_resources to return failure and IRQ for PCI
    devices is not set properly.

    Set length for all those TYPE_END_TAG acpi_resources.

    [rjw: Changelog]
    Bisected-by: Yinghai Lu
    Signed-off-by: Yinghai Lu
    Signed-off-by: Rafael J. Wysocki

    Yinghai Lu
     

30 Jan, 2013

1 commit

  • Make the ACPI PCI IRQ link driver use struct acpi_scan_handler
    for representing the object used to set up ACPI interrupt links and
    to remove data structures used for this purpose before unregistering
    the corresponding ACPI device nodes.

    This simplifies the code slightly and reduces the kernel's memory
    footprint by avoiding the registration of a struct device_driver
    object with the driver core and creation of its sysfs directory
    which is unnecessary.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Yinghai Lu
    Acked-by: Toshi Kani

    Rafael J. Wysocki
     

26 Jan, 2013

1 commit

  • The second argument of ACPI driver .remove() operation is only used
    by the ACPI processor driver and the value passed to that driver
    through it is always available from the given struct acpi_device
    object's removal_type field. For this reason, the second ACPI driver
    .remove() argument is in fact useless, so drop it.

    Signed-off-by: Rafael J. Wysocki
    Reviewed-by: Jiang Liu
    Acked-by: Toshi Kani
    Acked-by: Yinghai Lu

    Rafael J. Wysocki
     

08 May, 2012

1 commit


19 Mar, 2011

1 commit

  • ACPI uses a sysdev class and a sysdev for executing
    irqrouter_resume() before turning on interrupts on the boot CPU.
    However, since irqrouter_resume() ignores its argument, the entire
    mechanism may be replaced with a struct syscore_ops object which
    is considerably simpler.

    Signed-off-by: Rafael J. Wysocki
    Signed-off-by: Len Brown

    Rafael J. Wysocki
     

16 Oct, 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
     

17 Jan, 2010

1 commit

  • The ids field of the struct acpi_driver is constant in
    so it is worth to make the initialization data also constant.

    The semantic match that finds this kind of pattern is as follows:
    (http://coccinelle.lip6.fr/)

    //
    @r@
    disable decl_init,const_decl_init;
    identifier I1, I2, x;
    @@
    struct I1 {
    ...
    const struct I2 *x;
    ...
    };
    @s@
    identifier r.I1, y;
    identifier r.x, E;
    @@
    struct I1 y = {
    .x = E,
    };
    @c@
    identifier r.I2;
    identifier s.E;
    @@
    const struct I2 E[] = ... ;
    @depends on !c@
    identifier r.I2;
    identifier s.E;
    @@
    + const
    struct I2 E[] = ...;
    //

    Signed-off-by: Márton Németh
    Cc: Julia Lawall
    Cc: cocci@diku.dk
    Signed-off-by: Len Brown

    Márton Németh
     

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
     

17 Mar, 2009

4 commits


07 Feb, 2009

1 commit


09 Jan, 2009

1 commit


31 Dec, 2008

1 commit