From owner-freebsd-current@FreeBSD.ORG Fri Jul 6 05:04:24 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2022B1065670 for ; Fri, 6 Jul 2012 05:04:24 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id DCE5C8FC08 for ; Fri, 6 Jul 2012 05:04:23 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so15015151pbb.13 for ; Thu, 05 Jul 2012 22:04:23 -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=wYaNIKB4Ewj9Zc0rDwUVuMdsQXHv+eI1uu3urjZcR+o=; b=PUkf2qxxkXmEtBjqvIte3mJwr23cot6qyHg6SfByaGVOYQEbwD9Jsiu8zJ3Z3iIGvL levZ/XcJ2ris5VYa+d/eaQ0EIEh6lj3vTueFTiwPX8OLR/yxdbzLoL83t4uEwgMJtbwK wHzQwk4JE9Xx7MouLMD6oaqdAyygdabRlgfDN8W89hyISWHxDiU4sv4etuhwTE3BoNwU Xa9pzqSyfC8jD5qXiHzbceHUGunrh/6BiT4Zh+9UMCjjNtKv/7LKVPOT3GnxEp7Qi/H0 /uz/ME8cn6rLPjtP3QL4UZI9aXuilWYD5gJfGVfrNKC5ztl+BRJLAP02xNxjE4vM4Hbv NfgQ== Received: by 10.68.238.166 with SMTP id vl6mr33664171pbc.96.1341551063464; Thu, 05 Jul 2012 22:04:23 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id nh8sm21117559pbc.60.2012.07.05.22.04.22 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Jul 2012 22:04:23 -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: Thu, 5 Jul 2012 23:04:19 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Arnaud Lacombe X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmcgkFVlzYJ6Yp3vxSp1Sg4SxAvEIPWUtVBVVELN/PSR768D2n8ZGOIZHK6Acjqmc2VR+ey Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: Interfacing devices with multiple parents within newbus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 05:04:24 -0000 On Jul 5, 2012, at 5:14 PM, Arnaud Lacombe wrote: > Hi folks, >=20 > The problem has been raised in the last BSDCan during a talk, but no > clear answer has been given. Some (pseudo-)devices might require > resources from multiple other (pseudo-)devices. >=20 > For example, a device is sitting on an SMBus, but need to access a > software controlled LED, sitting on a GPIO bus, itself sitting on an > LPC bus... Or a variant where everything is controlled on the same > chip, but different GPIO banks. For that specific example, all the > GPIO pin could be implement on the same GPIObus, however, gpiobus(4) > is limited to 32 pins and the chip provides 5 banks of 8 pins, ie. a > total of 40 pins[0]. In the same idea, a device sitting on GPIOs > controlled by two independant chips, say one being an ICH10R chipset > on a PCI device function, and the other being a > SuperIO on an LPC bus. >=20 > This situation make me really dubious that FreeBSD will be able to > support configuration such as: >=20 > esdhc@50004000 { /* ESDHC1 */ > cd-gpios =3D <&gpio2 13 0>; /* GPIO3_13 */ > wp-gpios =3D <&gpio3 11 0>; /* GPIO4_11 */ > status =3D "okay"; > }; >=20 > or: >=20 > ecspi@50010000 { /* ECSPI1 */ > fsl,spi-num-chipselects =3D <2>; > cs-gpios =3D <&gpio1 30 0>, /* GPIO2_30 */ > <&gpio2 19 0>; /* GPIO3_19 */ > status =3D "okay"; > [...] >=20 > This example is taken from Linux' `arch/arm/boot/dts/imx53-smd.dts'. > Here, SDHC or SPI controller are using different GPIO devices. Note > that these GPIO pins does not seem to be multi-function pins as > another .dts defines ESDHC1 as: >=20 > esdhc@50004000 { /* ESDHC1 */ > cd-gpios =3D <&gpio2 13 0>; /* GPIO3_13 */ > wp-gpios =3D <&gpio2 14 0>; /* GPIO3_14 */ > status =3D "okay"; > }; >=20 > AFAIK, newbus is unable to model any of the above situation without > being bypassed one way or another. >=20 > any hints ? That's not correct. You don't need a parent-child relationship in = newbus to interact with another node in the tree. You can look up the = other node by name, and then call functions based on finding that other = device. Warner