- 08 Apr, 2021 3 commits
-
-
Manivannan Sadhasivam authored
"mhi_controller_config" struct is not modified inside "mhi_pci_dev_info" struct. So constify the instances. Signed-off-by:Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
-
Jarvis Jiang authored
Add support for T99W175 modems, this modem series is based on SDX55 qcom chip. The modem is mainly based on MBIM protocol for both the data and control path. This patch adds support for below modems: - T99W175(based on sdx55), Both for eSIM and Non-eSIM - DW5930e(based on sdx55), With eSIM, It's also T99W175 - DW5930e(based on sdx55), Non-eSIM, It's also T99W175 This patch was tested with Ubuntu 20.04 X86_64 PC as host Signed-off-by:
Jarvis Jiang <jarvis.w.jiang@gmail.com> Reviewed-by:
Loic Poulain <loic.poulain@linaro.org> Reviewed-by:
-
Jeffrey Hugo authored
When parsing the structures in the shared memory, there are values which come from the remote device. For example, a transfer completion event will have a pointer to the tre in the relevant channel's transfer ring. As another example, event ring elements may specify a channel in which the event occurred, however the specified channel value may not be valid as no channel is defined at that index even though the index may be less than the maximum allowed index. Such values should be considered to be untrusted, and validated before use. If we blindly use such values, we may access invalid data or crash if the values are corrupted. If validation fails, drop the relevant event. Signed-off-by:
Jeffrey Hugo <jhugo@codeaurora.org> Reviewed-by:
Hemant Kumar <hemantk@codeaurora.org> Link: https://lore.kernel.org/r/1615411855-15053-1-git-send-email-jhugo@codeaurora.orgSigned-off-by:
-
- 07 Apr, 2021 15 commits
-
-
Loic Poulain authored
When device enters flash programmer context (FP), it exposes firehose protocol through the EDL dedicated channels. Signed-off-by:
-
Loic Poulain authored
Deinit the device on shutdown to halt MHI/PCI operation on device side. This change fixes floating device state with some hosts that do not fully shutdown PCIe device when rebooting. Signed-off-by:
-
Bhaumik Bhatt authored
The mhi_prepare_for_transfer() and mhi_unprepare_from_transfer() APIs could use better explanation. Add details on what MHI does when these APIs are used. Signed-off-by:
Bhaumik Bhatt <bbhatt@codeaurora.org> Reviewed-by:
-
Bhaumik Bhatt authored
The __mhi_unprepare_channel() API does not require the __ prefix. Get rid of it and make the internal function consistent with the other function names. Signed-off-by:
-
Bhaumik Bhatt authored
A client can attempt to unprepare certain channels for transfer even after the execution environment they are supposed to run in has changed. In the event that happens, the device need not be notified of the reset and the host can proceed with clean up for the channel context and memory allocated for it on the host as the device will no longer be able to respond to such a request. Signed-off-by:
-
Bhaumik Bhatt authored
When clearing up the channel context after client drivers are done using channels, the configuration is currently not being reset entirely. Ensure this is done to appropriately handle issues where clients unaware of the context state end up calling functions which expect a context. Signed-off-by:
-
Bhaumik Bhatt authored
MHI host can fail early if device is in a bad state by attempting to assert device wake and holding the runtime PM vote before sending a channel update command instead of performing a wake toggle and waiting for a timeout if the send were to fail. This can help improve the design and enable shorter wait periods for device to respond as votes are already held. Signed-off-by:
-
Bhaumik Bhatt authored
Debug messages dealing with client devices use the generic MHI controller or parent device along with a channel number. It would be better to instead use the client device directly and enable better log messages for channel updates. Suggested-by:
-
Bhaumik Bhatt authored
Improve the channel handling state machine such that all commands go through a common function and a validation process to ensure that the state machine is not violated in any way and adheres to the MHI specification. Using this common function allows MHI to eliminate some unnecessary debug messages and code duplication. Signed-off-by:
-
Bhaumik Bhatt authored
If a channel was explicitly stopped but not reset and a driver remove is issued, clean up the channel context such that it is reflected on the device. This move is useful if a client driver module is unloaded or a device crash occurs with the host having placed the channel in a stopped state. Signed-off-by:
-
Bhaumik Bhatt authored
Add support to allow sending the STOP channel command. If a client driver would like to STOP a channel and have the device retain the channel context instead of issuing a RESET to it and clearing the context, this would provide support for it after the ability to send this command is exposed to clients. Signed-off-by:
-
Bhaumik Bhatt authored
Add generic info for SDX65 based modems. Signed-off-by:
-
Bhaumik Bhatt authored
Some controllers can choose to skip preparation for power up. In that case, device context is initialized based on the pre_init flag not being set during mhi_prepare_for_power_up(). There is no reason MHI host driver should maintain and provide controllers with two separate paths for preparing MHI. Going forward, all controllers will be required to call the mhi_prepare_for_power_up() API followed by their choice of sync or async power up. This allows MHI host driver to get rid of the pre_init flag and sets up a common way for all controllers to use MHI. This also helps controllers fail early on during preparation phase in some failure cases. Signed-off-by:
-
Loic Poulain authored
Since M3 can be entered/exited quite a lot when used for runtime PM, keep the mhi suspend/resume transitions quiet. Signed-off-by:
-
Loic Poulain authored
This change ensures that PM reference is always get during packet queueing and released either after queuing completion (RX) or once the buffer has been consumed (TX). This guarantees proper update for underlying MHI controller runtime status (e.g. last_busy timestamp) and prevents suspend to be triggered while TX packets are flying, or before we completed update of the RX ring. Signed-off-by:
-
- 31 Mar, 2021 9 commits
-
-
Bhaumik Bhatt authored
In certain devices, it is likely that there is no incoming MHI interrupt for a transition to MHI READY state. One such example is the move from Pass Through to an SBL or AMSS execution environment. In order to facilitate faster bootup times as there is no need to wait until timeout_ms completes, MHI host can poll every 25 milliseconds to check if device has entered MHI READY until a maximum timeout of twice the timeout_ms is reached. Signed-off-by:
-
Bhaumik Bhatt authored
Introduce helper function to allow MHI core driver to poll for a value in a register field. This helps reach a common path to read and poll register values along with a retry time interval. Signed-off-by:
-
Bhaumik Bhatt authored
As of now abbreviations are being used for many state and execution environment strings. Improve and expand those such that debug messages are clear. Signed-off-by:
-
Bhaumik Bhatt authored
When moving from SYS_ERROR transition to a different execution environment, MHI host relies on the BHI register read to spawn the next image download or wait for READY -> M0 states. The device can at times move the execution environment to mission mode when a pass through is expected, which can result in a stall. Initiate a wait for MHI READY and write M0 such that the device can proceed with state change event updates for any new execution environment being entered. This allows us to remove conditionals in handling firmware load for PBL modes and keeps the execution environment out of the picture as it can change at any time. Signed-off-by:
-
Bhaumik Bhatt authored
MHI power up can go through an EDL to Flash Programmer path when the device has a blank NAND. In those cases, mhi_sync_power_up() can timeout waiting for a mission mode execution environment. Allow a successful power up instead by identifying Flash Programmer as a valid mission mode execution environment with a purpose to flash the device image contents. Signed-off-by:
-
Carl Yin authored
MHI WWAN modems support downloading firmware to NAND or eMMC using Firehose protocol with process as follows: 1. Modem boots up, enters AMSS execution environment and the device later enters EDL (Emergency Download) mode through any mechanism host can use such as a diag command. 2. Modem enters SYS_ERROR, MHI host handles SYS_ERROR transition. 3. EDL image for device to enter 'Flash Programmer' execution environment is then flashed via BHI interface from host. 4. Modem enters MHI READY -> M0 and sends the Flash Programmer execution environment change to host. 5. Following that, EDL/FIREHOSE channels (34, 35) are made available from the host. 6. User space tool for downloading firmware image to modem over the EDL channels using Firehose protocol. Link to USB flashing tool: https://git.linaro.org/landing-teams/working/qualcomm/qdl.git/ Make the necessary changes to allow for this sequence to occur and allow using the Flash Programmer execution environment. Signed-off-by:
Carl Yin <carl.yin@quectel.com> Co-developed-by:
-
Bhaumik Bhatt authored
Device entering EDL or Emergency Download Mode will be in a SYS_ERROR MHI state. This requires MHI host to proceed with the EDL image download over BHI before device can enter an MHI READY state and proceed with further bootup. Allow this to be handled by relying on the execution environment check after SYS_ERROR processing to determine whether to wait for an MHI READY or download the EDL image over BHI after moving MHI PM state to Power on Reset internally. This way handling is contained well within the MHI core driver and helps pave the way for Flash Programmer execution environment functionality. Signed-off-by:
-
Bhaumik Bhatt authored
Currently, the firmware load handler returns after the EDL image is downloaded. Wait for an MHI READY transition instead as the specification expects so as to proceed with further bootup such as device entering Flash Programmer execution environment. Signed-off-by:
-
Bhaumik Bhatt authored
Relying on the current execution environment to determine if EDL image was downloaded should not be done as the execution environment can change at this point in error cases and we may misread it. Instead, MHI can rely on the local 'fw_name' variable as a safer alternative. Signed-off-by:
-
- 16 Mar, 2021 2 commits
-
-
Jeffrey Hugo authored
We cannot process a power_down if the power state is DISABLED. There is no valid mhi_ctxt in that case, so attepting to process the power_down will likely result in a null pointer dereference. If the power state is DISABLED, there is nothing to do anyways, so just bail early. Signed-off-by:
-
Fan Wu authored
Currently ENOMEM is returned when MHI ring is full. This error code is very misleading. Change to EAGAIN instead. Signed-off-by:
Fan Wu <wufan@codeaurora.org> Signed-off-by:
-
- 15 Mar, 2021 1 commit
-
-
Colin Ian King authored
The variables state and ee are being initialized with values that are never read and are being updated later with a new values. The initializations are redundant and can be removed. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
Manivannan Sadhasivam <mani@kernel.org> Addresses-Coverity: ("Unused value") Link: https://lore.kernel.org/r/20210311111727.8433-1-colin.king@canonical.comSigned-off-by:
-
- 10 Mar, 2021 10 commits
-
-
Bhaumik Bhatt authored
Some controllers can opt to not have MHI download a firmware image to have the device bootup and can find the device in a pass through execution environment, ready to go. Thus, MHI controllers for those devices do not need fw_image defined. Make it optional to accommodate different bootup modes. Suggested-by:
-
Jeffrey Hugo authored
The check to see if we have reset the device after detecting syserr at power_up is inverted. wait_for_event_timeout() returns 0 on failure, and a positive value on success. The check is looking for non-zero as a failure, which is likely to incorrectly cause a device init failure if syserr was detected at power_up. Fix this. Fixes: e18d4e9f ("bus: mhi: core: Handle syserr during power_up") Signed-off-by:
-
Bhaumik Bhatt authored
Update debug prints to include local device in the BHI interrupt handler. This helps show transitions better between MHI states. Signed-off-by:
-
Bhaumik Bhatt authored
In current design, whenever the BHI interrupt is fired, the execution environment is updated. This can cause race conditions and impede ongoing power up/down processing. For example, if a power down is in progress, MHI host updates to a local "disabled" execution environment. If a BHI interrupt fires later, that value gets replaced with one from the BHI EE register. This impacts the controller as it does not expect multiple RDDM execution environment change status callbacks as an example. Another issue would be that the device can enter mission mode and the execution environment is updated, while device creation for SBL channels is still going on due to slower PM state worker thread run, leading to multiple attempts at opening the same channel. Ensure that EE changes are handled only from appropriate places and occur one after another and handle only PBL modes or RDDM EE changes as critical events directly from the interrupt handler. Simplify handling by waiting for SYS ERROR before handling RDDM. This also makes sure that we use the correct execution environment to notify the controller driver when the device resets to one of the PBL execution environments. Signed-off-by:
-
Bhaumik Bhatt authored
During full boot chain firmware download, the PM state worker downloads the AMSS image after a blocking wait for the SBL execution environment change when running in PBL transition itself. Improve this design by having the host download the AMSS image from the SBL transition of PM state worker thread when a DEV_ST_TRANSITION_SBL is queued instead of the blocking wait. Signed-off-by:
-
Bhaumik Bhatt authored
Currently, client devices are created in SBL or AMSS (mission mode) and only destroyed after power down or SYS ERROR. When moving between certain execution environments, such as from SBL to AMSS, no clean-up is required. This presents an issue where SBL-specific channels are left open and client drivers now run in an execution environment where they cannot operate. Fix this by expanding the mhi_destroy_device() to do an execution environment specific clean-up if one is requested. Close the gap and destroy devices in such scenarios that allow SBL client drivers to clean up once device enters mission mode. Signed-off-by:
-
Loic Poulain authored
MHI suspend/resume are symmetric and balanced procedures. If device is not in M3 state on a resume, that means something happened behind our back. In this case resume is aborted and error reported, to let the controller handle the situation. This is mainly requested for system wide suspend-resume operation in PCI context which may lead to power-down/reset of the controller which will then lose its MHI context. In such cases, PCI driver is supposed to recover and reinitialize the device. Signed-off-by:
-
Bhaumik Bhatt authored
As per documentation, fields marked as (required) in an MHI controller structure need to be populated by the controller driver before calling mhi_register_controller(). Ensure all required pointers and non-zero fields are present in the controller before proceeding with the registration. Signed-off-by:
-
Loic Poulain authored
Use MHI controller device name instead of the 'bus' device name as debugfs dir name (e.g. /sys/kernel/debug/mhi0). That aligns with sysfs device name. Signed-off-by:
-
Loic Poulain authored
mhi_queue returns an error when the doorbell is not accessible in the current state. This can happen when the device is in non M0 state, like M3, and needs to be waken-up prior ringing the DB. This case is managed earlier by triggering an asynchronous M3 exit via controller resume/suspend callbacks, that in turn will cause M0 transition and DB update. So, since it's not an error but just delaying of doorbell update, there is no reason to return an error. This also fixes a use after free error for skb case, indeed a caller queuing skb will try to free the skb if the queueing fails, but in that case queueing has been done. Fixes: a8f75cb3 ("mhi: core: Factorize mhi queuing") Signed-off-by:
-
