From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin Blumenstingl Date: Mon, 27 Jun 2016 01:38:43 +0200 Subject: [ath9k-devel] [PATCH RFC v3 3/3] ath9k: parse the device configuration from an OF node In-Reply-To: <1973511.3caevZ3pSB@debian64> References: <20160624123430.4097-1-martin.blumenstingl@googlemail.com> <2421107.Vh3zsAgVDf@debian64> <1973511.3caevZ3pSB@debian64> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org On Sat, Jun 25, 2016 at 9:26 PM, Christian Lamparter wrote: > The problem with the owl-loader is/was that it sticks around > when it has initialized all the cards. Unloading a module by > itself is tough. One way out would be to add it to ath9k's pci.c. > The question is: will such a feature have support from the ath9k > folks? owl-loader seems very small (<7KiB) and it only allocates a few bytes dynamically. Even if you move this code to ath9k you will still have the same problem: as long as ath9k is not unloaded this code will hang around in memory. But apart from this - moving it to the kernel might have some benefits though as it could be shared between ath9k and ath5k (as some ath5k seem to require a similar "fixup" as well). > I've added lede-dev and Luis since this is relevant for them. > Maybe between the sysloadfw.sh and owl-loader, there's another > solution we overlooked so far? I know Luis has been digging > around in the firmware_class and added the sysdata API. But > from what I can tell, this would ?break? LEDE/OpenWRT's > userspace helper, since the sysfs interface in > /sys/class/firmware which is used by procd to upload the data > is gone with sysdata or am I wrong? good idea to keep lede-dev in the loop, as they will be affected (in my opinion: positively) by this change. Regards, Martin