From: Michal Wajdeczko <michal.wajdeczko@intel.com>
To: "Piotr Piórkowski" <piotr.piorkowski@intel.com>,
"Ghimiray, Himal Prasad" <himal.prasad.ghimiray@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH 1/6] drm/xe: Add helper to format SR-IOV function name
Date: Mon, 15 Apr 2024 10:30:07 +0200 [thread overview]
Message-ID: <431e5048-e909-4b9b-b1df-fd495298370f@intel.com> (raw)
In-Reply-To: <20240415075627.ctbcxxwk6jwuhk7p@intel.com>
On 15.04.2024 09:56, Piotr Piórkowski wrote:
> Ghimiray, Himal Prasad <himal.prasad.ghimiray@intel.com> wrote on pon [2024-kwi-15 09:17:27 +0530]:
>>
>> On 15-04-2024 00:31, Michal Wajdeczko wrote:
>>> While the GuC firmware and the Xe driver are using VF identifier
>>> VFID(0) to represent the Physical Function, we should avoid using
>>> "VF0" name and use proper "PF" name in all user facing messages
>>> related to the Physical Function and use "VFn" name only when
>>> referrinf to the true Virtual Function. Add simple helper to get
>>> properly formatted function name based on the function number.
>>>
>>> Signed-off-by: Michal Wajdeczko<michal.wajdeczko@intel.com>
>>> ---
>>> drivers/gpu/drm/xe/xe_sriov.c | 17 +++++++++++++++++
>>> drivers/gpu/drm/xe/xe_sriov.h | 1 +
>>> 2 files changed, 18 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/xe/xe_sriov.c b/drivers/gpu/drm/xe/xe_sriov.c
>>> index 1b40f5de9ef5..1c3fa84b6adb 100644
>>> --- a/drivers/gpu/drm/xe/xe_sriov.c
>>> +++ b/drivers/gpu/drm/xe/xe_sriov.c
>>> @@ -122,3 +122,20 @@ void xe_sriov_print_info(struct xe_device *xe, struct drm_printer *p)
>>> drm_printf(p, "enabled: %s\n", str_yes_no(IS_SRIOV(xe)));
>>> drm_printf(p, "mode: %s\n", xe_sriov_mode_to_string(xe_device_sriov_mode(xe)));
>>> }
>>> +
>>> +/**
>>> + * xe_sriov_function_name() - Get SR-IOV Function name.
>>> + * @n: the Function number (identifier) to get name of
>>> + * @buf: the buffer to format to
>>> + * @size: size of the buffer (shall be at least 5 bytes)
>>> + *
>>> + * Return: formatted function name ("PF" or "VF%u").
>>> + */
>>> +const char *xe_sriov_function_name(unsigned int n, char *buf, size_t size)
>>
>> nit: It is not necessary to return a |buf|, so |how about void instead of
>> const char * ?|
true, it could be done as void, but that looks as a waste of one of the
potential use which is mentioned below
besides, this is our Xe driver helper only, it's main goal is usability
otherwise it should be written as returning "int" to "return number of
characters of output that would have been written which may be greater
than len, if output was truncated)" like in string_get_size()
but that would be overkill IMO as it would be highly unlikely that we
ever check that ret value
>>
>> |With that LGTM.|
>>
>> |Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> |
>
> I'm guessing that this function returns a pointer to be able to use this directly
> in printf kind of functions. I am ok with this:
yes, even in patch 6/6 I'm using that this way in pf_push_vf_cfg_klvs()
>
> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
thanks!
>>
>>> +{
>>> + if (n)
>>> + snprintf(buf, size, "VF%u", n);
>>> + else
>>> + strscpy(buf, "PF", size);
>>> + return buf;
>>> +}
>>> diff --git a/drivers/gpu/drm/xe/xe_sriov.h b/drivers/gpu/drm/xe/xe_sriov.h
>>> index f9dec84d77e3..486bb21c3256 100644
>>> --- a/drivers/gpu/drm/xe/xe_sriov.h
>>> +++ b/drivers/gpu/drm/xe/xe_sriov.h
>>> @@ -13,6 +13,7 @@
>>> struct drm_printer;
>>> const char *xe_sriov_mode_to_string(enum xe_sriov_mode mode);
>>> +const char *xe_sriov_function_name(unsigned int n, char *buf, size_t len);
>>> void xe_sriov_probe_early(struct xe_device *xe);
>>> void xe_sriov_print_info(struct xe_device *xe, struct drm_printer *p);
>
next prev parent reply other threads:[~2024-04-15 8:30 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-14 19:01 [PATCH 0/6] PF: Add support to configure SR-IOV VFs Michal Wajdeczko
2024-04-14 19:01 ` [PATCH 1/6] drm/xe: Add helper to format SR-IOV function name Michal Wajdeczko
2024-04-15 3:47 ` Ghimiray, Himal Prasad
2024-04-15 7:56 ` Piotr Piórkowski
2024-04-15 8:30 ` Michal Wajdeczko [this message]
2024-04-14 19:01 ` [PATCH 2/6] drm/xe: Allow to assign GGTT region to the VF Michal Wajdeczko
2024-04-15 4:49 ` Ghimiray, Himal Prasad
2024-04-15 9:01 ` Michal Wajdeczko
2024-04-15 9:10 ` Piotr Piórkowski
2024-04-15 9:12 ` Ghimiray, Himal Prasad
2024-04-14 19:01 ` [PATCH 3/6] drm/xe: Add xe_ttm_vram_get_avail Michal Wajdeczko
2024-04-15 4:51 ` Ghimiray, Himal Prasad
2024-04-14 19:01 ` [PATCH 4/6] drm/xe/guc: Add PF2GUC_UPDATE_VF_CFG to ABI Michal Wajdeczko
2024-04-15 9:29 ` Piotr Piórkowski
2024-04-14 19:01 ` [PATCH 5/6] drm/xe/pf: Add SR-IOV PF specific early GT initialization Michal Wajdeczko
2024-04-15 5:19 ` Ghimiray, Himal Prasad
2024-04-15 8:14 ` Michal Wajdeczko
2024-04-14 19:01 ` [PATCH 6/6] drm/xe/pf: Add support to configure SR-IOV VFs Michal Wajdeczko
2024-04-15 14:29 ` Piotr Piórkowski
2024-04-15 17:06 ` Michal Wajdeczko
2024-04-15 17:15 ` ✓ CI.Patch_applied: success for PF: " Patchwork
2024-04-15 17:15 ` ✗ CI.checkpatch: warning " Patchwork
2024-04-15 17:16 ` ✓ CI.KUnit: success " Patchwork
2024-04-15 17:27 ` ✓ CI.Build: " Patchwork
2024-04-15 17:30 ` ✓ CI.Hooks: " Patchwork
2024-04-15 17:31 ` ✓ CI.checksparse: " Patchwork
2024-04-15 17:57 ` ✓ CI.BAT: " Patchwork
2024-04-16 3:44 ` ✓ CI.FULL: " Patchwork
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=431e5048-e909-4b9b-b1df-fd495298370f@intel.com \
--to=michal.wajdeczko@intel.com \
--cc=himal.prasad.ghimiray@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=piotr.piorkowski@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