Ethernet PHY chip discovery not working on 855T with 971/972 chips
Wolfgang Denk
wd at denx.de
Sat Jul 12 05:18:58 EST 2003
In message <20030711185050.GB17433 at ip68-0-152-218.tc.ph.cox.net> you wrote:
>
> 2.5 untested, so that when 2.6 rolls around there is less pain for all,
> and 2.4 tested. This hasn't changed, and is becoming a bit more of a
> trend even outside of the PPC world. It's not even that hard to test
> now, doing 'make ARCH=ppc CROSS_COMPILE=foo arch/ppc/foo/bar.o' will
> work and is a feature of the new build system.
Does not work for me; even simple core files fail to compile:
-> make ARCH=ppc CROSS_COMPILE=ppc_8xx- arch/ppc/syslib/ppc8xx_pic.o
CC arch/ppc/syslib/ppc8xx_pic.o
arch/ppc/syslib/ppc8xx_pic.c:172: parse error before `irqreturn_t'
arch/ppc/syslib/ppc8xx_pic.c:172: `request_irq' declared as function returning a function
arch/ppc/syslib/ppc8xx_pic.c:172: warning: function declaration isn't a prototype
arch/ppc/syslib/ppc8xx_pic.c:173: parse error before `unsigned'
make[1]: *** [arch/ppc/syslib/ppc8xx_pic.o] Error 1
make: *** [arch/ppc/syslib/ppc8xx_pic.o] Error 2
> > IIRC the last time we such discussions simply nothing happened: see
> > for example to code for dp_alloc / dp_free that was submitted several
> > times.
>
> google knows nothing of this, can you give a pointer into the thread
> please? Thanks.
Sorry, I don't have that much time to go thtough this again. AFAIR
> > Or see thread "set_rtc_time() cleanup / normalization" in May
> > this year.
>
> I just re-read most of it, and Gabriel Paubert, who wrote most / all of
> that code, and is the 'maintainer' of sorts objected, a few solutions to
> make everyone happy were proposed (ppc_md hook or similar, I believe)
> and no further patch was submitted.
IIRC there was a general disagreement - what patch do you expect then?
> As always, send things in functional hunks. If for example, the 8xx /
> 8260 enet and serial drivers (Of note: the 4xx enet driver now falls
> into this catagory) in 2.6 get moved into drivers/serial (And rewritten)
Please explain what "get moved" means. Is this planned but not
started yet? work in progress? who is working on it? who is
discussing these things? where does such discussion take place? I've
seen nothing like this on lkml? what must one do to participate in
such discussions?
> least as much griping as I've made in the past, if not more. And when
> someone comments on the reasoning, logic, or suggests an alternate way
> of doing things for people which need the current behavior / whatever,
> re-spin the patch. All of the patches you've submitted to me like this,
Sorry, but how should anybody comment before being faced with
accomplished facts?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
Hegel was right when he said that we learn from history that man can
never learn anything from history. - George Bernard Shaw
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
More information about the Linuxppc-embedded
mailing list