archive mirror
 help / color / mirror / Atom feed
From: "Rafał Miłecki" <>
To: Russell Joyce <>
Cc: "Arend van Spriel" <>,
	"Alan Millard" <>,
	"Franky Lin" <>,
	"Hante Meuleman" <>,
	"Chi-Hsien Lin" <>,
	"Wright Feng" <>,
	"Kalle Valo" <>,
	"Marc Kleine-Budde" <>,
	"Marcel Holtmann" <>,
	"Michael S. Tsirkin" <>,
	"Pieter-Paul Giesberts" <>,
	"Rafał Miłecki" <>,
	"" <>,
	"James Hughes" <>,
	"Tobias Klauser" <>,
	"Linux Kernel Mailing List" <>,
	"" <>,
	"Network Development" <>
Subject: Re: [PATCH] brcmfmac: added LED triggers for transmit/receive
Date: Mon, 17 Jul 2017 06:59:07 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 11 July 2017 at 17:01, Russell Joyce <> wrote:
> Thanks for your comments.
>> What I think Rafa=C5=82 is saying is that it would be better to have thi=
>> code in cfg80211 so other drivers including mac80211 could use it.
> While I agree that moving all wireless LED triggers to cfg80211 would be =
> ideal situation, it seems a bit out of scope for what I was trying to ach=
> This would probably also require removing the mac80211 LED triggers (and =
> other similar triggers that might be created by specific wireless drivers=
> using mac80211), in order to consolidate them in one place.
> Besides this, I'm not sure where exactly in cfg80211 this functionality w=
> go (I assume it was originally put in mac80211 instead for a reason?),
> although I'm certainly no expert in this area of the kernel.

I don't expect you to rewrite all mac80211 drivers at this point. Just
focus on the generic cfg80211 helper and use it in brcmfmac. Other
cfg80211 drivers and mac80211 may follow in the future.

I'm not sure what's the best place in cfg80211 for this. Try
something, or try to get some comments from cfg80211 guys.

>> Indeed. However, the LED subsystem could/should(?) take care of mapping
>> "rx" and "tx" triggers to the same LED.
> In terms of the LED triggers, the only alternative I can see is to create=
> single complex trigger that exposes "rx" and "tx" parameters that can be
> individually enabled or disabled. This would reduce the number of trigger=
s from
> three to one, but also makes things slightly more awkward for the user, a=
> deviates from the convention set by mac80211.

Ideally we should have "rx" and "tx". LED subsystem should allow
assigning *both* (at the same time) to the LED.

I'll try to discuss with with LED guys this week.

Sorry, I was busy last week.


      reply	other threads:[~2017-07-17  4:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-07 14:09 [PATCH] brcmfmac: added LED triggers for transmit/receive Russell Joyce
2017-07-10  9:48 ` Rafał Miłecki
2017-07-10 17:02   ` Russell Joyce
2017-07-11  8:58     ` Arend van Spriel
2017-07-11 15:01       ` Russell Joyce
2017-07-17  4:59         ` Rafał Miłecki [this message]

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:

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

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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).