[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL_JsqLmS4EEoPkOmaH6F_0XtQu5wkM-WEfxFvjLA=bJroEUVw@mail.gmail.com>
Date: Thu, 13 Mar 2025 13:44:40 -0500
From: Rob Herring <robh@...nel.org>
To: Roman Kisel <romank@...ux.microsoft.com>
Cc: arnd@...db.de, bhelgaas@...gle.com, bp@...en8.de, catalin.marinas@....com,
conor+dt@...nel.org, dave.hansen@...ux.intel.com, decui@...rosoft.com,
haiyangz@...rosoft.com, hpa@...or.com, joey.gouly@....com, krzk+dt@...nel.org,
kw@...ux.com, kys@...rosoft.com, lenb@...nel.org, lpieralisi@...nel.org,
manivannan.sadhasivam@...aro.org, mark.rutland@....com, maz@...nel.org,
mingo@...hat.com, oliver.upton@...ux.dev, rafael@...nel.org,
ssengar@...ux.microsoft.com, sudeep.holla@....com, suzuki.poulose@....com,
tglx@...utronix.de, wei.liu@...nel.org, will@...nel.org, yuzenghui@...wei.com,
devicetree@...r.kernel.org, kvmarm@...ts.linux.dev,
linux-acpi@...r.kernel.org, linux-arch@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-hyperv@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org, x86@...nel.org,
apais@...rosoft.com, benhill@...rosoft.com, bperkins@...rosoft.com,
sunilmut@...rosoft.com
Subject: Re: [PATCH hyperv-next v5 08/11] Drivers: hv: vmbus: Get the IRQ
number from DeviceTree
On Fri, Mar 7, 2025 at 4:03 PM Roman Kisel <romank@...ux.microsoft.com> wrote:
>
> The VMBus driver uses ACPI for interrupt assignment on
> arm64 hence it won't function in the VTL mode where only
> DeviceTree can be used.
>
> Update the VMBus driver to discover interrupt configuration
> from DT.
>
> Signed-off-by: Roman Kisel <romank@...ux.microsoft.com>
> Reviewed-by: Michael Kelley <mhklinux@...look.com>
> ---
> drivers/hv/vmbus_drv.c | 36 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index 75eb1390b45c..c8474b48dcd2 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -2345,6 +2345,36 @@ static int vmbus_acpi_add(struct platform_device *pdev)
> }
> #endif
>
> +static int __maybe_unused vmbus_set_irq(struct platform_device *pdev)
> +{
> + struct irq_data *data;
> + int irq;
> + irq_hw_number_t hwirq;
> +
> + irq = platform_get_irq(pdev, 0);
> + if (irq == 0) {
> + pr_err("VMBus interrupt mapping failure\n");
> + return -EINVAL;
> + }
> + if (irq < 0) {
> + pr_err("VMBus interrupt data can't be read from DeviceTree, error %d\n", irq);
> + return irq;
> + }
I don't think why you couldn't get the interrupt is important. Just
check for (irq <= 0) and be done with it. I'm not even sure if
returning 0 is possible now. There's a long history to that and
NO_IRQ.
Rob
Powered by blists - more mailing lists