02 Oct, 2020

1 commit

  • In order to switch the hip04 driver to provide standard interrupts
    for IPIs, rework the way interrupts are allocated, making sure
    the irqdomain covers the SGIs as well as the rest of the interrupt
    range.

    The driver is otherwise so old-school that it creates all interrupts
    upfront (duh!), so there is hardly anything else to change, apart
    from communicating the IPIs to the arch code.

    Signed-off-by: Marc Zyngier

    Bug: 140053385
    (cherry picked from commit a2df12c5899e9bb181cb64385b04f2bc755780b6
    https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/ipi-as-irq)
    Change-Id: I70ed8100824880900ca941ebafd41a8f3e8c8b92
    Signed-off-by: Eric Biggers

    Marc Zyngier
     

20 Aug, 2019

2 commits

  • GICv3.1 allows up to 80 PPIs (16 legaci PPIs and 64 Extended PPIs),
    meaning we can't just leave the old 16 hardcoded everywhere.

    We also need to add the infrastructure to discover the number of PPIs
    on a per redistributor basis, although we still pretend there is only
    16 of them for now.

    No functional change.

    Signed-off-by: Marc Zyngier

    Marc Zyngier
     
  • gic_configure_irq is currently passed the (re)distributor address,
    to which it applies an a fixed offset to get to the configuration
    registers. This offset is constant across all GICs, or rather it was
    until to v3.1...

    An easy way out is for the individual drivers to pass the base
    address of the configuration register for the considered interrupt.
    At the same time, move part of the error handling back to the
    individual drivers, as things are about to change on that front.

    Signed-off-by: Marc Zyngier

    Marc Zyngier
     

19 Jun, 2019

1 commit

  • Based on 2 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 version 2 as
    published by the free software foundation

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license version 2 as
    published by the free software foundation #

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-only

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

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

    Thomas Gleixner
     

18 Aug, 2017

1 commit

  • The HIP04 driver only targets a single CPU at a time, even if
    the notional affinity is wider. Let's inform the core code
    about this.

    Signed-off-by: Marc Zyngier
    Signed-off-by: Thomas Gleixner
    Cc: Andrew Lunn
    Cc: James Hogan
    Cc: Jason Cooper
    Cc: Paul Burton
    Cc: Chris Zankel
    Cc: Kevin Cernekee
    Cc: Wei Xu
    Cc: Max Filippov
    Cc: Florian Fainelli
    Cc: Gregory Clement
    Cc: Matt Redfearn
    Cc: Sebastian Hesselbarth
    Link: http://lkml.kernel.org/r/20170818083925.10108-11-marc.zyngier@arm.com

    Marc Zyngier
     

25 Dec, 2016

1 commit

  • When the state names got added a script was used to add the extra argument
    to the calls. The script basically converted the state constant to a
    string, but the cleanup to convert these strings into meaningful ones did
    not happen.

    Replace all the useless strings with 'subsys/xxx/yyy:state' strings which
    are used in all the other places already.

    Signed-off-by: Thomas Gleixner
    Cc: Peter Zijlstra
    Cc: Sebastian Siewior
    Link: http://lkml.kernel.org/r/20161221192112.085444152@linutronix.de
    Signed-off-by: Thomas Gleixner

    Thomas Gleixner
     

14 Jul, 2016

1 commit

  • Install the callbacks via the state machine and let the core invoke
    the callbacks on the already online CPUs.

    Signed-off-by: Richard Cochran
    Signed-off-by: Anna-Maria Gleixner
    Reviewed-by: Sebastian Andrzej Siewior
    Acked-by: Jason Cooper
    Cc: Linus Torvalds
    Cc: Marc Zyngier
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: rt@linutronix.de
    Link: http://lkml.kernel.org/r/20160713153333.244546182@linutronix.de
    Signed-off-by: Ingo Molnar

    Richard Cochran
     

28 May, 2016

