puc support for a generic card (patch attached)

[John Baldwin]

On Tuesday 03 March 2009 11:48:42 am Marcel Moolenaar wrote:
> 
> On Mar 3, 2009, at 6:15 AM, John Baldwin wrote:
> 
> >> diff -r 025cb00d19d7 sys/dev/puc/puc.c
> >> --- a/sys/dev/puc/puc.c	Sat Feb 28 12:42:37 2009 -0800
> >> +++ b/sys/dev/puc/puc.c	Mon Mar 02 12:21:07 2009 -0800
> >> @@ -440,9 +440,6 @@
> >> 	sc->sc_dev = dev;
> >> 	sc->sc_cfg = cfg;
> >>
> >> -	/* We don't attach to single-port serial cards. */
> >> -	if (cfg->ports == PUC_PORT_1S || cfg->ports == PUC_PORT_1P)
> >> -		return (EDOOFUS);
> >
> > FWIW, the traditional reason for this is that we made the sio/uart  
> > or ppc
> > drivers claim single port devices directly and only use puc for  
> > multiple-port
> > cards.  I'm not sure if that should still be the case or not.   
> > Marcel, do you
> > have an opinion?
> 
> Yes :-)
> 
> I explicitly added the test with that particular error code
> to make it absolutely clear that puc(4) is not the driver
> for single port cards. The reason being that it's pointless.
> 
> There are 2 things that puc(4) facilitates in: resource
> assignment and interrupt handling. For single port cards
> there's nothing to distribute nor is there any interrupt
> sharing. In other words: there's no value that puc(4) adds.
> As such, uart(4) and ppc(4) can attach directly to those
> cards and puc(4) does not have to be involved.
> 
> BTW: Traditionally puc(4) was used to attach even to single
> port cards. With the puc(4) rewrite I changed that, because
> it was really a mixed bag. Some single-port cards were known
> to puc(4) others to uart(4)/sio(4) or ppc(4). That typically
> leads to confusion given that puc(4) is (still) not in GENERIC.
> (i.e. why is this UART attached, but that one isn't, they're
> both single port?)
> 
> So, please do not apply the patch and instead add the IDs to
> sys/dev/uart/uart_bus_pci.c...

This sounds fine to me. :)  Navdeep, can you develop a patch for uart(4) 
instead and test that?

-- 
John Baldwin