linux-mediatek.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Pi-Hsun Shih <pihsun@chromium.org>
To: Neal Liu <neal.liu@mediatek.com>
Cc: Chun-Kuang Hu <chunkuang.hu@kernel.org>,
	wsd_upstream@mediatek.com,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>, lkml <linux-kernel@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	"moderated list:ARM/Mediatek SoC support"
	<linux-mediatek@lists.infradead.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	"moderated list:ARM/Mediatek SoC support"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v8 2/2] soc: mediatek: add mt6779 devapc driver
Date: Thu, 14 Jan 2021 17:40:26 +0800	[thread overview]
Message-ID: <CANdKZ0f7=-keVzKm7y5WHUhsCqjA75aCMf=ph+BmrDuS203fVg@mail.gmail.com> (raw)
In-Reply-To: <1602732039-12179-3-git-send-email-neal.liu@mediatek.com>

Hi Neal,
Please see inline comments below.

On Thu, Oct 15, 2020 at 11:21 AM Neal Liu <neal.liu@mediatek.com> wrote:
>
> MediaTek bus fabric provides TrustZone security support and data
> protection to prevent slaves from being accessed by unexpected
> masters.
> The security violation is logged and sent to the processor for
> further analysis or countermeasures.
>
> Any occurrence of security violation would raise an interrupt, and
> it will be handled by mtk-devapc driver. The violation
> information is printed in order to find the murderer.
>
> Signed-off-by: Neal Liu <neal.liu@mediatek.com>
> ---
>  drivers/soc/mediatek/Kconfig      |    9 ++
>  drivers/soc/mediatek/Makefile     |    1 +
>  drivers/soc/mediatek/mtk-devapc.c |  308 +++++++++++++++++++++++++++++++++++++
>  3 files changed, 318 insertions(+)
>  create mode 100644 drivers/soc/mediatek/mtk-devapc.c
>
> ...
> diff --git a/drivers/soc/mediatek/mtk-devapc.c b/drivers/soc/mediatek/mtk-devapc.c
> new file mode 100644
> index 0000000..f1cea04
> --- /dev/null
> +++ b/drivers/soc/mediatek/mtk-devapc.c
>
> ...
>
> +
> +static void clear_vio_status(struct mtk_devapc_context *ctx)
> +{
> +       void __iomem *reg;
> +       int i;
> +
> +       reg = ctx->infra_base + ctx->data->vio_sta_offset;
> +
> +       for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->data->vio_idx_num) - 1; i++)
> +               writel(GENMASK(31, 0), reg + 4 * i);
> +
> +       writel(GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num) - 1, 0),
> +              reg + 4 * i);

Is it guaranteed that vio_idx_num will always not a multiple of 32, or
should we check that VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num) is not
zero?

> +}
> +
> +static void mask_module_irq(struct mtk_devapc_context *ctx, bool mask)
> +{
> +       void __iomem *reg;
> +       u32 val;
> +       int i;
> +
> +       reg = ctx->infra_base + ctx->data->vio_mask_offset;
> +
> +       if (mask)
> +               val = GENMASK(31, 0);
> +       else
> +               val = 0;
> +
> +       for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->data->vio_idx_num) - 1; i++)
> +               writel(val, reg + 4 * i);
> +
> +       val = readl(reg + 4 * i);
> +       if (mask)
> +               val |= GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num) - 1,
> +                              0);
> +       else
> +               val &= ~GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num) - 1,
> +                               0);

Same here.