1 commit

  • Most users of IS_ERR_VALUE() in the kernel are wrong, as they
    pass an 'int' into a function that takes an 'unsigned long'
    argument. This happens to work because the type is sign-extended
    on 64-bit architectures before it gets converted into an
    unsigned type.

    However, anything that passes an 'unsigned short' or 'unsigned int'
    argument into IS_ERR_VALUE() is guaranteed to be broken, as are
    8-bit integers and types that are wider than 'unsigned long'.

    Andrzej Hajda has already fixed a lot of the worst abusers that
    were causing actual bugs, but it would be nice to prevent any
    users that are not passing 'unsigned long' arguments.

    This patch changes all users of IS_ERR_VALUE() that I could find
    on 32-bit ARM randconfig builds and x86 allmodconfig. For the
    moment, this doesn't change the definition of IS_ERR_VALUE()
    because there are probably still architecture specific users
    elsewhere.

    Almost all the warnings I got are for files that are better off
    using 'if (err)' or 'if (err < 0)'.
    The only legitimate user I could find that we get a warning for
    is the (32-bit only) freescale fman driver, so I did not remove
    the IS_ERR_VALUE() there but changed the type to 'unsigned long'.
    For 9pfs, I just worked around one user whose calling conventions
    are so obscure that I did not dare change the behavior.

    I was using this definition for testing:

    #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \
    unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO))

    which ends up making all 16-bit or wider types work correctly with
    the most plausible interpretation of what IS_ERR_VALUE() was supposed
    to return according to its users, but also causes a compile-time
    warning for any users that do not pass an 'unsigned long' argument.

    I suggested this approach earlier this year, but back then we ended
    up deciding to just fix the users that are obviously broken. After
    the initial warning that caused me to get involved in the discussion
    (fs/gfs2/dir.c) showed up again in the mainline kernel, Linus
    asked me to send the whole thing again.

    [ Updated the 9p parts as per Al Viro - Linus ]

    Signed-off-by: Arnd Bergmann
    Cc: Andrzej Hajda
    Cc: Andrew Morton
    Link: https://lkml.org/lkml/2016/1/7/363
    Link: https://lkml.org/lkml/2016/5/27/486
    Acked-by: Srinivas Kandagatla # For nvmem part
    Signed-off-by: Linus Torvalds

    Arnd Bergmann
     

14 Oct, 2015

1 commit

  • The struct irq_domain contains a "struct device_node *" field
    (of_node) that is almost the only link between the irqdomain
    and the device tree infrastructure.

    In order to prepare for the removal of that field, convert all
    users to use irq_domain_get_of_node() instead.

    Signed-off-by: Marc Zyngier
    Reviewed-and-tested-by: Hanjun Guo
    Tested-by: Lorenzo Pieralisi
    Cc:
    Cc: Tomasz Nowicki
    Cc: Suravee Suthikulpanit
    Cc: Graeme Gregory
    Cc: Jake Oshins
    Cc: Jiang Liu
    Cc: Jason Cooper
    Cc: Rafael J. Wysocki
    Link: http://lkml.kernel.org/r/1444737105-31573-2-git-send-email-marc.zyngier@arm.com
    Signed-off-by: Thomas Gleixner

    Marc Zyngier
     

16 Sep, 2015

1 commit

  • set_irq_flags is ARM specific with custom flags which have genirq
    equivalents. Convert drivers to use the genirq interfaces directly, so we
    can kill off set_irq_flags. The translation of flags is as follows:

    IRQF_VALID -> !IRQ_NOREQUEST
    IRQF_PROBE -> !IRQ_NOPROBE
    IRQF_NOAUTOEN -> IRQ_NOAUTOEN

    For IRQs managed by an irqdomain, the irqdomain core code handles clearing
    and setting IRQ_NOREQUEST already, so there is no need to do this in
    .map() functions and we can simply remove the set_irq_flags calls. Some
    users also modify IRQ_NOPROBE and this has been maintained although it
    is not clear that is really needed. There appears to be a great deal of
    blind copy and paste of this code.

    Signed-off-by: Rob Herring
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: Russell King
    Cc: Jason Cooper
    Cc: Kukjin Kim
    Cc: Krzysztof Kozlowski
    Cc: Stephen Warren
    Cc: Lee Jones
    Cc: Alexander Shiyan
    Cc: Maxime Ripard
    Cc: linux-rpi-kernel@lists.infradead.org
    Cc: linux-samsung-soc@vger.kernel.org
    Link: http://lkml.kernel.org/r/1440889285-5637-3-git-send-email-robh@kernel.org
    Signed-off-by: Thomas Gleixner

    Rob Herring
     

27 Jul, 2015

1 commit

  • The GIC controller doesn't provides any facility to configure the wakeup
    sources. For the same reason, GIC chip implementation can't provide
    irq_set_wake functionality, but that results in the irqchip core
    preventing the systems from entering sleep states like "suspend to RAM".

    The GICv1/v2 controllers support wakeup events. They signal these wakeup
    events even when CPU interface is disabled which means the wakeup
    outputs are always enabled with the required logic in always-on domain.
    An implementation can powerdown the GIC completely, but then the wake-up
    must be relayed to some control logic within the power controller that
    acts as wake-up interrupt controller.

    Setting the IRQCHIP_SKIP_SET_WAKE flags will ensure that the interrupts
    from GIC can work as wakeup interrupts and resume from suspend-to-{idle,
    ram}. The wakeup interrupt sources need to use enable_irq_wake() and the
    irqchip core will then set the IRQD_WAKEUP_STATE flag.

    Also it's always safer to mask all the non wakeup interrupts are masked
    at the chip level when suspending. The irqchip infrastructure can handle
    masking of those interrupts at the chip level. The chip implementation
    just have to indicate that with IRQCHIP_MASK_ON_SUSPEND.

    This patch enables IRQCHIP_SKIP_SET_WAKE and IRQCHIP_MASK_ON_SUSPEND so
    that the irqchip core allows and handles the power managemant wake up
    modes.

    Signed-off-by: Sudeep Holla
    Cc: Marc Zyngier
    Cc: Simon Horman
    Cc: Jason Cooper
    Cc: Michal Simek
    Cc: Linus Walleij
    Cc: Magnus Damm
    Cc: Gregory CLEMENT
    Cc: Geert Uytterhoeven
    Cc: Lorenzo Pieralisi
    Cc: linux-arm-kernel@lists.infradead.org
    Link: http://lkml.kernel.org/r/1436971109-20189-1-git-send-email-sudeep.holla@arm.com
    Signed-off-by: Thomas Gleixner

    Sudeep Holla
     

