This patch series adds support for UCI driver. UCI driver enables userspace
clients to communicate to external MHI devices like modem and WLAN. UCI driver
probe creates standard character device file nodes for userspace clients to
perform open, read, write, poll and release file operations. These file
operations call MHI core layer APIs to perform data transfer using MHI bus
to communicate with MHI device. Patch is tested using arm64 based platform.
V13:
- Removed LOOPBACK channel from mhi_device_id table from this patch series.
Pushing a new patch series to add support for LOOPBACK channel and the user
space test application. Also removed the description from kernel documentation.
- Added QMI channel to mhi_device_id table. QMI channel has existing libqmi
support from user space.
- Updated kernel Documentation for QMI channel and provided external reference
for libqmi.
- Updated device file node name by appending mhi device name only, which already
includes mhi controller device name.
V12:
- Added loopback test driver under selftest/drivers/mhi. Updated kernel
documentation for the usage of the loopback test application.
- Addressed review comments for renaming variable names, updated inline
comments and removed two redundant dev_dbg.
V11:
- Fixed review comments for UCI documentation by expanding TLAs and rewording
some sentences.
V10:
- Replaced mutex_lock with mutex_lock_interruptible in read() and write() file
ops call back.
V9:
- Renamed dl_lock to dl_pending _lock and pending list to dl_pending for
clarity.
- Used read lock to protect cur_buf.
- Change transfer status check logic and only consider 0 and -EOVERFLOW as
only success.
- Added __int to module init function.
- Print channel name instead of minor number upon successful probe.
V8:
- Fixed kernel test robot compilation error by changing %lu to %zu for
size_t.
- Replaced uci with UCI in Kconfig, commit text, and comments in driver
code.
- Fixed minor style related comments.
V7:
- Decoupled uci device and uci channel objects. uci device is
associated with device file node. uci channel is associated
with MHI channels. uci device refers to uci channel to perform
MHI channel operations for device file operations like read()
and write(). uci device increments its reference count for
every open(). uci device calls mhi_uci_dev_start_chan() to start
the MHI channel. uci channel object is tracking number of times
MHI channel is referred. This allows to keep the MHI channel in
start state until last release() is called. After that uci channel
reference count goes to 0 and uci channel clean up is performed
which stops the MHI channel. After the last call to release() if
driver is removed uci reference count becomes 0 and uci object is
cleaned up.
- Use separate uci channel read and write lock to fine grain locking
between reader and writer.
- Use uci device lock to synchronize open, release and driver remove.
- Optimize for downlink only or uplink only UCI device.
V6:
- Moved uci.c to mhi directory.
- Updated Kconfig to add module information.
- Updated Makefile to rename uci object file name as mhi_uci
- Removed kref for open count
V5:
- Removed mhi_uci_drv structure.
- Used idr instead of creating global list of uci devices.
- Used kref instead of local ref counting for uci device and
open count.
- Removed unlikely macro.
V4:
- Fix locking to protect proper struct members.
- Updated documentation describing uci client driver use cases.
- Fixed uci ref counting in mhi_uci_open for error case.
- Addressed style related review comments.
V3: Added documentation for MHI UCI driver.
V2:
- Added mutex lock to prevent multiple readers to access same
- mhi buffer which can result into use after free.
Hemant Kumar (4):
bus: mhi: core: Add helper API to return number of free TREs
bus: mhi: core: Move MHI_MAX_MTU to external header file
docs: Add documentation for userspace client interface
bus: mhi: Add userspace client interface driver
Documentation/mhi/index.rst | 1 +
Documentation/mhi/uci.rst | 94 ++++++
drivers/bus/mhi/Kconfig | 13 +
drivers/bus/mhi/Makefile | 3 +
drivers/bus/mhi/core/internal.h | 1 -
drivers/bus/mhi/core/main.c | 12 +
drivers/bus/mhi/uci.c | 665 ++++++++++++++++++++++++++++++++++++++++
include/linux/mhi.h | 12 +
8 files changed, 800 insertions(+), 1 deletion(-)
create mode 100644 Documentation/mhi/uci.rst
create mode 100644 drivers/bus/mhi/uci.c
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Introduce mhi_get_free_desc_count() API to return number
of TREs available to queue buffer. MHI clients can use this
API to know before hand if ring is full without calling queue
API.
Signed-off-by: Hemant Kumar <[email protected]>
Reviewed-by: Jeffrey Hugo <[email protected]>
Reviewed-by: Manivannan Sadhasivam <[email protected]>
---
drivers/bus/mhi/core/main.c | 12 ++++++++++++
include/linux/mhi.h | 9 +++++++++
2 files changed, 21 insertions(+)
diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
index 4eb93d8..defd579a 100644
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@ -260,6 +260,18 @@ int mhi_destroy_device(struct device *dev, void *data)
return 0;
}
+int mhi_get_free_desc_count(struct mhi_device *mhi_dev,
+ enum dma_data_direction dir)
+{
+ struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;
+ struct mhi_chan *mhi_chan = (dir == DMA_TO_DEVICE) ?
+ mhi_dev->ul_chan : mhi_dev->dl_chan;
+ struct mhi_ring *tre_ring = &mhi_chan->tre_ring;
+
+ return get_nr_avail_ring_elements(mhi_cntrl, tre_ring);
+}
+EXPORT_SYMBOL_GPL(mhi_get_free_desc_count);
+
void mhi_notify(struct mhi_device *mhi_dev, enum mhi_callback cb_reason)
{
struct mhi_driver *mhi_drv;
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index d31efcf..b3bc966 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -597,6 +597,15 @@ void mhi_set_mhi_state(struct mhi_controller *mhi_cntrl,
void mhi_notify(struct mhi_device *mhi_dev, enum mhi_callback cb_reason);
/**
+ * mhi_get_free_desc_count - Get transfer ring length
+ * Get # of TD available to queue buffers
+ * @mhi_dev: Device associated with the channels
+ * @dir: Direction of the channel
+ */
+int mhi_get_free_desc_count(struct mhi_device *mhi_dev,
+ enum dma_data_direction dir);
+
+/**
* mhi_prepare_for_power_up - Do pre-initialization before power up.
* This is optional, call this before power up if
* the controller does not want bus framework to
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
MHI userspace client driver is creating device file node
for user application to perform file operations. File
operations are handled by MHI core driver. Currently
QMI MHI channel is supported by this driver.
Signed-off-by: Hemant Kumar <[email protected]>
---
Documentation/mhi/index.rst | 1 +
Documentation/mhi/uci.rst | 94 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 95 insertions(+)
create mode 100644 Documentation/mhi/uci.rst
diff --git a/Documentation/mhi/index.rst b/Documentation/mhi/index.rst
index 1d8dec3..c75a371 100644
--- a/Documentation/mhi/index.rst
+++ b/Documentation/mhi/index.rst
@@ -9,6 +9,7 @@ MHI
mhi
topology
+ uci
.. only:: subproject and html
diff --git a/Documentation/mhi/uci.rst b/Documentation/mhi/uci.rst
new file mode 100644
index 0000000..ad22650
--- /dev/null
+++ b/Documentation/mhi/uci.rst
@@ -0,0 +1,94 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=================================
+Userspace Client Interface (UCI)
+=================================
+
+UCI driver enables userspace clients to communicate to external MHI devices
+like modem and WLAN. UCI driver probe creates standard character device file
+nodes for userspace clients to perform open, read, write, poll and release file
+operations. UCI device object represents UCI device file node which gets
+instantiated as part of MHI UCI driver probe. UCI channel object represents
+MHI uplink or downlink channel.
+
+Operations
+==========
+
+open
+----
+
+Instantiates UCI channel object and starts MHI channels to move it to running
+state. Inbound buffers are queued to downlink channel transfer ring. Every
+subsequent open() increments UCI device reference count as well as UCI channel
+reference count.
+
+read
+----
+
+When data transfer is completed on downlink channel, transfer ring element
+buffer is copied to pending list. Reader is unblocked and data is copied to
+userspace buffer. Transfer ring element buffer is queued back to downlink
+channel transfer ring.
+
+write
+-----
+
+Write buffer is queued to uplink channel transfer ring if ring is not full. Upon
+uplink transfer completion buffer is freed.
+
+poll
+----
+
+Returns EPOLLIN | EPOLLRDNORM mask if pending list has buffers to be read by
+userspace. Returns EPOLLOUT | EPOLLWRNORM mask if MHI uplink channel transfer
+ring is not empty. Returns EPOLLERR when UCI driver is removed.
+
+release
+-------
+
+Decrements UCI device reference count and UCI channel reference count upon last
+release(). UCI channel clean up is performed. MHI channel moves to disable
+state and inbound buffers are freed.
+
+Usage
+=====
+
+Device file node is created with format:-
+
+/dev/mhi_<mhi_device_name>
+
+mhi_device_name includes mhi controller name and the name of the MHI channel
+being used by MHI client in userspace to send or receive data using MHI
+protocol.
+
+There is a separate character device file node created for each channel
+specified in MHI device id table. MHI channels are statically defined by MHI
+specification. The list of supported channels is in the channel list variable
+of mhi_device_id table in UCI driver.
+
+Qualcomm MSM Interface(QMI) Channel
+-----------------------------------
+
+Qualcomm MSM Interface(QMI) is a modem control messaging protocol used to
+communicate between software components in the modem and other peripheral
+subsystems. QMI communication is of request/response type or an unsolicited
+event type. libqmi is userspace MHI client which communicates to a QMI service
+using UCI device. It sends a QMI request to a QMI service using MHI channel 14
+or 16. QMI response is received using MHI channel 15 or 17 respectively. libqmi
+is a glib-based library for talking to WWAN modems and devices which speaks QMI
+protocol. For more information about libqmi please refer
+https://www.freedesktop.org/wiki/Software/libqmi/
+
+Usage Example
+~~~~~~~~~~~~~
+
+QMI command to retrieve device mode
+$ sudo qmicli -d /dev/mhi_0000\:02\:00.0_QMI --dms-get-model
+[/dev/mhi_0000:02:00.0_QMI] Device model retrieved:
+ Model: 'FN980m'
+
+Other Use Cases
+---------------
+
+Getting MHI device specific diagnostics information to userspace MHI diagnostic
+client using DIAG channel 4 (Host to device) and 5 (Device to Host).
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Currently this macro is defined in internal MHI header as
a TRE length mask. Moving it to external header allows MHI
client drivers to set this upper bound for the transmit
buffer size.
Signed-off-by: Hemant Kumar <[email protected]>
Reviewed-by: Jeffrey Hugo <[email protected]>
Reviewed-by: Manivannan Sadhasivam <[email protected]>
---
drivers/bus/mhi/core/internal.h | 1 -
include/linux/mhi.h | 3 +++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/bus/mhi/core/internal.h b/drivers/bus/mhi/core/internal.h
index 6f80ec3..2b9c063 100644
--- a/drivers/bus/mhi/core/internal.h
+++ b/drivers/bus/mhi/core/internal.h
@@ -453,7 +453,6 @@ enum mhi_pm_state {
#define CMD_EL_PER_RING 128
#define PRIMARY_CMD_RING 0
#define MHI_DEV_WAKE_DB 127
-#define MHI_MAX_MTU 0xffff
#define MHI_RANDOM_U32_NONZERO(bmsk) (prandom_u32_max(bmsk) + 1)
enum mhi_er_type {
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index b3bc966..fc903b2 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -15,6 +15,9 @@
#include <linux/wait.h>
#include <linux/workqueue.h>
+/* MHI client drivers to set this upper bound for tx buffer */
+#define MHI_MAX_MTU 0xffff
+
#define MHI_MAX_OEM_PK_HASH_SEGMENTS 16
struct mhi_chan;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
On Fri, 27 Nov 2020 19:26:02 -0800 Hemant Kumar wrote:
> This patch series adds support for UCI driver. UCI driver enables userspace
> clients to communicate to external MHI devices like modem and WLAN. UCI driver
> probe creates standard character device file nodes for userspace clients to
> perform open, read, write, poll and release file operations. These file
> operations call MHI core layer APIs to perform data transfer using MHI bus
> to communicate with MHI device. Patch is tested using arm64 based platform.
Wait, I thought this was for modems.
Why do WLAN devices need to communicate with user space?
On 12/1/2020 1:03 PM, Jakub Kicinski wrote:
> On Tue, 1 Dec 2020 12:40:50 -0700 Jeffrey Hugo wrote:
>> On 12/1/2020 12:29 PM, Jakub Kicinski wrote:
>>> On Fri, 27 Nov 2020 19:26:02 -0800 Hemant Kumar wrote:
>>>> This patch series adds support for UCI driver. UCI driver enables userspace
>>>> clients to communicate to external MHI devices like modem and WLAN. UCI driver
>>>> probe creates standard character device file nodes for userspace clients to
>>>> perform open, read, write, poll and release file operations. These file
>>>> operations call MHI core layer APIs to perform data transfer using MHI bus
>>>> to communicate with MHI device. Patch is tested using arm64 based platform.
>>>
>>> Wait, I thought this was for modems.
>>>
>>> Why do WLAN devices need to communicate with user space?
>>>
>>
>> Why does it matter what type of device it is? Are modems somehow unique
>> in that they are the only type of device that userspace is allowed to
>> interact with?
>
> Yes modems are traditionally highly weird and require some serial
> device dance I don't even know about.
>
> We have proper interfaces in Linux for configuring WiFi which work
> across vendors. Having char device access to WiFi would be a step
> back.
So a WLAN device is only ever allowed to do Wi-Fi? It can't also have
GPS functionality for example?
>
>> However, I'll bite. Once such usecase would be QMI. QMI is a generic
>> messaging protocol, and is not strictly limited to the unique operations
>> of a modem.
>>
>> Another usecase would be Sahara - a custom file transfer protocol used
>> for uploading firmware images, and downloading crashdumps.
>
> Thanks, I was asking for use cases, not which proprietary vendor
> protocol you can implement over it.
>
> None of the use cases you mention here should require a direct FW -
> user space backdoor for WLAN.
Uploading runtime firmware, with variations based on the runtime mode.
Flashing the onboard flash based on cryptographic keys. Accessing
configuration data. Accessing device logs. Configuring device logs.
Synchronizing the device time reference to Linux local or remote time
sources. Enabling debugging/performance hardware. Getting software
diagnostic events. Configuring redundancy hardware per workload.
Uploading new cryptographic keys. Invalidating cryptographic keys.
Uploading factory test data and running factory tests.
Need more?
--
Jeffrey Hugo
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
On Sun, Dec 06, 2020 at 10:33:02AM +0200, Leon Romanovsky wrote:
> On Tue, Dec 01, 2020 at 09:59:53PM -0700, Jeffrey Hugo wrote:
> > On 12/1/2020 7:55 PM, Jakub Kicinski wrote:
> > > On Tue, 1 Dec 2020 13:48:36 -0700 Jeffrey Hugo wrote:
> > > > On 12/1/2020 1:03 PM, Jakub Kicinski wrote:
> > > > > On Tue, 1 Dec 2020 12:40:50 -0700 Jeffrey Hugo wrote:
> > > > > > On 12/1/2020 12:29 PM, Jakub Kicinski wrote:
> > > > > > > On Fri, 27 Nov 2020 19:26:02 -0800 Hemant Kumar wrote:
> > > > > > > > This patch series adds support for UCI driver. UCI driver enables userspace
> > > > > > > > clients to communicate to external MHI devices like modem and WLAN. UCI driver
> > > > > > > > probe creates standard character device file nodes for userspace clients to
> > > > > > > > perform open, read, write, poll and release file operations. These file
> > > > > > > > operations call MHI core layer APIs to perform data transfer using MHI bus
> > > > > > > > to communicate with MHI device. Patch is tested using arm64 based platform.
> > > > > > >
> > > > > > > Wait, I thought this was for modems.
> > > > > > >
[...]
> Like it or not, but Jakub is absolutely right with his claim that
> providing user-visible interfaces without any standardization is proven
> as wrong.
>
Everybody agrees with standardizing things but the problem is, the
standardization will only happen when more than one person implements the
same functionality.
The primary discussion is around the usage of chardev nodes for WLAN but
we made it clear that WLAN doesn't need this chardev node for working at
all. I agree that the commit message is a bit misleading and I hope that
Hemant will fix it in next revision.
Thanks,
Mani
> Thanks
>
> >
> > --
> > Jeffrey Hugo
> > Qualcomm Technologies, Inc. is a member of the
> > Code Aurora Forum, a Linux Foundation Collaborative Project.