<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-text-flowed" style="font-family: -moz-fixed;
font-size: 13px;" lang="x-unicode">
<br>
Am 20.05.2020 um 21:05 schrieb Vincent Wiemann:
<br>
<blockquote type="cite" style="color: #007cff;">Hi Sebastian,
<br>
<br>
On 20.05.20 15:00, Sebastian Gottschall wrote:
<br>
<blockquote type="cite" style="color: #007cff;">Am 20.05.2020 um
12:40 schrieb Vincent Wiemann:
<br>
<blockquote type="cite" style="color: #007cff;">Hi Sebastian,
<br>
<br>
I don't know why it was dropped, but I can say that the LED
control code was kind of
<br>
annoying me. Even when the LED was turned of, it "flickered"
when it was set disabled.
<br>
Unfortunately I didn't have time to look into it, yet.
<br>
</blockquote>
the led code will just be used if you set a trigger. otherwise
it doesnt touch the gpios.
<br>
the code itself was written to make use of the led's builtin
to several routers. if you dont set a led trigger, nothing
will happen
<br>
<br>
</blockquote>
Thank you for your quick response... I'll try to reproduce the
issue without your patch.
<br>
Maybe it's unrelated and a firmware-specific issue (official
QCA9887).
<br>
<br>
One thing I've seen with your patch is that if I set the ath10k
GPIO "steady on" it sometimes
<br>
(quite randomly) turns it off for a fraction of a second. It
happens about 3 times a minute.
<br>
It's not a big deal. But maybe it's related to the flickering
<br>
I've observed and possibly also a firmware issue...
<br>
</blockquote>
my code only sets the gpio state based on the led trigger code. so
basicly linux is handling it, my code just provides the code to
access
<br>
the gpios. but i know that the firmware will reset the gpio state
on certain events like channel reset/channel change.
<br>
but as i said. if you dont set a trigger, my code will not control
the gpio of the chipset in any way and keeps it untouched.
<br>
so whatever you see, can only be caused by the firmware itself.
what i can say is that on qca988x chipsets i have never seen
<br>
such a behaviour. the connected led on pin 1 is always off without
a trigger and with a trigger its doing what it should do. and the
988x is basicly
<br>
identical to the qca9887, just the amount of antennas is different
<br>
<blockquote type="cite" style="color: #007cff;">
<br>
Best,
<br>
<br>
Vincent
<br>
<br>
<br>
<blockquote type="cite" style="color: #007cff;">
<blockquote type="cite" style="color: #007cff;">Best,
<br>
<br>
Vincent
<br>
<br>
On 20.05.20 09:39, Sebastian Gottschall wrote:
<br>
<blockquote type="cite" style="color: #007cff;">this code is
not in use in its original form for ipq4019.
<br>
i have seen that his patch is also dropped from ath.git
but is still in use by openwrt.
<br>
could somone clarify the state here and why it was
dropped?
<br>
the original patch i wrote does exclude the soc chipsets,
but the patch was later reorganized and some part have
been rewritten
<br>
so i'm not sure if it covers the scenario mentioned here,
which i did take care of
<br>
<br>
Sebastian
<br>
<br>
Am 26.02.2019 um 10:16 schrieb Sven Eckelmann:
<br>
<blockquote type="cite" style="color: #007cff;">On Friday,
6 April 2018 17:17:55 CET Kalle Valo wrote:
<br>
<blockquote type="cite" style="color: #007cff;">From:
Sebastian Gottschall <a class="moz-txt-link-rfc2396E"
href="mailto:s.gottschall@newmedia-net.de"><s.gottschall@newmedia-net.de></a>
<br>
<br>
Adds LED and GPIO Control support for 988x, 9887,
9888, 99x0, 9984 based
<br>
chipsets with on chipset connected led's using WMI
Firmware API. The LED
<br>
device will get available named as "ath10k-phyX" at
sysfs and can be controlled
<br>
with various triggers. adds also debugfs interface
for gpio control.
<br>
<br>
Signed-off-by: Sebastian Gottschall <a
class="moz-txt-link-rfc2396E"
href="mailto:s.gottschall@dd-wrt.com"><s.gottschall@dd-wrt.com></a>
<br>
Reviewed-by: Steve deRosier <a
class="moz-txt-link-rfc2396E"
href="mailto:derosier@cal-sierra.com"><derosier@cal-sierra.com></a>
<br>
[kvalo: major reorg and cleanup]
<br>
Signed-off-by: Kalle Valo <a
class="moz-txt-link-rfc2396E"
href="mailto:kvalo@codeaurora.org"><kvalo@codeaurora.org></a>
<br>
</blockquote>
This patch was imported to OpenWrt in commit
61d57a2f88b9 ("mac80211: ath10k
<br>
add leds support") and broke the 11s support for IPQ4019
and QCA4019 (5GHz)
<br>
firmware versions 10.4-3.5.3-00053, 10.4-3.5.3-00057,
10.4-3.6-00140:
<br>
<br>
[ 221.620803] ath10k_pci 0000:01:00.0: wmi
command 36967 timeout, restarting hardware
<br>
[ 221.744056] ieee80211 phy0: Hardware restart
was requested
<br>
[ 225.130829] ath10k_pci 0000:01:00.0: failed to
receive control response completion, polling..
<br>
[ 226.170824] ath10k_pci 0000:01:00.0: Service
connect timeout
<br>
[ 226.170871] ath10k_pci 0000:01:00.0: failed to
connect htt (-110)
<br>
[ 226.252248] ath10k_pci 0000:01:00.0: Could not
init core: -110
<br>
<br>
This was tested on an A62 with following wireless
config:
<br>
<br>
config wifi-device 'radio0'
<br>
option type 'mac80211'
<br>
option channel '36'
<br>
option hwmode '11a'
<br>
option path
'soc/40000000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
<br>
option htmode 'VHT80'
<br>
option disabled '0'
<br>
option country US
<br>
config wifi-device 'radio1'
<br>
option type 'mac80211'
<br>
option channel '11'
<br>
option hwmode '11g'
<br>
option path 'platform/soc/a000000.wifi'
<br>
option htmode 'HT20'
<br>
option disabled '0'
<br>
option country US
<br>
config wifi-device 'radio2'
<br>
option type 'mac80211'
<br>
option channel '149'
<br>
option hwmode '11a'
<br>
option path 'platform/soc/a800000.wifi'
<br>
option htmode 'VHT80'
<br>
option disabled '0'
<br>
option country US
<br>
config wifi-iface 'mesh0'
<br>
option device 'radio0'
<br>
option ifname 'mesh0'
<br>
option network 'nwi_mesh0'
<br>
option mode 'mesh'
<br>
option mesh_id 'TestMesh'
<br>
option mesh_fwding '1'
<br>
option encryption 'none'
<br>
config wifi-iface 'mesh1'
<br>
option device 'radio1'
<br>
option ifname 'mesh1'
<br>
option network 'nwi_mesh1'
<br>
option mode 'mesh'
<br>
option mesh_id 'TestMesh'
<br>
option encryption 'none'
<br>
config wifi-iface 'mesh2'
<br>
option device 'radio2'
<br>
option ifname 'mesh2'
<br>
option network 'nwi_mesh2'
<br>
option mode 'mesh'
<br>
option mesh_id 'TestMesh'
<br>
option mesh_fwding '1'
<br>
option encryption 'none
<br>
<br>
Kind regards,
<br>
Sven
<br>
</blockquote>
_______________________________________________
<br>
openwrt-devel mailing list
<br>
<a class="moz-txt-link-abbreviated"
href="mailto:openwrt-devel@lists.openwrt.org">openwrt-devel@lists.openwrt.org</a>
<br>
<a class="moz-txt-link-freetext"
href="https://lists.openwrt.org/mailman/listinfo/openwrt-devel">https://lists.openwrt.org/mailman/listinfo/openwrt-devel</a>
<br>
<br>
</blockquote>
</blockquote>
_______________________________________________
<br>
openwrt-devel mailing list
<br>
<a class="moz-txt-link-abbreviated"
href="mailto:openwrt-devel@lists.openwrt.org">openwrt-devel@lists.openwrt.org</a>
<br>
<a class="moz-txt-link-freetext"
href="https://lists.openwrt.org/mailman/listinfo/openwrt-devel">https://lists.openwrt.org/mailman/listinfo/openwrt-devel</a>
<br>
</blockquote>
</blockquote>
</div>
</body>
</html>