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
Subject: Re: failed to insert STA entry for the AP (error -2)
In-Reply-To: <20221203155227.GA13254@lst.de> (Christoph Hellwig's message of
        "Sat, 3 Dec 2022 16:52:27 +0100")
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>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Date:   Wed, 07 Dec 2022 14:49:37 +0200
Message-ID: <87cz8v2xb2.fsf@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

Hi Christoph,

Sorry for the delay, it was Finland's Independence Day so I was offline
for a long weekend.

Christoph Hellwig <hch@lst.de> writes:

> On Fri, Dec 02, 2022 at 08:46:45PM +0200, Kalle Valo wrote:
>> Haven't seen this before either. Really unfortunate that the warning
>> message message is not printing the error value (missed that during
>> review), but I suspect the error is coming from crypto_alloc_shash()
>> call:
>
>> Any chance you could check that? Also please check that
>> CONFIG_CRYPTO_MICHAEL_MIC is enabled (it should be as CONFIG_ATH11K
>> depends on it).
>
> So, this is the debian-installer case onc again.  CONFIG_CRYPTO_MICHAEL_MIC
> is enabled in the kernel config, but michael_mic.ko is not present on
> the installation media. Once I side-load it, the problem goes away.
>
> I guess I'll respind the MODULE_SOFTDEP patch to include michael_mic,

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.

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.

> but if you have a good idea to make the error reporting more useful that
> would be appreciated as well.

I'll send a patch to improve the error messages in this case.

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

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