[PATCH] octeontx2-af: Send Link events one by one

[PATCH] octeontx2-af: Send Link events one by one

[Subbaraya Sundeep]

Send link events one after another otherwise new message
is overwriting the message which is being processed by PF.

Fixes: a88e0f936ba9 ("octeontx2: Detect the mbox up or down message via register")
Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
---
 drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
index 992fa0b..ebb56eb 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
@@ -272,6 +272,8 @@ static void cgx_notify_pfs(struct cgx_link_event *event, struct rvu *rvu)
 
 		otx2_mbox_msg_send_up(&rvu->afpf_wq_info.mbox_up, pfid);
 
+		otx2_mbox_wait_for_rsp(&rvu->afpf_wq_info.mbox_up, pfid);
+
 		mutex_unlock(&rvu->mbox_lock);
 	} while (pfmap);
 }
-- 
2.7.4

Re: [PATCH] octeontx2-af: Send Link events one by one

[Simon Horman]

On Wed, May 07, 2025 at 10:46:23PM +0530, Subbaraya Sundeep wrote:
> Send link events one after another otherwise new message
> is overwriting the message which is being processed by PF.
> 
> Fixes: a88e0f936ba9 ("octeontx2: Detect the mbox up or down message via register")
> Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
> ---
>  drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
> index 992fa0b..ebb56eb 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
> @@ -272,6 +272,8 @@ static void cgx_notify_pfs(struct cgx_link_event *event, struct rvu *rvu)
>  
>  		otx2_mbox_msg_send_up(&rvu->afpf_wq_info.mbox_up, pfid);

Hi Subbaraya,

Are there other callers of otx2_mbox_msg_send_up()
which also need this logic? If so, perhaps a helper is useful.
If not, could you clarify why?

>  
> +		otx2_mbox_wait_for_rsp(&rvu->afpf_wq_info.mbox_up, pfid);

This can return an error. Which is checked in otx2_sync_mbox_up_msg().
Does it make sense to do so here too?

> +
>  		mutex_unlock(&rvu->mbox_lock);
>  	} while (pfmap);
>  }
> -- 
> 2.7.4
> 

Re: [PATCH] octeontx2-af: Send Link events one by one

[Subbaraya Sundeep]

Hi Simon,

On 2025-05-12 at 10:09:54, Simon Horman (horms@kernel.org) wrote:
> On Wed, May 07, 2025 at 10:46:23PM +0530, Subbaraya Sundeep wrote:
> > Send link events one after another otherwise new message
> > is overwriting the message which is being processed by PF.
> > 
> > Fixes: a88e0f936ba9 ("octeontx2: Detect the mbox up or down message via register")
> > Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
> > ---
> >  drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
> > index 992fa0b..ebb56eb 100644
> > --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
> > +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
> > @@ -272,6 +272,8 @@ static void cgx_notify_pfs(struct cgx_link_event *event, struct rvu *rvu)
> >  
> >  		otx2_mbox_msg_send_up(&rvu->afpf_wq_info.mbox_up, pfid);
> 
> Hi Subbaraya,
> 
> Are there other callers of otx2_mbox_msg_send_up()
> which also need this logic? If so, perhaps a helper is useful.
> If not, could you clarify why?
> 
UP messages are async notifications where we just send and forget.
There are other callers as I said we just send and forget everywhere
in the driver. Only this callsite has been modified because we have
seen an issue on customer setup where bunch of link events are queued
for a same device at one point of time.
> >  
> > +		otx2_mbox_wait_for_rsp(&rvu->afpf_wq_info.mbox_up, pfid);
> 
> This can return an error. Which is checked in otx2_sync_mbox_up_msg().
> Does it make sense to do so here too?
> 
Yes it makes sense to use otx2_sync_mbox_up_msg here. I will use it
here.

Thanks,
Sundeep
> > +
> >  		mutex_unlock(&rvu->mbox_lock);
> >  	} while (pfmap);
> >  }
> > -- 
> > 2.7.4
> > 

