From: Richard Weinberger <richard@nod.at>
To: Arnd Bergmann <arnd@arndb.de>, Hauke Mehrtens <hauke@hauke-m.de>
Cc: mark.rutland@arm.com,
Boris Brezillon <boris.brezillon@free-electrons.com>,
dedekind1@gmail.com, Daniel Golle <daniel@makrotopia.org>,
devicetree@vger.kernel.org, robh+dt@kernel.org,
linux-mtd@lists.infradead.org, computersforpeace@gmail.com,
dwmw2@infradead.org
Subject: Re: [PATCH 1/2] ubi: mount partitions specified in device tree
Date: Mon, 20 Jun 2016 10:26:11 +0200 [thread overview]
Message-ID: <5767A8A3.4030004@nod.at> (raw)
In-Reply-To: <6411961.soYuJ4Ixfs@wuerfel>
Am 20.06.2016 um 10:09 schrieb Arnd Bergmann:
> A few more thoughts on various things that came up in the discussion
> so far (so I don't have to reply to each of them separately)
>
> - The /chosen and /aliases nodes do configure the OS to some degree,
> and historically we have used them to specify the device names that
> show up in the kernel (e.g. on MacOS and AIX) as well as the rootfs
> itself
>
> - The device tree should give us enough information to identify the
> root partition by a GUID from the kernel. This works on all block
> devices (at least with MBR and EFI partition tables, probably many
> of the lesser known ones as well) and it should really also work
> on UBI.
It does.
> - MTD partitioning unfortunately does not seem to have a widely used
> method for identifying partitions from what's stored on the flash,
> unlike block devices, so whatever we normally have in the partition
> table has to be stored in DT. This really sucks, but I don't know
> what else to do about it.
Since blocks on a MTD can render bad you'd lose the table sooner or later.
That's why we cannot store it on the MTD directly.
Defining the table in DT is at least less ugly than using the mtdparts=
kernel parameter.
> - The UBI design was originally meant to cover the entire flash
> device and provide the partitioning information inside. I have not
> looked at UBI in a long time (actually not since before embedded
> PPC moved to DT), but I would hope that this case works without
> any DT magic.
Of course it works without DT magic.
So, I don't see a urge to have UBI DT bindings.
First I thought having an attach flag would be handy but it turned out
that this behavior can easily achieved by naming. i.e. you a kernel
command line such as "ubi.mtd=UBI" and name the to be attached MTD "UBI"
in your DT.
Thanks,
//richard
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2016-06-20 8:26 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-18 19:17 [PATCH 1/2] ubi: mount partitions specified in device tree Hauke Mehrtens
[not found] ` <1466277476-14853-1-git-send-email-hauke-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>
2016-06-18 19:17 ` [PATCH 2/2] ubi: open volumes define " Hauke Mehrtens
[not found] ` <1466277476-14853-2-git-send-email-hauke-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>
2016-06-18 23:36 ` Daniel Golle
[not found] ` <20160618233654.GC29476-g5gK2j5usbvCyp4qypjU+w@public.gmane.org>
2016-06-19 21:21 ` Hauke Mehrtens
2016-06-24 18:45 ` Ezequiel Garcia
[not found] ` <CAAEAJfATWJL0fGEcBup+cWzhHUe_4CF4XHWuvp4NYOesmaTyZw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-06-25 20:24 ` Hauke Mehrtens
2016-06-18 23:56 ` [PATCH 1/2] ubi: mount partitions specified " Daniel Golle
2016-06-19 21:36 ` Hauke Mehrtens
[not found] ` <ecb7950d-9e07-5c5d-6668-1c67ba170ddf-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>
2016-06-19 21:52 ` Daniel Golle
2016-06-18 19:30 ` Richard Weinberger
[not found] ` <5765A14F.6020201-/L3Ra7n9ekc@public.gmane.org>
2016-06-18 19:35 ` Hauke Mehrtens
2016-06-18 23:20 ` Daniel Golle
[not found] ` <20160618232054.GB29476-g5gK2j5usbvCyp4qypjU+w@public.gmane.org>
2016-06-19 8:53 ` Richard Weinberger
[not found] ` <57665D96.1070804-/L3Ra7n9ekc@public.gmane.org>
2016-06-19 9:16 ` Richard Weinberger
2016-06-19 11:25 ` Daniel Golle
[not found] ` <20160619112510.GA820-g5gK2j5usbvCyp4qypjU+w@public.gmane.org>
2016-06-19 12:02 ` Richard Weinberger
[not found] ` <576689CC.3030809-/L3Ra7n9ekc@public.gmane.org>
2016-06-19 13:05 ` Daniel Golle
2016-06-19 13:19 ` Richard Weinberger
[not found] ` <57669BEA.5030306-/L3Ra7n9ekc@public.gmane.org>
2016-06-19 14:09 ` Daniel Golle
[not found] ` <20160619140952.GC820-g5gK2j5usbvCyp4qypjU+w@public.gmane.org>
2016-06-19 14:35 ` Richard Weinberger
[not found] ` <5766AD99.1040809-/L3Ra7n9ekc@public.gmane.org>
2016-06-19 15:24 ` Daniel Golle
2016-06-19 15:31 ` Richard Weinberger
[not found] ` <5766BAB8.9090707-/L3Ra7n9ekc@public.gmane.org>
2016-06-19 16:13 ` Daniel Golle
2016-06-19 16:53 ` Boris Brezillon
2016-06-19 19:42 ` Daniel Golle
[not found] ` <20160619194236.GA1222-g5gK2j5usbvCyp4qypjU+w@public.gmane.org>
2016-06-19 20:14 ` Boris Brezillon
2016-06-19 21:48 ` Daniel Golle
[not found] ` <20160619214820.GB1222-g5gK2j5usbvCyp4qypjU+w@public.gmane.org>
2016-06-19 22:21 ` Hauke Mehrtens
2016-06-20 8:09 ` Arnd Bergmann
2016-06-20 8:26 ` Richard Weinberger [this message]
2016-06-20 15:08 ` Arnd Bergmann
2016-06-20 17:24 ` Brian Norris
2016-06-20 19:57 ` Richard Weinberger
[not found] ` <57684AB9.5040607-/L3Ra7n9ekc@public.gmane.org>
2016-06-20 21:18 ` Hauke Mehrtens
2016-06-20 17:05 ` Brian Norris
[not found] ` <20160619152445.GG820-g5gK2j5usbvCyp4qypjU+w@public.gmane.org>
2016-06-19 15:43 ` Boris Brezillon
2016-06-19 16:23 ` Daniel Golle
2016-06-20 17:03 ` Brian Norris
[not found] ` <48242f26-7812-6957-6bf5-c12989b875b4-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>
2016-06-18 19:46 ` Richard Weinberger
[not found] ` <5765A4F9.3050107-/L3Ra7n9ekc@public.gmane.org>
2016-06-18 22:54 ` Hauke Mehrtens
[not found] ` <8697ff77-218b-2bc6-5d36-bfb02360d223-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>
2016-06-19 8:41 ` Richard Weinberger
2016-06-24 18:28 ` Ezequiel Garcia
[not found] ` <CAAEAJfC8mYnohRxKg0b-onbGadk0vPDty=7Bh8emP92mazB=aA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-06-25 20:20 ` Hauke Mehrtens
[not found] ` <aedd029f-858b-97f8-7fc7-f224999ed24c-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>
2016-06-25 20:33 ` Richard Weinberger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5767A8A3.4030004@nod.at \
--to=richard@nod.at \
--cc=arnd@arndb.de \
--cc=boris.brezillon@free-electrons.com \
--cc=computersforpeace@gmail.com \
--cc=daniel@makrotopia.org \
--cc=dedekind1@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dwmw2@infradead.org \
--cc=hauke@hauke-m.de \
--cc=linux-mtd@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).