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.
