From: Rob Herring <robh@kernel.org> To: Mike Yang <reimu@sudomaker.com> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>, Mark Brown <broonie@kernel.org>, Zhou Yanjie <zhouyanjie@wanyeetech.com>, tudor.ambarus@microchip.com, p.yadav@ti.com, michael@walle.cc, miquel.raynal@bootlin.com, richard@nod.at, vigneshr@ti.com, krzysztof.kozlowski+dt@linaro.org, linux-mtd@lists.infradead.org, linux-spi@vger.kernel.org, linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, aidanmacdonald.0x0@gmail.com, tmn505@gmail.com, paul@crapouillou.net, dongsheng.qiu@ingenic.com, aric.pzqi@ingenic.com, rick.tyliu@ingenic.com, jinghui.liu@ingenic.com, sernia.zhou@foxmail.com Subject: Re: [PATCH 2/3] dt-bindings: SPI: Add Ingenic SFC bindings. Date: Mon, 25 Jul 2022 12:30:52 -0600 [thread overview] Message-ID: <20220725183052.GA2392099-robh@kernel.org> (raw) In-Reply-To: <b52a8e97-3b8e-c67b-4440-2d7428edb4fa@sudomaker.com> On Sun, Jul 24, 2022 at 04:49:25AM +0800, Mike Yang wrote: > On 7/24/22 04:07, Krzysztof Kozlowski wrote: > > On 23/07/2022 21:27, Mark Brown wrote: > >> On Sun, Jul 24, 2022 at 02:47:14AM +0800, Mike Yang wrote: > >>> On 7/24/22 01:43, Krzysztof Kozlowski wrote: > >>>> On 23/07/2022 18:50, Zhou Yanjie wrote: > >> > >>>>> No offense, does it really need to be named that way? > >>>>> I can't seem to find documentation with instructions on this :( > >> > >> ... > >> > >>>> 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. > >> > >>> 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 don't like your tone. Patches are welcome to fix deficiencies in documentation. Out of the hundreds of bindings a year, I see <5 documentation patches a year. The documentation clearly says to run 'make dt_binding_check' and that was obviously not followed here. > >> Yeah, I do have to say that I was also completely unaware that > >> there was any enforced convention here. > > > > Indeed, it's not a enforced pattern. But there are many other > > insignificant ones which we also tend to forget during review, like > > using words "Device Tree bindings" in title or using unnecessary quotes > > around "refs" (also in ID of schema). It's not a big deal, but I ask > > when I notice it. > > Good. Thanks for paying attention to these details. > > > >> 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. Please wrap your lines on replies. > > > > It's everywhere in the kernel, what can I say? If you copy existing > > code, you might copy poor code... > > Still, it shouldn't be a responsibility of new contributors to > determine the quality of an existing piece of code, unless there are > clear guidelines (i.e. one should use the new "cs-gpios" attribute in SPI controllers). Generally the guidance is to look at newer drivers for current best practices. > >>> 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... > > > Okay. After careful inspection of the Ingenic datasheets, now I have > the conclusion: The Ingenic X1000, X1021, X1500, X1501, X1520, X1600, > X1800, X1830, X2000, X2100, X2500 have the same SFC controller. So if they are all 'the same', then I expect they all have a fallback compatible with x1000 and using that for the filename makes sense. > X1600 has a newer version (let's say v2) of the SFC, and X2000-2500 > have v3. Others have the original version (let's say v1). Each new > version introduced new features such as arbitrary DMA sizes, and the > rest features are the same. So backwards compatible? If so, then they should have x1000 for fallback. > > So IMO the name "ingenic,sfc.yaml" is perfectly logical. Covering all 3 versions? If so and not backwards compatible, then I would agree. Rob
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org> To: Mike Yang <reimu@sudomaker.com> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>, Mark Brown <broonie@kernel.org>, Zhou Yanjie <zhouyanjie@wanyeetech.com>, tudor.ambarus@microchip.com, p.yadav@ti.com, michael@walle.cc, miquel.raynal@bootlin.com, richard@nod.at, vigneshr@ti.com, krzysztof.kozlowski+dt@linaro.org, linux-mtd@lists.infradead.org, linux-spi@vger.kernel.org, linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, aidanmacdonald.0x0@gmail.com, tmn505@gmail.com, paul@crapouillou.net, dongsheng.qiu@ingenic.com, aric.pzqi@ingenic.com, rick.tyliu@ingenic.com, jinghui.liu@ingenic.com, sernia.zhou@foxmail.com Subject: Re: [PATCH 2/3] dt-bindings: SPI: Add Ingenic SFC bindings. Date: Mon, 25 Jul 2022 12:30:52 -0600 [thread overview] Message-ID: <20220725183052.GA2392099-robh@kernel.org> (raw) In-Reply-To: <b52a8e97-3b8e-c67b-4440-2d7428edb4fa@sudomaker.com> On Sun, Jul 24, 2022 at 04:49:25AM +0800, Mike Yang wrote: > On 7/24/22 04:07, Krzysztof Kozlowski wrote: > > On 23/07/2022 21:27, Mark Brown wrote: > >> On Sun, Jul 24, 2022 at 02:47:14AM +0800, Mike Yang wrote: > >>> On 7/24/22 01:43, Krzysztof Kozlowski wrote: > >>>> On 23/07/2022 18:50, Zhou Yanjie wrote: > >> > >>>>> No offense, does it really need to be named that way? > >>>>> I can't seem to find documentation with instructions on this :( > >> > >> ... > >> > >>>> 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. > >> > >>> 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 don't like your tone. Patches are welcome to fix deficiencies in documentation. Out of the hundreds of bindings a year, I see <5 documentation patches a year. The documentation clearly says to run 'make dt_binding_check' and that was obviously not followed here. > >> Yeah, I do have to say that I was also completely unaware that > >> there was any enforced convention here. > > > > Indeed, it's not a enforced pattern. But there are many other > > insignificant ones which we also tend to forget during review, like > > using words "Device Tree bindings" in title or using unnecessary quotes > > around "refs" (also in ID of schema). It's not a big deal, but I ask > > when I notice it. > > Good. Thanks for paying attention to these details. > > > >> 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. Please wrap your lines on replies. > > > > It's everywhere in the kernel, what can I say? If you copy existing > > code, you might copy poor code... > > Still, it shouldn't be a responsibility of new contributors to > determine the quality of an existing piece of code, unless there are > clear guidelines (i.e. one should use the new "cs-gpios" attribute in SPI controllers). Generally the guidance is to look at newer drivers for current best practices. > >>> 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... > > > Okay. After careful inspection of the Ingenic datasheets, now I have > the conclusion: The Ingenic X1000, X1021, X1500, X1501, X1520, X1600, > X1800, X1830, X2000, X2100, X2500 have the same SFC controller. So if they are all 'the same', then I expect they all have a fallback compatible with x1000 and using that for the filename makes sense. > X1600 has a newer version (let's say v2) of the SFC, and X2000-2500 > have v3. Others have the original version (let's say v1). Each new > version introduced new features such as arbitrary DMA sizes, and the > rest features are the same. So backwards compatible? If so, then they should have x1000 for fallback. > > So IMO the name "ingenic,sfc.yaml" is perfectly logical. Covering all 3 versions? If so and not backwards compatible, then I would agree. Rob ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2022-07-25 18:31 UTC|newest] Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-07-22 16:48 [PATCH 0/3] Add SFC support for Ingenic SoCs 周琰杰 (Zhou Yanjie) 2022-07-22 16:48 ` 周琰杰 (Zhou Yanjie) 2022-07-22 16:48 ` [PATCH 1/3] mtd: spi-nor: Use the spi-mem poll status APIs 周琰杰 (Zhou Yanjie) 2022-07-22 16:48 ` 周琰杰 (Zhou Yanjie) 2022-07-23 8:30 ` Sergey Shtylyov 2022-07-23 8:30 ` Sergey Shtylyov 2022-07-22 16:48 ` [PATCH 2/3] dt-bindings: SPI: Add Ingenic SFC bindings 周琰杰 (Zhou Yanjie) 2022-07-22 16:48 ` 周琰杰 (Zhou Yanjie) 2022-07-22 17:46 ` Krzysztof Kozlowski 2022-07-22 17:46 ` Krzysztof Kozlowski 2022-07-23 16:50 ` Zhou Yanjie 2022-07-23 16:50 ` Zhou Yanjie 2022-07-23 17:43 ` Krzysztof Kozlowski 2022-07-23 17:43 ` Krzysztof Kozlowski 2022-07-23 18:47 ` Mike Yang 2022-07-23 18:47 ` Mike Yang 2022-07-23 19:27 ` Mark Brown 2022-07-23 19:27 ` Mark Brown 2022-07-23 20:07 ` Krzysztof Kozlowski 2022-07-23 20:07 ` Krzysztof Kozlowski 2022-07-23 20:49 ` Mike Yang 2022-07-23 20:49 ` Mike Yang 2022-07-24 15:33 ` Zhou Yanjie 2022-07-24 15:33 ` Zhou Yanjie 2022-07-25 18:30 ` Rob Herring [this message] 2022-07-25 18:30 ` Rob Herring 2022-07-23 20:05 ` Krzysztof Kozlowski 2022-07-23 20:05 ` Krzysztof Kozlowski 2022-07-24 14:52 ` Zhou Yanjie 2022-07-24 14:52 ` Zhou Yanjie 2022-07-22 22:44 ` Rob Herring 2022-07-22 22:44 ` Rob Herring 2022-07-22 16:48 ` [PATCH 3/3] SPI: Ingenic: Add SFC support for Ingenic SoCs 周琰杰 (Zhou Yanjie) 2022-07-22 16:48 ` 周琰杰 (Zhou Yanjie) 2022-07-22 18:07 ` Krzysztof Kozlowski 2022-07-22 18:07 ` Krzysztof Kozlowski 2022-07-23 16:53 ` Zhou Yanjie 2022-07-23 16:53 ` Zhou Yanjie 2022-07-22 18:38 ` Mark Brown 2022-07-22 18:38 ` Mark Brown 2022-07-23 17:06 ` Zhou Yanjie 2022-07-23 17:06 ` Zhou Yanjie 2022-07-23 19:32 ` Mark Brown 2022-07-23 19:32 ` Mark Brown 2022-07-24 1:24 ` Zhou Yanjie 2022-07-24 1:24 ` Zhou Yanjie 2022-07-22 20:03 ` Paul Cercueil 2022-07-22 20:03 ` Paul Cercueil 2022-07-23 17:26 ` Zhou Yanjie 2022-07-23 17:26 ` Zhou Yanjie 2022-07-23 20:24 ` Paul Cercueil 2022-07-23 20:24 ` Paul Cercueil 2022-07-24 15:29 ` Zhou Yanjie 2022-07-24 15:29 ` Zhou Yanjie 2022-07-23 15:15 ` Christophe JAILLET 2022-07-23 15:15 ` Christophe JAILLET 2022-07-23 15:15 ` Christophe JAILLET 2022-07-24 1:22 ` Zhou Yanjie 2022-07-24 1:22 ` Zhou Yanjie 2022-07-24 0:43 ` kernel test robot 2022-07-24 0:43 ` kernel test robot 2022-07-24 1:28 ` Vanessa Page 2022-07-24 1:28 ` Vanessa Page 2022-07-25 16:58 ` Vanessa Page 2022-07-23 14:47 ` [PATCH 0/3] " Tomasz Maciej Nowak 2022-07-23 14:47 ` Tomasz Maciej Nowak 2022-07-24 1:25 ` Zhou Yanjie 2022-07-24 1:25 ` Zhou Yanjie 2022-07-24 1:28 ` Vanessa Page 2022-07-24 1:28 ` Vanessa Page 2022-07-24 1:28 ` Vanessa Page 2022-07-24 1:28 ` Vanessa Page 2022-07-24 1:30 ` Vanessa Page 2022-07-24 1:30 ` Vanessa Page 2022-07-24 1:32 ` Vee Page 2022-07-24 1:32 ` Vee Page 2022-07-26 6:13 ` Vee Page 2022-07-26 6:13 ` Vee Page
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20220725183052.GA2392099-robh@kernel.org \ --to=robh@kernel.org \ --cc=aidanmacdonald.0x0@gmail.com \ --cc=aric.pzqi@ingenic.com \ --cc=broonie@kernel.org \ --cc=devicetree@vger.kernel.org \ --cc=dongsheng.qiu@ingenic.com \ --cc=jinghui.liu@ingenic.com \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=krzysztof.kozlowski@linaro.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mips@vger.kernel.org \ --cc=linux-mtd@lists.infradead.org \ --cc=linux-spi@vger.kernel.org \ --cc=michael@walle.cc \ --cc=miquel.raynal@bootlin.com \ --cc=p.yadav@ti.com \ --cc=paul@crapouillou.net \ --cc=reimu@sudomaker.com \ --cc=richard@nod.at \ --cc=rick.tyliu@ingenic.com \ --cc=sernia.zhou@foxmail.com \ --cc=tmn505@gmail.com \ --cc=tudor.ambarus@microchip.com \ --cc=vigneshr@ti.com \ --cc=zhouyanjie@wanyeetech.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.