On 7/22/2025 1:35 AM, Baochen Qiang wrote:
>
>
> On 12/2/2022 9:06 PM, Christoph Hellwig wrote:
>> While ath11k_pci can load without qrtr-mhi, probing the actual hardware
>> will fail when qrtr and qrtr-mhi aren't loaded with
>>
>> failed to initialize qmi handle: -517
>>
>> Add a MODULE_SOFTDEP statement to bring the module in (and as a hint
>> for kernel packaging) for those cases where it isn't autoloaded already
>> for some reason.
>>
>> Signed-off-by: Christoph Hellwig <hch@xxxxxx>
>> ---
>> drivers/net/wireless/ath/ath11k/pci.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/net/wireless/ath/ath11k/pci.c b/drivers/net/wireless/ath/ath11k/pci.c
>> index 99cf3357c66e16..9d58856cbf8a94 100644
>> --- a/drivers/net/wireless/ath/ath11k/pci.c
>> +++ b/drivers/net/wireless/ath/ath11k/pci.c
>> @@ -1037,6 +1037,8 @@ module_exit(ath11k_pci_exit);
>> MODULE_DESCRIPTION("Driver support for Qualcomm Technologies 802.11ax WLAN PCIe devices");
>> MODULE_LICENSE("Dual BSD/GPL");
>>
>> +MODULE_SOFTDEP("pre: qrtr-mhi");
>> +
>> /* QCA639x 2.0 firmware files */
>> MODULE_FIRMWARE(ATH11K_FW_DIR "/QCA6390/hw2.0/" ATH11K_BOARD_API2_FILE);
>> MODULE_FIRMWARE(ATH11K_FW_DIR "/QCA6390/hw2.0/" ATH11K_AMSS_FILE);
>
> Do we know why this patch is rejected?
This predates me becoming a maintainer, and I don't see any comment from Kalle
to the patch, however he did have the following comment in a separate thread
where the issue was being discussed:
https://lore.kernel.org/all/87cz8v2xb2.fsf@xxxxxxxxxx/
> Though I am happy to take your MODULE_SOFTDEP() patch, just wondering if
> there is a better way to solve this. For example net/mac80211 (the
> 802.11 stack) has a lot of crypto dependencies:
>
> select CRYPTO
> select CRYPTO_LIB_ARC4
> select CRYPTO_AES
> select CRYPTO_CCM
> select CRYPTO_GCM
> select CRYPTO_CMAC
> select CRC32
>
> And it's not using MODULE_SOFTDEP() at all.
So I'm guessing he considered this to be an issue that should be solved
external to the individual drivers.
/jeff
