lkml.org 
[lkml]   [1999]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.069 / U:0.292 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site