Received: by 2002:a05:6358:489b:b0:bb:da1:e618 with SMTP id x27csp266267rwn; Thu, 8 Sep 2022 00:57:08 -0700 (PDT) X-Google-Smtp-Source: AA6agR4YQjCtLDRn55nTKfH/1aCy8fm8D7Nq1rq1UM0U1Wb9Rpqp6ehCzHGzOYBmRneiP1SKyrMH X-Received: by 2002:a17:907:9493:b0:73b:e605:f3b with SMTP id dm19-20020a170907949300b0073be6050f3bmr5360200ejc.37.1662623828523; Thu, 08 Sep 2022 00:57:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662623828; cv=none; d=google.com; s=arc-20160816; b=bWfACqV0m/RHhNVvTsToxEXHgo9PdpZo7myy2UgauGLVL8sneKiGSgT99BslFSWf/H fOv2ssBMoT4KGCHDGikWnMp5/5fp1lscKPgM/XwIMeo5VsDX859fGAVKOimj5eKQ7dBn Z55jHL+YdeY28mOIbnFF6l9mNLTcCW8GgEwlZyfecM0ORVzAX7n9LAnFVSi/kznWx8h4 LDq2iKhgqDr6QYCENhjMSLm/NYp9L872FbVWsPKmdC81/NHvDSeUcYneao1gVUYwEHCV mR3kCEITaIeQBTv9EN0cAIqptoygt5JFcjFK/1PNDELXI7q7NvsPcCyG7gfwDmCVx3BW /Mkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:in-reply-to :subject:cc:to:from:message-id:date:dkim-signature; bh=cEQSxSyudv6cX8BoYEhsrdLfhoWX8QBvKlFCg94hXII=; b=GL55Nn3382q0meOVX/q9pU4WPjTLf2dsgwvjAptBAga5wtj07VlYoGxzkMiDgbjcrg rRsDNHyFeS4x/hral1te6WaIQ/+4ZpuWzBnKgpbvWkHnOIhDmE3R50lhrTMepbSSlKOb SATepOUKNKMegzh78FIgK2YKqMgCxNMT40hlRnWS5ICenGottIe/FLZKsaXAWt3yXLjm Cnnqu2KQGect1Tq2HmjXfivfZ7nSMKJ9nYbfioaE5jy8GLxchdWyGLEJVlr5DdWOrQiJ +GkXPJe8/wE9CM34ZVvZCfZJr3/xMy7J6wWbJjnXITVQlfo4gVPxvq0uFt9YOwOlwbej o0gQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=T8zzCfRA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q2-20020a056402032200b00448b8836866si12019622edw.586.2022.09.08.00.56.39; Thu, 08 Sep 2022 00:57:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=T8zzCfRA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230040AbiIHHk0 (ORCPT + 99 others); Thu, 8 Sep 2022 03:40:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35034 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229624AbiIHHkY (ORCPT ); Thu, 8 Sep 2022 03:40:24 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5604F5A2C3; Thu, 8 Sep 2022 00:40:22 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id E6A1DB81F78; Thu, 8 Sep 2022 07:40:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 83BB7C433D6; Thu, 8 Sep 2022 07:40:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1662622819; bh=/yqgJJ5uMK1h6c2CgnSMPpgINloP07AxiagPnKlv0B8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=T8zzCfRAivY4zDIql8rWhtAybmQCHOH2GdXmCoGk/xs4ezqHhHKrMbFUWKsf8WX54 5giQu2ipQOkSiyRRcp4iJBrj4FKbd1zLu59a9d1Cf4e1CgCAJUMcVbYmKDQQqKUxED 89dpeKD7W36Ry//02PH1veGR8/dihQZmsTIFrc50RzCNuga8OiJoiPLpXzjNIXJxxn 0sK+pNzk7Hgcf+wTPv0mxLTUaGu1Ah51UAfg2PVWDCKWA0ziaVDbZDsixEWF1IRnCT pj6MYqGiartRvogorFXdiuKy7eFvKvL59Nlo72a2BlPJB0S3ARXzr4XGGWmNj7iKty AX9lNVV9r7WNA== Received: from ip-185-104-136-29.ptr.icomera.net ([185.104.136.29] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1oWC8z-008q9F-Pv; Thu, 08 Sep 2022 08:40:17 +0100 Date: Thu, 08 Sep 2022 08:39:47 +0100 Message-ID: <87fsh2qpq4.wl-maz@kernel.org> From: Marc Zyngier To: Frank Li Cc: tglx@linutronix.de, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, shawnguo@kernel.org, s.hauer@pengutronix.de, kw@linux.com, bhelgaas@google.com, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org, peng.fan@nxp.com, aisheng.dong@nxp.com, jdmason@kudzu.us, kernel@pengutronix.de, festevam@gmail.com, linux-imx@nxp.com, kishon@ti.com, lorenzo.pieralisi@arm.com, ntb@lists.linux.dev, lznuaa@gmail.com, imx@lists.linux.dev, manivannan.sadhasivam@linaro.org Subject: Re: [PATCH v9 2/4] irqchip: Add IMX MU MSI controller driver In-Reply-To: <20220907034856.3101570-3-Frank.Li@nxp.com> References: <20220907034856.3101570-1-Frank.Li@nxp.com> <20220907034856.3101570-3-Frank.Li@nxp.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.104.136.29 X-SA-Exim-Rcpt-To: Frank.Li@nxp.com, tglx@linutronix.de, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, shawnguo@kernel.org, s.hauer@pengutronix.de, kw@linux.com, bhelgaas@google.com, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org, peng.fan@nxp.com, aisheng.dong@nxp.com, jdmason@kudzu.us, kernel@pengutronix.de, festevam@gmail.com, linux-imx@nxp.com, kishon@ti.com, lorenzo.pieralisi@arm.com, ntb@lists.linux.dev, lznuaa@gmail.com, imx@lists.linux.dev, manivannan.sadhasivam@linaro.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 07 Sep 2022 04:48:54 +0100, Frank Li wrote: > > The MU block found in a number of Freescale/NXP SoCs supports generating > IRQs by writing data to a register > > This enables the MU block to be used as a MSI controller, by leveraging > the platform-MSI API Missing full stop after each sentence. > > Signed-off-by: Frank Li > --- > drivers/irqchip/Kconfig | 9 + > drivers/irqchip/Makefile | 1 + > drivers/irqchip/irq-imx-mu-msi.c | 451 +++++++++++++++++++++++++++++++ > 3 files changed, 461 insertions(+) > create mode 100644 drivers/irqchip/irq-imx-mu-msi.c > > diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig > index 5e4e50122777d..e04c6521dce55 100644 > --- a/drivers/irqchip/Kconfig > +++ b/drivers/irqchip/Kconfig > @@ -470,6 +470,15 @@ config IMX_INTMUX > help > Support for the i.MX INTMUX interrupt multiplexer. > > +config IMX_MU_MSI > + bool "i.MX MU work as MSI controller" Why bool? Doesn't it also work as a module? > + default y if ARCH_MXC Why would this be selected by default? > + select IRQ_DOMAIN > + select IRQ_DOMAIN_HIERARCHY > + select GENERIC_MSI_IRQ_DOMAIN > + help > + MU work as MSI controller to do general doorbell I'm not sure this is that generic. It really is limited to CPU-to-CPU interrupts. > + > config LS1X_IRQ > bool "Loongson-1 Interrupt Controller" > depends on MACH_LOONGSON32 > diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile > index 5d8e21d3dc6d8..870423746c783 100644 > --- a/drivers/irqchip/Makefile > +++ b/drivers/irqchip/Makefile > @@ -98,6 +98,7 @@ obj-$(CONFIG_RISCV_INTC) += irq-riscv-intc.o > obj-$(CONFIG_SIFIVE_PLIC) += irq-sifive-plic.o > obj-$(CONFIG_IMX_IRQSTEER) += irq-imx-irqsteer.o > obj-$(CONFIG_IMX_INTMUX) += irq-imx-intmux.o > +obj-$(CONFIG_IMX_MU_MSI) += irq-imx-mu-msi.o > obj-$(CONFIG_MADERA_IRQ) += irq-madera.o > obj-$(CONFIG_LS1X_IRQ) += irq-ls1x.o > obj-$(CONFIG_TI_SCI_INTR_IRQCHIP) += irq-ti-sci-intr.o > diff --git a/drivers/irqchip/irq-imx-mu-msi.c b/drivers/irqchip/irq-imx-mu-msi.c > new file mode 100644 > index 0000000000000..82b55f6d87266 > --- /dev/null > +++ b/drivers/irqchip/irq-imx-mu-msi.c > @@ -0,0 +1,451 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Freescale MU worked as MSI controller s/worked/used/ > + * > + * Copyright (c) 2018 Pengutronix, Oleksij Rempel > + * Copyright 2022 NXP > + * Frank Li > + * Peng Fan > + * > + * Based on drivers/mailbox/imx-mailbox.c > + */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include Keep this list in alphabetical order. > + > + > +#define IMX_MU_CHANS 4 > + > +enum imx_mu_xcr { > + IMX_MU_GIER, > + IMX_MU_GCR, > + IMX_MU_TCR, > + IMX_MU_RCR, > + IMX_MU_xCR_MAX, What is this last enum used for? > +}; > + > +enum imx_mu_xsr { > + IMX_MU_SR, > + IMX_MU_GSR, > + IMX_MU_TSR, > + IMX_MU_RSR, > +}; > + > +enum imx_mu_type { > + IMX_MU_V1 = BIT(0), This is never used. Why? > + IMX_MU_V2 = BIT(1), > + IMX_MU_V2_S4 = BIT(15), Same thing. > +}; > + > +/* Receive Interrupt Enable */ > +#define IMX_MU_xCR_RIEn(data, x) ((data->cfg->type) & IMX_MU_V2 ? BIT(x) : BIT(24 + (3 - (x)))) > +#define IMX_MU_xSR_RFn(data, x) ((data->cfg->type) & IMX_MU_V2 ? BIT(x) : BIT(24 + (3 - (x)))) > + > +struct imx_mu_dcfg { > + enum imx_mu_type type; > + u32 xTR; /* Transmit Register0 */ > + u32 xRR; /* Receive Register0 */ > + u32 xSR[4]; /* Status Registers */ > + u32 xCR[4]; /* Control Registers */ > +}; > + > +struct imx_mu_msi { > + spinlock_t lock; > + raw_spinlock_t reglock; Why two locks? Isn't one enough to protect both MSI allocation (which happens once in a blue moon) and register access? Also, where are these locks initialised? > + struct irq_domain *msi_domain; > + void __iomem *regs; > + phys_addr_t msiir_addr; > + const struct imx_mu_dcfg *cfg; > + unsigned long used; > + struct clk *clk; > +}; > + > +static void imx_mu_write(struct imx_mu_msi *msi_data, u32 val, u32 offs) > +{ > + iowrite32(val, msi_data->regs + offs); > +} > + > +static u32 imx_mu_read(struct imx_mu_msi *msi_data, u32 offs) > +{ > + return ioread32(msi_data->regs + offs); > +} > + > +static u32 imx_mu_xcr_rmw(struct imx_mu_msi *msi_data, enum imx_mu_xcr type, u32 set, u32 clr) > +{ > + unsigned long flags; > + u32 val; > + > + raw_spin_lock_irqsave(&msi_data->reglock, flags); > + val = imx_mu_read(msi_data, msi_data->cfg->xCR[type]); > + val &= ~clr; > + val |= set; > + imx_mu_write(msi_data, val, msi_data->cfg->xCR[type]); > + raw_spin_unlock_irqrestore(&msi_data->reglock, flags); > + > + return val; > +} > + > +static void imx_mu_msi_parent_mask_irq(struct irq_data *data) > +{ > + struct imx_mu_msi *msi_data = irq_data_get_irq_chip_data(data); > + > + imx_mu_xcr_rmw(msi_data, IMX_MU_RCR, 0, IMX_MU_xCR_RIEn(msi_data, data->hwirq)); > +} > + > +static void imx_mu_msi_parent_unmask_irq(struct irq_data *data) > +{ > + struct imx_mu_msi *msi_data = irq_data_get_irq_chip_data(data); > + > + imx_mu_xcr_rmw(msi_data, IMX_MU_RCR, IMX_MU_xCR_RIEn(msi_data, data->hwirq), 0); > +} > + > +static void imx_mu_msi_parent_ack_irq(struct irq_data *data) > +{ > + struct imx_mu_msi *msi_data = irq_data_get_irq_chip_data(data); > + > + imx_mu_read(msi_data, msi_data->cfg->xRR + data->hwirq * 4); > +} > + > +static struct irq_chip imx_mu_msi_irq_chip = { > + .name = "MU-MSI", > + .irq_ack = irq_chip_ack_parent, > +}; > + > +static struct msi_domain_ops imx_mu_msi_irq_ops = { > +}; > + > +static struct msi_domain_info imx_mu_msi_domain_info = { > + .flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS), > + .ops = &imx_mu_msi_irq_ops, > + .chip = &imx_mu_msi_irq_chip, > +}; > + > +static void imx_mu_msi_parent_compose_msg(struct irq_data *data, > + struct msi_msg *msg) > +{ > + struct imx_mu_msi *msi_data = irq_data_get_irq_chip_data(data); > + u64 addr = msi_data->msiir_addr + 4 * data->hwirq; > + > + msg->address_hi = upper_32_bits(addr); > + msg->address_lo = lower_32_bits(addr); > + msg->data = data->hwirq; > +} > + > +static int imx_mu_msi_parent_set_affinity(struct irq_data *irq_data, > + const struct cpumask *mask, bool force) > +{ > + return -EINVAL; > +} > + > +static struct irq_chip imx_mu_msi_parent_chip = { > + .name = "MU", > + .irq_mask = imx_mu_msi_parent_mask_irq, > + .irq_unmask = imx_mu_msi_parent_unmask_irq, > + .irq_ack = imx_mu_msi_parent_ack_irq, > + .irq_compose_msi_msg = imx_mu_msi_parent_compose_msg, > + .irq_set_affinity = imx_mu_msi_parent_set_affinity, > +}; > + > +static int imx_mu_msi_domain_irq_alloc(struct irq_domain *domain, > + unsigned int virq, > + unsigned int nr_irqs, > + void *args) > +{ > + struct imx_mu_msi *msi_data = domain->host_data; > + unsigned long flags; > + int pos, err = 0; > + > + WARN_ON(nr_irqs != 1); > + > + spin_lock_irqsave(&msi_data->lock, flags); > + pos = find_first_zero_bit(&msi_data->used, IMX_MU_CHANS); > + if (pos < IMX_MU_CHANS) > + __set_bit(pos, &msi_data->used); > + else > + err = -ENOSPC; > + spin_unlock_irqrestore(&msi_data->lock, flags); > + > + if (err) > + return err; > + > + irq_domain_set_info(domain, virq, pos, > + &imx_mu_msi_parent_chip, msi_data, > + handle_edge_irq, NULL, NULL); > + return 0; > +} > + > +static void imx_mu_msi_domain_irq_free(struct irq_domain *domain, > + unsigned int virq, unsigned int nr_irqs) > +{ > + struct irq_data *d = irq_domain_get_irq_data(domain, virq); > + struct imx_mu_msi *msi_data = irq_data_get_irq_chip_data(d); > + unsigned long flags; > + > + spin_lock_irqsave(&msi_data->lock, flags); > + __clear_bit(d->hwirq, &msi_data->used); > + spin_unlock_irqrestore(&msi_data->lock, flags); > +} > + > +static const struct irq_domain_ops imx_mu_msi_domain_ops = { > + .alloc = imx_mu_msi_domain_irq_alloc, > + .free = imx_mu_msi_domain_irq_free, > +}; > + > +static void imx_mu_msi_irq_handler(struct irq_desc *desc) > +{ > + struct imx_mu_msi *msi_data = irq_desc_get_handler_data(desc); > + struct irq_chip *chip = irq_desc_get_chip(desc); > + u32 status; > + int i; > + > + status = imx_mu_read(msi_data, msi_data->cfg->xSR[IMX_MU_RSR]); > + > + chained_irq_enter(chip, desc); > + for (i = 0; i < IMX_MU_CHANS; i++) { > + if (status & IMX_MU_xSR_RFn(msi_data, i)) > + generic_handle_domain_irq(msi_data->msi_domain, i); > + } > + chained_irq_exit(chip, desc); > +} > + > +static int imx_mu_msi_domains_init(struct imx_mu_msi *msi_data, struct device *dev) > +{ > + struct fwnode_handle *fwnodes = dev_fwnode(dev); > + struct irq_domain *parent; > + > + /* Initialize MSI domain parent */ > + parent = irq_domain_create_linear(fwnodes, > + IMX_MU_CHANS, > + &imx_mu_msi_domain_ops, > + msi_data); > + if (!parent) { > + dev_err(dev, "failed to create IRQ domain\n"); > + return -ENOMEM; > + } > + > + irq_domain_update_bus_token(parent, DOMAIN_BUS_NEXUS); > + > + msi_data->msi_domain = platform_msi_create_irq_domain( > + fwnodes, > + &imx_mu_msi_domain_info, > + parent); nit: move the first argument after the opening bracket (longer lines are fine). > + > + if (!msi_data->msi_domain) { > + dev_err(dev, "failed to create MSI domain\n"); > + irq_domain_remove(parent); > + return -ENOMEM; > + } > + > + irq_domain_set_pm_device(msi_data->msi_domain, dev); > + > + return 0; > +} > + > +/* Register offset of different version MU IP */ > +static const struct imx_mu_dcfg imx_mu_cfg_imx6sx = { Why doesn't this have a type? > + .xTR = 0x0, > + .xRR = 0x10, > + .xSR = {0x20, 0x20, 0x20, 0x20}, Since you defined enums for all the register offsets, please be consistent and use them everywhere: .xSR = { [IMX_MU_SR] = 0x20, [IMX_MU_GSR] = 0x20, [...] }, > + .xCR = {0x24, 0x24, 0x24, 0x24}, > +}; > + > +static const struct imx_mu_dcfg imx_mu_cfg_imx7ulp = { > + .xTR = 0x20, > + .xRR = 0x40, > + .xSR = {0x60, 0x60, 0x60, 0x60}, > + .xCR = {0x64, 0x64, 0x64, 0x64}, > +}; > + > +static const struct imx_mu_dcfg imx_mu_cfg_imx8ulp = { > + .type = IMX_MU_V2, > + .xTR = 0x200, > + .xRR = 0x280, > + .xSR = {0xC, 0x118, 0x124, 0x12C}, > + .xCR = {0x110, 0x114, 0x120, 0x128}, > +}; > + > +static const struct imx_mu_dcfg imx_mu_cfg_imx8ulp_s4 = { > + > + .type = IMX_MU_V2 | IMX_MU_V2_S4, > + .xTR = 0x200, > + .xRR = 0x280, > + .xSR = {0xC, 0x118, 0x124, 0x12C}, > + .xCR = {0x110, 0x114, 0x120, 0x128}, > +}; > + > +static int __init imx_mu_of_init(struct device_node *dn, > + struct device_node *parent, > + const struct imx_mu_dcfg *cfg > + ) Move closing bracket after 'cfg'. > +{ > + struct platform_device *pdev = of_find_device_by_node(dn); > + struct device_link *pd_link_a; > + struct device_link *pd_link_b; > + struct imx_mu_msi *msi_data; > + struct resource *res; > + struct device *pd_a; > + struct device *pd_b; > + struct device *dev; > + int ret; > + int irq; > + > + if (!pdev) > + return -ENODEV; How can that happen? > + > + dev = &pdev->dev; > + > + msi_data = devm_kzalloc(&pdev->dev, sizeof(*msi_data), GFP_KERNEL); > + if (!msi_data) > + return -ENOMEM; > + > + msi_data->cfg = cfg; > + > + msi_data->regs = devm_platform_ioremap_resource_byname(pdev, "processor-a-side"); > + if (IS_ERR(msi_data->regs)) { > + dev_err(&pdev->dev, "failed to initialize 'regs'\n"); > + return PTR_ERR(msi_data->regs); > + } > + > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "processor-b-side"); > + if (!res) > + return -EIO; > + > + msi_data->msiir_addr = res->start + msi_data->cfg->xTR; > + > + irq = platform_get_irq(pdev, 0); > + if (irq <= 0) > + return -ENODEV; > + > + platform_set_drvdata(pdev, msi_data); > + > + msi_data->clk = devm_clk_get(dev, NULL); > + if (IS_ERR(msi_data->clk)) { > + if (PTR_ERR(msi_data->clk) != -ENOENT) > + return PTR_ERR(msi_data->clk); > + > + msi_data->clk = NULL; Why is it acceptable to continue with no clock? > + } > + > + pd_a = dev_pm_domain_attach_by_name(dev, "processor-a-side"); > + if (IS_ERR(pd_a)) > + return PTR_ERR(pd_a); > + > + pd_b = dev_pm_domain_attach_by_name(dev, "processor-b-side"); > + if (IS_ERR(pd_b)) > + return PTR_ERR(pd_b); > + > + pd_link_a = device_link_add(dev, pd_a, > + DL_FLAG_STATELESS | > + DL_FLAG_PM_RUNTIME | > + DL_FLAG_RPM_ACTIVE); > + > + if (!pd_link_a) { > + dev_err(dev, "Failed to add device_link to mu a.\n"); > + goto err_pd_a; > + } > + > + pd_link_b = device_link_add(dev, pd_b, > + DL_FLAG_STATELESS | > + DL_FLAG_PM_RUNTIME | > + DL_FLAG_RPM_ACTIVE); > + > + > + if (!pd_link_b) { > + dev_err(dev, "Failed to add device_link to mu a.\n"); > + goto err_pd_b; > + } > + > + ret = imx_mu_msi_domains_init(msi_data, dev); > + if (ret) > + goto err_dm_init; > + > + irq_set_chained_handler_and_data(irq, > + imx_mu_msi_irq_handler, > + msi_data); > + > + pm_runtime_enable(dev); Shouldn't you enable the device PM before registering the chained handler? M. -- Without deviation from the norm, progress is not possible.