Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: Thomas Koeller <thomas.koeller@baslerweb.com>
Cc: linux-mips@linux-mips.org, Manish Lachwani <mlachwani@mvista.com>
Subject: Re: titan_ge etherent driver
Date: Mon, 29 Nov 2004 11:31:01 +0100	[thread overview]
Message-ID: <20041129103101.GB32075@linux-mips.org> (raw)
In-Reply-To: <200411291105.43441.thomas.koeller@baslerweb.com>

On Mon, Nov 29, 2004 at 11:05:43AM +0100, Thomas Koeller wrote:

> since I noticed that you are working on the titan_ge driver,
> I think it is time to let you know that I am currently
> reworking that driver in the context of a new platform port.
> The primary goal is to cleanly separate the  titan_ge driver
> from the yosemite platform and to make it usable with other
> RM9000-based platforms as well.
> 
> The work is rather advanced, I did implement all the necessary
> changes and am now debugging through the thing to make it
> work. During the process I found quite a number of issues with
> the old driver that I fixed along the way.
> 
> The main points addressed by my work are these:
> 
> - Do no longer monopolize the message interrupt, so the titan_ge
>   can coexist with other drivers for OCDs.
> 
> - Do not refuse to initialize if the link is down. This
>   would prevent a statically linked kernel from booting if
>   no network cord was attached :-(

Indeed, these messages were looking suspicious and I also meant to eventually
look into them also ...

> - Properly allocate and deallocate any resources used.
> 
> - Introduce a mapping layer, so that the driver can be told to
>   use any ethernet slice for any port number, and even leave
>   alone slices so they can be used for different purposes (GPI).

Networking gives you zero guarantee for an association of the port
numbers (as in ethX) and a particular slice.  Consider the case where a
board is using a PCI network controller and the Titan module is loaded
later - eth0 is already gone.

> - Introduce a general OCD access framework that is designed to be
>   useful for new platform ports.
> 
> I will submit my work work for review once it is completed (since
> I am working on it full time, that should not take too long). Until
> then, I'd like to avoid unnecessary duplication of work, so I am
> announcing this.

Other thing to fix is the driver itself playing with the CIC directly.

Good to know but collisions are likely very limited because the Titan GE
work I did was only small bug fixes.  The one thing which I'm chasing
now is that a recent update from kernel.org import is causing a NFS
hang when booting from NFS.  Interestingly the system will continue after
a few seconds and never hang again.  May be driver related or not.

  Ralf

      reply	other threads:[~2004-11-29 10:31 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-29 10:05 titan_ge etherent driver Thomas Koeller
2004-11-29 10:31 ` Ralf Baechle [this message]

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=20041129103101.GB32075@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=linux-mips@linux-mips.org \
    --cc=mlachwani@mvista.com \
    --cc=thomas.koeller@baslerweb.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox