Re: [OpenWrt-Devel] ar71xx: How to integrate UniFi AP Outdoor Plus HSR?
Hi Felix,
> I think deferring this to user space might mess up timings during fast
> active scans. I'd prefer to have a callback in ath9k_platform.h that
> allows the platform code to provide a hook which implements this.
> That way the changes to ath9k stay very small, and the code is still
> quite simple.
this would move the hsr driver into the kernel image, wouldn't it? That's IMHO
a maintenance nightmare as it would force us to flash a new image whenever we
want to update or even debug the driver.
What about this solution:
-Add the possibility to register a channel change helper in ath9k.ko. As with
your idea, this is only a very small patch that all ar71xx targets would
have to carry.
-Make the hsr driver a channel change helper .ko
-Install the hsr kernel module only into the UniFi Outdoor Plus image.
Like in the attached RFC patch (that has be applied manually).
Stefan
diff -Nur linux/drivers/net/wireless/ath9k.orig/ath/ath9k.h linux/drivers/net/wireless/ath9k/ath/ath9k.h
--- linux/drivers/net/wireless/ath/ath9k.orig/ath9k.h 2015-04-04 04:46:37.0 +0200
+++ linux/drivers/net/wireless/ath/ath9k/ath9k.h 2015-06-03 18:37:29.0 +0200
@@ -1098,4 +1098,10 @@
static inline void ath_ahb_exit(void) {};
#endif
+/*
+ * OpenWrt UBNT HSR filter support
+ */
+typedef void (set_channel_helper_fn)(struct ath_hw* ah, int bw, int fq);
+void ath9k_register_set_channel_helper(set_channel_helper_fn *);
+
#endif /* ATH9K_H */
diff -Nur linux/drivers/net/wireless/ath/ath9k.orig/channel.c linux/drivers/net/wireless/ath/ath9k/channel.c
--- linux/drivers/net/wireless/ath/ath9k.orig/channel.c 2015-04-04 04:46:37.0 +0200
+++ linux/drivers/net/wireless/ath/ath9k/channel.c 2015-06-03 18:42:28.0 +0200
@@ -16,6 +16,18 @@
#include "ath9k.h"
+/*
+ * OpenWrt UBNT HSR filter support
+ */
+static set_channel_helper_fn *ath9k_set_channel_helper;
+
+void ath9k_register_set_channel_helper(set_channel_helper_fn *chanfn)
+{
+ ath9k_set_channel_helper = chanfn;
+}
+EXPORT_SYMBOL(ath9k_register_set_channel_helper);
+
+
/* Set/change channels. If the channel is really being changed, it's done
* by reseting the chip. To accomplish this we must first cleanup any pending
* DMA, then restart stuff.
@@ -41,6 +53,9 @@
ath_dbg(common, CONFIG, "Set channel: %d MHz width: %d\n",
chan->center_freq, chandef->width);
+ if (ath9k_set_channel_helper)
+ ath9k_set_channel_helper(ah, chandef->width, chan->center_freq);
+
/* update survey stats for the old channel before switching */
spin_lock_bh(&common->cc_lock);
ath_update_survey_stats(sc);
diff -Nur linux/drivers/net/wireless/ath/ath9k.orig/hsr.c linux/drivers/net/wireless/ath/ath9k/hsr.c
--- linux/drivers/net/wireless/ath/ath9k.orig/hsr.c 1970-01-01 01:00:00.0 +0100
+++ linux/drivers/net/wireless/ath/ath9k/hsr.c 2015-06-03 18:45:04.0 +0200
@@ -0,0 +1,283 @@
+/*
+ *
+ * The MIT License (MIT)
+ *
+ * Copyright (c) 2015 Kirill Berezin
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in all
+ * copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "hw.h"
+#include "hw-ops.h"
+#include "ar9003_mac.h"
+#include "ar9003_mci.h"
+#include "ar9003_phy.h"
+#include "ath9k.h"
+
+#define HSR_GPIO_CSN 8
+#define HSR_GPIO_CLK 6
+#define HSR_GPIO_DOUT 7
+#define HSR_GPIO_DIN 5
+
+/* delays are in useconds */
+#define HSR_DELAY_HALF_TICK 100
+#define HSR_DELAY_PRE_WRITE 75
+#define HSR_DELAY_FINAL 2
+#define HSR_DELAY_TRAILING 200
+
+static void hsr_init(struct ath_hw* ah);
+static int hsr_disable(struct ath_hw* ah);
+static int hsr_enable(struct ath_hw* ah, int bw, int fq);
+static int hsr_status(struct ath_hw* ah);
+
+static void hsr_init(struct ath_hw* ah) {
+
+ if ( NULL == ah) {
+ return;
+ }
+
+ ath9k_hw_cfg_gpio_input(ah, HSR_GPIO_DIN);
+ ath9k_hw_cfg_output(ah, HSR_GPIO_CSN, AR_GPIO_OUTPUT_MUX_AS_OUTPUT);
+ ath9k_hw_cfg_output(ah, HSR_GPIO_CLK, AR_GPIO_OUT
Re: [OpenWrt-Devel] ar71xx: How to integrate UniFi AP Outdoor Plus HSR?
On 2015-05-27 22:48, Stefan Rompf wrote: > Hi Kirill, > >> So I made a patch for atheros driver and it works. A signal level on >> different frequencies is more or less equal and seems adequate (about >> -30 dbm if a client within a meter from ap). > > so you reverse engineered the timer values, the response format and the 's' > command I had planned looking at next weekend. Very cool work! > > Now that talking to the HSR seems mostly solved, this makes me think about > OpenWrt integration. Currently I see two possibities: > > Integration into the kernel driver like your latest patch does. > > Caveat: The build process seems to assume that all routers in the > ar71xx/generic target share the same set of kernel modules. So patching and > compiling yourself is no problem, but a working image on > downloads.openwrt.org > is not feasible as every router would get the HSR driver. Correct me if I am > wrong. > > Or making ath9k expose the gpio and driving from user space. A generic patch > for ath9k to register its gpio pins via the standard gpio subsystem. This > should go upstream to the kernel and may prove usable for other access points > to. > > An Unifi specific user space daemon listens to scan and channel change events > via netlink (will check next weekend if channel change is broadcasted > reliably) and tune the filter via sysfs interface accordingly like hsr.c > tried. > > Caveat: Changing ath9k driver is possibly stuff for Designated Driver. May be > the user space component can fall back to bit banging for Chaos Calmer. > > What do you think? What do OpenWrt core developers think? I'd prefer exposing > gpio and driving from userspace. I think deferring this to user space might mess up timings during fast active scans. I'd prefer to have a callback in ath9k_platform.h that allows the platform code to provide a hook which implements this. That way the changes to ath9k stay very small, and the code is still quite simple. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar71xx: How to integrate UniFi AP Outdoor Plus HSR?
Hi Kirill, > > An Unifi specific user space daemon listens to scan and channel change > > events via netlink (will check next weekend if channel change is > > broadcasted reliably) and tune the filter via sysfs interface > > accordingly like hsr.c tried. > > I like this idea because in this case it'll be much easier to correct > problems or add changes. I cannot get events for userspace triggered channel changes from nl80211, there seems no way to realize my userspace daemon idea other than by ugly polling. So your driver patch is clearly the way to go. I'll test with chaos calmer but I have no doubt that it will work. Care to push it for inclusion? > > PS: I've started working on the wiki page > > http://wiki.openwrt.org/toh/ubiquiti/unifi_outdoorplus that I hope to > > move to "supported" soon ;-) > > I have a couple photos of pcb (one with annotated serial port), can send > them if you need. Please, do so or just include them into the wiki page. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar71xx: How to integrate UniFi AP Outdoor Plus HSR?
Hi, Stefan On 05/27/2015 11:48 PM, Stefan Rompf wrote: Integration into the kernel driver like your latest patch does. Caveat: The build process seems to assume that all routers in the ar71xx/generic target share the same set of kernel modules. So patching and compiling yourself is no problem, but a working image on downloads.openwrt.org is not feasible as every router would get the HSR driver. Correct me if I am wrong. This is not a problem because it is possible to use full platform name, which includes a profile name, as a dependency. The ubiquity driver checks some flags before enabling hsr, but I can't still track down where they store them. May be somewhere in eeprom. Or making ath9k expose the gpio and driving from user space. A generic patch for ath9k to register its gpio pins via the standard gpio subsystem. This should go upstream to the kernel and may prove usable for other access points to. An Unifi specific user space daemon listens to scan and channel change events via netlink (will check next weekend if channel change is broadcasted reliably) and tune the filter via sysfs interface accordingly like hsr.c tried. I like this idea because in this case it'll be much easier to correct problems or add changes. However for more general use a patch to the driver is much better. PS: I've started working on the wiki page http://wiki.openwrt.org/toh/ubiquiti/unifi_outdoorplus that I hope to move to "supported" soon ;-) I have a couple photos of pcb (one with annotated serial port), can send them if you need. Kirill. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar71xx: How to integrate UniFi AP Outdoor Plus HSR?
Hi Kirill, > So I made a patch for atheros driver and it works. A signal level on > different frequencies is more or less equal and seems adequate (about > -30 dbm if a client within a meter from ap). so you reverse engineered the timer values, the response format and the 's' command I had planned looking at next weekend. Very cool work! Now that talking to the HSR seems mostly solved, this makes me think about OpenWrt integration. Currently I see two possibities: Integration into the kernel driver like your latest patch does. Caveat: The build process seems to assume that all routers in the ar71xx/generic target share the same set of kernel modules. So patching and compiling yourself is no problem, but a working image on downloads.openwrt.org is not feasible as every router would get the HSR driver. Correct me if I am wrong. Or making ath9k expose the gpio and driving from user space. A generic patch for ath9k to register its gpio pins via the standard gpio subsystem. This should go upstream to the kernel and may prove usable for other access points to. An Unifi specific user space daemon listens to scan and channel change events via netlink (will check next weekend if channel change is broadcasted reliably) and tune the filter via sysfs interface accordingly like hsr.c tried. Caveat: Changing ath9k driver is possibly stuff for Designated Driver. May be the user space component can fall back to bit banging for Chaos Calmer. What do you think? What do OpenWrt core developers think? I'd prefer exposing gpio and driving from userspace. Stefan PS: I've started working on the wiki page http://wiki.openwrt.org/toh/ubiquiti/unifi_outdoorplus that I hope to move to "supported" soon ;-) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
