From owner-freebsd-hackers@freebsd.org Wed Sep 9 02:37:09 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E1B9FA00E79 for ; Wed, 9 Sep 2015 02:37:09 +0000 (UTC) (envelope-from rpokala@panasas.com) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0057.outbound.protection.outlook.com [157.56.111.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F2D414C3 for ; Wed, 9 Sep 2015 02:37:07 +0000 (UTC) (envelope-from rpokala@panasas.com) Received: from CY1PR08MB1803.namprd08.prod.outlook.com (10.162.218.25) by CY1PR08MB1804.namprd08.prod.outlook.com (10.162.218.26) with Microsoft SMTP Server (TLS) id 15.1.262.15; Wed, 9 Sep 2015 02:37:05 +0000 Received: from CY1PR08MB1803.namprd08.prod.outlook.com ([10.162.218.25]) by CY1PR08MB1803.namprd08.prod.outlook.com ([10.162.218.25]) with mapi id 15.01.0262.011; Wed, 9 Sep 2015 02:37:05 +0000 From: "Pokala, Ravi" To: "freebsd-hackers@freebsd.org" Subject: bus_.*_resource() and rid Thread-Topic: bus_.*_resource() and rid Thread-Index: AQHQ6qhpmlcbMDBrSUWapu14ripoSg== Date: Wed, 9 Sep 2015 02:37:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rpokala@panasas.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [64.80.217.3] x-microsoft-exchange-diagnostics: 1; CY1PR08MB1804; 5:94/DvyVIARhcUSOPswbqf9dDoaG65T6RPO4JoNF04z8jvqfeP8W/P9mkENDvWURMrmCwEj2WAMCMj1xj/c48K2W0v9BkbBItH1nZAaEDfTIIA6Z2/EGD1Y+nMoQiOEeSRXd1D9O4NbVkgdZWqcledA==; 24:9G2kHp4apJzzNK0cTorkxUo4G6OhIPx50jk60SIjPpW+tOUr4Z83K/G+TcebddQFLGQl4nJp+ABtdmZ9GdFR2edrL66dPvzEmuj7T52ijsQ=; 20:397im9L9h8OOao9uYT9UaD06MYdJkosMx6AlCnyc6++BlxorWpMUgPIk3qQkMl2KPtLipFG7O/Tdi9AJX2haRg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR08MB1804; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:CY1PR08MB1804; BCL:0; PCL:0; RULEID:; SRVR:CY1PR08MB1804; x-forefront-prvs: 0694C54398 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(164054003)(199003)(101416001)(87936001)(62966003)(92566002)(2900100001)(450100001)(2501003)(107886002)(77096005)(77156002)(50986999)(102836002)(10400500002)(110136002)(11100500001)(36756003)(2351001)(15975445007)(5001960100002)(189998001)(97736004)(54356999)(5002640100001)(229853001)(5001860100001)(106356001)(99286002)(106116001)(46102003)(5001830100001)(68736005)(5001920100001)(86362001)(40100003)(105586002)(4001350100001)(4001540100001)(83506001)(81156007)(5890100001)(64706001)(5007970100001)(66066001)(122556002)(19580395003)(5004730100002)(21314002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR08MB1804; H:CY1PR08MB1803.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: panasas.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <8388A5A97F429C48B6B06A7A5DA49573@namprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: panasas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Sep 2015 02:37:04.0700 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: acf01c9d-c699-42af-bdbb-44bf582e60b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR08MB1804 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 02:37:10 -0000 Hi folks, I'm modifying a home-grown device driver; this is the first time I've played around in device-probe and -attach, so I'm a bit out of my element here. This is an LPC device attached to a PCI-ISA bridge (aka the LPC controller). It's accessed through IOPORT, and the BIOS sets up enough stuff that we can look for it. One thing that's confusing me is the "rid" which is passed to a bunch of the bus_.*_resource() functions. I've looked at bus_set_resource(9), bus_alloc_resource(9), and section 10.5 of the Architecture Handbook[1], and I'm still confused. bus_alloc_resource(9) says: rid points to a bus specific handle that identifies the resource being allocated. For ISA this is an index into an array of resources that have been setup for this device by either the PnP mechanism, or via the hints mechanism. ... But there's no indication as to how we get that index. One possibility is that the value passed in doesn't matter; bus_alloc_resource() sets it correctly and the caller can use the new value. However, that doesn't appear to be the case, since lots of times rid is ignored after the call to bus_alloc_resource(). For the sake of discussion, here are stripped-down versions of our probe and attach functions: xxx_probe_unit(device_t dev) { uint32_t ioport_base; uint32_t ioport_size; int rc; /* Device identification stuff; details unimportant, but we determine * ioport_base and ioport_size. */ rc =3D bus_set_resource( /* dev */ dev, /* type */ SYS_RES_IOPORT, /* rid */ 0, /* start */ ioport_base, /* count */ ioport_size); } Most of those args are obvious, but I have no idea why rid is 0. It looks like lots of drivers pass in a rid of 0, and the original author might have just shrugged and gone with "convention". xxx_attach_unit(device_t dev) { struct xxx_softc *sc; int rid; struct resource res; sc =3D device_get_softc(dev); /* Device configuration stuff; details unimportant. */ rid =3D 0; res =3D bus_alloc_resource( /* dev */ dev, /* type */ SYS_RES_IOPORT, /* rid */ &rid, /* start */ 0, /* end */ ~0, /* count */ sc->ioport_size, /* flags */ RF_ACTIVE); /* save stuff for use with bus_space_{read,write}_1() */ sc->iobase_addr =3D rman_get_start(res); sc->iobase_bustag =3D rman_get_bustag(res); sc->iobase_bushandle =3D rman_get_bushandle(res); sc->dev =3D dev; } Again, most things are fairly obvious, but I have no idea why rid is 0. It's passed by reference to bus_alloc_resource(), but the potentially-altered value is never stored or used. The lazy part of me says to just go with blindly passing in 0, because it works. However, the new device I'm adding support for will have multiple IOPORT ranges associated with it, so I'm not sure if passing 0 is the right thing. Any help would be appreciated. Thanks, Ravi [1]=20 https://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/isa-driver- resources.html