Re: [OpenWrt-Devel] [PATCH] swconfig: support setting SWITCH_TYPE_LINK attributes
Hi, On Montag, 11. Januar 2016 23:45:39 Rafał Miłecki wrote: > > Any comments to this usage/syntax? It doesn't look too nice (this long > > quoted string as a value), but swconfig is strongly focused on simple > > values. > > One more RFC... anyone? I am not an OpenWRT core developer so I cannot comment on the niceness of the interface ;-) The string does not allow to specify combinations like autoneg on, advertise 10 and 1000, but not 100, but that would be a very esoteric use case and it is about configuring a switch port and not an ethernet tester. IMHO for the normal use case, it allows to specify everything that is needed. So for me it's all right. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] swconfig: support setting SWITCH_TYPE_LINK attributes
Hi Rafał, > Supported syntax is inspired by ethtool. Example usage: > swconfig dev switch0 port 2 set link "duplex half speed 100 autoneg off" > > Signed-off-by: Rafał Miłecki I think that's the way to go, will try implementing set_port_link() for my good old 1043ND. Ack for this and the kernel patches. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/3] swconfig: add SWITCH_TYPE_LINK and support sending link info to user space
Hi Rafał, On Mittwoch, 16. Dezember 2015 18:19:01 Rafał Miłecki wrote: > So far we were sending link data as a string. It got some drawbacks: > 1) Didn't allow writing clean user space apps reading link state. It was >needed to do some screen scraping. > 2) Forced whole PORT_LINK communication to be string based. Adding >support for *setting* port link required passing string and parting >it in the kernel space. indeed, this interface looks a lot better than passing a string. It will make setting the link parameters easier. Minor nitpick: I'm not sure about the naming of these attributes: > + SWITCH_LINK_FLAG_ADVERTISED_100BASET_FULL, > + SWITCH_LINK_FLAG_ADVERTISED_1000BASET_FULL, As far as I understand the code, they specify whether EEE should be adverstised / is enabled for a specific speed. Therefore maybe they should be called f.e. SWITCH_LINK_EEE_100BASET and SWITCH_LINK_EEE_1000BASET Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v4 1/2] Add ubnt_hsr platform flag and enable for UniFi Outdoor Plus
Hi Tim, > The auto-built image of 9 December 2015 for this device results in a > bricked state. TFTP recovery with a stock recovery firmware from > Ubiquity does not allow the device to boot either. try flashing the chaos calmer factory image with TFTP (openwrt-15.05-ar71xx-generic-ubnt-unifi-outdoor-plus-squashfs-factory.bin) This has allowed me to recover a bricked Outdoor Plus. Flashing the Ubiquiti firmware via TFTP didn't work for me either. > but if anyone wants this device as a donation to get it > supported by OpenWRT, please let me know. Well on one hand I'd be interested because the access point I had is mounted onsite now and therefore not available for hacking anymore. On the other hand, I got the impression that mine and Kyrills patches were not too welcome, so I'm a bit hesitant to invest more time. So good luck with unbricking, may be the device gets usable for your again! Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][RFC] kernel: swconfig: add API for setting port link speed
Hi Rafał, > int (*get_port_link)(struct switch_dev *dev, int port, >struct switch_port_link *link); > + int (*set_port_link)(struct switch_dev *dev, int port, > + enum switch_port_speed speed); this creates an assymetric API. I think the prototype of the set function should be int (*set_port_link)(struct switch_dev *dev, int port, struct switch_port_link *link); to allow setting other parameters that are part of struct switch_port_link, like duplex or flow control. I'd be rather happy to disable crappy ethernet flow control on my router... API should be: If switch_port_link.aneg is enabled, the switch driver should advertise the capabilities as set in the struct. May be this requires making switch_port_speed a bit field for the allowed speeds. If switch_port_link.aneg is disabled, the driver should disable autonegotation and force the parameters set. If anything is set the switch does not support, the driver should return -EINVAL. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v4 0/2] Support Ubiquiti Unifi Outdoor Plus HSR filter
On Dienstag, 16. Juni 2015 23:14:05 Stefan Rompf wrote: > so we arrive at the fourth iteration of the patchset to support the HSR of > the Ubiquiti Unifi Outdoor Plus access point. This version implements the > suggestions from Felix. Ping? Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v4 2/2] Add HSR tuner to ath9k
Add tuner for the HSR filter of the UniFi Outdoor Plus access point. Usage of
the tuner is controlled at runtime by ath9k_platform_data. The code can be
enabled or disabled by a compile time option.
Signed-off-by: Stefan Rompf
---
Index: package/kernel/mac80211/Makefile
===
--- package/kernel/mac80211/Makefile(Revision 46000)
+++ package/kernel/mac80211/Makefile(Arbeitskopie)
@@ -587,6 +587,11 @@
bool "Support chips used in PC OEM cards"
depends on PACKAGE_kmod-ath9k
+ config ATH9K_UBNTHSR
+ bool "Support for Ubiquiti UniFi Outdoor Plus access point"
+ depends on PACKAGE_kmod-ath9k
+ default y
+
endef
define KernelPackage/ath9k-htc
@@ -1558,6 +1563,7 @@
config-$(CONFIG_PCI) += ATH9K_PCI
config-$(CONFIG_ATH_USER_REGD) += ATH_USER_REGD
config-$(CONFIG_ATH9K_SUPPORT_PCOEM) += ATH9K_PCOEM
+config-$(CONFIG_ATH9K_UBNTHSR) += ATH9K_UBNTHSR
config-$(call config_package,ath9k-htc) += ATH9K_HTC
config-$(call config_package,ath10k) += ATH10K ATH10K_PCI
Index: package/kernel/mac80211/patches/930-ubnt-uap-plus-hsr.patch
===
--- package/kernel/mac80211/patches/930-ubnt-uap-plus-hsr.patch (Revision 0)
+++ package/kernel/mac80211/patches/930-ubnt-uap-plus-hsr.patch (Arbeitskopie)
@@ -0,0 +1,373 @@
+--- compat-wireless-2015-03-09/drivers/net/wireless/ath/ath9k.orig/channel.c
2015-06-16 09:28:34.0 +0200
compat-wireless-2015-03-09/drivers/net/wireless/ath/ath9k/channel.c
2015-06-16 09:49:53.0 +0200
+@@ -15,6 +15,8 @@
+ */
+
+ #include "ath9k.h"
++#include
++#include "hsr.h"
+
+ /* 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
+@@ -22,6 +24,7 @@
+ */
+ static int ath_set_channel(struct ath_softc *sc)
+ {
++ struct ath9k_platform_data *pdata = sc->dev->platform_data;
+ struct ath_hw *ah = sc->sc_ah;
+ struct ath_common *common = ath9k_hw_common(ah);
+ struct ieee80211_hw *hw = sc->hw;
+@@ -41,6 +44,11 @@
+ ath_dbg(common, CONFIG, "Set channel: %d MHz width: %d\n",
+ chan->center_freq, chandef->width);
+
++ if (pdata && pdata->ubnt_hsr) {
++ hsr_enable(ah, chandef->width, chan->center_freq);
++ hsr_status(ah);
++ }
++
+ /* update survey stats for the old channel before switching */
+ spin_lock_bh(&common->cc_lock);
+ ath_update_survey_stats(sc);
+--- compat-wireless-2015-03-09/drivers/net/wireless/ath/ath9k.orig/hsr.c
1970-01-01 01:00:00.0 +0100
compat-wireless-2015-03-09/drivers/net/wireless/ath/ath9k/hsr.c
2015-06-16 09:41:24.0 +0200
+@@ -0,0 +1,220 @@
++/*
++ *
++ * 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 "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
++
++
++void hsr_init(struct ath_hw* ah) {
++ 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_OUTPUT_MUX_AS_OUTPUT);
++ ath9k_hw_cfg_output(ah, HSR_GPIO_DOUT, AR_GPIO_OUTPUT_MUX_AS_OUTPUT);
++
++
Re: [OpenWrt-Devel] [PATCH v4 1/2] Add ubnt_hsr platform flag and enable for UniFi Outdoor Plus
Add ubnt_hsr flag to struct ath9k_platform_data and enable it for the Outdoor Plus access point so that the availability ot the HSR filter can be detected by the ath9k driver at runtime. Signed-off-by: Stefan Rompf --- Index: package/kernel/mac80211/patches/150-ath9k_ubnt_hsr_filter.patch === --- package/kernel/mac80211/patches/150-ath9k_ubnt_hsr_filter.patch (Revision 0) +++ package/kernel/mac80211/patches/150-ath9k_ubnt_hsr_filter.patch (Arbeitskopie) @@ -0,0 +1,15 @@ +Flag that this platform is an Ubiquiti UniFi Outdoor Plus +containing a RF filter in ath9k's receive path. + +Signed-off-by: Stefan Rompf + +--- mac80211/include/linux/ath9k_platform.h.orig 2015-06-15 22:18:46.0 +0200 mac80211/include/linux/ath9k_platform.h2015-06-15 22:15:23.0 +0200 +@@ -36,6 +36,7 @@ + bool tx_gain_buffalo; + bool disable_2ghz; + bool disable_5ghz; ++ bool ubnt_hsr; + + int (*get_mac_revision)(void); + int (*external_reset)(void); Index: target/linux/generic/patches-3.18/150-ath9k_ubnt_hsr_filter.patch === --- target/linux/generic/patches-3.18/150-ath9k_ubnt_hsr_filter.patch (Revision 0) +++ target/linux/generic/patches-3.18/150-ath9k_ubnt_hsr_filter.patch (Arbeitskopie) @@ -0,0 +1,15 @@ +Flag that this platform is an Ubiquiti UniFi Outdoor Plus +containing a RF filter in ath9k's receive path. + +Signed-off-by: Stefan Rompf + +--- linux-3.18.14/include/linux/ath9k_platform.h.orig 2015-06-15 22:18:46.0 +0200 linux-3.18.14/include/linux/ath9k_platform.h 2015-06-15 22:15:23.0 +0200 +@@ -36,6 +36,7 @@ + bool tx_gain_buffalo; + bool disable_2ghz; + bool disable_5ghz; ++ bool ubnt_hsr; + + int (*get_mac_revision)(void); + int (*external_reset)(void); Index: target/linux/ar71xx/patches-3.18/608-MIPS-ath79-ubnt-xm-add-more-boards.patch === --- target/linux/ar71xx/patches-3.18/608-MIPS-ath79-ubnt-xm-add-more-boards.patch (Revision 46000) +++ target/linux/ar71xx/patches-3.18/608-MIPS-ath79-ubnt-xm-add-more-boards.patch (Arbeitskopie) @@ -254,6 +254,7 @@ + ath79_register_eth(0); + ath79_register_eth(1); + ++ ap9x_pci_get_wmac_data(0)->ubnt_hsr = true; + ap91_pci_init(ee, NULL); + + ath79_register_leds_gpio(-1, ARRAY_SIZE(ubnt_unifi_outdoor_plus_leds_gpio), ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v4 0/2] Support Ubiquiti Unifi Outdoor Plus HSR filter
Hi, so we arrive at the fourth iteration of the patchset to support the HSR of the Ubiquiti Unifi Outdoor Plus access point. This version implements the suggestions from Felix. We lost the feature to avoid tuning the same channel multiple times in a row, but this should not be critical. The HSR is a configurable RF filter in the receive path that must be tuned according to the selected Wifi channel for the access point to work. Patch 1 adds a ubnt_hsr flag to struct ath9k_platform_data and enables it for the Outdoor Plus access point. Patch 2 adds the HSR tuner to the ath9k driver as a configurable option, controller by the ubnt_hsr flag. The patchset is based on work of Kirill Berezin and me. The patch is against chaos_calmer branch and running on the access point right now. It applies against trunk, too, however this resulted in a bricked access point that did not boot at all. I don't know if that happened because of the patch, the new libc or due to Alexander's conversion to the new build code. I'm happy that I could recover via TFTP and I'm not too eager to retest trunk because the device is borrowed. I also compiled the brcm47xx platform successfully. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3 1/2] [mac80211] Add "channel set helper" callback to ath9k
Hi Felix, > Maybe in this case it would be > better to put the code in ath9k.ko and enable it via a Kconfig option in > the mac80211 package. Then add a bool flag to the ath9k_platform_data > struct to enable it only for devices that need it. sounds good to me, will create a patch... Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3 1/2] [mac80211] Add "channel set helper" callback to ath9k
Hi Felix,
thanks for your feedback!
> NACK from me for the ath9k_set_channel_helper part. This helper function
> needs to be passed in from the platform data, similar to how external
> reset is handled.
> From previous emails you pointed out that you guys chose this
> 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.
however this approach looks even more ugly to me.
The HSR is connected to the GPIO lines of the AR928x. As long as ath9k does
not register with the kernels' GPIO subsystem (which is definitely Designated
Driver stuff if I had to implement it), we need to callback into the ath9k
driver when tuning it. We'd end up with something like this in
ath9k_platform.h:
typedef void (cfg_gpio_input_fkt)(struct ath_hw *ah, u32 gpio);
typedef void (cfg_gpio_output_fkt)struct ath_hw *ah, u32 gpio,
u32 ah_signal_type);
typedef void (set_gpio_fkt)(struct ath_hw *ah, u32 gpio, u32 val);
typedef u32 (gpio_get_fkt)(struct ath_hw *ah, u32 gpio, u32 val);
struct ath9k_platform_data {
...
void (*set_channel_helper)(struct ath_hw*, int bw, int fq, cfg_gpio_input_fkt
*, cfg_gpio_output_fkt *, set_gpio_fkt*, gpio_get_fkt*);
...
};
and the callback inside channel.c:
if (sc->dev->platform_data->set_channel_helper) {
sc->dev->platform_data->set_channel_helper(ah, chandef->width, chan-
>center_freq, ath9k_hw_cfg_gpio_input, ath9k_hw_cfg_output, ath9k_hw_set_gpio,
ath9k_hw_gpio_get);
}
> 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.
May be we can use a similiar approach to avoid this function pointer passing
horror. Let's have a
void (*set_channel_helper)(struct ath_hw*, int bw, int fq)
callback in ath9k_platform_data that is enabled by the channel tuning module.
The module could then call into ath9k without indirections.
What do you think?
Stefan
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v3 2/2] Add kmod-ubnt-hsr tuner for the UBNT HSR filter
Add the tuner for the Ubiquiti Outdoor Plus HSR filter as a self contained
kmod package. When loaded, it registers with ath9k as a channel set helper and
tunes the HSR on every channel change.
Signed-off-by: Stefan Rompf
---
Index: package/kernel/ubnt-hsr/Makefile
===
--- package/kernel/ubnt-hsr/Makefile(Revision 0)
+++ package/kernel/ubnt-hsr/Makefile(Arbeitskopie)
@@ -0,0 +1,56 @@
+#
+# Copyright (C) 2015 OpenWrt.org
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+
+include $(TOPDIR)/rules.mk
+include $(INCLUDE_DIR)/kernel.mk
+
+PKG_NAME:=ubnt_hsr
+PKG_VERSION:=0.1
+PKG_RELEASE:=1
+PKG_BUILD_DEPENDS:=mac80211
+
+include $(INCLUDE_DIR)/package.mk
+
+define KernelPackage/ubnt-hsr
+ $(call KernelPackage/mac80211/Default)
+ SUBMENU:=Wireless Drivers
+ TITLE:=Driver for Ubiquiti UniFi Outdoor Plus HSR filter
+ URL:=http://wiki.openwrt.org/toh/ubiquiti/unifi_outdoorplus
+ DEPENDS:=@PCI_SUPPORT||TARGET_ar71xx kmod-ath9k
+ FILES:= $(PKG_BUILD_DIR)/ubnt_hsr.ko
+ AUTOLOAD:=$(call AutoProbe,ubnt_hsr)
+endef
+
+define KernelPackage/ubnt-hsr/description
+ubnt-hsr adds support for the 'High-Selectivity Receiver'
+RF filter built into the receive path of the Ubiquiti
+UniFi Outdoor Plus access point. It is required for this and
+only for this access point.
+endef
+
+include $(INCLUDE_DIR)/kernel-defaults.mk
+
+define Build/Prepare
+ mkdir -p $(PKG_BUILD_DIR)
+ cp src/Makefile src/ubnt_hsr.c $(PKG_BUILD_DIR)/
+endef
+
+define Build/Compile
+ $(MAKE) $(KERNEL_MAKEOPTS) SUBDIRS="$(PKG_BUILD_DIR)" \
+
LINUXINCLUDE="-I$(STAGING_DIR)/usr/include/mac80211-backport/uapi
-I$(STAGING_DIR)/usr/include/mac80211-backport \
+ -I$(STAGING_DIR)/usr/include/mac80211/uapi
-I$(STAGING_DIR)/usr/include/mac80211 \
+ -I$(LINUX_DIR)/include -I$(LINUX_DIR)/include/$(LINUX_UAPI_DIR)
\
+ -I$(LINUX_DIR)/include/generated/uapi/
-Iarch/$(LINUX_KARCH)/include \
+ -Iarch/$(LINUX_KARCH)/include/$(LINUX_UAPI_DIR) \
+ -Iarch/$(LINUX_KARCH)/include/generated \
+ -Iarch/$(LINUX_KARCH)/include/generated/$(LINUX_UAPI_DIR) \
+ -include generated/autoconf.h \
+ -include backport/backport.h " \
+ V="${V}" modules
+endef
+
+$(eval $(call KernelPackage,ubnt-hsr))
Index: package/kernel/ubnt-hsr/src/Makefile
===
--- package/kernel/ubnt-hsr/src/Makefile(Revision 0)
+++ package/kernel/ubnt-hsr/src/Makefile(Arbeitskopie)
@@ -0,0 +1 @@
+obj-m := ubnt_hsr.o
Index: package/kernel/ubnt-hsr/src/ubnt_hsr.c
===
--- package/kernel/ubnt-hsr/src/ubnt_hsr.c (Revision 0)
+++ package/kernel/ubnt-hsr/src/ubnt_hsr.c (Arbeitskopie)
@@ -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
+#include
+
+#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) {
+ ath9k_hw_cfg_gpio_input(ah, HSR_GPIO_DIN);
+ ath9k_hw_cfg_output(ah, HSR_GPIO_CSN, AR_GPIO_OUTPUT_MUX_AS_OUTPUT);
+ ath9k_
[OpenWrt-Devel] [PATCH v3 1/2] [mac80211] Add "channel set helper" callback to ath9k
This patch adds a "channel set helper" callback to the ath9k driver and
exports the ath9k kernel API for other packages. The registered function
is called whenever ath9k changes the channel.
Signed-off-by: Stefan Rompf
---
Index: package/kernel/mac80211/Makefile
===
--- package/kernel/mac80211/Makefile(Revision 45695)
+++ package/kernel/mac80211/Makefile(Arbeitskopie)
@@ -1737,11 +1737,13 @@
$(1)/usr/include/mac80211 \
$(1)/usr/include/mac80211-backport \
$(1)/usr/include/mac80211/ath \
+ $(1)/usr/include/mac80211/ath/ath9k \
$(1)/usr/include/net/mac80211
$(CP) $(PKG_BUILD_DIR)/net/mac80211/*.h $(PKG_BUILD_DIR)/include/*
$(1)/usr/include/mac80211/
$(CP) $(PKG_BUILD_DIR)/backport-include/*
$(1)/usr/include/mac80211-backport/
$(CP) $(PKG_BUILD_DIR)/net/mac80211/rate.h
$(1)/usr/include/net/mac80211/
$(CP) $(PKG_BUILD_DIR)/drivers/net/wireless/ath/*.h
$(1)/usr/include/mac80211/ath/
+ $(CP) $(PKG_BUILD_DIR)/drivers/net/wireless/ath/ath9k/*.h
$(1)/usr/include/mac80211/ath/ath9k/
rm -f $(1)/usr/include/mac80211-backport/linux/module.h
endef
Index: package/kernel/mac80211/patches/930-ath9k_add_channel_set_helper.patch
===
--- package/kernel/mac80211/patches/930-ath9k_add_channel_set_helper.patch
(Revision 0)
+++ package/kernel/mac80211/patches/930-ath9k_add_channel_set_helper.patch
(Arbeitskopie)
@@ -0,0 +1,46 @@
+diff -X diffign -Npur kernel/drivers/net/wireless/ath/ath9k.orig/ath9k.h
kernel/drivers/net/wireless/ath/ath9k/ath9k.h
+--- kernel/drivers/net/wireless/ath/ath9k.orig/ath9k.h 2015-06-04
21:19:11.0 +0200
kernel/drivers/net/wireless/ath/ath9k/ath9k.h 2015-06-06
10:23:05.0 +0200
+@@ -1110,4 +1110,10 @@ static inline int ath_ahb_init(void) { r
+ static inline void ath_ahb_exit(void) {};
+ #endif
+
++/*
++ * OpenWrt channel set helper, needed f.e. for Ubiquiti UniFi Outdoor Plus
++ */
++typedef void (set_channel_helper_fn)(struct ath_hw* ah, int bw, int fq);
++void ath9k_register_set_channel_helper(set_channel_helper_fn *); /* call
inside RTNL lock to guard against parallel channel change */
++
+ #endif /* ATH9K_H */
+diff -X diffign -Npur kernel/drivers/net/wireless/ath/ath9k.orig/channel.c
kernel/drivers/net/wireless/ath/ath9k/channel.c
+--- kernel/drivers/net/wireless/ath/ath9k.orig/channel.c 2015-03-10
04:37:15.0 +0100
kernel/drivers/net/wireless/ath/ath9k/channel.c2015-06-06
10:23:05.0 +0200
+@@ -16,6 +16,18 @@
+
+ #include "ath9k.h"
+
++/*
++ * OpenWrt channel set helper
++ */
++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 @@ static int ath_set_channel(struct ath_so
+ 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);
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v3 0/2] Support Ubiquiti Unifi Outdoor Plus HSR filter
Hi, this is the third iteration of the patchset to support the HSR filter of the Ubiquiti Unifi Outdoor Plus access point. The HSR is a configurable RF filter in the receive path that must be tuned according to the selected Wifi channel for the access point to work. Patch 1 adds a "channel set helper" callback to the ath9k driver and exports the ath9k kernel API for other packages. The registered function is called whenever ath9k changes the channel. Patch 2 adds the actual tuner as a self contained kmod package. When loaded, it registers with ath9k as a channel set helper and tunes the HSR on every channel change. The patchset is based on work of Kirill Berezin and me. Changes since last version: -Add debug module parameter to dump all IO from and to the HSR -Explicitely load ath9k before ubnt_hsr as dependencies from external kmod to another external kmod are not detected during the build process -Maintainer entry for kmod package -Description updates I'm running the driver compiled against chaos calmer RC1 right now and compile test it against trunk. Not yet solved is how to add the kmod to the outdoor plus image only, but I'd really like to push these changes before -rc2. Please apply Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 2/2] Support Ubiquiti Unifi Outdoor Plus HSR filter
Add kmod-ubnt-hsr package that tunes the HSR filter of the access point as a
ath9k channel change helper
Signed-off-by: Stefan Rompf
---
Index: package/kernel/ubnt-hsr/Makefile
===
--- package/kernel/ubnt-hsr/Makefile(Revision 0)
+++ package/kernel/ubnt-hsr/Makefile(Arbeitskopie)
@@ -0,0 +1,56 @@
+#
+# Copyright (C) 2015 OpenWrt.org
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+
+include $(TOPDIR)/rules.mk
+include $(INCLUDE_DIR)/kernel.mk
+
+PKG_NAME:=ubnt_hsr
+PKG_VERSION:=0.1
+PKG_RELEASE:=1
+PKG_BUILD_DEPENDS:=mac80211
+
+include $(INCLUDE_DIR)/package.mk
+
+define KernelPackage/ubnt-hsr
+ $(call KernelPackage/mac80211/Default)
+ SUBMENU:=Wireless Drivers
+ TITLE:=Driver for Ubiquiti UniFi Outdoor Plus HSR filter
+ URL:=http://wiki.openwrt.org/toh/ubiquiti/unifi_outdoorplus
+ DEPENDS:=@PCI_SUPPORT||TARGET_ar71xx kmod-ath9k
+ FILES:= $(PKG_BUILD_DIR)/ubnt_hsr.ko
+ AUTOLOAD:=$(call AutoProbe,ubnt_hsr)
+endef
+
+define KernelPackage/ubnt-hsr/description
+ubnt-hsr adds support for the 'High-Selectivity Receiver'
+RF filter built into the receive path of the Ubiquiti
+UniFi Outdoor Plus access point. It is required for this and
+only for this access point.
+endef
+
+include $(INCLUDE_DIR)/kernel-defaults.mk
+
+define Build/Prepare
+ mkdir -p $(PKG_BUILD_DIR)
+ cp src/Makefile src/ubnt_hsr.c $(PKG_BUILD_DIR)/
+endef
+
+define Build/Compile
+ $(MAKE) $(KERNEL_MAKEOPTS) SUBDIRS="$(PKG_BUILD_DIR)" \
+
LINUXINCLUDE="-I$(STAGING_DIR)/usr/include/mac80211-backport/uapi
-I$(STAGING_DIR)/usr/include/mac80211-backport \
+ -I$(STAGING_DIR)/usr/include/mac80211/uapi
-I$(STAGING_DIR)/usr/include/mac80211 \
+ -I$(LINUX_DIR)/include -I$(LINUX_DIR)/include/$(LINUX_UAPI_DIR)
\
+ -I$(LINUX_DIR)/include/generated/uapi/
-Iarch/$(LINUX_KARCH)/include \
+ -Iarch/$(LINUX_KARCH)/include/$(LINUX_UAPI_DIR) \
+ -Iarch/$(LINUX_KARCH)/include/generated \
+ -Iarch/$(LINUX_KARCH)/include/generated/$(LINUX_UAPI_DIR) \
+ -include generated/autoconf.h \
+ -include backport/backport.h " \
+ V="${V}" modules
+endef
+
+$(eval $(call KernelPackage,ubnt-hsr))
Index: package/kernel/ubnt-hsr/src/Makefile
===
--- package/kernel/ubnt-hsr/src/Makefile(Revision 0)
+++ package/kernel/ubnt-hsr/src/Makefile(Arbeitskopie)
@@ -0,0 +1 @@
+obj-m := ubnt_hsr.o
Index: package/kernel/ubnt-hsr/src/ubnt_hsr.c
===
--- package/kernel/ubnt-hsr/src/ubnt_hsr.c (Revision 0)
+++ package/kernel/ubnt-hsr/src/ubnt_hsr.c (Arbeitskopie)
@@ -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
+#include
+
+#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) {
+ 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_OUTPUT_MUX_AS_OUTPUT);
+ ath9k_h
[OpenWrt-Devel] [PATCH v2 1/2] Support Ubiquiti Unifi Outdoor Plus HSR filter
Add a "channel change helper" callback to the mac80211 package and
export the ath9k kernel API for other packages.
Signed-off-by: Stefan Rompf
---
Index: package/kernel/mac80211/Makefile
===
--- package/kernel/mac80211/Makefile(Revision 45695)
+++ package/kernel/mac80211/Makefile(Arbeitskopie)
@@ -1737,11 +1737,13 @@
$(1)/usr/include/mac80211 \
$(1)/usr/include/mac80211-backport \
$(1)/usr/include/mac80211/ath \
+ $(1)/usr/include/mac80211/ath/ath9k \
$(1)/usr/include/net/mac80211
$(CP) $(PKG_BUILD_DIR)/net/mac80211/*.h $(PKG_BUILD_DIR)/include/*
$(1)/usr/include/mac80211/
$(CP) $(PKG_BUILD_DIR)/backport-include/*
$(1)/usr/include/mac80211-backport/
$(CP) $(PKG_BUILD_DIR)/net/mac80211/rate.h
$(1)/usr/include/net/mac80211/
$(CP) $(PKG_BUILD_DIR)/drivers/net/wireless/ath/*.h
$(1)/usr/include/mac80211/ath/
+ $(CP) $(PKG_BUILD_DIR)/drivers/net/wireless/ath/ath9k/*.h
$(1)/usr/include/mac80211/ath/ath9k/
rm -f $(1)/usr/include/mac80211-backport/linux/module.h
endef
Index: package/kernel/mac80211/patches/930-ath9k_add_channel_set_helper.patch
===
--- package/kernel/mac80211/patches/930-ath9k_add_channel_set_helper.patch
(Revision 0)
+++ package/kernel/mac80211/patches/930-ath9k_add_channel_set_helper.patch
(Arbeitskopie)
@@ -0,0 +1,46 @@
+diff -X diffign -Npur kernel/drivers/net/wireless/ath/ath9k.orig/ath9k.h
kernel/drivers/net/wireless/ath/ath9k/ath9k.h
+--- kernel/drivers/net/wireless/ath/ath9k.orig/ath9k.h 2015-06-04
21:19:11.0 +0200
kernel/drivers/net/wireless/ath/ath9k/ath9k.h 2015-06-06
10:23:05.0 +0200
+@@ -1110,4 +1110,10 @@ static inline int ath_ahb_init(void) { r
+ static inline void ath_ahb_exit(void) {};
+ #endif
+
++/*
++ * OpenWrt channel set helper helper, needed f.e. for Ubiquiti UniFi Outdoor
Plus
++ */
++typedef void (set_channel_helper_fn)(struct ath_hw* ah, int bw, int fq);
++void ath9k_register_set_channel_helper(set_channel_helper_fn *); /* call
inside RTNL lock to guard against parallel channel change */
++
+ #endif /* ATH9K_H */
+diff -X diffign -Npur kernel/drivers/net/wireless/ath/ath9k.orig/channel.c
kernel/drivers/net/wireless/ath/ath9k/channel.c
+--- kernel/drivers/net/wireless/ath/ath9k.orig/channel.c 2015-03-10
04:37:15.0 +0100
kernel/drivers/net/wireless/ath/ath9k/channel.c2015-06-06
10:23:05.0 +0200
+@@ -16,6 +16,18 @@
+
+ #include "ath9k.h"
+
++/*
++ * OpenWrt channel set helper helper
++ */
++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 @@ static int ath_set_channel(struct ath_so
+ 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);
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 0/2] Support Ubiquiti Unifi Outdoor Plus HSR filter
Hi, this patchset adds support for the HSR filter of the Ubiquiti Unifi Outdoor Plus access point. The HSR is a configurable RF filter in the receive path that must be tuned according to the selected Wifi channel for the access point to work. Patch 1 adds a "channel change helper" callback to the mac80211 package and exports the ath9k kernel API for other packages. Patch 2 adds the actual tuner as a self contained kmod. The patchset is based on work of Kirill Berezin and me. Changes since last version: -Split into two packages to reduce impact on mac80211 -Merge Kirills latest updates of the HSR communication protocol. (Without ath_dbg() because of the split) I'm running the driver compiled against chaos calmer RC1 right now and compile test it with trunk. Not yet solved is how to add the kmod to the outdoor plus image only, but I'd really like to push these changes before -rc2. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH RFC] Add support for Ubiquiti Unifi Outdoor Plus
Hi Kirill, hi Arjen, thanks for your feedback. I'll create a new version of the patch with your updates and suggestions. I will also try to move the HSR tuner module into it's own subdirectory below package/kernel to minimize the mac80211 patch that Felix will have to maintain. > > I also tried to change target/linux/ar71xx/generic/profiles/ubnt.mk and > > target/linux/ar71xx/image/Makefile to include this module into the > > UBNTUNIFIOUTDOORPLUS image, but this fails. Any idea why? > > May be this happens when building a bunch of different profiles at once? I've also tried only one profile, no idea yet. Maybe Alexander Couzens' porting to new BuildCode helps. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH RFC] Add support for Ubiquiti Unifi Outdoor Plus
d
result)
++ if (status) {
++ int loop = 2;
++ do {
++ ++loop;
++ if (loop > 42) {
++ printk(KERN_NOTICE "hsr_write_a_chain: too many
loops in preamble. giving up.\n");
++ return -1;
++ }
++ status = hsr_write_byte(ah, HSR_DELAY_PRE_WRITE, 0);
++ } while(status);
++ }
++
++for ( i =0; (i < items) && ( 0 != chain[i]); ++i) {
++ hsr_write_byte(ah, HSR_DELAY_PRE_WRITE, (u32)chain[i]);
++ }
++ hsr_write_byte(ah, HSR_DELAY_PRE_WRITE, 0);
++ mdelay(HSR_DELAY_FINAL / 1000);
++
++ memset(chain, 0, items);
++
++ for ( j = 0, i = 0; (i < 7) && (j < (items - 1)) ; ++i) {
++ u32 ret;
++ if ( 31 < (ret = hsr_write_byte(ah, HSR_DELAY_PRE_WRITE, 0))) {
++ chain[j] = (char)ret;
++ ++ j;
++ }
++ udelay(HSR_DELAY_TRAILING);
++ }
++ /* printk(KERN_NOTICE "hsr_write_a_chain: j %d \n", j); */
++ return j > 1 ? simple_strtol(chain + 1, NULL, 10) : 0;
++}
++
++static int hsr_disable(struct ath_hw* ah) {
++ char cmd[10] = {'b', '4', '0', 0, 0, 0, 0, 0, 0, 0};
++ int ret;
++
++ ret = hsr_write_a_chain(ah, cmd, sizeof(cmd));
++ /* printk(KERN_NOTICE "hsr_disable: return %d \n", ret); */
++ if ( (ret > 0) && (*cmd == 'B')) {
++ printk(KERN_NOTICE "hsr_disable: bandwidth set %d \n", ret);
++ return 0;
++ }
++
++ return -1;
++}
++
++static int hsr_enable(struct ath_hw* ah, int bw, int fq) {
++ char cmd[10];
++ int ret;
++
++ memset(cmd, 0, sizeof(cmd));
++ *cmd = 'b'; // 98
++ snprintf(cmd + 1, 3, "%02d", bw);
++
++ ret = hsr_write_a_chain(ah, cmd, sizeof(cmd));
++ if ( (*cmd != 'B') || (ret != bw)) {
++ printk(KERN_NOTICE "hsr_enable: failed changing bandwidth ->
set (%d,%d) reply (%d, %d) \n", 'b', bw, *cmd, ret);
++ return -1;
++ }
++
++ memset(cmd, 0, sizeof(cmd));
++ *cmd = 'x'; // 120
++ ret = hsr_write_a_chain(ah, cmd, sizeof(cmd));
++ if ( *cmd != 'X') {
++ printk(KERN_NOTICE "hsr_enable: failed 'x' command -> reply
(%d, %d) \n", *cmd, ret);
++ return -1;
++ }
++
++ memset(cmd, 0, sizeof(cmd));
++ *cmd = 'm'; // 109
++ ret = hsr_write_a_chain(ah, cmd, sizeof(cmd));
++ if ( *cmd != 'M') {
++ printk(KERN_NOTICE "hsr_enable: failed 'm' command -> reply
(%d, %d) \n", *cmd, ret);
++ return -1;
++ }
++
++ memset(cmd, 0, sizeof(cmd));
++ *cmd = 'f'; // 102
++ snprintf(cmd + 1, 6, "%05d", fq);
++ ret = hsr_write_a_chain(ah, cmd, sizeof(cmd));
++ if ( (*cmd != 'F') && (ret != fq)) {
++ printk(KERN_NOTICE "hsr_enable: failed set frequency -> reply
(%d, %d) \n", *cmd, ret);
++ return -1;
++ }
++
++ printk(KERN_NOTICE "hsr_enable: center frequency %dMHz bandwidth %dMHz
\n", fq, bw);
++
++ return 0;
++}
++
++static int hsr_status(struct ath_hw* ah) {
++ char cmd[10] = {'s', 0, 0, 0, 0, 0, 0, 0, 0, 0}; // 115
++ int ret;
++
++ ret = hsr_write_a_chain(ah, cmd, sizeof(cmd));
++ if ( (*cmd != 'S')) {
++ printk(KERN_NOTICE "hsr_status: returned %d,%d \n", *cmd, ret);
++ return -1;
++ }
++
++ printk(KERN_NOTICE "hsr_status: current status is %d \n", ret);
++
++ return 0;
++}
++
++static void hsr_tune(struct ath_hw* ah, int bw, int fq) {
++ static int initialized;
++ static int last_bw, last_fq;
++
++ if (NULL == ah) {
++ return;
++ }
++
++ /* Bandwidth argument is 0 sometimes. Assume default 802.11bgn
++ 20MHz on invalid values */
++ if ( (bw != 5) && (bw != 10) && (bw != 20) && (bw != 40)) {
++ bw = 20;
++ }
++
++ if (bw == last_bw && fq == last_fq) {
++ /* Avoid tuning if nothing changes */
++ printk(KERN_NOTICE "hsr_tune: already tuned to center frequency
%dMHz bandwidth %dMHz\n", fq, bw);
++ return;
++ }
++
++ if (!initialized) {
++ initialized = 1;
++ hsr_init(ah);
++ }
++
++ if (!hsr_enable(ah, bw, fq)) {
++ hsr_status(ah);
++ last_bw = bw;
++ last_fq = fq;
++ } else {
++ /* Tuning failed - make sure that we try again */
++
Re: [OpenWrt-Devel] ar71xx: How to integrate UniFi AP Outdoor Plus HSR?
*cmd != 'S')) {
+ printk(KERN_NOTICE "hsr_status: returned %d,%d \n", *cmd, ret);
+ return -1;
+ }
+
+ printk(KERN_NOTICE "hsr_status: current status is %d \n", ret);
+
+ return 0;
+}
+
+static void hsr_tune(struct ath_hw* ah, int bw, int fq) {
+ static int initialized;
+
+ if (!initialized) {
+ initialized = 1;
+ hsr_init(ah);
+ }
+ hsr_enable(ah, bw, fq);
+ hsr_status(ah);
+}
+
+
+
+static int __init hsr_mod_init(void)
+{
+ rtnl_lock(); /* Should lock against nl80211_set_channel() */
+ ath9k_register_set_channel_helper(hsr_tune);
+ rtnl_unlock();
+}
+
+static void __exit hsr_mod_exit(void)
+{
+ rtnl_lock();
+ ath9k_register_set_channel_helper(NULL);
+ rtnl_unlock();
+}
+
+module_init(hsr_mod_init);
+module_exit(hsr_mod_exit);
+
+
+MODULE_AUTHOR("Kirill Berezin, Stefan Rompf");
+MODULE_DESCRIPTION("Support for Ubiquiti Outdoor Plus HSR filter.");
+MODULE_SUPPORTED_DEVICE("Ubiquiti Outdoor Plus");
+MODULE_LICENSE("GPL");
+
diff -Nur linux/drivers/net/wireless/ath/ath9k.orig/Makefile linux/drivers/net/wireless/ath/ath9k/Makefile
--- linux/drivers/net/wireless/ath/ath9k.orig/Makefile 2015-04-04 04:46:37.0 +0200
+++ linux/drivers/net/wireless/ath/ath9k/Makefile 2015-06-03 18:37:29.0 +0200
@@ -23,6 +23,10 @@
obj-$(CPTCFG_ATH9K) += ath9k.o
+ath9k_hsr-y := hsr.o
+
+obj-$(CPTCFG_ATH9K) += ath9k_hsr.o
+
ath9k_hw-y:= \
ar9002_hw.o \
ar9003_hw.o \
___
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 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
Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for the UniFi AP Outdoor Plus
Hi,
> It seems that ath9k does not even export its pins to the GPIO
> subsystem.
ok, here we go. For the brave ones who know their pci wifi chip is at
0x1000 and don't mind bit banging io registers.
Surely still all usleep() timers wrong and full of unknown side effects.
But tunes the hsr on my device.
Stefan
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
// High Selectivity Receiver?? Huh ...
int mem_fd;
char *mem_page;
unsigned int *mem_gpio;
#define HSR_CSR 8
#define HSR_OUT 7
#define HSR_CLK 6
#define HSR_IN 5
int create_dev() {
unsigned int *mem_dir;
unsigned int dir_val;
mem_fd = open("/dev/mem", O_RDWR);
if (mem_fd == -1) return -1;
mem_page = mmap(NULL, 4096, PROT_READ | PROT_WRITE,
MAP_SHARED, mem_fd, 0x10004000);
if (!mem_page) return -1;
mem_gpio = (unsigned int *)(&mem_page[0x48]);
/* Setup direction */
mem_dir = (unsigned int *)(&mem_page[0x4c]);
dir_val = *mem_dir | (3<> (7-i))&0x1 will be equal to
// seb v1,a1 --> mips32r2
// srl v0,v1,0x1f
// sll a1,v1,1 --> next to seb
if ((value >> (7 - i)) & 0x1) {
GPIO_SETBIT(HSR_OUT);
} else {
GPIO_CLRBIT(HSR_OUT);
}
usleep(1000);
GPIO_SETBIT(HSR_CLK);
usleep(1000);
rval |= !!GPIO_GETBIT(HSR_IN);
GPIO_CLRBIT(HSR_CLK);
usleep(1000);
}
GPIO_SETBIT(HSR_CSR);
usleep(1);
printf("write byte %d return value is %x \n", value, rval);
return rval & 0xff;
}
void write_a_chain(uint8_t* chain, int items) {
int i = 0;
int status = 0;
// a preabmle
hsr_write_byte(75, 0);
status = hsr_write_byte(75, 0);
/*
if ( status) {
int loop = 2;
do {
status = hsr_write_byte(d, 75, 0);
loop = (loop + 1) & 0x;
if ( loop < 2) {
continue;
}
} while(status);
}
*/
for ( i =0; i < items; ++i) {
hsr_write_byte(75, chain[i]);
}
for (i=0; i < 6 ; ++i) {
hsr_write_byte(75, 0);
}
usleep(15);
}
// known good commands: disable 98
int main(int argc, char** argv) {
int b = 40, cf = -1;
if ( argc < 2) {
printf("%s: bandwidth [center frequency kHz] \n", argv[0]);
return 1;
} else if ( argc < 3) {
b = 40; //strtol(argv[1], NULL, 10);
if ( (b != 10) && (b != 20) && (b != 40)) {
printf("Incorrect bandwidth : valid values are 10, 20, 40 \n");
return -1;
}
printf("Send a disable command \n");
} else {
b = strtol(argv[1], NULL, 10);
cf = strtol(argv[2], NULL, 10);
if ( (b != 10) && (b != 20) && (b != 40)) {
printf("Incorrect bandwidth : valid values are 10, 20, 40 \n");
return -1;
}
printf("Sent central freq %d and a bandwidth %d \n", cf, b);
}
if ( -1 != create_dev()) {
uint8_t chain[10];
uint8_t v1;
// write bandwidth
memset(chain, 0, sizeof(chain));
chain[0] = 98;
snprintf((char*)(chain + 1), 3, "%02d", b);
write_a_chain(chain, strlen((char*)chain));
if ( -1 != cf ) {
v1 = 120;
write_a_chain(&v1, 1);
v1 = 109;
write_a_chain(&v1, 1);
memset(chain, 0, sizeof(chain));
chain[0] = 102;
snprintf((char*)(chain + 1), 6, "%05d", cf);
write_a_chain(chain, strlen((char*)chain));
}
}
return 0;
}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for the UniFi AP Outdoor Plus
Hi Kirill, > Updated version is in the attachment. I tried it on a real device, but I > can't say that the problem was solved, but something is definitely happens. which OpenWrt image did you use? I flashed openwrt-15.05-rc1-ar71xx-generic- ubnt-unifi-outdoor-plus-squashfs-factory.bin and did not get any response from the hsr using your tool. Until I found that I was accessing GPIO lines of the CPU (cat /sys/devices/virtual/gpio/gpiochip0/label => ath79), not of the 928x wifi chip. It seems that ath9k does not even export its pins to the GPIO subsystem. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for the UniFi AP Outdoor Plus
Hi, > Updated version is in the attachment. I tried it on a real device, but I > can't say that the problem was solved, but something is definitely happens. related question: After installing OpenWRT on the access point, do you know whether I can revert using the instructions from: https://community.ubnt.com/t5/UniFi-Troubleshooting/UniFi-TFTP-soft-recovery-for-bricked-access-point/ta-p/607605 ? Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for the UniFi AP Outdoor Plus
Hi Kirill, > Updated version is in the attachment. I tried it on a real device, but I > can't say that the problem was solved, but something is definitely happens. > > Unfortunately I couldn't find where a bunch of zeros were generated, so > I skipped this part ))) (I tried a version with zeros, but no luck). I think the sequence looks like this: 00 00 b20 00 00 00 00 00 00 00 00 00 00 x 00 00 00 00 00 00 00 00 00 00 m 00 00 00 00 00 00 00 00 00 00 f02412 00 00 00 00 00 00 00 00 Two zeros preamble, the command, followed by 8 zeros. I haven't yet checked whether something is read while the commands are sent. Given that issueing a channel change takes noticeable time, you could try adding an usleep(15) after the eight zero bytes have been sent. Just guessing, maybe hsr.c is simply running too fast. > I also found in the code new commands 115 (lock), 120, 109, and 102. Haven't seen 115 in my logs so far... > However 2417 is a center for channel 2, but how knows ... Maybe my fault. The very first "ifconfig ath0 up" after the interface has been created with athbox sends multiple sequences switching to different channels, ending with the selected channel. >From this point on, a channel change sends one of the sequences above with the center frequency of the selected channel. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for the UniFi AP Outdoor Plus
Hi, > -Trapping ar5416GpioSet with some hand crafted assembly code that traces > calls and logs them somewhere this works. I've trapped ar5416GpioSet, putting my code into space occupied by the unused function ar5416GpioCfgInput. ar5416GpioGet is work to do. I can send the code, but it will require adoption to your environment. Tuning to channel 1 revealed the following commands sent via the SPI protocol you discovered (first column is number of repetitions). 2 00 00 00 00 00 00 00 00 1 00 01 01 00 00 00 01 00 (the 98 disable command) 1 00 00 01 01 00 00 01 00 1 00 00 01 01 00 00 00 00 10 00 00 00 00 00 00 00 00 1 00 01 01 01 01 00 00 00 10 00 00 00 00 00 00 00 00 1 00 01 01 00 01 01 00 01 10 00 00 00 00 00 00 00 00 1 00 01 01 00 00 01 01 00 1 00 00 01 01 00 00 00 00 1 00 00 01 01 00 00 01 00 1 00 00 01 01 00 01 00 00 1 00 00 01 01 00 00 00 01 1 00 00 01 01 00 01 01 01 7 00 00 00 00 00 00 00 00 1 00 00 00 00 00 00 00 00 I'll test repeated tuning, other channels and GpioGet next weekend, it's quite in the late evening here by now ;-) Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for the UniFi AP Outdoor Plus
Hi Kirill, On Dienstag, 19. Mai 2015 15:11:31 Kirill Berezin wrote: > I think that they tune an external receiver via some sort of SPI bus (GPIO > pins are 5,6,7,8). Write procedure is quite simple, but I can't still get > how enable works (for sure it sends a disable); it is quite possible that > we need to read from a device before sending a command. impressive! How did you succeed? I've started looking at two possibilities: -ARMSim -Trapping ar5416GpioSet with some hand crafted assembly code that traces calls and logs them somewhere (maybe an unused module like fuse could provide kernel space to scribble the logs ;-) Now that you decoded the init and disable sequences it should be possible to find a command in such a log. Any hints? Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for the UniFi AP Outdoor Plus
Hi Matthias, > Any news here? I know a lot of people who are eager to run OpenWrt on > their UAP Outdoor+ ... oh well so nearly two months have passed I must admit no news. I am/was planning to run the code in ARMSim to analyze what is sent to the filter and from where. Still want to do this, may be we can work in parallel. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for the UniFi AP Outdoor Plus
Hi Sergey, > You should be a wizard to reveal hw protocol without touching hw :) I cannot say 'Mischief managed!' by now, but it's slowly making progress ;-) > Unlikely that iwconfig changes something directly, I would bet on the > driver. Indeed. So far -The RF filter is controlled by the GPIO pins on the AR928x wifi chip via some kind of serial protocol. -The functions responsible for the filter are ath_hal_hsr_init(), called once on initialisation, ath_hal_hsr_disable() and ath_hal_hsr_enable() on channel change. There is an ath_hal_hsr_get_lock_status() that does not seem to be used. -There seems to be no filter tuning after it has been setup on channel change. Reverse engineering this unreadable MIPS assembly mess will take some time... anyone willing to help? Does it make sense to open a ticket to track the issue or is this mailing list ok? Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for the UniFi AP Outdoor Plus
On Dienstag, 17. März 2015 23:24:26 Sergey Ryazanov wrote: > > Interesting enough: When stopping all wifi related software on the device > > and creating a monitor interface, the RF filter seems to follow > > "iwconfig channel" commands (yes it is the madwifi driver). > > How do you realized that RF filter follows "iwconfig channel" command? When I create a monitor interface and change from channel 1 to 13; tcpdump really sees channel 13 traffic. When I change back, tcpdump sees traffic from channel 1 again. If the filter had not followed, I would have expected the device to be as deaf as with current OpenWRT. Another interesting effect is that the access point is totally non responsable for 0.2 seconds after a channel change. This effect multiplies if you create a STA interface and do an "iwlist scan". Ping replies get delayed for seconds while the wifi is scanning and massively changing channels during the process. I cannot remember this effect when I used madwifi the last time ages ago. May be this is the RF filter code busy waiting somewhere in ath_set_channel() or below. Let's see if it can be found. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for the UniFi AP Outdoor Plus
Hi Sergey, > If they built SPIoverGPIO or I2CoverGPIO or some other serial bus over > GPIO, then you do not see any changes between channel switches. Or > they could use some non GPIO interface to communicate with external > filter (embedded SPI, I2C or even USB or PCI of SoC). well, GPIO has been the starting point, but it does not seem to be that easy ;-) Neither GPIO pins of the CPU nor the wifi chip change their static values based on the channel. I haven't yet compiled a tool to poll these memory locations fast enough to detect a protocol. > Possibly, you could see some changes during change. Try check GPIO > pins with oscillograph during channel change. Unfortunately opening the case is not an option. > Or you could put device in continuous scan (e.g. use STA mode and > enter some not available SSID to put device for infinite AP search) Interesting enough: When stopping all wifi related software on the device and creating a monitor interface, the RF filter seems to follow "iwconfig channel" commands (yes it is the madwifi driver). So the magic happens in iwconfig or the driver, not in some userspace daemon. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ubiquiti AirOS7 is based on openwrt r40432
Hi Federico, On Donnerstag, 12. März 2015 13:37:37 Nemesis wrote: > I went at this URL: > https://www.ubnt.com/download/?group=nanobeam-ac > > Clicked on "GPL Archive", downloaded it, extracted it, and took a look > in it and found out a readme file which states: > > that the archive contains all GPL related sources and modifications made > by Ubiquiti Networks on original OpenWRT-r40432 sources. UniFi also seems to be based on OpenWRT. Many kernel modules contain strings referencing /home/build-unifi/uap.build/openwrt/build_dir/, and they forgot to remove an /etc/config/ dir with unused OpenWRT files in their 3.2.7 release. However, I've found no GPL source on their homepage. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for the UniFi AP Outdoor Plus
Hi, On Mittwoch, 11. März 2015 15:14:21 Shvedov Yury wrote: > Thank you for your answer. We will try to solve this issue with our own > forces. any progress on this? I have one of these access points available right now for hacking (as long as I do not brick it). The last hours I made those findings: The libc of UBNT 3.2.7 seems to be compatible to tools of the old kamikaze release (http://downloads.openwrt.org/kamikaze/8.09/ar71xx/packages/). So far I've tested io for looking at the gpio ports and strace. It seems that the filter it not statically connected to gpio. By adressing AR71XX_GPIO_REG_SET and AR71XX_GPIO_REG_CLEAR, I could switch the blue and white leds as expected: /tmp/io -4 -w 0x18040010 1 # blue off /tmp/io -4 -w 0x1804000c 2 # white on Ten GPIO lines seem to be configured as output: /tmp/io -4 -r 0x1804 1804: 0cff However, independant of the channel selected the ports are always set to 0x00081405 (or 0x00081404 or 0x00081406 depending on the LED setting): BZ.v3.2.7# /tmp/io -4 -r 0x18040004 18040004: 00081405 If anyone has ideas where else to look, please share. Meanwhile let's see what I can do with strace ;-) Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
