netdev - Re: [PATCH net-next v7 4/5] net: rnpgbe: Add basic mbx

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <0254B5B3B54BEDD3+20250828020246.GA567033@nic-Precision-5820-Tower>
Date: Thu, 28 Aug 2025 10:02:46 +0800
From: Yibo Dong <dong100@...se.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Vadim Fedorenko <vadim.fedorenko@...ux.dev>, andrew+netdev@...n.ch,
	davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
	pabeni@...hat.com, horms@...nel.org, corbet@....net,
	gur.stavi@...wei.com, maddy@...ux.ibm.com, mpe@...erman.id.au,
	danishanwar@...com, lee@...ger.us, gongfan1@...wei.com,
	lorenzo@...nel.org, geert+renesas@...der.be,
	Parthiban.Veerasooran@...rochip.com, lukas.bulwahn@...hat.com,
	alexanderduyck@...com, richardcochran@...il.com, kees@...nel.org,
	gustavoars@...nel.org, netdev@...r.kernel.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-hardening@...r.kernel.org
Subject: Re: [PATCH net-next v7 4/5] net: rnpgbe: Add basic mbx_fw support

On Wed, Aug 27, 2025 at 09:54:58PM +0200, Andrew Lunn wrote:
> > I try to explain the it:
> > 
> > driver-->fw, we has two types request:
> > 1. without response, such as mucse_mbx_ifinsmod
> > 2. with response, such as mucse_fw_get_macaddr
> > 
> > fw --> driver, we has one types request:
> > 1. link status (link speed, duplex, pause status...)
> 
> Is the firmware multi threaded? By that, i mean can there be two
> request/responses going on at once?
> 
> I'm assuming not.

No, fw is single threaded.

> 
> So there appears to be four use cases:
> 
> 1) Fire and forget, request without response.
> 2) Request with a response
> 3) Link state change from the firmware
> 4) Race condition: Request/response and link state change at the same time.
> 
> Again, assuming the firmware is single threaded, there must be a big
> mutex around the message box so there can only be one thread doing any
> sort of interaction with the firmware.
> 
> Since there can only be one thread waiting for the response, the
> struct completion can be a member of the message box. The thread
> waiting for a response uses wait_for_completion(mbx->completion).
> 
> The interrupt handler can look at the type of message it got from the
> firmware. If it is a link state, process it, and exit. If it is
> anything else, complete(mbx->completion) and exit.
> 
> I don't see the need for any sort of cookie.

Got it, I will try in patch which adds irq handler in the future.

> 
>   Andrew
> 

Thanks for your feedback.