.../devicetree/bindings/misc/xlnx,axi-fifo-mm-s.yaml | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
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.0On 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.