From owner-freebsd-embedded@FreeBSD.ORG Mon Mar 3 02:38:15 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9DDEDA14 for ; Mon, 3 Mar 2014 02:38:15 +0000 (UTC) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 644A014AC for ; Mon, 3 Mar 2014 02:38:15 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id rl12so2285160iec.32 for ; Sun, 02 Mar 2014 18:38:09 -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=2sMHPLd4EibfAk/WkktsSivFvzO+978wges/RFSKv48=; b=IuXutxMPkAHT+pPEzid7hMxepYPAxinUQTei7sQbRXzcF00bPcAFwxJftHGGrn3pDU Xqt27sPqz15h6YL9vK9zXNm0a7gX3q99Gs09AqP1/7Zh1tw8lORL71CKZhiIbP0kbIAW g8sDqVc4BItWKPtuccEZuwixmgv1CreUMsQDVJxTXiAOTYBRWSRWsaM/OtFDgAnAnnhp 1dRyl7TCrwPsSmLhzaCWgW0D1XkCqV6h25th+taUXd/dHww3jrFT8/mYJ3/+X53ElMIP GyLdfG8WsyTmWddb8EfTZr/runLk7w31hG7QwqRRtRPmVYgzoLQCDVa8Z3ov9LOhdGbd gkxw== X-Gm-Message-State: ALoCoQnXa/VPVOzjaJgMqm5xL75+QjBzfy4TkTvlYIFBP8bUfmwHMQ1wcwhbscu1goas32WDlADl X-Received: by 10.43.155.209 with SMTP id lj17mr95356icc.94.1393814289789; Sun, 02 Mar 2014 18:38: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 sc8sm34675367igb.0.2014.03.02.18.38.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Mar 2014 18:38:09 -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: Sun, 2 Mar 2014 19:38:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> References: 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-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 02:38:15 -0000 On Mar 2, 2014, at 4:56 PM, Patrick Kelsey wrote: > Hi, >=20 > 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 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. > 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. 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. 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. > 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. >=20 > 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. 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). Warner > Both patches were generated against 10-STABLE, r262447. >=20 > -Patrick > = _______= ________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"