[LEDE-DEV] [RFC] lantiq: fix ath5k EEPROM loading

[Oswald Buddenhagen]

On Tue, Aug 23, 2016 at 09:14:36PM +0200, Mathias Kresin wrote:
> With 12fe4b579801ea812b64fc7e689716cd39c895ec I switched the ath5k
> eeprom extraction to an alternate code path. Unfortunately this code
> seams to be broken since ages and broke the ath5k EEPROM extraction.
> 
i have no particular opinion about this patch itself, but it reminds me
of something i stumbled over in my meanders into wifi driver land:
the fact that the platform driver hooks are there at all, and eeprom
content *files* are used is, ehm, suboptimal. a much more elegant
solution would be using the memory directly, and configuring it via a
proper pci device:

diff --git a/target/linux/lantiq/dts/ARV7506PW11.dts b/target/linux/lantiq/dts/ARV7506PW11.dts
index 1c38c88..61f726a 100644
--- a/target/linux/lantiq/dts/ARV7506PW11.dts
+++ b/target/linux/lantiq/dts/ARV7506PW11.dts
@@ -61,7 +61,7 @@
                                                reg = <0x440000 0x3B0000>;
                                        };

-                                       partition at 7f0000 {
+                                       board_config: partition at 7f0000 {
                                                label = "board_config";
                                                reg = <0x7f0000 0x10000>;
                                                read-only;
@@ -143,6 +143,11 @@
                pci at E105400 {
                        status = "okay";
                        gpio-reset = <&gpio 21 0>;
+
+                       wmac at e,0 {
+                               reg = <0x7000 0 0 0 0>;
+                               ralink,mtd-eeprom = <&board_config 0x410>;
+                       };
                };

        };
===============

the interesting thing is that all the necessary bits and pieces for that
are *in principle* already there, except for two catches:
- according to my reading of the implementation, the ralink,mtd-eeprom
  node wouldn't be actually read without a fake ralink,eeprom one, or
  something like that. that's just a matter of correctly re-nesting the
  code paths.
  - i had only a very cursory look over the ath*k drivers, but it
    appears that they work mostly the same way in this regard.
- the "somewhat" bigger problem is that there is no pci device tree
  support for mips in the first place - as of 4.4, it's implemented only
  for powerpc and sparc. but there doesn't appear to be a real reason
  for that other than "nobody's done it", as the device tree code is in
  principle just as generic as pci itself.

any takers? :D