| Message ID | 20160623174536.5967-2-martin.blumenstingl@googlemail.com (mailing list archive) |
|---|---|
| State | RFC |
| Delegated to: | Kalle Valo |
| Headers | show |
On Thu, Jun 23, 2016 at 07:45:35PM +0200, Martin Blumenstingl wrote: > Add documentation how devicetree can be used to configure ath9k based > devices. > > Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> > --- > changes in v1 -> v2: > - use vendor prefix "qca" instead of "ath" > - extend the example so it includes the "compatible" property > > .../devicetree/bindings/net/wireless/qca,ath9k.txt | 41 ++++++++++++++++++++++ > 1 file changed, 41 insertions(+) > create mode 100644 Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt > > diff --git a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt > new file mode 100644 > index 0000000..bb78f68 > --- /dev/null > +++ b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt > @@ -0,0 +1,41 @@ > +* Qualcomm Atheros ath9k wireless devices > + > +This node provides properties for configuring the ath9k wireless device. The > +node is expected to be specified as a child node of the PCI controller to > +which the wireless chip is connected. > + > +Required properties: > +- compatible: Should be "qca,ath9k" > + > +Optional properties: > +- reg: Address and length of the register set for the device. > +- qca,gpio-mask: The GPIO mask > +- qca,gpio-val: The GPIO value > +- qca,led-pin: The GPIO number to which the LED is connected > +- qca,led-active-high: The LED is active when the GPIO is HIGH > +- qca,clk-25mhz: Defines that at 25MHz clock is used I must assume these apply to internal GPIOs, LEDs and clocks, so I'm somewhat surprised any description is necessary. How variable are these in practice? > +- qca,eeprom-name: The name of the file which contains the EEPROM data (which > + will be loaded via request_firmware) The binding shouldn't know anything about the host filesystem, request_firmware, etc. So the description is a best a little off. What happens when a new FW comes out? I shouldn't have to update my DT to cater for that. Please find a better way to identify relevant FW. What exactly affects which FW can be used, or would ideally be used? Are different FWs required for the same HW in some contexts? Can we not figure out the relevant FW names in the driver based on some identification mechanism (e.g. a more thoroughly defined set of compatible strings)? > +- qca,check-eeprom-endianness: Allow checking the EEPROM endianness and > + swapping of the EEPROM data if required CAn we not simply always do this? > +- qca,disable-2ghz: Disables the 2.4GHz band, even if enabled in the EEPROM > +- qca,disable-5ghz: Disables the 5GHz band, even if enabled in the EEPROM When/why would these be necessary? Thanks, Mark. -- 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 Thu, Jun 23, 2016 at 7:58 PM, Mark Rutland <mark.rutland@arm.com> wrote: > On Thu, Jun 23, 2016 at 07:45:35PM +0200, Martin Blumenstingl wrote: >> Add documentation how devicetree can be used to configure ath9k based >> devices. >> >> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> >> --- >> changes in v1 -> v2: >> - use vendor prefix "qca" instead of "ath" >> - extend the example so it includes the "compatible" property >> >> .../devicetree/bindings/net/wireless/qca,ath9k.txt | 41 ++++++++++++++++++++++ >> 1 file changed, 41 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt >> >> diff --git a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt >> new file mode 100644 >> index 0000000..bb78f68 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt >> @@ -0,0 +1,41 @@ >> +* Qualcomm Atheros ath9k wireless devices >> + >> +This node provides properties for configuring the ath9k wireless device. The >> +node is expected to be specified as a child node of the PCI controller to >> +which the wireless chip is connected. >> + >> +Required properties: >> +- compatible: Should be "qca,ath9k" >> + >> +Optional properties: >> +- reg: Address and length of the register set for the device. >> +- qca,gpio-mask: The GPIO mask >> +- qca,gpio-val: The GPIO value >> +- qca,led-pin: The GPIO number to which the LED is connected >> +- qca,led-active-high: The LED is active when the GPIO is HIGH >> +- qca,clk-25mhz: Defines that at 25MHz clock is used > > I must assume these apply to internal GPIOs, LEDs and clocks, so I'm > somewhat surprised any description is necessary. > > How variable are these in practice? led-pin and led-active-high are definitely used on various OpenWrt devices. However, I am afraid that I have to pass this question to the ath9k developers for the other properties (gpio-mask, gpio-val and clk-25mhz). If you want we can skip gpio-mask, gpio-val and clk-25mhz for now, but keep led-pin and led-active-high. >> +- qca,eeprom-name: The name of the file which contains the EEPROM data (which >> + will be loaded via request_firmware) > > The binding shouldn't know anything about the host filesystem, > request_firmware, etc. So the description is a best a little off. > > What happens when a new FW comes out? I shouldn't have to update my DT > to cater for that. This is not exactly a "firmware" but rather device-specific calibration data (RF settings, MAC address, etc). Usually there is an eeprom connected directly to the wifi chip, but on embedded devices this is usually skipped and instead the calibration data is shipped somewhere on the main flash (directly on SPI-/NOR-/NAND flash, sometimes even inside an UBI volume). > Please find a better way to identify relevant FW. What exactly affects > which FW can be used, or would ideally be used? Are different FWs > required for the same HW in some contexts? > > Can we not figure out the relevant FW names in the driver based on some > identification mechanism (e.g. a more thoroughly defined set of > compatible strings)? The only way of auto-detecting a "correct" name would be via dev_name() (with some prefix this could give something like ath9k-pci-0000:00:0e.0.bin). >> +- qca,check-eeprom-endianness: Allow checking the EEPROM endianness and >> + swapping of the EEPROM data if required > > CAn we not simply always do this? I've asked myself this question as well, but unfortunately some manufacturers ship the EEPROM data with incorrect endianness magic. Thus I decided to stay consistent with ath9k_platform_data which also has a boolean (which defaults to false). >> +- qca,disable-2ghz: Disables the 2.4GHz band, even if enabled in the EEPROM >> +- qca,disable-5ghz: Disables the 5GHz band, even if enabled in the EEPROM > > When/why would these be necessary? sometimes a manufacturer (accidentally) leaves both bands enabled in the EEPROM data,while the RF hardware is only suitable for one of both bands. The same settings exist in ath9k_platform_data, serving exactly the same purpose 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 23-6-2016 19:45, Martin Blumenstingl wrote: > Add documentation how devicetree can be used to configure ath9k based > devices. > > Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> > --- > changes in v1 -> v2: > - use vendor prefix "qca" instead of "ath" > - extend the example so it includes the "compatible" property > > .../devicetree/bindings/net/wireless/qca,ath9k.txt | 41 ++++++++++++++++++++++ > 1 file changed, 41 insertions(+) > create mode 100644 Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt > > diff --git a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt > new file mode 100644 > index 0000000..bb78f68 > --- /dev/null > +++ b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt > @@ -0,0 +1,41 @@ > +* Qualcomm Atheros ath9k wireless devices > + > +This node provides properties for configuring the ath9k wireless device. The > +node is expected to be specified as a child node of the PCI controller to > +which the wireless chip is connected. > + > +Required properties: > +- compatible: Should be "qca,ath9k" > + > +Optional properties: > +- reg: Address and length of the register set for the device. Is 'reg' property handled. I don't see it in patch 2/2. > +- qca,gpio-mask: The GPIO mask > +- qca,gpio-val: The GPIO value > +- qca,led-pin: The GPIO number to which the LED is connected > +- qca,led-active-high: The LED is active when the GPIO is HIGH > +- qca,clk-25mhz: Defines that at 25MHz clock is used For the above I can somehow see them as variables for different hardware platforms. > +- qca,eeprom-name: The name of the file which contains the EEPROM data (which > + will be loaded via request_firmware) > +- qca,check-eeprom-endianness: Allow checking the EEPROM endianness and > + swapping of the EEPROM data if required > +- qca,disable-2ghz: Disables the 2.4GHz band, even if enabled in the EEPROM > +- qca,disable-5ghz: Disables the 5GHz band, even if enabled in the EEPROM These not really. Storing filename information in device tree seems wrong as it does not describe hardware configuration. The other three also seem more like driver module parameters. I think what you are trying here with the last two properties is to use the same eeprom file for different types of hardware, ie. for dual-band, 2g-only, and 5g-only devices. From device tree perspective I would use those types, eg.: qca,2g-capable: Device can operate in 2.4GHz band. qca,5g-capable: Device can operate in 5GHz band. The other patch also looks for a MAC address for the device. I suppose that should be documented as well. > +In this example, the node is defined as child node of the PCI controller. > + > +pci { > + pcie@0 { > + reg = <0 0 0 0 0>; > + #interrupt-cells = <1>; > + #size-cells = <2>; > + #address-cells = <3>; > + device_type = "pci"; > + > + ath9k@0,0 { > + compatible = "qca,ath9k"; > + reg = <0 0 0 0 0>; > + device_type = "pci"; Is this just a copy-paste or should device_type be specified? Regards, Arend -- 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 Thu, Jun 23, 2016 at 9:25 PM, Arend Van Spriel <arend.vanspriel@broadcom.com> wrote: >> +Optional properties: >> +- reg: Address and length of the register set for the device. > > Is 'reg' property handled. I don't see it in patch 2/2. for AHB we would probably have to handle it separately, but AHB support is not scope of my patch. For PCI(e) this is parsed automatically by of_pci_find_child_device when the PCI controller is found and the child nodes are enumerated. See [0] >> +- qca,eeprom-name: The name of the file which contains the EEPROM data (which >> + will be loaded via request_firmware) >> +- qca,check-eeprom-endianness: Allow checking the EEPROM endianness and >> + swapping of the EEPROM data if required >> +- qca,disable-2ghz: Disables the 2.4GHz band, even if enabled in the EEPROM >> +- qca,disable-5ghz: Disables the 5GHz band, even if enabled in the EEPROM > > These not really. Storing filename information in device tree seems > wrong as it does not describe hardware configuration. The other three > also seem more like driver module parameters. I think what you are > trying here with the last two properties is to use the same eeprom file > for different types of hardware, ie. for dual-band, 2g-only, and 5g-only > devices. From device tree perspective I would use those types, eg.: > > qca,2g-capable: Device can operate in 2.4GHz band. > qca,5g-capable: Device can operate in 5GHz band. please let me explain this a bit more detailed (and clean up the confusion which I may have created): ath9k itself does not need a firmware to run. But it needs to know some details of the actual RF hardware (let's call it calibration/EEPROM data) to which the ath9k chip is wired (which frequencies/bands are enabled, how many RX/TX antennas are there, max TX power, if there's a LNA, and so on). This calibration/EEPROM data is unique for each "ath9k + RF hardware" combination and usually stored inside an EEPROM connected directly to the ath9k chip. However, many embedded devices do not have a physical EEPROM connected to ath9k. For these devices we have to obtain the calibration/EEPROM data from "somewhere" (which is usually stored somewhere on SPI/NOR/NAND flash, but can sometimes even be stored inside an UBI volume). "qca,eeprom-name" tries to solve the problem that ath9k needs calibration/EEPROM data even if there is no physical EEPROM attached to the wifi chip. One important thing here is that we need to be able to load two different calibration/EEPROM data files in case one system uses two ath9k chips (there might for example be a dedicated 2.4G and dedicated 5G chip). If this should not be part of devicetree then we could do it like ath10k does and generate the filename for request_firmware based on the dev_name() - see [1]. I would then replace "qca,eeprom-name" with a boolean "qca,use-external-eeprom" to signal ath9k that this chip does not have a (physical) EEPROM attached (ath9k would then start the request_firmware mechanism). qca,check-eeprom-endianness is unfortunately required because some vendors use the little endian magic while the data is actually big endian. Endianness swapping needs to be done inside ath9k because it's a quite complex operation (due to the fact that there are some 16bit and 32bit fields which have to be swapped differently). So one would set qca,check-eeprom-endianness if the device vendor chose the wrong endianness magic, while the data inside the calibration/EEPROM data is correct. Enabling it unconditionally would result in the calibration/EEPROM data being endianness-swapped. qca,disable-2ghz/qca,disable-5ghz exist due to a similar issue as we find with the eeprom endianness magic: Normally the information which bands are enabled for this specific "ath9k + RF hardware" combination is stored inside the calibration/EEPROM data. Unfortunately some vendors left for example the 5GHz band enabled in the calibration/EEPROM data while the RF hardware only supports 2.4GHz. Using the 5GHz band on such devices will lead to issues, so it should be possible to disable those "incorrectly allowed" frequencies/bands. > The other patch also looks for a MAC address for the device. I suppose > that should be documented as well. good catch, thanks! >> +In this example, the node is defined as child node of the PCI controller. >> + >> +pci { >> + pcie@0 { >> + reg = <0 0 0 0 0>; >> + #interrupt-cells = <1>; >> + #size-cells = <2>; >> + #address-cells = <3>; >> + device_type = "pci"; >> + >> + ath9k@0,0 { >> + compatible = "qca,ath9k"; >> + reg = <0 0 0 0 0>; >> + device_type = "pci"; > > Is this just a copy-paste or should device_type be specified? indeed, as far as I understand it should only be defined on the bridge - thus it should be removed from the ath9k node. again, thanks for noting this! Regards, Martin [0] http://lxr.free-electrons.com/source/drivers/of/of_pci.c?v=4.6#L21 [1] http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath10k/core.c#L729 -- 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 Thu, Jun 23, 2016 at 08:14:29PM +0200, Martin Blumenstingl wrote: > On Thu, Jun 23, 2016 at 7:58 PM, Mark Rutland <mark.rutland@arm.com> wrote: > > On Thu, Jun 23, 2016 at 07:45:35PM +0200, Martin Blumenstingl wrote: > >> +- qca,eeprom-name: The name of the file which contains the EEPROM data (which > >> + will be loaded via request_firmware) > > > > The binding shouldn't know anything about the host filesystem, > > request_firmware, etc. So the description is a best a little off. > > > > What happens when a new FW comes out? I shouldn't have to update my DT > > to cater for that. > This is not exactly a "firmware" but rather device-specific > calibration data (RF settings, MAC address, etc). Usually there is an > eeprom connected directly to the wifi chip, but on embedded devices > this is usually skipped and instead the calibration data is shipped > somewhere on the main flash (directly on SPI-/NOR-/NAND flash, > sometimes even inside an UBI volume). Ok. I believe that previously, for ath10k, it was suggested that this calibration data be placed directly in the DT (assuming it's small enough). > > Please find a better way to identify relevant FW. What exactly affects > > which FW can be used, or would ideally be used? Are different FWs > > required for the same HW in some contexts? > > > > Can we not figure out the relevant FW names in the driver based on some > > identification mechanism (e.g. a more thoroughly defined set of > > compatible strings)? > The only way of auto-detecting a "correct" name would be via > dev_name() (with some prefix this could give something like > ath9k-pci-0000:00:0e.0.bin). That may work, if the above is not an option. > > >> +- qca,check-eeprom-endianness: Allow checking the EEPROM endianness and > >> + swapping of the EEPROM data if required > > > > CAn we not simply always do this? > I've asked myself this question as well, but unfortunately some > manufacturers ship the EEPROM data with incorrect endianness magic. > Thus I decided to stay consistent with ath9k_platform_data which also > has a boolean (which defaults to false). Ah. It's probably worth a note in the binding that this is not always safe, and should only be set if the eeprom is known to have valid endianness magic. It would also be worth specifying teh behaviour in the absence of this property. > > >> +- qca,disable-2ghz: Disables the 2.4GHz band, even if enabled in the EEPROM > >> +- qca,disable-5ghz: Disables the 5GHz band, even if enabled in the EEPROM > > > > When/why would these be necessary? > sometimes a manufacturer (accidentally) leaves both bands enabled in > the EEPROM data,while the RF hardware is only suitable for one of both > bands. The same settings exist in ath9k_platform_data, serving exactly > the same purpose Ok. Can we invert these instead (i.e. describe when the feature is available)? e.g. qca,supports-2ghz. Thanks, Mark. -- 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 2016-06-27 14:57, Mark Rutland wrote: > On Thu, Jun 23, 2016 at 08:14:29PM +0200, Martin Blumenstingl wrote: >> On Thu, Jun 23, 2016 at 7:58 PM, Mark Rutland <mark.rutland@arm.com> wrote: >> > On Thu, Jun 23, 2016 at 07:45:35PM +0200, Martin Blumenstingl wrote: >> >> +- qca,eeprom-name: The name of the file which contains the EEPROM data (which >> >> + will be loaded via request_firmware) >> > >> > The binding shouldn't know anything about the host filesystem, >> > request_firmware, etc. So the description is a best a little off. >> > >> > What happens when a new FW comes out? I shouldn't have to update my DT >> > to cater for that. >> This is not exactly a "firmware" but rather device-specific >> calibration data (RF settings, MAC address, etc). Usually there is an >> eeprom connected directly to the wifi chip, but on embedded devices >> this is usually skipped and instead the calibration data is shipped >> somewhere on the main flash (directly on SPI-/NOR-/NAND flash, >> sometimes even inside an UBI volume). > > Ok. I believe that previously, for ath10k, it was suggested that this > calibration data be placed directly in the DT (assuming it's small > enough). I don't think the data should go directly into DT, because then we need a lot more complex kernel loader stubs. There are hundreds of devices out there with calibration data in flash, and many of them have the data in different places, and almost all of them don't support passing DT via boot loader. The actual RF settings are calibrated for every individual device, so they need to be read from the flash partition anyway. I think it makes sense to add an optional reference to a mtd partition and allow the kernel to read from it directly. >> > Please find a better way to identify relevant FW. What exactly affects >> > which FW can be used, or would ideally be used? Are different FWs >> > required for the same HW in some contexts? >> > >> > Can we not figure out the relevant FW names in the driver based on some >> > identification mechanism (e.g. a more thoroughly defined set of >> > compatible strings)? >> The only way of auto-detecting a "correct" name would be via >> dev_name() (with some prefix this could give something like >> ath9k-pci-0000:00:0e.0.bin). > > That may work, if the above is not an option. I think that's a good idea. - Felix -- 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 2:57 PM, Mark Rutland <mark.rutland@arm.com> wrote: >> > Please find a better way to identify relevant FW. What exactly affects >> > which FW can be used, or would ideally be used? Are different FWs >> > required for the same HW in some contexts? >> > >> > Can we not figure out the relevant FW names in the driver based on some >> > identification mechanism (e.g. a more thoroughly defined set of >> > compatible strings)? >> The only way of auto-detecting a "correct" name would be via >> dev_name() (with some prefix this could give something like >> ath9k-pci-0000:00:0e.0.bin). > > That may work, if the above is not an option. I would also prefer this (Felix' email already contains an explanation why this way is preferred and I fully agree with him). >> >> +- qca,check-eeprom-endianness: Allow checking the EEPROM endianness and >> >> + swapping of the EEPROM data if required >> > >> > CAn we not simply always do this? >> I've asked myself this question as well, but unfortunately some >> manufacturers ship the EEPROM data with incorrect endianness magic. >> Thus I decided to stay consistent with ath9k_platform_data which also >> has a boolean (which defaults to false). > > Ah. It's probably worth a note in the binding that this is not always > safe, and should only be set if the eeprom is known to have valid > endianness magic. > > It would also be worth specifying teh behaviour in the absence of this > property. noted, I will fix this in the next round >> >> >> +- qca,disable-2ghz: Disables the 2.4GHz band, even if enabled in the EEPROM >> >> +- qca,disable-5ghz: Disables the 5GHz band, even if enabled in the EEPROM >> > >> > When/why would these be necessary? >> sometimes a manufacturer (accidentally) leaves both bands enabled in >> the EEPROM data,while the RF hardware is only suitable for one of both >> bands. The same settings exist in ath9k_platform_data, serving exactly >> the same purpose > > Ok. Can we invert these instead (i.e. describe when the feature is > available)? e.g. qca,supports-2ghz. we could invert these, but I think the "disable" logic was chosen with a good reason: the ath9k calibration data already contains the information which bands are enabled/disabled. Enabling a band via devicetree / platform data is not possible, because that would mean we would have to pass additional calibration data for this band. The only use-case where these disable-Xghz properties are used is when the device vendor forgot to disable one of the bands. I can improve the documentation for this one, but I would prefer to stay with the disable naming/logic 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
diff --git a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt new file mode 100644 index 0000000..bb78f68 --- /dev/null +++ b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt @@ -0,0 +1,41 @@ +* Qualcomm Atheros ath9k wireless devices + +This node provides properties for configuring the ath9k wireless device. The +node is expected to be specified as a child node of the PCI controller to +which the wireless chip is connected. + +Required properties: +- compatible: Should be "qca,ath9k" + +Optional properties: +- reg: Address and length of the register set for the device. +- qca,gpio-mask: The GPIO mask +- qca,gpio-val: The GPIO value +- qca,led-pin: The GPIO number to which the LED is connected +- qca,led-active-high: The LED is active when the GPIO is HIGH +- qca,clk-25mhz: Defines that at 25MHz clock is used +- qca,eeprom-name: The name of the file which contains the EEPROM data (which + will be loaded via request_firmware) +- qca,check-eeprom-endianness: Allow checking the EEPROM endianness and + swapping of the EEPROM data if required +- qca,disable-2ghz: Disables the 2.4GHz band, even if enabled in the EEPROM +- qca,disable-5ghz: Disables the 5GHz band, even if enabled in the EEPROM + +In this example, the node is defined as child node of the PCI controller. + +pci { + pcie@0 { + reg = <0 0 0 0 0>; + #interrupt-cells = <1>; + #size-cells = <2>; + #address-cells = <3>; + device_type = "pci"; + + ath9k@0,0 { + compatible = "qca,ath9k"; + reg = <0 0 0 0 0>; + device_type = "pci"; + qca,disable-5ghz; + }; + }; +};
Add documentation how devicetree can be used to configure ath9k based devices. Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> --- changes in v1 -> v2: - use vendor prefix "qca" instead of "ath" - extend the example so it includes the "compatible" property .../devicetree/bindings/net/wireless/qca,ath9k.txt | 41 ++++++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt