Ethernet PHY chip discovery not working on 855T with 971/972 chips

Ethernet PHY chip discovery not working on 855T with 971/972 chips

[Dean Matsen]

To whomever maintains the file arch/ppc/8xx_io/fec.c:

I note the following code in mii_discover_phy() :

     fep = dev->priv;

     if ((phytype = (mii_reg & 0xffff)) != 0xffff) {

         /* Got first part of ID, now get remainder.
         */

In our devices, reading the first word with the wrong address yields the
value 0, not 0xFFFF.  This happens even if we play with it by hand.  The
search goes through address 0, 1, 2, .., and our chip is hard-coded at
address 1.  What happens is the kernel panics with something like
"Don't know what chip ID 0000FFFF is".  Anyway, I changed it to the
following, and it finds our PHY correctly now.

     fep = dev->priv;

     phytype = (mii_reg & 0xffff);
     if (phytype != 0xffff && phytype != 0x0000) {

         /* Got first part of ID, now get remainder.
         */

I am guessing that probably most devices have the PHY chip at address
zero, so nobody else has run into this problem because it finds their
chip in the first iteration.

You may also want to note in the file that it supports 972 chips (which
apparently look like 971 chips from the inside, 'cuz that's what the
kernel says it is).  Perhaps the printk() should be updated to say
"971/972" instead of just "971"?


Thanks
Dean Matsen


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ethernet PHY chip discovery not working on 855T with 971/972 chips

[Dean Matsen]

Dean Matsen wrote:

>
> In our devices, reading the first word with the wrong address yields the
> value 0, not 0xFFFF.

I suspect that this may have been part of the problem in

http://lists.linuxppc.org/linuxppc-embedded/200107/msg00141.html

but that's a guess.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ethernet PHY chip discovery not working on 855T with 971/972 chips

[Eugene Surovegin]

At 07:29 PM 7/8/2003, Dean Matsen wrote:

>Dean Matsen wrote:
>
>>
>>In our devices, reading the first word with the wrong address yields the
>>value 0, not 0xFFFF.
>
>I suspect that this may have been part of the problem in
>
>http://lists.linuxppc.org/linuxppc-embedded/200107/msg00141.html
>
>but that's a guess.

It usually means that your hw lacks pull-up on MII MDIO line.

Eugene


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ethernet PHY chip discovery not working on 855T with 971/972 chips

[Dan Malek]

Eugene Surovegin wrote:

> It usually means that your hw lacks pull-up on MII MDIO line.

Yep, and even when PHYs indicate they have internal pull-ups, either
they don't or they aren't sufficient.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ethernet PHY chip discovery not working on 855T with 971/972 chips

[Dean Matsen]

Dan Malek wrote:

>
> Eugene Surovegin wrote:
>
>> It usually means that your hw lacks pull-up on MII MDIO line.
>
>
> Yep, and even when PHYs indicate they have internal pull-ups, either
> they don't or they aren't sufficient.
>
>
> -- Dan
>
>
>
>
Yes, I see we have no pullup on that line. We do dedicated HVAC
applications, so we
don't need to do this search. Our dedicated software wouldn't talk to
the chip
at the wrong address.

Don't you think the fix from my original message should still be
considered for
integration into the kernel? It will improve the odds that the kernel can
auto-detect someone's hardware....

Thanks
Dean


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ethernet PHY chip discovery not working on 855T with 971/972 chips

[Dan Malek]

Dean Matsen wrote:

> Yes, I see we have no pullup on that line. We do dedicated HVAC
> applications, so we
> don't need to do this search.

But.......the hardware is broken.  The MDIO is supposed to be
an open-drain with a pullup.  I guess you may be lucky the
ends of the connection are driving the line proplerly, but it
could be luck that will run out someday.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ethernet PHY chip discovery not working on 855T with 971/972 chips

[Dean Matsen]

Dan Malek wrote:

>
> Dean Matsen wrote:
>
>> Yes, I see we have no pullup on that line. We do dedicated HVAC
>> applications, so we
>> don't need to do this search.
>
>
> But.......the hardware is broken. The MDIO is supposed to be
> an open-drain with a pullup. I guess you may be lucky the
> ends of the connection are driving the line proplerly, but it
> could be luck that will run out someday.
>
>
> -- Dan
>
Well, I don't disagree there. We're going to investigate updating the
schematics for future products. Thanks for the input.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ethernet PHY chip discovery not working on 855T with 971/972 chips

[Dean Matsen]

  Dan Malek wrote:

>
> Dean Matsen wrote:
>
>> Yes, I see we have no pullup on that line. We do dedicated HVAC
>> applications, so we
>> don't need to do this search.
>
>
> But.......the hardware is broken.  The MDIO is supposed to be
> an open-drain with a pullup.  I guess you may be lucky the
> ends of the connection are driving the line proplerly, but it
> could be luck that will run out someday.
>
>
>     -- Dan

Actually, it turns out that this is not quite true.  The MDIO line
is classified as an I/O line (on the same page where other lines
are classified as open drain).  There are tons of application notes from
Motorola and Intel and none of them show a pullup.  I think
this issue has more to do with talking to a device at the wrong address
and  having the line float only in that case.

The actual problem I have is that the kernel panics before it even gets
to address 1 (which is where my PHY chip is in the first place).  This
happens whenever it reads a value other than FFFF from the first word
of the ID.  I see now that my first patch adds detection for the value
0000, but other people may have varying results (especially if they
follow the app notes and don't have a pullup, like we do).

I think the search should be made smarter (especially, keep going to
the next address until it has gone through ALL address w/o finding a
valid ID).  The kernel could still panic if it can't find any PHY chip,
but not the first time it reads the floating line and can't find the
answer in its table.  The odds of reading a valid PHY ID from the
floating line is phenominally low.  I'd submit a proposed patch for
this, but it doesn't sound like anyone else thinks this is important
enough to warrant a change.

Those maintaining the official kernel repositories should consider whether
or not it's friendly to require the addition of a pullup resistor just so
the automatic PHY search will work.  Unless the pullup is required for
non-search applications (which I assert it isn't), then I think the code
should be fixed, not the hardware.

Regards,

Dean


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ethernet PHY chip discovery not working on 855T with 971/972 chips

[Wolfgang Denk]

In message <3F0C8112.5060001@earthlink.net> you wrote:
>
> I think the search should be made smarter (especially, keep going to
> the next address until it has gone through ALL address w/o finding a
> valid ID).  The kernel could still panic if it can't find any PHY chip,
> but not the first time it reads the floating line and can't find the
> answer in its table.  The odds of reading a valid PHY ID from the
> floating line is phenominally low.  I'd submit a proposed patch for
> this, but it doesn't sound like anyone else thinks this is important
> enough to warrant a change.

I agree that it makes little sense for th kernel to panic if it finds
an unsupported PHY id.

> the automatic PHY search will work.  Unless the pullup is required for
> non-search applications (which I assert it isn't), then I think the code
> should be fixed, not the hardware.

We changed this in our kernel tree some time ago. If no valid PHY  is
found  we simply do not enable the interface, but we do not panic any
more.


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"A witty saying proves nothing."                           - Voltaire

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ethernet PHY chip discovery not working on 855T with 971/972 chips

[Wolfgang Denk]

Dear Tom,

in message <20030711151834.GU17433@ip68-0-152-218.tc.ph.cox.net> you wrote:
>
> > We changed this in our kernel tree some time ago. If no valid PHY  is
> > found  we simply do not enable the interface, but we do not panic any
> > more.
>
> Which raises two fun questions:
> 1) Do you plan on ever trying to re-sync your 2.4 tree with the
> community tree (which should become kernel.org before too long)?

We do this from time to time. The last  (visible)  re-sync  was  with
2.4.20  (ChangeSet  1.1174  =  20021129181904|49831), which is half a
year ago. On the other hand, we don't have the  resources  to  follow
each and every change immediately.

> 2) Do you plan on trying to keep in sync with 2.6 now that it's coming
> up on us?

Of course we will follow 2.6 as well.

Why are you asking? Did I give any reason to think we might go out of
business?


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"There are three principal ways to lose money: wine, women,  and  en-
gineers.  While  the first two are more pleasant, the third is by far
the more certain."                      -- Baron Rothschild, ca. 1800

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ethernet PHY chip discovery not working on 855T with 971/972 chips

[Tom Rini]

On Fri, Jul 11, 2003 at 05:43:18PM +0200, Wolfgang Denk wrote:
> Dear Tom,
>
> in message <20030711151834.GU17433@ip68-0-152-218.tc.ph.cox.net> you wrote:
> >
> > > We changed this in our kernel tree some time ago. If no valid PHY  is
> > > found  we simply do not enable the interface, but we do not panic any
> > > more.
> >
> > Which raises two fun questions:
> > 1) Do you plan on ever trying to re-sync your 2.4 tree with the
> > community tree (which should become kernel.org before too long)?
>
> We do this from time to time. The last  (visible)  re-sync  was  with
> 2.4.20  (ChangeSet  1.1174  =  20021129181904|49831), which is half a
> year ago. On the other hand, we don't have the  resources  to  follow
> each and every change immediately.
>
> > 2) Do you plan on trying to keep in sync with 2.6 now that it's coming
> > up on us?
>
> Of course we will follow 2.6 as well.
>
> Why are you asking? Did I give any reason to think we might go out of
> business?

No, but I do wonder if you ever plan on sending anything out again.  It
does seem to be a once a year event, which is just about due (2002-06-18
is the last one I see).

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ethernet PHY chip discovery not working on 855T with 971/972 chips

[Wolfgang Denk]

Dear Tom,

in message <20030711155226.GV17433@ip68-0-152-218.tc.ph.cox.net> you wrote:
>
> No, but I do wonder if you ever plan on sending anything out again.  It

Has anything  significantly  changed?  Patches/extensions  are  still
accepted for 2.5 only, right? Does this tree work for 8xx systems?

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.  Or see thread "set_rtc_time() cleanup / normalization" in May
this year.


If you suggest there is a way to get patches really included into the
"official" trees, please let me know how to do this.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
You see things; and you say ``Why?'' But I dream  things  that  never
were; and I say ``Why not?''
       - George Bernard Shaw _Back to Methuselah_ (1921) pt. 1, act 1

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ethernet PHY chip discovery not working on 855T with 971/972 chips

[Tom Rini]

On Fri, Jul 11, 2003 at 08:29:16PM +0200, Wolfgang Denk wrote:
>
> Dear Tom,
>
> in message <20030711155226.GV17433@ip68-0-152-218.tc.ph.cox.net> you wrote:
> >
> > No, but I do wonder if you ever plan on sending anything out again.  It
>
> Has anything  significantly  changed?  Patches/extensions  are  still
> accepted for 2.5 only, right? Does this tree work for 8xx systems?

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.

>
> 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.

> 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.

> If you suggest there is a way to get patches really included into the
> "official" trees, please let me know how to do this.

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)
and drivers/net (cleaned up?), rmk (serial maintainer) and Jeff Garzik
(net driver maintainer) aren't going to take a large patch without at
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,
AFAIK, have either been accepted, or I've told you I cannot take that
patch, it needs to be sent elsewhere.

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ethernet PHY chip discovery not working on 855T with 971/972 chips

[Wolfgang Denk]

In message <20030711185050.GB17433@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@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/

Re: Ethernet PHY chip discovery not working on 855T with 971/972 chips

[Tom Rini]

On Fri, Jul 11, 2003 at 09:18:58PM +0200, Wolfgang Denk wrote:
> In message <20030711185050.GB17433@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

Are you modifying ppc8xx_pic.c ?  And yes, it does need generic updates.

> > > 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

You don't have time to find a pointer to a discussion?  Then I can't say
why nothing happened, but I'll wager a guess that Dan Malek didn't like
it for some reason.

> > > 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?

If there was a general disagreement (I thought the add a do or don't do
this in an interrupt flag was accepted) I can't go and apply the patch
anyhow.  That's also not something I can help you with[1].

> > 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?

A hypotheical.  Not that the serial drivers shouldn't be moved to the
new serial infrastructure that'll c&p bugs...

> > 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?

Can you rephrase that?  What I was saying is that frequently Paul has
pointed to something done outside of the 8xx / 8260 world and asked if
we can try doing it in a different way instead, which he believes is
cleaner / better / whatever.  And since Paul is the PPC maintainer, I
(or whomever has been asked) will give it a shot, or explain why that
won't work.

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ethernet PHY chip discovery not working on 855T with 971/972 chips

