All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
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, jic23@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,
	kernel@pengutronix.de
Subject: Re: [PATCH v3 5/6] ARM: dts: stm32: add ETZPC as a system bus for STM32MP15x boards
Date: Thu, 9 Feb 2023 08:51:44 +0100	[thread overview]
Message-ID: <20230209075144.cuw3xsxa6qgbttgq@pengutronix.de> (raw)
In-Reply-To: <20230127164040.1047583-6-gatien.chevallier@foss.st.com>

[-- Attachment #1: Type: text/plain, Size: 1607 bytes --]

Hello,

On Fri, Jan 27, 2023 at 05:40:39PM +0100, Gatien Chevallier wrote:
> The STM32 System Bus is an internal bus on which devices are connected.
> ETZPC is a peripheral overseeing the firewall bus that configures
> and control access to the peripherals connected on it.
> 
> For more information on which peripheral is securable, please read
> the STM32MP15 reference manual.

it might be naive, but I somehow expected that when showing at the
resulting commit with git show -b that the patch gets quite small.

Is it really intended that &etzpc (which has reg = <0x5c007000 0x400>;)
is the parent bus of the devices with feature-domains = <&etzpc XX>; even
though their addresses are out of &etzpc's range? Doesn't a bus usually
have a ranges property and a base address that matches its contained
devices?

Looking at imx6qdl.dtsi there is:

	aips1: bus@2000000 { /* AIPS1 */
		...
		reg = <0x02000000 0x100000>;
		ranges;

		spba-bus@2000000 {
			...
			reg = <0x02000000 0x40000>;
			...
		};

		...

		sdma: dma-controller@20ec000 {
			...
			reg = <0x020ec000 0x4000>;
			...
		};
	};

and the registers configuring the aips1 bus are (I think) in

                        aipstz@207c000 { /* AIPSTZ1 */
                                reg = <0x0207c000 0x4000>;
                        };

Maybe this change could be made less intrusive by using a similar setup
here?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
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, jic23@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,
	kernel@pengutronix.de
Subject: Re: [PATCH v3 5/6] ARM: dts: stm32: add ETZPC as a system bus for STM32MP15x boards
Date: Thu, 9 Feb 2023 08:51:44 +0100	[thread overview]
Message-ID: <20230209075144.cuw3xsxa6qgbttgq@pengutronix.de> (raw)
In-Reply-To: <20230127164040.1047583-6-gatien.chevallier@foss.st.com>


[-- Attachment #1.1: Type: text/plain, Size: 1607 bytes --]

Hello,

On Fri, Jan 27, 2023 at 05:40:39PM +0100, Gatien Chevallier wrote:
> The STM32 System Bus is an internal bus on which devices are connected.
> ETZPC is a peripheral overseeing the firewall bus that configures
> and control access to the peripherals connected on it.
> 
> For more information on which peripheral is securable, please read
> the STM32MP15 reference manual.

it might be naive, but I somehow expected that when showing at the
resulting commit with git show -b that the patch gets quite small.

Is it really intended that &etzpc (which has reg = <0x5c007000 0x400>;)
is the parent bus of the devices with feature-domains = <&etzpc XX>; even
though their addresses are out of &etzpc's range? Doesn't a bus usually
have a ranges property and a base address that matches its contained
devices?

Looking at imx6qdl.dtsi there is:

	aips1: bus@2000000 { /* AIPS1 */
		...
		reg = <0x02000000 0x100000>;
		ranges;

		spba-bus@2000000 {
			...
			reg = <0x02000000 0x40000>;
			...
		};

		...

		sdma: dma-controller@20ec000 {
			...
			reg = <0x020ec000 0x4000>;
			...
		};
	};

and the registers configuring the aips1 bus are (I think) in

                        aipstz@207c000 { /* AIPSTZ1 */
                                reg = <0x0207c000 0x4000>;
                        };

Maybe this change could be made less intrusive by using a similar setup
here?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 112 bytes --]

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

WARNING: multiple messages have this Message-ID (diff)
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
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, jic23@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,
	kernel@pengutronix.de
Subject: Re: [PATCH v3 5/6] ARM: dts: stm32: add ETZPC as a system bus for STM32MP15x boards
Date: Thu, 9 Feb 2023 08:51:44 +0100	[thread overview]
Message-ID: <20230209075144.cuw3xsxa6qgbttgq@pengutronix.de> (raw)
In-Reply-To: <20230127164040.1047583-6-gatien.chevallier@foss.st.com>


[-- Attachment #1.1: Type: text/plain, Size: 1607 bytes --]

Hello,

On Fri, Jan 27, 2023 at 05:40:39PM +0100, Gatien Chevallier wrote:
> The STM32 System Bus is an internal bus on which devices are connected.
> ETZPC is a peripheral overseeing the firewall bus that configures
> and control access to the peripherals connected on it.
> 
> For more information on which peripheral is securable, please read
> the STM32MP15 reference manual.

it might be naive, but I somehow expected that when showing at the
resulting commit with git show -b that the patch gets quite small.

Is it really intended that &etzpc (which has reg = <0x5c007000 0x400>;)
is the parent bus of the devices with feature-domains = <&etzpc XX>; even
though their addresses are out of &etzpc's range? Doesn't a bus usually
have a ranges property and a base address that matches its contained
devices?

Looking at imx6qdl.dtsi there is:

	aips1: bus@2000000 { /* AIPS1 */
		...
		reg = <0x02000000 0x100000>;
		ranges;

		spba-bus@2000000 {
			...
			reg = <0x02000000 0x40000>;
			...
		};

		...

		sdma: dma-controller@20ec000 {
			...
			reg = <0x020ec000 0x4000>;
			...
		};
	};

and the registers configuring the aips1 bus are (I think) in

                        aipstz@207c000 { /* AIPSTZ1 */
                                reg = <0x0207c000 0x4000>;
                        };

Maybe this change could be made less intrusive by using a similar setup
here?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

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

  reply	other threads:[~2023-02-09  7:52 UTC|newest]

Thread overview: 93+ 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 ` Gatien Chevallier
2023-01-27 16:40 ` Gatien Chevallier
2023-01-27 16:40 ` Gatien Chevallier
2023-01-27 16:40 ` [PATCH v3 1/6] dt-bindings: Document common device controller bindings Gatien Chevallier
2023-01-27 16:40   ` Gatien Chevallier
2023-01-27 16:40   ` Gatien Chevallier
2023-01-27 16:40   ` Gatien Chevallier
2023-01-27 16:49   ` Krzysztof Kozlowski
2023-01-27 16:49     ` Krzysztof Kozlowski
2023-01-27 16:49     ` Krzysztof Kozlowski
2023-01-27 16:49     ` Krzysztof Kozlowski
2023-01-27 17:00     ` Gatien CHEVALLIER
2023-01-27 17:00       ` Gatien CHEVALLIER
2023-01-27 17:00       ` Gatien CHEVALLIER
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-27 16:40   ` Gatien Chevallier
2023-01-27 16:40   ` Gatien Chevallier
2023-01-27 16:40   ` Gatien Chevallier
2023-01-28 15:46   ` Jonathan Cameron
2023-01-28 15:46     ` Jonathan Cameron
2023-01-28 15:46     ` Jonathan Cameron
2023-01-28 15:46     ` Jonathan Cameron
2023-02-03 20:57   ` Rob Herring
2023-02-03 20:57     ` Rob Herring
2023-02-03 20:57     ` Rob Herring
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-27 16:40   ` Gatien Chevallier
2023-01-27 16:40   ` Gatien Chevallier
2023-01-27 16:40   ` Gatien Chevallier
2023-01-28 15:48   ` Jonathan Cameron
2023-01-28 15:48     ` Jonathan Cameron
2023-01-28 15:48     ` Jonathan Cameron
2023-01-28 15:48     ` Jonathan Cameron
2023-02-07 13:31     ` Gatien CHEVALLIER
2023-02-07 13:31       ` Gatien CHEVALLIER
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-27 16:40   ` Gatien Chevallier
2023-01-27 16:40   ` Gatien Chevallier
2023-01-27 16:40   ` Gatien Chevallier
2023-01-28 16:12   ` Jonathan Cameron
2023-01-28 16:12     ` Jonathan Cameron
2023-01-28 16:12     ` Jonathan Cameron
2023-01-28 16:12     ` Jonathan Cameron
2023-02-07 14:12     ` Gatien CHEVALLIER
2023-02-07 14:12       ` Gatien CHEVALLIER
2023-02-07 14:12       ` Gatien CHEVALLIER
2023-02-07 14:12       ` Gatien CHEVALLIER
2023-02-08 19:08       ` Jonathan Cameron
2023-02-08 19:08         ` Jonathan Cameron
2023-02-08 19:08         ` Jonathan Cameron
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-01-27 16:40   ` Gatien Chevallier
2023-01-27 16:40   ` Gatien Chevallier
2023-01-27 16:40   ` Gatien Chevallier
2023-02-09  7:51   ` Uwe Kleine-König [this message]
2023-02-09  7:51     ` Uwe Kleine-König
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-01-27 16:40   ` Gatien Chevallier
2023-01-27 16:40   ` Gatien Chevallier
2023-01-27 16:40   ` Gatien Chevallier
2023-02-09  7:46   ` [Linux-stm32] " Ahmad Fatoum
2023-02-09  7:46     ` Ahmad Fatoum
2023-02-09  7:46     ` Ahmad Fatoum
2023-02-09  8:10     ` Ahmad Fatoum
2023-02-09  8:10       ` Ahmad Fatoum
2023-02-09  8:10       ` Ahmad Fatoum
2023-02-13 10:54       ` Gatien CHEVALLIER
2023-02-13 10:54         ` Gatien CHEVALLIER
2023-02-13 10:54         ` Gatien CHEVALLIER
2023-02-13 10:54         ` Gatien CHEVALLIER
2023-02-13 11:27         ` Ahmad Fatoum
2023-02-13 11:27           ` Ahmad Fatoum
2023-02-13 11:27           ` Ahmad Fatoum
2023-02-27 11:26           ` Gatien CHEVALLIER
2023-02-27 11:26             ` Gatien CHEVALLIER
2023-02-27 11:26             ` Gatien CHEVALLIER
2023-02-27 11:26             ` Gatien CHEVALLIER
2023-04-21 10:19             ` Oleksii Moisieiev via Alsa-devel
2023-04-21 10:19             ` Oleksii Moisieiev
2023-04-21 10:19               ` Oleksii Moisieiev
2023-04-21 10:19               ` Oleksii Moisieiev
2023-04-25  7:56               ` Gatien CHEVALLIER
2023-04-25  7:56                 ` Gatien CHEVALLIER
2023-04-25  7:56                 ` Gatien CHEVALLIER
2023-07-05 17:35 ` [PATCH v3 0/6] Introduce STM32 system bus Gatien CHEVALLIER
2023-07-05 17:35   ` Gatien CHEVALLIER
2023-07-05 17:35   ` 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=20230209075144.cuw3xsxa6qgbttgq@pengutronix.de \
    --to=u.kleine-koenig@pengutronix.de \
    --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=jic23@kernel.org \
    --cc=kernel@pengutronix.de \
    --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=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 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.