On Fri, 2013-04-26 at 10:28 -0400, Mark Hounschell wrote: > On 04/26/2013 09:45 AM, Peter Hurley wrote: > > On Fri, 2013-04-26 at 08:58 -0400, Mark Hounschell wrote: > >> On 04/25/2013 05:41 PM, Peter Hurley wrote: > >>> On Wed, 2013-04-24 at 13:44 -0400, Mark Hounschell wrote: > >>>> 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); > >>> > >>> > >> > >> 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 *), > > ^^^^^^^^^^^^^^ > > is this a transcription error? > > Yes, sorry. (MIN(maxminor,256) * sizeof(TERMIOS *) Ok. > > > >> 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. > > > >> 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. > > >> 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? > > >> > >> 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?? > >> > >> 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. > > > 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. Good luck, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
