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]
Message-Id: <DIGPLR.WRMNJFUPZ02P3@gmail.com>
Date:   Mon, 21 Nov 2022 19:01:25 +0300
From:   Yassine Oudjana <yassine.oudjana@...il.com>
To:     AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Sean Wang <sean.wang@...nel.org>,
        Andy Teng <andy.teng@...iatek.com>,
        Yassine Oudjana <y.oudjana@...tonmail.com>,
        linux-mediatek@...ts.infradead.org, linux-gpio@...r.kernel.org,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, Rob Herring <robh@...nel.org>
Subject: Re: [PATCH v5 6/7] dt-bindings: pinctrl: mediatek,mt6779-pinctrl:
 Document MT6735 pin controller


On Mon, Nov 21 2022 at 14:48:58 +01:00:00, AngeloGioacchino Del Regno 
<angelogioacchino.delregno@...labora.com> wrote:
> Il 18/11/22 12:30, Yassine Oudjana ha scritto:
>> From: Yassine Oudjana <y.oudjana@...tonmail.com>
>> 
>> Add bindings for the pin controller found on MediaTek MT6735 and
>> MT6735M SoCs, including describing a method to manually specify
>> a pin and function in the pinmux property making defining bindings
>> for each pin/function combination unnecessary. The pin controllers
>> on those SoCs are generally identical, with the only difference
>> being the lack of MSDC2 pins (198-203) on MT6735M.
>> 
>> Signed-off-by: Yassine Oudjana <y.oudjana@...tonmail.com>
>> Reviewed-by: Rob Herring <robh@...nel.org>
>> ---
>>   .../pinctrl/mediatek,mt6779-pinctrl.yaml      | 55 
>> ++++++++++++++++++-
>>   MAINTAINERS                                   |  6 ++
>>   2 files changed, 60 insertions(+), 1 deletion(-)
>> 
> 
> ..snip..
> 
>> @@ -352,18 +391,32 @@ examples:
>>               };
>>                 /* GPIO0 set as multifunction GPIO0 */
>> -            gpio-pins {
>> +            gpio0-pins {
>>                   pins {
>>                       pinmux = <PINMUX_GPIO0__FUNC_GPIO0>;
>>                   };
>>               };
>>   +            /* GPIO1 set to function 0 (GPIO) */
>> +            gpio1-pins {
>> +                pins {
>> +                    pinmux = <(MTK_PIN_NO(1) | 0)>;
> 
> Please follow the same format that you can find in all of the
> mtXXXX-pinfunc.h.
> 
> What you wrote here (MTK_PIN_NO(x) | func) is defined in there for 
> the purpose
> of providing a definition name that actually means something (for 
> both readability
> and documentation purposes).
> 
> This means that your GPIO1 set to function 0 (gpio) should be
> 
> 			pinmux = <PINMUX_GPIO1__FUNC_GPIO1>;
> 
>> +                };
>> +            };
>> +
>>               /* GPIO52 set as multifunction SDA0 */
>>               i2c0-pins {
>>                   pins {
>>                     pinmux = <PINMUX_GPIO52__FUNC_SDA0>;
>>                   };
>>               };
>> +
>> +            /* GPIO62 set to function 1 (primary function) */
>> +            i2c1-pins {
>> +                pins {
>> +                    pinmux = <(MTK_PIN_NO(62) | 1)>;
> 
> pinmux = <PINMUX_GPIO62__FUNC_SDA1>; (is it sda1??)
> 
> This means that you should as well add a mediatek,mt6735-pinfunc.h 
> binding...

This is pretty much what I was trying to avoid by doing this. 
Originally I tried to have something similar to qualcomm pin 
controllers which use "pins" and "function" properties (but probably 
with integer values rather than strings) without making any major 
changes to pinctrl-paris or related DT bindings, but it quickly became 
obvious that it wouldn't be possible when looking at how it does things 
currently. pinctrl-moore was better in this aspect, actually making use 
of pin groups to describe how sets of pins have shared functions 
instead of making a group for each pin, and taking "groups" and 
"function" properties. However, it wasn't fully suitable for the 
hardware so I had to stick with pinctrl-paris. At that point I thought 
of this to be the simplest way of doing it. I think it is unnecessary 
to define every single pin-function combination. Yes, doing it this way 
doesn't make it clear what function is being set right away, but a 
quick look at pinctrl-mtk-mt6735.h is all it takes to find out. 
Furthermore, in most cases functions 0 (GPIO) and 1 (primary, pin named 
after it) are the only ones used so knowing the pin names is all it 
takes to figure out the functions.

With all of that being said however, I guess I don't mind following the 
current convention for the time being. The pinctrl subsystem (not just 
mediatek pin controllers) has some of the most inconsistent DT bindings 
from what I've seen, specifically when it comes to specifying pin 
functions, and I think it will end up having some major cleanup down 
the line anyway.



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