Al 09/09/13 08:01, En/na John Crispin ha escrit: > On 08/09/13 18:50, Luca Olivetti wrote: >> Al 08/09/13 18:08, En/na Luca Olivetti ha escrit: >>> As per the subject, the function ath_pci_fixup (in >>> arch/mips/lantiq/xway/pci-ath-fixup.c) is called very early in the boot >>> process, before ath9k_eeprom_probe (in arch/mips/lantiq/xway/ath_eep.c) >>> has had any possibility to call ltq_pci_ath_fixup. >>> The net result is that the fixup isn't done and the wireless adapter >>> doesn't work. >>> What can I change to revert the order of those calls? (i'm lost in the >>> 75 levels of indirection, I had it working 3 years ago but then the >>> levels of indirection where only 63 ;-) >> >> Found the solution, change the call from >> >> late_initcall(of_ath9k_eeprom_init) >> >> to >> >> subsys_initcall(of_ath9k_eeprom_init). >> >> >> Now I have to see why it doesn't get the mac address and the regdomain >> from the eeprom (things, again, that I had working but it seems this >> platform is an easy target for being broken again and again). >> >> Bye >> >> >> >> _______________________________________________ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > > this is wrong. the eeprom needs to be probed after spi.
I don't know if it's right or wrong, I *do* know that this way it works, with late_initcall it doesn't. I see that before revision 36778 (probably the one that broke it) it was arch_initcall. What I'm sure about is that the eeprom must be probed *before* pci fixup (re-read the first message that explains the problem). Bye -- Luca _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
