Out of tree GPL serial tty driver help?

I've been sort of maintaining a couple of Digi International serial port card (XP and AP) drivers for years now because, well, they just won't do it anymore. In any case, I'm moving from a 3.4.x kernel, that works just fine, to a 3.8.8 kernel, that does not. I have code that does something like this:

     tty_set_operations(&SerialDriver, &SerialOps);
     tty_register_driver(&SerialDriver);
     maxminor = NumBoards * 64;
     for (i = 0; i < maxminor; i++)
         tty_register_device(&SerialDriver, i, NULL);

Quoted 11 lines · Mark Hounschell

I've been sort of maintaining a couple of Digi International serial port card (XP and AP) drivers for years now because, well, they just won't do it anymore. In any case, I'm moving from a 3.4.x kernel, that works just fine, to a 3.8.8 kernel, that does not. I have code that does something like this:

      tty_set_operations(&SerialDriver, &SerialOps);
      tty_register_driver(&SerialDriver);
      maxminor = NumBoards * 64;
      for (i = 0; i < maxminor; i++)
          tty_register_device(&SerialDriver, i, NULL);

You're correct in diagnosing the problem to cdevs == NULL. You're missing:

	maxminor = min(num_boards * 64, 256);
	serial_driver = alloc_tty_driver(maxminor);

then,

	/* Fill in pertinent tty_driver fields, esp. */
	serial_driver->flags = TTY_DRIVER_DYNAMIC_DEV;

	tty_set_operations(serial_driver, &serial_ops);
	tty_register_driver(serial_driver);
	for (i = 0; i < maxminor; i++)
		tty_register_device(serial_driver, i, NULL);

PS - Each board supports 64 individual serial ports??

Quoted 19 lines · Peter Hurley

Quoted 11 lines · Mark Hounschell

I've been sort of maintaining a couple of Digi International serial port card (XP and AP) drivers for years now because, well, they just won't do it anymore. In any case, I'm moving from a 3.4.x kernel, that works just fine, to a 3.8.8 kernel, that does not. I have code that does something like this:

      tty_set_operations(&SerialDriver, &SerialOps);
      tty_register_driver(&SerialDriver);
      maxminor = NumBoards * 64;
      for (i = 0; i < maxminor; i++)
          tty_register_device(&SerialDriver, i, NULL);

You're correct in diagnosing the problem to cdevs == NULL. You're missing:

	maxminor = min(num_boards * 64, 256);
	serial_driver = alloc_tty_driver(maxminor);

Quoted 10 lines

then,

	/* Fill in pertinent tty_driver fields, esp. */
	serial_driver->flags = TTY_DRIVER_DYNAMIC_DEV;

	tty_set_operations(serial_driver, &serial_ops);
	tty_register_driver(serial_driver);
	for (i = 0; i < maxminor; i++)
		tty_register_device(serial_driver, i, NULL);

Thanks for responding Peter.

Earlier in the code they do this:

static struct tty_driver SerialDriver
and things like
SerialDriver.termios = kmalloc((maxminor - 256) * sizeof(TERMIOS *),

GFP_KERNEL);

So is the above no longer going to work and I _must_ now use alloc_tty_driver?

If alloc_tty_driver is now a requirement, how much is
it going to do for me? There are several things like the termios above that are manually allocated. How much if any of this is alloc_tty_driver going to do for me?

or might this work

static struct tty_driver SerialDriver
.
.
.
serial_driver.flags = TTY_DRIVER_DYNAMIC_DEV;

SerialDriver.cdevs = kcalloc(maxminor,
sizeof(SerialDriver.cdevs), GFP_KERNEL);

  	tty_set_operations(&serial_driver, &serial_ops);
  	tty_register_driver(&serial_driver);
  	for (i = 0; i < maxminor; i++)
  		tty_register_device(&serial_driver, i, NULL);

???

Quoted 1 line

Quoted 1 line

PS - Each board supports 64 individual serial ports??

No, this particular card comes in 4, 8, and 16 port flavors. I never did understand why they create so many device entries. I just figured they had a reason. For a single card, no matter how many ports, they create 64 normal serial tty entries (tty_dgdm_G0 - tty_dgdm_G63), 64 serial printer entries (lp_dgdm_G0 - lp_dgdm_G63), and then 64 serial modem entries (cu_dgdm_G0 - cu_dgdm_G63). Don't know why.

Quoted 33 lines · Mark Hounschell

Quoted 19 lines · Peter Hurley

Quoted 11 lines · Mark Hounschell

I've been sort of maintaining a couple of Digi International serial port card (XP and AP) drivers for years now because, well, they just won't do it anymore. In any case, I'm moving from a 3.4.x kernel, that works just fine, to a 3.8.8 kernel, that does not. I have code that does something like this:

       tty_set_operations(&SerialDriver, &SerialOps);
       tty_register_driver(&SerialDriver);
       maxminor = NumBoards * 64;
       for (i = 0; i < maxminor; i++)
           tty_register_device(&SerialDriver, i, NULL);

You're correct in diagnosing the problem to cdevs == NULL. You're missing:

	maxminor = min(num_boards * 64, 256);
	serial_driver = alloc_tty_driver(maxminor);

Quoted 10 lines

then,

	/* Fill in pertinent tty_driver fields, esp. */
	serial_driver->flags = TTY_DRIVER_DYNAMIC_DEV;

	tty_set_operations(serial_driver, &serial_ops);
	tty_register_driver(serial_driver);
	for (i = 0; i < maxminor; i++)
		tty_register_device(serial_driver, i, NULL);

Thanks for responding Peter.

Quoted 5 lines

Earlier in the code they do this:

static struct tty_driver SerialDriver
and things like
SerialDriver.termios = kmalloc((maxminor - 256) * sizeof(TERMIOS *),

^^^^^^^^^^^^^^
is this a transcription error?

Quoted 5 lines

GFP_KERNEL);

So is the above no longer going to work and I _must_ now use alloc_tty_driver?

Not required but functionally equivalent. alloc_tty_driver() is actually a wrapper macro which calls __tty_alloc_driver(). You can verify your driver behavior against that function, if you want.

Quoted 4 lines

If alloc_tty_driver is now a requirement, how much is
it going to do for me? There are several things like the termios above that are manually allocated. How much if any of this is alloc_tty_driver going to do for me?

I can't answer this because I don't know what else your open-coded method is doing.

Quoted 10 lines

or might this work

static struct tty_driver SerialDriver
.
.
.
serial_driver.flags = TTY_DRIVER_DYNAMIC_DEV;

SerialDriver.cdevs = kcalloc(maxminor,
sizeof(SerialDriver.cdevs), GFP_KERNEL);

Quoted 11 lines

   	tty_set_operations(&serial_driver, &serial_ops);
   	tty_register_driver(&serial_driver);
   	for (i = 0; i < maxminor; i++)
   		tty_register_device(&serial_driver, i, NULL);

???

Quoted 2 lines

PS - Each board supports 64 individual serial ports??

Quoted 6 lines

No, this particular card comes in 4, 8, and 16 port flavors. I never did understand why they create so many device entries. I just figured they had a reason. For a single card, no matter how many ports, they create 64 normal serial tty entries (tty_dgdm_G0 - tty_dgdm_G63), 64 serial printer entries (lp_dgdm_G0 - lp_dgdm_G63), and then 64 serial modem entries (cu_dgdm_G0 - cu_dgdm_G63). Don't know why.

So where does i/o go for tty_dgdm_G16?

Also, what host bus are these cards for?

This particular driver and one other are normal PCI based cards. I also have one other that is PCI-e. This particular one is the only one that creates all these weird device entries. The other 2 are pretty straight forward. One entry per port. I figured I'd tackle this one first.

Quoted 5 lines · Mark Hounschell

This particular driver and one other are normal PCI based cards. I also have one other that is PCI-e. This particular one is the only one that creates all these weird device entries. The other 2 are pretty straight forward. One entry per port. I figured I'd tackle this one first.

I would remove those other "weird" device entries from the driver, we removed those types of device nodes from the kernel tree many many years ago. Just stick to one device node per port, and all should be fine.

Also, any reason why these drivers aren't in the main kernel tree? If they were, all of this work would have been done for you :)

Quoted 3 lines

Also, any reason why these drivers aren't in the main kernel tree? If they were, all of this work would have been done for you :)

Yes, I wish they were in the kernel. I've had to maintain them since the 2.6 days because Digi just won't do it and their cards do what we need quite well and are still current products. Ya, you can buy a brand new one but the latest kernel supported is 2.6. I think Digi at one point long ago may have tried the "in kernel" route but you probably know more about that than I do.

Since 2.6, the maintenance on these hasn't been to bad, until udev came along. But I guess after 3.4 the tty layer is going through quite some changes that I have yet to understand.

Actually, we also have 3-4 of our own "out of kernel" GPL drivers that I would love to see in the kernel. They are mature and only require changes when something in the kernel changes. That's another story though.

Quoted 11 lines · Mark Hounschell

Quoted 3 lines

Also, any reason why these drivers aren't in the main kernel tree? If they were, all of this work would have been done for you :)

Yes, I wish they were in the kernel. I've had to maintain them since the 2.6 days because Digi just won't do it and their cards do what we need quite well and are still current products. Ya, you can buy a brand new one but the latest kernel supported is 2.6. I think Digi at one point long ago may have tried the "in kernel" route but you probably know more about that than I do.

Quoted 3 lines

Since 2.6, the maintenance on these hasn't been to bad, until udev came along. But I guess after 3.4 the tty layer is going through quite some changes that I have yet to understand.

And there will be lots more changes happening to it in the future. Why not submit the drivers now (after you get them working)?

Quoted 12 lines · Greg KH

Quoted 11 lines · Mark Hounschell

Quoted 3 lines

Also, any reason why these drivers aren't in the main kernel tree? If they were, all of this work would have been done for you :)

Yes, I wish they were in the kernel. I've had to maintain them since the 2.6 days because Digi just won't do it and their cards do what we need quite well and are still current products. Ya, you can buy a brand new one but the latest kernel supported is 2.6. I think Digi at one point long ago may have tried the "in kernel" route but you probably know more about that than I do.

Quoted 6 lines

Quoted 3 lines

Since 2.6, the maintenance on these hasn't been to bad, until udev came along. But I guess after 3.4 the tty layer is going through quite some changes that I have yet to understand.

And there will be lots more changes happening to it in the future. Why not submit the drivers now (after you get them working)?

Probably not Mark's (or Compro's) code to submit.

Quoted 20 lines · Peter Hurley

Quoted 18 lines · Greg KH

Quoted 11 lines · Mark Hounschell

Quoted 3 lines

Also, any reason why these drivers aren't in the main kernel tree? If they were, all of this work would have been done for you :)

Yes, I wish they were in the kernel. I've had to maintain them since the 2.6 days because Digi just won't do it and their cards do what we need quite well and are still current products. Ya, you can buy a brand new one but the latest kernel supported is 2.6. I think Digi at one point long ago may have tried the "in kernel" route but you probably know more about that than I do.

Quoted 3 lines

Since 2.6, the maintenance on these hasn't been to bad, until udev came along. But I guess after 3.4 the tty layer is going through quite some changes that I have yet to understand.

And there will be lots more changes happening to it in the future. Why not submit the drivers now (after you get them working)?

Quoted 1 line

Probably not Mark's (or Compro's) code to submit.

If it's a GPL driver, anyone can submit it.

However, if the original copyright owner doesn't want it to be submitted, we will be glad to take that under consideration.

Mark, what's the reason this has never been submitted?

As for the Digi card driver/drivers, I can't say why not. There is a remnant of the actual one this thread is pertaining to in ./Documentation/serial/digiepca.txt. I've never submitted it or any of their others I have to maintain because I didn't know I could nor would know how to start. I thought that Digi would have had to do it.

As far as Compro's drivers go, I think we have just been a little wary/unknowing of what it would take and what the results of the effort would actually be. Would they still do what _we_ needed them to do? Are we kernel savvy enough to get them to a state you would accept? etc... We do understand that if they were in the kernel that the best qualified people would be the ones that "kept them current" with the latest kernel changes. It's certainly something that no one here would object to doing. Are you the man to talk to? What is the actual process?

Quoted 36 lines · Peter Hurley

Quoted 35 lines · Mark Hounschell

Quoted 19 lines · Peter Hurley

Quoted 11 lines · Mark Hounschell

I've been sort of maintaining a couple of Digi International serial port card (XP and AP) drivers for years now because, well, they just won't do it anymore. In any case, I'm moving from a 3.4.x kernel, that works just fine, to a 3.8.8 kernel, that does not. I have code that does something like this:

       tty_set_operations(&SerialDriver, &SerialOps);
       tty_register_driver(&SerialDriver);
       maxminor = NumBoards * 64;
       for (i = 0; i < maxminor; i++)
           tty_register_device(&SerialDriver, i, NULL);

You're correct in diagnosing the problem to cdevs == NULL. You're missing:

	maxminor = min(num_boards * 64, 256);
	serial_driver = alloc_tty_driver(maxminor);

Quoted 10 lines

then,

	/* Fill in pertinent tty_driver fields, esp. */
	serial_driver->flags = TTY_DRIVER_DYNAMIC_DEV;

	tty_set_operations(serial_driver, &serial_ops);
	tty_register_driver(serial_driver);
	for (i = 0; i < maxminor; i++)
		tty_register_device(serial_driver, i, NULL);

Thanks for responding Peter.

Earlier in the code they do this:

Quoted 5 lines

Quoted 3 lines

static struct tty_driver SerialDriver
and things like
SerialDriver.termios = kmalloc((maxminor - 256) * sizeof(TERMIOS *),

^^^^^^^^^^^^^^
is this a transcription error?

Yes, sorry. (MIN(maxminor,256) * sizeof(TERMIOS *)

Quoted 10 lines

Quoted 5 lines

GFP_KERNEL);

So is the above no longer going to work and I _must_ now use alloc_tty_driver?

Not required but functionally equivalent. alloc_tty_driver() is actually a wrapper macro which calls __tty_alloc_driver(). You can verify your driver behavior against that function, if you want.

Quoted 8 lines

Quoted 4 lines

If alloc_tty_driver is now a requirement, how much is
it going to do for me? There are several things like the termios above that are manually allocated. How much if any of this is alloc_tty_driver going to do for me?

I can't answer this because I don't know what else your open-coded method is doing.

Looking at __tty_alloc_driver, it looks as though only driver, cdevs and ports are provided.

Quoted 10 lines

Quoted 10 lines

or might this work

static struct tty_driver SerialDriver
.
.
.
serial_driver.flags = TTY_DRIVER_DYNAMIC_DEV;

SerialDriver.cdevs = kcalloc(maxminor,
sizeof(SerialDriver.cdevs), GFP_KERNEL);

So might something like the above for cdevs and ports get me where I need to be?

Quoted 11 lines

Quoted 11 lines

   	tty_set_operations(&serial_driver, &serial_ops);
   	tty_register_driver(&serial_driver);
   	for (i = 0; i < maxminor; i++)
   		tty_register_device(&serial_driver, i, NULL);

???

Quoted 2 lines

PS - Each board supports 64 individual serial ports??

Quoted 9 lines

Quoted 6 lines

No, this particular card comes in 4, 8, and 16 port flavors. I never did understand why they create so many device entries. I just figured they had a reason. For a single card, no matter how many ports, they create 64 normal serial tty entries (tty_dgdm_G0 - tty_dgdm_G63), 64 serial printer entries (lp_dgdm_G0 - lp_dgdm_G63), and then 64 serial modem entries (cu_dgdm_G0 - cu_dgdm_G63). Don't know why.

So where does i/o go for tty_dgdm_G16?

I have no idea. I do know that G0 - G7 are the ones I actually use for ports 0-7 of an 8 port card-0, and
G64 - G71 are the ones I use for ports 0-7 of an 8 port card-1. I remember long ago I had some doc explaining this but can't seem to find it now.

Quoted 2 lines

Also, what host bus are these cards for?

This particular driver and one other are normal PCI based cards. I also have one other that is PCI-e. This particular one is the only one that creates all these weird device entries. The other 2 are pretty straight forward. One entry per port. I figured I'd tackle this one first.

Quoted 37 lines · Mark Hounschell

Quoted 36 lines · Peter Hurley

Quoted 35 lines · Mark Hounschell

Quoted 19 lines · Peter Hurley

Quoted 11 lines · Mark Hounschell

I've been sort of maintaining a couple of Digi International serial port card (XP and AP) drivers for years now because, well, they just won't do it anymore. In any case, I'm moving from a 3.4.x kernel, that works just fine, to a 3.8.8 kernel, that does not. I have code that does something like this:

        tty_set_operations(&SerialDriver, &SerialOps);
        tty_register_driver(&SerialDriver);
        maxminor = NumBoards * 64;
        for (i = 0; i < maxminor; i++)
            tty_register_device(&SerialDriver, i, NULL);

You're correct in diagnosing the problem to cdevs == NULL. You're missing:

	maxminor = min(num_boards * 64, 256);
	serial_driver = alloc_tty_driver(maxminor);

Quoted 10 lines

then,

	/* Fill in pertinent tty_driver fields, esp. */
	serial_driver->flags = TTY_DRIVER_DYNAMIC_DEV;

	tty_set_operations(serial_driver, &serial_ops);
	tty_register_driver(serial_driver);
	for (i = 0; i < maxminor; i++)
		tty_register_device(serial_driver, i, NULL);

Thanks for responding Peter.

Earlier in the code they do this:

Quoted 7 lines

Quoted 5 lines

Quoted 3 lines

static struct tty_driver SerialDriver
and things like
SerialDriver.termios = kmalloc((maxminor - 256) * sizeof(TERMIOS *),

^^^^^^^^^^^^^^
is this a transcription error?

Yes, sorry. (MIN(maxminor,256) * sizeof(TERMIOS *)

Ok.

Quoted 63 lines

Quoted 10 lines

Quoted 5 lines

GFP_KERNEL);

So is the above no longer going to work and I _must_ now use alloc_tty_driver?

Not required but functionally equivalent. alloc_tty_driver() is actually a wrapper macro which calls __tty_alloc_driver(). You can verify your driver behavior against that function, if you want.

Quoted 8 lines

Quoted 4 lines

If alloc_tty_driver is now a requirement, how much is
it going to do for me? There are several things like the termios above that are manually allocated. How much if any of this is alloc_tty_driver going to do for me?

I can't answer this because I don't know what else your open-coded method is doing.

Looking at __tty_alloc_driver, it looks as though only driver, cdevs and ports are provided.

Quoted 10 lines

Quoted 10 lines

or might this work

static struct tty_driver SerialDriver
.
.
.
serial_driver.flags = TTY_DRIVER_DYNAMIC_DEV;

SerialDriver.cdevs = kcalloc(maxminor,
sizeof(SerialDriver.cdevs), GFP_KERNEL);

So might something like the above for cdevs and ports get me where I need to be?

Quoted 11 lines

Quoted 11 lines

    	tty_set_operations(&serial_driver, &serial_ops);
    	tty_register_driver(&serial_driver);
    	for (i = 0; i < maxminor; i++)
    		tty_register_device(&serial_driver, i, NULL);

???

Quoted 2 lines

PS - Each board supports 64 individual serial ports??

Quoted 9 lines

Quoted 6 lines

No, this particular card comes in 4, 8, and 16 port flavors. I never did understand why they create so many device entries. I just figured they had a reason. For a single card, no matter how many ports, they create 64 normal serial tty entries (tty_dgdm_G0 - tty_dgdm_G63), 64 serial printer entries (lp_dgdm_G0 - lp_dgdm_G63), and then 64 serial modem entries (cu_dgdm_G0 - cu_dgdm_G63). Don't know why.

So where does i/o go for tty_dgdm_G16?

I have no idea. I do know that G0 - G7 are the ones I actually use for ports 0-7 of an 8 port card-0, and
G64 - G71 are the ones I use for ports 0-7 of an 8 port card-1. I remember long ago I had some doc explaining this but can't seem to find it now.

Quoted 7 lines

Quoted 2 lines

Also, what host bus are these cards for?

This particular driver and one other are normal PCI based cards. I also have one other that is PCI-e. This particular one is the only one that creates all these weird device entries. The other 2 are pretty straight forward. One entry per port. I figured I'd tackle this one first.

Ok. Looking at Digi's website, I see they have external port concentrators. That would explain the fixed 64-port allocation (although that's not really how to do it).

These drivers weren't really current at 3.4 though, either. I'm not sure what else you're going to find that doesn't work.

For both PCI and PCI-e, these drivers should _at a minimum_ be pci drivers that register the tty driver at module init and register _only_ the tty devices for that particular PCI device at PCI probe time. Look at the end of synclink_gt.c for how this is supposed to look.

Quoted 3 lines · Peter Hurley

These drivers weren't really current at 3.4 though, either. I'm not sure what else you're going to find that doesn't work.

No, I have kept them current, or I should say functional, to the best of my ability from 2.6 up to and including 3.4.x.

What I have here works
with kernels up to 3.4.x. I have not tried anything between 3.4 and 3.8.
As far as building against 3.8, the only issues were the change from
*termios to termios and the "structn_tty_data" no longer in an include file so not easily directly accessible.

Quoted 5 lines

For both PCI and PCI-e, these drivers should _at a minimum_ be pci drivers that register the tty driver at module init and register _only_ the tty devices for that particular PCI device at PCI probe time. Look at the end of synclink_gt.c for how this is supposed to look.

I'll look at it some more but I have been there.

Quoted 7 lines · Mark Hounschell

Quoted 3 lines · Peter Hurley

These drivers weren't really current at 3.4 though, either. I'm not sure what else you're going to find that doesn't work.

No, I have kept them current, or I should say functional, to the best of my ability from 2.6 up to and including 3.4.x.

By 'current', I mean 'similar in structure and functionality to in-tree drivers'.

The structure of this driver is more akin to a 2.5 driver (back when there were separate serial and callout tty drivers).

Quoted 5 lines

What I have here works
with kernels up to 3.4.x. I have not tried anything between 3.4 and 3.8.
As far as building against 3.8, the only issues were the change from
*termios to termios and the "structn_tty_data" no longer in an include file so not easily directly accessible.

What is this driver accessing in N_TTY's private data?

Quoted 7 lines

Quoted 5 lines

For both PCI and PCI-e, these drivers should _at a minimum_ be pci drivers that register the tty driver at module init and register _only_ the tty devices for that particular PCI device at PCI probe time. Look at the end of synclink_gt.c for how this is supposed to look.

I'll look at it some more but I have been there.

Specifically, review:

	struct pci_driver
	device_init()
	init_one()
	remove_one()
	sglt_init()
	sglt_exit()

Quoted 15 lines · Peter Hurley

Quoted 7 lines · Mark Hounschell

Quoted 3 lines · Peter Hurley

These drivers weren't really current at 3.4 though, either. I'm not sure what else you're going to find that doesn't work.

No, I have kept them current, or I should say functional, to the best of my ability from 2.6 up to and including 3.4.x.

By 'current', I mean 'similar in structure and functionality to in-tree drivers'.

The structure of this driver is more akin to a 2.5 driver (back when there were separate serial and callout tty drivers).

Quoted 7 lines

Quoted 5 lines

What I have here works
with kernels up to 3.4.x. I have not tried anything between 3.4 and 3.8.
As far as building against 3.8, the only issues were the change from
*termios to termios and the "structn_tty_data" no longer in an include file so not easily directly accessible.

What is this driver accessing in N_TTY's private data?

         /* Decide how much data we can send into the tty layer */
         if(dgdm_rawreadok && tty->real_raw)
                 flip_len = MYFLIPLEN;
         else
                 flip_len = TTY_FLIPBUF_SIZE;
         len = MIN(data_len, flip_len);
         len = MIN(len, (N_TTY_BUF_SIZE - 1) - tty->read_cnt);
         dxb_return_fixed_cost(dxb, channel, 1);
         ld = tty_ldisc_ref(tty);

.
.
.
.

                 /*
                  * In high performance mode, we don't have to update
                  * flag_buf or any of the counts or pointers into flip buf.
                  */
                 if(!dgdm_rawreadok || !tty->real_raw) {
                         if (I_PARMRK(tty) || I_BRKINT(tty) || 
I_INPCK(tty)) {
                                 parity_scan(dc, myflipbuf[boardnum],
                                         myflipflagbuf[boardnum], &len);
                         } else {
                                 memset(myflipflagbuf[boardnum], 
TTY_NORMAL, len);
                         }
                 }

.
.
.
.
/*
* If we're doing raw reads, jam it right into the
* line disc bypassing the flip buffers.
* OPT OPP: do this only once per channel instead of
* once per dxb message.
*/
if(dgdm_rawreadok && tty->real_raw) {
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,27)

#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,30)
                         tty->ldisc->ops->receive_buf(tty, 
myflipbuf[boardnum], NULL, len);
#else
                         tty->ldisc.ops->receive_buf(tty, 
myflipbuf[boardnum], NULL, len);
#endif
#else
                         tty->ldisc.receive_buf(tty, 
myflipbuf[boardnum], NULL, len);
#endif
                 } else {
                         len = tty_buffer_request_room(tty, len);
                         tty_insert_flip_string_flags(tty, 
myflipbuf[boardnum],
                                 myflipflagbuf[boardnum], len);

                         /* Tell the tty layer its okay to "eat" the 
data now */
                         tty_flip_buffer_push(tty);
                 }
.
.
.
         /*
          * Just go ahead and try to read some data into the flip buffer.
          * If there isn't any data available, dxb_rxbuf_read will return
          * 0 back to us right away.
          *
          * The dgdm_rawreadok case takes advantage of carnal knowldge that
          * the char_buf and the flag_buf are next to each other and
          * are each of (2 * TTY_FLIPBUF_SIZE) size.
          */

         if(dgdm_rawreadok && tty->real_raw)
                 flip_len = MYFLIPLEN;
         else
                 flip_len = TTY_FLIPBUF_SIZE;

         flip_len = MIN(flip_len, (N_TTY_BUF_SIZE - 1) - tty->read_cnt);

         len = dxb_rxbuf_read(brd->dxb, dc->dxbchan, 

myflipbuf[boardnum], flip_len);

etc...

Looks like for hopes of performance????

Quoted 8 lines

Quoted 7 lines

Quoted 5 lines

For both PCI and PCI-e, these drivers should _at a minimum_ be pci drivers that register the tty driver at module init and register _only_ the tty devices for that particular PCI device at PCI probe time. Look at the end of synclink_gt.c for how this is supposed to look.

I'll look at it some more but I have been there.

Quoted 8 lines

Specifically, review:

	struct pci_driver
	device_init()
	init_one()
	remove_one()
	sglt_init()
	sglt_exit()

Ok, I'll will look more closely at these to try to understand what should be done.