Messages in this thread | | | Date | Tue, 11 May 1999 20:32:40 +0200 | From | Pavel Machek <> | Subject | Re: High speed serial ports |
| |
Hi!
> PS: tytso, is there chance for this to be included in next version? Is > this still too dirty? (Well, do not look at #warning, if you say it > looks good I'm sure I can find a way for it to go away...) > > It's definitely a lot, a lot better. A couple of questions, though: > > 1) How common are these boards/chipsets. (i.e., how is it worth it to > spend a lot of time making the autodetection/probe safe so it can be > always enabled, or do we expect to force people to recompile the kernel > in order to be able to use this feature?)
Very common. Nearly everything build these days supports IrDA and nearly everything supporting IrDA can do much better than 115k200.
> 2) How safe is it to do the probing on a machine which doesn't have > these boards. (i.e., Can it accidentally cause SCSI controllers to start > doing low-level formats on some systems. :-)
I do not know...
> 3) Is the probing instructions timing sensitive? i.e., can we do all > of this in a user-mode program, and if it succeeds in enabling the > high-speed port, just simply use the standard ioctl to set the > baud_base, and thus not requiring any serial driver changes at all. > This has the advantage of not loading down kernel memory with one-time > initialization code. It also means that all of these tables can be > more easily updated, and kept separate from the kernel, which would be a > good thing. It also satisfies a concern I have about what to do when > the next motherboard/chipset manufacture comes along, needing to do the > same thing but in a subtlely incompatible manner.... basically, this is > a scaling issue.
From my experiments with pc87108, it worked even from userspace. I think modern hardware is clean enough not to be timing critical...
> 4) If we can't do this, why not put most of hispeed.c under an > __initfunc(), and simply enable all of the board to the hispeed divisor, > and then set the baud_base to the appropriate value, all at boot time. > Then all of this memory can be thrown away after the kernel initializes > itself, and if we're sure that the probing code is safe to run on all > machines, maybe we don't even need to make it a CONFIG option.
Yes, this would be nice. Initfuncting it is certainly not a problem.
Pavel -- I'm really pavel@ucw.cz. Look at http://195.113.31.123/~pavel. Pavel Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |