bus: mhi: host: Remove unused functions

mhi_device_get() and mhi_queue_dma() haven't been used since 2020's
commit 189ff97cca53 ("bus: mhi: core: Add support for data transfer")
added them.

Remove

bus: mhi: host: Remove unused functions

mhi_device_get() and mhi_queue_dma() haven't been used since 2020's
commit 189ff97cca53 ("bus: mhi: core: Add support for data transfer")
added them.

Remove them.

Note that mhi_queue_dma_sync() is used and has been left.

Signed-off-by: Dr. David Alan Gilbert <[email protected]>
Reviewed-by: Manivannan Sadhasivam <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Manivannan Sadhasivam <[email protected]>

show more ...

bus: mhi: host: Allow controller drivers to specify name for the MHI controller

MHI devices usually have a product/device name to identify each device
uniquely. So let's specify that name in 'struct

bus: mhi: host: Allow controller drivers to specify name for the MHI controller

MHI devices usually have a product/device name to identify each device
uniquely. So let's specify that name in 'struct mhi_controller' so that the
client drivers can use this name to uniquely identify the devices and apply
any device specific quirks.

Signed-off-by: Slark Xiao <[email protected]>
Reviewed-by: Manivannan Sadhasivam <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[mani: reworked subject and description]
Signed-off-by: Manivannan Sadhasivam <[email protected]>

show more ...

driver core: have match() callback in struct bus_type take a const *

In the match() callback, the struct device_driver * should not be
changed, so change the function callback to be a const *. This

driver core: have match() callback in struct bus_type take a const *

In the match() callback, the struct device_driver * should not be
changed, so change the function callback to be a const *. This is one
step of many towards making the driver core safe to have struct
device_driver in read-only memory.

Because the match() callback is in all busses, all busses are modified
to handle this properly. This does entail switching some container_of()
calls to container_of_const() to properly handle the constant *.

For some busses, like PCI and USB and HV, the const * is cast away in
the match callback as those busses do want to modify those structures at
this point in time (they have a local lock in the driver structure.)
That will have to be changed in the future if they wish to have their
struct device * in read-only-memory.

Cc: Rafael J. Wysocki <[email protected]>
Reviewed-by: Alex Elder <[email protected]>
Acked-by: Sumit Garg <[email protected]>
Link: https://lore.kernel.org/r/2024070136-wrongdoer-busily-01e8@gregkh
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

bus: mhi: host: Add a new API for getting channel doorbell offset

Some controllers may want to access a specific doorbell register. Hence add
a new API that reads the CHDBOFF register and returns th

bus: mhi: host: Add a new API for getting channel doorbell offset

Some controllers may want to access a specific doorbell register. Hence add
a new API that reads the CHDBOFF register and returns the offset of the
doorbell registers from MMIO base, so that the controller can calculate the
address of the specific doorbell register by adding the register offset
with doorbell offset and MMIO base address.

Signed-off-by: Qiang Yu <[email protected]>
Reviewed-by: Jeffrey Hugo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[mani: reworded commit message and Kdoc]
Signed-off-by: Manivannan Sadhasivam <[email protected]>

show more ...

bus: mhi: host: Add sysfs entry to force device to enter EDL

Add sysfs entry to allow users of MHI bus to force device to enter EDL
(Emergency Download) mode to download the device firmware. Since t

bus: mhi: host: Add sysfs entry to force device to enter EDL

Add sysfs entry to allow users of MHI bus to force device to enter EDL
(Emergency Download) mode to download the device firmware. Since there is
no guarantee that all the devices will support EDL mode, the sysfs entry
is kept as an optional one and will appear only for the supported devices.

Controllers supporting the EDL mode are expected to provide edl_trigger()
callback that puts the device into EDL mode.

Signed-off-by: Qiang Yu <[email protected]>
Reviewed-by: Jeffrey Hugo <[email protected]>
Reviewed-by: Manivannan Sadhasivam <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[mani: fixed the kernel version and reworded the commit message]
Signed-off-by: Manivannan Sadhasivam <[email protected]>

show more ...

