netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Gatien Chevallier <gatien.chevallier@foss.st.com>
Cc: <Oleksii_Moisieiev@epam.com>, <gregkh@linuxfoundation.org>,
	<herbert@gondor.apana.org.au>, <davem@davemloft.net>,
	<robh+dt@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>,
	<alexandre.torgue@foss.st.com>, <vkoul@kernel.org>,
	<olivier.moysan@foss.st.com>, <arnaud.pouliquen@foss.st.com>,
	<mchehab@kernel.org>, <fabrice.gasnier@foss.st.com>,
	<ulf.hansson@linaro.org>, <edumazet@google.com>,
	<kuba@kernel.org>, <pabeni@redhat.com>,
	<linux-crypto@vger.kernel.org>, <devicetree@vger.kernel.org>,
	<linux-stm32@st-md-mailman.stormreply.com>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <dmaengine@vger.kernel.org>,
	<linux-i2c@vger.kernel.org>, <linux-iio@vger.kernel.org>,
	<alsa-devel@alsa-project.org>, <linux-media@vger.kernel.org>,
	<linux-mmc@vger.kernel.org>, <netdev@vger.kernel.org>,
	<linux-phy@lists.infradead.org>, <linux-serial@vger.kernel.org>,
	<linux-spi@vger.kernel.org>, <linux-usb@vger.kernel.org>,
	Loic PALLARDY <loic.pallardy@st.com>
Subject: Re: [PATCH v3 4/6] bus: stm32_sys_bus: add support for STM32MP15 and STM32MP13 system bus
Date: Sat, 28 Jan 2023 16:12:17 +0000	[thread overview]
Message-ID: <20230128161217.0e79436e@jic23-huawei> (raw)
In-Reply-To: <20230127164040.1047583-5-gatien.chevallier@foss.st.com>

On Fri, 27 Jan 2023 17:40:38 +0100
Gatien Chevallier <gatien.chevallier@foss.st.com> wrote:

> This driver is checking the access rights of the different
> peripherals connected to the system bus. If access is denied,
> the associated device tree node is skipped so the platform bus
> does not probe it.
> 
> Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
> Signed-off-by: Loic PALLARDY <loic.pallardy@st.com>

Hi Gatien,

A few comments inline,

Thanks,

Jonathan

> diff --git a/drivers/bus/stm32_sys_bus.c b/drivers/bus/stm32_sys_bus.c
> new file mode 100644
> index 000000000000..c12926466bae
> --- /dev/null
> +++ b/drivers/bus/stm32_sys_bus.c
> @@ -0,0 +1,168 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2023, STMicroelectronics - All Rights Reserved
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/bits.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_device.h>
> +
> +/* ETZPC peripheral as firewall bus */
> +/* ETZPC registers */
> +#define ETZPC_DECPROT			0x10
> +
> +/* ETZPC miscellaneous */
> +#define ETZPC_PROT_MASK			GENMASK(1, 0)
> +#define ETZPC_PROT_A7NS			0x3
> +#define ETZPC_DECPROT_SHIFT		1

This define makes the code harder to read.  What we care about is
the number of bits in the register divided by number of entries.
(which is 2) hence the shift by 1. See below for more on this.


> +
> +#define IDS_PER_DECPROT_REGS		16

> +#define STM32MP15_ETZPC_ENTRIES		96
> +#define STM32MP13_ETZPC_ENTRIES		64

These defines just make the code harder to check.
They aren't magic numbers, but rather just telling us how many
entries there are, so I would just put them in the structures directly.
Their use make it clear what they are without needing to give them a name.


> +struct stm32_sys_bus_match_data {

Comment on naming of this below.

> +	unsigned int max_entries;
> +};
> +

