On 17/06/2023 01:18, Jassi Brar wrote: > On Fri, 16 Jun 2023 at 15:34, Krzysztof Kozlowski > <krzysztof.kozlowski@xxxxxxxxxx> wrote: >> >> On 16/06/2023 22:06, Jassi Brar wrote: >>> On Fri, 16 Jun 2023 at 11:47, Krzysztof Kozlowski >>> <krzysztof.kozlowski@xxxxxxxxxx> wrote: >>>> >>>> On 16/06/2023 18:23, Jassi Brar wrote: >>>>> On Fri, 16 Jun 2023 at 05:15, Krzysztof Kozlowski >>>>> <krzysztof.kozlowski@xxxxxxxxxx> wrote: >>>>>> >>>>>> On 16/06/2023 05:58, jaswinder.singh@xxxxxxxxxx wrote: >>>>>>> From: Jassi Brar <jaswinder.singh@xxxxxxxxxx> >>>>>>> >>>>>>> Socionext's DeveloperBox is based on the SC2A11B SoC (Synquacer). >>>>>>> Specify bindings for the platform and boards based on that. >>>>>> >>>>>> A nit, subject: drop second/last, redundant "bindings". The >>>>>> "dt-bindings" prefix is already stating that these are bindings. >>>>>> >>>>> I can remove it, but I see many mentions like "Fix bindings for" "Add >>>>> binding for" etc in the subject line. >>>> >>>> Can we fix them as well? >>>> >>> ?? >> What else I can say to such argument? >> > It was not an argument, I agreed to remove it. I just observed that > the nit-pick was arbitrary. > And frankly > "dt-bindings: arm: socionext: add Synquacer" is as misleading as > "dt-bindings: arm: socionext: add bindings for the Synquacer" is improper. "add Synquacer boards" it is both precise and correct. No misleading. > > >>>>>> >>>>>> Binding without it's user is usually useless. Where is the user? >>>>>> >>>>> It is required for SystemReady-2.0 certification. >>>> >>>> For what? If there is no user, it is not required for SR. We don't >>>> document compatibles for something which does not exist in the projects. >>>> >>> The dts/dtsi for synquacer will be added later. >>> I am sure you are aware that there are countless bindings without >>> actual use in any dts/dtsi. >> >> Bindings without user (so no DTSI and no driver)? Just few, not countless. >> > I disagree. But I don't have time to write a script to find > compatibles/enums and properties in yaml/txt files that are not in any > dts/dtsi file. > By that logic synquacer's spi/netsec/i2c/exiu bindings and drivers in > kernel are illegit too? Don't know which one you talk about. > > Also the user may not be in Linux, but we keep "os-agnostic" bindings in Linux. I did not say anything about Linux here. Look: "does not exist in the projects." > The synquacer dts/dtsi are in u-boot upstream. SR testsuite looks up Sure, can you point it? U-Boot upstream is a valid project. Just like many other upstream ones. > the underlying platform name and checks if the bindings are merged > upstream. > While I am not against also submitting dts/dtsi in linux, I don't > think the binding should be held at ransom. > >>> When exactly did it become mandatory to >>> have dts/dtsi for the bindings to be merged upstream? >> >> It was always. We do not want/need to document downstream stuff or >> anything just because it is somewhere there. >> > I am not asking you to merge an obscure internal revision of some SoC. > Synquacer is a public development platform and a "96board" already > certified for SR-1.0. Without any reference to any project using this, it looks like you are. Sorry. Best regards, Krzysztof
