All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
To: Geetha sowjanya <gakula@marvell.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	kuba@kernel.org, davem@davemloft.net, pabeni@redhat.com,
	edumazet@google.com, andrew+netdev@lunn.ch, sgoutham@marvell.com,
	sbhatta@marvell.com, hkelam@marvell.com
Subject: Re: [net PATCH 2/2] octeontx2-af: Fix APR entry mapping based on APR_LMT_CFG
Date: Wed, 21 May 2025 10:36:06 +0200	[thread overview]
Message-ID: <aC2QdjlVJTNhfvV9@mev-dev.igk.intel.com> (raw)
In-Reply-To: <20250521060834.19780-3-gakula@marvell.com>

On Wed, May 21, 2025 at 11:38:34AM +0530, Geetha sowjanya wrote:
> The current implementation maps the APR table using a fixed size,
> which can lead to incorrect mapping when the number of PFs and VFs
> varies.
> This patch corrects the mapping by calculating the APR table
> size dynamically based on the values configured in the
> APR_LMT_CFG register, ensuring accurate representation
> of APR entries in debugfs.
> 
> Fixes: 0daa55d033b0 ("octeontx2-af: cn10k: debugfs for dumping LMTST map table").
> Signed-off-by: Geetha sowjanya <gakula@marvell.com>
> ---
>  drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c |  9 ++++++---
>  .../net/ethernet/marvell/octeontx2/af/rvu_debugfs.c   | 11 ++++++++---
>  2 files changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c
> index 3838c04b78c2..4a3370a40dd8 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c
> @@ -13,7 +13,6 @@
>  /* RVU LMTST */
>  #define LMT_TBL_OP_READ		0
>  #define LMT_TBL_OP_WRITE	1
> -#define LMT_MAP_TABLE_SIZE	(128 * 1024)
>  #define LMT_MAPTBL_ENTRY_SIZE	16
>  #define LMT_MAX_VFS		256
>  
> @@ -26,10 +25,14 @@ static int lmtst_map_table_ops(struct rvu *rvu, u32 index, u64 *val,
>  {
>  	void __iomem *lmt_map_base;
>  	u64 tbl_base, cfg;
> +	int pfs, vfs;
>  
>  	tbl_base = rvu_read64(rvu, BLKADDR_APR, APR_AF_LMT_MAP_BASE);
> +	cfg  = rvu_read64(rvu, BLKADDR_APR, APR_AF_LMT_CFG);
> +	vfs = 1 << (cfg & 0xF);
> +	pfs = 1 << ((cfg >> 4) & 0x7);
>  
> -	lmt_map_base = ioremap_wc(tbl_base, LMT_MAP_TABLE_SIZE);
> +	lmt_map_base = ioremap_wc(tbl_base, pfs * vfs * LMT_MAPTBL_ENTRY_SIZE);
>  	if (!lmt_map_base) {
>  		dev_err(rvu->dev, "Failed to setup lmt map table mapping!!\n");
>  		return -ENOMEM;
> @@ -80,7 +83,7 @@ static int rvu_get_lmtaddr(struct rvu *rvu, u16 pcifunc,
>  
>  	mutex_lock(&rvu->rsrc_lock);
>  	rvu_write64(rvu, BLKADDR_RVUM, RVU_AF_SMMU_ADDR_REQ, iova);
> -	pf = rvu_get_pf(pcifunc) & 0x1F;
> +	pf = rvu_get_pf(pcifunc) & RVU_PFVF_PF_MASK;
>  	val = BIT_ULL(63) | BIT_ULL(14) | BIT_ULL(13) | pf << 8 |
>  	      ((pcifunc & RVU_PFVF_FUNC_MASK) & 0xFF);
>  	rvu_write64(rvu, BLKADDR_RVUM, RVU_AF_SMMU_TXN_REQ, val);
> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c
> index a1f9ec03c2ce..c827da626471 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c
> @@ -553,6 +553,7 @@ static ssize_t rvu_dbg_lmtst_map_table_display(struct file *filp,
>  	u64 lmt_addr, val, tbl_base;
>  	int pf, vf, num_vfs, hw_vfs;
>  	void __iomem *lmt_map_base;
> +	int apr_pfs, apr_vfs;
>  	int buf_size = 10240;
>  	size_t off = 0;
>  	int index = 0;
> @@ -568,8 +569,12 @@ static ssize_t rvu_dbg_lmtst_map_table_display(struct file *filp,
>  		return -ENOMEM;
>  
>  	tbl_base = rvu_read64(rvu, BLKADDR_APR, APR_AF_LMT_MAP_BASE);
> +	val  = rvu_read64(rvu, BLKADDR_APR, APR_AF_LMT_CFG);
> +	apr_vfs = 1 << (val & 0xF);
> +	apr_pfs = 1 << ((val >> 4) & 0x7);
>  
> -	lmt_map_base = ioremap_wc(tbl_base, 128 * 1024);
> +	lmt_map_base = ioremap_wc(tbl_base, apr_pfs * apr_vfs *
> +				  LMT_MAPTBL_ENTRY_SIZE);

As it is the same as in lmtst_map_table_ops() I think you can move whole
to a new function.

rvu_ioremap_wc(rvu, base, size);

or sth like that. It isn't strong opinion. Rest looks fine, thanks.

>  	if (!lmt_map_base) {
>  		dev_err(rvu->dev, "Failed to setup lmt map table mapping!!\n");
>  		kfree(buf);
> @@ -591,7 +596,7 @@ static ssize_t rvu_dbg_lmtst_map_table_display(struct file *filp,
>  		off += scnprintf(&buf[off], buf_size - 1 - off, "PF%d  \t\t\t",
>  				    pf);
>  
> -		index = pf * rvu->hw->total_vfs * LMT_MAPTBL_ENTRY_SIZE;
> +		index = pf * apr_vfs * LMT_MAPTBL_ENTRY_SIZE;
>  		off += scnprintf(&buf[off], buf_size - 1 - off, " 0x%llx\t\t",
>  				 (tbl_base + index));
>  		lmt_addr = readq(lmt_map_base + index);
> @@ -604,7 +609,7 @@ static ssize_t rvu_dbg_lmtst_map_table_display(struct file *filp,
>  		/* Reading num of VFs per PF */
>  		rvu_get_pf_numvfs(rvu, pf, &num_vfs, &hw_vfs);
>  		for (vf = 0; vf < num_vfs; vf++) {
> -			index = (pf * rvu->hw->total_vfs * 16) +
> +			index = (pf * apr_vfs * LMT_MAPTBL_ENTRY_SIZE) +
>  				((vf + 1)  * LMT_MAPTBL_ENTRY_SIZE);
>  			off += scnprintf(&buf[off], buf_size - 1 - off,
>  					    "PF%d:VF%d  \t\t", pf, vf);
> -- 
> 2.25.1

  reply	other threads:[~2025-05-21  8:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-21  6:08 [net PATCH 0/2] octeontx2-af: APR Mapping Fixes Geetha sowjanya
2025-05-21  6:08 ` [net PATCH 1/2] octeontx2-af: Set LMT_ENA bit for APR table entries Geetha sowjanya
2025-05-21  8:39   ` Michal Swiatkowski
2025-05-21 12:00     ` Geethasowjanya Akula
2025-05-21  6:08 ` [net PATCH 2/2] octeontx2-af: Fix APR entry mapping based on APR_LMT_CFG Geetha sowjanya
2025-05-21  8:36   ` Michal Swiatkowski [this message]
2025-05-21 12:07     ` Geethasowjanya Akula
2025-05-22 10:15       ` Paolo Abeni
2025-05-22 10:40 ` [net PATCH 0/2] octeontx2-af: APR Mapping Fixes patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aC2QdjlVJTNhfvV9@mev-dev.igk.intel.com \
    --to=michal.swiatkowski@linux.intel.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=gakula@marvell.com \
    --cc=hkelam@marvell.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sbhatta@marvell.com \
    --cc=sgoutham@marvell.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.