[OpenWrt-Devel] [RFC 2/3] kernel: owl-loader for delayed Atheros ath9k fixup

[Christian Lamparter]

On Wednesday, March 09, 2016 07:59:28 AM Martin Blumenstingl wrote:
> On Wed, Mar 9, 2016 at 12:14 AM, Christian Lamparter
> <chunkeey at googlemail.com> wrote:
> > 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 of booting linux, because the necessary init code
> > is read from the memory mapped SPI and passed to pci_enable_ath9k_fixup.
> > However,this isn't possible for devices which have the init code for the
> > Atheros chip stored on NAND. Hence, this module can be used to initialze
> > the chip when the user-space is ready to extract the init code.
> I assume that you are speaking of UBI when you said "NAND".
> This case is tricky indeed, because the UBI initialization starts as
> late_initcall. Additionally there is some event-handling inside
> UBI/ubifs which makes it hard to read from an ubi volume from another
> kernel driver.
Yes, handling UBI is the tricky part. We depend on user-space's 
10-ath9k-eeprom script to extract the caldata partition. But this
is what all other ar71xx generic (c-55) and NAND devices do as well.

> Mathias and I have already experimented with reading calibration data
> from an UBI volume (we started with MAC addresses, but it will be the
> same for the ath9k caldata).
> It sounds easy at first sight, but it turns out to be tricky.
>
> I would like to find a generic solution for this (which does not
> depend on the ar71xx target) because we probably need the same code
> for the lantiq target as well.
Except for the call to "pci_enable_ath9k_fixup" [0] (which supplies
the caldata to the ath9k pci fixup routine). The owl-loader should be
platform-independent. it registers a pci driver for the dodgy pci-ids
and does little else than downloading the caldata and remove the old
device and force a pci rescan.

I've looked into lantiq (and BCM63XX) target a bit.

BCM63XX has already a function called pci_enable_ath9k_fixup, but uses
a slightly different signature. Instead of a pointer to the caldata is
supplies an offset.... And BCM63XX also uses it for fixing rt2x00 device
as well.

lantiq on the other hand has copied the func from ar71xx and adapted 
and renamed it, but kept the signature:
ltq_pci_ath_fixup(unsigned slot, u16 *cal_data)
it's in arch/mips/lantiq/xway/pci-ath-fixup.c.


So far, these are all for MIPS, or does anyone know of a different 
architecture or device that need a pci_fixup? I'm not sure how to
handle the rt2x00 though. Because otherwise we could just have
something like register_pci_fixup(slot, cal_data) for now.

Regards,
Christian

[0] <https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/files/arch/mips/ath79/pci-ath9k-fixup.c>
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel