On Wed, Apr 10, 2024 at 08:47:00AM +0200, Krzysztof Kozlowski wrote: > 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. I understand what's your concern. I just said I run dt_binding_check before submit patch. Never said I will not take time to inversitage it. Actually I found the problem yesterday and will fix next version. I also find what's wrong why success in my side. I also read many of your email about other thread in dt-binding. Most is the similar question. The words in your all email "It does not look like you tested the bindings" is most frequency words regardless from nxp.com or NOT. Yaml file look like as document, but actually NOT. Unlike C code, which can compile and running. And more people get well trainning at debug C driver. Actually it takes more time handle binding yaml doc than debug driver code. Some item is actually quite difficult to understand without deep into json scheme. It is not simple as what look like. It may cause many low level error because it it not simple as what look like and even hard. The whole reviewer team take great efforts to make dt-binding better. I think it should stop complain and start improve tools. For example: I try to add --check in b4. https://lore.kernel.org/tools/20240319045332.2304950-1-Frank.Li@xxxxxxx/T/#t Some self-auto-bot help filter low lever problem. And from another point, it means more and more NXP engineer want to take more time and efforts to do upstream works. > > 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. Some background is difference. There are many argument spaces at some side. 'minimal effort' is not exist. I bet the email reply to community is 10x carefull more than other internal email. > > 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. My intention "strange, test pass" just said my suprised "why it success in my side" and "will check tools and my environment", Not "skip run dt-binding" before submit. But what your understand is , "my comment is wrong, and you stop inverstiage it and close this topic". > > 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. Many time, I want to help filter out some low level problem for nxp patche. A long-term illness makes a good doctor. Your team work are too efficency. before I can do anything, you already provide professional feedback. > > 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. If you can help do trainning for us, weclome!! > > Till the situation improves, I will be ignoring all patches from @nxp.com. > > Best regards, > Krzysztof >