bus: mhi: host: Add mhi_power_down_keep_dev() API to support system suspend/hibernation

Currently, ath11k fails to resume from system suspend/hibernation on some
the x86 host machines with below err

bus: mhi: host: Add mhi_power_down_keep_dev() API to support system suspend/hibernation

Currently, ath11k fails to resume from system suspend/hibernation on some
the x86 host machines with below error message:

```
ath11k_pci 0000:06:00.0: timeout while waiting for restart complete
```

This happens because, ath11k powers down the MHI stack during suspend and
that leads to destruction of the struct device associated with the MHI
channels. And during resume, ath11k calls calling mhi_sync_power_up() to
power up the MHI subsystem and that eventually calls the driver framework's
device_add() API from mhi_create_devices(). But the PM framework blocks the
struct device creation during device_add() and this leads to probe deferral
as below:

```
mhi mhi0_IPCR: Driver qcom_mhi_qrtr force probe deferral
```

The reason for deferring device creation during resume is explained in
dpm_prepare():

/*
* It is unsafe if probing of devices will happen during suspend or
* hibernation and system behavior will be unpredictable in this
* case. So, let's prohibit device's probing here and defer their
* probes instead. The normal behavior will be restored in
* dpm_complete().
*/

Due to the device probe deferral, qcom_mhi_qrtr_probe() API is not getting
called during resume and thus MHI channels are not prepared. So this blocks
the QMI messages from being transferred between ath11k and firmware,
resulting in a firmware initialization failure.

After consulting with Rafael, it was decided to not destroy the struct
device for the MHI channels during system suspend/hibernation because the
device is bound to appear again during resume.

So to achieve this, a new API called mhi_power_down_keep_dev() is
introduced for MHI controllers to keep the struct device when required.
This API is similar to the existing mhi_power_down() API, except that it
keeps the struct device associated with MHI channels instead of destroying
them.

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30

Signed-off-by: Baochen Qiang <[email protected]>
Reviewed-by: Manivannan Sadhasivam <[email protected]>
Reviewed-by: Jeff Johnson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[mani: reworded the commit message and subject]
Signed-off-by: Manivannan Sadhasivam <[email protected]>

show more ...

Revert "bus: mhi: core: Add support for reading MHI info from device"

This reverts commit 3316ab2b45f6bf4797d8d65b22fda3cc13318890.

The MHI spec owner pointed out that the SOC_HW_VERSION register i

Revert "bus: mhi: core: Add support for reading MHI info from device"

This reverts commit 3316ab2b45f6bf4797d8d65b22fda3cc13318890.

The MHI spec owner pointed out that the SOC_HW_VERSION register is part
of the BHIe segment, and only valid on devices which implement BHIe.
Only a small subset of MHI devices implement BHIe so blindly accessing
the register for all devices is not correct. Also, since the BHIe
segment offset is not used when accessing the register, any
implementation which moves the BHIe segment will result in accessing
some other register. We've seen that accessing this register on AIC100
which does not support BHIe can result in initialization failures.

We could try to put checks into the code to address these issues, but in
the roughly 4 years this functionality has existed, no one has used it.
Easier to drop this dead code and address the issues if anyone comes up
with a real world use for it.

Signed-off-by: Jeffrey Hugo <[email protected]>
Reviewed-by: Manivannan Sadhasivam <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Manivannan Sadhasivam <[email protected]>

show more ...

bus: mhi: host: Read PK HASH dynamically

The OEM PK HASH registers in the BHI region are read once during firmware
load (boot), cached, and displayed on demand via sysfs. This has a few
problems - i

bus: mhi: host: Read PK HASH dynamically

The OEM PK HASH registers in the BHI region are read once during firmware
load (boot), cached, and displayed on demand via sysfs. This has a few
problems - if firmware load is skipped, the registers will not be read and
if the register values change over the life of the device the local cache
will be out of sync.

Qualcomm Cloud AI 100 can expose both these problems. It is possible for
mhi_async_power_up() to be invoked while the device is in AMSS EE, which
would bypass firmware loading. Also, Qualcomm Cloud AI 100 has 5 PK HASH
slots which can be dynamically provisioned while the device is active,
which would result in the values changing and users may want to know what
keys are active.

Address these concerns by reading the PK HASH registers on-demand during
the sysfs read. This will result in showing the most current information.

Signed-off-by: Jeffrey Hugo <[email protected]>
Reviewed-by: Pranjal Ramajor Asha Kanojiya <[email protected]>
Reviewed-by: Manivannan Sadhasivam <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Manivannan Sadhasivam <[email protected]>

show more ...

bus: mhi: host: Add a separate timeout parameter for waiting ready

Some devices(eg. SDX75) take longer than expected (default, 8 seconds) to
set ready after reboot. Hence add optional ready timeout

bus: mhi: host: Add a separate timeout parameter for waiting ready

Some devices(eg. SDX75) take longer than expected (default, 8 seconds) to
set ready after reboot. Hence add optional ready timeout parameter and pass
the appropriate timeout value to mhi_poll_reg_field() to wait enough for
device ready as part of power up sequence.

Signed-off-by: Qiang Yu <[email protected]>
Reviewed-by: Manivannan Sadhasivam <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Manivannan Sadhasivam <[email protected]>

show more ...

bus: mhi: host: allow MHI client drivers to provide the firmware via a pointer

Currently MHI loads the firmware image from the path provided by client
devices. ath11k needs to support firmware image

bus: mhi: host: allow MHI client drivers to provide the firmware via a pointer

Currently MHI loads the firmware image from the path provided by client
devices. ath11k needs to support firmware image embedded along with meta
data (named as firmware-2.bin). So allow the client driver to request the
firmware file from user space on it's own and provide the firmware image
data and size to MHI via a pointer struct mhi_controller::fw_data.

This is an optional feature, if fw_data is NULL MHI load the firmware using
the name from struct mhi_controller::fw_image string as before.

Tested with ath11k and WCN6855 hw2.0.

Signed-off-by: Kalle Valo <[email protected]>
Reviewed-by: Manivannan Sadhasivam <[email protected]>
Reviewed-by: Jeffrey Hugo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[mani: wrapped commit message to 75 columns]
Signed-off-by: Manivannan Sadhasivam <[email protected]>

show more ...

bus: mhi: host: Remove mhi_poll() API

mhi_poll() API is not used within the MHI stack and also not by any client
drivers in mainline. So let's remove it until any consumer is available.

Reviewed-by

bus: mhi: host: Remove mhi_poll() API

mhi_poll() API is not used within the MHI stack and also not by any client
drivers in mainline. So let's remove it until any consumer is available.

Reviewed-by: Jeffrey Hugo <[email protected]>
Signed-off-by: Manivannan Sadhasivam <[email protected]>

show more ...

bus: mhi: core: Add an API for auto queueing buffers for DL channel

Add a new API "mhi_prepare_for_transfer_autoqueue" for using with client
drivers like QRTR to request MHI core to autoqueue buffer

bus: mhi: core: Add an API for auto queueing buffers for DL channel

Add a new API "mhi_prepare_for_transfer_autoqueue" for using with client
drivers like QRTR to request MHI core to autoqueue buffers for the DL
channel along with starting both UL and DL channels.

So far, the "auto_queue" flag specified by the controller drivers in
channel definition served this purpose but this will be removed at some
point in future.

Cc: [email protected]
Cc: Jakub Kicinski <[email protected]>
Cc: David S. Miller <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Co-developed-by: Loic Poulain <[email protected]>
Acked-by: Jakub Kicinski <[email protected]>
Signed-off-by: Loic Poulain <[email protected]>
Signed-off-by: Manivannan Sadhasivam <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

bus: mhi: core: Add support for forced PM resume

For whatever reason, some devices like QCA6390, WCN6855 using ath11k
are not in M3 state during PM resume, but still functional. The
mhi_pm_resume sh

bus: mhi: core: Add support for forced PM resume

For whatever reason, some devices like QCA6390, WCN6855 using ath11k
are not in M3 state during PM resume, but still functional. The
mhi_pm_resume should then not fail in those cases, and let the higher
level device specific stack continue resuming process.

