linux-kernel - Re: [PATCH v3 04/26] platform: Add firmware-agnostic irq and affinity retrieval interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251009180351.00000d3d@huawei.com>
Date: Thu, 9 Oct 2025 18:03:51 +0100
From: Jonathan Cameron <jonathan.cameron@...wei.com>
To: Marc Zyngier <maz@...nel.org>
CC: <linux-kernel@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>,
	<linux-acpi@...r.kernel.org>, Thomas Gleixner <tglx@...utronix.de>, "Mark
 Rutland" <mark.rutland@....com>, Will Deacon <will@...nel.org>, "Rafael J.
 Wysocki" <rafael@...nel.org>, Rob Herring <robh@...nel.org>, "Saravana
 Kannan" <saravanak@...gle.com>, Greg Kroah-Hartman
	<gregkh@...uxfoundation.org>, Sven Peter <sven@...nel.org>, Janne Grunau
	<j@...nau.net>, Suzuki K Poulose <suzuki.poulose@....com>, James Clark
	<james.clark@...aro.org>
Subject: Re: [PATCH v3 04/26] platform: Add firmware-agnostic irq and
 affinity retrieval interface

On Mon, 22 Sep 2025 09:28:11 +0100
Marc Zyngier <maz@...nel.org> wrote:

> Expand platform_get_irq_optional() to also return an affinity if
> available, renaming it to platform_get_irq_affinity() in the
> process.
> 
> platform_get_irq_optional() is preserved with its current semantics
> by calling into the new helper with a NULL affinity pointer.
> 
> Signed-off-by: Marc Zyngier <maz@...nel.org>

Maybe a breadcrumb of a comment for those of us who can't be bothered
to figure out why this needs the ifndef CONFIG_SPARC?

Otherwise a question on whether it's worth spinning a fwnode.h handler
to hide away the fwnode type in get_irq_affinity.
I think not given the complexity already there for the platform device
irq stuff, but thought I'd mention it.

Reviewed-by: Jonathan Cameron <jonathan.cameron@...wei.com>

> ---
>  drivers/base/platform.c         | 60 +++++++++++++++++++++++++++------
>  include/linux/platform_device.h |  2 ++
>  2 files changed, 52 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 09450349cf323..3a058f63ef0d3 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -150,25 +150,37 @@ devm_platform_ioremap_resource_byname(struct platform_device *pdev,
>  EXPORT_SYMBOL_GPL(devm_platform_ioremap_resource_byname);
>  #endif /* CONFIG_HAS_IOMEM */
>  
> +static const struct cpumask *get_irq_affinity(struct platform_device *dev,
> +					      unsigned int num)
> +{
> +	const struct cpumask *mask = NULL;
> +#ifndef CONFIG_SPARC
> +	struct fwnode_handle *fwnode = dev_fwnode(&dev->dev);
> +
> +	if (is_of_node(fwnode))
> +		mask = of_irq_get_affinity(to_of_node(fwnode), num);
> +	else if (is_acpi_device_node(fwnode))
> +		mask = acpi_irq_get_affinity(ACPI_HANDLE_FWNODE(fwnode), num);

Not sure how useful it will be more generally, but maybe use fwnode.h and
appropriate callback rather than opencoding here?

Mind you the extra handling in existing platform_get_irq_optional()
for corner cases doesn't really fit with that model.

> +#endif
> +
> +	return mask ?: cpu_possible_mask;
> +}