[Wolfgang Denk]

In message <20030711193435.GC17433@ip68-0-152-218.tc.ph.cox.net> you wrote:
>
> Are you modifying ppc8xx_pic.c ?  And yes, it does need generic updates.

No, not at the moment. But how can I understand the stuff in 2.5 if I
cannot even compile the code for any standard 8xx system? Any  effort
to add more code of similar quality is a waste of time.

> You don't have time to find a pointer to a discussion?  Then I can't say
> why nothing happened, but I'll wager a guess that Dan Malek didn't like
> it for some reason.

I can dig out the original messages when I sent you  the  patches,  I
can  try to find traces in the archives. It takes time, but what will
be the result? If nothing happened then, I don't expect  anything  to
happen now.

You are right, patches get rejected because somebody didn't  like  it
for  some  reason.  But  if  these  patches are addressing reoccuring
problems, and no other  (better)  solution  gets  implemented,  which
sense does it make to reject the stuff?

I'm sorry, but both you and me remember that we had discussions  like
this  before,  and obviously nothing has changed since. So the result
will be the same. We can stop that here.


> > 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?
>
> A hypotheical.  Not that the serial drivers shouldn't be moved to the
> new serial infrastructure that'll c&p bugs...

Let me repeat: 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?

> Can you rephrase that?  What I was saying is that frequently Paul has
> pointed to something done outside of the 8xx / 8260 world and asked if

Where has this frequent discussion taken place? I don't remember I've
seen it here on the list, nor on lkml (well, I might have  missed  it
on lkml).


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
In the beginning there was nothing.
And the Lord said "Let There Be Light!"
And still there was nothing, but at least now you could see it.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ethernet PHY chip discovery not working on 855T with 971/972 chips

[Pantelis Antoniou]

Tom Rini wrote:

>On Fri, Jul 11, 2003 at 08:29:16PM +0200, Wolfgang Denk wrote:
>
[snip]

>
>>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.
>
>
I was the one that sent the patches (search for dpalloc).

A link to the thread in the archive is here.

http://lists.linuxppc.org/linuxppc-embedded/200212/msg00302.html

As it stands I maintain them for the linuxppc_2_4_devel tree
and I'm waiting for the 2.5 to build in order to port them
there and resubmit.

>
>--
>Tom Rini
>http://gate.crashing.org/~trini/
>
>
>
>
>
Regards

Pantelis


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ethernet PHY chip discovery not working on 855T with 971/972 chips

[Wolfgang Denk]

Dear Pantelis,

in message <3F124BF5.6070803@intracom.gr> you wrote:
>
> >>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.
> >
> >
> I was the one that sent the patches (search for dpalloc).

I was referring to a much older implementation  of  this  feature.  I
sent it to Tom nearly two years ago:

	Subject: Re: Modifications to linuxppc_2_4_devel
	From: Wolfgang Denk <wd@denx.de>
	Date: Wed, 29 Aug 2001 23:57:30 +0200
	To: Tom Rini <trini@kernel.crashing.org>

The patch in question was named "PATCH-006-dpfree+uart".


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Ever try. Ever fail. No matter. Try again. Fail again.  Fail  better.
                                                        -- S. Beckett

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ethernet PHY chip discovery not working on 855T with 971/972 chips

[Tom Rini]

On Mon, Jul 14, 2003 at 09:58:05AM +0200, Wolfgang Denk wrote:

