On 10/11/2026 10:03 PM, Manivannan Sadhasivam wrote:
On Thu, Oct 08, 2026 at 11:53:44AM +0530, Kishore Batta wrote:Hi All, This series reworks the Sahara protocol driver to make it reusable for multiple MHI based devices and adds support for capturing, restoring and exposing DDR training data using the Sahara command mode. The Sahara protocol is transported over the MHI bus and is used by multiple flashless devices to transfer firmware images, retrieve memory dumps and exchange command mode data during early boot. However, the current implementation lives under the QAIC accelerator driver and contains device-specific assumptions that limit reuse. Some MHI devices (for example, QDU100) expose the sahara protocol directly on a "SAHARA" MHI channel and rely on command mode to exchange DDR training data with the host. The existing driver does not bind to such devices and ignores Sahara command mode packets, causing training data to be dropped. This series addresses these issues by relocating the Sahara driver to the MHI subsystem, centralizing device specific configuration and adding command mode handling for DDR training data. Overview of the changes in this series - 1. Move Sahara under the MHI subsystem: a. Relocate the sahara protocol driver from QAIC accelerator tree to drivers/bus/mhi/host/clients directory. b. Register Sahara as an independent MHI protocol driver. 2. Generalize device matching and configuration a. Allow the driver to bind to devices exposing the protocol on a SAHARA MHI channel. b. Centralize firmware image table selection at probe time using a variant table, instead of scattered conditionals. c. Preserve existing behavior on AIC devices. 3. Add QDU100 firmware image table support a. Add a QDU100 image table and select it based on the matched MHI channel. b. No separate client driver or registration mechanism is required. 4. Add Sahara command mode support for DDR training. a. Handle command mode packets(CMD_READY, EXECUTE, EXECUTE_DATA). b. Query supported commands and retrieve DDR training data from the device. c. Allocate receive buffers based on the reported payload size and copy raw data from the MHI DL. d. Store training data in controller-scoped memory using devres so it survives sahara channel teardown. 5. Expose DDR training data to userspace a. Add a read-only binary sysfs attribute under the MHI controller device. b. The attribute reads directly from controller-scoped storage and remains available after the Sahara channel device is removed. c. Cleanup is handled automatically via device-managed resources. 6. Document the sysfs ABI a. Add ABI documentation describing the DDR training data sysfs node. Signed-off-by: Kishore Batta <[email protected]>Series fails to apply to mhi-next branch. Please rebase and resend. Since I'm about to send the PR for v7.4, this will miss the upcoming cycle. But I can queue it once v7.4-rc1 is released. - Mani
Sure Mani. I'll rebase the series onto the current mhi-next branch and resend it in v8 version.