Add an API mhi_pm_resume_force(), to force resuming irrespective of the
current MHI state. This fixes a regression with non functional ath11k WiFi
after suspend/resume cycle on some machines.

Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=214179

Link: https://lore.kernel.org/regressions/[email protected]/
Fixes: 020d3b26c07a ("bus: mhi: Early MHI resume failure in non M3 state")
Cc: [email protected] #5.13
Reported-by: Kalle Valo <[email protected]>
Reported-by: Pengyu Ma <[email protected]>
Tested-by: Kalle Valo <[email protected]>
Acked-by: Kalle Valo <[email protected]>
Signed-off-by: Loic Poulain <[email protected]>
[mani: Switched to API, added bug report, reported-by tags and CCed stable]
Signed-off-by: Manivannan Sadhasivam <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

Revert "bus: mhi: Add inbound buffers allocation flag"

This reverts commit 0092a1e3f7636ff4e202a41b0320690699247e22

This should be reverted in the char-misc-next branch to make merging
with Linus's

Revert "bus: mhi: Add inbound buffers allocation flag"

This reverts commit 0092a1e3f7636ff4e202a41b0320690699247e22

This should be reverted in the char-misc-next branch to make merging
with Linus's branch possible due to issues with the mhi code that was
found in the networking tree.

Link: https://lore.kernel.org/r/20210827175852.GB15018@thinkpad
Reported-by: Manivannan Sadhasivam <[email protected]>
Reported-by: Stephen Rothwell <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Bhaumik Bhatt <[email protected]>
Cc: Hemant Kumar <[email protected]>
Cc: Jakub Kicinski <[email protected]>
Cc: Kalle Valo <[email protected]>
Cc: Loic Poulain <[email protected]>
Cc: Manivannan Sadhasivam <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

Revert "net: really fix the build..."

This reverts commit ce78ffa3ef1681065ba451cfd545da6126f5ca88.

Wren and Nicolas reported that ath11k was failing to initialise QCA6390
Wi-Fi 6 device with error

Revert "net: really fix the build..."

This reverts commit ce78ffa3ef1681065ba451cfd545da6126f5ca88.

Wren and Nicolas reported that ath11k was failing to initialise QCA6390
Wi-Fi 6 device with error:

qcom_mhi_qrtr: probe of mhi0_IPCR failed with error -22

Commit ce78ffa3ef16 ("net: really fix the build..."), introduced in
v5.14-rc5, caused this regression in qrtr. Most likely all ath11k
devices are broken, but I only tested QCA6390. Let's revert the broken
commit so that ath11k works again.

Reported-by: Wren Turkal <[email protected]>
Reported-by: Nicolas Schichan <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>

show more ...

bus: mhi: Add MMIO region length to controller structure

Make controller driver specify the MMIO register region length
for range checking of BHI or BHIe space. This can help validate
that offsets a

bus: mhi: Add MMIO region length to controller structure

Make controller driver specify the MMIO register region length
for range checking of BHI or BHIe space. This can help validate
that offsets are in acceptable memory region or not and avoid any
boot-up issues due to BHI or BHIe memory accesses.

Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Jeffrey Hugo <[email protected]>
Reviewed-by: Hemant Kumar <[email protected]>
Reviewed-by: Manivannan Sadhasivam <[email protected]>
Signed-off-by: Bhaumik Bhatt <[email protected]>
Signed-off-by: Manivannan Sadhasivam <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

bus: mhi: Add inbound buffers allocation flag

Currently, the MHI controller driver defines which channels should
have their inbound buffers allocated and queued. But ideally, this is
something that

bus: mhi: Add inbound buffers allocation flag

Currently, the MHI controller driver defines which channels should
have their inbound buffers allocated and queued. But ideally, this is
something that should be decided by the MHI device driver instead,
which actually deals with that buffers.

Add a flag parameter to mhi_prepare_for_transfer allowing to specify
if buffers have to be allocated and queued by the MHI stack.

Keep auto_queue flag for now, but should be removed at some point.

