| Message ID | 20160624123430.4097-4-martin.blumenstingl@googlemail.com (mailing list archive) |
|---|---|
| State | RFC |
| Delegated to: | Kalle Valo |
| Headers | show |
On Friday, June 24, 2016 02:34:30 PM Martin Blumenstingl wrote: > This makes it possible to configure ath9k based devices using > devicetree. That makes some out-of-tree "convert devicetree to > ath9k_platform_data glue"-code obsolete. Hm, what about the embedded ath9k pcie chips that need the early pci-fixup routine for the device to work properly [0], [1]? How will this be handled/integrated? I know that the ar71xx and the lantiq platforms use similar pci-fixup routines that need a few bytes from the eeprom/cal data. So lantiq has a few extra properties: "ath,pci-slot", "ath,device-id" and "ath,eep-flash". As an example: the AR9280 in the Cisco Z1 AP is initially 0x168c:0xff1f (<-- ath9k doesn't know about that id). The pci-fixup routine will change it to 0x168c:0x002A. Only then ath9k can take it over and will initialize it. Thing is: this is all currently done by platform code for those architectures... And currently, the request_firmware doesn't work for caldata on UBI partitions. Regards, Christian [0] <https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/ar71xx/files/arch/mips/ath79/pci-ath9k-fixup.c;h=22023518069bc9b15b898f12f342b89563358e6a;hb=HEAD> [1] <https://dev.openwrt.org/browser/trunk/target/linux/lantiq/patches-4.4/0035-owrt-lantiq-wifi-and-ethernet-eeprom-handling.patch> -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Jun 25, 2016 at 2:01 PM, Christian Lamparter <chunkeey@googlemail.com> wrote: > On Friday, June 24, 2016 02:34:30 PM Martin Blumenstingl wrote: >> This makes it possible to configure ath9k based devices using >> devicetree. That makes some out-of-tree "convert devicetree to >> ath9k_platform_data glue"-code obsolete. > > Hm, what about the embedded ath9k pcie chips that need the early > pci-fixup routine for the device to work properly [0], [1]? How > will this be handled/integrated? I know that the ar71xx and the > lantiq platforms use similar pci-fixup routines that need a few > bytes from the eeprom/cal data. So lantiq has a few extra properties: > "ath,pci-slot", "ath,device-id" and "ath,eep-flash". that is exactly the use-case I want to use your owl-loader for (see [0], it's a small kernel module which adds the PCI configuration for ath9k devices). This makes ath,pci-slot and ath,eep-flash obsolete. As far as I'm aware ath,device-id is a bit of a special case (mtd_read issues when the caldata is stored at an unaligned position on NOR flash). So this might be obsolete as well when using owl-loader. > As an example: the AR9280 in the Cisco Z1 AP is initially > 0x168c:0xff1f (<-- ath9k doesn't know about that id). The > pci-fixup routine will change it to 0x168c:0x002A. Only > then ath9k can take it over and will initialize it. > Thing is: this is all currently done by platform code for > those architectures... And currently, the request_firmware > doesn't work for caldata on UBI partitions. request_firmware is working on UBI partitions in many cases. It's just not working when request_firmware is called too early (and this is not UBI specific, other filesystems might be affected as well): if it is called before rootfs is mounted (which is the case when you call it from a PCI fixup function) then it's not working (like you said). The "solution" to this is to compile the driver as kernel module (once this is loadable everything else should be readable as well). Not only ath9k is affected by this "issue", this is simply a limitation of request_firmware and/or the linux boot chain. A few words regarding your owl-loader: First of all I would like to say "thank you"! Mathias and I are working on changing the lantiq target in LEDE to use owl-loader for all (ath9k) devices. All I had to do was to add another OWL PCI ID, implement a fallback for the firmware filename when there is no ath9k_platform_data (I'm using the same pattern as in PATCH 3/3 in this series). You can find the WIP code here: [1] Regards, Martin [0] https://patchwork.ozlabs.org/patch/607682/ [1] https://github.com/xdarklight/source/commits/ath9k-owl-loader-20160624 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Saturday, June 25, 2016 05:08:29 PM Martin Blumenstingl wrote: > On Sat, Jun 25, 2016 at 2:01 PM, Christian Lamparter > <chunkeey@googlemail.com> wrote: > > On Friday, June 24, 2016 02:34:30 PM Martin Blumenstingl wrote: > >> This makes it possible to configure ath9k based devices using > >> devicetree. That makes some out-of-tree "convert devicetree to > >> ath9k_platform_data glue"-code obsolete. > > > > Hm, what about the embedded ath9k pcie chips that need the early > > pci-fixup routine for the device to work properly [0], [1]? How > > will this be handled/integrated? I know that the ar71xx and the > > lantiq platforms use similar pci-fixup routines that need a few > > bytes from the eeprom/cal data. So lantiq has a few extra properties: > > "ath,pci-slot", "ath,device-id" and "ath,eep-flash". > that is exactly the use-case I want to use your owl-loader for (see > [0], it's a small kernel module which adds the PCI configuration for > ath9k devices). Well, we also cooked up a userspace hack for OpenWRT/LEDE which would work with the existing code (for the case you mentioned below) [2]. Furthermore it also works for other devices, as long as the fw is in /lib/firmware and not in a subdirectory (But this can be fixed in 5 minutes with better bash foo). One thing that needs to be considered though: That script interferes with procd firmware loading if the "timing" is right. However usually procd has already finished all firmware requests by then. > This makes ath,pci-slot and ath,eep-flash obsolete. > As far as I'm aware ath,device-id is a bit of a special case (mtd_read > issues when the caldata is stored at an unaligned position on NOR > flash). So this might be obsolete as well when using owl-loader. 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? > > As an example: the AR9280 in the Cisco Z1 AP is initially > > 0x168c:0xff1f (<-- ath9k doesn't know about that id). The > > pci-fixup routine will change it to 0x168c:0x002A. Only > > then ath9k can take it over and will initialize it. > > Thing is: this is all currently done by platform code for > > those architectures... And currently, the request_firmware > > doesn't work for caldata on UBI partitions. > request_firmware is working on UBI partitions in many cases. > It's just not working when request_firmware is called too early (and > this is not UBI specific, other filesystems might be affected as > well): if it is called before rootfs is mounted (which is the case > when you call it from a PCI fixup function) then it's not working > (like you said). > The "solution" to this is to compile the driver as kernel module (once > this is loadable everything else should be readable as well). > Not only ath9k is affected by this "issue", this is simply a > limitation of request_firmware and/or the linux boot chain. > > A few words regarding your owl-loader: > First of all I would like to say "thank you"! > Mathias and I are working on changing the lantiq target in LEDE to use > owl-loader for all (ath9k) devices. > All I had to do was to add another OWL PCI ID, implement a fallback > for the firmware filename when there is no ath9k_platform_data (I'm > using the same pattern as in PATCH 3/3 in this series). You can find > the WIP code here: [1] 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? Regards, Christian > [0] https://patchwork.ozlabs.org/patch/607682/ > [1] https://github.com/xdarklight/source/commits/ath9k-owl-loader-20160624 [2] <https://github.com/riptidewave93/Openwrt-Z1/commit/9a38c60a1206b4010fbfb626fc7b2ec69bbe232a> -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Jun 25, 2016 at 9:26 PM, Christian Lamparter <chunkeey@googlemail.com> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jun 27, 2016 at 01:38:43AM +0200, Martin Blumenstingl wrote: > On Sat, Jun 25, 2016 at 9:26 PM, Christian Lamparter > <chunkeey@googlemail.com> wrote: > > 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. We cannot remove the /sys/class/firmware usermode helper, it however should be compartamentalized to only a few device drivers that we *know* definitely need it. So far there are only 2 device drivers that we've identified as needing it and as such only those drivers should implicate use of it. In the future, should the sysdata API get merged, the implications are that the further features of the firmware API will be added for sysdata users, but perhaps not for the old API as that entails silly collateral evolutions to the API or new exported symbols. I highly encourage use of the usermode helper to be reconsidered and simply abandoned. There are many reasons why it was a bad idea, for details refer to the thread [0]. [0] https://lkml.kernel.org/r/1466117661-22075-1-git-send-email-mcgrof@kernel.org Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c index a0f4a52..9521bc8 100644 --- a/drivers/net/wireless/ath/ath9k/init.c +++ b/drivers/net/wireless/ath/ath9k/init.c @@ -20,6 +20,8 @@ #include <linux/slab.h> #include <linux/ath9k_platform.h> #include <linux/module.h> +#include <linux/of.h> +#include <linux/of_net.h> #include <linux/relay.h> #include <net/ieee80211_radiotap.h> @@ -555,6 +557,68 @@ static int ath9k_init_platform(struct ath_softc *sc) return 0; } +static int ath9k_of_init(struct ath_softc *sc) +{ + struct device_node *np = sc->dev->of_node; + struct ath_hw *ah = sc->sc_ah; + struct ath_common *common = ath9k_hw_common(ah); + enum ath_bus_type bus_type = common->bus_ops->ath_bus_type; + const char *mac; + char eeprom_name[100]; + int led_pin, ret; + u32 gpio_data; + + if (!of_device_is_available(np)) + return 0; + + ath_dbg(common, CONFIG, "parsing configuration from OF node\n"); + + if (!of_property_read_u32(np, "qca,led-pin", &led_pin)) + ah->led_pin = led_pin; + + if (!of_property_read_u32(np, "qca,gpio-mask", &gpio_data)) + ah->gpio_mask = gpio_data; + + if (!of_property_read_u32(np, "qca,gpio-val", &gpio_data)) + ah->gpio_val = gpio_data; + + if (of_property_read_bool(np, "qca,clk-25mhz")) + ah->is_clk_25mhz = true; + + if (of_property_read_bool(np, "qca,led-active-high")) + ah->config.led_active_high = true; + + if (of_property_read_bool(np, "qca,disable-2ghz")) + ah->disable_2ghz = true; + + if (of_property_read_bool(np, "qca,disable-5ghz")) + ah->disable_5ghz = true; + + if (of_property_read_bool(np, "qca,check-eeprom-endianness")) + ah->ah_flags &= ~AH_NO_EEP_SWAP; + else + ah->ah_flags |= AH_NO_EEP_SWAP; + + if (of_property_read_bool(np, "qca,no-eeprom")) { + /* ath9k-eeprom-<bus>-<id>.bin */ + scnprintf(eeprom_name, sizeof(eeprom_name), + "ath9k-eeprom-%s-%s.bin", + ath_bus_type_to_string(bus_type), dev_name(ah->dev)); + + ret = ath9k_eeprom_request(sc, eeprom_name); + if (ret) + return ret; + } + + mac = of_get_mac_address(np); + if (mac) + ether_addr_copy(common->macaddr, mac); + + ah->ah_flags &= ~AH_USE_EEPROM; + + return 0; +} + static int ath9k_init_softc(u16 devid, struct ath_softc *sc, const struct ath_bus_ops *bus_ops) { @@ -611,6 +675,10 @@ static int ath9k_init_softc(u16 devid, struct ath_softc *sc, if (ret) return ret; + ret = ath9k_of_init(sc); + if (ret) + return ret; + if (ath9k_led_active_high != -1) ah->config.led_active_high = ath9k_led_active_high == 1;
This makes it possible to configure ath9k based devices using devicetree. That makes some out-of-tree "convert devicetree to ath9k_platform_data glue"-code obsolete. Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> --- changes in v2 -> v3: - replaced qca,eeprom-name with a boolean "qca,no-eeprom". The name of the eeprom firmware file is now generated based on the following pattern: ath9k-eeprom-<bus>-<id>.bin drivers/net/wireless/ath/ath9k/init.c | 68 +++++++++++++++++++++++++++++++++++ 1 file changed, 68 insertions(+)