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:   Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= <toke@toke.dk>
To:     Wenli Looi <wlooi@ucalgary.ca>
Cc:     linux-wireless@vger.kernel.org, Kalle Valo <kvalo@kernel.org>
Subject: Re: [PATCH v3 00/11] wifi: ath9k: add support for QCN550x
In-Reply-To: <20230629231625.951744-1-wlooi@ucalgary.ca>
References: <20230629231625.951744-1-wlooi@ucalgary.ca>
Date:   Thu, 10 Aug 2023 18:51:54 +0200
Message-ID: <87a5uyg7rp.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk


I've started looking at this now. A few initial questions:

> This patchset adds support for QCN550x. Compared to previous versions of
> this patchset:
>
> - Removed hidden dependencies on ah macro
>   (see commit b3a663f0037d20e77bbafd9271a3d9dd0351059d)
> - Done significantly more testing and performance improvements. In my
>   informal testing, the 3x3 performance of this driver generally meets
>   or exceeds the performance of stock firmwares, which was not the case
>   for previous patchsets. The main source of the improvement was
>   enabling the clock doubler.

Did you do any regression tests on other types of ar9300 hardware to
ensure these patches don't negatively affect existing systems?

>   Revert "ath9k_hw: fall back to OTP ROM when platform data has no valid
>     eeprom data"

This revert seems a bit dodgy; the commit message states "Users
currently relying on this silent fallback will need to stop providing
invalid EEPROM data to the driver." - which kinda sounds like a
kernel-to-userspace regression to me? Do any such systems actually
exist?

-Toke