No subject

design/structure simply because you want to have an easy way of
debugging, but I think that's not a strong enough reason to make the API
between ath9k and the HSR code this quirky.

Here's what I want:
The hsr filter code function is passed in by the mach-* function for the
UniFi Outdoor, and the code is in the kernel itself.

And here's how you make debugging easy:
You make a package (which can live somewhere in a separate git tree),
which contains a copy of the code that is also in the kernel, and when
this package gets loaded, it looks up the ath9k pci device and the
platform data, and it overwrites the channel helper function callback.

Whenever you're finished testing your changes, you simply copy them back
to the source file used by the kernel and submit patches based on that.

Does that seem like a reasonable compromise to you?

- Felix
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel