Re: [PATCH v3 1/2] dt-bindings: dma: fsl-edma: remove 'clocks' from required

[Krzysztof Kozlowski]

On 10/04/2024 08:32, Krzysztof Kozlowski wrote:
> On 10/04/2024 08:30, Krzysztof Kozlowski wrote:
>> On 09/04/2024 23:09, Frank Li wrote:
>>> On Tue, Apr 09, 2024 at 10:02:32PM +0200, Krzysztof Kozlowski wrote:
>>>> On 09/04/2024 20:54, Frank Li wrote:
>>>>> fsl,imx8qm-adma and fsl,imx8qm-edma don't require 'clocks'. Remove it from
>>>>> required and add 'if' block for other compatible string to keep the same
>>>>> restrictions.
>>>>>
>>>>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>
>>>>> Signed-off-by: Frank Li <Frank.Li@xxxxxxx>
>>>>> ---
>>>>>
>>>>> Notes:
>>>>>     Change from v2 to v3
>>>>>       - rebase to dmaengine/next
>>>>
>>>> This fails...
>>>
>>> What's wrong? 
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git/log/?h=next
>>>
>>>>
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/dma/fsl,edma.yaml b/Documentation/devicetree/bindings/dma/fsl,edma.yaml
>>>>> index 825f4715499e5..657a7d3ebf857 100644
>>>>> --- a/Documentation/devicetree/bindings/dma/fsl,edma.yaml
>>>>> +++ b/Documentation/devicetree/bindings/dma/fsl,edma.yaml
>>>>> @@ -82,7 +82,6 @@ required:
>>>>>    - compatible
>>>>>    - reg
>>>>>    - interrupts
>>>>> -  - clocks
>>>>>    - dma-channels
>>>>>  
>>>>>  allOf:
>>>>> @@ -187,6 +186,22 @@ allOf:
>>>>>          "#dma-cells":
>>>>>            const: 3
>>>>>  
>>>>> +  - if:
>>>>> +      properties:
>>>>> +        compatible:
>>>>> +	  contains:
>>>>
>>>> It does not look like you tested the bindings, at least after quick
>>>> look. Please run `make dt_binding_check` (see
>>>> Documentation/devicetree/bindings/writing-schema.rst for instructions).
>>>> Maybe you need to update your dtschema and yamllint.
>>>
>>> Strange, Test passed
>>>
>>> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8  dt_binding_check DT_SCHEMA_FILES=fsl,edma.yaml
>>>   LINT    Documentation/devicetree/bindings
>>>   DTEX    Documentation/devicetree/bindings/dma/fsl,edma.example.dts
>>>   CHKDT   Documentation/devicetree/bindings/processed-schema.json
>>>   SCHEMA  Documentation/devicetree/bindings/processed-schema.json
>>>   DTC_CHK Documentation/devicetree/bindings/dma/fsl,edma.example.dtb
>>
>> Nope, you tested other patch. Just look at your second patch for this.
>> When reviewer points to errors to your code, please investigate?
>>
>> NAK, fix your patches.
> 
> And to prove it, so you will stop wasting my time:
> ../Documentation/devicetree/bindings/dma/fsl,edma.yaml:192:1: found
> character that cannot start any token
> 
> ../Documentation/devicetree/bindings/dma/fsl,edma.yaml:192:1: [error]
> syntax error: found character '\t' that cannot start any token (syntax)
> 
> ../Documentation/devicetree/bindings/dma/fsl,edma.yaml:192:1: found
> character that cannot start any token
> 
> Documentation/devicetree/bindings/dma/fsl,edma.yaml: ignoring, error
> parsing file

Dear NXP,

Quality of patches from NXP is terrible. Several of them are poorly
coded, not following coding style, their submission is not following the
process and requires a lot of effort from reviewers. I was already
complaining about this on mailing lists months ago.

Things did not improve much.

However another trouble is the quality of responses during review. In
many patchsets your responses to reviewers comments were half-baked, not
on actual topic or just with minimal effort to close the topic from your
side. That's not how it works.

If you receive comment, you must investigate. Don't respond immediately
"no, I don't see error" or "but I want something else", but be sure that
you fixed the problem.

Such responses of minimal effort or pushing your own patch is
significant effort on reviewers side. I was complaining about this as
well. This patch here, which does not even build/test yet you claim in
response that you test, is perfect example of it. You got comment from
reviewer and instead really investigating this, you respond that
everything is good on your side. Typical response with minimal effort on
your side, but pushing it to the community.

That's it, that's too much.

NXP, your contributions are poor quality and put too much effort on
community.

Please improve your process, e.g. by training people interacting with
community and using extensive internal review. You can also reach to
experienced community members for help in training and explaining
upstream work, like Denx, Pengutronix, Bootlin, Linaro, Baylibre,
Collabora and others.

Till the situation improves, I will be ignoring all patches from @nxp.com.

Best regards,
Krzysztof