Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Kalle Valo <kvalo@kernel.org>
To:     Christoph Hellwig <hch@lst.de>
Cc:     ath11k@lists.infradead.org, linux-wireless@vger.kernel.org,
        debian-kernel@lists.debian.org, debian-boot@lists.debian.org
Subject: Re: failed to insert STA entry for the AP (error -2)
References: <20221130122807.GA31720@lst.de> <87o7so4nr2.fsf@kernel.org>
        <20221130125236.GA865@lst.de> <87k03c4mdb.fsf@kernel.org>
        <20221130133016.GC3055@lst.de> <87sfhx3ap6.fsf@kernel.org>
        <20221203155227.GA13254@lst.de> <87cz8v2xb2.fsf@kernel.org>
        <20221207134025.GA21691@lst.de>
Date:   Thu, 08 Dec 2022 20:44:11 +0200
In-Reply-To: <20221207134025.GA21691@lst.de> (Christoph Hellwig's message of
        "Wed, 7 Dec 2022 14:40:25 +0100")
Message-ID: <87lenh20sk.fsf@kernel.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

Christoph Hellwig <hch@lst.de> writes:

> adding the debian-kernel list due to issues with using debian-installer
> daily snapshot to install on my brand new laptop with an ath11k_pci
> supported wifi chip.
>
> It turns out that while d-i comes with the ath11k and ath11k_pci
> drivers, but misses the qrtr, qrtr-mki and michael_mic modules that
> are needed for the driver to actually work and not just load.

s/qrtr-mki/qrtr-mhi/

And also CRYPTO_MICHAEL_MIC is needed. This the copy from Kconfig file
which should be an accurate list of dependencies:

config ATH11K
	tristate "Qualcomm Technologies 802.11ax chipset support"
	depends on MAC80211 && HAS_DMA
	depends on CRYPTO_MICHAEL_MIC
	select ATH_COMMON
	select QCOM_QMI_HELPERS
...
config ATH11K_PCI
	tristate "Atheros ath11k PCI support"
	depends on ATH11K && PCI
	select MHI_BUS
	select QRTR
	select QRTR_MHI

> On Wed, Dec 07, 2022 at 02:49:37PM +0200, Kalle Valo wrote:
>> Thanks. But this makes me wonder is it sensible to randomly install a
>> set of .ko files and drop the rest, like Debian's installer apparently
>> does? The dependency for drivers is pretty well documented in Kconfig
>> files, thanks to build testers testing with random configurations, but
>> if the installer omits all that there will be problems just like you are
>> experiencing. So for me MODULE_SOFTDEP() feels just like a band aid and
>> not a robust solution.
>
> I think a driver that a driver that has a runtime depedency on a
> certain module, but doesn't import symbols is always going to be
> somewhat problematic.  But I also agree that the arbitrary splitting
> of kernel modules into separate packages for the installer, or
> in fact not packaging them at all for the installer is rather
> problematic.  I'm not sure what the rationale is behind that, but
> I've added the debian-kernel and debian-boot lists.
>
>> 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.
>
> Yes.  I'm not quite sure how the packages for d-i select which
> modules to include where, but given that other wifi hardware
> seems to work in the installer they must have figured this out
> somehow.

For older ath driver (ath6kl, ath9k, ath10k) the dependencies were quite
simple. ath11k was the first driver requiring MHI and QRTR for PCI
devices, so in that regard it's not surprising that this problem comes
up only now.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches