XPost: linux.debian.maint.boot

Hi all,

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.

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.maint.boot

Hallo Christoph,

Christoph Hellwig <hch@lst.de> (2022-12-07):

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.

Reminds me of: https://bugs.debian.org/761902 which meant my wireless
adapter was happy with WEP but not WPA.

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.

What modules end up in what udebs is decided in src:linux, under debian/installer/modules.

Commit fixing the bug mentioned above:
https://salsa.debian.org/kernel-team/linux/-/commit/782d644da7ab74e04bfebd30b66c264654028da3


Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmOQojcACgkQ/5FK8MKz VSDkFA/6A/nAxvhQJb+QA8y2Q+wT8r3MSJcucTOf/kp52oMgjjwM4wQsgjEvUFVG nb5oM9rlvBgm6X5oRL8+Mb5DHyNMb2roh8HK4EXn1Xy3WcPOyRKP1sTPSLx1qe9C 0h5BBZgfFayBfiU4s2eFQSArJQPRYFm8E5stZY+pwJevgaJ0jC8mOOZ2MMnau34S 5PWvR/Z86tZ+z114LcdLthi+tGPSCOHxsitmACLFMQZ5WsxZKR3WDJoZMKhu9E1M XNhyZJ/y5IYwa5/fEgj2RzYO4ExPUVYplefMQEeHrp+xcBB9nCfyb59BJbQ1t1+S +9Iir7K7OMMGlBA0EDCMqvUgHgQswVSvCHHEsz5lEefme54pWebDoZQ4hysYJxhq zcQK6/1oX8phSu8sY/ZeXU5slCUMZQJjgVd5rS0gKenbE0OEYAhJAqAFBpwJ/ZzY Xn9c8Dii9XJqlWO9c8km8bhvjn9Y7PMSo7aUsp2Uq9XHh7gV/rPQri+sIB7q6Nro Pahee/O4wX8NEEZk16UTQS0rvqVf1ZNOKi1PrvxkDwCrtxwTq3rbhZ9z/yJhl3DS yiZo8GWo/0Us6k+pSFPZ12O8Id2pQojm6+UKBW3EsUVEwq2v9U6O21BUngdnRIY+ sfaXRYr2c7VqeWTBVXDcW+GOKgXKAbErJA/e3HUjVwEmJQC7j+Y=
=TgTW
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

XPost: linux.debian.maint.boot

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)