Message-ID: <81137bf1-09a3-42ca-a9d6-fefeba693c05@dd-wrt.com>
Date: Fri, 10 May 2024 10:53:07 +0200
From: Sebastian Gottschall <s.gottschall@...wrt.com>
To: Christian Marangi <ansuelsmth@...il.com>, Kalle Valo <kvalo@...nel.org>
Cc: "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, linux-kernel@...r.kernel.org,
 ath10k@...ts.infradead.org, linux-wireless@...r.kernel.org,
 netdev@...r.kernel.org, Steve deRosier <derosier@...-sierra.com>,
 Stefan Lippers-Hollmann <s.l-h@....de>
Subject: Re: [PATCH v14] ath10k: add LED and GPIO controlling support for
 various chipsets


Am 09.05.2024 um 12:04 schrieb Christian Marangi:
> On Thu, May 09, 2024 at 07:50:40AM +0300, Kalle Valo wrote:
>> Ansuel Smith <ansuelsmth@...il.com> writes:
>>
>>> Il giorno sab 17 giu 2023 alle ore 19:28 Christian Marangi
>>> <ansuelsmth@...il.com> ha scritto:
>>>
>>>> On Fri, Jun 16, 2023 at 01:35:04PM +0200, Christian Marangi wrote:
>>>>> On Fri, Jun 16, 2023 at 08:03:23PM +0300, Kalle Valo wrote:
>>>>>> Christian Marangi <ansuelsmth@...il.com> writes:
>>>>>>
>>>>>>> From: Sebastian Gottschall <s.gottschall@...wrt.com>
>>>>>>>
>>>>>>> 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@...wrt.com>
>>>>>>> Reviewed-by: Steve deRosier <derosier@...-sierra.com>
>>>>>>> [kvalo: major reorg and cleanup]
>>>>>>> Signed-off-by: Kalle Valo <kvalo@...eaurora.org>
>>>>>>> [ansuel: rebase and small cleanup]
>>>>>>> Signed-off-by: Christian Marangi <ansuelsmth@...il.com>
>>>>>>> Tested-by: Stefan Lippers-Hollmann <s.l-h@....de>
>>>>>>> ---
>>>>>>>
>>>>>>> Hi,
>>>>>>> this is a very old patch from 2018 that somehow was talked till 2020
>>>>>>> with Kavlo asked to rebase and resubmit and nobody did.
>>>>>>> So here we are in 2023 with me trying to finally have this upstream.
>>>>>>>
>>>>>>> A summarize of the situation.
>>>>>>> - The patch is from years in OpenWRT. Used by anything that has ath10k
>>>>>>>    card and a LED connected.
>>>>>>> - This patch is also used by the fw variant from Candela Tech with no
>>>>>>>    problem reported.
>>>>>>> - It was pointed out that this caused some problem with ipq4019 SoC
>>>>>>>    but the problem was actually caused by a different bug related to
>>>>>>>    interrupts.
>>>>>>>
>>>>>>> I honestly hope we can have this feature merged since it's really
>>>>>>> funny to have something that was so near merge and jet still not
>>>>>>> present and with devices not supporting this simple but useful
>>>>>>> feature.
>>>>>> Indeed, we should finally get this in. Thanks for working on it.
>>>>>>
>>>>>> I did some minor changes to the patch, they are in my pending branch:
>>>>>>
>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=686464864538158f22842dc49eddea6fa50e59c1
>>>>>>
>>>>>> My comments below, please review my changes. No need to resend because
>>>>>> of these.
>>>>>>
>>>>> Hi,
>>>>> very happy this is going further.
>>>>>
>>>>>>> --- a/drivers/net/wireless/ath/ath10k/Kconfig
>>>>>>> +++ b/drivers/net/wireless/ath/ath10k/Kconfig
>>>>>>> @@ -67,6 +67,23 @@ config ATH10K_DEBUGFS
>>>>>>>
>>>>>>>      If unsure, say Y to make it easier to debug problems.
>>>>>>>
>>>>>>> +config ATH10K_LEDS
>>>>>>> + bool "Atheros ath10k LED support"
>>>>>>> + depends on ATH10K
>>>>>>> + select MAC80211_LEDS
>>>>>>> + select LEDS_CLASS
>>>>>>> + select NEW_LEDS
>>>>>>> + default y
>>>>>>> + help
>>>>>>> +   This option enables LEDs support for chipset LED pins.
>>>>>>> +   Each pin is connected via GPIO and can be controlled using
>>>>>>> +   WMI Firmware API.
>>>>>>> +
>>>>>>> +   The LED device will get available named as "ath10k-phyX" at sysfs and
>>>>>>> +           can be controlled with various triggers.
>>>>>>> +
>>>>>>> +   Say Y, if you have LED pins connected to the ath10k wireless card.
>>>>>> I'm not sure anymore if we should ask anything from the user, better to
>>>>>> enable automatically if LED support is enabled in the kernel. So I
>>>>>> simplified this to:
>>>>>>
>>>>>> config ATH10K_LEDS
>>>>>>      bool
>>>>>>      depends on ATH10K
>>>>>>      depends on LEDS_CLASS=y || LEDS_CLASS=MAC80211
>>>>>>      default y
>>>>>>
>>>>>> This follows what mt76 does:
>>>>>>
>>>>>> config MT76_LEDS
>>>>>>      bool
>>>>>>      depends on MT76_CORE
>>>>>>      depends on LEDS_CLASS=y || MT76_CORE=LEDS_CLASS
>>>>>>      default y
>>>>>>
>>>>> I remember there was the same discussion in a previous series. OK for me
>>>>> for making this by default, only concern is any buildbot error (if any)
>>>>>
>>>>> Anyway OK for the change.
>>>>>
>>>>>>> @@ -65,6 +66,7 @@ static const struct ath10k_hw_params
>>>>>>> ath10k_hw_params_list[] = {
>>>>>>>            .dev_id = QCA988X_2_0_DEVICE_ID,
>>>>>>>            .bus = ATH10K_BUS_PCI,
>>>>>>>            .name = "qca988x hw2.0",
>>>>>>> +         .led_pin = 1,
>>>>>>>            .patch_load_addr = QCA988X_HW_2_0_PATCH_LOAD_ADDR,
>>>>>>>            .uart_pin = 7,
>>>>>>>            .cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
>>>>>> I prefer following the field order from struct ath10k_hw_params
>>>>>> declaration and also setting fields explicitly to zero (even though
>>>>>> there are gaps still) so I changed that for every entry.
>>>>>>
>>>>> Thanks for the change, np for me.
>>>>>
>>>>>>> +int ath10k_leds_register(struct ath10k *ar)
>>>>>>> +{
>>>>>>> + int ret;
>>>>>>> +
>>>>>>> + if (ar->hw_params.led_pin == 0)
>>>>>>> +         /* leds not supported */
>>>>>>> +         return 0;
>>>>>>> +
>>>>>>> + snprintf(ar->leds.label, sizeof(ar->leds.label), "ath10k-%s",
>>>>>>> +          wiphy_name(ar->hw->wiphy));
>>>>>>> + ar->leds.wifi_led.active_low = 1;
>>>>>>> + ar->leds.wifi_led.gpio = ar->hw_params.led_pin;
>>>>>>> + ar->leds.wifi_led.name = ar->leds.label;
>>>>>>> + ar->leds.wifi_led.default_state = LEDS_GPIO_DEFSTATE_KEEP;
>>>>>>> +
>>>>>>> + ar->leds.cdev.name = ar->leds.label;
>>>>>>> + ar->leds.cdev.brightness_set_blocking = ath10k_leds_set_brightness_blocking;
>>>>>>> +
>>>>>>> + /* FIXME: this assignment doesn't make sense as it's NULL, remove it? */
>>>>>>> + ar->leds.cdev.default_trigger = ar->leds.wifi_led.default_trigger;
>>>>>> But what to do with this FIXME?
>>>>>>
>>>>> It was pushed by you in v13.
>>>>>
>>>>> I could be wrong but your idea was to prepare for future support of
>>>>> other patch that would set the default_trigger to the mac80211 tpt.
>>>>>
>>>>> We might got both confused by default_trigger and default_state.
>>>>> default_trigger is actually never set and is NULL (actually it's 0)
>>>>>
>>>>> We have other 2 patch that adds tpt rates for the mac80211 LED trigger
>>>>> and set this trigger as the default one but honestly I would chose a
>>>>> different implementation than hardcoding everything.
>>>>>
>>>>> If it's ok for you, I would drop the comment and the default_trigger and
>>>>> I will send a follow-up patch to this adding DT support by using
>>>>> led_classdev_register_ext and defining init_data.
>>>>> (and this indirectly would permit better LED naming and defining of
>>>>> default-trigger in DT)
>>>>>
>>>>> Also ideally I will also send a patch for default_state following
>>>>> standard LED implementation. (to set default_state in DT)
>>>>>
>>>>> I would prefer this approach as the LED patch already took way too much
>>>>> time and I think it's better to merge this initial version and then
>>>>> improve it.
>>>> If you want to check out I attached the 2 patch (one dt-bindings and the
>>>> one for the code) that I will submit when this will be merged (the
>>>> change is with the assumption that the FIXME line is dropped)
>>>>
>>>> Tested and works correctly with my use case of wifi card attached with
>>>> pcie. This implementation permits to declare the default trigger in DT
>>>> instead of hardcoding.
>>>>
>>> Any news with this? Did I notice the LEDs patch are still in pending...
>> Sorry for the delay but finally I looked at this again. I decided to
>> just remove the fixme and otherwise it looks good for me. Please check
>> my changes:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=688130a66ed49f20ca0ce02c3987f6a474f7c93a
>>
> All ok for me, Just I notice the ATH10K_LEDS is not exposed anymore? Is
> that intended?
>
> Aside from this very happy that we are finally finishing with this long
> lasting feature!

since ATH10K_LEDS is no exposed option anymore. how is this feature 
enabled then? Its not selected by any dependency

Sebastian

>

Powered by blists - more mailing lists