Hello, It's probably driven by a GPIO on the radio itself. Possibly monitor /sys/kernel/debug/ieee80211/phy[0-9]/ath9k/regidx and /sys/kernel/debug/ieee80211/phy[0-9]/ath9k/regval. Perhaps someone with a datasheet might be able to tell you which register(s) it *could* be tied to, then take Sergey's strategy and watch changes to those registers.
* Just a thought, I could be completely wrong :) * -- Davey On Mon, Mar 16, 2015 at 6:37 PM, Sergey Ryazanov <ryazanov....@gmail.com> wrote: > Hello Stefan, > > 2015-03-16 23:36 GMT+03:00 Stefan Rompf <ste...@loplof.de>: >> 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 ;-) >> > 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). > > Possibly, you could see some changes during change. Try check GPIO > pins with oscillograph during channel change. > > 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) > and then read GPIO register state in circle. That trick does not > reveal actual protocol, but shows GPIO lines in use, if any. > > -- > Sergey > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel