lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 26 Apr 2018 19:23:27 -0700
From:   Sujeev Dias <>
To:     Greg Kroah-Hartman <>,
        Arnd Bergmann <>
Cc:     Sujeev Dias <>,,, Tony Truong <>
Subject: MHI initial design review

Hi Greg Kroah-Hartman\All

This is the initial submit of Modem Host Interface (MHI) stack for upstream
consideration. MHI is a communication protocol to communicate with external
Qualcomm modems and Wi-Fi chipsets over high speed peripheral buses. Even
though MHI doesn’t dictate underlying physical layer, protocol and mhi stack
is structured for PCIe based devices.

For additional details related to MHI interface please see Documentation/mhi.txt.

MHI stack partitioned into three main components:
1. Core layer  handles all MHI protocol specific actions such as firmware download,
   and data transfer
2. Control layer  bus master, manages power transitions of external modem.
3. Device drivers  MHI channels (physical transport channels) exposed as mhi devices
   for clients to send and receive data.

There are three ways which clients can interface with MHI framework to send and receive
data from external modem.

1. Register directly with mhi core layer as a mhi device driver
2. User space clients can interface via mhi_uci driver.
3. For net traffic, mhi_netdev can be used.

Can you please do a high-level design review of the MHI driver and let me know if I need to
make any design changes before the drivers can be considered for upstream.



Powered by blists - more mailing lists