DMA Engine development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Jelly Jia" <Jelly.Jia@cixtech.com>
Cc: devicetree@vger.kernel.org, dmaengine@vger.kernel.org,
	linux-clk@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org,
	vkoul@kernel.org, Frank.Li@kernel.org
Subject: Re: [PATCH v1 2/5] clk: cix: Handle Sky1 AUDSS DMA interrupt gates as an irqchip
Date: Fri, 23 Oct 2026 09:53:15 +0000	[thread overview]
Message-ID: <sashiko-outbox-182643@kernel.org> (raw)
In-Reply-To: <20261023093045.3248630-3-Jelly.Jia@cixtech.com>

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [High] clk: cix: unclocked MMIO access in sky1_audss_irq_teardown() and IRQ callbacks
- [High] clk: cix: invalid wait context in sky1_audss_irq_handler() and mask callbacks
- [High] clk: cix: missing irq_dispose_mapping() in sky1_audss_irq_teardown()
- [High] clk: cix: level IRQ storm with handle_untracked_irq() on lazy IRQ disable
- [Low] clk: cix: missing select IRQ_DOMAIN for CLK_SKY1_AUDSS in Kconfig
--

commit d366d15da9922d1961ddd48a45f4b621f1a77320
Author: Jelly Jia <Jelly.Jia@cixtech.com>

clk: cix: Handle Sky1 AUDSS DMA interrupt gates as an irqchip

This commit adds an irqchip and linear IRQ domain to the CIX Sky1 AUDSS clock
driver to manage the DMA-350 channel interrupt gates in the INFO_AP_IRQC
register. It installs a chained IRQ handler on the shared parent GIC line and
registers a devres teardown action to clean up the irqchip.

> diff --git a/drivers/clk/cix/clk-sky1-audss.c b/drivers/clk/cix/clk-sky1-audss.c
> index e096b8121df30..789cbba631d16 100644
> --- a/drivers/clk/cix/clk-sky1-audss.c
> +++ b/drivers/clk/cix/clk-sky1-audss.c

[ ... ]

> @@ -928,6 +939,110 @@ static int sky1_audss_clks_enable(struct sky1_audss_clks_priv *priv)
>  	return err;
>  }
>  
> +static void sky1_audss_irq_mask(struct irq_data *d)
> +{
> +	struct sky1_audss_clks_priv *priv = irq_data_get_irq_chip_data(d);
> +
> +	regmap_update_bits(priv->regmap_cru, INFO_AP_IRQC,
> +			   BIT(d->hwirq), 0);
> +}
> +
> +static void sky1_audss_irq_unmask(struct irq_data *d)
> +{
> +	struct sky1_audss_clks_priv *priv = irq_data_get_irq_chip_data(d);
> +
> +	regmap_update_bits(priv->regmap_cru, INFO_AP_IRQC,
> +			   BIT(d->hwirq), BIT(d->hwirq));
> +}

[Severity: High]
Will calling regmap_update_bits() in sky1_audss_irq_mask() and
sky1_audss_irq_unmask(), as well as regmap_read() in sky1_audss_irq_handler(),
trigger an invalid wait context warning under CONFIG_PROVE_RAW_LOCK_NESTING
and sleep in atomic context on PREEMPT_RT?

In drivers/clk/cix/clk-sky1-audss.c, priv->regmap_cru is initialized via
devm_regmap_init_mmio() using sky1_audss_regmap_config:

    static const struct regmap_config sky1_audss_regmap_config = {
            .reg_bits = 32,
            .val_bits = 32,
            .reg_stride = 4,
    };

Because sky1_audss_regmap_config does not set .use_raw_spinlock = true,
regmap initializes a non-raw spinlock_t for map->spinlock.

The IRQ core invokes .irq_mask and .irq_unmask while holding irq_desc->lock
(a raw_spinlock_t), and sky1_audss_irq_handler() runs in hardirq context.
Acquiring the regmap spinlock_t in those paths violates raw_spinlock_t
nesting rules. Should sky1_audss_regmap_config set .use_raw_spinlock = true?

