From: Andrea Cervesato via ltp <ltp@lists.linux.it>
To: "Piotr Kubaj" <piotr.kubaj@intel.com>
Cc: daniel.niestepski@intel.com, tomasz.ossowski@intel.com,
helena.anna.dubel@intel.com, rafael.j.wysocki@intel.com,
ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v4] rfim: add new test for verifying RFIM sysfs interface
Date: Tue, 30 Jun 2026 09:40:16 +0000 [thread overview]
Message-ID: <6a438f04.117c96fe.17e125.74f9@mx.google.com> (raw)
In-Reply-To: <20260623113422.188364-2-piotr.kubaj@intel.com>
Hi Piotr,
> +#include "tst_test.h"
> +
> +#define RFIM_ROOT "/sys/bus/pci/devices/0000:00:04.0"
> +
> +static bool have_dvfs, have_fivr, have_dlvr;
> +
> +static const char * const fivr_nodes[] = {
> + RFIM_ROOT "/fivr/vco_ref_code_lo",
> + RFIM_ROOT "/fivr/vco_ref_code_hi",
> + RFIM_ROOT "/fivr/spread_spectrum_pct",
> + RFIM_ROOT "/fivr/spread_spectrum_clk_enable",
> + RFIM_ROOT "/fivr/rfi_vco_ref_code",
> + RFIM_ROOT "/fivr/fivr_fffc_rev",
> + NULL
> +};
> +
> +static const char * const ro_dvfs_nodes[] = {
> + RFIM_ROOT "/dvfs/ddr_data_rate_point_0",
> + RFIM_ROOT "/dvfs/ddr_data_rate_point_1",
> + RFIM_ROOT "/dvfs/ddr_data_rate_point_2",
> + RFIM_ROOT "/dvfs/ddr_data_rate_point_3",
> + RFIM_ROOT "/dvfs/ddr_data_rate",
> + NULL
> +};
> +
> +static const char * const ro_dlvr_nodes[] = {
> + RFIM_ROOT "/dlvr/dlvr_hardware_rev",
> + RFIM_ROOT "/dlvr/dlvr_freq_mhz",
> + RFIM_ROOT "/dlvr/dlvr_pll_busy",
> + NULL
> +};
> +
> +static const char * const rw_dlvr_nodes[] = {
> + RFIM_ROOT "/dlvr/dlvr_freq_select",
> + RFIM_ROOT "/dlvr/dlvr_rfim_enable",
> + RFIM_ROOT "/dlvr/dlvr_spread_spectrum_pct",
> + RFIM_ROOT "/dlvr/dlvr_control_mode",
> + RFIM_ROOT "/dlvr/dlvr_control_lock",
> + NULL
> +};
> +
> +static const char * const rw_dvfs_nodes[] = {
> + RFIM_ROOT "/dvfs/rfi_restriction_run_busy",
> + RFIM_ROOT "/dvfs/rfi_restriction_err_code",
> + RFIM_ROOT "/dvfs/rfi_restriction_data_rate_base",
> + RFIM_ROOT "/dvfs/rfi_restriction_data_rate",
> + RFIM_ROOT "/dvfs/rfi_restriction",
> + RFIM_ROOT "/dvfs/rfi_disable",
> + NULL
> +};
I was thinking that we can make it easier now. Instead of verifying
RW on different functions, we can simply create a .tcase structure
where we assign to each sysfs patch a specific read or write flag.
And according to that, we simply make a check inside the run()
function.
static struct tcase {
const char *path;
int read;
int write;
} tcases[] = {
...
};
static run(unsigned int i)
{
static struct *tc = &tcases[i];
if (tc->read && !tc->write) {
/* open with read -> pass */
/* open with write -> fail */
} else if (!tc->read && tc->write) {
/* open with read -> fail */
/* open with write -> pass */
} else if (tc->read && tc->write) {
/* open with read/write -> pass */
} else {
/* TBROK */
}
}
Something like this. Feel free to optimize it, it's just a draft.
Regards,
--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com
--
Mailing list info: https://lists.linux.it/listinfo/ltp
prev parent reply other threads:[~2026-06-30 9:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-23 11:34 [LTP] [PATCH v4] rfim: add new test for verifying RFIM sysfs interface Piotr Kubaj
2026-06-23 12:14 ` [LTP] " linuxtestproject.agent
2026-06-30 9:40 ` Andrea Cervesato via ltp [this message]
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=6a438f04.117c96fe.17e125.74f9@mx.google.com \
--to=ltp@lists.linux.it \
--cc=andrea.cervesato@suse.com \
--cc=daniel.niestepski@intel.com \
--cc=helena.anna.dubel@intel.com \
--cc=piotr.kubaj@intel.com \
--cc=rafael.j.wysocki@intel.com \
--cc=tomasz.ossowski@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