From: Dmitry Osipenko <digetx@gmail.com>
To: "Michał Mirosław" <mirq-linux@rere.qmqm.pl>
Cc: Jens Axboe <axboe@kernel.dk>,
Thierry Reding <thierry.reding@gmail.com>,
Jonathan Hunter <jonathanh@nvidia.com>,
David Heidelberg <david@ixit.cz>,
Peter Geis <pgwipeout@gmail.com>,
Stephen Warren <swarren@wwwdotorg.org>,
Nicolas Chauvet <kwizart@gmail.com>,
Ulf Hansson <ulf.hansson@linaro.org>,
Adrian Hunter <adrian.hunter@intel.com>,
Billy Laws <blaws05@gmail.com>,
linux-tegra@vger.kernel.org, linux-block@vger.kernel.org,
Andrey Danin <danindrey@mail.ru>,
Gilles Grandou <gilles@grandou.net>,
Ryan Grachek <ryan@edited.us>,
linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 00/10] Introduce NVIDIA Tegra Partition Table
Date: Mon, 23 Mar 2020 22:44:13 +0300 [thread overview]
Message-ID: <9f63f113-fc67-5e1c-a539-81e3b0cd4e31@gmail.com> (raw)
In-Reply-To: <20200323180750.GA30585@qmqm.qmqm.pl>
23.03.2020 21:07, Michał Mirosław пишет:
> On Mon, Mar 23, 2020 at 07:34:21PM +0300, Dmitry Osipenko wrote:
>> Some NVIDIA Tegra devices have GPT entry at a wrong location and others may
>> even not have it at all. So either a custom workaround for GPT parsing or
>> TegraPT support is needed for those devices if we want to support them in
>> upstream kernel. The former solution was already rejected [1], let's try
>> the latter.
> [...]
>
> Hi Dmitry,
>
> This amusing use of whole-device offsets in the TegraPT makes it take
> a lot of hacks to support it. Have you considered to first join the MMC
> hardware partitions using DM and its linear target and only then processing
> the partition table dividing just the merged device?
Hello Michał,
Thank you very much for the suggestion! I had a thought about that and
it's not apparent to me how to determine when the joining needs to be
done and when not.
The joining shouldn't be done for devices that aren't booting from eMMC
because then the alt GPT entry will be found on a joined block device
and this shouldn't happen.
Actually, maybe we could create a new MMC device-tree property, telling
that the joining needs to be performed. Perhaps this indeed could result
in a less hackery, I'll give it a try and see how it goes.
prev parent reply other threads:[~2020-03-23 19:44 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-23 16:34 [PATCH v3 00/10] Introduce NVIDIA Tegra Partition Table Dmitry Osipenko
2020-03-23 16:34 ` [PATCH v3 01/10] mmc: core: Add raw_boot_mult field to mmc_ext_csd Dmitry Osipenko
2020-03-23 16:34 ` [PATCH v3 02/10] mmc: block: Add mmc_bdev_to_card() helper Dmitry Osipenko
2020-03-23 16:34 ` [PATCH v3 03/10] partitions: Introduce NVIDIA Tegra Partition Table Dmitry Osipenko
2020-03-23 19:17 ` Michał Mirosław
2020-03-23 19:59 ` Dmitry Osipenko
2020-03-23 21:35 ` Michał Mirosław
2020-03-23 23:22 ` Dmitry Osipenko
2020-03-24 20:52 ` Michał Mirosław
2020-03-25 0:27 ` Dmitry Osipenko
2020-03-23 16:34 ` [PATCH v3 04/10] block: Introduce GENHD_FL_PART_SCAN_ONCE Dmitry Osipenko
2020-03-23 16:34 ` [PATCH v3 05/10] mmc: block: Add mmc_bdev_to_part_type() helper Dmitry Osipenko
2020-03-23 16:34 ` [PATCH v3 06/10] mmc: block: Add mmc_bdev_to_area_type() helper Dmitry Osipenko
2020-03-23 16:34 ` [PATCH v3 07/10] mmc: block: Add MMC_QUIRK_RESCAN_MAIN_BLKDEV Dmitry Osipenko
2020-03-23 16:34 ` [PATCH v3 08/10] mmc: block: Support partition-table scanning on boot partitions Dmitry Osipenko
2020-03-23 16:34 ` [PATCH v3 09/10] mmc: sdhci-tegra: Enable boot partitions scanning on Tegra20 and Tegra30 Dmitry Osipenko
2020-03-23 16:34 ` [PATCH v3 10/10] partitions/tegra: Implement eMMC boot partitions scanning Dmitry Osipenko
2020-03-23 16:49 ` [PATCH v3 00/10] Introduce NVIDIA Tegra Partition Table Dmitry Osipenko
2020-03-23 18:07 ` Michał Mirosław
2020-03-23 19:44 ` Dmitry Osipenko [this message]
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=9f63f113-fc67-5e1c-a539-81e3b0cd4e31@gmail.com \
--to=digetx@gmail.com \
--cc=adrian.hunter@intel.com \
--cc=axboe@kernel.dk \
--cc=blaws05@gmail.com \
--cc=danindrey@mail.ru \
--cc=david@ixit.cz \
--cc=gilles@grandou.net \
--cc=jonathanh@nvidia.com \
--cc=kwizart@gmail.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=mirq-linux@rere.qmqm.pl \
--cc=pgwipeout@gmail.com \
--cc=ryan@edited.us \
--cc=swarren@wwwdotorg.org \
--cc=thierry.reding@gmail.com \
--cc=ulf.hansson@linaro.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).