lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Tue, 16 May 2023 18:27:32 +0200
From:   Alexandre TORGUE <alexandre.torgue@...s.st.com>
To:     Fabrice Gasnier <fabrice.gasnier@...s.st.com>,
        <robh+dt@...nel.org>, <krzysztof.kozlowski+dt@...aro.org>
CC:     <amelie.delaunay@...s.st.com>, <devicetree@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>,
        <linux-stm32@...md-mailman.stormreply.com>
Subject: Re: [RFC PATCH] ARM: dts: stm32: remove typec port dtbs_check warning
 on stm32mp15xx-dkx


On 4/12/23 17:13, Fabrice Gasnier wrote:
> According to usb-connector.yaml, typec connector should always use:
> - ports property
> - with port@0 (required).
> This is also true for a single HS port. This removes dtbs_check warning:
> stusb1600@28: connector: Unevaluated properties are not allowed ('port'
> was unexpected)
> 
> Downside is it introduces another warning when building with W=1:
> 
> Warning (graph_child_address): /soc/i2c@...02000/stusb1600@...connector/
> ports: graph node has single child node 'port@0', #address-cells
> /#size-cells are not necessary
> 
> By removing #address-cells/#size-cells as suggested, another couple of
> W=1 warning shows up:
> Warning (avoid_default_addr_size): /soc/i2c@...02000/stusb1600@28/
> connector/ports/port@0: Relying on default #address-cells value
> Warning (avoid_default_addr_size): /soc/i2c@...02000/stusb1600@28/
> connector/ports/port@0: Relying on default #size-cells value
> 
> Is there a clean way or necessary change to reach a clean build and clean
> dtbs_check ?
> Maybe this kind of concern has already been addressed ?
> As far as I understand, the OF graph allows a single port {} node (e.g.
> code being reworked here). Could this be added in relevant dtschema, to
> address the single HS port use case (usb-connector.yaml) ?
> 

Rob, Krzysztof, do you an idea to figure out this issue ?

Thanks in advance
Alex


> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@...s.st.com>
> ---
>   arch/arm/boot/dts/stm32mp15xx-dkx.dtsi | 11 ++++++++---
>   1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/stm32mp15xx-dkx.dtsi b/arch/arm/boot/dts/stm32mp15xx-dkx.dtsi
> index cefeeb00fc22..41e79c8cc752 100644
> --- a/arch/arm/boot/dts/stm32mp15xx-dkx.dtsi
> +++ b/arch/arm/boot/dts/stm32mp15xx-dkx.dtsi
> @@ -259,9 +259,14 @@ connector {
>   			power-role = "dual";
>   			typec-power-opmode = "default";
>   
> -			port {
> -				con_usbotg_hs_ep: endpoint {
> -					remote-endpoint = <&usbotg_hs_ep>;
> +			ports {
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +				port@0 {
> +					reg = <0>;
> +					con_usbotg_hs_ep: endpoint {
> +						remote-endpoint = <&usbotg_hs_ep>;
> +					};
>   				};
>   			};
>   		};

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