Re: [PATCH] octeontx2-af: Send Link events one by one

[Subbaraya Sundeep]

Hi again,

On 2025-05-12 at 11:45:43, Subbaraya Sundeep (sbhatta@marvell.com) wrote:
> Hi Simon,
> 
> On 2025-05-12 at 10:09:54, Simon Horman (horms@kernel.org) wrote:
> > On Wed, May 07, 2025 at 10:46:23PM +0530, Subbaraya Sundeep wrote:
> > > Send link events one after another otherwise new message
> > > is overwriting the message which is being processed by PF.
> > > 
> > > Fixes: a88e0f936ba9 ("octeontx2: Detect the mbox up or down message via register")
> > > Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
> > > ---
> > >  drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
> > > index 992fa0b..ebb56eb 100644
> > > --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
> > > +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
> > > @@ -272,6 +272,8 @@ static void cgx_notify_pfs(struct cgx_link_event *event, struct rvu *rvu)
> > >  
> > >  		otx2_mbox_msg_send_up(&rvu->afpf_wq_info.mbox_up, pfid);
> > 
> > Hi Subbaraya,
> > 
> > Are there other callers of otx2_mbox_msg_send_up()
> > which also need this logic? If so, perhaps a helper is useful.
> > If not, could you clarify why?
> > 
> UP messages are async notifications where we just send and forget.
> There are other callers as I said we just send and forget everywhere
> in the driver. Only this callsite has been modified because we have
> seen an issue on customer setup where bunch of link events are queued
> for a same device at one point of time.
> > >  
> > > +		otx2_mbox_wait_for_rsp(&rvu->afpf_wq_info.mbox_up, pfid);
> > 
> > This can return an error. Which is checked in otx2_sync_mbox_up_msg().
> > Does it make sense to do so here too?
> > 
> Yes it makes sense to use otx2_sync_mbox_up_msg here. I will use it
> here.
> 
I will leave it as otx2_mbox_wait_for_rsp. Since otx2_sync_mbox_up_msg
is in nic driver and we do not include nic files in AF driver. Since
this is a void function will print an error if otx2_mbox_wait_for_rsp
returns error.

Thanks,
Sundeep

> Thanks,
> Sundeep
> > > +
> > >  		mutex_unlock(&rvu->mbox_lock);
> > >  	} while (pfmap);
> > >  }
> > > -- 
> > > 2.7.4
> > > 

Re: [PATCH] octeontx2-af: Send Link events one by one

[Simon Horman]

On Mon, May 12, 2025 at 01:02:35PM +0000, Subbaraya Sundeep wrote:
> Hi again,
> 
> On 2025-05-12 at 11:45:43, Subbaraya Sundeep (sbhatta@marvell.com) wrote:
> > Hi Simon,
> > 
> > On 2025-05-12 at 10:09:54, Simon Horman (horms@kernel.org) wrote:
> > > On Wed, May 07, 2025 at 10:46:23PM +0530, Subbaraya Sundeep wrote:
> > > > Send link events one after another otherwise new message
> > > > is overwriting the message which is being processed by PF.
> > > > 
> > > > Fixes: a88e0f936ba9 ("octeontx2: Detect the mbox up or down message via register")
> > > > Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
> > > > ---
> > > >  drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > > > 
> > > > diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
> > > > index 992fa0b..ebb56eb 100644
> > > > --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
> > > > +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
> > > > @@ -272,6 +272,8 @@ static void cgx_notify_pfs(struct cgx_link_event *event, struct rvu *rvu)
> > > >  
> > > >  		otx2_mbox_msg_send_up(&rvu->afpf_wq_info.mbox_up, pfid);
> > > 
> > > Hi Subbaraya,
> > > 
> > > Are there other callers of otx2_mbox_msg_send_up()
> > > which also need this logic? If so, perhaps a helper is useful.
> > > If not, could you clarify why?
> > > 
> > UP messages are async notifications where we just send and forget.
> > There are other callers as I said we just send and forget everywhere
> > in the driver. Only this callsite has been modified because we have
> > seen an issue on customer setup where bunch of link events are queued
> > for a same device at one point of time.