12 Jul, 2015

1 commit

  • The IRQCHIP_DECLARE macro moved to to 'include/linux/irqchip.h', so
    the local irqchip.h became an empty shell, which solely includes
    include/linux/irqchip.h

    Include the global header in all irqchip drivers instead of the local
    header, so we can remove it.

    Signed-off-by: Joel Porquet
    Cc: vgupta@synopsys.com
    Cc: monstr@monstr.eu
    Cc: ralf@linux-mips.org
    Cc: jason@lakedaemon.net
    Link: http://lkml.kernel.org/r/1882096.X39jVG8e0D@joel-zenbook
    Signed-off-by: Thomas Gleixner

    Joel Porquet
     

06 Jun, 2015

1 commit

  • GIC requires to disable the interrupt before changing the trigger type.
    irqchip core provides IRQCHIP_SET_TYPE_MASKED flag and ensures that the
    interrupt is masked before calling chip.irq_set_type() if the irqchip
    sets the flag.

    This patch adds IRQCHIP_SET_TYPE_MASKED to GIC irqchip so that the core
    can manage disabling the interrupt while changing the trigger type.

    Signed-off-by: Sudeep Holla
    Reviewed-by: Marc Zyngier
    Cc: Jason Cooper
    Link: http://lkml.kernel.org/r/1433501997-19205-1-git-send-email-sudeep.holla@arm.com
    Signed-off-by: Thomas Gleixner

    Sudeep Holla
     

26 Jan, 2015

1 commit

  • During a recent cleanup of the arm64 DTs it has become clear that
    the handling of PPIs in xxxx_set_type() is incorrect. The ARM TRMs
    for GICv2 and later allow for "implementation defined" support for
    setting the edge or level type of the PPI interrupts and don't restrict
    the activation level of the signal. Current ARM implementations
    do restrict the PPI level type to IRQ_TYPE_LEVEL_LOW, but licensees
    of the IP can decide to shoot themselves in the foot at any time.

    Signed-off-by: Liviu Dudau
    Acked-by: Marc Zyngier
    Cc: LAKML
    Cc: Russell King
    Cc: Rob Herring
    Cc: Mark Rutland
    Cc: Ian Campbell
    Cc: Jason Cooper
    Cc: Haojian Zhuang
    Link: http://lkml.kernel.org/r/1421772779-25764-1-git-send-email-Liviu.Dudau@arm.com
    Signed-off-by: Thomas Gleixner

    Liviu Dudau
     

07 Jan, 2015

1 commit


02 Nov, 2014

1 commit

  • The HIP04 GIC-like irqchip escaped the conversion to handle_domain_irq.
    Let's give it the treatment it deserves.

    Cc: Haojian Zhuang
    Cc: Jason Cooper
    Signed-off-by: Marc Zyngier
    Link: https://lkml.kernel.org/r/1413882576-18922-1-git-send-email-marc.zyngier@arm.com
    Signed-off-by: Jason Cooper

    Marc Zyngier
     

20 Aug, 2014

1 commit

  • HiP04 GIC is the variate of ARM GICv2.

    ARM GICv2 supports 8 cores. HiP04 GIC extends to support 16 cores. It
    results that bit fields in GIC_DIST_TARGET & GIC_DIST_SOFTINT are
    different from ARM GICv2. And the maximium IRQ is downgrade from 1020 to 510.

    Since different register offset & bitfields definitation breaks
    compartible with ARM GICv2, create a new hip04 irq driver.

    And this driver is derived from irq-gic.c to support the Hisilicon HiP04
    interrupt controller, which is similar to the GIC, but deviates at some
    points. Support for power management, non-banked registers, cascaded
    GICs (and multiple controllers in general) and bigLittle support has
    been removed from the GIC driver.

    Affinity related functions have been adjusted to match the Hisilicon
    hardware implementation.

    Signed-off-by: Haojian Zhuang
    Link: https://lkml.kernel.org/r/1407408695-19626-9-git-send-email-haojian.zhuang@linaro.org
    Signed-off-by: Jason Cooper

    Haojian Zhuang