From owner-freebsd-hackers@freebsd.org Mon Sep 28 15:01:24 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 83E02A0BE71 for ; Mon, 28 Sep 2015 15:01:24 +0000 (UTC) (envelope-from rpokala@panasas.com) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0070.outbound.protection.outlook.com [157.56.110.70]) (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 DE47B1F47; Mon, 28 Sep 2015 15:01:22 +0000 (UTC) (envelope-from rpokala@panasas.com) Received: from CY1PR08MB1803.namprd08.prod.outlook.com (10.162.218.25) by CY1PR08MB1801.namprd08.prod.outlook.com (10.162.218.23) with Microsoft SMTP Server (TLS) id 15.1.280.20; Mon, 28 Sep 2015 15:01:14 +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.0280.017; Mon, 28 Sep 2015 15:01:14 +0000 From: "Pokala, Ravi" To: John Baldwin , Francois Tigeot , "cem@FreeBSD.org" CC: "freebsd-hackers@freebsd.org" Subject: Re: bus_.*_resource() and rid Thread-Topic: bus_.*_resource() and rid Thread-Index: AQHQ6qhpmlcbMDBrSUWapu14ripoSp42SMsAgAAUkACAE/CTgIAHZG6A Date: Mon, 28 Sep 2015 15:01:13 +0000 Message-ID: References: <1685918.WyYIclYTSg@ralph.baldwin.cx> <1637146.Rv3dkk0gMi@ralph.baldwin.cx> In-Reply-To: <1637146.Rv3dkk0gMi@ralph.baldwin.cx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.5.150821 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rpokala@panasas.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [24.6.178.251] x-microsoft-exchange-diagnostics: 1; CY1PR08MB1801; 5:zyoYqKnor13C5tbu+lbqS1bzfAtdNVIVpLUqe2hR49hHJUwusItW1txxS/4yhhUSqRu6sTOUtWQcsQwpGFUIYMVuxfwppfWogd+UwxQQB8FnOs6j2Rb6ei8zhNeQ7Qk4o9fp9eaGZsjTqdEEGF7Ddg==; 24:KUwgpioR6nj4Zu5ihro/iDUycMENfXzZCxOwVQpjjMWOqZH/+GCZmhgdz8usD2iVMLY09d3iCaRXs6JQqPfdryU0FG6mVLAfXxStZxGzLXs=; 20:OoDcL30+1KHc0gQwOWLFxcEwQTyB7Clp21GIG8wE7XKsNbUncZGqDxcMUPFmo3r3mVtfubY50HWG/Z+Y9c7tyw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR08MB1801; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:CY1PR08MB1801; BCL:0; PCL:0; RULEID:; SRVR:CY1PR08MB1801; x-forefront-prvs: 0713BC207F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(377424004)(13464003)(76176999)(5890100001)(64706001)(36756003)(5001960100002)(189998001)(40100003)(54356999)(50986999)(122556002)(87936001)(77096005)(5004730100002)(66066001)(102836002)(5007970100001)(83506001)(68736005)(4001540100001)(105586002)(4001350100001)(106116001)(106356001)(2950100001)(2900100001)(5001860100001)(11100500001)(5001770100001)(5001830100001)(99286002)(19580405001)(19580395003)(101416001)(2501003)(46102003)(81156007)(77156002)(92566002)(62966003)(5002640100001)(10400500002)(86362001)(93886004)(97736004)(21314002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR08MB1801; H:CY1PR08MB1803.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX: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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: panasas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Sep 2015 15:01:13.3806 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: acf01c9d-c699-42af-bdbb-44bf582e60b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR08MB1801 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: Mon, 28 Sep 2015 15:01:24 -0000 -----Original Message----- From: John Baldwin Date: 2015-09-23, Wednesday at 08:07 To: Ravi Pokala Cc: "freebsd-hackers@freebsd.org" Subject: Re: bus_.*_resource() and rid >Yes, you'd have to grumble around with kgdb to see rids. We might store >rids in 'struct resouce *' now so we could possibly expose those to >devinfo. Survey says "no": sys/sys/rman.h: 89 /* 90 * The public (kernel) view of struct resource 91 * 92 * NB: Changing the offset/size/type of existing fields in struct resource 93 * NB: breaks the device driver ABI and is strongly FORBIDDEN. 94 * NB: Appending new fields is probably just misguided. 95 */ 96=20 97 struct resource { 98 struct resource_i *__r_i; 99 bus_space_tag_t r_bustag; /* bus_space tag */ 100 bus_space_handle_t r_bushandle; /* bus_space handle */ 101 }; We *do* keep the rid in (struct resource_i): sys/kern/subr_rman.c: 88 struct resource_i { 89 struct resource r_r; 90 TAILQ_ENTRY(resource_i) r_link; 91 LIST_ENTRY(resource_i) r_sharelink; 92 LIST_HEAD(, resource_i) *r_sharehead; 93 u_long r_start; /* index of the first entry in this resource */ 94 u_long r_end; /* index of the last entry (inclusive) */ 95 u_int r_flags; 96 void *r_virtual; /* virtual address of this resource */ 97 struct device *r_dev; /* device which has allocated this resource */ 98 struct rman *r_rm; /* resource manager from whence this came */ 99 int r_rid; /* optional rid for this resource. */ 100 }; I have a one-line change to dump_rman() to include the RID along w/ the start and end address. That at least got me what I was interested in from ddb. As for `devinfo', it looks like (struct u_resource) and (struct u_rman) don't include the RID either: sys/sys/rman.h: 67 struct u_resource { 68 uintptr_t r_handle; /* resource uniquifier */ 69 uintptr_t r_parent; /* parent rman */ 70 uintptr_t r_device; /* device owning this resource */ 71 char r_devname[RM_TEXTLEN]; /* device name XXX obsolete */ 72=20 73 u_long r_start; /* offset in resource space */ 74 u_long r_size; /* size in resource space */ 75 u_int r_flags; /* RF_* flags */ 76 }; 77=20 78 struct u_rman { 79 uintptr_t rm_handle; /* rman uniquifier */ 80 char rm_descr[RM_TEXTLEN]; /* rman description */ 81=20 82 u_long rm_start; /* base of managed region */ 83 u_long rm_size; /* size of managed region */ 84 enum rman_type rm_type; /* region type */ 85 }; >Some drivers take over the LPC (e.g. I think some of the smb controllers >do this) and provide functionality directly in the driver attached to the >LPC rather than as a child. In general I think it is cleaner to provide >these extended functionalities as pseudo-ISA devices that are children of >the LPC instead. Yeah, the existing driver I'm extending is being done as an ISA child of the PCI-ISA bridge. No worries there. >>I'll look into bus_get_resource(). Oh, look - there's no manpage >> (share/man/man9/bus_get_resource.9 does not exist, despite being a "see >> also" entry in bus_set_resource.9). :-S > >Time for Someone(tm) to write one. :-/ Thanks to Francois for pointing at Dragonfly's version, and to Conrad for bringing it in. ---- I ultimately just added a "next_rid" field to the softc, saving the value after a successful call to bus_set_resource() and then incrementing it. That way, each subsequent resource I add for an instance of the device gets a unique value, which appears to be the only constraint for IOPORT resources. In any case, with that change, both the original and the new resource are able to be set and allocated. Thanks all, Ravi