24.08.2021 13:38, Michał Mirosław пишет:

On Tue, Aug 24, 2021 at 01:40:02AM +0200, Michał Mirosław wrote:

quoted

On Sat, Aug 21, 2021 at 08:27:15PM +0300, Dmitry Osipenko wrote:

quoted

21.08.2021 01:41, Michał Mirosław пишет:

quoted

On Thu, Aug 19, 2021 at 01:19:15AM +0300, Dmitry Osipenko wrote:

quoted

This series adds the most minimal EFI partition support for NVIDIA Tegra
consumer devices, like Android tablets and game consoles, making theirs
eMMC accessible out-of-the-box using downstream bootloader and mainline
Linux kernel.  eMMC now works on Acer A500 tablet and Ouya game console
that are already well supported in mainline and internal storage is the
only biggest thing left to support.

[...]

Could we provide the GPT sector via DT? As I understand this is for
non-removable eMMC storage. It would remove the need for a cap bit and
hardcoded calculations instead just checking if DT node of the controller
contains a magic entry with a number.

The same device model usually comes in different flavors that have a
different eMMC unit and size. So no, it can't be hardcoded in DT.

I see. I was thinking how to avoid of going the whole way and creating
another controller capability (since this is going to be core code) -
could this workaround be enabled just by a boolean DT property at
controller's node instead? Or do we expect non-DT platforms to be
similarly broken?

Rewording my concern: I believe that this is platform's and not 
a controller's misfeature, so the controller driver feels like wrong
place fix. That's why I'd prefer that the enable came from the DT
and not from driver's code.

The alternative GPT entry requires user to add 'gpt' argument to
kernel's cmdline. If board already uses proper alternative GPT entry at
the last sector, then nothing changed for that board.

The case where board uses 'gpt' cmdline + it had stale GPT entry at the
special location used by Android devices and chance that now suddenly
that GPT entry will pop up is close to zero.

All old partition table entries should be erased on reparation. If it
wasn't done, then it's not a kernel's problem, it's much more a user's
problem. Even though kernel could help that poor user if will be really
needed.

There is no reason to over-engineer unless somebody will tell that it
broke the very special board. Neither of currently supported boards
should require more quirks. Hence, why bother?