All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Slaby <jirislaby@kernel.org>
To: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>,
	linux-arm-kernel@lists.infradead.org, soc@kernel.org,
	linux-serial@vger.kernel.org, sumit.garg@linaro.org
Cc: arnd@arndb.de, olof@lixom.net, catalin.marinas@arm.com,
	will@kernel.org, gregkh@linuxfoundation.org,
	jason.wessel@windriver.com, daniel.thompson@linaro.org,
	dianders@chromium.org, linux-kernel@vger.kernel.org,
	kgdb-bugreport@lists.sourceforge.net, peterz@infradead.org
Subject: Re: [PATCH v4 1/1] soc: fujitsu: Add A64FX diagnostic interrupt driver
Date: Wed, 11 May 2022 08:47:50 +0200	[thread overview]
Message-ID: <48cfa0b3-0424-81bd-ac6a-d631184b71b7@kernel.org> (raw)
In-Reply-To: <20220511062113.2645747-2-hasegawa-hitomi@fujitsu.com>

On 11. 05. 22, 8:21, Hitomi Hasegawa wrote:
> Enable diagnostic interrupts for the Fujitsu A64FX.
> 
> Register the NMI/IRQ corresponding to the A64FX's device definition
> dedicated to diagnostic interrupts, so that when this interrupt is
> sent using the BMC, it causes a panic. This can be used to obtain
> a kernel dump.
> 
> Signed-off-by: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>

Hi,

I'm not sure why you cc linux-serial, but anyway, comments below :).