Link: https://lore.kernel.org/r/[email protected]
Tested-by: Bhaumik Bhatt <[email protected]>
Reviewed-by: Bhaumik Bhatt <[email protected]>
Reviewed-by: Hemant Kumar <[email protected]>
Reviewed-by: Manivannan Sadhasivam <[email protected]>
Acked-by: Jakub Kicinski <[email protected]>
Signed-off-by: Loic Poulain <[email protected]>
Signed-off-by: Manivannan Sadhasivam <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

net: really fix the build...

Signed-off-by: David S. Miller <[email protected]>

Revert "mhi: Fix networking tree build."

This reverts commit 40e159403896f7d55c98f858d0b20fee1d941fa4.

Looks like this commit breaks the build for me.

Signed-off-by: Jakub Kicinski <[email protected]

Revert "mhi: Fix networking tree build."

This reverts commit 40e159403896f7d55c98f858d0b20fee1d941fa4.

Looks like this commit breaks the build for me.

Signed-off-by: Jakub Kicinski <[email protected]>

show more ...

mhi: Fix networking tree build.

Signed-off-by: David S. Miller <[email protected]>

bus: mhi: pci-generic: configurable network interface MRU

The MRU value used by the MHI MBIM network interface affects
the throughput performance of the interface. Different modem
models use differe

bus: mhi: pci-generic: configurable network interface MRU

The MRU value used by the MHI MBIM network interface affects
the throughput performance of the interface. Different modem
models use different default MRU sizes based on their bandwidth
capabilities. Large values generally result in higher throughput
for larger packet sizes.

In addition if the MRU used by the MHI device is larger than that
specified in the MHI net device the data is fragmented and needs
to be re-assembled which generates a (single) warning message about
the fragmented packets. Setting the MRU on both ends avoids the
extra processing to re-assemble the packets.

This patch allows the documented MRU for a modem to be automatically
set as the MHI net device MRU avoiding fragmentation and improving
throughput performance.

Signed-off-by: Richard Laing <[email protected]>
Signed-off-by: David S. Miller <[email protected]>

show more ...

bus: mhi: fix typo in comments for struct mhi_channel_config

The word 'rung' is a typo in below comment, fix it.
* @event_ring: The event rung index that services this channel

Signed-off-by: Jarvis

bus: mhi: fix typo in comments for struct mhi_channel_config

The word 'rung' is a typo in below comment, fix it.
* @event_ring: The event rung index that services this channel

Signed-off-by: Jarvis Jiang <[email protected]>
Reviewed-by: Manivannan Sadhasivam <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Manivannan Sadhasivam <[email protected]>

show more ...

bus: mhi: Improve documentation on channel transfer setup APIs

The mhi_prepare_for_transfer() and mhi_unprepare_from_transfer()
APIs could use better explanation. Add details on what MHI does
when t

bus: mhi: Improve documentation on channel transfer setup APIs

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 <[email protected]>
Reviewed-by: Hemant Kumar <[email protected]>
Reviewed-by: Manivannan Sadhasivam <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Manivannan Sadhasivam <[email protected]>

show more ...

bus: mhi: core: Remove pre_init flag used for power purposes

Some controllers can choose to skip preparation for power up.
In that case, device context is initialized based on the pre_init
flag not

bus: mhi: core: Remove pre_init flag used for power purposes

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: Bhaumik Bhatt <[email protected]>
Reviewed-by: Hemant Kumar <[email protected]>
Reviewed-by: Manivannan Sadhasivam <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Manivannan Sadhasivam <[email protected]>

show more ...

bus: mhi: core: Add support for Flash Programmer execution environment

MHI WWAN modems support downloading firmware to NAND or eMMC
using Firehose protocol with process as follows:
1. Modem boots up

bus: mhi: core: Add support for Flash Programmer execution environment

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 <[email protected]>
Co-developed-by: Bhaumik Bhatt <[email protected]>
Signed-off-by: Bhaumik Bhatt <[email protected]>
Reviewed-by: Loic Poulain <[email protected]>
Reviewed-by: Manivannan Sadhasivam <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Manivannan Sadhasivam <[email protected]>

show more ...