Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 9612A607DE
From:   Kalle Valo <kvalo@codeaurora.org>
To:     Christian Lamparter <chunkeey@gmail.com>
Cc:     linux-wireless@vger.kernel.org,
        QCA ath9k Development <ath9k-devel@qca.qualcomm.com>,
        Julian Calaby <julian.calaby@gmail.com>
Subject: Re: [PATCH v3] ath9k: add loader for AR92XX (and older) pci(e)
References: <20190609203621.13015-1-chunkeey@gmail.com>
Date:   Thu, 27 Jun 2019 21:13:47 +0300
In-Reply-To: <20190609203621.13015-1-chunkeey@gmail.com> (Christian
        Lamparter's message of "Sun, 9 Jun 2019 22:36:21 +0200")
Message-ID: <87tvcasxpg.fsf@purkki.adurom.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

Christian Lamparter <chunkeey@gmail.com> 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 <julian.calaby@gmail.com>
> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>

[...]

> --- /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