netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Tatyana Nikolova <tatyana.e.nikolova@intel.com>
Cc: intel-wired-lan@lists.osuosl.org, jgg@nvidia.com,
	leon@kernel.org, linux-rdma@vger.kernel.org,
	netdev@vger.kernel.org, kuba@kernel.org,
	anthony.l.nguyen@intel.com, Joshua Hay <joshua.a.hay@intel.com>
Subject: Re: [iwl-next 2/6] idpf: implement core RDMA auxiliary dev create, init, and destroy
Date: Wed, 28 May 2025 11:40:43 +0100	[thread overview]
Message-ID: <20250528104043.GA365796@horms.kernel.org> (raw)
In-Reply-To: <20250523170435.668-3-tatyana.e.nikolova@intel.com>

On Fri, May 23, 2025 at 12:04:31PM -0500, Tatyana Nikolova wrote:
> From: Joshua Hay <joshua.a.hay@intel.com>
> 
> Add the initial idpf_idc.c file with the functions to kick off the IDC
> initialization, create and initialize a core RDMA auxiliary device, and
> destroy said device.
> 
> The RDMA core has a dependency on the vports being created by the
> control plane before it can be initialized. Therefore, once all the
> vports are up after a hard reset (either during driver load or a function
> level reset), the core RDMA device info will be created. It is populated
> with the function type (as distinguished by the IDC initialization
> function pointer), the core idc_ops function points (just stubs for
> now), the reserved RDMA MSIX table, and various other info the core RDMA
> auxiliary driver will need. It is then plugged on to the bus.
> 
> During a function level reset or driver unload, the device will be
> unplugged from the bus and destroyed.
> 
> Reviewed-by: Madhu Chittim <madhu.chittim@intel.com>
> Signed-off-by: Joshua Hay <joshua.a.hay@intel.com>
> Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com>

...

> diff --git a/drivers/net/ethernet/intel/idpf/idpf_idc.c b/drivers/net/ethernet/intel/idpf/idpf_idc.c

...

> +/**
> + * idpf_idc_init_aux_core_dev - initialize Auxiliary Device(s)
> + * @adapter: driver private data structure
> + * @ftype: PF or VF
> + *
> + * Return: 0 on success or error code on failure.
> + */
> +int idpf_idc_init_aux_core_dev(struct idpf_adapter *adapter,
> +			       enum iidc_function_type ftype)
> +{
> +	struct iidc_rdma_core_dev_info *cdev_info;
> +	struct iidc_rdma_priv_dev_info *privd;
> +	int err;
> +
> +	adapter->cdev_info = kzalloc(sizeof(*cdev_info), GFP_KERNEL);
> +	if (!adapter->cdev_info)
> +		return -ENOMEM;
> +
> +	privd = kzalloc(sizeof(*privd), GFP_KERNEL);
> +	if (!privd) {
> +		err = -ENOMEM;
> +		goto err_privd_alloc;

Hi Joshua, Tatyana, all,

Jumping to err_privd_alloc will free cdev_info.
However cdev_info isn't initialised until a few lines
further down.

Flagged by Smatch.

> +	}
> +
> +	cdev_info = adapter->cdev_info;
> +	cdev_info->iidc_priv = privd;
> +	cdev_info->pdev = adapter->pdev;
> +	cdev_info->rdma_protocol = IIDC_RDMA_PROTOCOL_ROCEV2;
> +	privd->ftype = ftype;
> +
> +	idpf_idc_init_msix_data(adapter);
> +
> +	err = idpf_plug_core_aux_dev(cdev_info);
> +	if (err)
> +		goto err_plug_aux_dev;
> +
> +	return 0;
> +
> +err_plug_aux_dev:
> +	kfree(privd);
> +err_privd_alloc:
> +	kfree(cdev_info);
> +	adapter->cdev_info = NULL;
> +
> +	return err;
> +}

...

  reply	other threads:[~2025-05-28 10:40 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-23 17:04 [iwl-next 0/6] Add RDMA support for Intel IPU E2000 in idpf Tatyana Nikolova
2025-05-23 17:04 ` [iwl-next 1/6] idpf: use reserved RDMA vectors from control plane Tatyana Nikolova
2025-05-25  5:23   ` [Intel-wired-lan] " Paul Menzel
2025-05-28 21:35     ` Hay, Joshua A
2025-05-23 17:04 ` [iwl-next 2/6] idpf: implement core RDMA auxiliary dev create, init, and destroy Tatyana Nikolova
2025-05-28 10:40   ` Simon Horman [this message]
2025-05-28 21:35     ` Hay, Joshua A
2025-05-23 17:04 ` [iwl-next 3/6] idpf: implement RDMA vport " Tatyana Nikolova
2025-05-23 17:04 ` [iwl-next 4/6] idpf: implement remaining IDC RDMA core callbacks and handlers Tatyana Nikolova
2025-05-23 17:04 ` [iwl-next 5/6] idpf: implement IDC vport aux driver MTU change handler Tatyana Nikolova
2025-05-23 17:04 ` [iwl-next 6/6] idpf: implement get LAN MMIO memory regions Tatyana Nikolova
2025-05-28 10:44   ` Simon Horman
2025-05-28 21:35     ` Hay, Joshua A

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=20250528104043.GA365796@horms.kernel.org \
    --to=horms@kernel.org \
    --cc=anthony.l.nguyen@intel.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jgg@nvidia.com \
    --cc=joshua.a.hay@intel.com \
    --cc=kuba@kernel.org \
    --cc=leon@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=tatyana.e.nikolova@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).