puc support for a generic card (patch attached)
jhb at freebsd.org
Tue Mar 3 09:00:31 PST 2009
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
This sounds fine to me. :) Navdeep, can you develop a patch for uart(4)
instead and test that?
More information about the freebsd-hackers