There's actually a bug above where it returns instead of calling goto.
Instead of calling goto, move dcr_map and friends down as they're used
right after the spinlock in mal_reset.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
 drivers/net/ethernet/ibm/emac/mal.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/ibm/emac/mal.c b/drivers/net/ethernet/ibm/emac/mal.c
index 4f58a38f4b32..e6354843d856 100644
--- a/drivers/net/ethernet/ibm/emac/mal.c
+++ b/drivers/net/ethernet/ibm/emac/mal.c
@@ -553,6 +553,18 @@ static int mal_probe(struct platform_device *ofdev)
 	}
 	mal->num_rx_chans = prop[0];
 
+	if (of_device_is_compatible(ofdev->dev.of_node, "ibm,mcmal-405ez")) {
+#if defined(CONFIG_IBM_EMAC_MAL_CLR_ICINTSTAT) && \
+		defined(CONFIG_IBM_EMAC_MAL_COMMON_ERR)
+		mal->features |= (MAL_FTR_CLEAR_ICINTSTAT |
+				MAL_FTR_COMMON_ERR_INT);
+#else
+		printk(KERN_ERR "%pOF: Support for 405EZ not enabled!\n",
+				ofdev->dev.of_node);
+		return -ENODEV;
+#endif
+	}
+
 	dcr_base = dcr_resource_start(ofdev->dev.of_node, 0);
 	if (dcr_base == 0) {
 		printk(KERN_ERR
@@ -566,18 +578,6 @@ static int mal_probe(struct platform_device *ofdev)
 		return -ENODEV;
 	}
 
-	if (of_device_is_compatible(ofdev->dev.of_node, "ibm,mcmal-405ez")) {
-#if defined(CONFIG_IBM_EMAC_MAL_CLR_ICINTSTAT) && \
-		defined(CONFIG_IBM_EMAC_MAL_COMMON_ERR)
-		mal->features |= (MAL_FTR_CLEAR_ICINTSTAT |
-				MAL_FTR_COMMON_ERR_INT);
-#else
-		printk(KERN_ERR "%pOF: Support for 405EZ not enabled!\n",
-				ofdev->dev.of_node);
-		return -ENODEV;
-#endif
-	}
-
 	INIT_LIST_HEAD(&mal->poll_list);
 	INIT_LIST_HEAD(&mal->list);
 	spin_lock_init(&mal->lock);
-- 
2.46.2

On Wed,  2 Oct 2024 19:11:35 -0700 Rosen Penev wrote:
> There's actually a bug above where it returns instead of calling goto.
> Instead of calling goto, move dcr_map and friends down as they're used
> right after the spinlock in mal_reset.

Not a fix?

On Fri, Oct 4, 2024 at 4:36 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Wed,  2 Oct 2024 19:11:35 -0700 Rosen Penev wrote:
> > There's actually a bug above where it returns instead of calling goto.
> > Instead of calling goto, move dcr_map and friends down as they're used
> > right after the spinlock in mal_reset.
>
> Not a fix?
It's a fix for a prior commit, yes. 6d3ba097ee81d if I'm using git
blame correctly.

On Fri, 4 Oct 2024 16:43:48 -0700 Rosen Penev wrote:
> > On Wed,  2 Oct 2024 19:11:35 -0700 Rosen Penev wrote:  
> > > There's actually a bug above where it returns instead of calling goto.
> > > Instead of calling goto, move dcr_map and friends down as they're used
> > > right after the spinlock in mal_reset.  
> >
> > Not a fix?  
> It's a fix for a prior commit, yes. 6d3ba097ee81d if I'm using git
> blame correctly.

Hm, I don't have this hash in my local tree.
What I'm getting at is that if it's a fix for a patch already in
networking trees the patch needs to have a Fixes tag. And if the 
bug is present in net - the patch needs to go to net rather than
net-next.

On Mon, 7 Oct 2024 07:05:14 -0700 Jakub Kicinski wrote:
> > > Not a fix?    
> > It's a fix for a prior commit, yes. 6d3ba097ee81d if I'm using git
> > blame correctly.  
> 
> Hm, I don't have this hash in my local tree.
> What I'm getting at is that if it's a fix for a patch already in
> networking trees the patch needs to have a Fixes tag. And if the 
> bug is present in net - the patch needs to go to net rather than
> net-next.

Looking closer I think this got added in:
commit 1ff0fcfcb1a6 ("ibm_newemac: Fix new MAL feature handling")
please post the first to net. Then once net gets merged to net-next
(which happens every Thu), you can proceed with the net-next
conversions.