2019-06-09 20:37:29

by Christian Lamparter

[permalink] [raw]
Subject: [PATCH v3] ath9k: add loader for AR92XX (and older) pci(e)

Atheros cards with a AR92XX generation (and older) chip usually
store their pci(e) initialization vectors on an external eeprom chip.
However these chips technically don't need the eeprom chip attached,
the AR9280 Datasheet in section "6.1.2 DEVICE_ID" describes that
"... if the EEPROM content is not valid, a value of 0xFF1C returns
when read from the register". So, they will show up on the system's
pci bus. However in that state, ath9k can't load, since it relies
on having the correct pci-id, otherwise it doesn't know what chip it
actually is. This happens on many embedded devices like routers
and accesspoint since they want to keep the BOM low and store the
pci(e) initialization vectors together with the calibration data
on the system's FLASH, which is out of reach of the ath9k chip.

Furthermore, Some devices (like the Cisco Meraki Z1 Cloud Managed
Teleworker Gateway) need to be able to initialize the PCIe wifi device.
Normally, this should be done as a pci quirk during the early stages of
booting linux. However, this isn't possible for devices which have the
init code for the Atheros chip stored on NAND in an UBI volume.
Hence, this module can be used to initialize the chip when the
user-space is ready to extract the init code.

Martin Blumenstingl prodived the following fixes:
owl-loader: add support for OWL emulation PCI devices
owl-loader: don't re-scan the bus when ath9k_pci_fixup failed
owl-loader: use dev_* instead of pr_* logging functions
owl-loader: auto-generate the eeprom filename as fallback
owl-loader: add a debug message when swapping the eeprom data
owl-loader: add missing newlines in log messages

Reviewed-by: Julian Calaby <[email protected]>
Signed-off-by: Christian Lamparter <[email protected]>
Signed-off-by: Martin Blumenstingl <[email protected]>

---
v3: changed module description

v2: address Julian Calaby's comments:
- make it a separate driver again (much like OpenWrt)
- remove ar71xx leftovers (pdata)
---
drivers/net/wireless/ath/ath9k/Kconfig | 16 ++
drivers/net/wireless/ath/ath9k/Makefile | 2 +
.../wireless/ath/ath9k/ath9k_pci_owl_loader.c | 215 ++++++++++++++++++
3 files changed, 233 insertions(+)
create mode 100644 drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c

diff --git a/drivers/net/wireless/ath/ath9k/Kconfig b/drivers/net/wireless/ath/ath9k/Kconfig
index a1ef8769983a..d6a87698a44a 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -157,6 +157,22 @@ config ATH9K_PCOEM
depends on ATH9K
default y

+config ATH9K_PCI_NO_EEPROM
+ tristate "Atheros ath9k pci loader for EEPROM-less chips"
+ depends on ATH9K_PCI
+ default n
+ help
+ This separate driver provides a loader in order to support the
+ AR500X to AR92XX-generation of ath9k PCI(e) WiFi chips, which have
+ their initialization data (which contains the real PCI Device ID
+ that ath9k will need) stored together with the calibration data out
+ of reach for the ath9k chip.
+
+ These devices are usually various network appliances, routers or
+ access Points and such.
+
+ If unsure say N.
+
config ATH9K_HTC
tristate "Atheros HTC based wireless cards support"
depends on USB && MAC80211
diff --git a/drivers/net/wireless/ath/ath9k/Makefile b/drivers/net/wireless/ath/ath9k/Makefile
index f71b2ad8275c..abd0f61370d9 100644
--- a/drivers/net/wireless/ath/ath9k/Makefile
+++ b/drivers/net/wireless/ath/ath9k/Makefile
@@ -77,3 +77,5 @@ ath9k_htc-y += htc_hst.o \
ath9k_htc-$(CONFIG_ATH9K_HTC_DEBUGFS) += htc_drv_debug.o