> +
> +static struct irq_chip sky1_audss_irq_chip = {
> +	.name		= "sky1-audss-dmac",
> +	.irq_mask	= sky1_audss_irq_mask,
> +	.irq_unmask	= sky1_audss_irq_unmask,
> +	.flags		= IRQCHIP_SKIP_SET_WAKE,
> +};
> +
> +static int sky1_audss_irq_map(struct irq_domain *d, unsigned int irq,
> +			      irq_hw_number_t hwirq)
> +{
> +	if (hwirq >= SKY1_AUDSS_DMAC_IRQS)
> +		return -EINVAL;
> +
> +	irq_set_chip_data(irq, d->host_data);
> +	irq_set_chip_and_handler(irq, &sky1_audss_irq_chip,
> +				 handle_untracked_irq);
> +	irq_set_noprobe(irq);
> +
> +	return 0;
> +}
> +
> +static const struct irq_domain_ops sky1_audss_irq_ops = {
> +	.map	= sky1_audss_irq_map,
> +	.xlate	= irq_domain_xlate_onecell,
> +};
> +
> +static void sky1_audss_irq_handler(struct irq_desc *desc)
> +{
> +	struct sky1_audss_clks_priv *priv = irq_desc_get_handler_data(desc);
> +	struct irq_chip *chip = irq_desc_get_chip(desc);
> +	unsigned long enabled;
> +	unsigned int hwirq;
> +	u32 val;
> +
> +	chained_irq_enter(chip, desc);
> +
> +	if (!regmap_read(priv->regmap_cru, INFO_AP_IRQC, &val)) {
> +		enabled = val & INFO_AP_IRQC_DMAC_MASK;
> +		for_each_set_bit(hwirq, &enabled, SKY1_AUDSS_DMAC_IRQS)
> +			generic_handle_domain_irq(priv->irq_domain, hwirq);
> +	}
> +
> +	chained_irq_exit(chip, desc);
> +}

[Severity: High]
What happens if a child DMA interrupt is disabled via disable_irq(),
disable_irq_nosync(), or suspend_device_irqs() and that channel later
asserts its level-high interrupt?

Because sky1_audss_irq_chip only provides .irq_mask and .irq_unmask (without
.irq_disable or IRQCHIP_MASK_ON_SUSPEND) and sky1_audss_irq_map() does not
set IRQ_DISABLE_UNLAZY, irq_disable() performs a lazy disable: it marks the
interrupt disabled in software without calling sky1_audss_irq_mask(), leaving
BIT(hwirq) set in INFO_AP_IRQC.

