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] [thread-next>] [day] [month] [year] [list]

Message-Id: <C53F8AC9-8F95-4191-A1E4-177AA1D0DA20@york.ac.uk>
Date:   Tue, 11 Jul 2017 16:01:16 +0100
From:   Russell Joyce <russell.joyce@...k.ac.uk>
To:     Arend van Spriel <arend.vanspriel@...adcom.com>
Cc:     Rafał Miłecki <zajec5@...il.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

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.

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