linux-kernel - Re: [PATCH 11/13] ARM: dts: stm32: fix LTDC port node on STM32 MCU ad MPU

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 15 Apr 2021 16:35:25 +0200
From:   Alexandre TORGUE <alexandre.torgue@...s.st.com>
To:     Marek Vasut <marex@...x.de>, <arnd@...db.de>, <robh+dt@...nel.org>,
        <jagan@...rulasolutions.com>,
        Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
        Marcin Sloniewski <marcin.sloniewski@...il.com>,
        Ahmad Fatoum <a.fatoum@...gutronix.de>
CC:     <linux-arm-kernel@...ts.infradead.org>,
        <devicetree@...r.kernel.org>,
        <linux-stm32@...md-mailman.stormreply.com>,
        <linux-kernel@...r.kernel.org>, Lee Jones <lee.jones@...aro.org>,
        <kuba@...nel.org>
Subject: Re: [PATCH 11/13] ARM: dts: stm32: fix LTDC port node on STM32 MCU ad
 MPU



On 4/15/21 4:30 PM, Marek Vasut wrote:
> On 4/15/21 3:34 PM, Alexandre TORGUE wrote:
>> Hi Marek
> 
> Hello Alexandre,
> 
>>>> diff --git a/arch/arm/boot/dts/stm32mp157c-dk2.dts 
>>>> b/arch/arm/boot/dts/stm32mp157c-dk2.dts
>>>> index 2bc92ef3aeb9..19ef475a48fc 100644
>>>> --- a/arch/arm/boot/dts/stm32mp157c-dk2.dts
>>>> +++ b/arch/arm/boot/dts/stm32mp157c-dk2.dts
>>>> @@ -82,9 +82,15 @@
>>>>   };
>>>>   &ltdc {
>>>> -    status = "okay";
>>>> -
>>>>       port {
>>>> +        #address-cells = <1>;
>>>> +        #size-cells = <0>;
>>>> +
>>>> +        ltdc_ep0_out: endpoint@0 {
>>>> +            reg = <0>;
>>>> +            remote-endpoint = <&sii9022_in>;
>>>> +        };
>>>> +
>>>>           ltdc_ep1_out: endpoint@1 {
>>>>               reg = <1>;
>>>>               remote-endpoint = <&dsi_in>;
>>>
>>> [...]
>>>
>>>> diff --git a/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi 
>>>> b/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
>>>> index 64dca5b7f748..e7f10975cacf 100644
>>>> --- a/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
>>>> +++ b/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
>>>> @@ -277,11 +277,7 @@
>>>>       status = "okay";
>>>>       port {
>>>> -        #address-cells = <1>;
>>>> -        #size-cells = <0>;
>>>> -
>>>> -        ltdc_ep0_out: endpoint@0 {
>>>> -            reg = <0>;
>>>> +        ltdc_ep0_out: endpoint {
>>>>               remote-endpoint = <&adv7513_in>;
>>>>           };
>>>>       };
>>>
>>> I think this is wrong, the AV96 can have two displays connected to 
>>> two ports of the LTDC, just like DK2 for example.
>>
>> As for dk2 address/size cells are added only if there are 2 endpoints. 
>> It is for this reason I moved endpoint0 definition from 
>> stm32mp15xx-dkx to stm32mp151a-dk1.dts (dk1 has only one endpoint).
>>
>> Here it's the same, if you have second endpoint then adress/size will 
>> have to be added.
> 
> That's a bit problematic. Consider either the use case of DTO which adds 
> the other display, or even a custom board DTS. Without your patch, this 
> works:
> 
> arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
> &ltdc {
>    ...
>    ports {
>      ltdc_ep0_out: endpoint@0 {
>        remote-endpoint = <&adv7513_in>;
>      };
>    };
> };
> 
> board-with-display.dts or board-overlay.dts
> &ltdc {
>    ports {
>      endpoint@1 { // just add another endpoint@1, no problem
>        remote-endpoint = <&display>;
>      };
>    };
> };
> 
> With your patch, the DTS would have to modify the "endpoint" node to be 
> "endpoint@0" probably with a whole lot of /detele-node/ etc. magic (DTO 
> cannot do that, so that's a problem, and I do use DTOs on AV96 
> extensively for the various expansion cards) and then add the 
> endpoint@1. That becomes real complicated in custom board DT, and 
> impossible with DTO.

Yes I agree that it'll be problematic. So maybe so solution would be to 
not detect a warning for the initial case (only one endpoint with a reg)