> --- /dev/null
> +++ b/drivers/soc/fujitsu/a64fx-diag.c
> @@ -0,0 +1,155 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * A64FX diag driver.
> + * Copyright (c) 2022 Fujitsu Ltd.
> + */
> +
> +#include <linux/acpi.h>
> +#include <linux/interrupt.h>
> +#include <linux/irq.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +
> +#define A64FX_DIAG_IRQ 1
> +#define BMC_DIAG_INTERRUPT_STATUS_OFFSET (0x0044)
> +#define BMC_DIAG_INTERRUPT_ENABLE_OFFSET (0x0040)
> +#define BMC_DIAG_INTERRUPT_MASK BIT(31)
> +
> +struct a64fx_diag_priv {
> +	int irq;
> +	void __iomem *mmsc_reg_base;
> +	bool has_nmi;

There are unnecessary holes in the struct. If you reorder it, you drop 
some alignment. Like: pointer, int, bool.

> +};
> +
> +static irqreturn_t a64fx_diag_handler_nmi(int irq, void *dev_id)
> +{
> +	nmi_panic(NULL, "a64fx_diag: interrupt received\n");
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static irqreturn_t a64fx_diag_handler_irq(int irq, void *dev_id)
> +{
> +	panic("a64fx_diag: interrupt received\n");
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static void a64fx_diag_interrupt_clear(struct a64fx_diag_priv *priv)
> +{
> +	u32 mmsc;
> +	void __iomem *diag_status_reg_addr;

I'm not sure what soc/ maintainers prefer, but inverted xmas tree would 
look/read better.

> +
> +	diag_status_reg_addr = priv->mmsc_reg_base + BMC_DIAG_INTERRUPT_STATUS_OFFSET;
> +	mmsc = readl(diag_status_reg_addr);
> +	if (mmsc & BMC_DIAG_INTERRUPT_MASK)
> +		writel(BMC_DIAG_INTERRUPT_MASK, diag_status_reg_addr);
> +}
> +
> +static void a64fx_diag_interrupt_enable(struct a64fx_diag_priv *priv)
> +{
> +	u32 mmsc;
> +	void __iomem *diag_enable_reg_addr;
> +
> +	diag_enable_reg_addr = priv->mmsc_reg_base + BMC_DIAG_INTERRUPT_ENABLE_OFFSET;
> +	mmsc = readl(diag_enable_reg_addr);
> +	if (!(mmsc & BMC_DIAG_INTERRUPT_MASK)) {
> +		mmsc |= BMC_DIAG_INTERRUPT_MASK;
> +		writel(mmsc, diag_enable_reg_addr);
> +	}
> +}
> +
> +static void a64fx_diag_interrupt_disable(struct a64fx_diag_priv *priv)
> +{
> +	u32 mmsc;
> +	void __iomem *diag_enable_reg_addr;
> +
> +	diag_enable_reg_addr = priv->mmsc_reg_base + BMC_DIAG_INTERRUPT_ENABLE_OFFSET;
> +	mmsc = readl(diag_enable_reg_addr);
> +	if (mmsc & BMC_DIAG_INTERRUPT_MASK) {
> +		mmsc &= ~BMC_DIAG_INTERRUPT_MASK;
> +		writel(mmsc, diag_enable_reg_addr);
> +	}
> +}
> +
> +static int a64fx_diag_probe(struct platform_device *pdev)
> +{
> +	int ret;
> +	unsigned long irq_flags;
> +	struct device *dev = &pdev->dev;
> +	struct a64fx_diag_priv *priv;
> +
> +	priv = devm_kzalloc(dev, sizeof(struct a64fx_diag_priv), GFP_KERNEL);

Don't we prefer sizeof(*priv)?

> +	if (priv == NULL)
> +		return -ENOMEM;
> +
> +	priv->mmsc_reg_base = devm_platform_ioremap_resource(pdev, 0);
> +	if (IS_ERR(priv->mmsc_reg_base))
> +		return PTR_ERR(priv->mmsc_reg_base);
> +
> +	priv->irq = platform_get_irq(pdev, A64FX_DIAG_IRQ);
> +	if (priv->irq < 0)
> +		return priv->irq;
> +
> +	platform_set_drvdata(pdev, priv);
> +
> +	a64fx_diag_interrupt_clear(priv);
> +	a64fx_diag_interrupt_enable(priv);
> +
> +	irq_flags = IRQF_PERCPU | IRQF_NOBALANCING | IRQF_NO_AUTOEN |
> +		   IRQF_NO_THREAD;
> +	ret = request_nmi(priv->irq, &a64fx_diag_handler_nmi, irq_flags,
> +			"a64fx_diag_nmi", NULL);
> +	if (ret) {
> +		ret = request_irq(priv->irq, &a64fx_diag_handler_irq,
> +				irq_flags, "a64fx_diag_irq", NULL);
> +		if (ret) {
> +			dev_err(dev, "cannot register IRQ %d\n", ret);

No a64fx_diag_interrupt_disable()?

> +			return ret;
> +		}
> +		enable_irq(priv->irq);

Hmm...

> +		priv->has_nmi = false;

No need to set zeroed priv member to zero.

> +	} else {
> +		enable_nmi(priv->irq);

Provided the above, I don't immediatelly see, what's the purpose of 
IRQF_NO_AUTOEN then?

> +		priv->has_nmi = true;
> +	}
> +
> +	return 0;
> +}
> +
> +static int __exit a64fx_diag_remove(struct platform_device *pdev)

Is __exit appropriate here at all -- I doubt that.

> +{
> +	struct a64fx_diag_priv *priv = platform_get_drvdata(pdev);
> +
> +	a64fx_diag_interrupt_disable(priv);
> +	a64fx_diag_interrupt_clear(priv);
> +
> +	if (priv->has_nmi)
> +		free_nmi(priv->irq, NULL);
> +	else
> +		free_irq(priv->irq, NULL);
> +
> +	return 0;
> +}
> +
> +static const struct acpi_device_id a64fx_diag_acpi_match[] = {
> +	{ "FUJI2007", 0 },
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(acpi, a64fx_diag_acpi_match);
> +
> +
> +static struct platform_driver a64fx_diag_driver = {
> +	.driver = {
> +		.name = "a64fx_diag_driver",
> +		.acpi_match_table = ACPI_PTR(a64fx_diag_acpi_match),
> +	},
> +	.probe = a64fx_diag_probe,
> +	.remove = a64fx_diag_remove,
> +};
> +
> +module_platform_driver(a64fx_diag_driver);
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_AUTHOR("Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>");
> +MODULE_DESCRIPTION("A64FX diag driver");


-- 
js
suse labs

WARNING: multiple messages have this Message-ID (diff)
From: Jiri Slaby <jirislaby@kernel.org>
To: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>,
	linux-arm-kernel@lists.infradead.org, soc@kernel.org,
	linux-serial@vger.kernel.org, sumit.garg@linaro.org
Cc: arnd@arndb.de, olof@lixom.net, catalin.marinas@arm.com,
	will@kernel.org, gregkh@linuxfoundation.org,
	jason.wessel@windriver.com, daniel.thompson@linaro.org,
	dianders@chromium.org, linux-kernel@vger.kernel.org,
	kgdb-bugreport@lists.sourceforge.net, peterz@infradead.org
Subject: Re: [PATCH v4 1/1] soc: fujitsu: Add A64FX diagnostic interrupt driver
Date: Wed, 11 May 2022 08:47:50 +0200	[thread overview]
Message-ID: <48cfa0b3-0424-81bd-ac6a-d631184b71b7@kernel.org> (raw)
In-Reply-To: <20220511062113.2645747-2-hasegawa-hitomi@fujitsu.com>

On 11. 05. 22, 8:21, Hitomi Hasegawa wrote:
> Enable diagnostic interrupts for the Fujitsu A64FX.
> 
> Register the NMI/IRQ corresponding to the A64FX's device definition
> dedicated to diagnostic interrupts, so that when this interrupt is
> sent using the BMC, it causes a panic. This can be used to obtain
> a kernel dump.
> 
> Signed-off-by: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>

Hi,

I'm not sure why you cc linux-serial, but anyway, comments below :).

> --- /dev/null
> +++ b/drivers/soc/fujitsu/a64fx-diag.c
> @@ -0,0 +1,155 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * A64FX diag driver.
> + * Copyright (c) 2022 Fujitsu Ltd.
> + */
> +
> +#include <linux/acpi.h>
> +#include <linux/interrupt.h>
> +#include <linux/irq.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +
> +#define A64FX_DIAG_IRQ 1
> +#define BMC_DIAG_INTERRUPT_STATUS_OFFSET (0x0044)
> +#define BMC_DIAG_INTERRUPT_ENABLE_OFFSET (0x0040)
> +#define BMC_DIAG_INTERRUPT_MASK BIT(31)
> +
> +struct a64fx_diag_priv {
> +	int irq;
> +	void __iomem *mmsc_reg_base;
> +	bool has_nmi;

There are unnecessary holes in the struct. If you reorder it, you drop 
some alignment. Like: pointer, int, bool.

> +};
> +
> +static irqreturn_t a64fx_diag_handler_nmi(int irq, void *dev_id)
> +{
> +	nmi_panic(NULL, "a64fx_diag: interrupt received\n");
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static irqreturn_t a64fx_diag_handler_irq(int irq, void *dev_id)
> +{
> +	panic("a64fx_diag: interrupt received\n");
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static void a64fx_diag_interrupt_clear(struct a64fx_diag_priv *priv)
> +{
> +	u32 mmsc;
> +	void __iomem *diag_status_reg_addr;

I'm not sure what soc/ maintainers prefer, but inverted xmas tree would 
look/read better.

> +
> +	diag_status_reg_addr = priv->mmsc_reg_base + BMC_DIAG_INTERRUPT_STATUS_OFFSET;
> +	mmsc = readl(diag_status_reg_addr);
> +	if (mmsc & BMC_DIAG_INTERRUPT_MASK)
> +		writel(BMC_DIAG_INTERRUPT_MASK, diag_status_reg_addr);
> +}
> +
> +static void a64fx_diag_interrupt_enable(struct a64fx_diag_priv *priv)
> +{
> +	u32 mmsc;
> +	void __iomem *diag_enable_reg_addr;
> +
> +	diag_enable_reg_addr = priv->mmsc_reg_base + BMC_DIAG_INTERRUPT_ENABLE_OFFSET;
> +	mmsc = readl(diag_enable_reg_addr);
> +	if (!(mmsc & BMC_DIAG_INTERRUPT_MASK)) {
> +		mmsc |= BMC_DIAG_INTERRUPT_MASK;
> +		writel(mmsc, diag_enable_reg_addr);
> +	}
> +}
> +
> +static void a64fx_diag_interrupt_disable(struct a64fx_diag_priv *priv)
> +{
> +	u32 mmsc;
> +	void __iomem *diag_enable_reg_addr;
> +
> +	diag_enable_reg_addr = priv->mmsc_reg_base + BMC_DIAG_INTERRUPT_ENABLE_OFFSET;
> +	mmsc = readl(diag_enable_reg_addr);
> +	if (mmsc & BMC_DIAG_INTERRUPT_MASK) {
> +		mmsc &= ~BMC_DIAG_INTERRUPT_MASK;
> +		writel(mmsc, diag_enable_reg_addr);
> +	}
> +}
> +
> +static int a64fx_diag_probe(struct platform_device *pdev)
> +{
> +	int ret;
> +	unsigned long irq_flags;
> +	struct device *dev = &pdev->dev;
> +	struct a64fx_diag_priv *priv;
> +
> +	priv = devm_kzalloc(dev, sizeof(struct a64fx_diag_priv), GFP_KERNEL);

Don't we prefer sizeof(*priv)?

> +	if (priv == NULL)
> +		return -ENOMEM;
> +
> +	priv->mmsc_reg_base = devm_platform_ioremap_resource(pdev, 0);
> +	if (IS_ERR(priv->mmsc_reg_base))
> +		return PTR_ERR(priv->mmsc_reg_base);
> +
> +	priv->irq = platform_get_irq(pdev, A64FX_DIAG_IRQ);
> +	if (priv->irq < 0)
> +		return priv->irq;
> +
> +	platform_set_drvdata(pdev, priv);
> +
> +	a64fx_diag_interrupt_clear(priv);
> +	a64fx_diag_interrupt_enable(priv);
> +
> +	irq_flags = IRQF_PERCPU | IRQF_NOBALANCING | IRQF_NO_AUTOEN |
> +		   IRQF_NO_THREAD;
> +	ret = request_nmi(priv->irq, &a64fx_diag_handler_nmi, irq_flags,
> +			"a64fx_diag_nmi", NULL);
> +	if (ret) {
> +		ret = request_irq(priv->irq, &a64fx_diag_handler_irq,
> +				irq_flags, "a64fx_diag_irq", NULL);
> +		if (ret) {
> +			dev_err(dev, "cannot register IRQ %d\n", ret);

No a64fx_diag_interrupt_disable()?

> +			return ret;
> +		}
> +		enable_irq(priv->irq);

Hmm...

> +		priv->has_nmi = false;

No need to set zeroed priv member to zero.

> +	} else {
> +		enable_nmi(priv->irq);

Provided the above, I don't immediatelly see, what's the purpose of 
IRQF_NO_AUTOEN then?

> +		priv->has_nmi = true;
> +	}
> +
> +	return 0;
> +}
> +
> +static int __exit a64fx_diag_remove(struct platform_device *pdev)

Is __exit appropriate here at all -- I doubt that.

> +{
> +	struct a64fx_diag_priv *priv = platform_get_drvdata(pdev);
> +
> +	a64fx_diag_interrupt_disable(priv);
> +	a64fx_diag_interrupt_clear(priv);
> +
> +	if (priv->has_nmi)
> +		free_nmi(priv->irq, NULL);
> +	else
> +		free_irq(priv->irq, NULL);
> +
> +	return 0;
> +}
> +
> +static const struct acpi_device_id a64fx_diag_acpi_match[] = {
> +	{ "FUJI2007", 0 },
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(acpi, a64fx_diag_acpi_match);
> +
> +
> +static struct platform_driver a64fx_diag_driver = {
> +	.driver = {
> +		.name = "a64fx_diag_driver",
> +		.acpi_match_table = ACPI_PTR(a64fx_diag_acpi_match),
> +	},
> +	.probe = a64fx_diag_probe,
> +	.remove = a64fx_diag_remove,
> +};
> +
> +module_platform_driver(a64fx_diag_driver);
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_AUTHOR("Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>");
> +MODULE_DESCRIPTION("A64FX diag driver");


-- 
js
suse labs

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-05-11  6:47 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-11  6:21 [PATCH v4 0/1] soc: fujitsu: Add A64FX diagnostic interrupt driver Hitomi Hasegawa
2022-05-11  6:21 ` Hitomi Hasegawa
2022-05-11  6:21 ` [PATCH v4 1/1] " Hitomi Hasegawa
2022-05-11  6:21   ` Hitomi Hasegawa
2022-05-11  6:47   ` Jiri Slaby [this message]
2022-05-11  6:47     ` Jiri Slaby
2022-05-17  9:53     ` hasegawa-hitomi
2022-05-17  9:53       ` hasegawa-hitomi
2022-05-11  6:50   ` Greg KH
2022-05-11  6:50     ` Greg KH
2022-05-13 10:13     ` Arnd Bergmann
2022-05-13 10:13       ` Arnd Bergmann
2022-05-17  9:54     ` hasegawa-hitomi
2022-05-17  9:54       ` hasegawa-hitomi
2022-05-11  6:51   ` Jiri Slaby
2022-05-11  6:51     ` Jiri Slaby

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=48cfa0b3-0424-81bd-ac6a-d631184b71b7@kernel.org \
    --to=jirislaby@kernel.org \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=daniel.thompson@linaro.org \
    --cc=dianders@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hasegawa-hitomi@fujitsu.com \
    --cc=jason.wessel@windriver.com \
    --cc=kgdb-bugreport@lists.sourceforge.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=olof@lixom.net \
    --cc=peterz@infradead.org \
    --cc=soc@kernel.org \
    --cc=sumit.garg@linaro.org \
    --cc=will@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.