Unlike handle_level_irq() and handle_fasteoi_irq(), handle_untracked_irq()
does not call mask_irq() when an interrupt arrives while disabled:

    void handle_untracked_irq(struct irq_desc *desc)
    {
            raw_spin_lock(&desc->lock);

            if (!irq_can_handle(desc))
                    goto out_unlock;
            ...

When the disabled channel asserts its level interrupt, sky1_audss_irq_handler()
sees BIT(hwirq) set in INFO_AP_IRQC and calls generic_handle_domain_irq() ->
handle_untracked_irq(), which returns immediately without masking the gate or
clearing the source. Once chained_irq_exit() unmasks the parent GIC line,
won't the level-high parent interrupt immediately re-fire in an infinite hard
IRQ storm?

> +
> +static void sky1_audss_irq_teardown(void *data)
> +{
> +	struct sky1_audss_clks_priv *priv = data;
> +
> +	regmap_update_bits(priv->regmap_cru, INFO_AP_IRQC,
> +			   INFO_AP_IRQC_DMAC_MASK, 0);
> +	irq_set_chained_handler_and_data(priv->parent_irq, NULL, NULL);
> +	irq_domain_remove(priv->irq_domain);
> +}

[Severity: High]
Does sky1_audss_irq_teardown() leak mapped irq_desc descriptors and leave
dangling pointers when calling irq_domain_remove(priv->irq_domain) without
first disposing of existing mappings?

When a consumer calls platform_get_irq(), irq_create_fwspec_mapping() maps the
child virq through sky1_audss_irq_map(), setting desc->irq_data.domain to
priv->irq_domain, desc->irq_data.chip_data to priv, and desc->irq_data.chip to
&sky1_audss_irq_chip. Platform consumers do not call irq_dispose_mapping() on
unbind.

Calling irq_domain_remove() directly without iterating over the domain's
hwirqs and calling irq_dispose_mapping(irq_find_mapping(priv->irq_domain,
hwirq)) leaves those virtual IRQ descriptors allocated in the global IRQ tree
with dangling pointers to the freed domain, freed priv, and (if built as a
module and unloaded) unmapped sky1_audss_irq_chip memory.

> +
> +static int sky1_audss_irq_init(struct platform_device *pdev,
> +			       struct sky1_audss_clks_priv *priv)
> +{
> +	struct device *dev = &pdev->dev;
> +	int ret;
> +	int irq;
> +
> +	if (!of_property_read_bool(dev->of_node, "interrupt-controller"))
> +		return 0;
> +
> +	irq = platform_get_irq(pdev, 0);
> +	if (irq < 0)
> +		return irq;
> +
> +	priv->irq_domain = irq_domain_add_linear(dev->of_node,
> +						 SKY1_AUDSS_DMAC_IRQS,
> +						 &sky1_audss_irq_ops, priv);

[Severity: Low]
Can this fail to build under CONFIG_COMPILE_TEST=y when CONFIG_IRQ_DOMAIN is
not enabled?

In drivers/clk/cix/Kconfig, CLK_SKY1_AUDSS depends on ARCH_CIX || COMPILE_TEST
and selects AUXILIARY_BUS, REGMAP_MMIO, and RESET_CONTROLLER, but does not
select IRQ_DOMAIN. Because irq_domain_add_linear(), irq_domain_remove(),
irq_domain_xlate_onecell, and generic_handle_domain_irq() are only declared
when CONFIG_IRQ_DOMAIN is enabled, should CLK_SKY1_AUDSS select IRQ_DOMAIN as
well?

[ ... ]

> @@ -1110,6 +1225,13 @@ static int sky1_audss_clk_probe(struct platform_device *pdev)
>  		goto fail_pm;
>  	}
>  
> +	/* Tear the irqchip down before the runtime-PM cleanup disables clocks. */
> +	ret = sky1_audss_irq_init(pdev, priv);
> +	if (ret) {
> +		dev_err_probe(dev, ret, "failed to set up AUDSS DMA IRQs\n");
> +		goto fail_pm;
> +	}
> +
>  	pm_runtime_put_sync(dev);
>  
>  	return 0;

[Severity: High]
Can sky1_audss_irq_teardown(), sky1_audss_irq_mask(), sky1_audss_irq_unmask(),
and sky1_audss_irq_handler() access INFO_AP_IRQC while the AUDSS CRU is
runtime-suspended with its NoC reset asserted and parent clocks disabled?

In sky1_audss_clk_runtime_suspend(), suspending the device asserts
priv->rst_noc and disables all four parent clocks:

    reset_control_assert(priv->rst_noc);

    sky1_audss_clks_disable(priv);

There appear to be three paths where INFO_AP_IRQC is accessed while the CRU is
in this unclocked/reset state:

1. At the end of sky1_audss_clk_probe() (and at fail_pm), pm_runtime_put_sync()
suspends the device immediately if no consumer clock is prepared. Likewise,
during driver unbind, __device_release_driver() runs pm_runtime_put_sync()
before devres_release_all(). Because the device is already runtime-suspended
before devres teardown starts, registering sky1_audss_irq_teardown() after
sky1_audss_clk_rpm_cleanup() does not keep the CRU clocked when
sky1_audss_irq_teardown() calls regmap_update_bits() on INFO_AP_IRQC.

2. In sky1_audss_irq_init(), priv->irq_domain is created without calling
irq_domain_set_pm_device(priv->irq_domain, dev). As a result, requesting or
freeing a child DMA IRQ does not runtime-resume dev before
sky1_audss_irq_unmask() or sky1_audss_irq_mask() accesses INFO_AP_IRQC (and
any gate bit written while suspended would be overwritten by sky1_reg_save
on the next runtime resume).

3. In sky1_audss_clk_pm_ops, pm_runtime_force_suspend() and
pm_runtime_force_resume() are wired to normal system sleep callbacks via
SET_SYSTEM_SLEEP_PM_OPS() rather than noirq callbacks, so the CRU is placed
in reset and unclocked during dpm_suspend() while the chained handler
sky1_audss_irq_handler() and child IRQs are still active.

Should the driver set irq_domain_set_pm_device(), ensure runtime PM is active
around the register write in sky1_audss_irq_teardown(), and move the system
sleep callbacks to noirq?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261023093045.3248630-1-Jelly.Jia@cixtech.com?part=2

  reply	other threads:[~2026-10-23  9:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-23  9:30 [PATCH v1 0/5] soc: cix: Add the Sky1 AUDSS DMA-350 interrupt path Jelly Jia
2026-10-23  9:30 ` [PATCH v1 1/5] dt-bindings: soc: cix: Describe the Sky1 AUDSS DMA IRQ controller Jelly Jia
2026-10-26  8:12   ` Krzysztof Kozlowski
2026-10-29  5:25     ` Jelly Jia
2026-10-23  9:30 ` [PATCH v1 2/5] clk: cix: Handle Sky1 AUDSS DMA interrupt gates as an irqchip Jelly Jia
2026-10-23  9:53   ` sashiko-bot [this message]
2026-10-23  9:30 ` [PATCH v1 3/5] dt-bindings: dma: arm,dma-350: Document dma-channel-mask Jelly Jia
2026-10-26  8:13   ` Krzysztof Kozlowski
2026-10-23  9:30 ` [PATCH v1 4/5] dmaengine: arm-dma350: Honour dma-channel-mask Jelly Jia
2026-10-28 16:47   ` Frank Li
2026-10-29  5:18     ` Jelly Jia
2026-10-23  9:30 ` [PATCH v1 5/5] arm64: dts: cix: Add the Sky1 AUDSS DMA-350 integration Jelly Jia
2026-10-23 10:28   ` sashiko-bot

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=sashiko-outbox-182643@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=Jelly.Jia@cixtech.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vkoul@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox