linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Marangi <ansuelsmth@gmail.com>
To: Kalle Valo <kvalo@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	linux-kernel@vger.kernel.org, ath10k@lists.infradead.org,
	linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
	Sebastian Gottschall <s.gottschall@dd-wrt.com>,
	Steve deRosier <derosier@cal-sierra.com>,
	Stefan Lippers-Hollmann <s.l-h@gmx.de>
Subject: Re: [PATCH v14] ath10k: add LED and GPIO controlling support for various chipsets
Date: Fri, 16 Jun 2023 13:35:04 +0200	[thread overview]
Message-ID: <648cdebb.5d0a0220.be7f8.a096@mx.google.com> (raw)
In-Reply-To: <878rcjbaqs.fsf@kernel.org>

On Fri, Jun 16, 2023 at 08:03:23PM +0300, Kalle Valo wrote:
> Christian Marangi <ansuelsmth@gmail.com> writes:
> 
> > From: Sebastian Gottschall <s.gottschall@dd-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@dd-wrt.com>
> > Reviewed-by: Steve deRosier <derosier@cal-sierra.com>
> > [kvalo: major reorg and cleanup]
> > Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
> > [ansuel: rebase and small cleanup]
> > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> > Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.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.

-- 
	Ansuel

  reply	other threads:[~2023-06-16 22:14 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-11  8:05 [PATCH v14] ath10k: add LED and GPIO controlling support for various chipsets Christian Marangi
2023-06-16 17:03 ` Kalle Valo
2023-06-16 11:35   ` Christian Marangi [this message]
2023-06-16 21:27     ` Christian Marangi
2023-08-21 10:46       ` Ansuel Smith
2024-05-09  4:50         ` Kalle Valo
2024-05-09 10:04           ` Christian Marangi
2024-05-10  8:53             ` Sebastian Gottschall
2024-05-10 13:50             ` Kalle Valo
2024-05-10 14:09               ` Christian Marangi
2024-05-09 16:37           ` Jeff Johnson
2024-05-09 16:48             ` Jeff Johnson
2024-05-10 13:52               ` Kalle Valo
2024-05-10 14:14               ` Christian Marangi
2024-05-10 14:54                 ` Jeff Johnson
2024-05-11 14:17                   ` Kalle Valo
2024-05-13 15:08                     ` Jeff Johnson
2024-05-15  8:59 ` Kalle Valo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=648cdebb.5d0a0220.be7f8.a096@mx.google.com \
    --to=ansuelsmth@gmail.com \
    --cc=ath10k@lists.infradead.org \
    --cc=davem@davemloft.net \
    --cc=derosier@cal-sierra.com \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=kvalo@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=s.gottschall@dd-wrt.com \
    --cc=s.l-h@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).