In message <Pine.SOL.3.96.1000207102332.11519B-100000@marcy.nas.nasa.gov>Bill S
tudenmund writes

>"low" and "high" are confusing in RS-232. Since a "1" is a voltage lower
>than -3 V, and a "0" is one over +3, "active low" is rather ambiguous.

Yep.  That's why the PPS-API uses "assert" and "clear".  The I-D was
trying to avoid that ambiguity.  Guess it didn't work so well.

>I think what the chips do is that a "1" in the status register means
>logically asserted.

Thats what I found by carefully removing and re-inserting the serial
cable to a ricochet.

>> But yep, thats one reason I left the sc_msr_mask alone.  The other is
>> that I think the com driver takes interrupts for DCD changes even if
>> MSR_DCD is off in sc_msr_mask.
>
>Then that's a difference between the drivers. The zs driver only asserts
>interrupts for the bits set in cs_rr0_mask.

OK.  My guess is that DCD is unlikley to waggle often enough to
cause a significant interupt load -- certainly not for PPS --
but maybe its worth looking into.

BTW, the sys/dev/ic/com.c code in today's sup worked for me, both when
the line discipline set CLOCAL (via tip) and when it didn't, so it
should work with a real PPS clock.


Hm.  How should we handle someone trying to enable PPS on a line with
MDMBUF set, or vice-versa?  Return an error, but EBUSY, or EINVAL?