From: Kalle Valo <kvalo@kernel.org>
To: Ramya Gnanasekar <quic_rgnanase@quicinc.com>
Cc: ath12k@lists.infradead.org, linux-wireless@vger.kernel.org,
Dinesh Karthikeyan <quic_dinek@quicinc.com>
Subject: Re: [PATCH v2 1/5] wifi: ath12k: Add support to enable debugfs_htt_stats
Date: Tue, 21 May 2024 10:49:36 +0300 [thread overview]
Message-ID: <87y183d2pb.fsf@kernel.org> (raw)
In-Reply-To: <20240510050806.514126-2-quic_rgnanase@quicinc.com> (Ramya Gnanasekar's message of "Fri, 10 May 2024 10:38:02 +0530")
Ramya Gnanasekar <quic_rgnanase@quicinc.com> writes:
> From: Dinesh Karthikeyan <quic_dinek@quicinc.com>
>
> Create debugfs_htt_stats file when ath12k debugfs support is enabled.
> Add basic ath12k_debugfs_htt_stats_init and handle htt_stats_type
> file operations.
>
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
>
> Signed-off-by: Dinesh Karthikeyan <quic_dinek@quicinc.com>
> Co-developed-by: Ramya Gnanasekar <quic_rgnanase@quicinc.com>
> Signed-off-by: Ramya Gnanasekar <quic_rgnanase@quicinc.com>
[...]
> +struct ath12k_dbg_htt_stats {
> + enum ath12k_dbg_htt_ext_stats_type type;
> + u32 cfg_param[4];
> + /* protects shared stats req buffer */
> + spinlock_t lock;
> +};
Is there a specific reason why a new lock is needed? Why not just use
struct ath12k::data_lock?
> +
> struct ath12k_debug {
> struct dentry *debugfs_pdev;
> + struct ath12k_dbg_htt_stats htt_stats;
> };
>
> struct ath12k_per_peer_tx_stats {
> diff --git a/drivers/net/wireless/ath/ath12k/debugfs.c b/drivers/net/wireless/ath/ath12k/debugfs.c
> index 8d8ba951093b..30a80f04d824 100644
> --- a/drivers/net/wireless/ath/ath12k/debugfs.c
> +++ b/drivers/net/wireless/ath/ath12k/debugfs.c
> @@ -6,6 +6,7 @@
>
> #include "core.h"
> #include "debugfs.h"
> +#include "debugfs_htt_stats.h"
>
> static ssize_t ath12k_write_simulate_radar(struct file *file,
> const char __user *user_buf,
> @@ -87,4 +88,6 @@ void ath12k_debugfs_register(struct ath12k *ar)
> ar->debug.debugfs_pdev, ar,
> &fops_simulate_radar);
> }
> +
> + ath12k_debugfs_htt_stats_init(ar);
Let's try to have consistent naming: ath12k_debugfs_htt_stats_register()
> +static ssize_t ath12k_read_htt_stats_type(struct file *file,
> + char __user *user_buf,
> + size_t count, loff_t *ppos)
> +{
> + struct ath12k *ar = file->private_data;
> + char buf[32];
> + size_t len;
> +
> + len = scnprintf(buf, sizeof(buf), "%u\n", ar->debug.htt_stats.type);
> +
> + return simple_read_from_buffer(user_buf, count, ppos, buf, len);
> +}
Access to ar->debug.htt_stats.type isn't protected in any way.
> +
> +static ssize_t ath12k_write_htt_stats_type(struct file *file,
> + const char __user *user_buf,
> + size_t count, loff_t *ppos)
> +{
> + struct ath12k *ar = file->private_data;
> + enum ath12k_dbg_htt_ext_stats_type type;
> + unsigned int cfg_param[4] = {0};
> + int num_args;
> +
> + char *buf __free(kfree) = kzalloc(count, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> +
> + if (copy_from_user(buf, user_buf, count))
> + return -EFAULT;
> +
> + num_args = sscanf(buf, "%u %u %u %u %u\n", &type, &cfg_param[0],
> + &cfg_param[1], &cfg_param[2], &cfg_param[3]);
> + if (!num_args || num_args > 5)
> + return -EINVAL;
> +
> + if (type >= ATH12K_DBG_HTT_NUM_EXT_STATS)
> + return -E2BIG;
> +
> + if (type == ATH12K_DBG_HTT_EXT_STATS_RESET)
> + return -EPERM;
> +
> + ar->debug.htt_stats.type = type;
> + ar->debug.htt_stats.cfg_param[0] = cfg_param[0];
> + ar->debug.htt_stats.cfg_param[1] = cfg_param[1];
> + ar->debug.htt_stats.cfg_param[2] = cfg_param[2];
> + ar->debug.htt_stats.cfg_param[3] = cfg_param[3];
> +
> + return count;
> +}
Same here with both type and cfg_param. Maybe it's ok to skip
protection, I didn't do analysis yet, but this makes me suspicious.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
next prev parent reply other threads:[~2024-05-21 7:49 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-10 5:08 [PATCH v2 0/5] wifi: ath12k: Add support to enable debugfs_htt_stats Ramya Gnanasekar
2024-05-10 5:08 ` [PATCH v2 1/5] " Ramya Gnanasekar
2024-05-10 19:53 ` Jeff Johnson
2024-05-21 7:49 ` Kalle Valo [this message]
2024-05-27 10:42 ` Ramya Gnanasekar
2024-05-10 5:08 ` [PATCH v2 2/5] wifi: ath12k: Add htt_stats_dump file ops support Ramya Gnanasekar
2024-05-10 19:53 ` Jeff Johnson
2024-05-21 7:53 ` Kalle Valo
2024-05-10 5:08 ` [PATCH v2 3/5] wifi: ath12k: Fix Pdev id in HTT stats request for WCN7850 Ramya Gnanasekar
2024-05-10 19:53 ` Jeff Johnson
2024-05-21 7:57 ` Kalle Valo
2024-05-23 12:34 ` Lingbo Kong
2024-05-23 12:55 ` Kalle Valo
2024-05-23 14:04 ` Lingbo Kong
2024-05-10 5:08 ` [PATCH v2 4/5] wifi: ath12k: Add support to parse requested stats_type Ramya Gnanasekar
2024-05-10 19:53 ` Jeff Johnson
2024-05-10 5:08 ` [PATCH v2 5/5] wifi: ath12k: Dump additional Tx PDEV HTT stats Ramya Gnanasekar
2024-05-10 19:54 ` Jeff Johnson
2024-05-21 8:00 ` Kalle Valo
2024-05-27 9:38 ` Ramya Gnanasekar
2024-05-28 11:06 ` Kalle Valo
2024-05-28 16:48 ` Ramya Gnanasekar
2024-05-31 18:00 ` Kalle Valo
2024-05-31 19:05 ` Ramya Gnanasekar
2024-05-21 7:40 ` [PATCH v2 0/5] wifi: ath12k: Add support to enable debugfs_htt_stats Kalle Valo
2024-05-27 10:44 ` Ramya Gnanasekar
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=87y183d2pb.fsf@kernel.org \
--to=kvalo@kernel.org \
--cc=ath12k@lists.infradead.org \
--cc=linux-wireless@vger.kernel.org \
--cc=quic_dinek@quicinc.com \
--cc=quic_rgnanase@quicinc.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