From: Kishore Batta <kishore.batta@oss.qualcomm.com>
To: Jeff Hugo <jeff.hugo@oss.qualcomm.com>,
Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
Carl Vanderlip <carl.vanderlip@oss.qualcomm.com>,
Oded Gabbay <ogabbay@kernel.org>,
Manivannan Sadhasivam <mani@kernel.org>,
andersson@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
Subject: Re: [PATCH v4 2/9] bus: mhi: Move sahara protocol driver under drivers/bus/mhi
Date: Mon, 13 Apr 2026 14:33:27 +0530 [thread overview]
Message-ID: <71ed19bc-30ef-486b-b587-03a2503c484a@oss.qualcomm.com> (raw)
In-Reply-To: <0a2af0d1-27da-4f60-952a-409a5abc5647@oss.qualcomm.com>
On 4/10/2026 1:50 AM, Jeff Hugo wrote:
> On 3/19/2026 12:31 AM, Kishore Batta wrote:
>> The Sahara protocol driver is currently located under the QAIC
>> accelerator subsystem even though protocol itself is transported over
>> the
>> MHI bus and is used by multiple Qualcomm flashless devices.
>>
>> Relocate the Sahara protocol driver to drivers/bus/mhi and register
>> it as
>> an independent MHI protocol driver. This avoids treating Sahara as QAIC
>> specific and makes it available for reuse by other MHI based devices.
>>
>> As part of this move, introduce a dedicated Kconfig and Makefile
>> under the
>> MHI subsystem and expose the sahara interface via a common header.
>
> I don't think this belongs under MHI. Mani needs to confirm that he
> agrees with the concept of moving this there.
>
> The Sahara protocol as defined by the spec does not require MHI. We
> know that there are Sahara implementations over USB. I don't see a
> dependency or relationship to MHI other than the current in-kernel
> implementation uses MHI, but there are plenty of things that use MHI
> (qaic, mhi-net, ath12k, etc) which are not a part of the MHI bus.
>
> The implementation presented in this series is not well integrated
> into MHI, which also suggests to me that it doesn't belong there. The
> Documentation is not integrated with MHI (which I mentioned over on
> that patch) and I see the header file (sahara.h) is also not integrated.
On Patch 1 series, I have got a review comment from Bjorn to have it
moved to drivers/bus/mhi as this implementation only supports MHI and is
going to be used with MHI. Hence the sahara driver is moved to this
directory. Do i need to move this to a different directory ? I will move
the Sahara documentation once we conclude on where Sahara driver needs
to be moved.
>
>> diff --git a/drivers/accel/qaic/qaic_drv.c
>> b/drivers/accel/qaic/qaic_drv.c
>> index
>> 63fb8c7b4abcbe4f1b76c32106f4e8b9ea5e2c8e..76cc8086825e7949ed756d51fcb56a08f392d228
>> 100644
>> --- a/drivers/accel/qaic/qaic_drv.c
>> +++ b/drivers/accel/qaic/qaic_drv.c
>> @@ -15,6 +15,7 @@
>> #include <linux/msi.h>
>> #include <linux/mutex.h>
>> #include <linux/pci.h>
>> +#include <linux/sahara.h>
>
> What do we need this for? register()/unregister() get removed.
ACK.I will remove it.
>
>> #include <linux/spinlock.h>
>> #include <linux/workqueue.h>
>> #include <linux/wait.h>
>> @@ -32,7 +33,6 @@
>> #include "qaic_ras.h"
>> #include "qaic_ssr.h"
>> #include "qaic_timesync.h"
>> -#include "sahara.h"
>> MODULE_IMPORT_NS("DMA_BUF");
>> @@ -782,18 +782,12 @@ static int __init qaic_init(void)
>> ret = pci_register_driver(&qaic_pci_driver);
>> if (ret) {
>> pr_debug("qaic: pci_register_driver failed %d\n", ret);
>> - return ret;
>> + goto free_pci;
>
> This is wrong, and there should not be a change here.
ACK. I will revert this change.
>
>> ret = mhi_driver_register(&qaic_mhi_driver);
>> if (ret) {
>> pr_debug("qaic: mhi_driver_register failed %d\n", ret);
>> - goto free_pci;
>> - }
>> -
>> - ret = sahara_register();
>> - if (ret) {
>> - pr_debug("qaic: sahara_register failed %d\n", ret);
>> goto free_mhi;
>
> This is also wrong
I want to make sure I understand the concern correctly before changing
the init flow. With Sahara now being a standalone MHI client driver
(moved out of QAIC and self registering), QAIC no longer calling
sahara_register() is intentional. However, removing that call also
removes an implicit init time dependency/failure gate. Is the objection
primarily about losing that gating / ordering guarantee or is there
another issue with removing the call itself ?
Once i understand that, I'll update the patches in the direction you prefer.
>
>> @@ -847,7 +841,6 @@ static void __exit qaic_exit(void)
>> qaic_ras_unregister();
>> qaic_bootlog_unregister();
>> qaic_timesync_deinit();
>> - sahara_unregister();
>> mhi_driver_unregister(&qaic_mhi_driver);
>> pci_unregister_driver(&qaic_pci_driver);
>> }
>> diff --git a/drivers/bus/mhi/Kconfig b/drivers/bus/mhi/Kconfig
>> index
>> b39a11e6c624ba00349cca22d74bd876020590ab..4acedb886adccc6f76f69c241d53106da59b491f
>> 100644
>> --- a/drivers/bus/mhi/Kconfig
>> +++ b/drivers/bus/mhi/Kconfig
>> @@ -7,3 +7,4 @@
>> source "drivers/bus/mhi/host/Kconfig"
>> source "drivers/bus/mhi/ep/Kconfig"
>> +source "drivers/bus/mhi/sahara/Kconfig"
>> diff --git a/drivers/bus/mhi/Makefile b/drivers/bus/mhi/Makefile
>> index
>> 354204b0ef3ae4030469a24a659f32429d592aef..e4af535e1bb1bc9481fae60d7eb347700d2e874c
>> 100644
>> --- a/drivers/bus/mhi/Makefile
>> +++ b/drivers/bus/mhi/Makefile
>> @@ -3,3 +3,6 @@ obj-$(CONFIG_MHI_BUS) += host/
>> # Endpoint MHI stack
>> obj-$(CONFIG_MHI_BUS_EP) += ep/
>> +
>> +# Sahara MHI protocol
>> +obj-$(CONFIG_MHI_SAHARA) += sahara/
>> diff --git a/drivers/bus/mhi/sahara/Kconfig
>> b/drivers/bus/mhi/sahara/Kconfig
>> new file mode 100644
>> index
>> 0000000000000000000000000000000000000000..3f1caf6acd979a4af68aaf0e250aa54762e8cda5
>> --- /dev/null
>> +++ b/drivers/bus/mhi/sahara/Kconfig
>> @@ -0,0 +1,18 @@
>> +config MHI_SAHARA
>> + tristate
>> + depends on MHI_BUS
>> + select FW_LOADER_COMPRESS
>
> Why are we selecting this? I don't see anyone else doing this. Sahara
> should work with and without firmware compression.
ACK. I will remove this.
>
>> + select FW_LOADER_COMPRESS_XZ
>> + select FW_LOADER_COMPRESS_ZSTD
>> + help
>> + Enable support for the Sahara protocol transported over the
>> MHI bus.
>> +
>> + The Sahara protocol is used to transfer firmware images, retrieve
>> + memory dumps and exchange command mode DDR calibration data
>> between
>> + host and device. This driver is not tied to a specific SoC and
>> may be
>> + used by multiple MHI based devices.
>> +
>> + If unsure, say N.
>> +
>> + To compile this driver as a module, choose M here: the module
>> will be
>> + called mhi_sahara.
>> diff --git a/drivers/bus/mhi/sahara/Makefile
>> b/drivers/bus/mhi/sahara/Makefile
>> new file mode 100644
>> index
>> 0000000000000000000000000000000000000000..fc02a25935011cbd7138ea8f24b88cf5b032a4ce
>> --- /dev/null
>> +++ b/drivers/bus/mhi/sahara/Makefile
>> @@ -0,0 +1,2 @@
>> +obj-$(CONFIG_MHI_SAHARA) += mhi_sahara.o
>> +mhi_sahara-y := sahara.o
>> diff --git a/drivers/accel/qaic/sahara.c
>> b/drivers/bus/mhi/sahara/sahara.c
>> similarity index 99%
>> rename from drivers/accel/qaic/sahara.c
>> rename to drivers/bus/mhi/sahara/sahara.c
>> index
>> fd3c3b2d1fd3bb698809e6ca669128e2dce06613..8ff7b6425ac5423ef8f32117151dca10397686a8
>> 100644
>> --- a/drivers/accel/qaic/sahara.c
>> +++ b/drivers/bus/mhi/sahara/sahara.c
>> @@ -1,6 +1,8 @@
>> -// SPDX-License-Identifier: GPL-2.0-only
>> -
>> -/* Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights
>> reserved. */
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (c) 2018-2020, The Linux Foundation. All rights reserved.
>> + *
>> + */
>
> What makes you think that changing the copyright markings is
> appropiate when moving a file?
>
> Furthermore, I wrote this code from scratch based on the spec document
> and therefore know beyond a doubt that this file did not exist prior
> to 2024, so what you are changing the markings to is completely invalid.
>
> Also the SPDX marking you are using is long deprecated and should not
> be used.
Sorry. I misunderstood the review comment that was given on v1 patchset.
Only the copyright style needs to match the subsystem where this driver
is moved to. I will make the changes in the next patch set.
>
>> #include <linux/devcoredump.h>
>> #include <linux/firmware.h>
>> @@ -9,12 +11,11 @@
>> #include <linux/minmax.h>
>> #include <linux/mod_devicetable.h>
>> #include <linux/overflow.h>
>> +#include <linux/sahara.h>
>> #include <linux/types.h>
>> #include <linux/vmalloc.h>
>> #include <linux/workqueue.h>
>> -#include "sahara.h"
>> -
>> #define SAHARA_HELLO_CMD 0x1 /* Min protocol version 1.0 */
>> #define SAHARA_HELLO_RESP_CMD 0x2 /* Min protocol version
>> 1.0 */
>> #define SAHARA_READ_DATA_CMD 0x3 /* Min protocol version
>> 1.0 */
>> @@ -928,8 +929,13 @@ int sahara_register(void)
>> {
>> return mhi_driver_register(&sahara_mhi_driver);
>> }
>> +module_init(sahara_register);
>> void sahara_unregister(void)
>> {
>> mhi_driver_unregister(&sahara_mhi_driver);
>> }
>> +module_exit(sahara_unregister);
>> +
>> +MODULE_LICENSE("GPL");
>> +MODULE_DESCRIPTION("Qualcomm Sahara MHI protocol driver");
>> diff --git a/drivers/accel/qaic/sahara.h b/include/linux/sahara.h
>> similarity index 100%
>> rename from drivers/accel/qaic/sahara.h
>> rename to include/linux/sahara.h
>>
>
next prev parent reply other threads:[~2026-04-13 9:03 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-19 6:31 [PATCH v4 0/9] Qualcomm Sahara protocol enhancements Kishore Batta
2026-03-19 6:31 ` [PATCH v4 1/9] Add documentation for Sahara protocol Kishore Batta
2026-04-09 19:47 ` Jeff Hugo
2026-04-13 9:03 ` Kishore Batta
2026-03-19 6:31 ` [PATCH v4 2/9] bus: mhi: Move sahara protocol driver under drivers/bus/mhi Kishore Batta
2026-04-09 20:20 ` Jeff Hugo
2026-04-13 9:03 ` Kishore Batta [this message]
2026-04-13 11:04 ` Manivannan Sadhasivam
2026-04-14 9:45 ` Kishore Batta
2026-04-13 11:20 ` Manivannan Sadhasivam
2026-04-14 9:48 ` Kishore Batta
2026-03-19 6:31 ` [PATCH v4 3/9] bus: mhi: Match devices exposing the protocol on the SAHARA channel Kishore Batta
2026-04-09 20:23 ` Jeff Hugo
2026-04-13 9:03 ` Kishore Batta
2026-03-19 6:31 ` [PATCH v4 4/9] bus: mhi: Centralize firmware image table selection at probe time Kishore Batta
2026-04-09 20:52 ` Jeff Hugo
2026-04-13 9:04 ` Kishore Batta
2026-04-13 11:26 ` Manivannan Sadhasivam
2026-04-14 9:49 ` Kishore Batta
2026-03-19 6:31 ` [PATCH v4 5/9] bus: mhi: Add QDU100 variant and image_id firmware fallback Kishore Batta
2026-04-09 21:14 ` Jeff Hugo
2026-04-13 11:34 ` Manivannan Sadhasivam
2026-04-14 9:51 ` Kishore Batta
2026-03-19 6:31 ` [PATCH v4 6/9] bus: mhi: Load DDR training data using per-device serial number Kishore Batta
2026-04-09 21:23 ` Jeff Hugo
2026-03-19 6:31 ` [PATCH v4 7/9] bus: mhi: Capture DDR training data using command mode Kishore Batta
2026-03-22 17:39 ` kernel test robot
2026-04-09 21:27 ` Jeff Hugo
2026-04-13 9:05 ` Kishore Batta
2026-03-19 6:31 ` [PATCH v4 8/9] bus: mhi: Expose DDR training data via controller sysfs Kishore Batta
2026-04-13 11:58 ` Manivannan Sadhasivam
2026-04-14 9:56 ` Kishore Batta
2026-03-19 6:31 ` [PATCH v4 9/9] Documentation: ABI: Add sysfs ABI documentation for DDR training data Kishore Batta
2026-04-09 21:30 ` Jeff Hugo
2026-04-13 9:05 ` Kishore Batta
2026-04-13 11:59 ` Manivannan Sadhasivam
2026-04-14 9:57 ` Kishore Batta
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=71ed19bc-30ef-486b-b587-03a2503c484a@oss.qualcomm.com \
--to=kishore.batta@oss.qualcomm.com \
--cc=andersson@kernel.org \
--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