mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Yidong Zhang <yidong.zhang@amd.com>
To: Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
	<ogabbay@kernel.org>, <quic_jhugo@quicinc.com>,
	<maciej.falkowski@linux.intel.com>,
	<dri-devel@lists.freedesktop.org>
Cc: <linux-kernel@vger.kernel.org>, <sonal.santan@amd.com>,
	<mario.limonciello@amd.com>, <lizhi.hou@amd.com>,
	Nishad Saraf <nishads@amd.com>
Subject: Re: [PATCH V1 4/5] accel/amd_vpci: Add Remote Management (RM) queue service APIs
Date: Wed, 12 Nov 2025 20:52:47 -0800	[thread overview]
Message-ID: <54c86f57-4200-42d2-8661-123ac097d292@amd.com> (raw)
In-Reply-To: <3f40d64a-5312-40b1-890d-68d6c5e5203b@wanadoo.fr>



On 11/11/25 01:51, Christophe JAILLET wrote:
> Caution: This message originated from an External Source. Use proper 
> caution when opening attachments, clicking links, or responding.
> 
> 
> Le 11/11/2025 à 02:15, David Zhang a écrit :
>> This patch introduces a set of APIs for allowing the PCIe driver submit
>> commands, transfer binary payloads and retrieve firmware metadata.
>>
>> Key features:
>> - RM queue command APIs:
>>    - create and destroy RM queue commands
>>    - Initialized command data payloads
>>    - Send and poll for command completion
>> - Service-level operations:
>>    - Retrieve firmware ID
>>    - Program accelerator and APU firmware images
>>    - Periodic health monitoring
>>
>> Co-developed-by: Nishad Saraf <nishads@amd.com>
>> Signed-off-by: Nishad Saraf <nishads@amd.com>
>> Signed-off-by: David Zhang <yidong.zhang@amd.com>
> 
> ...
> 
>> +static void rm_check_health(struct work_struct *w)
>> +{
>> +     struct rm_device *rdev = to_rdev_health_monitor(w);
>> +     u32 max_len = PAGE_SIZE;
>> +     struct rm_cmd *cmd;
>> +     int ret;
>> +
>> +     ret = rm_queue_create_cmd(rdev, RM_QUEUE_OP_GET_LOG_PAGE, &cmd);
>> +     if (ret)
>> +             return;
>> +
>> +     ret = rm_queue_payload_init(cmd, RM_CMD_LOG_PAGE_AXI_TRIP_STATUS);
>> +     if (ret)
>> +             goto destroy_cmd;
>> +
>> +     ret = rm_queue_send_cmd(cmd, RM_CMD_WAIT_CONFIG_TIMEOUT);
>> +     if (ret == -ETIME || ret == -EINVAL)
>> +             goto payload_fini;
>> +
>> +     if (ret) {
>> +             u32 log_len = cmd->cq_msg.data.page.len;
>> +
>> +             if (log_len > max_len) {
>> +                     vdev_warn(rdev->vdev, "msg size %d is greater 
>> than requested %d",
>> +                               log_len, max_len);
>> +                     log_len = max_len;
>> +             }
>> +
>> +             if (log_len) {
>> +                     char *buffer = vzalloc(log_len);
>> +
>> +                     if (!buffer)
>> +                             goto payload_fini;
>> +
>> +                     ret = rm_queue_copy_response(cmd, buffer, log_len);
>> +                     if (ret) {
>> +                             vfree(buffer);
>> +                             goto payload_fini;
>> +                     }
>> +
>> +                     vdev_err(rdev->vdev, "%s", buffer);
> 
> This looks like the normal path. is vdev_err() expected here?

This is the detail info when log_len is not 0, thus err log is expected.

> 
>> +                     vfree(buffer);
>> +
>> +             } else {
>> +                     vdev_err(rdev->vdev, "firewall check ret%d", ret);
>> +             }
>> +
>> +             rdev->firewall_tripped = 1;
>> +     }
>> +
>> +payload_fini:
>> +     rm_queue_payload_fini(cmd);
>> +destroy_cmd:
>> +     rm_queue_destroy_cmd(cmd);
>> +
>> +     vdev_dbg(rdev->vdev, "check result: %d", ret);
>> +}
> 
> ...
> 
>> +struct rm_device *versal_pci_rm_init(struct versal_pci_device *vdev)
>> +{
>> +     struct rm_header *header;
>> +     struct rm_device *rdev;
>> +     u32 status;
>> +     int ret;
>> +
>> +     rdev = devm_kzalloc(&vdev->pdev->dev, sizeof(*rdev), GFP_KERNEL);
>> +     if (!rdev)
>> +             return ERR_PTR(-ENOMEM);
>> +
>> +     rdev->vdev = vdev;
>> +     header = &rdev->rm_metadata;
>> +
>> +     rm_shmem_bulk_read(rdev, RM_HDR_OFF, (u32 *)header, 
>> sizeof(*header));
>> +     if (header->magic != RM_HDR_MAGIC_NUM) {
>> +             vdev_err(vdev, "Invalid RM header 0x%x", header->magic);
>> +             ret = -ENODEV;
>> +             goto err;
>> +     }
>> +
>> +     status = rm_shmem_read(rdev, header->status_off);
>> +     if (!status) {
>> +             vdev_err(vdev, "RM status %d is not ready", status);
> 
> This can be simplified, status is knwon to be 0.

Yes, I will fix this.

> 
>> +             ret = -ENODEV;
>> +             goto err;
>> +     }
> 
> ...
> 
> CJ

  reply	other threads:[~2025-11-13  4:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-11  1:15 [PATCH V1 0/5] accel/amd_vpci: Add new driver for AMD Versal PCI David Zhang
2025-11-11  1:15 ` [PATCH V1 1/5] accel/amd_vpci: Add documentation for AMD Versal PCI accelerator management David Zhang
2025-11-11  1:15 ` [PATCH V1 2/5] accel/amd_vpci: Add new driver for AMD Versal PCI accelerator David Zhang
2025-11-11  9:38   ` Christophe JAILLET
2025-12-27 19:17     ` Yidong Zhang
2025-11-11  1:15 ` [PATCH V1 3/5] accel/amd_vpci: Add Remote Management(RM) queue infrastructure David Zhang
2025-11-11  9:44   ` Christophe JAILLET
2025-11-13  4:50     ` Yidong Zhang
2025-11-11  1:15 ` [PATCH V1 4/5] accel/amd_vpci: Add Remote Management (RM) queue service APIs David Zhang
2025-11-11  9:51   ` Christophe JAILLET
2025-11-13  4:52     ` Yidong Zhang [this message]
2025-11-11  1:15 ` [PATCH V1 5/5] accel/amd_vpci: Add communication channel service David Zhang
2025-11-11  9:59   ` Christophe JAILLET
2025-11-13  4:53     ` Yidong Zhang

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=54c86f57-4200-42d2-8661-123ac097d292@amd.com \
    --to=yidong.zhang@amd.com \
    --cc=christophe.jaillet@wanadoo.fr \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizhi.hou@amd.com \
    --cc=maciej.falkowski@linux.intel.com \
    --cc=mario.limonciello@amd.com \
    --cc=nishads@amd.com \
    --cc=ogabbay@kernel.org \
    --cc=quic_jhugo@quicinc.com \
    --cc=sonal.santan@amd.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

all inboxes | Powered by JetHome®