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
