From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 6 18:57:05 2012 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 C50531065672 for ; Fri, 6 Jul 2012 18:57:05 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7EE8F8FC08 for ; Fri, 6 Jul 2012 18:57:05 +0000 (UTC) Received: by obbun3 with SMTP id un3so19356086obb.13 for ; Fri, 06 Jul 2012 11:57:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=MeqTKp1m1xMTqd2+L6pcWtzdaEHQpKliBPwU5XEEROE=; b=ZowCrNlpY++18u9GTIY28NE+1lHG3c+l3qJGPVCTCqwXHESLKKHpAkHcQrNw8mLFf4 diQy3M7IkC54oNh2UDOR+sZ37Nz96kkyw8ZzVjaEaEyRg3NaCdxPB/IwaEog2XgPU9To WVhqMZDiD72UWR6FtgkjxBz17wRlElAFo5hMgQg8y4Oj8syTlQLnQLfmhWdWsmyVU4pG ClKSczgUeRscajuFFCGQ3/KDWPewPElnRQpkKbOqCsZtikp1vPmkSnXLrLX7ITT8BEhW y3nCmgiR9k0YxjxyBwT2TUH8wAkXsDmbwEDCRPI6Hi8UKJ0iubCioHzR1zpDwb4iawwL Ap1g== Received: by 10.60.22.5 with SMTP id z5mr32265106oee.2.1341601025048; Fri, 06 Jul 2012 11:57:05 -0700 (PDT) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id tn8sm23723383obc.21.2012.07.06.11.57.04 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Jul 2012 11:57:04 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Fri, 6 Jul 2012 12:57:02 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Arnaud Lacombe X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQk+QAouCzHFFd3091TnsTUSRcp+pZr/TsK27BR8qUuX2FrTCqsGNVcGTyfb+A1A20fDnNkb Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: Interfacing devices with multiple parents within newbus 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: Fri, 06 Jul 2012 18:57:06 -0000 On Jul 6, 2012, at 12:46 PM, Arnaud Lacombe wrote: > Hi, >=20 > On Fri, Jul 6, 2012 at 11:33 AM, Arnaud Lacombe = wrote: >> That's neither correct nor robust in a couple of way: >> 1) you have no guarantee a device unit will always give you the same = resource. > this raises the following question: how can a device, today, figure > out which parent in a given devclass would give it access to resources > it needs. >=20 > Say, you have gpiobus0 provided by a superio and gpiobus1 provided by > the chipset and a LED on the chipset's GPIO. Now, say gpiobus0 > attachment is conditional to some BIOS setting. How can you tell > gpioled(4) to attach on the chipset provided GPIO without hardcoding > unit number either way ? >=20 > AFAIK, you can not. >=20 > Even hints provided layout description is defeated. Each device in a > given devclass need to have a set of unique attribute to allow a child > to distinguish it from other potential parent in the same devclass... hints can hard-wire the device to a given bus. This also can hard-wire = the unit number, which will be stable even if one of them fails to = attach. But since the FDT language provides a richer set of connections than is = possible with raw newbus, perhaps the solution to your problem should be = handled in the FDT domain where you can look up a device name and have = the FDT layer do the proper mapping into newbus rather than trying to = guess at unit numbers. The reference count problem would still be there, but that's a different = issue that we have all over the place and need to solve before we can = properly lock NEWBUS. Warner