Documentation/devicetree/bindings/misc/xlnx,axi-fifo-mm-s.yaml | 2 -- 1 file changed, 2 deletions(-)
v2: Remove interrupt-parent property declaration as it is a standard
property that does not need to be explicitly defined in the binding.
Signed-off-by: Alexandru Hossu <hossu.alexandru@gmail.com>From 403c6c299c82c39dd09ed9ed75d6750d358e53da Mon Sep 17 00:00:00 2001
From: Alexandru Hossu <hossu.alexandru@gmail.com>
Date: Wed, 4 Mar 2026 13:43:09 +0100
Subject: [PATCH v2] dt-bindings: misc: xlnx,axi-fifo-mm-s: fix
interrupt-parent property
Signed-off-by: Alexandru Hossu <hossu.alexandru@gmail.com>
---
Documentation/devicetree/bindings/misc/xlnx,axi-fifo-mm-s.yaml | 2 --
1 file changed, 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/misc/xlnx,axi-fifo-mm-s.yaml b/Documentation/devicetree/bindings/misc/xlnx,axi-fifo-mm-s.yaml
index 6d1cd651e..a21cae6e6 100644
--- a/Documentation/devicetree/bindings/misc/xlnx,axi-fifo-mm-s.yaml
+++ b/Documentation/devicetree/bindings/misc/xlnx,axi-fifo-mm-s.yaml
@@ -31,7 +31,6 @@ properties:
items:
- const: interrupt
- interrupt-parent: true
xlnx,use-rx-data:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -56,7 +55,6 @@ required:
- reg
- interrupts
- interrupt-names
- - interrupt-parent
- xlnx,use-rx-data
- xlnx,use-tx-data
--
2.43.0
On Wed, Mar 04, 2026 at 01:46:00PM +0100, Alexandru Hossu wrote: > v2: Remove interrupt-parent property declaration as it is a standard > property that does not need to be explicitly defined in the binding. > > Signed-off-by: Alexandru Hossu <hossu.alexandru@gmail.com> Please, wait a day between resends. No need to rush. https://staticthinking.wordpress.com/2022/07/27/how-to-send-a-v2-patch/ regards, dan carpenter
On 04/03/2026 13:46, Alexandru Hossu wrote: > v2: Remove interrupt-parent property declaration as it is a standard > property that does not need to be explicitly defined in the binding. > > Signed-off-by: Alexandru Hossu <hossu.alexandru@gmail.com> Stop and read the feedback. There is still no patch! Best regards, Krzysztof
On 04/03/2026 13:51, Krzysztof Kozlowski wrote: > On 04/03/2026 13:46, Alexandru Hossu wrote: >> v2: Remove interrupt-parent property declaration as it is a standard >> property that does not need to be explicitly defined in the binding. >> >> Signed-off-by: Alexandru Hossu <hossu.alexandru@gmail.com> > > > Stop and read the feedback. > > There is still no patch! Look here: https://lore.kernel.org/lkml/fbb68131-03ab-460b-8d11-e4892d91807f@gmail.com/ No patch inline, just separate attachment. That's not something possible to review. And another point is: Do not attach (thread) your patchsets to some other threads (unrelated or older versions). This buries them deep in the mailbox and might interfere with applying entire sets. See also: https://elixir.bootlin.com/linux/v6.16-rc2/source/Documentation/process/submitting-patches.rst#L830 Best regards, Krzysztof
I apologize for not responding to your emails. I was focused on fixing the issues and kept resubmitting instead of replying first. I understand now that I should have acknowledged your feedback before sending new versions. I will resubmit properly with a full changelog once I have fixed all issues. Thank you for your patience. Alexandru
Signed-off-by: Alexandru Hossu <hossu.alexandru@gmail.com>
---
.../devicetree/bindings/misc/xlnx,axi-fifo-mm-s.yaml | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/misc/xlnx,axi-fifo-mm-s.yaml b/Documentation/devicetree/bindings/misc/xlnx,axi-fifo-mm-s.yaml
index 6d1cd651e..cdc295f2d 100644
--- a/Documentation/devicetree/bindings/misc/xlnx,axi-fifo-mm-s.yaml
+++ b/Documentation/devicetree/bindings/misc/xlnx,axi-fifo-mm-s.yaml
@@ -31,8 +31,6 @@ properties:
items:
- const: interrupt
- interrupt-parent: true
-
xlnx,use-rx-data:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1]
@@ -56,7 +54,6 @@ required:
- reg
- interrupts
- interrupt-names
- - interrupt-parent
- xlnx,use-rx-data
- xlnx,use-tx-data
@@ -64,11 +61,16 @@ additionalProperties: true
examples:
- |
+ intc: interrupt-controller {
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+
axi_fifo_mm_s_0: axi_fifo_mm_s@43c00000 {
compatible = "xlnx,axi-fifo-mm-s-4.1";
interrupt-names = "interrupt";
interrupt-parent = <&intc>;
- interrupts = <0 29 4>;
+ interrupts = <29>;
reg = <0x43c00000 0x10000>;
xlnx,use-rx-data = <0x0>;
xlnx,use-tx-data = <0x1>;
--
2.43.0
On 04/03/2026 14:16, Alexandru Hossu wrote: > Signed-off-by: Alexandru Hossu <hossu.alexandru@gmail.com> > --- NAK, I replied way too many times. Best regards, Krzysztof
On Wed, Mar 04, 2026 at 02:16:10PM +0100, Alexandru Hossu wrote: > Signed-off-by: Alexandru Hossu <hossu.alexandru@gmail.com> For obvious reasons, we can't take patches without any changelog text, nor would you want us to. thanks, greg k-h
On 4 March 2026 13:22:48 GMT, Greg KH <gregkh@linuxfoundation.org> wrote: >On Wed, Mar 04, 2026 at 02:16:10PM +0100, Alexandru Hossu wrote: >> Signed-off-by: Alexandru Hossu <hossu.alexandru@gmail.com> > >For obvious reasons, we can't take patches without any changelog text, >nor would you want us to. This is also a second person working on this conversation. I left commentary on the other version of it. I am fairly confident that converting this binding is almost useless without evaluating whether this should become a dma engine. I'm almost certain my employer has something very similar, based on naming and use case, and I saw no reason why it could not be a dma engine. Any as-is conversation of this should, IMO, come with an evaluation of why this is the correct way to model it. I don't think it's suitable for any sort of "internship" program that sees binding conversations as low hanging fruit.
On 04/03/2026 14:29, Conor Dooley wrote: > > > On 4 March 2026 13:22:48 GMT, Greg KH <gregkh@linuxfoundation.org> wrote: >> On Wed, Mar 04, 2026 at 02:16:10PM +0100, Alexandru Hossu wrote: >>> Signed-off-by: Alexandru Hossu <hossu.alexandru@gmail.com> >> >> For obvious reasons, we can't take patches without any changelog text, >> nor would you want us to. > > This is also a second person working on this conversation. I see, so that's a patch for something which does not exist yet (not merged). > I left commentary on the other version of it. > I am fairly confident that converting this binding is almost useless without evaluating whether this should become a dma engine. > I'm almost certain my employer has something very similar, based on naming and use case, and I saw no reason why it could not be a dma engine. > Any as-is conversation of this should, IMO, come with an evaluation of why this is the correct way to model it. > I don't think it's suitable for any sort of "internship" program that sees binding conversations as low hanging fruit. Do you suspect another round of some GSoC or LFX mentorship? Best regards, Krzysztof
On Wed, Mar 04, 2026 at 03:08:46PM +0100, Krzysztof Kozlowski wrote: > On 04/03/2026 14:29, Conor Dooley wrote: > > > > > > On 4 March 2026 13:22:48 GMT, Greg KH <gregkh@linuxfoundation.org> wrote: > >> On Wed, Mar 04, 2026 at 02:16:10PM +0100, Alexandru Hossu wrote: > >>> Signed-off-by: Alexandru Hossu <hossu.alexandru@gmail.com> > >> > >> For obvious reasons, we can't take patches without any changelog text, > >> nor would you want us to. > > > > This is also a second person working on this conversation. > > I see, so that's a patch for something which does not exist yet (not > merged). This is the usual "two people working independently", except Alexandru's "v2" is actually not a v2 but rather a patch on top of his own v1. Ditto with his v3. It's not a patch on top of the other guy. > > > I left commentary on the other version of it. > > I am fairly confident that converting this binding is almost useless without evaluating whether this should become a dma engine. > > I'm almost certain my employer has something very similar, based on naming and use case, and I saw no reason why it could not be a dma engine. > > Any as-is conversation of this should, IMO, come with an evaluation of why this is the correct way to model it. > > I don't think it's suitable for any sort of "internship" program that sees binding conversations as low hanging fruit. Whoops, my bad on the long lines, sent it from my phone.. > Do you suspect another round of some GSoC or LFX mentorship? Yeah, that is my suspicion. Lucas (the other submitter) also displayed lack of familiarity with the process, but that may just be happenstance. Plenty of binding conversions I am sure are suitable for some sort of "internship", but probably not ones in staging, since they probably need to come with an evaluation of whether things are currently correct and maybe with driver changes that really require having the hardware. This is probably one of the few cases where what's in staging is a bad candidate to work on, and things outside of staging that have a fixed ABI are much easier to convert. If this is some sort of "internship", probably the guidance on what to do should not include binding conversions without oversight from the mentor.
© 2016 - 2026 Red Hat, Inc.