* Re: [PATCH 2/2] ARM: dts: qcom: msm8974: Use proper compatible for APCS syscon
From: Krzysztof Kozlowski @ 2024-04-09 12:21 UTC (permalink / raw)
To: Luca Weiss, ~postmarketos/upstreaming, phone-devel, Jassi Brar,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Matthias Brugger, AngeloGioacchino Del Regno,
Jacky Huang, Shan-Chun Hung
Cc: linux-arm-msm, linux-kernel, devicetree, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20240408-msm8974-apcs-v1-2-90cb7368836e@z3ntu.xyz>
On 08/04/2024 21:32, Luca Weiss wrote:
> Use the apcs-kpss-global compatible for the APCS global mailbox block
> found on this SoC.
>
> This also resolves a dt-binding checker warning:
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] riscv: dts: sophgo: add initial Milk-V Duo S board device tree
From: Inochi Amaoto @ 2024-04-09 12:27 UTC (permalink / raw)
To: Conor Dooley, Inochi Amaoto
Cc: michael.opdenacker, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen Wang, Paul Walmsley, Palmer Dabbelt, Albert Ou,
devicetree, linux-riscv, linux-kernel
In-Reply-To: <20240409-prevent-deepness-2d22bf009b16@spud>
On Tue, Apr 09, 2024 at 01:13:32PM +0100, Conor Dooley wrote:
> On Tue, Apr 09, 2024 at 03:17:35PM +0800, Inochi Amaoto wrote:
> > On Tue, Apr 09, 2024 at 08:45:04AM +0200, michael.opdenacker@bootlin.com wrote:
> > > From: Michael Opdenacker <michael.opdenacker@bootlin.com>
> > >
> > > This adds initial support for the Milk-V Duo S board
> > > (https://milkv.io/duo-s), enabling the serial port and
> > > read-only SD card support, allowing to boot Linux to the
> > > command line.
> > >
> >
> > Hi Michael,
> >
> > I think your patch losts the board binding and have wrong compatiable.
> > Also, the SD can have rw support with proper property. See link [1]
> > (need 'disable-wp').
>
> [1] doesn't go anywhere useful.
>
This is my fault, I copied the wrong url. The right patch is
https://lore.kernel.org/r/20240217144826.3944-1-jszhang@kernel.org.
> > I suggest you resubmitting this patch after applying clk patchs.
> > This could reduce some unnecessary change. For now, you can just
> > use the dts for huashan-pi (with changed memory size).
>
> Why would using patched huashan-pi dts be more suitable than carrying
> a local patch for duo-s devicetree? What am I missing?
>
> Cheers,
> Conor.
>
> >
> > [1]: https://lore.kernel.org/linux-riscv/IA1PR20MB4953B158F6F575840F3D4267BB7D2@IA1PR20MB4953.namprd20.prod.outlook.com/
I think you miss nothing. Using huashan-pi dts as a temporary
solution is just because they are both CV181X series. Since
only a few peripherals are supported, it is also OK to use duo
dts with local change. They're not significantly different.
This is also the reason I did not prepare any patch for the
new board. (such as lichee RV NANO, duo 256).
^ permalink raw reply
* Re: [PATCH] riscv: dts: sophgo: add initial Milk-V Duo S board device tree
From: Inochi Amaoto @ 2024-04-09 12:30 UTC (permalink / raw)
To: michael.opdenacker, Inochi Amaoto
Cc: Conor Dooley, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen Wang, Paul Walmsley, Palmer Dabbelt, Albert Ou, devicetree,
linux-riscv, linux-kernel
In-Reply-To: <IA1PR20MB49534E00CAE29D24F7D7E718BB072@IA1PR20MB4953.namprd20.prod.outlook.com>
On Tue, Apr 09, 2024 at 08:27:59PM +0800, Inochi Amaoto wrote:
> On Tue, Apr 09, 2024 at 01:13:32PM +0100, Conor Dooley wrote:
> > On Tue, Apr 09, 2024 at 03:17:35PM +0800, Inochi Amaoto wrote:
> > > On Tue, Apr 09, 2024 at 08:45:04AM +0200, michael.opdenacker@bootlin.com wrote:
> > > > From: Michael Opdenacker <michael.opdenacker@bootlin.com>
> > > >
> > > > This adds initial support for the Milk-V Duo S board
> > > > (https://milkv.io/duo-s), enabling the serial port and
> > > > read-only SD card support, allowing to boot Linux to the
> > > > command line.
> > > >
> > >
> > > Hi Michael,
> > >
> > > I think your patch losts the board binding and have wrong compatiable.
> > > Also, the SD can have rw support with proper property. See link [1]
> > > (need 'disable-wp').
> >
> > [1] doesn't go anywhere useful.
> >
>
> This is my fault, I copied the wrong url. The right patch is
> https://lore.kernel.org/r/20240217144826.3944-1-jszhang@kernel.org.
>
FYI, Michael. This is the right url for sdhci dts. The previous
is wrong.
> > > I suggest you resubmitting this patch after applying clk patchs.
> > > This could reduce some unnecessary change. For now, you can just
> > > use the dts for huashan-pi (with changed memory size).
> >
> > Why would using patched huashan-pi dts be more suitable than carrying
> > a local patch for duo-s devicetree? What am I missing?
> >
> > Cheers,
> > Conor.
> >
> > >
> > > [1]: https://lore.kernel.org/linux-riscv/IA1PR20MB4953B158F6F575840F3D4267BB7D2@IA1PR20MB4953.namprd20.prod.outlook.com/
>
> I think you miss nothing. Using huashan-pi dts as a temporary
> solution is just because they are both CV181X series. Since
> only a few peripherals are supported, it is also OK to use duo
> dts with local change. They're not significantly different.
> This is also the reason I did not prepare any patch for the
> new board. (such as lichee RV NANO, duo 256).
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: power: supply: ltc3350-charger: Add bindings
From: Mike Looijmans @ 2024-04-09 12:34 UTC (permalink / raw)
To: Krzysztof Kozlowski, linux-pm
Cc: Conor Dooley, Krzysztof Kozlowski, Rob Herring, Sebastian Reichel,
devicetree, linux-kernel
In-Reply-To: <a4a9f949-ecc7-4603-8c8b-90a1e309570a@linaro.org>
Thanks for your feedback. Will fix them all, except see below.
I'll send a v2
On 09-04-2024 10:27, Krzysztof Kozlowski wrote:
...
>> +
>> + lltc,rsnsc-micro-ohms:
>> + description: Capacitor charger sense resistor in microohm.
>> + minimum: 1000
>> +
>> + lltc,rsnsi-micro-ohms:
>> + description: Input current sense resistor in microohm.
>> + minimum: 1000
> Looks like it is shunt-resistor-micro-ohms. Unless it is something
> different?
It's a shunt, but different and there's two of them (akin to the
ltc4162-l which has the same property with the same meaning). One to
measure input, one to measure charge current.
When the datasheet talks about "shunt" it means the resistor that can be
used to balance or discharge the caps. So I'd rather avoid the word
completely so users aren't tempted to put the wrong resistor value there.
The datasheet uses "rsnsi" and "rsnsc" whenever referring to these
resistors.
...
--
Mike Looijmans
System Expert
TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands
T: +31 (0) 499 33 69 69
E: mike.looijmans@topic.nl
W: www.topic.nl
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: power: supply: ltc3350-charger: Add bindings
From: Mike Looijmans @ 2024-04-09 12:35 UTC (permalink / raw)
To: linux-pm
Cc: Mike Looijmans, Conor Dooley, Krzysztof Kozlowski, Rob Herring,
Sebastian Reichel, devicetree, linux-kernel
In-Reply-To: <1b153bce-a66a-45ee-a5c6-963ea6fb1c82.949ef384-8293-46b8-903f-40a477c056ae.67250ca5-6a79-4048-b845-3d240ff83a75@emailsignatures365.codetwo.com>
The LTC3350 is a backup power controller that can charge and monitor
a series stack of one to four supercapacitors.
Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
---
Changes in v2:
Rename to lltc,ltc3350.yaml
Fix spaces and indentation
.../bindings/power/supply/lltc,ltc3350.yaml | 54 +++++++++++++++++++
1 file changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/supply/lltc,ltc3350.yaml
diff --git a/Documentation/devicetree/bindings/power/supply/lltc,ltc3350.yaml b/Documentation/devicetree/bindings/power/supply/lltc,ltc3350.yaml
new file mode 100644
index 000000000000..c8e36523c689
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/lltc,ltc3350.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (C) 2024 Topic Embedded Products
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/ltc3350.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Linear Technology (Analog Devices) LTC3350 Supercap Charger
+
+maintainers:
+ - Mike Looijmans <mike.looijmans@topic.nl>
+
+description: |
+ The LTC3350 is a High Current Supercapacitor Backup Controller and System
+ Monitor.
+ Specifications about the charger can be found at:
+ https://www.analog.com/en/products/ltc3350.html
+
+properties:
+ compatible:
+ enum:
+ - lltc,ltc3350
+
+ reg:
+ maxItems: 1
+
+ lltc,rsnsc-micro-ohms:
+ description: Capacitor charger sense resistor in microohm.
+ minimum: 1000
+
+ lltc,rsnsi-micro-ohms:
+ description: Input current sense resistor in microohm.
+ minimum: 1000
+
+required:
+ - compatible
+ - reg
+ - lltc,rsnsc-micro-ohms
+ - lltc,rsnsi-micro-ohms
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ charger: battery-charger@9 {
+ compatible = "lltc,ltc3350";
+ reg = <0x9>;
+ lltc,rsnsc-micro-ohms = <10000>;
+ lltc,rsnsi-micro-ohms = <10000>;
+ };
+ };
--
2.34.1
Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands
T: +31 (0) 499 33 69 69
E: mike.looijmans@topic.nl
W: www.topic.nl
Please consider the environment before printing this e-mail
^ permalink raw reply related
* Re: [PATCH v2 3/6] firmware: arm_scmi: add initial support for i.MX BBM protocol
From: Sudeep Holla @ 2024-04-09 12:52 UTC (permalink / raw)
To: Peng Fan
Cc: Peng Fan (OSS), Cristian Marussi, Sudeep Holla, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <AS1PR04MB9431F99D49D6A777B09814FB88072@AS1PR04MB9431.eurprd04.prod.outlook.com>
On Tue, Apr 09, 2024 at 11:19:31AM +0000, Peng Fan wrote:
>
> ok, will add more comment in the patch for the commands.
>
No I meant add document/description similar to SCMI spec for each of these
commands. Not just one line comment. For std protocols, we can refer spec,
for these vendor protocols, just one like comment will not suffice. Describe
in more details and hence the request for separate TXT file for that.
Hope that is clear now, I have mentioned it several times already.
--
Regards,
Sudeep
^ permalink raw reply
* RE: [PATCH v2 3/6] firmware: arm_scmi: add initial support for i.MX BBM protocol
From: Peng Fan @ 2024-04-09 13:01 UTC (permalink / raw)
To: Sudeep Holla
Cc: Peng Fan (OSS), Cristian Marussi, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <ZhU6C2Ovh7xxeREP@bogus>
> Subject: Re: [PATCH v2 3/6] firmware: arm_scmi: add initial support for i.MX
> BBM protocol
>
> On Tue, Apr 09, 2024 at 11:19:31AM +0000, Peng Fan wrote:
> >
> > ok, will add more comment in the patch for the commands.
> >
>
> No I meant add document/description similar to SCMI spec for each of these
> commands. Not just one line comment. For std protocols, we can refer spec,
> for these vendor protocols, just one like comment will not suffice. Describe in
> more details and hence the request for separate TXT file for that.
> Hope that is clear now, I have mentioned it several times already.
I see, will try to work with our firmware developers to write the details.
Thanks,
Peng.
>
> --
> Regards,
> Sudeep
^ permalink raw reply
* Re: [RFC PATCH v2 0/2] fw_devlink overlay fix
From: Herve Codina @ 2024-04-09 13:02 UTC (permalink / raw)
To: Saravana Kannan
Cc: Geert Uytterhoeven, Rob Herring, kernel-team, linux-kernel, imx,
linux-arm-kernel, linux-i2c, devicetree, linux-spi, linux-acpi,
Luca Ceresoli, Thomas Petazzoni
In-Reply-To: <20240409053704.428336-1-saravanak@google.com>
Hi Saravana,
+CC Luca and Thomas
On Mon, 8 Apr 2024 22:37:01 -0700
Saravana Kannan <saravanak@google.com> wrote:
> Don't bother reviewing this patch. It needs to be tested and possibly
> refactored first.
>
> Geert and Herve,
>
> This patch serious should hopefully fix both of your use cases
> [1][2][3]. Can you please check to make sure the device links created
> to/from the overlay devices are to/from the right ones?
>
> I've only compile tested it. If I made some obvious mistake, feel free
> to fix it and give it a shot.
>
> Cc: Rob Herring <robh@kernel.org>
>
> [1] - https://lore.kernel.org/lkml/CAMuHMdXEnSD4rRJ-o90x4OprUacN_rJgyo8x6=9F9rZ+-KzjOg@mail.gmail.com/
> [2] - https://lore.kernel.org/all/20240221095137.616d2aaa@bootlin.com/
> [3] - https://lore.kernel.org/lkml/20240312151835.29ef62a0@bootlin.com/
>
I tested your patches.
Concerning my use cases, they fix the issue described in
https://lore.kernel.org/all/20240221095137.616d2aaa@bootlin.com/
But not the one described in
https://lore.kernel.org/lkml/20240312151835.29ef62a0@bootlin.com/
A link is still present between the i2c@600 and the PCI device.
instead of the i2c@600 and the pci-ep-bus.
Adding the patch clearing the FWNODE_FLAG_NOT_DEVICE in device_add() available
at [1] on top of your patches fixes the link issue.
With this additional patch applied, the link is present between the i2c@600
and the pci-ep-bus.
[1] https://lore.kernel.org/lkml/20240220111044.133776-2-herve.codina@bootlin.com/
Best regards,
Hervé
^ permalink raw reply
* Re: [PATCH] riscv: dts: sophgo: add initial Milk-V Duo S board device tree
From: Michael Opdenacker @ 2024-04-09 13:08 UTC (permalink / raw)
To: Inochi Amaoto, Conor Dooley
Cc: michael.opdenacker, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen Wang, Paul Walmsley, Palmer Dabbelt, Albert Ou,
devicetree, linux-riscv, linux-kernel
In-Reply-To: <IA1PR20MB49534E00CAE29D24F7D7E718BB072@IA1PR20MB4953.namprd20.prod.outlook.com>
Hi Inochi
On 4/9/24 at 14:27, Inochi Amaoto wrote:
> On Tue, Apr 09, 2024 at 01:13:32PM +0100, Conor Dooley wrote:
>> On Tue, Apr 09, 2024 at 03:17:35PM +0800, Inochi Amaoto wrote:
>>> On Tue, Apr 09, 2024 at 08:45:04AM +0200, michael.opdenacker@bootlin.com wrote:
>>>> From: Michael Opdenacker <michael.opdenacker@bootlin.com>
>>>>
>>>> This adds initial support for the Milk-V Duo S board
>>>> (https://milkv.io/duo-s), enabling the serial port and
>>>> read-only SD card support, allowing to boot Linux to the
>>>> command line.
>>>>
>>> Hi Michael,
>>>
>>> I think your patch losts the board binding and have wrong compatiable.
>>> Also, the SD can have rw support with proper property. See link [1]
>>> (need 'disable-wp').
>> [1] doesn't go anywhere useful.
>>
> This is my fault, I copied the wrong url. The right patch is
> https://lore.kernel.org/r/20240217144826.3944-1-jszhang@kernel.org.
No problem, I found out.
I confirm that using the "disable-wp;" property does the trick to make
the MMC writable.
However, it wasn't mentioned in the above URL...
By the way, do I really need those under &sdhci0?
+ bus-width = <4>; + no-1-8-v; + no-mmc; + no-sdio;
My board looks happy so far without them ;-)
Thanks again for your help
Cheers
Michael.
--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: power: supply: ltc3350-charger: Add bindings
From: Krzysztof Kozlowski @ 2024-04-09 13:10 UTC (permalink / raw)
To: Mike Looijmans, linux-pm
Cc: Conor Dooley, Krzysztof Kozlowski, Rob Herring, Sebastian Reichel,
devicetree, linux-kernel
In-Reply-To: <20240409123556.34299-1-mike.looijmans@topic.nl>
On 09/04/2024 14:35, Mike Looijmans wrote:
> The LTC3350 is a backup power controller that can charge and monitor
> a series stack of one to four supercapacitors.
>
> Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
>
> ---
>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
This is an automated instruction, just in case, because many review tags
are being ignored. If you know the process, you can skip it (please do
not feel offended by me posting it here - no bad intentions intended).
If you do not know the process, here is a short explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions, under or above your Signed-off-by tag. Tag is "received", when
provided in a message replied to you on the mailing list. Tools like b4
can help here. However, there's no need to repost patches *only* to add
the tags. The upstream maintainer will do that for tags received on the
version they apply.
https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L577
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RFC PATCH v2 1/2] Revert "treewide: Fix probing of devices in DT overlays"
From: Rob Herring @ 2024-04-09 13:14 UTC (permalink / raw)
To: Saravana Kannan
Cc: Herve Codina, Geert Uytterhoeven, kernel-team, linux-kernel, imx,
linux-arm-kernel, linux-i2c, devicetree, linux-spi, linux-acpi
In-Reply-To: <20240409053704.428336-2-saravanak@google.com>
On Tue, Apr 9, 2024 at 12:37 AM Saravana Kannan <saravanak@google.com> wrote:
>
> This reverts commit 1a50d9403fb90cbe4dea0ec9fd0351d2ecbd8924.
Please say *why* we are reverting. And you still need a S-o-b.
And you are missing some maintainers.
Rob
^ permalink raw reply
* Re: [PATCH v1] arm64: dts: imx8mm: fix missing pgc_vpu_* power domain parent
From: Vitor Soares @ 2024-04-09 13:22 UTC (permalink / raw)
To: Lucas Stach, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Vitor Soares, devicetree, imx, linux-arm-kernel, linux-kernel,
stable
In-Reply-To: <9ce35b9bb5a15891f6bd01bd54b7dc84b3ba4021.camel@pengutronix.de>
Hi Lucas,
Thanks for your feedback.
On Tue, 2024-04-09 at 11:13 +0200, Lucas Stach wrote:
> Hi Vitor,
>
> Am Dienstag, dem 09.04.2024 um 09:58 +0100 schrieb Vitor Soares:
> > From: Vitor Soares <vitor.soares@toradex.com>
> >
> > The pgc_vpu_* nodes miss the reference to the power domain parent,
> > leading the system to hang during the resume.
> >
> This change is not correct. The vpumix domain is controlled through
> the
> imx8mm-vpu-blk-ctrl and must not be directly triggered by the child
> domains in order to guarantee proper power sequencing.
>
> If the sequencing is incorrect for resume, it needs to be fixed in
> the
> blk-ctrl driver. I'll happily assist if you have any questions about
> this intricate mix between GPC and blk-ctrl hardware/drivers.
I'm new into the topic, so I tried to follow same approach as in imx8mp
DT. I also checked the imx8mq DT and it only have one domain for the
VPU in the GPC. It seem blk-ctrl also dependes on pgc_vpu_* to work
properly.
The blk-ctrl driver hangs on imx8m_blk_ctrl_power_on() when access the
ip registers for the soft reset. I tried to power-up the before the
soft reset, but it didn't work.
Do you have an idea how we can address this within blk-ctrl?
Best regards,
Vitor
>
> Regards,
> Lucas
>
> > As these PU domains are nested inside the vpumix domain, let's
> > reference
> > it accordingly. After this change, the suspend/resume is working.
> >
> > Cc: Lucas Stach <l.stach@pengutronix.de>
> > Cc: <stable@vger.kernel.org>
> > Closes:
> > https://lore.kernel.org/all/fccbb040330a706a4f7b34875db1d896a0bf81c8.camel@gmail.com/
> > Fixes: d39d4bb15310 ("arm64: dts: imx8mm: add GPC node")
> > Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
> > ---
> > arch/arm64/boot/dts/freescale/imx8mm.dtsi | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > index 8a1b42b94dce..97d0c6d23ad8 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > @@ -739,16 +739,19 @@ pgc_vpumix: power-domain@6 {
> > pgc_vpu_g1: power-domain@7
> > {
> > #power-domain-cells
> > = <0>;
> > reg =
> > <IMX8MM_POWER_DOMAIN_VPUG1>;
> > + power-domains =
> > <&pgc_vpumix>;
> > };
> >
> > pgc_vpu_g2: power-domain@8
> > {
> > #power-domain-cells
> > = <0>;
> > reg =
> > <IMX8MM_POWER_DOMAIN_VPUG2>;
> > + power-domains =
> > <&pgc_vpumix>;
> > };
> >
> > pgc_vpu_h1: power-domain@9
> > {
> > #power-domain-cells
> > = <0>;
> > reg =
> > <IMX8MM_POWER_DOMAIN_VPUH1>;
> > + power-domains =
> > <&pgc_vpumix>;
> > };
> >
> > pgc_dispmix:
> > power-domain@10 {
>
^ permalink raw reply
* Re: [PATCH 2/4] coresight: Add support for multiple output ports on the funnel
From: Tao Zhang @ 2024-04-09 13:22 UTC (permalink / raw)
To: Suzuki K Poulose, Mathieu Poirier, Alexander Shishkin,
Konrad Dybcio, Mike Leach, Rob Herring, Krzysztof Kozlowski
Cc: Jinlong Mao, Leo Yan, Greg Kroah-Hartman, coresight,
linux-arm-kernel, linux-kernel, devicetree, Tingwei Zhang,
Yuanfang Zhang, Trilok Soni, Song Chai, linux-arm-msm, andersson
In-Reply-To: <a8947ac4-e251-47ba-b44a-6f4fc58f1aac@arm.com>
On 4/9/2024 3:13 PM, Suzuki K Poulose wrote:
> Hi
>
> On 29/03/2024 09:27, Tao Zhang wrote:
>>
>> On 3/22/2024 12:41 AM, Suzuki K Poulose wrote:
>>> On 21/03/2024 08:32, Tao Zhang wrote:
>>>> Funnel devices are now capable of supporting multiple-inputs and
>>>> multiple-outputs configuration with in built hardware filtering
>>>> for TPDM devices. Add software support to this function. Output
>>>> port is selected according to the source in the trace path.
>>>>
>>>> The source of the input port on funnels will be marked in the
>>>> device tree.
>>>> e.g.
>>>> tpdm@xxxxxxx {
>>>> ... ... ... ...
>>>> };
>>>>
>>>> funnel_XXX: funnel@xxxxxxx {
>>>> ... ... ... ...
>>>> out-ports {
>>>> ... ... ... ...
>>>> port@x {
>>>> ... ... ... ...
>>>> label = "xxxxxxx.tpdm"; <-- To label the source
>>>> }; corresponding to the output
>>>> ... ... ... ... connection "port@x". And this
>>>> }; is a hardware static
>>>> connections.
>>>> ... ... ... ... Here needs to refer to hardware
>>>> }; design.
>>>>
>>>> Then driver will parse the source label marked in the device tree, and
>>>> save it to the coresight path. When the function needs to know the
>>>> source label, it could obtain it from coresight path parameter.
>>>> Finally,
>>>> the output port knows which source it corresponds to, and it also
>>>> knows
>>>> which input port it corresponds to.
>>>
>>> Why do we need labels ? We have connection information for all devices
>>> (both in and out), so, why do we need this label to find a device ?
>>
>> Because our funnel's design has multi-output ports, the data stream
>> will not
>>
>> know which output port should pass in building the data trace path.
>> This source
>>
>> label can make the data stream find the right output port to go.
>>
>>>
>>> And also, I thought TPDM is a source device, why does a funnel output
>>> port link to a source ?
>>
>> No, this label doesn't mean this funnel output port link to a source,
>> it just let
>>
>> the output port know its data source.
>>
>>>
>>> Are these funnels programmable ? Or, are they static ? If they are
>>> static, do these need to be described in the DT ? If they are simply
>>> acting as a "LINK" (or HWFIFO ?)
>>
>> These funnels are static, and we will add the "label" to the DT to
>> describe the
>>
>> multi-output ports for these funnels.
>
> I think there is still a bit of confusion. By "Dynamic" I mean,
> the "dynamic funnel" (explicit port enablement via MMIO) vs "static
> funnel" (no programming, always ON).
>
> So, coming to your example, do we need to "explicitly" enable trace
> flow for an "input" and/or an "output" port in your "funnel" ?
Sorry for my misunderstanding in the previous mails. Our funnels are
programmable just like the common dynamic funnels.
In our solution, we just make funnels have multiple output ports
connected to different devices or ports. When we use it, we still
enable the input port through programming. Our solution is to know which
input port the expected data comes from based on the
source label corresponding to the output port. This way we can build the
expected trace path. In other respects, it is used the same
as common dynamic funnels.
Best,
Tao
>
>
>>
>> "If they are simply acting as a "LINK" (or HWFIFO ?) " I'm not sure
>> what's the meaning
>
> i.e, Like TMC-ETF in HWFIFO mode. In this mode, the TMC-ETF is acting
> like a cache for easing ATB data load, by providing h/w buffering.
> (In your case, it may not be providing any buffering, it doesn't matter
> either way, as it is not visible to the driver).
>
> Suzuki
>
>>
>> of this. Could you describe it in detail?
>>
>>
>> Best,
>>
>> Tao
>>
>>>
>>> Suzuki
>>>
>>>>
>>>> Signed-off-by: Tao Zhang <quic_taozha@quicinc.com>
>>>> ---
>>>> drivers/hwtracing/coresight/coresight-core.c | 81
>>>> ++++++++++++++++---
>>>> .../hwtracing/coresight/coresight-platform.c | 5 ++
>>>> include/linux/coresight.h | 2 +
>>>> 3 files changed, 75 insertions(+), 13 deletions(-)
>>>>
>>>> diff --git a/drivers/hwtracing/coresight/coresight-core.c
>>>> b/drivers/hwtracing/coresight/coresight-core.c
>>>> index 5dde597403b3..b1b5e6d9ec7a 100644
>>>> --- a/drivers/hwtracing/coresight/coresight-core.c
>>>> +++ b/drivers/hwtracing/coresight/coresight-core.c
>>>> @@ -113,15 +113,63 @@ struct coresight_device
>>>> *coresight_get_percpu_sink(int cpu)
>>>> }
>>>> EXPORT_SYMBOL_GPL(coresight_get_percpu_sink);
>>>> +static struct coresight_device *coresight_get_source(struct
>>>> list_head *path)
>>>> +{
>>>> + struct coresight_device *csdev;
>>>> +
>>>> + if (!path)
>>>> + return NULL;
>>>> +
>>>> + csdev = list_first_entry(path, struct coresight_node,
>>>> link)->csdev;
>>>> + if (csdev->type != CORESIGHT_DEV_TYPE_SOURCE)
>>>> + return NULL;
>>>> +
>>>> + return csdev;
>>>> +}
>>>> +
>>>> +/**
>>>> + * coresight_source_filter - checks whether the connection matches
>>>> the source
>>>> + * of path if connection is binded to specific source.
>>>> + * @path: The list of devices
>>>> + * @conn: The connection of one outport
>>>> + *
>>>> + * Return zero if the connection doesn't have a source binded or
>>>> source of the
>>>> + * path matches the source binds to connection.
>>>> + */
>>>> +static int coresight_source_filter(struct list_head *path,
>>>> + struct coresight_connection *conn)
>>>> +{
>>>> + int ret = 0;
>>>> + struct coresight_device *source = NULL;
>>>> +
>>>> + if (conn->source_label == NULL)
>>>> + return ret;
>>>> +
>>>> + source = coresight_get_source(path);
>>>> + if (source == NULL)
>>>> + return ret;
>>>> +
>>>> + if (strstr(kobject_get_path(&source->dev.kobj, GFP_KERNEL),
>>>> + conn->source_label))
>>>> + ret = 0;
>>>> + else
>>>> + ret = -1;
>>>> +
>>>> + return ret;
>>>> +}
>>>> +
>>>> static struct coresight_connection *
>>>> coresight_find_out_connection(struct coresight_device *src_dev,
>>>> - struct coresight_device *dest_dev)
>>>> + struct coresight_device *dest_dev,
>>>> + struct list_head *path)
>>>> {
>>>> int i;
>>>> struct coresight_connection *conn;
>>>> for (i = 0; i < src_dev->pdata->nr_outconns; i++) {
>>>> conn = src_dev->pdata->out_conns[i];
>>>> + if (coresight_source_filter(path, conn))
>>>> + continue;
>>>> if (conn->dest_dev == dest_dev)
>>>> return conn;
>>>> }
>>>> @@ -312,7 +360,8 @@ static void coresight_disable_sink(struct
>>>> coresight_device *csdev)
>>>> static int coresight_enable_link(struct coresight_device *csdev,
>>>> struct coresight_device *parent,
>>>> - struct coresight_device *child)
>>>> + struct coresight_device *child,
>>>> + struct list_head *path)
>>>> {
>>>> int ret = 0;
>>>> int link_subtype;
>>>> @@ -321,8 +370,8 @@ static int coresight_enable_link(struct
>>>> coresight_device *csdev,
>>>> if (!parent || !child)
>>>> return -EINVAL;
>>>> - inconn = coresight_find_out_connection(parent, csdev);
>>>> - outconn = coresight_find_out_connection(csdev, child);
>>>> + inconn = coresight_find_out_connection(parent, csdev, path);
>>>> + outconn = coresight_find_out_connection(csdev, child, path);
>>>> link_subtype = csdev->subtype.link_subtype;
>>>> if (link_subtype == CORESIGHT_DEV_SUBTYPE_LINK_MERG &&
>>>> IS_ERR(inconn))
>>>> @@ -341,7 +390,8 @@ static int coresight_enable_link(struct
>>>> coresight_device *csdev,
>>>> static void coresight_disable_link(struct coresight_device *csdev,
>>>> struct coresight_device *parent,
>>>> - struct coresight_device *child)
>>>> + struct coresight_device *child,
>>>> + struct list_head *path)
>>>> {
>>>> int i;
>>>> int link_subtype;
>>>> @@ -350,8 +400,8 @@ static void coresight_disable_link(struct
>>>> coresight_device *csdev,
>>>> if (!parent || !child)
>>>> return;
>>>> - inconn = coresight_find_out_connection(parent, csdev);
>>>> - outconn = coresight_find_out_connection(csdev, child);
>>>> + inconn = coresight_find_out_connection(parent, csdev, path);
>>>> + outconn = coresight_find_out_connection(csdev, child, path);
>>>> link_subtype = csdev->subtype.link_subtype;
>>>> if (link_ops(csdev)->disable) {
>>>> @@ -507,7 +557,7 @@ static void coresight_disable_path_from(struct
>>>> list_head *path,
>>>> case CORESIGHT_DEV_TYPE_LINK:
>>>> parent = list_prev_entry(nd, link)->csdev;
>>>> child = list_next_entry(nd, link)->csdev;
>>>> - coresight_disable_link(csdev, parent, child);
>>>> + coresight_disable_link(csdev, parent, child, path);
>>>> break;
>>>> default:
>>>> break;
>>>> @@ -588,7 +638,7 @@ int coresight_enable_path(struct list_head
>>>> *path, enum cs_mode mode,
>>>> case CORESIGHT_DEV_TYPE_LINK:
>>>> parent = list_prev_entry(nd, link)->csdev;
>>>> child = list_next_entry(nd, link)->csdev;
>>>> - ret = coresight_enable_link(csdev, parent, child);
>>>> + ret = coresight_enable_link(csdev, parent, child, path);
>>>> if (ret)
>>>> goto err;
>>>> break;
>>>> @@ -802,7 +852,8 @@ static void coresight_drop_device(struct
>>>> coresight_device *csdev)
>>>> */
>>>> static int _coresight_build_path(struct coresight_device *csdev,
>>>> struct coresight_device *sink,
>>>> - struct list_head *path)
>>>> + struct list_head *path,
>>>> + struct coresight_device *source)
>>>> {
>>>> int i, ret;
>>>> bool found = false;
>>>> @@ -814,7 +865,7 @@ static int _coresight_build_path(struct
>>>> coresight_device *csdev,
>>>> if (coresight_is_percpu_source(csdev) &&
>>>> coresight_is_percpu_sink(sink) &&
>>>> sink == per_cpu(csdev_sink,
>>>> source_ops(csdev)->cpu_id(csdev))) {
>>>> - if (_coresight_build_path(sink, sink, path) == 0) {
>>>> + if (_coresight_build_path(sink, sink, path, source) == 0) {
>>>> found = true;
>>>> goto out;
>>>> }
>>>> @@ -825,8 +876,12 @@ static int _coresight_build_path(struct
>>>> coresight_device *csdev,
>>>> struct coresight_device *child_dev;
>>>> child_dev = csdev->pdata->out_conns[i]->dest_dev;
>>>> + if (csdev->pdata->out_conns[i]->source_label &&
>>>> + !strstr(kobject_get_path(&source->dev.kobj, GFP_KERNEL),
>>>> + csdev->pdata->out_conns[i]->source_label))
>>>> + continue;
>>>> if (child_dev &&
>>>> - _coresight_build_path(child_dev, sink, path) == 0) {
>>>> + _coresight_build_path(child_dev, sink, path, source)
>>>> == 0) {
>>>> found = true;
>>>> break;
>>>> }
>>>> @@ -871,7 +926,7 @@ struct list_head *coresight_build_path(struct
>>>> coresight_device *source,
>>>> INIT_LIST_HEAD(path);
>>>> - rc = _coresight_build_path(source, sink, path);
>>>> + rc = _coresight_build_path(source, sink, path, source);
>>>> if (rc) {
>>>> kfree(path);
>>>> return ERR_PTR(rc);
>>>> diff --git a/drivers/hwtracing/coresight/coresight-platform.c
>>>> b/drivers/hwtracing/coresight/coresight-platform.c
>>>> index 9d550f5697fa..f553fb20966d 100644
>>>> --- a/drivers/hwtracing/coresight/coresight-platform.c
>>>> +++ b/drivers/hwtracing/coresight/coresight-platform.c
>>>> @@ -205,6 +205,7 @@ static int of_coresight_parse_endpoint(struct
>>>> device *dev,
>>>> struct fwnode_handle *rdev_fwnode;
>>>> struct coresight_connection conn = {};
>>>> struct coresight_connection *new_conn;
>>>> + const char *label;
>>>> do {
>>>> /* Parse the local port details */
>>>> @@ -243,6 +244,10 @@ static int of_coresight_parse_endpoint(struct
>>>> device *dev,
>>>> conn.dest_fwnode = fwnode_handle_get(rdev_fwnode);
>>>> conn.dest_port = rendpoint.port;
>>>> + conn.source_label = NULL;
>>>> + if (!of_property_read_string(ep, "label", &label))
>>>> + conn.source_label = label;
>>>> +
>>>> new_conn = coresight_add_out_conn(dev, pdata, &conn);
>>>> if (IS_ERR_VALUE(new_conn)) {
>>>> fwnode_handle_put(conn.dest_fwnode);
>>>> diff --git a/include/linux/coresight.h b/include/linux/coresight.h
>>>> index e8b6e388218c..a9c06ef9bbb2 100644
>>>> --- a/include/linux/coresight.h
>>>> +++ b/include/linux/coresight.h
>>>> @@ -167,6 +167,7 @@ struct coresight_desc {
>>>> * struct coresight_connection - representation of a single
>>>> connection
>>>> * @src_port: a connection's output port number.
>>>> * @dest_port: destination's input port number @src_port is
>>>> connected to.
>>>> + * @source_label: source component's label.
>>>> * @dest_fwnode: destination component's fwnode handle.
>>>> * @dest_dev: a @coresight_device representation of the component
>>>> connected to @src_port. NULL until the device is created
>>>> @@ -195,6 +196,7 @@ struct coresight_desc {
>>>> struct coresight_connection {
>>>> int src_port;
>>>> int dest_port;
>>>> + const char *source_label;
>>>> struct fwnode_handle *dest_fwnode;
>>>> struct coresight_device *dest_dev;
>>>> struct coresight_sysfs_link *link;
>>>
>
^ permalink raw reply
* Re: [PATCH v5 0/7] PCI: dwc: rcar-gen4: Add R-Car V4H support
From: Bjorn Helgaas @ 2024-04-09 13:28 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: lpieralisi, kw, robh, bhelgaas, krzysztof.kozlowski+dt, conor+dt,
jingoohan1, mani, marek.vasut+renesas, linux-pci, devicetree,
linux-renesas-soc
In-Reply-To: <20240408012458.3717977-1-yoshihiro.shimoda.uh@renesas.com>
On Mon, Apr 08, 2024 at 10:24:51AM +0900, Yoshihiro Shimoda wrote:
> Yoshihiro Shimoda (7):
> dt-bindings: PCI: rcar-gen4-pci-host: Add R-Car V4H compatible
> dt-bindings: PCI: rcar-gen4-pci-ep: Add R-Car V4H compatible
> PCI: dwc: Add PCIE_PORT_{FORCE,LANE_SKEW} macros
> PCI: dwc: rcar-gen4: Add rcar_gen4_pcie_platdata
> PCI: dwc: rcar-gen4: Add .ltssm_enable() for other SoC support
> PCI: dwc: rcar-gen4: Add support for r8a779g0
Previous history for this file uses a "PCI: rcar-gen4: " prefix
(without "dwc:"). I don't think we need to replicate the whole file
path here in the precious subject line space, so "PCI: rcar-gen4: "
should be enough.
> misc: pci_endpoint_test: Document a policy about adding pci_device_id
>
> .../bindings/pci/rcar-gen4-pci-ep.yaml | 4 +-
> .../bindings/pci/rcar-gen4-pci-host.yaml | 4 +-
> drivers/misc/pci_endpoint_test.c | 1 +
> drivers/pci/controller/dwc/pcie-designware.h | 6 +
> drivers/pci/controller/dwc/pcie-rcar-gen4.c | 272 +++++++++++++++++-
> 5 files changed, 270 insertions(+), 17 deletions(-)
>
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: power: supply: ltc3350-charger: Add bindings
From: Rob Herring @ 2024-04-09 13:31 UTC (permalink / raw)
To: Mike Looijmans
Cc: Krzysztof Kozlowski, Sebastian Reichel, linux-pm, devicetree,
Conor Dooley, linux-kernel
In-Reply-To: <20240409123556.34299-1-mike.looijmans@topic.nl>
On Tue, 09 Apr 2024 14:35:54 +0200, Mike Looijmans wrote:
> The LTC3350 is a backup power controller that can charge and monitor
> a series stack of one to four supercapacitors.
>
> Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
>
> ---
>
> Changes in v2:
> Rename to lltc,ltc3350.yaml
> Fix spaces and indentation
>
> .../bindings/power/supply/lltc,ltc3350.yaml | 54 +++++++++++++++++++
> 1 file changed, 54 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/supply/lltc,ltc3350.yaml
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/supply/lltc,ltc3350.yaml: $id: Cannot determine base path from $id, relative path/filename doesn't match actual path or filename
$id: http://devicetree.org/schemas/power/supply/ltc3350.yaml
file: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/supply/lltc,ltc3350.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240409123556.34299-1-mike.looijmans@topic.nl
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v2 0/3] arm64: dts: add description for solidrun cn9130 som and clearfog boards
From: Rob Herring @ 2024-04-09 13:38 UTC (permalink / raw)
To: Josua Mayer
Cc: Conor Dooley, Andrew Lunn, Gregory Clement, Krzysztof Kozlowski,
devicetree, Rob Herring, Yazan Shhady, Sebastian Hesselbarth,
linux-kernel, linux-arm-kernel
In-Reply-To: <20240404-cn9130-som-v2-0-3af2229c7d2d@solid-run.com>
On Thu, 04 Apr 2024 17:35:04 +0200, Josua Mayer wrote:
> SolidRun CN9130 SoM is a mostly pin-comptible replacement for Armada 388
> SoM used in Clearfog and Clearfog Pro boards.
>
> 1. Add new binding for compatible strings closely matching the original.
>
> 2. Add device-tree includes for SoM and carrier shared design.
>
> 3. Add device-tree for both Clearfog Base and Pro.
>
> While dtbs_check is happy with LED descriptions behind dsa switch,
> functionally they require supporting code by Andrew Lunn:
> https://lore.kernel.org/r/20240401-v6-8-0-net-next-mv88e6xxx-leds-v4-v3-0-221b3fa55f78@lunn.ch
>
> NOTICE IN CASE ANYBODY WANTS TO SELF-UPGRADE:
> CN9130 SoM has a different footprint from Armada 388 SoM.
> Components on the carrier board below the SoM may collide causing
> damage, such as on Clearfog Base.
>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
> ---
> Changes in v2:
> - rewrote dt bindings dropping unnecessary compatibles
> (Reported-By: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>)
> - added bindings for two additional boards (cn9131/9132)
> support planned for the coming weeks, mostly serves
> illustrational purposes, to understand cn913x variants
> - cf-pro: add description for LEDs behind DSA switch
> - cf-base: add description for LEDs behind PHYs
> (Reported-By: Andrew Lunn <andrew@lunn.ch>)
> - Link to v1: https://lore.kernel.org/r/20240321-cn9130-som-v1-0-711127a409ae@solid-run.com
>
> ---
> Josua Mayer (3):
> dt-bindings: arm64: marvell: add solidrun cn9130 som based boards
> dt-bindings: arm64: marvell: add solidrun cn9132 CEX-7 evaluation board
> arm64: dts: add description for solidrun cn9130 som and clearfog boards
>
> .../bindings/arm/marvell/armada-7k-8k.yaml | 18 +
> arch/arm64/boot/dts/marvell/Makefile | 2 +
> arch/arm64/boot/dts/marvell/cn9130-cf-base.dts | 178 ++++++++++
> arch/arm64/boot/dts/marvell/cn9130-cf-pro.dts | 367 +++++++++++++++++++++
> arch/arm64/boot/dts/marvell/cn9130-cf.dtsi | 193 +++++++++++
> arch/arm64/boot/dts/marvell/cn9130-sr-som.dtsi | 159 +++++++++
> 6 files changed, 917 insertions(+)
> ---
> base-commit: 4cece764965020c22cff7665b18a012006359095
> change-id: 20240318-cn9130-som-848e86acb0ac
>
> Sincerely,
> --
> Josua Mayer <josua@solid-run.com>
>
>
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
New warnings running 'make CHECK_DTBS=y marvell/cn9130-cf-base.dtb marvell/cn9130-cf-pro.dtb' for 20240404-cn9130-som-v2-0-3af2229c7d2d@solid-run.com:
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: ap807: $nodename:0: 'ap807' does not match '^([a-z][a-z0-9\-]+-bus|bus|localbus|soc|axi|ahb|apb)(@.+)?$'
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: config-space@f0000000: $nodename:0: 'config-space@f0000000' does not match '^([a-z][a-z0-9\-]+-bus|bus|localbus|soc|axi|ahb|apb)(@.+)?$'
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: config-space@f0000000: timer: {'compatible': ['arm,armv8-timer'], 'interrupts': [[1, 13, 3848], [1, 14, 3848], [1, 11, 3848], [1, 10, 3848]]} should not be valid under {'type': 'object'}
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: config-space@f0000000: pmu: {'compatible': ['arm,cortex-a72-pmu'], 'interrupt-parent': [[2]], 'interrupts': [[17]]} should not be valid under {'type': 'object'}
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/odmi@300000: failed to match any schema with compatible: ['marvell,odmi-controller']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/gicp@3f0040: failed to match any schema with compatible: ['marvell,ap806-gicp']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/interrupt-controller@3f0100: failed to match any schema with compatible: ['marvell,armada-8k-pic']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/interrupt-controller@3f0200: failed to match any schema with compatible: ['marvell,ap806-sei']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/xor@400000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/xor@400000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/xor@420000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/xor@420000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/xor@440000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/xor@440000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/xor@460000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/xor@460000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/spi@510600: failed to match any schema with compatible: ['marvell,armada-380-spi']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: mmc@6e0000: clocks: [[4, 4]] is too short
from schema $id: http://devicetree.org/schemas/mmc/marvell,xenon-sdhci.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: mmc@6e0000: clock-names: ['core'] is too short
from schema $id: http://devicetree.org/schemas/mmc/marvell,xenon-sdhci.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: mmc@6e0000: Unevaluated properties are not allowed ('dma-coherent' was unexpected)
from schema $id: http://devicetree.org/schemas/mmc/marvell,xenon-sdhci.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: system-controller@6f4000: compatible: ['syscon', 'simple-mfd'] is too short
from schema $id: http://devicetree.org/schemas/mfd/syscon.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/system-controller@6f4000/pinctrl: failed to match any schema with compatible: ['marvell,ap806-pinctrl']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: gpio@1040: Unevaluated properties are not allowed ('gpio-ranges' was unexpected)
from schema $id: http://devicetree.org/schemas/gpio/gpio-mvebu.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/system-controller@6f4000/clock: failed to match any schema with compatible: ['marvell,ap807-clock']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: system-controller@6f8000: compatible: ['syscon', 'simple-mfd'] is too short
from schema $id: http://devicetree.org/schemas/mfd/syscon.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/system-controller@6f8000/thermal-sensor@80: failed to match any schema with compatible: ['marvell,armada-ap807-thermal']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/system-controller@6f8000/clock-cpu: failed to match any schema with compatible: ['marvell,ap807-cpu-clock']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: cp0: $nodename:0: 'cp0' does not match '^([a-z][a-z0-9\-]+-bus|bus|localbus|soc|axi|ahb|apb)(@.+)?$'
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: config-space@f2000000: $nodename:0: 'config-space@f2000000' does not match '^([a-z][a-z0-9\-]+-bus|bus|localbus|soc|axi|ahb|apb)(@.+)?$'
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/config-space@f2000000/phy@120000: failed to match any schema with compatible: ['marvell,comphy-cp110']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/config-space@f2000000/interrupt-controller@1e0000: failed to match any schema with compatible: ['marvell,cp110-icu']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/config-space@f2000000/interrupt-controller@1e0000/interrupt-controller@10: failed to match any schema with compatible: ['marvell,cp110-icu-nsr']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/config-space@f2000000/interrupt-controller@1e0000/interrupt-controller@50: failed to match any schema with compatible: ['marvell,cp110-icu-sei']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: system-controller@440000: compatible: ['syscon', 'simple-mfd'] is too short
from schema $id: http://devicetree.org/schemas/mfd/syscon.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/config-space@f2000000/system-controller@440000/clock: failed to match any schema with compatible: ['marvell,cp110-clock']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: gpio@100: Unevaluated properties are not allowed ('gpio-ranges', 'sim-select-hog' were unexpected)
from schema $id: http://devicetree.org/schemas/gpio/gpio-mvebu.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: ap807: $nodename:0: 'ap807' does not match '^([a-z][a-z0-9\-]+-bus|bus|localbus|soc|axi|ahb|apb)(@.+)?$'
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: gpio@140: Unevaluated properties are not allowed ('gpio-ranges' was unexpected)
from schema $id: http://devicetree.org/schemas/gpio/gpio-mvebu.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: config-space@f0000000: $nodename:0: 'config-space@f0000000' does not match '^([a-z][a-z0-9\-]+-bus|bus|localbus|soc|axi|ahb|apb)(@.+)?$'
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: config-space@f0000000: timer: {'compatible': ['arm,armv8-timer'], 'interrupts': [[1, 13, 3848], [1, 14, 3848], [1, 11, 3848], [1, 10, 3848]]} should not be valid under {'type': 'object'}
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: config-space@f0000000: pmu: {'compatible': ['arm,cortex-a72-pmu'], 'interrupt-parent': [[2]], 'interrupts': [[17]]} should not be valid under {'type': 'object'}
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/config-space@f2000000/system-controller@440000/pinctrl: failed to match any schema with compatible: ['marvell,cp115-standalone-pinctrl']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: system-controller@400000: compatible: ['syscon', 'simple-mfd'] is too short
from schema $id: http://devicetree.org/schemas/mfd/syscon.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/config-space@f2000000/system-controller@400000/thermal-sensor@70: failed to match any schema with compatible: ['marvell,armada-cp110-thermal']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: usb@500000: Unevaluated properties are not allowed ('dma-coherent', 'dr_mode', 'vbus-supply' were unexpected)
from schema $id: http://devicetree.org/schemas/usb/generic-xhci.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: usb@510000: Unevaluated properties are not allowed ('dma-coherent', 'dr_mode' were unexpected)
from schema $id: http://devicetree.org/schemas/usb/generic-xhci.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: sata@540000: sata-port@1: 'anyOf' conditional failed, one must be fixed:
'phys' is a required property
'target-supply' is a required property
from schema $id: http://devicetree.org/schemas/ata/ahci-platform.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/config-space@f2000000/xor@6a0000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/config-space@f2000000/xor@6a0000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/config-space@f2000000/xor@6c0000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/config-space@f2000000/xor@6c0000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/config-space@f2000000/spi@700600: failed to match any schema with compatible: ['marvell,armada-380-spi']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/config-space@f2000000/spi@700680: failed to match any schema with compatible: ['marvell,armada-380-spi']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/odmi@300000: failed to match any schema with compatible: ['marvell,odmi-controller']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/gicp@3f0040: failed to match any schema with compatible: ['marvell,ap806-gicp']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/interrupt-controller@3f0100: failed to match any schema with compatible: ['marvell,armada-8k-pic']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/config-space@f2000000/trng@760000: failed to match any schema with compatible: ['marvell,armada-8k-rng', 'inside-secure,safexcel-eip76']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: mmc@780000: Unevaluated properties are not allowed ('dma-coherent' was unexpected)
from schema $id: http://devicetree.org/schemas/mmc/marvell,xenon-sdhci.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: crypto@800000: 'dma-coherent' does not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/crypto/inside-secure,safexcel.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/interrupt-controller@3f0200: failed to match any schema with compatible: ['marvell,ap806-sei']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/pcie@f2600000: failed to match any schema with compatible: ['marvell,armada8k-pcie', 'snps,dw-pcie']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/xor@400000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/xor@400000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/pcie@f2620000: failed to match any schema with compatible: ['marvell,armada8k-pcie', 'snps,dw-pcie']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/pcie@f2640000: failed to match any schema with compatible: ['marvell,armada8k-pcie', 'snps,dw-pcie']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/xor@420000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/xor@420000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/xor@440000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/xor@440000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/xor@460000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/xor@460000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/spi@510600: failed to match any schema with compatible: ['marvell,armada-380-spi']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: mmc@6e0000: clocks: [[4, 4]] is too short
from schema $id: http://devicetree.org/schemas/mmc/marvell,xenon-sdhci.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: mmc@6e0000: clock-names: ['core'] is too short
from schema $id: http://devicetree.org/schemas/mmc/marvell,xenon-sdhci.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: mmc@6e0000: Unevaluated properties are not allowed ('dma-coherent' was unexpected)
from schema $id: http://devicetree.org/schemas/mmc/marvell,xenon-sdhci.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: system-controller@6f4000: compatible: ['syscon', 'simple-mfd'] is too short
from schema $id: http://devicetree.org/schemas/mfd/syscon.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/system-controller@6f4000/pinctrl: failed to match any schema with compatible: ['marvell,ap806-pinctrl']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: gpio@1040: Unevaluated properties are not allowed ('gpio-ranges' was unexpected)
from schema $id: http://devicetree.org/schemas/gpio/gpio-mvebu.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/system-controller@6f4000/clock: failed to match any schema with compatible: ['marvell,ap807-clock']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: system-controller@6f8000: compatible: ['syscon', 'simple-mfd'] is too short
from schema $id: http://devicetree.org/schemas/mfd/syscon.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/system-controller@6f8000/thermal-sensor@80: failed to match any schema with compatible: ['marvell,armada-ap807-thermal']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/system-controller@6f8000/clock-cpu: failed to match any schema with compatible: ['marvell,ap807-cpu-clock']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: cp0: $nodename:0: 'cp0' does not match '^([a-z][a-z0-9\-]+-bus|bus|localbus|soc|axi|ahb|apb)(@.+)?$'
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: config-space@f2000000: $nodename:0: 'config-space@f2000000' does not match '^([a-z][a-z0-9\-]+-bus|bus|localbus|soc|axi|ahb|apb)(@.+)?$'
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/config-space@f2000000/phy@120000: failed to match any schema with compatible: ['marvell,comphy-cp110']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/config-space@f2000000/interrupt-controller@1e0000: failed to match any schema with compatible: ['marvell,cp110-icu']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/config-space@f2000000/interrupt-controller@1e0000/interrupt-controller@10: failed to match any schema with compatible: ['marvell,cp110-icu-nsr']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/config-space@f2000000/interrupt-controller@1e0000/interrupt-controller@50: failed to match any schema with compatible: ['marvell,cp110-icu-sei']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: system-controller@440000: compatible: ['syscon', 'simple-mfd'] is too short
from schema $id: http://devicetree.org/schemas/mfd/syscon.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/config-space@f2000000/system-controller@440000/clock: failed to match any schema with compatible: ['marvell,cp110-clock']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: gpio@100: Unevaluated properties are not allowed ('gpio-ranges' was unexpected)
from schema $id: http://devicetree.org/schemas/gpio/gpio-mvebu.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: gpio@140: Unevaluated properties are not allowed ('gpio-ranges' was unexpected)
from schema $id: http://devicetree.org/schemas/gpio/gpio-mvebu.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/config-space@f2000000/system-controller@440000/pinctrl: failed to match any schema with compatible: ['marvell,cp115-standalone-pinctrl']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: system-controller@400000: compatible: ['syscon', 'simple-mfd'] is too short
from schema $id: http://devicetree.org/schemas/mfd/syscon.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/config-space@f2000000/system-controller@400000/thermal-sensor@70: failed to match any schema with compatible: ['marvell,armada-cp110-thermal']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: usb@500000: Unevaluated properties are not allowed ('dma-coherent', 'dr_mode', 'vbus-supply' were unexpected)
from schema $id: http://devicetree.org/schemas/usb/generic-xhci.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: usb@510000: Unevaluated properties are not allowed ('dma-coherent', 'dr_mode' were unexpected)
from schema $id: http://devicetree.org/schemas/usb/generic-xhci.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: sata@540000: sata-port@1: 'anyOf' conditional failed, one must be fixed:
'phys' is a required property
'target-supply' is a required property
from schema $id: http://devicetree.org/schemas/ata/ahci-platform.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/config-space@f2000000/xor@6a0000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/config-space@f2000000/xor@6a0000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/config-space@f2000000/xor@6c0000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/config-space@f2000000/xor@6c0000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/config-space@f2000000/spi@700600: failed to match any schema with compatible: ['marvell,armada-380-spi']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/config-space@f2000000/spi@700680: failed to match any schema with compatible: ['marvell,armada-380-spi']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/config-space@f2000000/trng@760000: failed to match any schema with compatible: ['marvell,armada-8k-rng', 'inside-secure,safexcel-eip76']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: mmc@780000: Unevaluated properties are not allowed ('dma-coherent' was unexpected)
from schema $id: http://devicetree.org/schemas/mmc/marvell,xenon-sdhci.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: crypto@800000: 'dma-coherent' does not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/crypto/inside-secure,safexcel.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/pcie@f2600000: failed to match any schema with compatible: ['marvell,armada8k-pcie', 'snps,dw-pcie']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/pcie@f2620000: failed to match any schema with compatible: ['marvell,armada8k-pcie', 'snps,dw-pcie']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/pcie@f2640000: failed to match any schema with compatible: ['marvell,armada8k-pcie', 'snps,dw-pcie']
^ permalink raw reply
* Re: [PATCH v2 1/5] ARM: dts: aspeed: greatlakes: correct Mellanox multi-host property
From: Rob Herring @ 2024-04-09 13:38 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Krzysztof Kozlowski, devicetree, Andrew Jeffery, Joel Stanley,
linux-arm-kernel, Conor Dooley, linux-kernel, linux-aspeed
In-Reply-To: <20240405064624.18997-1-krzysztof.kozlowski@linaro.org>
On Fri, 05 Apr 2024 08:46:20 +0200, Krzysztof Kozlowski wrote:
> "mlx,multi-host" is using incorrect vendor prefix and is not documented.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>
> ---
>
> Changes in v2:
> 1. None
> ---
> arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-greatlakes.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
New warnings running 'make CHECK_DTBS=y aspeed/aspeed-bmc-ampere-mtmitchell.dtb aspeed/aspeed-bmc-facebook-greatlakes.dtb aspeed/aspeed-bmc-facebook-harma.dtb aspeed/aspeed-bmc-facebook-yosemite4.dtb aspeed/aspeed-bmc-facebook-yosemitev2.dtb' for 20240405064624.18997-1-krzysztof.kozlowski@linaro.org:
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dtb: ftgmac@1e690000: Unevaluated properties are not allowed ('#address-cells', '#size-cells', 'mellanox,multi-host' were unexpected)
from schema $id: http://devicetree.org/schemas/net/faraday,ftgmac100.yaml#
^ permalink raw reply
* Re: [PATCH 0/3] arm64: dts: qcom: msm8916-samsung-fortuna: Add accelerometer/magnetometer
From: Rob Herring @ 2024-04-09 13:38 UTC (permalink / raw)
To: Raymond Hackley
Cc: linux-arm-msm, Krzysztof Kozlowski, Rob Herring, linux-kernel,
Konrad Dybcio, ~postmarketos/upstreaming, Conor Dooley,
devicetree, Bjorn Andersson, Stephan Gerhold, Nikita Travkin
In-Reply-To: <20240405120803.20754-1-raymondhackley@protonmail.com>
On Fri, 05 Apr 2024 12:08:19 +0000, Raymond Hackley wrote:
> Some Grand Prime use a Bosch BMC150 accelerometer/magnetometer combo.
> The chip provides two separate I2C devices for the accelerometer
> and magnetometer that are already supported by the bmc150-accel
> and bmc150-magn driver.
> Some Grand Prime use a ST LSM303C accelerometer/magnetometer combo.
> Core Prime LTE uses ST LIS2HH12 accelerometer.
>
> Add support for them.
>
>
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
New warnings running 'make CHECK_DTBS=y qcom/msm8216-samsung-fortuna3g.dtb' for 20240405120803.20754-1-raymondhackley@protonmail.com:
arch/arm64/boot/dts/qcom/msm8216-samsung-fortuna3g.dtb: magnetometer@12: 'mount-matrix' does not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/iio/magnetometer/bosch,bmc150_magn.yaml#
arch/arm64/boot/dts/qcom/msm8216-samsung-fortuna3g.dtb: accelerometer@1d: 'interrupt-names' does not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/iio/st,st-sensors.yaml#
^ permalink raw reply
* Re: [PATCH 0/4] Introduce msm8916 based Motorola devices
From: Rob Herring @ 2024-04-09 13:38 UTC (permalink / raw)
To: Nikita Travkin
Cc: linux-arm-msm, Stephan Gerhold, Krzysztof Kozlowski,
Konrad Dybcio, Bjorn Andersson, linux-kernel, devicetree,
Ruby Iris Juric, Valérie Roux, Wiktor Strzębała,
Martijn Braam, Conor Dooley
In-Reply-To: <20240405-msm8916-moto-init-v1-0-502b58176d34@trvn.ru>
On Fri, 05 Apr 2024 19:06:09 +0500, Nikita Travkin wrote:
> This series introduces a set of msm8916 bsed Motorola devices:
>
> - Moto G4 Play (harpia)
> - Moto G 2015 (osprey)
> - Moto E 2015 LTE (surnia)
>
> The submission brings up the following features:
>
> - eMMC and SD;
> - Buttons;
> - Touchscreen;
> - USB;
> - Fuel Gauge;
> - Sound;
> - Accelerometer (harpia only).
>
> Since the devices share a lot of similarities, the common parts of the
> DT are separated out into a dedicated dtsi, introduced with the first
> device.
>
> Signed-off-by: Nikita Travkin <nikita@trvn.ru>
> ---
> Martijn Braam (1):
> arm64: dts: qcom: Add Motorola Moto G 2015 (osprey)
>
> Nikita Travkin (1):
> dt-bindings: arm: qcom: Add msm8916 based Motorola devices
>
> Ruby Iris Juric (1):
> arm64: dts: qcom: Add device tree for Motorola Moto G4 Play (harpia)
>
> Wiktor Strzębała (1):
> arm64: dts: qcom: Add Motorola Moto E 2015 LTE (surnia)
>
> Documentation/devicetree/bindings/arm/qcom.yaml | 3 +
> arch/arm64/boot/dts/qcom/Makefile | 3 +
> .../boot/dts/qcom/msm8916-motorola-common.dtsi | 161 +++++++++++++++++++++
> .../boot/dts/qcom/msm8916-motorola-harpia.dts | 147 +++++++++++++++++++
> .../boot/dts/qcom/msm8916-motorola-osprey.dts | 105 ++++++++++++++
> .../boot/dts/qcom/msm8916-motorola-surnia.dts | 83 +++++++++++
> 6 files changed, 502 insertions(+)
> ---
> base-commit: 29493ca7d6b1d3fdc224467c422ac9bdf6d7a252
> change-id: 20240405-msm8916-moto-init-640862b8f57c
>
> Best regards,
> --
> Nikita Travkin <nikita@trvn.ru>
>
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
New warnings running 'make CHECK_DTBS=y qcom/msm8916-motorola-harpia.dtb qcom/msm8916-motorola-osprey.dtb qcom/msm8916-motorola-surnia.dtb' for 20240405-msm8916-moto-init-v1-0-502b58176d34@trvn.ru:
arch/arm64/boot/dts/qcom/msm8916-motorola-surnia.dtb: /soc@0/audio-codec@771c000: failed to match any schema with compatible: ['qcom,msm8916-wcd-digital-codec']
arch/arm64/boot/dts/qcom/msm8916-motorola-harpia.dtb: /soc@0/audio-codec@771c000: failed to match any schema with compatible: ['qcom,msm8916-wcd-digital-codec']
arch/arm64/boot/dts/qcom/msm8916-motorola-osprey.dtb: /soc@0/audio-codec@771c000: failed to match any schema with compatible: ['qcom,msm8916-wcd-digital-codec']
arch/arm64/boot/dts/qcom/msm8916-motorola-surnia.dtb: /soc@0/power-manager@b088000: failed to match any schema with compatible: ['qcom,msm8916-acc']
arch/arm64/boot/dts/qcom/msm8916-motorola-harpia.dtb: /soc@0/power-manager@b088000: failed to match any schema with compatible: ['qcom,msm8916-acc']
arch/arm64/boot/dts/qcom/msm8916-motorola-surnia.dtb: /soc@0/power-manager@b098000: failed to match any schema with compatible: ['qcom,msm8916-acc']
arch/arm64/boot/dts/qcom/msm8916-motorola-harpia.dtb: /soc@0/power-manager@b098000: failed to match any schema with compatible: ['qcom,msm8916-acc']
arch/arm64/boot/dts/qcom/msm8916-motorola-surnia.dtb: /soc@0/power-manager@b0a8000: failed to match any schema with compatible: ['qcom,msm8916-acc']
arch/arm64/boot/dts/qcom/msm8916-motorola-harpia.dtb: /soc@0/power-manager@b0a8000: failed to match any schema with compatible: ['qcom,msm8916-acc']
arch/arm64/boot/dts/qcom/msm8916-motorola-surnia.dtb: /soc@0/power-manager@b0b8000: failed to match any schema with compatible: ['qcom,msm8916-acc']
arch/arm64/boot/dts/qcom/msm8916-motorola-harpia.dtb: /soc@0/power-manager@b0b8000: failed to match any schema with compatible: ['qcom,msm8916-acc']
arch/arm64/boot/dts/qcom/msm8916-motorola-osprey.dtb: /soc@0/power-manager@b088000: failed to match any schema with compatible: ['qcom,msm8916-acc']
arch/arm64/boot/dts/qcom/msm8916-motorola-osprey.dtb: /soc@0/power-manager@b098000: failed to match any schema with compatible: ['qcom,msm8916-acc']
arch/arm64/boot/dts/qcom/msm8916-motorola-osprey.dtb: /soc@0/power-manager@b0a8000: failed to match any schema with compatible: ['qcom,msm8916-acc']
arch/arm64/boot/dts/qcom/msm8916-motorola-osprey.dtb: /soc@0/power-manager@b0b8000: failed to match any schema with compatible: ['qcom,msm8916-acc']
arch/arm64/boot/dts/qcom/msm8916-motorola-surnia.dtb: /usb-id: failed to match any schema with compatible: ['linux,extcon-usb-gpio']
arch/arm64/boot/dts/qcom/msm8916-motorola-harpia.dtb: /usb-id: failed to match any schema with compatible: ['linux,extcon-usb-gpio']
arch/arm64/boot/dts/qcom/msm8916-motorola-osprey.dtb: /usb-id: failed to match any schema with compatible: ['linux,extcon-usb-gpio']
^ permalink raw reply
* Re: [PATCH v2 0/3] arm64: dts: qcom: msm8916-samsung-fortuna: Add accelerometer/magnetometer
From: Rob Herring @ 2024-04-09 13:38 UTC (permalink / raw)
To: Raymond Hackley
Cc: Nikita Travkin, Stephan Gerhold, Rob Herring, Konrad Dybcio,
Krzysztof Kozlowski, Bjorn Andersson, Conor Dooley, linux-arm-msm,
~postmarketos/upstreaming, devicetree, linux-kernel
In-Reply-To: <20240406111348.14358-1-raymondhackley@protonmail.com>
On Sat, 06 Apr 2024 11:14:12 +0000, Raymond Hackley wrote:
> Some Grand Prime use a Bosch BMC150 accelerometer/magnetometer combo.
> The chip provides two separate I2C devices for the accelerometer
> and magnetometer that are already supported by the bmc150-accel
> and bmc150-magn driver.
> Some Grand Prime use a ST LSM303C accelerometer/magnetometer combo.
> Core Prime LTE uses ST LIS2HH12 accelerometer.
>
> Add support for them.
> ---
> v2: fix accelerometer@1d: 'interrupt-names' does not match any of the regexes:
> 'pinctrl-[0-9]+'
>
>
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
New warnings running 'make CHECK_DTBS=y qcom/msm8216-samsung-fortuna3g.dtb' for 20240406111348.14358-1-raymondhackley@protonmail.com:
arch/arm64/boot/dts/qcom/msm8216-samsung-fortuna3g.dtb: magnetometer@12: 'mount-matrix' does not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/iio/magnetometer/bosch,bmc150_magn.yaml#
^ permalink raw reply
* Re: [PATCH v4 0/2] Samsung Galaxy Z Fold5 initial support
From: Rob Herring @ 2024-04-09 13:38 UTC (permalink / raw)
To: Alexandru Marc Serdeliuc
Cc: Conor Dooley, Krzysztof Kozlowski, Bjorn Andersson, linux-arm-msm,
devicetree, linux-kernel, Konrad Dybcio
In-Reply-To: <20240407-samsung-galaxy-zfold5-q5q-v4-0-8b67b1813653@yahoo.com>
On Sun, 07 Apr 2024 07:38:12 +0200, Alexandru Marc Serdeliuc wrote:
> - removed extraneous new line
> - removed pcie_1_phy_aux_clk
> - removed extranous pcie1
>
> This documents and add intial dts support for Samsung Galaxy Z Fold5 (samsung,q5q)
> which is a foldable phone by Samsung based on the sm8550 SoC.
>
> Currently working features:
> - Framebuffer
> - UFS
> - i2c
> - Buttons
>
> Signed-off-by: Alexandru Marc Serdeliuc <serdeliuk@yahoo.com>
> ---
> Alexandru Marc Serdeliuc (2):
> dt-bindings: arm: qcom: Document the Samsung Galaxy Z Fold5
> arm64: dts: qcom: sm8550: Add support for Samsung Galaxy Z Fold5
>
> Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
> arch/arm64/boot/dts/qcom/Makefile | 1 +
> arch/arm64/boot/dts/qcom/sm8550-samsung-q5q.dts | 593 ++++++++++++++++++++++++
> 3 files changed, 595 insertions(+)
> ---
> base-commit: 39cd87c4eb2b893354f3b850f916353f2658ae6f
> change-id: 20240407-samsung-galaxy-zfold5-q5q-ab1fdb3df966
>
> Best regards,
> --
> Alexandru Marc Serdeliuc <serdeliuk@yahoo.com>
>
>
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
New warnings running 'make CHECK_DTBS=y qcom/sm8550-samsung-q5q.dtb' for 20240407-samsung-galaxy-zfold5-q5q-v4-0-8b67b1813653@yahoo.com:
arch/arm64/boot/dts/qcom/sm8550-samsung-q5q.dtb: pcie-1-phy-aux-clk: 'clock-frequency' is a required property
from schema $id: http://devicetree.org/schemas/clock/fixed-clock.yaml#
arch/arm64/boot/dts/qcom/sm8550-samsung-q5q.dtb: phy@1c0e000: clock-output-names: ['pcie1_pipe_clk'] is too short
from schema $id: http://devicetree.org/schemas/phy/qcom,sc8280xp-qmp-pcie-phy.yaml#
arch/arm64/boot/dts/qcom/sm8550-samsung-q5q.dtb: phy@1c0e000: #clock-cells:0:0: 1 was expected
from schema $id: http://devicetree.org/schemas/phy/qcom,sc8280xp-qmp-pcie-phy.yaml#
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: arm64: mediatek: add Kontron 3.5"-SBC-i1200
From: Rob Herring @ 2024-04-09 13:38 UTC (permalink / raw)
To: Michael Walle
Cc: Matthias Brugger, Sean Wang, Conor Dooley,
AngeloGioacchino Del Regno, linux-kernel, devicetree,
linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski,
linux-mediatek
In-Reply-To: <20240408080816.4134370-1-mwalle@kernel.org>
On Mon, 08 Apr 2024 10:08:15 +0200, Michael Walle wrote:
> Add the compatible string for the Kontron 3.5"-SBC-i1200 single board
> computer.
>
> Signed-off-by: Michael Walle <mwalle@kernel.org>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> v4:
> - rebase to latest next
>
> v3:
> - drop description and add to mt8395 existing entry
>
> v2:
> - convert enum to const as there is only one specific board
> ---
> Documentation/devicetree/bindings/arm/mediatek.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
New warnings running 'make CHECK_DTBS=y mediatek/mt8395-kontron-3-5-sbc-i1200.dtb' for 20240408080816.4134370-1-mwalle@kernel.org:
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: soc: jpgdec-master: {'compatible': ['mediatek,mt8195-jpgdec'], 'power-domains': [[43, 24]], 'iommus': [[130, 621], [130, 622], [130, 626], [130, 627], [130, 628], [130, 629]], '#address-cells': [[2]], '#size-cells': [[2]], 'ranges': True, 'jpgdec@1a040000': {'compatible': ['mediatek,mt8195-jpgdec-hw'], 'reg': [[0, 436469760, 0, 65536]], 'iommus': [[130, 621], [130, 622], [130, 626], [130, 627], [130, 628], [130, 629]], 'interrupts': [[0, 343, 4, 0]], 'clocks': [[34, 3]], 'clock-names': ['jpgdec'], 'power-domains': [[43, 23]]}, 'jpgdec@1a050000': {'compatible': ['mediatek,mt8195-jpgdec-hw'], 'reg': [[0, 436535296, 0, 65536]], 'iommus': [[130, 621], [130, 622], [130, 626], [130, 627], [130, 628], [130, 629]], 'interrupts': [[0, 344, 4, 0]], 'clocks': [[34, 4]], 'clock-names': ['jpgdec'], 'power-domains': [[43, 24]]}, 'jpgdec@1b040000': {'compatible': ['mediatek,mt8195-jpgdec-hw'], 'reg': [[0, 453246976, 0, 65536]], 'iommus': [[112, 653], [112, 654], [112, 658], [112, 659], [112, 660], [112, 661]], 'interrupts': [[0, 348, 4, 0]], 'clocks': [[28, 3]], 'clock-names': ['jpgdec'], 'power-domains': [[43, 25]]}} should not be valid under {'type': 'object'}
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: soc: jpgenc-master: {'compatible': ['mediatek,mt8195-jpgenc'], 'power-domains': [[43, 27]], 'iommus': [[112, 647], [112, 648], [112, 649], [112, 652]], '#address-cells': [[2]], '#size-cells': [[2]], 'ranges': True, 'jpgenc@1a030000': {'compatible': ['mediatek,mt8195-jpgenc-hw'], 'reg': [[0, 436404224, 0, 65536]], 'iommus': [[130, 615], [130, 616], [130, 617], [130, 620]], 'interrupts': [[0, 342, 4, 0]], 'clocks': [[34, 2]], 'clock-names': ['jpgenc'], 'power-domains': [[43, 26]]}, 'jpgenc@1b030000': {'compatible': ['mediatek,mt8195-jpgenc-hw'], 'reg': [[0, 453181440, 0, 65536]], 'iommus': [[112, 647], [112, 648], [112, 649], [112, 652]], 'interrupts': [[0, 347, 4, 0]], 'clocks': [[28, 2]], 'clock-names': ['jpgenc'], 'power-domains': [[43, 27]]}} should not be valid under {'type': 'object'}
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: syscon@10001000: compatible: ['mediatek,mt8195-infracfg_ao', 'syscon', 'simple-mfd'] is too long
from schema $id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt8195-sys-clock.yaml#
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: /soc/pwrap@10024000/pmic: failed to match any schema with compatible: ['mediatek,mt6359']
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: /soc/pwrap@10024000/pmic/mt6359rtc: failed to match any schema with compatible: ['mediatek,mt6358-rtc']
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: infra-iommu@10315000: interrupts: [[0, 795, 4, 0], [0, 796, 4, 0], [0, 797, 4, 0], [0, 798, 4, 0], [0, 799, 4, 0]] is too long
from schema $id: http://devicetree.org/schemas/iommu/mediatek,iommu.yaml#
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: ethernet@11021000: Unevaluated properties are not allowed ('snps,rxpbl', 'snps,txpbl' were unexpected)
from schema $id: http://devicetree.org/schemas/net/mediatek-dwmac.yaml#
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: regulator: 'BUCK1', 'BUCK2', 'LDO1', 'LDO2', 'LDO3', 'LDO5', 'LDO6', 'LDO7' do not match any of the regexes: '^buck[12]$', '^ldo[123567]$', 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/regulator/mt6360-regulator.yaml#
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: t-phy@11e30000: 'power-domains' does not match any of the regexes: '^(usb|pcie|sata)-phy@[0-9a-f]+$', 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/phy/mediatek,tphy.yaml#
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: display@14f06000: clocks: [[30, 14], [30, 43], [30, 44]] is too long
from schema $id: http://devicetree.org/schemas/display/mediatek/mediatek,split.yaml#
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: dp-intf@1c015000: clock-names:0: 'pixel' was expected
from schema $id: http://devicetree.org/schemas/display/mediatek/mediatek,dpi.yaml#
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: dp-intf@1c015000: clock-names:1: 'engine' was expected
from schema $id: http://devicetree.org/schemas/display/mediatek/mediatek,dpi.yaml#
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: mutex@1c101000: 'clock-names', 'reg-names' do not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/soc/mediatek/mediatek,mutex.yaml#
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: dp-intf@1c113000: clock-names:0: 'pixel' was expected
from schema $id: http://devicetree.org/schemas/display/mediatek/mediatek,dpi.yaml#
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: dp-intf@1c113000: clock-names:1: 'engine' was expected
from schema $id: http://devicetree.org/schemas/display/mediatek/mediatek,dpi.yaml#
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: dp-intf@1c113000: Additional properties are not allowed ('power-domains' was unexpected)
from schema $id: http://devicetree.org/schemas/display/mediatek/mediatek,dpi.yaml#
^ permalink raw reply
* Re: [PATCH] arm64: dts: mediatek: mt7622: fix "emmc" pinctrl mux
From: Rob Herring @ 2024-04-09 13:38 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Ryder Lee, Sean Wang, Krzysztof Kozlowski, Conor Dooley,
linux-arm-kernel, AngeloGioacchino Del Regno, devicetree,
Rafał Miłecki, linux-mediatek, Matthias Brugger
In-Reply-To: <20240408100040.25997-1-zajec5@gmail.com>
On Mon, 08 Apr 2024 12:00:40 +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Value "emmc_rst" is a group name and should be part of the "groups"
> property.
>
> This fixes:
> arch/arm64/boot/dts/mediatek/mt7622-rfb1.dtb: pinctrl@10211000: emmc-pins-default:mux:function: ['emmc', 'emmc_rst'] is too long
> from schema $id: http://devicetree.org/schemas/pinctrl/mediatek,mt7622-pinctrl.yaml#
> arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dtb: pinctrl@10211000: emmc-pins-default:mux:function: ['emmc', 'emmc_rst'] is too long
> from schema $id: http://devicetree.org/schemas/pinctrl/mediatek,mt7622-pinctrl.yaml#
>
> Fixes: 3725ba3f5574 ("arm64: dts: mt7622: add pinctrl related device nodes")
> Fixes: 0b6286dd96c0 ("arm64: dts: mt7622: add bananapi BPI-R64 board")
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts | 4 ++--
> arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
New warnings running 'make CHECK_DTBS=y mediatek/mt7622-bananapi-bpi-r64.dtb mediatek/mt7622-rfb1.dtb' for 20240408100040.25997-1-zajec5@gmail.com:
arch/arm64/boot/dts/mediatek/mt7622-rfb1.dtb: pinctrl@10211000: emmc-pins-default:mux:groups: ['emmc', 'emmc_rst'] is too long
from schema $id: http://devicetree.org/schemas/pinctrl/mediatek,mt7622-pinctrl.yaml#
arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dtb: pinctrl@10211000: emmc-pins-default:mux:groups: ['emmc', 'emmc_rst'] is too long
from schema $id: http://devicetree.org/schemas/pinctrl/mediatek,mt7622-pinctrl.yaml#
^ permalink raw reply
* Re: [PATCH 1/1] arm64: dts: rockchip: enable onboard spi flash for rock-3a
From: Rob Herring @ 2024-04-09 13:38 UTC (permalink / raw)
To: Chukun Pan
Cc: devicetree, linux-kernel, Conor Dooley, Heiko Stuebner,
linux-arm-kernel, linux-rockchip, Krzysztof Kozlowski
In-Reply-To: <20240408124005.182565-1-amadeus@jmu.edu.cn>
On Mon, 08 Apr 2024 20:40:05 +0800, Chukun Pan wrote:
> There is a mx25u12835f spi flash on this board, enable it.
>
> [ 2.525805] spi-nor spi4.0: mx25u12835f (16384 Kbytes)
>
> Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
> ---
> arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
New warnings running 'make CHECK_DTBS=y rockchip/rk3568-rock-3a.dtb' for 20240408124005.182565-1-amadeus@jmu.edu.cn:
arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts:765.3-15: Warning (reg_format): /spi@fe300000/flash@0:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dtb: Warning (pci_device_reg): Failed prerequisite 'reg_format'
arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
arch/arm64/boot/dts/rockchip/rk356x.dtsi:1091.20-1100.4: Warning (spi_bus_bridge): /spi@fe300000: incorrect #address-cells for SPI bus
also defined at arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts:760.6-770.3
arch/arm64/boot/dts/rockchip/rk356x.dtsi:1091.20-1100.4: Warning (spi_bus_bridge): /spi@fe300000: incorrect #size-cells for SPI bus
also defined at arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts:760.6-770.3
arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format'
arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dtb: Warning (spi_bus_reg): Failed prerequisite 'spi_bus_bridge'
arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts:763.10-769.4: Warning (avoid_default_addr_size): /spi@fe300000/flash@0: Relying on default #address-cells value
arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts:763.10-769.4: Warning (avoid_default_addr_size): /spi@fe300000/flash@0: Relying on default #size-cells value
^ permalink raw reply
* Re: [PATCH 0/4] arm64: dts: qcom: add USB-C orientation GPIOs
From: Rob Herring @ 2024-04-09 13:38 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Conor Dooley, Bjorn Andersson, Konrad Dybcio, Krzysztof Kozlowski,
linux-kernel, devicetree, linux-arm-msm
In-Reply-To: <20240408-hdk-orientation-gpios-v1-0-8064ba43e52a@linaro.org>
On Mon, 08 Apr 2024 05:33:58 +0300, Dmitry Baryshkov wrote:
> Populate orientation GPIOs for some of the PMIC-GLINK-based devices.
> This leaves only FairPhone5, RB3Gen2, SC8180X Primus and SC8280XP CRD
> without the orientation GPIOs declared.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
> Dmitry Baryshkov (4):
> arm64: dts: qcom: sm8350-hdk: add USB-C orientation GPIO
> arm64: dts: qcom: sm8450-hdk: add USB-C orientation GPIO
> arm64: dts: qcom: sc8280xp-lenovo-thinkpad-x13s: add USB-C orientation GPIOs
> arm64: dts: qcom: sc8180x-lenovo-flex-5g: add USB-C orientation GPIOs
>
> arch/arm64/boot/dts/qcom/sc8180x-lenovo-flex-5g.dts | 2 ++
> arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 2 ++
> arch/arm64/boot/dts/qcom/sm8350-hdk.dts | 1 +
> arch/arm64/boot/dts/qcom/sm8450-hdk.dts | 1 +
> 4 files changed, 6 insertions(+)
> ---
> base-commit: 8568bb2ccc278f344e6ac44af6ed010a90aa88dc
> change-id: 20240408-hdk-orientation-gpios-141bc7fd247d
>
> Best regards,
> --
> Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>
>
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
New warnings running 'make CHECK_DTBS=y qcom/sc8180x-lenovo-flex-5g.dtb qcom/sc8280xp-lenovo-thinkpad-x13s.dtb qcom/sm8350-hdk.dtb qcom/sm8450-hdk.dtb' for 20240408-hdk-orientation-gpios-v1-0-8064ba43e52a@linaro.org:
arch/arm64/boot/dts/qcom/sc8180x-lenovo-flex-5g.dtb: pmic-glink: orientation-gpios: False schema does not allow [[50, 38, 0], [50, 58, 0]]
from schema $id: http://devicetree.org/schemas/soc/qcom/qcom,pmic-glink.yaml#
arch/arm64/boot/dts/qcom/sm8350-hdk.dtb: pmic-glink: orientation-gpios: False schema does not allow [[52, 81, 0]]
from schema $id: http://devicetree.org/schemas/soc/qcom/qcom,pmic-glink.yaml#
arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dtb: pmic-glink: orientation-gpios: False schema does not allow [[62, 166, 0], [62, 49, 0]]
from schema $id: http://devicetree.org/schemas/soc/qcom/qcom,pmic-glink.yaml#
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox