Re: High speed serial ports

Pavel Machek (pavel@bug.ucw.cz)
Tue, 11 May 1999 20:32:40 +0200


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/