Re: LED support for QCA9980

Re: LED support for QCA9980

[Tolga Cakir]

> Thanks to some hero's sleuthing around a GPL source dump
> (https://forum.openwrt.org/viewtopic.php?pid=336237#p336237) and a
> later suggestion to try flipping bits from userspace (using
> https://github.com/billfarrow/pcimem), I can report that, at least for
> the two QCA9980s in my possession (within the TP-Link C2600 gateway I
> have) that the speculation is correct: kicking on bit 17 (the value of
> ATH_BEELINER_LED) in 0x85018 of resource0 makes bit 17 in 0x85000 an
> active-low controller for the LEDs attached to the chip.

Hi! I've got the Zyxel NBG6817, which uses QCA9984 SoCs - very similar
to yours. I've investigated Zyxel's OEM firmware and also came across
QCA9984 GPIO pin 17 beeing used for the WiFi 2.4G and 5G LEDs.
Interestingly enough, Netgear R7800 also uses GPIO pin 17, according
to their firmware sources. Unfortunately, I was not able to find out
any address or verify your supplied address or find any other way to
manipulate the WiFi SoC's GPIOs.

I'm a hobby programmer and have worked on reverse-engineering USB
devices and Linux kernel drivers in the past and am now interested in
getting this to work. I'm familiar with the Linux LED API, but I'm
completely new to networking / PCI / ath10k.

What I need is a hint, how to cleanly access QCA9984 GPIOs (or atleast
GPIO pin 17) within ath10k / kernel. Exposing that access to userspace
via Linux LED API is not an issue - I can do that.

Any ideas? I'm thankful for any help or hint I can get!

Cheers,
Tolga

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: LED support for QCA9980

[Nathaniel Filardo]

Hi!  You may find the following script I run on my ath10k board useful.

#!/bin/sh

DEVNAME=$1; shift
DEVPATH=/sys/class/net/${DEVNAME}/device

if [ ! -r ${DEVPATH}/vendor -o ! -r ${DEVPATH}/device ]; then
  echo "Bad device name?  No /vendor or /device sys file in ${DEVPATH}"
  exit 1
fi

PCIID="$(cat ${DEVPATH}/vendor):$(cat ${DEVPATH}/device)"

if [ "0x168c:0x0040" != "${PCIID}" ]; then
  echo "Bad PCI ID: ${PCIID}; bailing out!"
  exit 1
fi

dopcimem() {
  # echo pcimem ${DEVPATH}/resource0 $1 w $2 >&2
  pcimem ${DEVPATH}/resource0 $1 w $2 | sed -ne 's/^Value at [^:]*:
\(.*\)$/\1/p'
}

ORIG18=$(dopcimem 0x85018)
ORIG00=$(dopcimem 0x85000)

case $1 in
  on)
     dopcimem 0x85018 $((${ORIG18} |  0x20000)) # init
     dopcimem 0x85000 $((${ORIG00} & ~0x20000)) # active low
     ;;
  off)
     dopcimem 0x85000 $((${ORIG00} |  0x20000)) # inactive high
     dopcimem 0x85018 $((${ORIG18} & ~0x20000)) # deinit
     ;;
  *) echo "Dunno how to '$2'?  Try 'on' or 'off'"
     exit 1
     ;;
esac


Run as, for example, "./ath-leds.sh wlan0 on".

Cheers!
--nwf;

