linux-kernel - Re: [PATCH] brcmfmac: added LED triggers for transmit/receive

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 17 Jul 2017 06:59:07 +0200
From:   Rafał Miłecki <zajec5@...il.com>
To:     Russell Joyce <russell.joyce@...k.ac.uk>
Cc:     Arend van Spriel <arend.vanspriel@...adcom.com>,
        Alan Millard <alan.millard@...k.ac.uk>,
        Franky Lin <franky.lin@...adcom.com>,
        Hante Meuleman <hante.meuleman@...adcom.com>,
        Chi-Hsien Lin <chi-hsien.lin@...ress.com>,
        Wright Feng <wright.feng@...ress.com>,
        Kalle Valo <kvalo@...eaurora.org>,
        Marc Kleine-Budde <mkl@...gutronix.de>,
        Marcel Holtmann <marcel@...tmann.org>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Pieter-Paul Giesberts <pieter-paul.giesberts@...adcom.com>,
        Rafał Miłecki <rafal@...ecki.pl>,
        "mhiramat@...nel.org" <mhiramat@...nel.org>,
        James Hughes <james.hughes@...pberrypi.org>,
        Tobias Klauser <tklauser@...tanz.ch>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
        "open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER" 
        <brcm80211-dev-list.pdl@...adcom.com>,
        brcm80211-dev-list@...ress.com,
        Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH] brcmfmac: added LED triggers for transmit/receive

On 11 July 2017 at 17:01, Russell Joyce <russell.joyce@...k.ac.uk> wrote:
> Thanks for your comments.
>
>> What I think Rafał is saying is that it would be better to have this
>> code in cfg80211 so other drivers including mac80211 could use it.
>
>
> While I agree that moving all wireless LED triggers to cfg80211 would be an
> ideal situation, it seems a bit out of scope for what I was trying to achieve.
> This would probably also require removing the mac80211 LED triggers (and any
> other similar triggers that might be created by specific wireless drivers not
> using mac80211), in order to consolidate them in one place.
>
> Besides this, I'm not sure where exactly in cfg80211 this functionality would
> 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 a
> single complex trigger that exposes "rx" and "tx" parameters that can be
> individually enabled or disabled. This would reduce the number of triggers from
> three to one, but also makes things slightly more awkward for the user, and
> 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.

-- 
Rafał