linux-kernel - Re: [PATCH] ath9k: fix build error with LEDS

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: <CAK8P3a1NEbZtXVA0Z4P3K97L9waBp7nkCWOkdYjR3+7FUF0P0Q@mail.gmail.com>
Date:   Mon, 25 Jan 2021 15:38:07 +0100
From:   Arnd Bergmann <arnd@...nel.org>
To:     Krzysztof Kozlowski <krzk@...nel.org>
Cc:     QCA ath9k Development <ath9k-devel@....qualcomm.com>,
        Kalle Valo <kvalo@...eaurora.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Johannes Berg <johannes@...solutions.net>,
        Arnd Bergmann <arnd@...db.de>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Flavio Suligoi <f.suligoi@...m.it>,
        linux-wireless <linux-wireless@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ath9k: fix build error with LEDS_CLASS=m

On Mon, Jan 25, 2021 at 2:27 PM Krzysztof Kozlowski <krzk@...nel.org> wrote:
> On Mon, 25 Jan 2021 at 14:09, Arnd Bergmann <arnd@...nel.org> wrote:
> > On Mon, Jan 25, 2021 at 12:40 PM Krzysztof Kozlowski <krzk@...nel.org> wrote:
> > > On Mon, 25 Jan 2021 at 12:36, Arnd Bergmann <arnd@...nel.org> wrote:
> > > But we do not want to have this dependency (selecting MAC80211_LEDS).
> > > I fixed this problem here:
> > > https://lore.kernel.org/lkml/20201227143034.1134829-1-krzk@kernel.org/
> > > Maybe let's take this approach?
> >
> > Generally speaking, I don't like to have a device driver specific Kconfig
> > setting 'select' a subsystem', for two reasons:
> >
> > - you suddenly get asked for tons of new LED specific options when
> >   enabling seemingly benign options
> >
> > - Mixing 'depends on' and 'select' leads to bugs with circular
> >   dependencies that usually require turning some other 'select'
> >   into 'depends on'.
> >
> > The problem with LEDS_CLASS in particular is that there is a mix of drivers
> > using one vs the other roughly 50:50.
>
> Yes, you are right, I also don't like it. However it was like this
> before my commit so I am not introducing a new issue. The point is
> that in your choice the MAC80211_LEDS will be selected if LEDS_CLASS
> is present, which is exactly what I was trying to fix/remove. My WiFi
> dongle does not have a LED and it causes a periodic (every second)
> event. However I still have LEDS_CLASS for other LEDS in the system.

What is the effect of this lost event every second? If it causes some
runtime warning or other problem, then neither of our fixes would
solve it completely, because someone with a distro kernel would
see the same issue when they have the symbol enabled but no
physical LED in the device.

      Arnd