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]
Date: Fri, 02 Feb 2024 11:23:06 +0100
From: Toke Høiland-Jørgensen <toke@...e.dk>
To: Arnd Bergmann <arnd@...db.de>, Andy Shevchenko
 <andriy.shevchenko@...ux.intel.com>
Cc: Linus Walleij <linus.walleij@...aro.org>, Kalle Valo <kvalo@...nel.org>,
 Arend van Spriel <aspriel@...il.com>, Franky Lin
 <franky.lin@...adcom.com>, Hante Meuleman <hante.meuleman@...adcom.com>,
 Lee Jones <lee@...nel.org>, Brian Norris <briannorris@...omium.org>,
 Srinivasan Raju <srini.raju@...elifi.com>, linux-wireless@...r.kernel.org,
 linux-kernel@...r.kernel.org, brcm80211-dev-list.pdl@...adcom.com
Subject: Re: [PATCH 1/6] wifi: ath9k: Obtain system GPIOS from descriptors

"Arnd Bergmann" <arnd@...db.de> writes:

> On Thu, Feb 1, 2024, at 15:18, Toke Høiland-Jørgensen wrote:
>> "Arnd Bergmann" <arnd@...db.de> writes:
>>
>>> We could probably go a little further in the cleanup and
>>> throw out the gpiolib path entirely, instead relying
>>> on the existing leds-gpio driver. Since there are currently
>>> no upstream users of the gpiolib path, that would likely
>>> lead to cleaner code but require more changes to any
>>> out-of-tree users that rely on the platform_data to
>>> pass the GPIOs today.
>>
>> There being exactly one such out of tree user (per your up-thread
>> email) in OpenWrt? Or are you aware of others?
>
> Actually, on a closer look not even that: the ath9k LED support
> in openwrt is quite different from upstream, and it just uses
> gpio-led there, with a gpio provider in the driver for the
> internal gpios.
>
> We can probably just remove the gpiolib consumer side from
> ath9k entirely then: it's not needed for the PCI devices
> at all, and the SoC devices no longer use it upstream or
> in openwrt.

Alright cool, in that case I am OK with just ripping it out entirely :)

-Toke

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