linux-kernel - Re: [PATCH v2 1/2] spi: dt-bindings: amlogic, meson-gx-spicc: Add pinctrl names for SPI signal states

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: <83649505-d8eb-b0b5-da9d-4536f58a7daa@linaro.org>
Date:   Fri, 7 Oct 2022 09:04:24 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     neil.armstrong@...aro.org,
        Amjad Ouled-Ameur <aouledameur@...libre.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        Kevin Hilman <khilman@...libre.com>,
        Jerome Brunet <jbrunet@...libre.com>,
        Mark Brown <broonie@...nel.org>
Cc:     Da Xue <da@...re.computer>, linux-kernel@...r.kernel.org,
        linux-spi@...r.kernel.org, linux-amlogic@...ts.infradead.org,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 1/2] spi: dt-bindings: amlogic, meson-gx-spicc: Add
 pinctrl names for SPI signal states

On 06/10/2022 17:48, Neil Armstrong wrote:
> On 06/10/2022 16:11, Krzysztof Kozlowski wrote:
>> On 06/10/2022 12:57, Amjad Ouled-Ameur wrote:
>>> Hi Krzysztof,
>>>
>>> Thank you for the review.
>>>
>>> On 10/5/22 10:14, Krzysztof Kozlowski wrote:
>>>> On 04/10/2022 13:10, Amjad Ouled-Ameur wrote:
>>>>> SPI pins of the SPICC Controller in Meson-GX needs to be controlled by
>>>>> pin biais when idle. Therefore define three pinctrl names:
>>>>> - default: SPI pins are controlled by spi function.
>>>>> - idle-high: SCLK pin is pulled-up, but MOSI/MISO are still controlled
>>>>> by spi function.
>>>>> - idle-low: SCLK pin is pulled-down, but MOSI/MISO are still controlled
>>>>> by spi function.
>>>>>
>>>>> Reported-by: Da Xue <da@...re.computer>
>>>>> Signed-off-by: Neil Armstrong <narmstrong@...libre.com>
>>>>> Signed-off-by: Amjad Ouled-Ameur <aouledameur@...libre.com>
>>>>> ---
>>>>>    .../devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml   | 15 +++++++++++++++
>>>>>    1 file changed, 15 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml b/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml
>>>>> index 0c10f7678178..53013e27f507 100644
>>>>> --- a/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml
>>>>> +++ b/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml
>>>>> @@ -43,6 +43,14 @@ properties:
>>>>>        minItems: 1
>>>>>        maxItems: 2
>>>>>    
>>>>> +  pinctrl-0:
>>>>> +    minItems: 1
>>>> maxItems?
>>>>
>>> Will fill it in next version.
>>>>> +
>>>>> +  pinctrl-1:
>>>>> +    maxItems: 1
>>>>> +
>>>>> +  pinctrl-names: true
>>>> Why do you need all these in the bindings?
>>>
>>> SPI clock bias needs to change at runtime depending on SPI mode, here is an example of
>>>
>>> how this is supposed to be used ("spi_idle_low_pins" and "spi_idle_low_pins" are defined
>>>
>>> in the second patch of this series):
>>
>> I know what it the point in general of pinctrl configuration... But the
>> question is why do you need to specify them in the bindings? Core
>> handles that. IOW, do you require them and missing/incomplete pinctrl
>> should be reported?
> 
> Looking at other bindings, when specific pinctrl state names were requires, they were
> documented.

Yes, the required and/or necessary entries were added to few other
bindings. Since Amjad did not make them required, why adding them? So I
repeat the question for the third time - why do you need to add them to
the bindings?

> There's some bindings with pinctrl-names for specific states like rockchip/rockchip,dw-hdmi.yaml,
> mediatek/mediatek,dpi.yaml, mmc/mtk-sd.yaml or mmc/fsl-imx-esdhc.yaml

And? Just because someone did something is not itself an argument. They
might have their reasons. If their reasons are applicable here, please
state them.

Best regards,
Krzysztof