> Dear Pantelis,
>
> in message <3F124BF5.6070803@intracom.gr> you wrote:
> >
> > >>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.
> > >
> > >
> > I was the one that sent the patches (search for dpalloc).
>
> I was referring to a much older implementation  of  this  feature.  I
> sent it to Tom nearly two years ago:
>
> 	Subject: Re: Modifications to linuxppc_2_4_devel
> 	From: Wolfgang Denk <wd@denx.de>
> 	Date: Wed, 29 Aug 2001 23:57:30 +0200
> 	To: Tom Rini <trini@kernel.crashing.org>
>
> The patch in question was named "PATCH-006-dpfree+uart".

I really wish I had looked into making mutt keep a copy of sent mail a
lot sooner.  I don't suppose you have a copy of my reply to that as
well?  I suspect it was either "Can you break the uart stuff out from
the dpfree stuff" and you didn't, or "This is large and intrusive and
I'd feel better if I could make Dan Malek look at it".

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ethernet PHY chip discovery not working on 855T with 971/972 chips

[Wolfgang Denk]

Dear Tom,

in message <20030714143110.GA1211@ip68-0-152-218.tc.ph.cox.net> you wrote:
>
> > I was referring to a much older implementation  of  this  feature.  I
> > sent it to Tom nearly two years ago:
...
> I really wish I had looked into making mutt keep a copy of sent mail a
> lot sooner.  I don't suppose you have a copy of my reply to that as
> well?  I suspect it was either "Can you break the uart stuff out from
> the dpfree stuff" and you didn't, or "This is large and intrusive and
> I'd feel better if I could make Dan Malek look at it".

I found two related replies in my archive:

28 Aug 2001:
...
PATCH-006 - Looks good.  I'll play w/ it a bit more tomorrow and let you
  know.
...

15 Oct 2001:
...
PATCH-006 Paul Mundt has been a bit busy of late (and had his disks die
a week or so ago), but he should have something soon I hope.  Sorry.
...



Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Der Irrtum wiederholt sich immerfort in der Tat.  Deshalb muß man das
Wahre unermüdlich in Worten wiederholen.                     - Goethe

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ethernet PHY chip discovery not working on 855T with 971/972 chips

[Tom Rini]

On Mon, Jul 14, 2003 at 09:26:13PM +0200, Wolfgang Denk wrote:
> Dear Tom,
>
> in message <20030714143110.GA1211@ip68-0-152-218.tc.ph.cox.net> you wrote:
> >
> > > I was referring to a much older implementation  of  this  feature.  I
> > > sent it to Tom nearly two years ago:
> ...
> > I really wish I had looked into making mutt keep a copy of sent mail a
> > lot sooner.  I don't suppose you have a copy of my reply to that as
> > well?  I suspect it was either "Can you break the uart stuff out from
> > the dpfree stuff" and you didn't, or "This is large and intrusive and
> > I'd feel better if I could make Dan Malek look at it".
>
> I found two related replies in my archive:
>
> 28 Aug 2001:
> ...
> PATCH-006 - Looks good.  I'll play w/ it a bit more tomorrow and let you
>   know.
> ...
>
> 15 Oct 2001:
> ...
> PATCH-006 Paul Mundt has been a bit busy of late (and had his disks die
> a week or so ago), but he should have something soon I hope.  Sorry.
> ...

I found that one (I do keep replies) and that was for an rpxfb patch.

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ethernet PHY chip discovery not working on 855T with 971/972 chips

[Dean Matsen]

Tom Rini wrote:

>On Wed, Jul 09, 2003 at 11:21:40PM +0200, Wolfgang Denk wrote:
>
>
>
>>In message <3F0C8112.5060001@earthlink.net> you wrote:
>>
>>
>>>I think the search should be made smarter (especially, keep going to
>>>the next address until it has gone through ALL address w/o finding a
>>>valid ID).  The kernel could still panic if it can't find any PHY chip,
>>>but not the first time it reads the floating line and can't find the
>>>answer in its table.  The odds of reading a valid PHY ID from the
>>>floating line is phenominally low.  I'd submit a proposed patch for
>>>this, but it doesn't sound like anyone else thinks this is important
>>>enough to warrant a change.
>>>
>>>
>>I agree that it makes little sense for th kernel to panic if it finds
>>an unsupported PHY id.
>>
>>
>>
>>>the automatic PHY search will work.  Unless the pullup is required for
>>>non-search applications (which I assert it isn't), then I think the code
>>>should be fixed, not the hardware.
>>>
>>>
>>We changed this in our kernel tree some time ago. If no valid PHY  is
>>found  we simply do not enable the interface, but we do not panic any
>>more.
>>
>>
>
>Which raises two fun questions:
>1) Do you plan on ever trying to re-sync your 2.4 tree with the
>community tree (which should become kernel.org before too long)?
>2) Do you plan on trying to keep in sync with 2.6 now that it's coming
>up on us?
>
>--
>Tom Rini
>http://gate.crashing.org/~trini/
>
>
>
>
>
Somewhere in this discussion thread I saw that the 2.4 kernel is closed for
patches (I just joined this list, so I didn't know that).

Would it help if I came up with a 2.5 patch for fec.c? I made a few minor
changes that will make it behave friendlier for all [to whom it is not
already being totally friendly], and I see the 2.5 kernel could use some
of the same changes.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ethernet PHY chip discovery not working on 855T with 971/972 chips

[Paul Mackerras]

Dean Matsen writes:

> Somewhere in this discussion thread I saw that the 2.4 kernel is closed for
> patches (I just joined this list, so I didn't know that).

Well, that's not strictly true, we will continue to fix things that
are broken, but I would prefer than any new development (e.g. support
for new boards or devices) happened in 2.5.  It's a bit disappointing
that 8xx still doesn't compile in 2.5.  I don't have any 8xx hardware
to test on so I have been relying on others to update it.

> Would it help if I came up with a 2.5 patch for fec.c? I made a few minor
> changes that will make it behave friendlier for all [to whom it is not
> already being totally friendly], and I see the 2.5 kernel could use some
> of the same changes.

Excellent idea. :)

Paul.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ethernet PHY chip discovery not working on 855T with 971/972 chips

[Dean Matsen]

Paul Mackerras wrote:

>Dean Matsen writes:
>
>
>
>>Somewhere in this discussion thread I saw that the 2.4 kernel is closed for
>>patches (I just joined this list, so I didn't know that).
>>
>>
>
>Well, that's not strictly true, we will continue to fix things that
>are broken, but I would prefer than any new development (e.g. support
>for new boards or devices) happened in 2.5.  It's a bit disappointing
>that 8xx still doesn't compile in 2.5.  I don't have any 8xx hardware
>to test on so I have been relying on others to update it.
>
>
Ok, in that case I do have ONE thing that I know should be fixed, but
I haven't seen any response on it, so I am wondering if anyone noticed
it at all. See

http://lists.linuxppc.org/linuxppc-dev/200307/msg00085.html

This affects existing support. It's so simple that:
a) It's kind of annoying to 8xx people
b) probably everyone will figure it out
c) there is really no risk in fixing it.

>
>
>>Would it help if I came up with a 2.5 patch for fec.c? I made a few minor
>>changes that will make it behave friendlier for all [to whom it is not
>>already being totally friendly], and I see the 2.5 kernel could use some
>>of the same changes.
>>
>>
>
>Excellent idea. :)
>
>Paul.
>
>
>
>
>
I would love to see the kernel perform well for mpc8xx users right out
of the
box, so I am highly motivated to contibute. I'll focus on the 2.5 kernel
(I'm surprised to hear it doesn't compile).


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ethernet PHY chip discovery not working on 855T with 971/972 chips

[Wolfgang Denk]

In message <3F1079FA.3050901@earthlink.net> you wrote:
>
> box, so I am highly motivated to contibute. I'll focus on the 2.5 kernel
> (I'm surprised to hear it doesn't compile).

I think it never did. At least never all the times I tried.


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Administration: An ingenious abstraction  in  politics,  designed  to
receive the kicks and cuffs due to the premier or president.
- Ambrose Bierce

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ethernet PHY chip discovery not working on 855T with 971/972 chips

[Tom Rini]

On Sat, Jul 12, 2003 at 02:13:30PM -0700, Dean Matsen wrote:

> Paul Mackerras wrote:
>
> >Dean Matsen writes:
> >
> >
> >
> >>Somewhere in this discussion thread I saw that the 2.4 kernel is closed
> >>for
> >>patches (I just joined this list, so I didn't know that).
> >>
> >>
> >
> >Well, that's not strictly true, we will continue to fix things that
> >are broken, but I would prefer than any new development (e.g. support
> >for new boards or devices) happened in 2.5.  It's a bit disappointing
> >that 8xx still doesn't compile in 2.5.  I don't have any 8xx hardware
> >to test on so I have been relying on others to update it.
> >
> >
> Ok, in that case I do have ONE thing that I know should be fixed, but
> I haven't seen any response on it, so I am wondering if anyone noticed
> it at all. See
>
> http://lists.linuxppc.org/linuxppc-dev/200307/msg00085.html

This has been fixed in the 2_4_devel tree now.  This is not an issue in
2.5 / 2.6.

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ethernet PHY chip discovery not working on 855T with 971/972 chips

[Dan Malek]

Paul Mackerras wrote:

 > .... It's a bit disappointing
> that 8xx still doesn't compile in 2.5.  I don't have any 8xx hardware
> to test on so I have been relying on others to update it.

Ok, OK....I'll work on it some more.  I'm travelling for the next week or
so, but when I get back I'll push some updates and get it going.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ethernet PHY chip discovery not working on 855T with 971/972 chips

[Roland Dreier]

    Paul> .... It's a bit disappointing that 8xx still doesn't compile
    Paul> in 2.5.  I don't have any 8xx hardware to test on so I have
    Paul> been relying on others to update it.

Speaking of 2.5, since our custom boards are in production now, I have
an Ebony (440GP eval board) that is completely idle, and some free
hacking time.  Is there any 4xx work that I could help with?  Is
linuxppc-2.5 the right tree to use?

Best,
  Roland

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ethernet PHY chip discovery not working on 855T with 971/972 chips

[Matt Porter]

On Sun, Jul 13, 2003 at 09:29:09AM -0700, Roland Dreier wrote:
>
>     Paul> .... It's a bit disappointing that 8xx still doesn't compile
>     Paul> in 2.5.  I don't have any 8xx hardware to test on so I have
>     Paul> been relying on others to update it.
>
> Speaking of 2.5, since our custom boards are in production now, I have
> an Ebony (440GP eval board) that is completely idle, and some free
> hacking time.  Is there any 4xx work that I could help with?  Is

A 44x thing that would be nice is to abstract the PCI-X bridge support
into a common call (or calls) so it can be configured into a variety
of windowing modes...like alternative monarch memory maps or any
non-monarch configurations.  Part of this would work would require that
fixup_bigphys_addr() be made aware of these window changes.  In addition
it would be nice to have a helper function that sets the same values as
the current hardcoded monarch configuration via the new abstracted
interface since that is a common configuration.

Sorry, but you asked. :)

> linuxppc-2.5 the right tree to use?

Yes, nothing 44x-related should be going in without a 2.5 patch.
I've invested considerable time making sure that it was usable
by other developers on 44x...hopefully that still the case after
two weeks of vacation.

Regards,
--
Matt Porter
mporter@kernel.crashing.org

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ethernet PHY chip discovery not working on 855T with 971/972 chips

[Roland Dreier]

    Matt> A 44x thing that would be nice is to abstract the PCI-X
    Matt> bridge support into a common call (or calls) so it can be
    Matt> configured into a variety of windowing modes...like
    Matt> alternative monarch memory maps or any non-monarch
    Matt> configurations.  Part of this would work would require that
    Matt> fixup_bigphys_addr() be made aware of these window changes.
    Matt> In addition it would be nice to have a helper function that
    Matt> sets the same values as the current hardcoded monarch
    Matt> configuration via the new abstracted interface since that is
    Matt> a common configuration.

That sounds doable, although I'm not sure how to test any non-monarch
support given the systems I have available.  In any case I'll start
taking a look at the current 2.5 sources and try to come up with a
proposal for the right PCI-X abstraction.

 - R.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/