On 21/09/2022 10:23, Pandey, Radhey Shyam wrote: >>> required: >>> - compatible >>> - interrupts >>> - reg >>> - xlnx,rxmem >>> - phy-handle >>> + - dmas >>> + - dma-names >>> >>> additionalProperties: false >>> >>> @@ -132,11 +137,13 @@ examples: >>> axi_ethernet_eth: ethernet@40c00000 { >>> compatible = "xlnx,axi-ethernet-1.00.a"; >>> interrupt-parent = <µblaze_0_axi_intc>; >>> - interrupts = <2>, <0>, <1>; >>> + interrupts = <1>; >> >> This looks like an ABI break. How do you handle old DTS? Oh wait... you do >> not handle it at all. > > Yes, this is anticipated ABI break due to major changes in axiethernet > driver while adopting to dmaengine framework. Same is highlighted > in commit description - "DT changes are not backward compatible > due to major driver restructuring/cleanup done in adopting the > dmaengine framework". > > Some background - Factor out AXI DMA code into separate driver was > a TODO item (mentioned in driver changelog) and is being done as > part of this series. The DMA code is removed from axiethernet driver > and ethernet driver now make use of dmaengine framework to > communicate with AXIDMA IP. > > When DMA code is removed from axiethernet driver there is limitation > to support legacy DMA resources binding. One option is to inform > user to switch to new binding when old DTS is detected? (and at some > point we have to make this transition and remove dma code). If you keep ABI non-broken, such message is a good idea. > Please let us know if there are any other alternative to consider? You just cannot break ABI just because you want to refactor some code in driver. Best regards, Krzysztof