From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 3 22:48:25 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCCF9106568B; Tue, 3 Mar 2009 22:48:25 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 662558FC1F; Tue, 3 Mar 2009 22:48:25 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: by yx-out-2324.google.com with SMTP id 31so1676188yxl.13 for ; Tue, 03 Mar 2009 14:48:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=5Ycke98q+ruQIhgQAdnTEjkyA2S9RhjWIOgcDFKWhdM=; b=os8c5K0+X9s7VgsF07i7yKicFkHheRtNHCh9CgGFiSwCiHbEYzEBUobmNGNnQ4EHcz 2YHsDkaEQVM+gRQmW5B6wtfq7sUqv0ynrnY/54Zi00EN3vOkGi9yhwinIkpljYzxWS8a kCgkTZHnp7BK5JUut5Wt6DxshrXh0u4hJbmwg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ijGCfFh2nHu81CM8gKaiH1zzrMTKhJ48Qs4RqEsTeD1umXX+HQ0X2uGRU9W7RENF9T GwYDbXgVaEYIn5LTw56QwS37alCOhUfzvVvgwm/qMZOCo3u7jiCecbvGc06Fubk2rZXE hG2FlQpeRt0rYadOJQvhv+Z5IvWCgBXOmxYnA= MIME-Version: 1.0 Received: by 10.142.72.4 with SMTP id u4mr3826669wfa.216.1236120504312; Tue, 03 Mar 2009 14:48:24 -0800 (PST) In-Reply-To: <20090303195122.GA30421@insightsol.com> References: <200903030915.43037.jhb@freebsd.org> <200903031159.55299.jhb@freebsd.org> <9B775F97-1E5A-4E55-A2AE-26DC78CD08C0@mac.com> <20090303195122.GA30421@insightsol.com> Date: Tue, 3 Mar 2009 14:48:24 -0800 Message-ID: From: Navdeep Parhar To: Marcel Moolenaar Content-Type: multipart/mixed; boundary=001636ed65778f233d04643ebb99 Cc: FreeBSD Hackers Subject: Re: puc support for a generic card (patch attached) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 22:48:27 -0000 --001636ed65778f233d04643ebb99 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Mar 3, 2009 at 11:51 AM, Navdeep Parhar wrote: > On Tue, Mar 03, 2009 at 09:04:32AM -0800, Marcel Moolenaar wrote: >> >> 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 =A0 Sat Feb 28 12:42:37 2009 -0800 >>>>>> +++ b/sys/dev/puc/puc.c =A0 Mon Mar 02 12:21:07 2009 -0800 >>>>>> @@ -440,9 +440,6 @@ >>>>>> =A0 sc->sc_dev =3D dev; >>>>>> =A0 sc->sc_cfg =3D cfg; >>>>>> >>>>>> - /* We don't attach to single-port serial cards. */ >>>>>> - if (cfg->ports =3D=3D PUC_PORT_1S || cfg->ports =3D=3D PUC_PORT_1P= ) >>>>>> - =A0 =A0 =A0 =A0 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. =A0I'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. :) =A0Navdeep, 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... > > OK, I'll keep this in mind and will modify the patch to have uart(4) > claim the card and puc(4) ignore it. =A0I'll post it once I've tested > it. Reworked patch attached. Works for me. Navdeep > > Regards, > Navdeep > >> >> -- >> Marcel Moolenaar >> xcllnt@mac.com >> >> >> > --001636ed65778f233d04643ebb99 Content-Type: application/octet-stream; name="puc.2.patch" Content-Disposition: attachment; filename="puc.2.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_frv5w9ux0 ZGlmZiAtciAwMjVjYjAwZDE5ZDcgc3lzL2Rldi9wdWMvcHVjZGF0YS5jCi0tLSBhL3N5cy9kZXYv cHVjL3B1Y2RhdGEuYwlTYXQgRmViIDI4IDEyOjQyOjM3IDIwMDkgLTA4MDAKKysrIGIvc3lzL2Rl di9wdWMvcHVjZGF0YS5jCVR1ZSBNYXIgMDMgMTQ6MzI6MDEgMjAwOSAtMDgwMApAQCAtNzYxLDYg Kzc2MSwxOCBAQAogCSAgICBQVUNfUE9SVF8yUCwgMHgxMCwgOCwgMCwKIAl9LCAKIAorCS8qCisJ ICogVGhpcyBpcyBtb3JlIHNwZWNpZmljIHRoYW4gdGhlIGdlbmVyaWMgTk05ODM1IGVudHJ5IHRo YXQgZm9sbG93cywgYW5kCisJICogaXMgcGxhY2VkIGhlcmUgdG8gX3ByZXZlbnRfIHB1YyBmcm9t IGNsYWltaW5nIHRoaXMgc2luZ2xlIHBvcnQgY2FyZC4KKwkgKgorCSAqIHVhcnQoNCkgd2lsbCBj bGFpbSB0aGlzIGRldmljZS4KKwkgKi8KKwl7ICAgMHg5NzEwLCAweDk4MzUsIDB4MTAwMCwgMSwK KwkgICAgIk5ldE1vcyBOTTk4MzUgYmFzZWQgMS1wb3J0IHNlcmlhbCIsCisJICAgIERFRkFVTFRf UkNMSywKKwkgICAgUFVDX1BPUlRfMVMsIDB4MTAsIDQsIDAsCisJfSwKKwogCXsgICAweDk3MTAs IDB4OTgzNSwgMHhmZmZmLCAwLAogCSAgICAiTmV0TW9zIE5NOTgzNSBEdWFsIFVBUlQgYW5kIDEy ODQgUHJpbnRlciBwb3J0IiwKIAkgICAgREVGQVVMVF9SQ0xLLApkaWZmIC1yIDAyNWNiMDBkMTlk NyBzeXMvZGV2L3VhcnQvdWFydF9idXNfcGNpLmMKLS0tIGEvc3lzL2Rldi91YXJ0L3VhcnRfYnVz X3BjaS5jCVNhdCBGZWIgMjggMTI6NDI6MzcgMjAwOSAtMDgwMAorKysgYi9zeXMvZGV2L3VhcnQv dWFydF9idXNfcGNpLmMJVHVlIE1hciAwMyAxNDozMjowMSAyMDA5IC0wODAwCkBAIC0xMTAsNiAr MTEwLDcgQEAKIHsgMHgxNDE1LCAweDk1MGIsIDB4ZmZmZiwgMCwgIk94Zm9yZCBTZW1pY29uZHVj dG9yIE9YQ0I5NTAgQ2FyZGJ1cyAxNjk1MCBVQVJUIiwKIAkweDEwLCAxNjM4NDAwMCB9LAogeyAw eDE1MWYsIDB4MDAwMCwgMHhmZmZmLCAwLCAiVE9QSUMgU2VtaWNvbmR1Y3RvciBUUDU2MCA1Nmsg bW9kZW0iLCAweDEwIH0sCit7IDB4OTcxMCwgMHg5ODM1LCAweDEwMDAsIDEsICJOZXRNb3MgTk05 ODM1IFNlcmlhbCBQb3J0IiwgMHgxMCB9LAogeyAweGRlYWYsIDB4OTA1MSwgMHhmZmZmLCAwLCAi TWlkZGxlIERpZ2l0YWwgUEMgV2Vhc2VsIFNlcmlhbCBQb3J0IiwgMHgxMCB9LAogeyAweGZmZmYs IDAsIDB4ZmZmZiwgMCwgTlVMTCwgMCwgMH0KIH07Cg== --001636ed65778f233d04643ebb99--