From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Stefan Agner <stefan@agner.ch>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>,
robh+dt@kernel.org, dwmw2@infradead.org,
computersforpeace@gmail.com, marek.vasut@gmail.com,
mark.rutland@arm.com, thierry.reding@gmail.com,
mturquette@baylibre.com, sboyd@kernel.org, dev@lynxeye.de,
richard@nod.at, marcel@ziswiler.com, krzk@kernel.org,
digetx@gmail.com, benjamin.lindqvist@endian.se,
jonathanh@nvidia.com, pdeschrijver@nvidia.com,
pgaikwad@nvidia.com, mirza.krak@gmail.com,
linux-mtd@lists.infradead.org, linux-tegra@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-clk@vger.kernel.org
Subject: Re: [RESEND PATCH 2/5] mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver
Date: Thu, 31 May 2018 22:30:27 +0200 [thread overview]
Message-ID: <20180531223027.57e36d0b@bbrezillon> (raw)
In-Reply-To: <047a9a5e72c8db52858a505865d4f720@agner.ch>
On Thu, 31 May 2018 19:54:08 +0200
Stefan Agner <stefan@agner.ch> wrote:
> >> +
> >> + mtd->dev.parent = &pdev->dev;
> >> + mtd->name = "tegra_nand";
> >
> > I just figured it was undocumented (yet) but you could have a label
> > string property in your nand DT node that tells you the name of the
> > MTD device instead of something too generic like tegra_nand.
> >
>
> Using label in the NAND chip subnode actually causes current U-Boot to
> delete (!!) the chip node and create partitions on the controller node.
>
> See:
> https://elixir.bootlin.com/u-boot/latest/source/common/fdt_support.c#L757
>
> The code essentially uses the property label to detect whether its a
> NAND chip or a partition...
Why not fixing that in uboot? The representation where the NAND device
and NAND controller are mixed in a single node called nand@xxx is just
wrong from a HW PoV, and it seems uboot is using this representation,
which is probably why you have a problem when trying to find the
partition directly under the NAND controller node.
>
> At least this is the case when using fdt_fixup_mtdparts and passing the
> controller compatible ("nvidia,tegra20-nand") in node_info,
Just a digression, but I recommend using
"nvidia,tegra20-nand-controller" for the compatible, because the node
is describing the NAND controller not the NAND chip.
> what our
> downstream U-Boot is currently doing. Maybe we should pass the
> compatible property of the NAND chip?
Or maybe you should search for partitions in children of the controller
node instead of searching directly under the controller node itself.
> But afaik, chips do not have a
> compatible necessarily.
Nope, and it should stay like that.
>
> So using label in the chip node is currently a no-go for me.
I hope I'm wrong but I fear this is not the only problem you'll face
when switching to a controller+chip representation. This is just the
tip of the iceberg.
>
> Will send out v3 soon.
Sure, let's see how v3 looks.
next prev parent reply other threads:[~2018-05-31 20:30 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-22 12:07 [RESEND PATCH 0/5] mtd: rawnand: add NVIDIA Tegra NAND flash support Stefan Agner
2018-05-22 12:07 ` [RESEND PATCH 1/5] mtd: rawnand: tegra: add devicetree binding Stefan Agner
2018-05-22 17:52 ` Boris Brezillon
2018-05-22 12:07 ` [RESEND PATCH 2/5] mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver Stefan Agner
2018-05-22 12:16 ` Dmitry Osipenko
2018-05-22 12:19 ` Stefan Agner
2018-05-22 13:34 ` Dmitry Osipenko
2018-05-22 14:28 ` Stefan Agner
2018-05-22 14:53 ` Stefan Agner
2018-05-22 17:55 ` Boris Brezillon
2018-05-23 14:18 ` Boris Brezillon
2018-05-24 8:46 ` Stefan Agner
2018-05-24 8:56 ` Boris Brezillon
2018-05-24 11:09 ` Stefan Agner
2018-05-24 12:23 ` Boris Brezillon
2018-05-24 12:41 ` Boris Brezillon
2018-05-24 22:56 ` Stefan Agner
2018-05-24 12:27 ` Boris Brezillon
2018-05-24 7:45 ` Benjamin Lindqvist
2018-05-24 11:00 ` Stefan Agner
2018-05-24 11:07 ` Boris Brezillon
2018-05-24 11:30 ` Benjamin Lindqvist
2018-05-24 11:53 ` Boris Brezillon
2018-05-24 12:19 ` Stefan Agner
2018-05-27 14:18 ` Miquel Raynal
2018-05-27 15:13 ` Boris Brezillon
2018-05-27 15:54 ` Miquel Raynal
2018-05-27 16:30 ` Boris Brezillon
2018-05-27 19:08 ` Stefan Agner
2018-05-27 22:04 ` Miquel Raynal
2018-05-28 12:39 ` Stefan Agner
2018-05-31 17:54 ` Stefan Agner
2018-05-31 20:30 ` Boris Brezillon [this message]
2018-05-31 21:44 ` Stefan Agner
2018-05-22 12:07 ` [RESEND PATCH 3/5] clk: tegra20: init NDFLASH clock to sensible rate Stefan Agner
2018-05-22 12:07 ` [RESEND PATCH 4/5] ARM: tegra: add Tegra20 NAND flash controller node Stefan Agner
2018-05-22 12:07 ` [RESEND PATCH 5/5] ARM: tegra: enable NAND flash on Colibri T20 Stefan Agner
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=20180531223027.57e36d0b@bbrezillon \
--to=boris.brezillon@bootlin.com \
--cc=benjamin.lindqvist@endian.se \
--cc=computersforpeace@gmail.com \
--cc=dev@lynxeye.de \
--cc=devicetree@vger.kernel.org \
--cc=digetx@gmail.com \
--cc=dwmw2@infradead.org \
--cc=jonathanh@nvidia.com \
--cc=krzk@kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-tegra@vger.kernel.org \
--cc=marcel@ziswiler.com \
--cc=marek.vasut@gmail.com \
--cc=mark.rutland@arm.com \
--cc=miquel.raynal@bootlin.com \
--cc=mirza.krak@gmail.com \
--cc=mturquette@baylibre.com \
--cc=pdeschrijver@nvidia.com \
--cc=pgaikwad@nvidia.com \
--cc=richard@nod.at \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.org \
--cc=stefan@agner.ch \
--cc=thierry.reding@gmail.com \
/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).