From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 7 16:02:19 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 6F2A2106566C for ; Sat, 7 Jul 2012 16:02:19 +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 28DB28FC1B for ; Sat, 7 Jul 2012 16:02:19 +0000 (UTC) Received: by obbun3 with SMTP id un3so21099417obb.13 for ; Sat, 07 Jul 2012 09:02:18 -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=R9TJmdrqpWp3aCYDP2Jc3EeCP62DFixE8mu0TeykeNA=; b=GY+CDEAY2O4sTtBmhSsm6lMZPufIq8hlatjw9Z3n8J2VN/9VQe4euCB3O7ECe871N1 XyzytriaPOhOnP5TAKIVSrupZLETlECIOl5GhTB+ANCpEAn01KelWzRsPGSE+ztoLuYZ 1wl1R8fzKaA7g6j7Sn4DBcjUHVLJEsJHsVyM302WKXxaZjF9jN724DJuQjS+QpAbFxV4 SejoIKIAVoiD4xy9RPR8Ql3wqhkmRkKuSZJ9WGQfoxguP++jKv6qlUqBzM7PHRDKBKNq IzuzwQoYrS27+g95BRkazF7+O9dZqsHarfUqdHcCgNSzjmTk5b1TS1S165BJhNpmJJic 9zGQ== Received: by 10.50.219.136 with SMTP id po8mr4722277igc.70.1341676938639; Sat, 07 Jul 2012 09:02:18 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id s4sm4953838igb.1.2012.07.07.09.02.17 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 07 Jul 2012 09:02:18 -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: Sat, 7 Jul 2012 10:02:16 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <7AAA45BE-520B-4753-823E-D17D1AB0A5E0@bsdimp.com> References: To: Stefan Bethke X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQn8ML/KELICJ2sWvM9ldeSgNpxzvUeOZYc9hBHnumfWmEV7BBlr5HAZH9Hvdn9vYoUPtSKC Cc: FreeBSD Hackers , FreeBSD Current , Arnaud Lacombe 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: Sat, 07 Jul 2012 16:02:19 -0000 On Jul 7, 2012, at 6:25 AM, Stefan Bethke wrote: > Am 06.07.2012 um 17:33 schrieb Arnaud Lacombe: >=20 >> I assume you are talking about = devclass_get_device()/device_find_child(). >>=20 >> 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. >>=20 >> About (1), lower unit devices can fails to attach[0], thus newly >> attached bus will now have a negative offset. >>=20 >> 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. >>=20 >> 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. >=20 > I believe there is one more thing that needs to be addressed, which I = ran into while trying to do the arge/mdio attachment: >=20 > 4) the device attach method may require access to the other device to = complete the attachment, but that other might not be attached yet. >=20 > Circular dependencies nonwithstanding, it would be highly desirable = for a device driver developer to be able to simply declare all = prerequisites for attachment, and have newbus call attach only after = everything is there. Right now, the drivers attach method is called by = the parent bus as soon as enumeration is completed. The device should go ahead and attach. When multiple devices need to = communicate with each other, they need to coordinate things. newbus is = a weak coordination mechanism. Stronger coordination mechanisms would = be FDT or ACPI which can tie known devices to a device_t rather than to = just a name. The device_t will be around even if that device is = attached and detached. > A notification mechanism (similar to the devfs notification but with = an exposed KPI) might be an alternative, as mentioned in this thread. This would also work. However, many of proposed uses for this seem = more and more to me to need a non-newbus mechanism to cope with. You'll = absolutely require the notification method since devices can detach at = any time. Circular dependencies are way too easy to create. In the Atmel work I'm doing and have done, there's devices that provide = services to other devices (mostly pin muxing and GPIO). I don't try to = get the GPIO device to attach first, but rather have routines that can = be called to accomplish these things. During the early boot, I have to = use the GPIO device to turn on pins so that I can even talk to things = like the MII bus of the internal NIC. While the GPIO devices have = device_t's to allocate resources and to create dev_t nodes, I don't = marshal everything through newbus. When I want to map a pin as an = interrupt source for the PHY chip, that call is made directly. When I = need to shut off a device's pin and instead drive it via the GPIO logic, = that's just a call. etc. Warner=