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:   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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