All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pete Popov <ppopov@embeddedalley.com>
To: Ulrich Eckhardt <eckhardt@satorlaser.com>
Cc: linux-mips@linux-mips.org
Subject: Re: bitrot in drivers/net/au1000_eth.c
Date: Fri, 28 Jan 2005 09:01:36 -0800	[thread overview]
Message-ID: <41FA6FF0.4060302@embeddedalley.com> (raw)
In-Reply-To: <200501281501.19162.eckhardt@satorlaser.com>

Ulrich Eckhardt wrote:
> Hi!
> 
> I've been debugging a problem in above mentioned file and found several cases 
> of redundant, unused or even buggy code in the handling of the MII there. 
> Also, there is a comment that suggests that I'm not the only one: 
>  * FIXME
>  * All of the PHY code really should be detached from the MAC
>  * code.

Yes, I put that in over four years ago. There was no mii code at 
all, that I could find, at that time. I wanted to separate the mii 
code out of the mac driver but it never happened.

> An important point there is that much of the code is in fact not even specific 
> to the au1x00 ethernet adapters. I found driver code for the MII I wanted to 
> drive in sis900.c, and it looked almost similar to the code in au1x00.c. 
> Simply adding the device/vendor IDs to a map and choosing the first of the 
> drivers there got my ethernet running.
> 
> Now, question is how to proceed. There are basically three ways I would go:
> 1. Leave it like it is, because someone else is working on it. I'd just post a 
> mini-patch that binds my device to an existing driver.

For 2.6, I was told someone is working on something ...

> 2. Remove the dead/unused parts from au1x00.c, try to restructure and document 
> the code so it is easier to maintain in the future.
> 3. Split off the MII handling code or, better, reuse the facility already 
> provided by drivers/net/mii.c. This would mean a significant rewrite of 
> au1x00.c, including probably breaking things on the way.

That's a possibility too but more code needs to be added to mii.c. I 
actually revisited the code yesterday and was trying to figure out 
how to clean it up. But someone told me that there is 2.6 work in 
progress to do this so I decided to just wait. Maybe someone knows 
more about it.

Pete

  reply	other threads:[~2005-01-28 17:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-28 14:01 bitrot in drivers/net/au1000_eth.c Ulrich Eckhardt
2005-01-28 17:01 ` Pete Popov [this message]
2005-01-28 17:20   ` Matt Porter
2005-01-28 18:15     ` Pete Popov
2005-01-29 10:04     ` Ulrich Eckhardt
2005-01-30 11:50 ` Ulrich Eckhardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41FA6FF0.4060302@embeddedalley.com \
    --to=ppopov@embeddedalley.com \
    --cc=eckhardt@satorlaser.com \
    --cc=linux-mips@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.