[LEDE-DEV] [RFC] lantiq: fix ath5k EEPROM loading
John Crispin
john at phrozen.org
Wed Aug 24 01:17:45 PDT 2016
On 24/08/2016 09:54, Oswald Buddenhagen wrote:
> 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>;
> + };
> };
>
> };
> ===============
that would work for all devices that have a memory mapped flash chip.
however about 50% of the devices using the ralink code have spi flash
and various ltq targets using the ath version have spi aswell.
ideally all the code paths do get merged together into one. feel free to
send a patch doing so if you have time for it.
John
>
> 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
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>
More information about the Lede-dev
mailing list