[U-Boot] [PATCH v6] net: ll_temac: Add LL TEMAC driver to u-boot
Wolfgang Denk
wd at denx.de
Sun Nov 27 23:29:39 CET 2011
Dear Stephan Linz,
In message <1322424370.3870.370.camel at keto> you wrote:
>
> > ETH_HALTING is permanently undef'ed, so all this is dead code. Please
> > remove.
>
> @Michal: Is there any platform which can not halt the TEMAC? I have no
> problem with this code but I left ETH_HALTING undefined from original
> driver code. I would like to remove all the ETH_HALTING statements and
> hold this code.
I have no idea. But there is no code in mainline that uses
ETH_HALTING, and your file #undef's it.
> > Interesting - here you return an error code, above you don't :-(
>
> Grr, ache on my head. I need one more look to the timeouts (see above).
ache != ash. I'm nut sure which you prefer, though ;-)
> > Umm.... this code is more or less exactly the same as for
> > ll_temac_recv_sdma(). Can we please avoid this duplication of code?
> >
> > Ditto for the other duplicated functions.
>
> You are completely right, but for more than one week I have not found
> any practicable way to avoid duplicate code here. The only really good
> approach would be to use private function pointers in struct ll_temac
> for all the in_*/out_* calls we need in sdma code and refactor the DCR
> code to use its special in_*/out_* functions with the same prototype.
diff'ing the functions it appears there are only very few function
pointers that would be needed.
> This special 'DCR' function can map into indirect DCR access. But
> unfortunately in_be32() and out_be32() for Microblaze are not real
> functions. They are CPP defines :-(
Change it? Turning them into inline functions should be not too
difficult.
> I will review arch/microblaze/include/asm/io.h together with Michal.
> Until then it would be nice if we could keep this code as it is. I will
> fix the dublicate code if we have in/out functions -- no defines.
Hm... past experience has shown that the stragey of adding bad code
first and then cleaning it up has never worked really well, nor fast.
Insisting on clean patches from the beginning is probably more
painful, but almost always faster, and more reliable.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The first 90% of a project takes 90% of the time, the last 10% takes
the other 90% of the time.
More information about the U-Boot
mailing list