From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 6 15:33:58 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B374F1065670; Fri, 6 Jul 2012 15:33:58 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 21CFE8FC16; Fri, 6 Jul 2012 15:33:57 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so9280543wgb.31 for ; Fri, 06 Jul 2012 08:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8tZs1+xnwWmNDwtHtKjhk12i2ML5kEFXMoj0IZm3wg0=; b=HwwzH8SmnTmWCDmdjvwJqfGq8ndPTahwSHrIU+NhUuspea0/guRgNMEVpxgm1qxCJE AwBBT9AuazYb6RGyIGjvkEwoe9NT/Q75hI6DapE9YR3Nho9c5LTGj9i9l7+O7+xhpaAB UHzx89QAUL7eheujbsv1hqDk4CY/4ll3K2V9a2mZUt4+/Z/g8OTb7i2vL9NHUKz3rvN4 vBmxiZMne/Pklb4QOYLgZNL73TgP34tFYoNot7m0LCC24ujmXwQRdTr5APkd26/zY3zn nf3ZC3YbCEIi/RR7PC8TFwGLlgOP28hGffRGwkKC1e7juIv6MSjS+qmbLwiBJBQHtHdD /Gog== MIME-Version: 1.0 Received: by 10.217.3.209 with SMTP id r59mr10001747wes.108.1341588836915; Fri, 06 Jul 2012 08:33:56 -0700 (PDT) Received: by 10.216.23.200 with HTTP; Fri, 6 Jul 2012 08:33:56 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 Jul 2012 11:33:56 -0400 Message-ID: From: Arnaud Lacombe To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 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 15:33:58 -0000 Hi, On Fri, Jul 6, 2012 at 1:04 AM, Warner Losh wrote: > > On Jul 5, 2012, at 5:14 PM, Arnaud Lacombe wrote: > >> Hi folks, >> >> 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. >> >> 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. >> >> This situation make me really dubious that FreeBSD will be able to >> support configuration such as: >> >> esdhc@50004000 { /* ESDHC1 */ >> cd-gpios = <&gpio2 13 0>; /* GPIO3_13 */ >> wp-gpios = <&gpio3 11 0>; /* GPIO4_11 */ >> status = "okay"; >> }; >> >> or: >> >> ecspi@50010000 { /* ECSPI1 */ >> fsl,spi-num-chipselects = <2>; >> cs-gpios = <&gpio1 30 0>, /* GPIO2_30 */ >> <&gpio2 19 0>; /* GPIO3_19 */ >> status = "okay"; >> [...] >> >> 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: >> >> esdhc@50004000 { /* ESDHC1 */ >> cd-gpios = <&gpio2 13 0>; /* GPIO3_13 */ >> wp-gpios = <&gpio2 14 0>; /* GPIO3_14 */ >> status = "okay"; >> }; >> >> AFAIK, newbus is unable to model any of the above situation without >> being bypassed one way or another. >> >> 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. > I assume you are talking about devclass_get_device()/device_find_child(). 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. 2) there is no reference counting on the returned device. 3) there is no track record of the reference being given. About (1), lower unit devices can fails to attach[0], thus newly attached bus will now have a negative offset. About (2) and (3), referenced device (think KLD) might go away and the child will not be told. In this situation, I want the child to be detached prior to its parent. As such, looking up other node by name would fit in what I call "bypassing newbus purpose". I might just as well export a damn function pointer and make my life easier. What would be need is an interface where the child need to have a way to say "resources I need are not complete, tell me when a new device in devclass Z is attached that I can check if it fills my need", ala: - dev0 is probed - dev0 tells it is present, but need unavailable resource in devclass X and devclass Y - dev0 is marked as pending - dev1 is attached in devclass X - dev0 is asked if dev1 would suit it - dev0 answers negatively - dev2 is attached in devclass X - dev0 is asked if dev2 would suit it - dev0 answers positively - dev0 continues its probe, but still need unavailable resource in devclass Y - dev3 is attached in devclass Y - dev0 is asked if dev3 would suit it - dev0 answers positively - dev0 finishes its probe - dev0 is attached [...] - dev3 is to be detached - dev0 is detached - dev3 is detached - Arnaud [0]: for many reason; hardware failure, configuration change (think GPIO on multi-function pin)