Re: QCN5502 support in ath9k

Re: QCN5502 support in ath9k

[Kalle Valo]

Wenli Looi <wlooi@ucalgary.ca> writes:

> I'm wondering if there's any plan to support QCN5502 in ath9k. If not,
> is it possible to obtain the initvals and other information that would
> be required to support QCN5502 in ath9k? (such as those for QCA956x in
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireless/ath/ath9k/ar956x_initvals.h)
>
>
> For context, I have recently submitted two patches that seem to allow
> QCN5502 to be fully functional except for the integrated wifi:
>
> * https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=a0b8cd5c223042efe764864b8dd9396ee127c763
>  
> * https://github.com/openwrt/openwrt/pull/4271
>
> Thanks!

Don't use HTML, linux-wireless drops all HTML mail, I don't know about
QCN5502 support, but hopefully people see your email now.

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

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

Re: QCN5502 support in ath9k

[Wenli Looi]

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).

Thanks!

On Tue, Feb 8, 2022 at 3:08 AM Kalle Valo <kvalo@kernel.org> wrote:
>
> [△EXTERNAL]
>
>
>
> Wenli Looi <wlooi@ucalgary.ca> writes:
>
> > I'm wondering if there's any plan to support QCN5502 in ath9k. If not,
> > is it possible to obtain the initvals and other information that would
> > be required to support QCN5502 in ath9k? (such as those for QCA956x in
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireless/ath/ath9k/ar956x_initvals.h)
> >
> >
> > For context, I have recently submitted two patches that seem to allow
> > QCN5502 to be fully functional except for the integrated wifi:
> >
> > * https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=a0b8cd5c223042efe764864b8dd9396ee127c763
> >
> > * https://github.com/openwrt/openwrt/pull/4271
> >
> > Thanks!
>
> Don't use HTML, linux-wireless drops all HTML mail, I don't know about
> QCN5502 support, but hopefully people see your email now.
>
> --
> https://patchwork.kernel.org/project/linux-wireless/list/
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: QCN5502 support in ath9k

[Toke Høiland-Jørgensen]

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

Re: QCN5502 support in ath9k

[Wenli Looi]

On Wed, Mar 9, 2022 at 3:24 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>
> 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
>

Thanks, I'm glad you would consider merging this support. Sounds good
to avoid something that works in non-obvious ways. I'll think more
about how to implement the code cleanly.