linux-kernel - Re: [PATCH 2/3] dt-bindings: SPI: Add Ingenic SFC bindings.

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: <aa68546e-09a2-3ed7-d9ed-6566a7c9f997@wanyeetech.com>
Date:   Sun, 24 Jul 2022 22:52:59 +0800
From:   Zhou Yanjie <zhouyanjie@...yeetech.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Mike Yang <reimu@...omaker.com>, tudor.ambarus@...rochip.com,
        p.yadav@...com, michael@...le.cc, miquel.raynal@...tlin.com,
        richard@....at, vigneshr@...com, broonie@...nel.org,
        robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org
Cc:     linux-mtd@...ts.infradead.org, linux-spi@...r.kernel.org,
        linux-mips@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, aidanmacdonald.0x0@...il.com,
        tmn505@...il.com, paul@...pouillou.net, dongsheng.qiu@...enic.com,
        aric.pzqi@...enic.com, rick.tyliu@...enic.com,
        jinghui.liu@...enic.com, sernia.zhou@...mail.com
Subject: Re: [PATCH 2/3] dt-bindings: SPI: Add Ingenic SFC bindings.

Hi Krzysztof, Mike & Mark,

On 2022/7/24 上午4:05, Krzysztof Kozlowski wrote:
> On 23/07/2022 20:47, Mike Yang wrote:
>> On 7/24/22 01:43, Krzysztof Kozlowski wrote:
>>> On 23/07/2022 18:50, Zhou Yanjie wrote:
>>>> Hi Krzysztof,
>>>>
>>>> On 2022/7/23 上午1:46, Krzysztof Kozlowski wrote:
>>>>> On 22/07/2022 18:48, 周琰杰 (Zhou Yanjie) wrote:
>>>>>> Add the SFC bindings for the X1000 SoC, the X1600 SoC, the X1830 SoC,
>>>>>> and the X2000 SoC from Ingenic.
>>>>>>
>>>>>> Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@...yeetech.com>
>>>>>> ---
>>>>>>    .../devicetree/bindings/spi/ingenic,sfc.yaml       | 64 ++++++++++++++++++++++
>>>>>>    1 file changed, 64 insertions(+)
>>>>>>    create mode 100644 Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/spi/ingenic,sfc.yaml b/Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
>>>>>> new file mode 100644
>>>>>> index 00000000..b7c4cf4
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
>>>>>> @@ -0,0 +1,64 @@
>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>>> +%YAML 1.2
>>>>>> +---
>>>>>> +$id: http://devicetree.org/schemas/spi/ingenic,sfc.yaml#
>>>>> File name should be rather based on first compatible, so
>>>>> ingenic,x1000-sfc.yaml
>>>>
>>>> No offense, does it really need to be named that way?
>>>> I can't seem to find documentation with instructions on this :(
>>>>
>>>> The use of "ingenic,sfc.yaml" indicates that this is the documentation
>>>> for the SFC module for all Ingenic SoCs, without misleading people into
>>>> thinking it's only for a specific model of SoC. And there seem to be many
>>>> other yaml documents that use similar names (eg. fsl,spi-fsl-qspi.yaml,
>>>> spi-rockchip.yaml, spi-nxp-fspi.yaml, ingenic,spi.yaml, spi-sifive.yaml,
>>>> omap-spi.yaml), maybe these yaml files that are not named with first
>>>> compatible are also for the same consideration. :)
>>> We have many bad examples, many poor patterns and they are never an
>>> argument to add one more bad pattern.
>> Zhou already mentioned he was unable find the naming guidelines of these .yaml files.
>>
>> Apparently you think it's unacceptable for new contributors of a certain subsystem to use existing code as examples, and/or they're responsible for figuring out what's a good example and what's a bad one in the existing codebase.
> It's everywhere in the kernel, what can I say? If you copy existing
> code, you might copy poor code...
>
>>> It might never grow to new devices (because they might be different), so
>>> that is not really an argument.
>> It is an argument. A very valid one.
>>
>> "they *might* be different". You may want to get your hands on real hardware and try another word. Or at least read the datasheets instead of believing your imagination.
>>
>> I would enjoy duplicating the st,stm32-spi.yaml into st,stm32{f,h}{0..7}-spi.yaml if I'm bored at a Sunday afternoon.
>>
>>> All bindings are to follow this rule, so I don't understand why you
>>> think it is an exception for you?
>> Zhou didn't ask you to make an exception. They have a valid point and they're asking why.
> Hm, everyone has the same valid point and such recommendation is to
> everyone, although it is nothing serious.
>
>> You may want to avoid further incidents of this kind by stop being bossy and actually writing a guideline of naming these .yaml files and publish it somewhere online.
> I did not see any incident here... Process of review includes comments
> and there is nothing bad happening when you receive a comment. No
> incident...


I have no intention of provoking arguments, I just did *grep -rn "first 
compatible"* in the
Documentation folder after you mentioned the naming rules about "first 
compatible" before,
but just found a "first compatible" in "Documentation/fb/sstfb.rst", but 
It has absolutely
nothing to do with file naming. As Mike and Mark said, my question in 
the previous email
was just out of curiosity about where to look for a detailed explanation 
of the rule.
Since it would be somewhat strange to have two "Ingenic" yaml files with 
different naming
rules in the SPI subsystem, maybe Rob can guide us here?


Thanks and best regards!


>
> Best regards,
> Krzysztof