Krzysztof and Ueimor,
Following the advice prescribed below, I've had a look at existing
HDLC work in the kernel. I tried firing up a Riscom/N2 adapter with the
2.4.28 N2 module and HDLC support but was faced with a number of problems.
It seems like the transmit buffers aren't getting emptied after transmit,
because I can only transmit a few frames before traffic halts. Transmit
statistics don't increment either, but I am seeing frames on the remote end.
Has the N2 module been tested with recent kernels? Is it useable?
If not, which module will show me the genius of the Linux HDLC "stack"?
-AA
-----Original Message-----
From: Francois Romieu [mailto:[email protected]]
Sent: Monday, January 10, 2005 1:01 PM
To: Adam Anthony
Cc: [email protected]; [email protected]
Subject: Re: [PATCH] /driver/net/wan/sbs520
Adam Anthony <[email protected]> :
[...]
> It would be great to receive some feedback on our work, and we hope
> that this driver will eventually be added to the kernel.
It will probably require a few extra steps:
- read Documentation/CodingStyle (mixed case, typedef from hell, ugly
#ifdef);
- grep ^static
-> no static functions ? Uh ?
- use non-obsolete API (pci_find_device in 2005 ?);
- convert the os independant wrappers.
Btw it would probably make sense 1) to figure out what can be merged with
the in-tree DSCC4 driver and 2) to integrate the driver with the existing
hdlc stack. Imho there is some duplicated work/code.
--
Ueimor
***This message has been scanned for virus, spam, and undesirable
content.***
***For further information, contact your mail administrator.***
For limitations on the use and distribution of this message, please visit http://www.sbs.com/emaildisclaimer.
Adam Anthony <[email protected]> :
[...]
> It seems like the transmit buffers aren't getting emptied after transmit,
> because I can only transmit a few frames before traffic halts. Transmit
> statistics don't increment either, but I am seeing frames on the remote end.
> Has the N2 module been tested with recent kernels? Is it useable?
No idea.
> If not, which module will show me the genius of the Linux HDLC "stack"?
struct foo_dev_priv {
/*
Device private stuff here
*/
...
struct net_device *dev;
}
...
static int foo_init_one(...)
{
struct foo_dev_priv *priv;
struct net_device *dev;
hdlc_device *hdlc;
priv = kmalloc(sizeof(*priv), GFP_KERNEL);
if (!priv)
goto damn_it;
memset(priv, 0, ...);
dev = alloc_hdlcdev(priv);
if (!dev)
goto crap;
memset(dev, 0, ...);
priv->dev = dev;
hdlc = dev_to_hdlc(dev);
hdlc->xmit = foo_start_xmit();
hdlc->attach = foo_hdlc_attach();
ret = register_hdlc_device(hdlc);
if (ret < 0)
goto not_my_day;
...
}
static int foo_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
/* The usual linux hard_start_xmit() handler of a net_device */
...
}
unregister_hdlc_device() balances register_hdlc_device().
hdlc_to_dev(hdlc) is the counterpart of dev_to_hdlc(dev).
Impressing, is not it ?
--
Ueimor
Adam Anthony <[email protected]> writes:
> Krzysztof and Ueimor,
> Following the advice prescribed below, I've had a look at existing
> HDLC work in the kernel. I tried firing up a Riscom/N2 adapter with the
> 2.4.28 N2 module and HDLC support but was faced with a number of problems.
> It seems like the transmit buffers aren't getting emptied after transmit,
> because I can only transmit a few frames before traffic halts. Transmit
> statistics don't increment either, but I am seeing frames on the remote end.
Looks like IRQ problem. Can you see IRQ handler being called?
I.e. doesn the counter in /proc/interrupts increment?
> Has the N2 module been tested with recent kernels? Is it useable?
It should be, though I haven't used N2 card for a year maybe.
Still, other cards (c101 and pci200syn) share the same low-level
driver core, I know people with c101 (not sure about their kernel
versions) and I personally use pci200syn with latest 2.6 kernels.
There are some issues wrt Frame-Relay code (no PVC list locking,
there is some small possibility of kernel panic etc. while removing
a PVC on live interface - will fix when time permits, problem never
reported).
--
Krzysztof Halasa