> +
> +       writel(val, reg + 4 * i);
> +}
> +
> +#define PHY_DEVAPC_TIMEOUT     0x10000
> +
> +/*
> + * devapc_sync_vio_dbg - do "shift" mechansim" to get full violation information.

nit: One extra double quote in the comment.

> + *                       shift mechanism is depends on devapc hardware design.
> + *                       Mediatek devapc set multiple slaves as a group.
> + *                       When violation is triggered, violation info is kept
> + *                       inside devapc hardware.
> + *                       Driver should do shift mechansim to sync full violation
> + *                       info to VIO_DBGs registers.
> + *
> + */
> +static int devapc_sync_vio_dbg(struct mtk_devapc_context *ctx)
>
> ...
>
> +static int mtk_devapc_probe(struct platform_device *pdev)
> +{
> +       struct device_node *node = pdev->dev.of_node;
> +       struct mtk_devapc_context *ctx;
> +       u32 devapc_irq;
> +       int ret;
> +
> +       if (IS_ERR(node))

Does this ever happens? I feel the check should be `if (node == NULL)`.

> +               return -ENODEV;
> +
> +       ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
> +       if (!ctx)
> +               return -ENOMEM;
> +
> +       ctx->data = of_device_get_match_data(&pdev->dev);
> +       ctx->dev = &pdev->dev;
> +
> +       ctx->infra_base = of_iomap(node, 0);
> +       if (!ctx->infra_base)
> +               return -EINVAL;

Missing `iounmap(ctx->infra_base)` in the following error paths and
mtk_devapc_remove. Use devm_of_iomap instead?

> +
> +       devapc_irq = irq_of_parse_and_map(node, 0);
> +       if (!devapc_irq)
> +               return -EINVAL;
> +
> +       ctx->infra_clk = devm_clk_get(&pdev->dev, "devapc-infra-clock");
> +       if (IS_ERR(ctx->infra_clk))
> +               return -EINVAL;
> +
> +       if (clk_prepare_enable(ctx->infra_clk))
> +               return -EINVAL;
> +
> +       ret = devm_request_irq(&pdev->dev, devapc_irq, devapc_violation_irq,
> +                              IRQF_TRIGGER_NONE, "devapc", ctx);
> +       if (ret) {
> +               clk_disable_unprepare(ctx->infra_clk);
> +               return ret;
> +       }
> +
> +       platform_set_drvdata(pdev, ctx);
> +
> +       start_devapc(ctx);
> +
> +       return 0;
> +}
> +
> +static int mtk_devapc_remove(struct platform_device *pdev)
> +{
> +       struct mtk_devapc_context *ctx = platform_get_drvdata(pdev);
> +
> +       stop_devapc(ctx);
> +
> +       clk_disable_unprepare(ctx->infra_clk);
> +
> +       return 0;
> +}
> +
> +static struct platform_driver mtk_devapc_driver = {
> +       .probe = mtk_devapc_probe,
> +       .remove = mtk_devapc_remove,
> +       .driver = {
> +               .name = "mtk-devapc",
> +               .of_match_table = mtk_devapc_dt_match,
> +       },
> +};
> +
> +module_platform_driver(mtk_devapc_driver);
> +
> +MODULE_DESCRIPTION("Mediatek Device APC Driver");
> +MODULE_AUTHOR("Neal Liu <neal.liu@mediatek.com>");
> +MODULE_LICENSE("GPL");
> --
> 1.7.9.5

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

  reply	other threads:[~2021-01-14  9:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-15  3:20 Neal Liu
2020-10-15  3:20 ` [PATCH v8 1/2] dt-bindings: devapc: add bindings for mtk-devapc Neal Liu
2020-10-21 15:05   ` Rob Herring
2020-10-15  3:20 ` [PATCH v8 2/2] soc: mediatek: add mt6779 devapc driver Neal Liu
2021-01-14  9:40   ` Pi-Hsun Shih [this message]
2020-10-15  3:24 ` [PATCH v8] Add MediaTek MT6779 " Neal Liu
2020-11-02  7:24   ` Neal Liu
2020-11-27 23:31 ` Matthias Brugger

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='CANdKZ0f7=-keVzKm7y5WHUhsCqjA75aCMf=ph+BmrDuS203fVg@mail.gmail.com' \
    --to=pihsun@chromium.org \
    --cc=chunkuang.hu@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=neal.liu@mediatek.com \
    --cc=robh+dt@kernel.org \
    --cc=wsd_upstream@mediatek.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).