From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 4 15:13:21 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA1C7327 for ; Tue, 4 Mar 2014 15:13:21 +0000 (UTC) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 706EC12B for ; Tue, 4 Mar 2014 15:13:21 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id rd18so5809363iec.15 for ; Tue, 04 Mar 2014 07:13:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=MDjqcPoGmamcHa+Kgfi5I4de6f3Jgf4TgNPAYEMpwhc=; b=DBhYOxrh0SyudHzOjQwVLornFv3CePZQE5NMhviU4Ao/TjkOlEmQy/cgUDO8rj/6YK 2B4LPDuBwaanQhOOuGE1ggg6J6U71kaS/jeNMzuMD7RmEN440yRZOHSL7UhW5KqZKO5n oXJbIobDkFkgSJ9oPKUVkd0rLJft/F6Sgn3NfqZkMxT8ZCsgTYdyxHgj5dCw5vYIE8kA 2nOL63wOiXj9XhqmAqL/Da2U3CXmNaP6UZafTmN4RZOCG0T1ewL0/i2DsinIGieXCLz4 0/BTs2NxekXS+QBAgfS9/DuPT8+4kGUZ7DD1k09wOJ27pGM8jayw7lJoITk4mEsiZiJg A1qw== X-Gm-Message-State: ALoCoQl5ErUVZ96A5GDWwO2lV09LC5niS5XQTyPz74MzsNCSPUBJoer/XPwOkhUte7emIeziNB7/ X-Received: by 10.43.65.145 with SMTP id xm17mr628294icb.35.1393945509501; Tue, 04 Mar 2014 07:05:09 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id rj10sm50728789igc.8.2014.03.04.07.05.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Mar 2014 07:05:08 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Warner Losh In-Reply-To: Date: Tue, 4 Mar 2014 08:05:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7110A2B6-A7E4-42F8-8232-9B09BE769C74@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> To: Patrick Kelsey X-Mailer: Apple Mail (2.1874) Cc: "freebsd-hackers@freebsd.org" , freebsd-arm@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 15:13:21 -0000 On Mar 3, 2014, at 11:05 PM, Patrick Kelsey wrote: > On Sun, Mar 2, 2014 at 9:38 PM, Warner Losh wrote: >=20 > On Mar 2, 2014, at 4:56 PM, Patrick Kelsey wrote: >=20 > > Hi, > > > > The attached patch (fdt_probe_order_control.patch) allows control = over the > > probe order of simplebus child devices by using a "probe-order" = property in > > simplebus child nodes in the .dts file >=20 > Where is the probe-order property defined? I can=92t seem to find it = in the bindings. > Also, I don=92t think it is necessary. This is a software construct, = so doesn=92t really > belong in the dts file. I=92d really like to avoid FreeBSD specific = hacks in the DTS > files. >=20 > It is currently not in any bindings, and has the status of being = something of my own invention and something possibly not ever used = outside of private codebases. I think this is something that would fit = conceptually with the miscellaneous bindings defined in ePAPR, as it is = a rather generic property. As to this being a software construct, I = appreciate and support the goal of keeping DTS files as pure hardware = descriptions (and I'd also argue that the way the status property is = sometimes used turns it into a software construct). Generally, anything that=92s a FreeBSD invention needs to be prefixed by = =91freebsd,=92 or we need to get it through the semi-standarded = device-tree list process. > Let's completely avoid the issue of am I arguing for adding a software = construct to DTS files by looking at this another way. Instead of a = 'probe-order' property that specifies a sort key, I could have the same = quality of result (same warts and all, as discussed below) with a = property that indicates whether the device is hardwired or has some sort = of pluggable interface (a property, say, called 'pluggable'). That = would be a pure hardware-as-it-is-designed description, and having that = information would allow me to do a sort that orders non-pluggable ahead = of pluggable in the probe/attach process. There=92s already properties for this defined, so that wouldn=92t be = terrible. But I=92m not sure how that would affect the order. > > This was motivated by booting FreeBSD from the eMMC on a BeagleBone = Black, > > which has a pluggable microSD card slot in addition to the eMMC. = The order > > that the mmc units are defined in sys/boot/fdt/dts/am335x.dtsi = causes the > > pluggable slot to be probed/attached first, so the device name = assigned to > > the eMMC soldered to the board changes depending on whether there is = a card > > in the pluggable slot, which makes establishing appropriate = /etc/fstab > > contents less than convenient. >=20 > Sounds like you=92d like to have some sort of name to instance = mapping. > The typical way this is solved is by naming the partitions so that = ordering > doesn=92t matter. Even if you don=92t handle this at the filesystem = level, which > is how others cope, you=92d want this to be more of a direct binding = rather than an > ordering so that you get the effect you want (constant name) directly, = rather > than as a side-effect of ordering. >=20 > Yes, ideally I'd like to be able to assign a name to every MMC/SD card = slot (hardwired or otherwise) in a system that depends only on the = physical location of that slot, and be able to resolve that name to an = mmcsd device instance. This works-here-side-effect-based approach is a = result of the ideal solution seemingly not being within reach given the = available resources. Using partition naming/glabel is a fair point, and = does address the /etc/fstab issue, but it still leaves me short of being = able to construct a product function that relies on knowing what's where = when there is no partitioning/filesystem in place, for example, = something that boils down to 'dd this image to the eMMC [or to the card = in the card slot]'. Perhaps the answer to that is to build something = using devinfo(3)/devd(8) to identify what mmcsdX is currently attached = to each controller when I need to know. We don=92t assign names based on physical location in FreeBSD generally. = The old concept of wiring a card to an address is mostly gone at this = point. You can get information from devinfo to find where the devices actually = live, and do things based on that. There=92s supposed to be (but might = not actually be) sufficient plug and play information so that people = that are invested in tying a physical location to a particular task can = dig that information out. > If you insist on that, then having a something more like = =93freesbd,unit-number=94 > property would also accomplish this. But that would only wire the = controller unit > number, and not the resulting mmcsdX device. >=20 > I understand fully that the utility of this goes as far as having none = of the hardwired devices sharing controllers with pluggable devices in = such a way that the controllers can find the attached pluggable devices = first. Subject to that limitation as it is, this does usefully apply to = at least one real system now, and it is a behavior I can take advantage = of when designing new hardware to make developing the associated = FreeBSD-based product software easier (namely, by not having to cobble = together a poor-man's udev [which is not saying users of udev are = exactly rich], and/or worry about how a customer might label the fat = partition on an SD card they insert). Device security goes well beyond device enumeration ordering, but that=92s= a fair point. > More generally, whether this is or isn't a widely useful thing in the = end, what is the current process for introducing a new property for use = in DTS files? You need to get it approved via the devicetree-spec@vger.kernel.org = mailing list to make it official. There are efforts to move this away = from Linux infrastructure to its own infrastructure... > > By using the "probe-order" property in > > sys/boot/fdt/dts/beaglebone-black.dts (see attached > > beaglebone_black_mmc_probe_order.patch), I am able to swap the order = in > > which the mmc units are probed/attached for that board. This avoids > > inappropriate hacking of the mmc definition order in am335x.dtsi, = which is > > shared among multiple boards. > > > > This is not a general solution to the problem of wanting stable = device > > names for hard-wired MMC devices when pluggable slots are present in = the > > system. There could, for example, be a multi-slot MMC controller = with a > > mixture of hard-wired and pluggable devices attached, and this would = not > > address that case. However, it does address the needs of BeagleBone = Black, > > and the mechanism may be of use for similar issues on other = platforms. >=20 > As it isn=92t a generic solution, I=92d be biased against adopting it. = What=92s wrong > with using glabel to accomplish this (either with a label specific = property, or > by using a ufs label and mounting /dev/ufs/foo). >=20 >=20 > It is not my intention to lobby for adding this to the kernel at this = point. Whether it is widely-enough or only very-narrowly useful I would = say is currently unknown. My intention in posting this patch was for = others on the list(s) that might find it useful to see it and have = access to it, and to attract thoughtful criticism such as yours. Sure. Tying devices name to physical location is a hardish FreeBSD = problem, but has been since around FreeBSD 3. =46rom the sounds of things, you=92d want any SD card found on this = controller to have a unique name=85 The move to CAM may help that, but = we=92d need to invent FDT bindings, I think, for CAM to get the device = wiring info it currently gets from hints... > I appreciate you taking the time to respond. Sure thing=85 Warner=