On Wed, 2006-10-04 at 23:33 -0700, Eugene Surovegin wrote:

On Thu, Oct 05, 2006 at 04:26:34PM +1000, Benjamin Herrenschmidt wrote:

quoted

Regarding the "mess", it's the whole #ifdef junk in there that is
driving me nuts and that I'll rip appart probably next week. A lot of
this could be soft-tests or the ifdefs could be resolved at Kconfig
instead of having a list of processors in 3 different headers if you
really want to compile the changes in rather than do soft-tests.

Well, sent me changes for review, or become a maintainer, but this 
time _real_ maintainer, not like last time when you touched this code.

Well, last time I touched this code, I took something that was not
working at all and made it work for me and a couple of other people that
were working on it at the same time. If it had issues, they were never
reported to me back then. However, I never intended to do long term
maintainership of this driver and that was clear from the very
beginning. If you ran into other issues and fixed them afterward, that's
fine, but don't blame me for not fixing issues I didn't encounter nor
was told about for the short time while I was taking care of it.

Anyway, my point is, the per-processor ifdef lists are just fugly and
need to be turned into "soft" changes. The driver also needs to get some
OF probing and use the new DCR accessors to move over to powerpc and to
work with the EMAC cell within the new Cell southbridge.

I have some preliminary patches doing just the OF probing and DCR
changes. I still want to do some serious change of the #ifdef mess into
something more flexible to allow for runtime choice of the type of EMAC
and MAL.

I'll post patches (and possibly incremental "cleanup") to the list,
CC'ing you, as expected for a driver you maintain.

Ben.