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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.