Date: Tue, 4 Mar 2014 08:05:07 -0700 From: Warner Losh <imp@bsdimp.com> To: Patrick Kelsey <kelsey@ieee.org> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, freebsd-arm@freebsd.org, freebsd-embedded@freebsd.org Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) Message-ID: <7110A2B6-A7E4-42F8-8232-9B09BE769C74@bsdimp.com> In-Reply-To: <CAD44qMXe8bh0cR60tm8%2BLZ9W3WhJDuGX6xz9FLNHrzmXNd5FDQ@mail.gmail.com> References: <CAD44qMUyqzaFtjgXdgThgHcHjPctx-oZAdhvHp4Kf0G7N4HVog@mail.gmail.com> <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <CAD44qMXe8bh0cR60tm8%2BLZ9W3WhJDuGX6xz9FLNHrzmXNd5FDQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 3, 2014, at 11:05 PM, Patrick Kelsey <kelsey@ieee.org> wrote: > On Sun, Mar 2, 2014 at 9:38 PM, Warner Losh <imp@bsdimp.com> wrote: >=20 > On Mar 2, 2014, at 4:56 PM, Patrick Kelsey <kelsey@ieee.org> 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7110A2B6-A7E4-42F8-8232-9B09BE769C74>