Re: [PATCH v13 0/4] userspace MHI client interface driver
On Tue, Dec 08, 2020 at 10:29:27PM +0530, Manivannan Sadhasivam wrote: > 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. >From my experience in RDMA and netdev, I can't agree with both of your statements. There are a lot of people who see standardization as a bad thing. Also we are pushing even one person to make user visible interfaces right from the beginning without relation to how wide it will be adopted later. Thanks
Re: [PATCH v13 0/4] userspace MHI client interface driver
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.
Re: [PATCH v13 0/4] userspace MHI client interface driver
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. > > > > > > > > > > > > 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? > > > > No, but it's also not true that the only way to implement GPS is by > > opening a full on command/packet interface between fat proprietary > > firmware and custom user space (which may or may not be proprietary > > as well). > > Funny, that exactly what the GPS "API" in the kernel is, although a bit > limited to the specifics on the standardized GPS "sentences" and not > covering implementation specific configuration. > > > > > > > > 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? > > > > This conversation is going nowhere. Are you trying to say that creating > > a common Linux API for those features is impossible and each vendor > > should be allowed to add their own proprietary way? > > > > This has been proven incorrect again and again, and Wi-Fi is a good > > example. > > > > You can do whatever you want for GPS etc. but don't come nowhere near > > networking with this attitude please. > > > > No I'm saying (and Bjorn/Mani by the looks of things), that there is > commonality in the core features - IP traffic, Wi-Fi, etc but then there are > vendor specific things which are either things you don't actually want in > the kernel, don't want the kernel doing, or have little commonality between > vendors such that attempting to unify them gains you little to nothing. > > Over in the networking space, I can see where standardization is plenty > useful. > > I can't speak for other vendors, but a "modem" or a "wlan" device from > Qualcomm is not something that just provides one service. They tend to > provide dozens of different functionalities, some of those are > "standardized" like wi-fi where common wi-fi interfaces are used. Others are > unique to Qualcomm. > > The point is "wlan device" is a superset of "wi-fi". You seem to be > equating them to be the same in a "shoot first, ask questions later" manner. > > This series provides a way for userspace to talk to remote MHI "widgets" for > usecases not covered elsewhere. Those "widgets" just happen to commonly > provide modem/wlan services, but one
Re: [PATCH v13 0/4] userspace MHI client interface driver
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. 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? No, but it's also not true that the only way to implement GPS is by opening a full on command/packet interface between fat proprietary firmware and custom user space (which may or may not be proprietary as well). Funny, that exactly what the GPS "API" in the kernel is, although a bit limited to the specifics on the standardized GPS "sentences" and not covering implementation specific configuration. 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? This conversation is going nowhere. Are you trying to say that creating a common Linux API for those features is impossible and each vendor should be allowed to add their own proprietary way? This has been proven incorrect again and again, and Wi-Fi is a good example. You can do whatever you want for GPS etc. but don't come nowhere near networking with this attitude please. No I'm saying (and Bjorn/Mani by the looks of things), that there is commonality in the core features - IP traffic, Wi-Fi, etc but then there are vendor specific things which are either things you don't actually want in the kernel, don't want the kernel doing, or have little commonality between vendors such that attempting to unify them gains you little to nothing. Over in the networking space, I can see where standardization is plenty useful. I can't speak for other vendors, but a "modem" or a "wlan" device from Qualcomm is not something that just provides one service. They tend to provide dozens of different functionalities, some of those are "standardized" like wi-fi where common wi-fi interfaces are used. Others are unique to Qualcomm. The point is "wlan device" is a superset of "wi-fi". You seem to be equating them to be the same in a "shoot first, ask questions later" manner. This series provides a way for userspace to talk to remote MHI "widgets" for usecases not covered elsewhere. Those "widgets" just happen to commonly provide modem/wlan services, but ones that don't are not excluded. Regarding not coming near networking, I'd like to remind you it was you that decided to come over here to the non-networking area and try to make this about networking. -- Jeffrey Hugo Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH v13 0/4] userspace MHI client interface driver
On Tue 01 Dec 13:29 CST 2020, 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. > No, this allows exposing particular channels from any type of MHI devices. For modems there is a legacy control path that uses UCI. But data traffic, (non-legacy) modem control signals and e.g the bearer of GPS data uses in-kernel drivers that are already in place. > Why do WLAN devices need to communicate with user space? They normally don't, all WLAN operations are dealt with within the kernel. The use case that comes to mind for UCI when it comes to WiFi products is to avoid implementing the Qualcomm debug (diag) protocol in the kernel. As such I think saying that it can be used to communicate with modem or WLAN devices is misleading. Because while it could be done, it is only used for dealing with optional side-band services on such products - not the actual WiFi and modem functionality. Regards, Bjorn
Re: [PATCH v13 0/4] userspace MHI client interface driver
On Tue, Dec 01, 2020 at 12:03:02PM -0800, 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. > This is not for configuring the WiFi. This driver is mostly used for modems and the AI accelerator Jeff is working on. But there might be a usecase for WLAN devices as well to collect crash dumps and download fw (typical vendor ways) but having those features are add-ons IMO. So I think we should not be blocked by those usecases. Thanks, Mani
Re: [PATCH v13 0/4] userspace MHI client interface driver
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. > >>> > >>> 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? No, but it's also not true that the only way to implement GPS is by opening a full on command/packet interface between fat proprietary firmware and custom user space (which may or may not be proprietary as well). > >> 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? This conversation is going nowhere. Are you trying to say that creating a common Linux API for those features is impossible and each vendor should be allowed to add their own proprietary way? This has been proven incorrect again and again, and Wi-Fi is a good example. You can do whatever you want for GPS etc. but don't come nowhere near networking with this attitude please.
Re: [PATCH v13 0/4] userspace MHI client interface driver
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.
Re: [PATCH v13 0/4] userspace MHI client interface driver
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. > 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. > Off the top of my head, this driver is useful for modems, wlan, and AI > accelerators. And other Qualcomm products are available as well :/ Kernel is supposed to create abstract interfaces for user space to utilize. I will never understand why kernel is expected to be in business of shipping this sort of vendor backdoors :/
Re: [PATCH v13 0/4] userspace MHI client interface driver
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? 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. Off the top of my head, this driver is useful for modems, wlan, and AI accelerators. -- Jeffrey Hugo Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH v13 0/4] userspace MHI client interface driver
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?
[PATCH v13 0/4] userspace MHI client interface driver
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