public inbox for drm-ai-reviews@public-inbox.freedesktop.org
 help / color / mirror / Atom feed
From: Kishore Batta <kishore.batta@oss.qualcomm.com>
To: Jonathan Corbet <corbet@lwn.net>,
	Shuah Khan <skhan@linuxfoundation.org>,
	Jeff Hugo <jeff.hugo@oss.qualcomm.com>,
	Carl Vanderlip <carl.vanderlip@oss.qualcomm.com>,
	Oded Gabbay <ogabbay@kernel.org>,
	Manivannan Sadhasivam <mani@kernel.org>
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org,
	mhi@lists.linux.dev,
	Kishore Batta <kishore.batta@oss.qualcomm.com>
Subject: [PATCH v2 8/9] bus: mhi: Expose DDR training data via controller sysfs
Date: Sat, 07 Mar 2026 17:11:29 +0530	[thread overview]
Message-ID: <20260307-sahara_protocol_new_v2-v2-8-29dc748b5e9c@oss.qualcomm.com> (raw)
In-Reply-To: <20260307-sahara_protocol_new_v2-v2-0-29dc748b5e9c@oss.qualcomm.com>

DDR training data captured during Sahara command mode needs to be
accessible to userspace so it can be persisted and reused on subsequent
boots. Currently, the training data is stored internally in the driver
but has no external visibility once the sahara channel is torn down.

Expose the captured DDR training data via a read-only binary sysfs
attribute on the MHI controller device. The sysfs file is created under
the controller node, allowing userspace to read the training data even
after the sahara channel device has been removed.

The sysfs attribute reads directly from controller-scoped storage and
relies on device managed resources for cleanup when the controller
device is destroyed. No explicit sysfs removal is required, avoiding
lifetime dependencies on the Sahara channel device.

Signed-off-by: Kishore Batta <kishore.batta@oss.qualcomm.com>
---
 drivers/bus/mhi/sahara/sahara.c | 69 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 69 insertions(+)

diff --git a/drivers/bus/mhi/sahara/sahara.c b/drivers/bus/mhi/sahara/sahara.c
index 1eea93384724f559f3b6b78cb6a6e9a77cd5de6b..147bbe20c768198851ce78b9ea36867c554867be 100644
--- a/drivers/bus/mhi/sahara/sahara.c
+++ b/drivers/bus/mhi/sahara/sahara.c
@@ -404,6 +404,73 @@ static struct sahara_ctrl_trng_data *sahara_ctrl_trng_get(struct device *dev)
 	return ct;
 }
 
+static ssize_t ddr_training_data_read(struct file *filp, struct kobject *kobj,
+				      const struct bin_attribute *attr, char *buf,
+				      loff_t offset, size_t count)
+{
+	struct device *dev = kobj_to_dev(kobj);
+	struct sahara_ctrl_trng_data *ct;
+	size_t available;
+
+	ct = sahara_ctrl_trng_get(dev);
+	if (!ct)
+		return -ENODEV;
+
+	mutex_lock(&ct->lock);
+
+	/* No data yet or offset past end */
+	if (!ct->data || offset >= ct->size) {
+		mutex_unlock(&ct->lock);
+		return 0;
+	}
+
+	available = ct->size - offset;
+	count = min(count, available);
+	memcpy(buf, (u8 *)ct->data + offset, count);
+
+	mutex_unlock(&ct->lock);
+
+	return count;
+}
+
+static const struct bin_attribute ddr_training_data_attr = {
+	.attr = {
+		.name = "ddr_training_data",
+		.mode = 0444,
+	},
+	.read = ddr_training_data_read,
+};
+
+static void sahara_sysfs_devres_release(struct device *dev, void *res)
+{
+	device_remove_bin_file(dev, &ddr_training_data_attr);
+}
+
+static void sahara_sysfs_create(struct mhi_device *mhi_dev)
+{
+	struct device *dev = &mhi_dev->mhi_cntrl->mhi_dev->dev;
+	void *cookie;
+	int ret;
+
+	if (devres_find(dev, sahara_sysfs_devres_release, NULL, NULL))
+		return;
+
+	ret = device_create_bin_file(dev, &ddr_training_data_attr);
+	if (ret) {
+		dev_warn(&mhi_dev->dev,
+			 "Failed to create DDR training sysfs node (%d)\n", ret);
+		return;
+	}
+
+	cookie = devres_alloc(sahara_sysfs_devres_release, 1, GFP_KERNEL);
+	if (!cookie) {
+		device_remove_bin_file(dev, &ddr_training_data_attr);
+		return;
+	}
+
+	devres_add(dev, cookie);
+}
+
 static int sahara_find_image(struct sahara_context *context, u32 image_id)
 {
 	char *fw_path;
@@ -1249,6 +1316,8 @@ static int sahara_mhi_probe(struct mhi_device *mhi_dev, const struct mhi_device_
 		return ret;
 	}
 
+	sahara_sysfs_create(mhi_dev);
+
 	return 0;
 }
 

-- 
2.34.1


  parent reply	other threads:[~2026-03-07 11:42 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-07 11:41 [PATCH v2 0/9] Qualcomm Sahara protocol enhancements Kishore Batta
2026-03-07 11:41 ` [PATCH v2 1/9] Add documentation for Sahara protocol Kishore Batta
2026-03-07 19:50   ` kernel test robot
2026-03-08 22:09   ` Claude review: " Claude Code Review Bot
2026-03-07 11:41 ` [PATCH v2 2/9] bus: mhi: Move sahara protocol driver under drivers/bus/mhi Kishore Batta
2026-03-08 22:09   ` Claude review: " Claude Code Review Bot
2026-03-07 11:41 ` [PATCH v2 3/9] bus: mhi: Match devices exposing the protocol on the SAHARA channel Kishore Batta
2026-03-08 22:09   ` Claude review: " Claude Code Review Bot
2026-03-07 11:41 ` [PATCH v2 4/9] bus: mhi: Centralize firmware image table selection at probe time Kishore Batta
2026-03-08  8:56   ` kernel test robot
2026-03-08  9:27   ` kernel test robot
2026-03-08 22:09   ` Claude review: " Claude Code Review Bot
2026-03-07 11:41 ` [PATCH v2 5/9] bus: mhi: Add QDU100 firmware image table Kishore Batta
2026-03-08 22:09   ` Claude review: " Claude Code Review Bot
2026-03-07 11:41 ` [PATCH v2 6/9] bus: mhi: Load DDR training data using per-device serial number Kishore Batta
2026-03-08 22:09   ` Claude review: " Claude Code Review Bot
2026-03-07 11:41 ` [PATCH v2 7/9] bus: mhi: Capture DDR training data using command mode Kishore Batta
2026-03-08 22:09   ` Claude review: " Claude Code Review Bot
2026-03-07 11:41 ` Kishore Batta [this message]
2026-03-08 22:09   ` Claude review: bus: mhi: Expose DDR training data via controller sysfs Claude Code Review Bot
2026-03-07 11:41 ` [PATCH v2 9/9] Documentation: ABI: Add sysfs ABI documentation for DDR training data Kishore Batta
2026-03-08 22:09   ` Claude review: " Claude Code Review Bot
2026-03-08 22:08 ` Claude review: Qualcomm Sahara protocol enhancements Claude Code Review Bot

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=20260307-sahara_protocol_new_v2-v2-8-29dc748b5e9c@oss.qualcomm.com \
    --to=kishore.batta@oss.qualcomm.com \
    --cc=carl.vanderlip@oss.qualcomm.com \
    --cc=corbet@lwn.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jeff.hugo@oss.qualcomm.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mani@kernel.org \
    --cc=mhi@lists.linux.dev \
    --cc=ogabbay@kernel.org \
    --cc=skhan@linuxfoundation.org \
    /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