2022-03-10 02:09:56

by Toke Høiland-Jørgensen

[permalink] [raw]
Subject: Re: QCN5502 support in ath9k

Wenli Looi <[email protected]> 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


2022-03-11 15:50:23

by Wenli Looi

[permalink] [raw]
Subject: Re: QCN5502 support in ath9k

On Wed, Mar 9, 2022 at 3:24 PM Toke Høiland-Jørgensen <[email protected]> wrote:
>
> Wenli Looi <[email protected]> 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.