linux-mips
[Top] [All Lists]

Re: titan_ge etherent driver

To: Thomas Koeller <thomas.koeller@baslerweb.com>
Subject: Re: titan_ge etherent driver
From: Ralf Baechle <ralf@linux-mips.org>
Date: Mon, 29 Nov 2004 11:31:01 +0100
Cc: linux-mips@linux-mips.org, Manish Lachwani <mlachwani@mvista.com>
In-reply-to: <200411291105.43441.thomas.koeller@baslerweb.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <200411291105.43441.thomas.koeller@baslerweb.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.4.1i
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

<Prev in Thread] Current Thread [Next in Thread>