obj-$(CONFIG_ATH9K_HTC) += ath9k_htc.o
+
+obj-$(CONFIG_ATH9K_PCI_NO_EEPROM) += ath9k_pci_owl_loader.o
diff --git a/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c b/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
new file mode 100644
index 000000000000..717dee7b6c4c
--- /dev/null
+++ b/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
@@ -0,0 +1,215 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Initialize Owl Emulation Devices
+ *
+ * Copyright (C) 2016 Christian Lamparter <[email protected]>
+ * Copyright (C) 2016 Martin Blumenstingl <[email protected]>
+ *
+ * Some devices (like the Cisco Meraki Z1 Cloud Managed Teleworker Gateway)
+ * need to be able to initialize the PCIe wifi device. Normally, this is done
+ * during the early stages as a pci quirk.
+ * However, this isn't possible for devices which have the init code for the
+ * Atheros chip stored on UBI Volume on NAND. Hence, this module can be used to
+ * initialize the chip when the user-space is ready to extract the init code.
+ */
+#include <linux/module.h>
+#include <linux/version.h>
+#include <linux/completion.h>
+#include <linux/etherdevice.h>
+#include <linux/firmware.h>
+#include <linux/pci.h>
+#include <linux/delay.h>
+#include <linux/platform_device.h>
+#include <linux/ath9k_platform.h>
+
+struct owl_ctx {
+ struct completion eeprom_load;
+};
+
+#define EEPROM_FILENAME_LEN 100
+
+#define AR5416_EEPROM_MAGIC 0xa55a
+
+static int ath9k_pci_fixup(struct pci_dev *pdev, const u16 *cal_data,
+ size_t cal_len)
+{
+ void __iomem *mem;
+ const void *cal_end = (void *)cal_data + cal_len;
+ const struct {
+ u16 reg;
+ u16 low_val;
+ u16 high_val;
+ } __packed * data;
+ u16 cmd;
+ u32 bar0;
+ bool swap_needed = false;
+
+ if (*cal_data != AR5416_EEPROM_MAGIC) {
+ if (*cal_data != swab16(AR5416_EEPROM_MAGIC)) {
+ dev_err(&pdev->dev, "invalid calibration data\n");
+ return -EINVAL;
+ }
+
+ dev_dbg(&pdev->dev, "calibration data needs swapping\n");
+ swap_needed = true;
+ }
+
+ dev_info(&pdev->dev, "fixup device configuration\n");
+
+ mem = pcim_iomap(pdev, 0, 0);
+ if (!mem) {
+ dev_err(&pdev->dev, "ioremap error\n");
+ return -EINVAL;
+ }
+
+ pci_read_config_dword(pdev, PCI_BASE_ADDRESS_0, &bar0);
+ pci_write_config_dword(pdev, PCI_BASE_ADDRESS_0,
+ pci_resource_start(pdev, 0));
+ pci_read_config_word(pdev, PCI_COMMAND, &cmd);
+ cmd |= PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY;
+ pci_write_config_word(pdev, PCI_COMMAND, cmd);
+
+ /* set pointer to first reg address */
+ for (data = (const void *)(cal_data + 3);
+ (const void *)data <= cal_end && data->reg != (u16)~0;
+ data++) {
+ u32 val;
+ u16 reg;
+
+ reg = data->reg;
+ val = data->low_val;
+ val |= ((u32)data->high_val) << 16;
+
+ if (swap_needed) {
+ reg = swab16(reg);
+ val = swahb32(val);
+ }
+
+ __raw_writel(val, mem + reg);
+ usleep_range(100, 120);
+ }
+
+ pci_read_config_word(pdev, PCI_COMMAND, &cmd);
+ cmd &= ~(PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY);
+ pci_write_config_word(pdev, PCI_COMMAND, cmd);
+
+ pci_write_config_dword(pdev, PCI_BASE_ADDRESS_0, bar0);
+ pcim_iounmap(pdev, mem);
+
+ pci_disable_device(pdev);
+
+ return 0;
+}
+
+static void owl_fw_cb(const struct firmware *fw, void *context)
+{
+ struct pci_dev *pdev = (struct pci_dev *)context;
+ struct owl_ctx *ctx = (struct owl_ctx *)pci_get_drvdata(pdev);
+ struct pci_bus *bus;
+
+ complete(&ctx->eeprom_load);
+
+ if (!fw) {
+ dev_err(&pdev->dev, "no eeprom data received.\n");
+ goto release;
+ }
+
+ /* also note that we are doing *u16 operations on the file */
+ if (fw->size > 4096 || fw->size < 0x200 || (fw->size & 1) == 1) {
+ dev_err(&pdev->dev, "eeprom file has an invalid size.\n");
+ goto release;
+ }
+
+ if (ath9k_pci_fixup(pdev, (const u16 *)fw->data, fw->size))
+ goto release;
+
+ pci_lock_rescan_remove();
+ bus = pdev->bus;
+ pci_stop_and_remove_bus_device(pdev);
+ /* the device should come back with the proper
+ * ProductId. But we have to initiate a rescan.
+ */
+ pci_rescan_bus(bus);
+ pci_unlock_rescan_remove();
+
+release:
+ release_firmware(fw);
+}
+
+static const char *owl_get_eeprom_name(struct pci_dev *pdev)
+{
+ struct device *dev = &pdev->dev;
+ char *eeprom_name;
+
+ dev_dbg(dev, "using auto-generated eeprom filename\n");
+
+ eeprom_name = devm_kzalloc(dev, EEPROM_FILENAME_LEN, GFP_KERNEL);
+ if (!eeprom_name)
+ return NULL;
+
+ /* this should match the pattern used in ath9k/init.c */
+ scnprintf(eeprom_name, EEPROM_FILENAME_LEN, "ath9k-eeprom-pci-%s.bin",
+ dev_name(dev));
+
+ return eeprom_name;
+}
+
+static int owl_probe(struct pci_dev *pdev,
+ const struct pci_device_id *id)
+{
+ struct owl_ctx *ctx;
+ const char *eeprom_name;
+ int err = 0;
+
+ if (pcim_enable_device(pdev))
+ return -EIO;
+
+ pcim_pin_device(pdev);
+
+ eeprom_name = owl_get_eeprom_name(pdev);
+ if (!eeprom_name) {
+ dev_err(&pdev->dev, "no eeprom filename found.\n");
+ return -ENODEV;
+ }
+
+ ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
+ if (!ctx)
+ return -ENOMEM;
+
+ init_completion(&ctx->eeprom_load);
+
+ pci_set_drvdata(pdev, ctx);
+ err = request_firmware_nowait(THIS_MODULE, true, eeprom_name,
+ &pdev->dev, GFP_KERNEL, pdev, owl_fw_cb);
+ if (err)
+ dev_err(&pdev->dev, "failed to request caldata (%d).\n", err);
+
+ return err;
+}
+
+static void owl_remove(struct pci_dev *pdev)
+{
+ struct owl_ctx *ctx = pci_get_drvdata(pdev);
+
+ if (ctx) {
+ wait_for_completion(&ctx->eeprom_load);
+ pci_set_drvdata(pdev, NULL);
+ }
+}
+
+static const struct pci_device_id owl_pci_table[] = {
+ { PCI_VDEVICE(ATHEROS, 0xff1c) }, /* PCIe */
+ { PCI_VDEVICE(ATHEROS, 0xff1d) }, /* PCI */
+ { },
+};
+MODULE_DEVICE_TABLE(pci, owl_pci_table);
+
+static struct pci_driver owl_driver = {
+ .name = KBUILD_MODNAME,
+ .id_table = owl_pci_table,
+ .probe = owl_probe,
+ .remove = owl_remove,
+};
+module_pci_driver(owl_driver);
+MODULE_AUTHOR("Christian Lamparter <[email protected]>");
+MODULE_DESCRIPTION("External EEPROM data loader for Atheros AR500X to AR92XX");
+MODULE_LICENSE("GPL v2");
--
2.20.1


2019-06-27 18:16:18

by Kalle Valo

[permalink] [raw]
Subject: Re: [PATCH v3] ath9k: add loader for AR92XX (and older) pci(e)

Christian Lamparter <[email protected]> writes:

> Atheros cards with a AR92XX generation (and older) chip usually
> store their pci(e) initialization vectors on an external eeprom chip.
> However these chips technically don't need the eeprom chip attached,
> the AR9280 Datasheet in section "6.1.2 DEVICE_ID" describes that
> "... if the EEPROM content is not valid, a value of 0xFF1C returns
> when read from the register". So, they will show up on the system's
> pci bus. However in that state, ath9k can't load, since it relies
> on having the correct pci-id, otherwise it doesn't know what chip it
> actually is. This happens on many embedded devices like routers
> and accesspoint since they want to keep the BOM low and store the
> pci(e) initialization vectors together with the calibration data
> on the system's FLASH, which is out of reach of the ath9k chip.
>
> Furthermore, Some devices (like the Cisco Meraki Z1 Cloud Managed
> Teleworker Gateway) need to be able to initialize the PCIe wifi device.
> Normally, this should be done as a pci quirk during the early stages of
> booting linux. However, this isn't possible for devices which have the
> init code for the Atheros chip stored on NAND in an UBI volume.
> Hence, this module can be used to initialize the chip when the
> user-space is ready to extract the init code.
>
> Martin Blumenstingl prodived the following fixes:
> owl-loader: add support for OWL emulation PCI devices
> owl-loader: don't re-scan the bus when ath9k_pci_fixup failed
> owl-loader: use dev_* instead of pr_* logging functions
> owl-loader: auto-generate the eeprom filename as fallback
> owl-loader: add a debug message when swapping the eeprom data
> owl-loader: add missing newlines in log messages
>
> Reviewed-by: Julian Calaby <[email protected]>
> Signed-off-by: Christian Lamparter <[email protected]>
> Signed-off-by: Martin Blumenstingl <[email protected]>

[...]

> --- /dev/null
> +++ b/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
> @@ -0,0 +1,215 @@
> +// SPDX-License-Identifier: GPL-2.0

[...]

> +MODULE_LICENSE("GPL v2");

ath9k has ISC license, is there a specific reason why you chose GPLv2
here instead of ISC? I don't like mixing licenses within a driver,
that's why I'm asking.

--
Kalle Valo

2019-06-29 08:44:53

by Christian Lamparter

[permalink] [raw]
Subject: Re: [PATCH v3] ath9k: add loader for AR92XX (and older) pci(e)