+static int stm32_etzpc_get_access(struct sys_bus_data *pdata, struct device_node *np)
+{
+	int err;
+	u32 offset, reg_offset, sec_val, id;
+
+	err = stm32_sys_bus_get_periph_id(pdata, np, &id);
+	if (err)
+		return err;
+
+	/* Check access configuration, 16 peripherals per register */
+	reg_offset = ETZPC_DECPROT + 0x4 * (id / IDS_PER_DECPROT_REGS);
+	offset = (id % IDS_PER_DECPROT_REGS) << ETZPC_DECPROT_SHIFT;

Use of defines in here is actively unhelpful when it comes to review. I would suggest letting
the maths be self explanatory (even if it's more code).

	offset = (id % IDS_PER_DECPROT_REGS) * (sizeof(u32) * BITS_PER_BYTE / IDS_PER_DECPROT_REGS);

Or if you prefer have a define of

#define DECPROT_BITS_PER_ID (sizeof(u32) * BITS_PER_BYTE / IDS_PER_DECPROT_REGS)

and
	offset = (id % IDS_PER_DECPROT_REGS) * DECPROT_BITS_PER_ID;

+
+	/* Verify peripheral is non-secure and attributed to cortex A7 */
+	sec_val = (readl(pdata->sys_bus_base + reg_offset) >> offset) & ETZPC_PROT_MASK;
+	if (sec_val != ETZPC_PROT_A7NS) {
+		dev_dbg(pdata->dev, "Invalid bus configuration: reg_offset %#x, value %d\n",
+			reg_offset, sec_val);
+		return -EACCES;
+	}
+
+	return 0;
+}
+
...

> +static int stm32_sys_bus_probe(struct platform_device *pdev)
> +{
> +	struct sys_bus_data *pdata;
> +	void __iomem *mmio;
> +	struct device_node *np = pdev->dev.of_node;

I'd be consistent. You use dev_of_node() accessor elsewhere, so should
use it here as well.

> +
> +	pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
> +	if (!pdata)
> +		return -ENOMEM;
> +
> +	mmio = devm_platform_ioremap_resource(pdev, 0);
> +	if (IS_ERR(mmio))
> +		return PTR_ERR(mmio);
> +
> +	pdata->sys_bus_base = mmio;
> +	pdata->pconf = of_device_get_match_data(&pdev->dev);
> +	pdata->dev = &pdev->dev;
> +
> +	platform_set_drvdata(pdev, pdata);

Does this get used? I can't immediately spot where but maybe I just
missed it.

> +
> +	stm32_sys_bus_populate(pdata);
> +
> +	/* Populate all available nodes */
> +	return of_platform_populate(np, NULL, NULL, &pdev->dev);

As np only used here, I'd not bother with the local variable in this function.

> +}
> +
> +static const struct stm32_sys_bus_match_data stm32mp15_sys_bus_data = {

Naming a structure after where it comes from is a little unusual and
confusion when a given call gets it from somewhere else.

I'd expect it to be named after what sort of thing it contains.
stm32_sys_bus_info or something like that.

> +	.max_entries = STM32MP15_ETZPC_ENTRIES,
> +};
> +
> +static const struct stm32_sys_bus_match_data stm32mp13_sys_bus_data = {
> +	.max_entries = STM32MP13_ETZPC_ENTRIES,
> +};
> +
> +static const struct of_device_id stm32_sys_bus_of_match[] = {
> +	{ .compatible = "st,stm32mp15-sys-bus", .data = &stm32mp15_sys_bus_data },
> +	{ .compatible = "st,stm32mp13-sys-bus", .data = &stm32mp13_sys_bus_data },

Alphabetical order usually preferred when there isn't a strong reason for
another choice.

> +	{}
> +};
> +MODULE_DEVICE_TABLE(of, stm32_sys_bus_of_match);
> +
> +static struct platform_driver stm32_sys_bus_driver = {
> +	.probe  = stm32_sys_bus_probe,
> +	.driver = {
> +		.name = "stm32-sys-bus",
> +		.of_match_table = stm32_sys_bus_of_match,
> +	},
> +};
> +
> +static int __init stm32_sys_bus_init(void)
> +{
> +	return platform_driver_register(&stm32_sys_bus_driver);
> +}
> +arch_initcall(stm32_sys_bus_init);
> +

Unwanted trailing blank line.



  reply	other threads:[~2023-01-28 15:58 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-27 16:40 [PATCH v3 0/6] Introduce STM32 system bus Gatien Chevallier
2023-01-27 16:40 ` [PATCH v3 1/6] dt-bindings: Document common device controller bindings Gatien Chevallier
2023-01-27 16:49   ` Krzysztof Kozlowski
2023-01-27 17:00     ` Gatien CHEVALLIER
2023-01-27 16:40 ` [PATCH v3 2/6] dt-bindings: treewide: add feature-domains description in binding files Gatien Chevallier
2023-01-28 15:46   ` Jonathan Cameron
2023-02-03 20:57   ` Rob Herring
2023-01-27 16:40 ` [PATCH v3 3/6] dt-bindings: bus: add STM32 System Bus Gatien Chevallier
2023-01-28 15:48   ` Jonathan Cameron
2023-02-07 13:31     ` Gatien CHEVALLIER
2023-01-27 16:40 ` [PATCH v3 4/6] bus: stm32_sys_bus: add support for STM32MP15 and STM32MP13 system bus Gatien Chevallier
2023-01-28 16:12   ` Jonathan Cameron [this message]
2023-02-07 14:12     ` Gatien CHEVALLIER
2023-02-08 19:08       ` Jonathan Cameron
2023-01-27 16:40 ` [PATCH v3 5/6] ARM: dts: stm32: add ETZPC as a system bus for STM32MP15x boards Gatien Chevallier
2023-02-09  7:51   ` Uwe Kleine-König
2023-01-27 16:40 ` [PATCH v3 6/6] ARM: dts: stm32: add ETZPC as a system bus for STM32MP13x boards Gatien Chevallier
2023-02-09  7:46   ` [Linux-stm32] " Ahmad Fatoum
2023-02-09  8:10     ` Ahmad Fatoum
2023-02-13 10:54       ` Gatien CHEVALLIER
2023-02-13 11:27         ` Ahmad Fatoum
2023-02-27 11:26           ` Gatien CHEVALLIER
2023-04-21 10:19             ` Oleksii Moisieiev
2023-04-25  7:56               ` Gatien CHEVALLIER
2023-07-05 17:35 ` [PATCH v3 0/6] Introduce STM32 system bus Gatien CHEVALLIER

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=20230128161217.0e79436e@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=Oleksii_Moisieiev@epam.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=arnaud.pouliquen@foss.st.com \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=fabrice.gasnier@foss.st.com \
    --cc=gatien.chevallier@foss.st.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=loic.pallardy@st.com \
    --cc=mchehab@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olivier.moysan@foss.st.com \
    --cc=pabeni@redhat.com \
    --cc=robh+dt@kernel.org \
    --cc=ulf.hansson@linaro.org \
    --cc=vkoul@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 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).