[OpenWrt-Devel] [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets
Sebastian Gottschall
s.gottschall at dd-wrt.com
Wed May 20 19:21:05 EDT 2020
Am 20.05.2020 um 21:05 schrieb Vincent Wiemann:
> Hi Sebastian,
>
> On 20.05.20 15:00, Sebastian Gottschall wrote:
>> Am 20.05.2020 um 12:40 schrieb Vincent Wiemann:
>>> Hi Sebastian,
>>>
>>> I don't know why it was dropped, but I can say that the LED control
>>> code was kind of
>>> annoying me. Even when the LED was turned of, it "flickered" when it
>>> was set disabled.
>>> Unfortunately I didn't have time to look into it, yet.
>> the led code will just be used if you set a trigger. otherwise it
>> doesnt touch the gpios.
>> 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
>>
> Thank you for your quick response... I'll try to reproduce the issue
> without your patch.
> Maybe it's unrelated and a firmware-specific issue (official QCA9887).
>
> One thing I've seen with your patch is that if I set the ath10k GPIO
> "steady on" it sometimes
> (quite randomly) turns it off for a fraction of a second. It happens
> about 3 times a minute.
> It's not a big deal. But maybe it's related to the flickering
> I've observed and possibly also a firmware issue...
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
the gpios. but i know that the firmware will reset the gpio state on
certain events like channel reset/channel change.
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.
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
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
identical to the qca9887, just the amount of antennas is different
>
> Best,
>
> Vincent
>
>
>>> Best,
>>>
>>> Vincent
>>>
>>> On 20.05.20 09:39, Sebastian Gottschall wrote:
>>>> this code is not in use in its original form for ipq4019.
>>>> i have seen that his patch is also dropped from ath.git but is
>>>> still in use by openwrt.
>>>> could somone clarify the state here and why it was dropped?
>>>> the original patch i wrote does exclude the soc chipsets, but the
>>>> patch was later reorganized and some part have been rewritten
>>>> so i'm not sure if it covers the scenario mentioned here, which i
>>>> did take care of
>>>>
>>>> Sebastian
>>>>
>>>> Am 26.02.2019 um 10:16 schrieb Sven Eckelmann:
>>>>> On Friday, 6 April 2018 17:17:55 CET Kalle Valo wrote:
>>>>>> From: Sebastian Gottschall <s.gottschall at newmedia-net.de>
>>>>>>
>>>>>> Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0,
>>>>>> 9984 based
>>>>>> chipsets with on chipset connected led's using WMI Firmware API.
>>>>>> The LED
>>>>>> device will get available named as "ath10k-phyX" at sysfs and can
>>>>>> be controlled
>>>>>> with various triggers. adds also debugfs interface for gpio
>>>>>> control.
>>>>>>
>>>>>> Signed-off-by: Sebastian Gottschall <s.gottschall at dd-wrt.com>
>>>>>> Reviewed-by: Steve deRosier <derosier at cal-sierra.com>
>>>>>> [kvalo: major reorg and cleanup]
>>>>>> Signed-off-by: Kalle Valo <kvalo at codeaurora.org>
>>>>> This patch was imported to OpenWrt in commit 61d57a2f88b9
>>>>> ("mac80211: ath10k
>>>>> add leds support") and broke the 11s support for IPQ4019 and
>>>>> QCA4019 (5GHz)
>>>>> firmware versions 10.4-3.5.3-00053, 10.4-3.5.3-00057, 10.4-3.6-00140:
>>>>>
>>>>> [ 221.620803] ath10k_pci 0000:01:00.0: wmi command 36967
>>>>> timeout, restarting hardware
>>>>> [ 221.744056] ieee80211 phy0: Hardware restart was requested
>>>>> [ 225.130829] ath10k_pci 0000:01:00.0: failed to receive
>>>>> control response completion, polling..
>>>>> [ 226.170824] ath10k_pci 0000:01:00.0: Service connect
>>>>> timeout
>>>>> [ 226.170871] ath10k_pci 0000:01:00.0: failed to connect
>>>>> htt (-110)
>>>>> [ 226.252248] ath10k_pci 0000:01:00.0: Could not init
>>>>> core: -110
>>>>>
>>>>> This was tested on an A62 with following wireless config:
>>>>>
>>>>> config wifi-device 'radio0'
>>>>> option type 'mac80211'
>>>>> option channel '36'
>>>>> option hwmode '11a'
>>>>> option path
>>>>> 'soc/40000000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
>>>>> option htmode 'VHT80'
>>>>> option disabled '0'
>>>>> option country US
>>>>> config wifi-device 'radio1'
>>>>> option type 'mac80211'
>>>>> option channel '11'
>>>>> option hwmode '11g'
>>>>> option path 'platform/soc/a000000.wifi'
>>>>> option htmode 'HT20'
>>>>> option disabled '0'
>>>>> option country US
>>>>> config wifi-device 'radio2'
>>>>> option type 'mac80211'
>>>>> option channel '149'
>>>>> option hwmode '11a'
>>>>> option path 'platform/soc/a800000.wifi'
>>>>> option htmode 'VHT80'
>>>>> option disabled '0'
>>>>> option country US
>>>>> config wifi-iface 'mesh0'
>>>>> option device 'radio0'
>>>>> option ifname 'mesh0'
>>>>> option network 'nwi_mesh0'
>>>>> option mode 'mesh'
>>>>> option mesh_id 'TestMesh'
>>>>> option mesh_fwding '1'
>>>>> option encryption 'none'
>>>>> config wifi-iface 'mesh1'
>>>>> option device 'radio1'
>>>>> option ifname 'mesh1'
>>>>> option network 'nwi_mesh1'
>>>>> option mode 'mesh'
>>>>> option mesh_id 'TestMesh'
>>>>> option encryption 'none'
>>>>> config wifi-iface 'mesh2'
>>>>> option device 'radio2'
>>>>> option ifname 'mesh2'
>>>>> option network 'nwi_mesh2'
>>>>> option mode 'mesh'
>>>>> option mesh_id 'TestMesh'
>>>>> option mesh_fwding '1'
>>>>> option encryption 'none
>>>>>
>>>>> Kind regards,
>>>>> Sven
>>>> _______________________________________________
>>>> openwrt-devel mailing list
>>>> openwrt-devel at lists.openwrt.org
>>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>>>
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel at lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20200521/e3cdb4ee/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
More information about the openwrt-devel
mailing list