linux-kernel - Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAD=FV=XLuPWKjQBMLApRQxk0K30p_TPcztB7g_1DB7iRA9BGRQ@mail.gmail.com>
Date:   Fri, 15 Mar 2019 16:23:26 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Marek Vasut <marex@...x.de>
Cc:     Tim Harvey <tharvey@...eworks.com>,
        Måns Rullgård <mans@...sr.com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Jaehoon Chung <jh80.chung@...sung.com>,
        Shawn Lin <shawn.lin@...k-chips.com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Stefan Agner <stefan@...er.ch>,
        Linux MMC List <linux-mmc@...r.kernel.org>,
        Brian Norris <computersforpeace@...il.com>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Heiko Stuebner <heiko@...ech.de>,
        Jisheng Zhang <jszhang@...vell.com>,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
        devicetree-spec@...r.kernel.org,
        Mark Rutland <mark.rutland@....com>,
        open list <linux-kernel@...r.kernel.org>,
        Venu Byravarasu <vbyravarasu@...dia.com>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Russell King - ARM Linux <linux@....linux.org.uk>,
        Jon Hunter <jonathanh@...dia.com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        devicetree@...r.kernel.org, Pawel Moll <pawel.moll@....com>,
        Ian Campbell <ijc+devicetree@...lion.org.uk>,
        Grant Grundler <grundler@...omium.org>,
        Kumar Gala <galak@...eaurora.org>,
        "Luca Porzio (lporzio)" <lporzio@...ron.com>,
        Rob Herring <robh+dt@...nel.org>,
        Chaotian Jing (井朝天) 
        <chaotian.jing@...iatek.com>,
        Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
        Sudeep Holla <sudeep.holla@....com>,
        zhonghui.fu@...ux.intel.com, kirill.shutemov@...ux.intel.com
Subject: Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering
 w/ device tree

Hi,

On Fri, Mar 15, 2019 at 4:00 PM Marek Vasut <marex@...x.de> wrote:
>
> > Completely agree here - we need a dt solution that allows us to
> > specify ordering.
>
> Nope, ordering would be a policy and does not describe hardware, thus it
> shouldn't be in the DT. Use UUID or PARTUUID, they apply both to raw FS
> (fsuuid) and to partitions (part uuid). Linux kernel can mount FS using
> PARTUUID, to support UUID you need initramfs.

Two thoughts about that:

1. Some amount of policy is allowed in device tree.  At some point in
time there was a big discussion about the need for a separate "config
tree" that was totally parallel to the device tree so we could put
policy stuff in that.  Nobody wanted that and (as I recall) it was
agreed that in some cases policy could go there if that policy
expressed policy that was the generic intent of how the board ought to
be run.  I believe this is how things like the assigned-clocks is
justified.

2. In some cases this number does describe the hardware.  You look at
the hardware reference manual and see that there are 3 MMC
controllers: 0, 1, and 2.  In such cases it seems like it's an OK
description of the hardware to encode this info into the DTS.

...from what I recall, one big objection is for SoCs that didn't just
have numbers for their controllers.  AKA I think some SoCs might call
their controllers the "eMMC" controller, the "SD" controller, and the
"SDIO" controller.  They may be nearly the same hardware, but perhaps
the SoC allows for a GPIO interrupt on the SDIO controller and perhaps
the eMMC controller exposes the strobe line or has an 8-bit wide
datapath.  In this case making up numbers does become a bit more
arbitrary and folks didn't like it.

IIRC there was general consensus that it'd be OK to somehow specify a
string (AKA non-numeric) name for different SD controllers.  I don't
have pointers to that conversation offhand and it's possible I
imagined it.

-Doug