It can be useful to control the different power states of various
parts of hardware for device testing. Add a debugfs node for qmp so
messages can be sent to aoss for debugging and testing purposes.
Signed-off-by: Chris Lew <[email protected]>
Signed-off-by: Deepak Kumar Singh <[email protected]>
---
drivers/soc/qcom/qcom_aoss.c | 40 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/drivers/soc/qcom/qcom_aoss.c b/drivers/soc/qcom/qcom_aoss.c
index b84cb31..16e3d65 100644
--- a/drivers/soc/qcom/qcom_aoss.c
+++ b/drivers/soc/qcom/qcom_aoss.c
@@ -4,6 +4,7 @@
*/
#include <dt-bindings/power/qcom-aoss-qmp.h>
#include <linux/clk-provider.h>
+#include <linux/debugfs.h>
#include <linux/interrupt.h>
#include <linux/io.h>
#include <linux/mailbox_client.h>
@@ -86,6 +87,9 @@ struct qmp {
struct clk_hw qdss_clk;
struct genpd_onecell_data pd_data;
struct qmp_cooling_device *cooling_devs;
+#if IS_ENABLED(CONFIG_DEBUG_FS)
+ struct dentry *debugfs_file;
+#endif /* CONFIG_DEBUG_FS */
};
struct qmp_pd {
@@ -558,6 +562,33 @@ void qmp_put(struct qmp *qmp)
}
EXPORT_SYMBOL(qmp_put);
+#if IS_ENABLED(CONFIG_DEBUG_FS)
+static ssize_t aoss_dbg_write(struct file *file, const char __user *userstr,
+ size_t len, loff_t *pos)
+{
+ struct qmp *qmp = file->private_data;
+ char buf[QMP_MSG_LEN] = {};
+ int ret;
+
+ if (!len || len >= QMP_MSG_LEN)
+ return -EINVAL;
+
+ ret = copy_from_user(buf, userstr, len);
+ if (ret) {
+ return -EFAULT;
+ }
+
+ ret = qmp_send(qmp, buf, QMP_MSG_LEN);
+
+ return ret ? ret : len;
+}
+
+static const struct file_operations aoss_dbg_fops = {
+ .open = simple_open,
+ .write = aoss_dbg_write,
+};
+#endif /* CONFIG_DEBUG_FS */
+
static int qmp_probe(struct platform_device *pdev)
{
struct resource *res;
@@ -612,6 +643,11 @@ static int qmp_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, qmp);
+#if IS_ENABLED(CONFIG_DEBUG_FS)
+ qmp->debugfs_file = debugfs_create_file("aoss_send_message", 0220, NULL,
+ qmp, &aoss_dbg_fops);
+#endif /* CONFIG_DEBUG_FS */
+
return 0;
err_remove_qdss_clk:
@@ -628,6 +664,10 @@ static int qmp_remove(struct platform_device *pdev)
{
struct qmp *qmp = platform_get_drvdata(pdev);
+#if IS_ENABLED(CONFIG_DEBUG_FS)
+ debugfs_remove(qmp->debugfs_file);
+#endif /* CONFIG_DEBUG_FS */
+
qmp_qdss_clk_remove(qmp);
qmp_pd_remove(qmp);
qmp_cooling_devices_remove(qmp);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Quoting Deepak Kumar Singh (2021-08-05 04:12:54)
> It can be useful to control the different power states of various
> parts of hardware for device testing. Add a debugfs node for qmp so
> messages can be sent to aoss for debugging and testing purposes.
Is it ever useful after device testing? I'd prefer we not apply this
patch as it looks like testing code that won't ever be used after
developing this driver.
On 8/5/2021 11:58 PM, Stephen Boyd wrote:
> Quoting Deepak Kumar Singh (2021-08-05 04:12:54)
>> It can be useful to control the different power states of various
>> parts of hardware for device testing. Add a debugfs node for qmp so
>> messages can be sent to aoss for debugging and testing purposes.
> Is it ever useful after device testing? I'd prefer we not apply this
> patch as it looks like testing code that won't ever be used after
> developing this driver.
This is not only for testing. Some user space clients can also use this
to send messages to aoss.
One such example is setting higher ddr frequency during boot and
reducing it post boot from user space.
Quoting Deepak Kumar Singh (2021-08-30 04:46:53)
>
> On 8/5/2021 11:58 PM, Stephen Boyd wrote:
> > Quoting Deepak Kumar Singh (2021-08-05 04:12:54)
> >> It can be useful to control the different power states of various
> >> parts of hardware for device testing. Add a debugfs node for qmp so
> >> messages can be sent to aoss for debugging and testing purposes.
> > Is it ever useful after device testing? I'd prefer we not apply this
> > patch as it looks like testing code that won't ever be used after
> > developing this driver.
>
> This is not only for testing. Some user space clients can also use this
> to send messages to aoss.
>
> One such example is setting higher ddr frequency during boot and
> reducing it post boot from user space.
>
The debugfs file system should not be used by userspace to do things
like that. It's a debugging file system, not a configuration file
system. If you want to expose userspace control for this it needs to be
done in a different way.