[PATCH 5.10] rt: Fix buid issue in be2net

[PATCH 5.10] rt: Fix buid issue in be2net

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]

The problem described here is specific to v5.10-rt.

The function be_cmd_unlock() includes the line:

    return spin_unlock_bh(...);

In 5.10-rt, with CONFIG_PREEMPT_RT enabled, spin_unlock_bh() is a
macro that doesn't expand to a valid expression, so this fails to
compile.

A similar issue was recently fixed in at_hdmac.  Do the same thing
here: make the spin_unlock_bh() and return 2 separate statements.

Signed-off-by: Ben Hutchings <benh@debian.org>
---
 drivers/net/ethernet/emulex/benet/be_cmds.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c b/drivers/net/ethernet/emulex/benet/be_cmds.c
index 9812a9a5d033..b3540b3d2862 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -875,10 +875,12 @@ static int be_cmd_lock(struct be_adapter *adapter)
 /* Must be used only in process context */
 static void be_cmd_unlock(struct be_adapter *adapter)
 {
-	if (use_mcc(adapter))
-		return spin_unlock_bh(&adapter->mcc_lock);
-	else
+	if (use_mcc(adapter)) {
+		spin_unlock_bh(&adapter->mcc_lock);
+		return;
+	} else {
 		return mutex_unlock(&adapter->mbox_lock);
+	}
 }
 
 static struct be_mcc_wrb *be_cmd_copy(struct be_adapter *adapter,

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 5.10] rt: Fix buid issue in be2net

[Sebastian Andrzej Siewior]

On 2025-03-28 21:29:16 [+0100], Ben Hutchings wrote:
> The problem described here is specific to v5.10-rt.
…

Thank you for the report.

Luis is aware of it and handling it
	https://lore.kernel.org/all/Z9yuIpi8zjrTCkoB@uudg.org/

Sebastian

Re: [PATCH 5.10] rt: Fix buid issue in be2net

[Luis Claudio R. Goncalves]

On Mon, Mar 31, 2025 at 11:38:44AM +0200, Sebastian Andrzej Siewior wrote:
> On 2025-03-28 21:29:16 [+0100], Ben Hutchings wrote:
> > The problem described here is specific to v5.10-rt.
> …
> 
> Thank you for the report.
> 
> Luis is aware of it and handling it
> 	https://lore.kernel.org/all/Z9yuIpi8zjrTCkoB@uudg.org/

Thank you for the report and patch Ben!

As Sebastian mentioned, I was working on that and looking for input from
the other RT maintainers on whether to fix that case with a small patch or
backport the lock primitive definitions from, say, v5.15-rt and remove the
two patches we have in place for similar problems.

As, so far, the usage of similar statements has been rare in the code, a
small patch sounded like a good compromise. If another update brings a
similar statement (void function returning <spin_lock macro>), I will
backport newer locking primitives (that use functions instead of macros).

Best regards,
Luis

> 
> Sebastian
> 
---end quoted text---