On Tue, Oct 24, 2017 at 5:32 PM, Tolga Cakir <cevelnet@gmail.com> wrote:
>> Thanks to some hero's sleuthing around a GPL source dump
>> (https://forum.openwrt.org/viewtopic.php?pid=336237#p336237) and a
>> later suggestion to try flipping bits from userspace (using
>> https://github.com/billfarrow/pcimem), I can report that, at least for
>> the two QCA9980s in my possession (within the TP-Link C2600 gateway I
>> have) that the speculation is correct: kicking on bit 17 (the value of
>> ATH_BEELINER_LED) in 0x85018 of resource0 makes bit 17 in 0x85000 an
>> active-low controller for the LEDs attached to the chip.
>
> Hi! I've got the Zyxel NBG6817, which uses QCA9984 SoCs - very similar
> to yours. I've investigated Zyxel's OEM firmware and also came across
> QCA9984 GPIO pin 17 beeing used for the WiFi 2.4G and 5G LEDs.
> Interestingly enough, Netgear R7800 also uses GPIO pin 17, according
> to their firmware sources. Unfortunately, I was not able to find out
> any address or verify your supplied address or find any other way to
> manipulate the WiFi SoC's GPIOs.
>
> I'm a hobby programmer and have worked on reverse-engineering USB
> devices and Linux kernel drivers in the past and am now interested in
> getting this to work. I'm familiar with the Linux LED API, but I'm
> completely new to networking / PCI / ath10k.
>
> What I need is a hint, how to cleanly access QCA9984 GPIOs (or atleast
> GPIO pin 17) within ath10k / kernel. Exposing that access to userspace
> via Linux LED API is not an issue - I can do that.
>
> Any ideas? I'm thankful for any help or hint I can get!
>
> Cheers,
> Tolga

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: LED support for QCA9980

[Sebastian Gottschall]

i wrote a patch for ath10k now which implements a gpio chip and led 
subsystem for the ath10k driver.
all common ath10k chipsets are supported. so 99xx, 9984, 988x, ipq4019 
etc. will work with the correct led pin assignment.
i will publish it here after i cleaned it up

sample:
root@OTAi:/sys/devices/virtual/leds/ath10k-phy0# cat trigger
none gpio switch0 phy0rx phy0tx phy0assoc phy0radio [phy0tpt]


Sebastian


Am 24.10.2017 um 23:51 schrieb Nathaniel Filardo:
> Hi!  You may find the following script I run on my ath10k board useful.
>
> #!/bin/sh
>
> DEVNAME=$1; shift
> DEVPATH=/sys/class/net/${DEVNAME}/device
>
> if [ ! -r ${DEVPATH}/vendor -o ! -r ${DEVPATH}/device ]; then
>    echo "Bad device name?  No /vendor or /device sys file in ${DEVPATH}"
>    exit 1
> fi
>
> PCIID="$(cat ${DEVPATH}/vendor):$(cat ${DEVPATH}/device)"
>
> if [ "0x168c:0x0040" != "${PCIID}" ]; then
>    echo "Bad PCI ID: ${PCIID}; bailing out!"
>    exit 1
> fi
>
> dopcimem() {
>    # echo pcimem ${DEVPATH}/resource0 $1 w $2 >&2
>    pcimem ${DEVPATH}/resource0 $1 w $2 | sed -ne 's/^Value at [^:]*:
> \(.*\)$/\1/p'
> }
>
> ORIG18=$(dopcimem 0x85018)
> ORIG00=$(dopcimem 0x85000)
>
> case $1 in
>    on)
>       dopcimem 0x85018 $((${ORIG18} |  0x20000)) # init
>       dopcimem 0x85000 $((${ORIG00} & ~0x20000)) # active low
>       ;;
>    off)
>       dopcimem 0x85000 $((${ORIG00} |  0x20000)) # inactive high
>       dopcimem 0x85018 $((${ORIG18} & ~0x20000)) # deinit
>       ;;
>    *) echo "Dunno how to '$2'?  Try 'on' or 'off'"
>       exit 1
>       ;;
> esac
>
>
> Run as, for example, "./ath-leds.sh wlan0 on".
>
> Cheers!
> --nwf;
>
> On Tue, Oct 24, 2017 at 5:32 PM, Tolga Cakir <cevelnet@gmail.com> wrote:
>>> Thanks to some hero's sleuthing around a GPL source dump
>>> (https://forum.openwrt.org/viewtopic.php?pid=336237#p336237) and a
>>> later suggestion to try flipping bits from userspace (using
>>> https://github.com/billfarrow/pcimem), I can report that, at least for
>>> the two QCA9980s in my possession (within the TP-Link C2600 gateway I
>>> have) that the speculation is correct: kicking on bit 17 (the value of
>>> ATH_BEELINER_LED) in 0x85018 of resource0 makes bit 17 in 0x85000 an
>>> active-low controller for the LEDs attached to the chip.
>> Hi! I've got the Zyxel NBG6817, which uses QCA9984 SoCs - very similar
>> to yours. I've investigated Zyxel's OEM firmware and also came across
>> QCA9984 GPIO pin 17 beeing used for the WiFi 2.4G and 5G LEDs.
>> Interestingly enough, Netgear R7800 also uses GPIO pin 17, according
>> to their firmware sources. Unfortunately, I was not able to find out
>> any address or verify your supplied address or find any other way to
>> manipulate the WiFi SoC's GPIOs.
>>
>> I'm a hobby programmer and have worked on reverse-engineering USB
>> devices and Linux kernel drivers in the past and am now interested in
>> getting this to work. I'm familiar with the Linux LED API, but I'm
>> completely new to networking / PCI / ath10k.
>>
>> What I need is a hint, how to cleanly access QCA9984 GPIOs (or atleast
>> GPIO pin 17) within ath10k / kernel. Exposing that access to userspace
>> via Linux LED API is not an issue - I can do that.
>>
>> Any ideas? I'm thankful for any help or hint I can get!
>>
>> Cheers,
>> Tolga
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
>

-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

LED support for QCA9980

[Nathaniel Filardo]

Hallo ath10k@,

It seems that LED support is still missing in the latest versions of
the Linux ath10k driver; if that's not so, please ignore this message
entirely. :)

Thanks to some hero's sleuthing around a GPL source dump
(https://forum.openwrt.org/viewtopic.php?pid=336237#p336237) and a
later suggestion to try flipping bits from userspace (using
https://github.com/billfarrow/pcimem), I can report that, at least for
the two QCA9980s in my possession (within the TP-Link C2600 gateway I
have) that the speculation is correct: kicking on bit 17 (the value of
ATH_BEELINER_LED) in 0x85018 of resource0 makes bit 17 in 0x85000 an
active-low controller for the LEDs attached to the chip.

I'd attempt to wire this knowledge into the ath10k driver and the
broader LED framework within Linux and submit a patch, but I have no
idea where to begin such a task.  Perhaps it is, nevertheless, useful
to know and have confirmed?  I know blinking LEDs are a low priority
relative to getting packets on and off the air. :)

Cheers,
--nwf;

P.S. Please CC as I am not subscribed to ath10k@.

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k