| 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
| ||
|
Message-ID: <20230414-bounding-guidance-262dffacd05c-mkl@pengutronix.de>
Date: Fri, 14 Apr 2023 20:20:01 +0200
From: Marc Kleine-Budde <mkl@...gutronix.de>
To: Judith Mendez <jm@...com>
Cc: Chandrasekar Ramakrishnan <rcsekar@...sung.com>,
Nishanth Menon <nm@...com>,
Vignesh Raghavendra <vigneshr@...com>,
Andrew Davis <afd@...com>,
Wolfgang Grandegger <wg@...ndegger.com>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
linux-can@...r.kernel.org, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org, netdev@...r.kernel.org,
Schuyler Patton <spatton@...com>
Subject: Re: [RFC PATCH 5/5] can: m_can: Add hrtimer to generate software
interrupt
On 13.04.2023 17:30:51, Judith Mendez wrote:
> Add a hrtimer to MCAN struct. Each MCAN will have its own
> hrtimer instantiated if there is no hardware interrupt found.
>
> The hrtimer will generate a software interrupt every 1 ms. In
Are you sure about the 1ms?
> hrtimer callback, we check if there is a transaction pending by
> reading a register, then process by calling the isr if there is.
>
> Signed-off-by: Judith Mendez <jm@...com>
> ---
> drivers/net/can/m_can/m_can.c | 24 ++++++++++++++++++++++--
> drivers/net/can/m_can/m_can.h | 3 +++
> drivers/net/can/m_can/m_can_platform.c | 9 +++++++--
> 3 files changed, 32 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
> index 8e83d6963d85..bb9d53f4d3cc 100644
> --- a/drivers/net/can/m_can/m_can.c
> +++ b/drivers/net/can/m_can/m_can.c
> @@ -23,6 +23,7 @@
> #include <linux/pinctrl/consumer.h>
> #include <linux/platform_device.h>
> #include <linux/pm_runtime.h>
> +#include <linux/hrtimer.h>
>
> #include "m_can.h"
>
> @@ -1584,6 +1585,11 @@ static int m_can_close(struct net_device *dev)
> if (!cdev->is_peripheral)
> napi_disable(&cdev->napi);
>
> + if (dev->irq < 0) {
> + dev_info(cdev->dev, "Disabling the hrtimer\n");
Make it a dev_dbg() or remove completely.
> + hrtimer_cancel(&cdev->hrtimer);
> + }
> +
> m_can_stop(dev);
> m_can_clk_stop(cdev);
> free_irq(dev->irq, dev);
> @@ -1792,6 +1798,19 @@ static netdev_tx_t m_can_start_xmit(struct sk_buff *skb,
> return NETDEV_TX_OK;
> }
>
> +enum hrtimer_restart hrtimer_callback(struct hrtimer *timer)
> +{
> + irqreturn_t ret;
never read value?
> + struct m_can_classdev *cdev =
> + container_of(timer, struct m_can_classdev, hrtimer);
> +
> + ret = m_can_isr(0, cdev->net);
> +
> + hrtimer_forward_now(timer, ns_to_ktime(5 * NSEC_PER_MSEC));
There's ms_to_ktime()....and the "5" doesn't match your patch
description.
> +
> + return HRTIMER_RESTART;
> +}
> +
> static int m_can_open(struct net_device *dev)
> {
> struct m_can_classdev *cdev = netdev_priv(dev);
> @@ -1836,8 +1855,9 @@ static int m_can_open(struct net_device *dev)
> }
>
> if (err < 0) {
> - netdev_err(dev, "failed to request interrupt\n");
> - goto exit_irq_fail;
> + dev_info(cdev->dev, "Enabling the hrtimer\n");
> + cdev->hrtimer.function = &hrtimer_callback;
> + hrtimer_start(&cdev->hrtimer, ns_to_ktime(0), HRTIMER_MODE_REL_PINNED);
IMHO it makes no sense to request an IRQ if the device doesn't have one,
and then try to fix up things in the error path. What about this?
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -1831,9 +1831,11 @@ static int m_can_open(struct net_device *dev)
err = request_threaded_irq(dev->irq, NULL, m_can_isr,
IRQF_ONESHOT,
dev->name, dev);
- } else {
+ } else if (dev->irq) {
err = request_irq(dev->irq, m_can_isr, IRQF_SHARED, dev->name,
dev);
+ } else {
+ // polling
}
if (err < 0) {
> }
>
> /* start the m_can controller */
> diff --git a/drivers/net/can/m_can/m_can.h b/drivers/net/can/m_can/m_can.h
> index a839dc71dc9b..ed046d77fdb9 100644
> --- a/drivers/net/can/m_can/m_can.h
> +++ b/drivers/net/can/m_can/m_can.h
> @@ -28,6 +28,7 @@
> #include <linux/pm_runtime.h>
> #include <linux/slab.h>
> #include <linux/uaccess.h>
> +#include <linux/hrtimer.h>
>
> /* m_can lec values */
> enum m_can_lec_type {
> @@ -93,6 +94,8 @@ struct m_can_classdev {
> int is_peripheral;
>
> struct mram_cfg mcfg[MRAM_CFG_NUM];
> +
> + struct hrtimer hrtimer;
> };
>
> struct m_can_classdev *m_can_class_allocate_dev(struct device *dev, int sizeof_priv);
> diff --git a/drivers/net/can/m_can/m_can_platform.c b/drivers/net/can/m_can/m_can_platform.c
> index 9c1dcf838006..53e1648e9dab 100644
> --- a/drivers/net/can/m_can/m_can_platform.c
> +++ b/drivers/net/can/m_can/m_can_platform.c
> @@ -7,6 +7,7 @@
>
> #include <linux/phy/phy.h>
> #include <linux/platform_device.h>
> +#include <linux/hrtimer.h>
>
> #include "m_can.h"
>
> @@ -98,8 +99,12 @@ static int m_can_plat_probe(struct platform_device *pdev)
> addr = devm_platform_ioremap_resource_byname(pdev, "m_can");
> irq = platform_get_irq_byname(pdev, "int0");
> if (IS_ERR(addr) || irq < 0) {
What about the IS_ERR(addr) case?
> - ret = -EINVAL;
> - goto probe_fail;
> + if (irq == -EPROBE_DEFER) {
> + ret = -EPROBE_DEFER;
> + goto probe_fail;
> + }
> + dev_info(mcan_class->dev, "Failed to get irq, initialize hrtimer\n");
> + hrtimer_init(&mcan_class->hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL_PINNED);
I don't like it when polling is unconditionally set up in case of an irq
error. I'm not sure if we need an explicit device tree property....
> }
>
> /* message ram could be shared */
> --
> 2.17.1
>
>
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung Nürnberg | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists