> BOCA make a very poorly documented unintelligent serial card, they call 
> the ioAT66, with six 16550-look-alike UARTS.
> 
> I have modified the existing BOCA driver for this particular card, and, 
> within certain restrictions into which I will delve below, it seems to 
> work correctly.
> 
> Is there any interest out there for this particular driver?  I managed 
> to streamline some of the existing code, possibly not to any great 
> degree, and it may be worth retrofitting the changes to the other 
> multiport card drivers...  Let me know, anyone.

It'd probably be a good driver to have. You should probably (if you haven't
already) look at the existing boca driver.

> Now for some of the issues that were raised, probably through too 
> little understanding on my part of how device drivers and the CONFIG 
> utility are meant to interact:

[snip]

> Now, all this being said, I could not determine how to write the driver 
> so that, between the actual adapter settings and the contents of the 
> CONFIG file, it would be possible to use each port, irrespective of how 
> it was configured.  The potential pitfalls are:
> 
> (a) The device driver has no mechanism to discriminate between standard 
> COM ports and those on the adapter it services.  If the driver attempts 
> to service COM1 and it is not an adapter port, it will fail to do so 
> because the interrupt indicator flag in the STATUS register for that 
> port will not be set.  Unless the NetBSD kernel chains interrupt 
> handlers so that the correct handler is called on such a failure, the 
> standard UART ports will become unusable.  And this presupposes that 
> the conventional handler was configured correctly, earlier - 
> another possibility is to include the standard ports in the ioAT66 
> driver, trigger interrupts at probe time, determine which cause the 
> STATUS register to report and which don't and attach two slightly 
> different interrupt handlers to the two different groups.

Support for multi-function serial cards is not present in GENERIC kernels
by default. So the user had to compile in this driver. I'd say you can
trust the configuration info you're given.

> (b) Only with such convoluted probing is it possible to determine the 
> actual adapter configuration, and here is the point: I chose to make 
> certain assumptions about the configuration of the adapter, so as to 
> minimise the likelihood of misconfigurations.  The first assumption is 
> that conventional ports are paired with (nearly) conventional IRQs: 
> COM1 and COM2 are taken to be standard, COM3 and COM4 nearly so, and 
> COM5 and COM6 merely extrapolate on this.  The alternate ports are all 
> taken to use the chosen shared IRQ and aren't even considered for 
> probing if the IRQ specification in the configuration is left out.  The 
> alternative port is tested first, making it possible for other drivers 
> to manage the conventional ports if they are excluded on the adapter.

I'd say just let the user's configuration tell you what to do.

> (c) Any number of adapter configuration can trash this scheme, for 
> example, to match a current configuration, the third port would have to 
> be set up as 0x248/5 instead of 0x2E8/5, the latter would be forced to 
> 0x2E8/11 and clash.
> 
> (d) The only alternative would be to find some means of describing in 
> the CONFIG file, the properties of individual slaves, not so much their 
> I/O address, where the choices are limited and mutually exclusive, but 
> the rather the selected IRQ (god forbid that this should then be wrong 
> :-(

But that sounds like the best thing to do. You can specify location
information for the slaves, and you should be able to set things up so
you can specify the interrupt used by the slave.

> In summary, there are two options: a more complex mechanism to describe 
> adapters (I guess that's where PnP was meant to help) or the ability to 
> perform rather complex tests, including triggering and intercepting 
> interrupts, at adapter probing time.  I think the former option 
> stretches into dangerous territory, while the latter could provide 
> additional robustness to other drivers.  I'm not comfortable with 
> exploring this avenue, but with sufficient encouragment and support, I 
> may embark on it.

I think a richer description of the slaves is in order. But I don't think
it'd be too much trouble. Basically all you need to do is make a layer
which gets the interrupts and ports right, and then hook up the com driver
to handle the cips. Then you'll only have to intercept interrupts and feed
them to the right slave.

One thing to keep in mind is that with the current i/o space accounting, if
the "normal" com driver has attached on one of the com ports, your
slave won't be able to. So you'll have a bit of an ability to know if
you've got an overlapping configuration.

> In the meantime, it has been fun to get this far, it would be a pleasure 
> to be able to contribute where so far I have only been a spectator.

It is fun, isn't it?

Take care,

Bill