Re: [PATCH v7 0/7] Qualcomm Sahara protocol enhancements

[Manivannan Sadhasivam]

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 <kishore.batta@xxxxxxxxxxxxxxxx>

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

-- 
மணிவண்ணன் சதாசிவம்