are written out.
This allows EEPROM-less NICs on the AR7241 PCIe bus to be correctly
initialised.
Tested:
* AP91 (AR7240+AR9285) - the existing board support didn't break;
* AP99 (AR7241+AR9287) - this fixed the configuration of the AR9287 PCI.
ar724x_pci.c.
* Move out the code which populates the firmware into ar71xx_fixup.c
* Shuffle around the ar724x fixup code to match what the ar71xx fixup
code does.
I've validated this on an AR7240 with AR9285 on-board NIC. It doesn't
yet load, as the AR9285 EEPROM code needs to be made "flash aware."
TODO:
* Validate that I haven't broken AR71xx
* Test AR9285/AR9287 onboard NICs, complete with EEPROM code changes
* Port over the needed BAR hacks for AR7240, AR7241 and AR7242 from
Linux OpenWRT. The current WAR has only been tested on the AR7240
and I'm not sure the way the BAR register is treated is "right".
The "fixup" method here is right when setting the BAR for local access -
ie, the BAR address is either 0xffff (AR7240) or 0x1000ffff (AR7241/AR7242),
but the ath9k-fixup.c code (Linux OpenWRT) does this when setting the
initial "fixup" BAR. It then restores the original BAR.
I'll have to read the ar724x PCI bus glue to see what other special cases
await.
This was preventing the ath driver from being loaded at runtime.
It worked fine when compiled statically into the kernel but not when
kldload'ed after the system booted.
The root cause was that PCIR_INTLINE (register 60) was being
overwritten by zeros when register 62 was being written to.
A subsequent read of this register would return 0, and thus
the rest of the PCI glue assumed an IRQ resource had already
been allocated. This caused the device to fail to attach at
runtime as the device itself didn't contain any IRQ resources.
TODO: go back over the ar71xx and ar724x PCI config read/write
code and ensure it's correct.
one. Interestingly, these are actually the default for quite some time
(bus_generic_driver_added(9) since r52045 and bus_generic_print_child(9)
since r52045) but even recently added device drivers do this unnecessarily.
Discussed with: jhb, marcel
- While at it, use DEVMETHOD_END.
Discussed with: jhb
- Also while at it, use __FBSDID.
of endian-ness issues with the AR724x.
From Luiz:
* Fix the bus space tag used so endian-ness is correctly handled;
* Only do the workaround for the AR7240; AR7241/AR7242 (PB92)
don't require this
From me:
* Add a read flush from openwrt
Submitted by: Luiz Otavio O Souza
This is reported to work on the AR7240 based Ubiquiti Rocket M5
but I haven't tested it on that hardware. I also don't yet have
it fully working on the AR7242 based development board here;
probe/attach functions but the register space resource looks like
the endian-ness is wrong (0x10000000 instead of 0x00001000).o
Further digging will be required.
Submitted by: Luiz Otavio O Souza
