[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87y1c3xj05.fsf@toke.dk>
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