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@redhat.com>
To:     Wenli Looi <wlooi@ucalgary.ca>, Kalle Valo <kvalo@kernel.org>
Cc:     ath9k-devel@qca.qualcomm.com,
        Miaoqing Pan <miaoqing@codeaurora.org>,
        linux-wireless@vger.kernel.org
Subject: Re: QCN5502 support in ath9k
In-Reply-To: <CAKe_nd3Hc+5u9O0Bd31oFF_mTOJU9bx5hmcS1TkSy0FMtQamBA@mail.gmail.com>
References: <CAKe_nd1jthFhJhojQLXMeU741AoTks74K+J1v5FqS6ABB6gW-Q@mail.gmail.com>
 <87r18d1upk.fsf@kernel.org>
 <CAKe_nd3Hc+5u9O0Bd31oFF_mTOJU9bx5hmcS1TkSy0FMtQamBA@mail.gmail.com>
Date:   Thu, 10 Mar 2022 00:24:08 +0100
Message-ID: <87mthyvhev.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

Wenli Looi <wlooi@ucalgary.ca> writes:

> I've managed to get QCN5502 working in ath9k in a very hacky way, by
> mainly treating it as QCA956x, including the initvals:
>
> https://github.com/openwrt/openwrt/pull/9389
>
> It would be great if anyone could provide comments on the code, as
> well as the ideas for incorporating this cleanly into ath9k (and
> whether there would be interest in doing so).

I certainly wouldn't mind merging this support if it can be implemented
in a clean way; we'd have to be sure it doesn't break anything on
existing devices, of course.

You'll have to split out the code to co-exist with the ar9003. My
immediate thought would be that it would be a mistake to employ too
clever tricks to maximise code reuse. By all means, try to reuse as much
code as possible, but I'd rather take a bit of code duplication than end
up with something that works in non-obvious ways :)

Hope that helps!

-Toke