Thanks for the clarification.

> > > >  
> > > > +		otx2_mbox_wait_for_rsp(&rvu->afpf_wq_info.mbox_up, pfid);
> > > 
> > > This can return an error. Which is checked in otx2_sync_mbox_up_msg().
> > > Does it make sense to do so here too?
> > > 
> > Yes it makes sense to use otx2_sync_mbox_up_msg here. I will use it
> > here.
> > 
> I will leave it as otx2_mbox_wait_for_rsp. Since otx2_sync_mbox_up_msg
> is in nic driver and we do not include nic files in AF driver. Since
> this is a void function will print an error if otx2_mbox_wait_for_rsp
> returns error.

Sorry, I wasn't clear in my previous email.

I was asking if it makes sense to check the return value of
otx2_mbox_wait_for_rsp() in this patch.

...

Re: [PATCH] octeontx2-af: Send Link events one by one

[Subbaraya Sundeep]

Hi Simon,

On 2025-05-13 at 13:17:21, Simon Horman (horms@kernel.org) wrote:
> On Mon, May 12, 2025 at 01:02:35PM +0000, Subbaraya Sundeep wrote:
> > Hi again,
> > 
> > On 2025-05-12 at 11:45:43, Subbaraya Sundeep (sbhatta@marvell.com) wrote:
> > > Hi Simon,
> > > 
> > > On 2025-05-12 at 10:09:54, Simon Horman (horms@kernel.org) wrote:
> > > > On Wed, May 07, 2025 at 10:46:23PM +0530, Subbaraya Sundeep wrote:
> > > > > Send link events one after another otherwise new message
> > > > > is overwriting the message which is being processed by PF.
> > > > > 
> > > > > Fixes: a88e0f936ba9 ("octeontx2: Detect the mbox up or down message via register")
> > > > > Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
> > > > > ---
> > > > >  drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c | 2 ++
> > > > >  1 file changed, 2 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
> > > > > index 992fa0b..ebb56eb 100644
> > > > > --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
> > > > > +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
> > > > > @@ -272,6 +272,8 @@ static void cgx_notify_pfs(struct cgx_link_event *event, struct rvu *rvu)
> > > > >  
> > > > >  		otx2_mbox_msg_send_up(&rvu->afpf_wq_info.mbox_up, pfid);
> > > > 
> > > > Hi Subbaraya,
> > > > 
> > > > Are there other callers of otx2_mbox_msg_send_up()
> > > > which also need this logic? If so, perhaps a helper is useful.
> > > > If not, could you clarify why?
> > > > 
> > > UP messages are async notifications where we just send and forget.
> > > There are other callers as I said we just send and forget everywhere
> > > in the driver. Only this callsite has been modified because we have
> > > seen an issue on customer setup where bunch of link events are queued
> > > for a same device at one point of time.
> 
> Thanks for the clarification.
> 
> > > > >  
> > > > > +		otx2_mbox_wait_for_rsp(&rvu->afpf_wq_info.mbox_up, pfid);
> > > > 
> > > > This can return an error. Which is checked in otx2_sync_mbox_up_msg().
> > > > Does it make sense to do so here too?
> > > > 
> > > Yes it makes sense to use otx2_sync_mbox_up_msg here. I will use it
> > > here.
> > > 
> > I will leave it as otx2_mbox_wait_for_rsp. Since otx2_sync_mbox_up_msg
> > is in nic driver and we do not include nic files in AF driver. Since
> > this is a void function will print an error if otx2_mbox_wait_for_rsp
> > returns error.
> 
> Sorry, I wasn't clear in my previous email.
> 
> I was asking if it makes sense to check the return value of
> otx2_mbox_wait_for_rsp() in this patch.
> 
Not needed because there is nothing much we can do if it returns error
other than just printing that it failed. And anyway otx2_mbox_wait_for_rsp
has debug print internally so will leave this with no changes.

Thanks,
Sundeep
> ...