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: <87pmhgwfyp.wl-maz@kernel.org>
Date:   Thu, 04 Aug 2022 09:49:50 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Nipun Gupta <nipun.gupta@....com>
Cc:     <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <gregkh@...uxfoundation.org>, <rafael@...nel.org>,
        <tglx@...utronix.de>, <okaya@...nel.org>, <harpreet.anand@....com>,
        <michal.simek@....com>, <nikhil.agarwal@....com>
Subject: Re: [RFC PATCH 1/2] irqchip: cdx-bus: add cdx-MSI domain with gic-its domain as parent

On Wed, 03 Aug 2022 13:26:54 +0100,
Nipun Gupta <nipun.gupta@....com> wrote:
> 
> Devices on cdx bus are dynamically detected and registered using
> platform_device_register API. As these devices are not linked to
> of node they need a separate MSI domain for handling device ID
> to be provided to the GIC ITS domain.
> 
> Signed-off-by: Nipun Gupta <nipun.gupta@....com>
> Signed-off-by: Nikhil Agarwal <nikhil.agarwal@....com>
> ---
> CONFIG_CDX_BUS and device tree bindings for xlnx,cdx-controller-1.0
> would be added as part of CDX bus patches
> 
>  drivers/irqchip/Makefile                 |   1 +
>  drivers/irqchip/irq-gic-v3-its-cdx-msi.c | 113 +++++++++++++++++++++++
>  include/linux/cdx/cdx.h                  |  15 +++
>  3 files changed, 129 insertions(+)
>  create mode 100644 drivers/irqchip/irq-gic-v3-its-cdx-msi.c
>  create mode 100644 include/linux/cdx/cdx.h
> 
> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> index 5b67450a9538..623adb8a1f20 100644
> --- a/drivers/irqchip/Makefile
> +++ b/drivers/irqchip/Makefile
> @@ -115,3 +115,4 @@ obj-$(CONFIG_WPCM450_AIC)		+= irq-wpcm450-aic.o
>  obj-$(CONFIG_IRQ_IDT3243X)		+= irq-idt3243x.o
>  obj-$(CONFIG_APPLE_AIC)			+= irq-apple-aic.o
>  obj-$(CONFIG_MCHP_EIC)			+= irq-mchp-eic.o
> +obj-$(CONFIG_CDX_BUS)			+= irq-gic-v3-its-cdx-msi.o
> diff --git a/drivers/irqchip/irq-gic-v3-its-cdx-msi.c b/drivers/irqchip/irq-gic-v3-its-cdx-msi.c
> new file mode 100644
> index 000000000000..eb17b74efdc5
> --- /dev/null
> +++ b/drivers/irqchip/irq-gic-v3-its-cdx-msi.c
> @@ -0,0 +1,113 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * AMD CDX bus driver MSI support
> + *
> + * Copyright(C) 2022 Xilinx Inc.
> + */
> +
> +#include <linux/irq.h>
> +#include <linux/msi.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_device.h>
> +#include <linux/of_irq.h>
> +#include <linux/cdx/cdx.h>
> +
> +static struct irq_chip its_msi_irq_chip = {
> +	.name = "ITS-fMSI",
> +	.irq_mask = irq_chip_mask_parent,
> +	.irq_unmask = irq_chip_unmask_parent,
> +	.irq_eoi = irq_chip_eoi_parent,
> +	.irq_set_affinity = msi_domain_set_affinity
> +};
> +
> +static int its_cdx_msi_prepare(struct irq_domain *msi_domain,
> +				  struct device *dev,
> +				  int nvec, msi_alloc_info_t *info)
> +{
> +	struct msi_domain_info *msi_info;
> +	struct cdx_device_data *dev_data;
> +	u32 dev_id;
> +
> +	dev_data = dev->platform_data;
> +	dev_id = dev_data->dev_id;
> +
> +	/* Set the device Id to be passed to the GIC-ITS */
> +	info->scratchpad[0].ul = dev_id;
> +
> +	msi_info = msi_get_domain_info(msi_domain->parent);
> +
> +	/* Allocate at least 32 MSIs, and always as a power of 2 */
> +	nvec = max_t(int, 32, roundup_pow_of_two(nvec));
> +	return msi_info->ops->msi_prepare(msi_domain->parent, dev, nvec, info);
> +}
> +
> +static struct msi_domain_ops its_cdx_msi_ops __ro_after_init = {
> +	.msi_prepare = its_cdx_msi_prepare,
> +};
> +
> +static struct msi_domain_info its_cdx_msi_domain_info = {
> +	.flags	= (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS),
> +	.ops	= &its_cdx_msi_ops,
> +	.chip	= &its_msi_irq_chip,
> +};
> +
> +static const struct of_device_id cdx_device_id[] = {
> +	{.compatible = "xlnx,cdx-controller-1.0", },

What is this? If this is supposed to represent am ITS, it really
should say so.

> +	{},
> +};
> +
> +struct irq_domain *get_parent(struct fwnode_handle *handle)
> +{
> +	return irq_find_matching_fwnode(handle, DOMAIN_BUS_NEXUS);
> +}
> +
> +static void __init its_cdx_msi_init_one(struct device_node *np,
> +				    const char *name)
> +{
> +	struct irq_domain *parent;
> +	struct irq_domain *cdx_msi_domain;
> +	struct fwnode_handle *fwnode_handle;
> +	struct device_node *parent_node;
> +
> +	parent_node = of_parse_phandle(np, "msi-parent", 0);
> +
> +	parent = get_parent(of_node_to_fwnode(parent_node));
> +	if (!parent || !msi_get_domain_info(parent)) {
> +		pr_err("%s: unable to locate ITS domain\n", name);
> +		return;
> +	}
> +
> +	fwnode_handle = of_node_to_fwnode(np);
> +	cdx_msi_domain = platform_msi_create_irq_domain(fwnode_handle,
> +						&its_cdx_msi_domain_info,
> +						parent);
> +	if (!cdx_msi_domain) {
> +		pr_err("%s: unable to create cdx bus domain\n", name);
> +		return;
> +	}
> +
> +	pr_info("cdx bus MSI: %s domain created\n", name);
> +}
> +
> +static void __init its_cdx_of_msi_init(void)
> +{
> +	struct device_node *np;
> +
> +	for (np = of_find_matching_node(NULL, cdx_device_id); np;
> +	     np = of_find_matching_node(np, cdx_device_id)) {
> +		if (!of_device_is_available(np))
> +			continue;
> +
> +		its_cdx_msi_init_one(np, np->full_name);
> +	}
> +}
> +
> +static int __init its_cdx_msi_init(void)
> +{
> +	its_cdx_of_msi_init();
> +
> +	return 0;
> +}
> +
> +early_initcall(its_cdx_msi_init);

I really don't think we should have any more of this muck. Yes, the
other busses are also doing that, but here's our chance to do
something better.

Why can't the *bus* driver (I assume there is one) perform these
tasks? It would really help if this patch was shown in context,
because I have no idea how this fits in the grand scheme of things.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