Am 24.08.2016 um 09:54 schrieb 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@7f0000 {
+                                       board_config: partition@7f0000 {
                                                label = "board_config";
                                                reg = <0x7f0000 0x10000>;
                                                read-only;
@@ -143,6 +143,11 @@
                pci@E105400 {
                        status = "okay";
                        gpio-reset = <&gpio 21 0>;
+
+                       wmac@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

I've the required patches in my a tree[1] for a while but was distracted by other stuff. They need a bit of testing on other platforms than lantiq, but in general I consider them as complete.

At the moment I'm trying to get a patch upstream which will allow to override the mac address stored in the EEPROM. The EEPROM of at least three lantiq devices has for every device the same generic ralink mac in EEPROM.

Mathias

[1] https://github.com/mkresin/lede/commits/ralink

_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Reply via email to