Hello,

(Sorry for the delay. I only have time for dealing with this
on the weekends. Thanks!)

On Thursday, June 27, 2019 8:13:47 PM CEST Kalle Valo wrote:
> Christian Lamparter <[email protected]> writes:
> > Atheros cards with a AR92XX generation (and older) chip usually
> > store their pci(e) initialization vectors on an external eeprom chip.
> > However these chips technically don't need the eeprom chip attached,
> > the AR9280 Datasheet in section "6.1.2 DEVICE_ID" describes that
> > "... if the EEPROM content is not valid, a value of 0xFF1C returns
> > when read from the register". So, they will show up on the system's
> > pci bus. However in that state, ath9k can't load, since it relies
> > on having the correct pci-id, otherwise it doesn't know what chip it
> > actually is. This happens on many embedded devices like routers
> > and accesspoint since they want to keep the BOM low and store the
> > pci(e) initialization vectors together with the calibration data
> > on the system's FLASH, which is out of reach of the ath9k chip.
> >
> > Furthermore, Some devices (like the Cisco Meraki Z1 Cloud Managed
> > Teleworker Gateway) need to be able to initialize the PCIe wifi device.
> > Normally, this should be done as a pci quirk during the early stages of
> > booting linux. However, this isn't possible for devices which have the
> > init code for the Atheros chip stored on NAND in an UBI volume.
> > Hence, this module can be used to initialize the chip when the
> > user-space is ready to extract the init code.
> >
> > Martin Blumenstingl prodived the following fixes:
> > owl-loader: add support for OWL emulation PCI devices
> > owl-loader: don't re-scan the bus when ath9k_pci_fixup failed
> > owl-loader: use dev_* instead of pr_* logging functions
> > owl-loader: auto-generate the eeprom filename as fallback
> > owl-loader: add a debug message when swapping the eeprom data
> > owl-loader: add missing newlines in log messages
> >
> > Reviewed-by: Julian Calaby <[email protected]>
> > Signed-off-by: Christian Lamparter <[email protected]>
> > Signed-off-by: Martin Blumenstingl <[email protected]>
>
> [...]
>
> > --- /dev/null
> > +++ b/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
> > @@ -0,0 +1,215 @@
> > +// SPDX-License-Identifier: GPL-2.0
>
> [...]
>
> > +MODULE_LICENSE("GPL v2");
>
> ath9k has ISC license, is there a specific reason why you chose GPLv2
> here instead of ISC? I don't like mixing licenses within a driver,
> that's why I'm asking.

About that: The commit message hints The owl-loader was written because
Chris Blake needed it for the Cisco Meraki Z1 (Atheros based SoC) because
the existing methods in the OpenWrt project were designed to work with
straight-from-SPI-NOR. OpenWrt already had multiple different versions for
each platform (ar71xx = Atheros SoCs, lantiq, brcm63xx) of the
pci-ath9k-fixup.c which are all licensed under GPLv2 and they predated
owl-loader initiative by about 8 years.

https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ar71xx/files/arch/mips/ath79/pci-ath9k-fixup.c
(lantiq's version has been since replaced by the owl-loader)
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/brcm63xx/patches-4.14/416-BCM63XX-add-a-fixup-for-ath9k-devices.patch

(ar71xx has been deprecated and will be dropped in favor of the upstream
DeviceTree ath79 which relies on the owl-loader exclusivly)

So this is were the license comes from: Existing code looks similar.
And while the owl-loader was written from scratch as it needed:
- to get the via firmware_request to make it as universal as possible
- be able to support all platforms (no fixed pci(e) addresses)
- separate driver as a module (and not a pci fixup)
I went for the safer "GPLv2" as it is the standard OpenWrt License:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=LICENSE

That said: I have no problem relicensing my code under the ISC, if it
helps with the upstreaming process. I've added Chris, Martin and
Mathias as they both were consultants, as well as the previous
authors of three targets to "let them know".

Best Regards,
Christian

(Yeah, I think this might take a while longer. So please don't delete
it just yet.)


2019-07-01 12:33:58

by Martin Blumenstingl

[permalink] [raw]
Subject: Re: [PATCH v3] ath9k: add loader for AR92XX (and older) pci(e)

On Sat, Jun 29, 2019 at 10:44 AM Christian Lamparter <[email protected]> wrote:
[...]
> That said: I have no problem relicensing my code under the ISC, if it
> helps with the upstreaming process. I've added Chris, Martin and
> Mathias as they both were consultants, as well as the previous
> authors of three targets to "let them know".
I am also fine with re-licensing my part of the code (to make it
explicit: of the ath9k PCI OWL loader) under the ISC (which is
expressed as MODULE_LICENSE("Dual BSD/GPL") in the ath9k driver code)


Martin