titan_ge etherent driver

titan_ge etherent driver

[Thomas Koeller]

Hi Ralf,

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

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

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

tk
-- 
--------------------------------------------------

Thomas Koeller, Software Development
Basler Vision Technologies

thomas dot koeller at baslerweb dot com
http://www.baslerweb.com

==============================

Re: titan_ge etherent driver

[Ralf Baechle]

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