controllerless pci device support
would it be sensible to write a PCI device interface for controllerless PCI devices like serial PCI ports? I am now trying to make the older 2.2.x series LT winmodem patch into the 2.4.0-test13pre4 sources work. I see how some companies are unable to release all the source code to drivers due to legal reasons and patent restrictions. Maybe there should be a generic driver interface for software modems or other devices, so it is easier to - as an example - write winmodem drivers for the serial driver without hacking in many sets of "#ifdef LUCENT_MODEM. modified code #endif" to the serial.c source file. i am not able to create such a thing, and winmodems are not the most popular thing to talk about in regards to support. after spending 3 hours staring at serial.c, as a beginning programmer, and hand copying the appropriate 2.2.x winnmodem "serial.c" driver code in, i am lost. the module finally compiles, without error, but complains with an error that there is an unresolved symbol "jiffie". kind of funny, a jiffie is all that separates me from turning my brand new laptop into a machine i can use the modem on. also it is equally fustrating. will this situation improve in time or what else can i do to get my modem working? arrrgh! even if the hand-done patching of 2.4.x's serial.c file resulted in a useable kernel module, i would not like to have to patch it every time i update my kernel. a winmodem.o module with support for generic interfaces into the kernel so driver vendors do not need to muck around with serial.c would be an idea. my real question to all is where is the support of PCI serial devices at inside of the kernel? if i have pci bus 0:0.b sharing irq 11 with 0:0.c, does the linux kernel support both devices working at the same time (ethernet, and serial port aka winmodem)? this is probably better off sent to the serial mailing list i know, but i am more interested in whether all the problems i am having with 4 out of 6 devices on my laptop's PCI bus conflicting, whether this is because the linux kernel does not support more than one PCI function operating simultaneously on any given PCI device under the same PCI bus. ( bus:device.function ) right now i get a message that says [IRQ 11 is already used by device 0:8.0] when i load drivers for the device 0:8.1, and the visa-versa message when loading drivers for device 0:8.0. Is this just a warning, or an error? i can't tell. sometimes the driver (as is the case with pcmcia drivers, where slot0 is 0:6.0 and slot1 is 0:6.1) loads anyways, despite the message about [IRQ 11 is alr...]. othertimes, with my ethernet drivers and alsa sound drivers, i see the message and the drivers fail to load. what to do merry holidays, all. i apologize this is long and likely off topic. i mean well though. -Eric Shattow [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
controllerless pci device support
would it be sensible to write a PCI device interface for controllerless PCI devices like serial PCI ports? I am now trying to make the older 2.2.x series LT winmodem patch into the 2.4.0-test13pre4 sources work. I see how some companies are unable to release all the source code to drivers due to legal reasons and patent restrictions. Maybe there should be a generic driver interface for software modems or other devices, so it is easier to - as an example - write winmodem drivers for the serial driver without hacking in many sets of "#ifdef LUCENT_MODEM. modified code #endif" to the serial.c source file. i am not able to create such a thing, and winmodems are not the most popular thing to talk about in regards to support. after spending 3 hours staring at serial.c, as a beginning programmer, and hand copying the appropriate 2.2.x winnmodem "serial.c" driver code in, i am lost. the module finally compiles, without error, but complains with an error that there is an unresolved symbol "jiffie". kind of funny, a jiffie is all that separates me from turning my brand new laptop into a machine i can use the modem on. also it is equally fustrating. will this situation improve in time or what else can i do to get my modem working? arrrgh! even if the hand-done patching of 2.4.x's serial.c file resulted in a useable kernel module, i would not like to have to patch it every time i update my kernel. a winmodem.o module with support for generic interfaces into the kernel so driver vendors do not need to muck around with serial.c would be an idea. my real question to all is where is the support of PCI serial devices at inside of the kernel? if i have pci bus 0:0.b sharing irq 11 with 0:0.c, does the linux kernel support both devices working at the same time (ethernet, and serial port aka winmodem)? this is probably better off sent to the serial mailing list i know, but i am more interested in whether all the problems i am having with 4 out of 6 devices on my laptop's PCI bus conflicting, whether this is because the linux kernel does not support more than one PCI function operating simultaneously on any given PCI device under the same PCI bus. ( bus:device.function ) right now i get a message that says [IRQ 11 is already used by device 0:8.0] when i load drivers for the device 0:8.1, and the visa-versa message when loading drivers for device 0:8.0. Is this just a warning, or an error? i can't tell. sometimes the driver (as is the case with pcmcia drivers, where slot0 is 0:6.0 and slot1 is 0:6.1) loads anyways, despite the message about [IRQ 11 is alr...]. othertimes, with my ethernet drivers and alsa sound drivers, i see the message and the drivers fail to load. what to do merry holidays, all. i apologize this is long and likely off topic. i mean well though. -Eric Shattow [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: devfs names ending in %d or %u
On Sun, 24 Dec 2000, Adam J. Richter wrote: > I propose to change the devfs registration functions > to allow registrations of devices ending in %d or %u, in which > case it will use the first value, starting at 0, that generates a > string that already registered. So, if I have disc0, disc1, and disc2, > and I remove the device containing disc1, then disc1 will be next > disc device name to be registered, then disc3, then disc4, etc. i use devfs for my computers and i agree that the quasi-consistancy of device naming is annoying. my example is with my scsi zip ext. drive. when i insert a FAT formatted disc with a PC partition table, the partition i want to mount is part1. when i insert a HFS formatted disc with a MAC partition table, the partition i want to mount is part4. this is very ugly, having to set up two entries in fstab for the same device. instead of messing around with the naming behavior, why not add configuartion options to the devfsd daemon? they could be per-driver/host/device. maybe i just don't see how to do it with the existing system. in the meantime i am just setting up a /dev/mntsym/ directory that has symlinks "zip" "cdrom" "dvd", etc. when the appropriate modules register, as a quick hack until this is resolved. > This will make it a bit simpler to add devfs support to > the remaining drivers that do not have it, and it will make > numbering within devfs much simpler by default. Of course, drivers > that want to do their own thing the current way would not be impeded > from doing so by this change. it is my opinion that drivers should not have to be too specific about where their representitive /dev entries end up. i don't know enough about internals, but there must be a way to unify the registration of device entries. make the drivers register with the devfs system with the default informations and specifications, and let the devfs system make those dumb null entries or what ever else. it would be yet another layer of abstraction, but it might help make the devfs more flexible. sidenote: i got a new laptop with a serial port and lots of unsupported hardware. i went to work hacking away at what i could. i noticed especially with devfs, that debugging serial port like /dev/tts/0 is impossible if the serial.o driver refuses to load due to an IRQ conflict. if the driver never registers/auto_config's, the /dev/tts entries are not there to use. this is of concern, since some device names should be created regardless of whether the device is loaded or not. without the device entries for serial ports i was not able to give 'setserial' or 'stty' a proper device name for the ports. the PCI standards committee slacked off on the PCI serial spec, it is really weak for standards on devices like modems. the serial port is a (Xircom MPCI 56) Toshiba internal PCI modem 56, a real modem like i always thought would be supported by the serial driver, and yet sits unused like the winmodems i was careful to avoid. that's my dime-and-a-quarter. Eric Shattow [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test11pre2 ram size detect incorrect
I am happy to report that I finally got a 2.4.x kernel booted and running. To get the kernel booting without an oops, I had to use the kernel option "mem=64M" (I have 64 megabytes of ram installed). Aparently, without this option the kernel was detecting an absurdly large amount of installed memory, and thus dereferenced a null pointer. Should i help find out how to get the kernel to recognize the proper amount of memory in my computer without the kernel option? What information should i make available? I am new to actual linux development, and do not know if this is something i should help fix or if it is just something that requires the kernel option. regards to the kernel-hackers, eric shattow [[EMAIL PROTECTED]] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test11pre2 ram size detect incorrect
I am happy to report that I finally got a 2.4.x kernel booted and running. To get the kernel booting without an oops, I had to use the kernel option "mem=64M" (I have 64 megabytes of ram installed). Aparently, without this option the kernel was detecting an absurdly large amount of installed memory, and thus dereferenced a null pointer. Should i help find out how to get the kernel to recognize the proper amount of memory in my computer without the kernel option? What information should i make available? I am new to actual linux development, and do not know if this is something i should help fix or if it is just something that requires the kernel option. regards to the kernel-hackers, eric shattow [[EMAIL PROTECTED]] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
