Re: puc support for a generic card (patch attached)

On Mar 3, 2009, at 8:59 AM, John Baldwin wrote:

> 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?

BTW: I forgot to mention that puc(4) needs to back-off from this
particular card. That means that the catch-all that we have there
needs to be tweaked.

So, the change to pucdata.c can still be made, but with a big
comment that states that the entry is added only to avoid puc(4)
from attaching to that particular 1-port card so that uart(4)
can claim it...

-- 
Marcel Moolenaar
xcllnt@mac.com

_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"