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

Zhou Yanjie <zhouyanjie@xxxxxxxxxxxxxx> · Sun, 24 Jul 2022 22:52:59 +0800

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@xxxxxxxxxxxxxx>
---
   .../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






