24.08.2021 13:38, Michał Mirosław пишет: > On Tue, Aug 24, 2021 at 01:40:02AM +0200, Michał Mirosław wrote: >> On Sat, Aug 21, 2021 at 08:27:15PM +0300, Dmitry Osipenko wrote: >>> 21.08.2021 01:41, Michał Mirosław пишет: >>>> On Thu, Aug 19, 2021 at 01:19:15AM +0300, Dmitry Osipenko wrote: >>>>> 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?
