Re: [PATCH v5 4/5] mmc: sdhci-tegra: Implement alternative_gpt_sector()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Aug 18, 2021 at 07:15:43PM +0300, Dmitry Osipenko wrote:
> 18.08.2021 16:35, Thierry Reding пишет:
> >>> +static int sdhci_tegra_alternative_gpt_sector(struct mmc_card *card,
> >>> +                                             sector_t *gpt_sector)
> >>> +{
> >>> +       unsigned int boot_sectors_num;
> >>> +
> >>> +       /* filter out unrelated cards */
> >>> +       if (card->ext_csd.rev < 3 ||
> >>> +           !mmc_card_mmc(card) ||
> >>> +           !mmc_card_is_blockaddr(card) ||
> >>> +            mmc_card_is_removable(card->host))
> >>> +               return -ENOENT;
> >>> +
> >>> +       /*
> >>> +        * eMMC storage has two special boot partitions in addition to the
> >>> +        * main one.  NVIDIA's bootloader linearizes eMMC boot0->boot1->main
> >>> +        * accesses, this means that the partition table addresses are shifted
> >>> +        * by the size of boot partitions.  In accordance with the eMMC
> >>> +        * specification, the boot partition size is calculated as follows:
> >>> +        *
> >>> +        *      boot partition size = 128K byte x BOOT_SIZE_MULT
> >>> +        *
> >>> +        * Calculate number of sectors occupied by the both boot partitions.
> >>> +        */
> >>> +       boot_sectors_num = card->ext_csd.raw_boot_mult * SZ_128K /
> >>> +                          SZ_512 * MMC_NUM_BOOT_PARTITION;
> >>> +
> >>> +       /* Defined by NVIDIA and used by Android devices. */
> >>> +       *gpt_sector = card->ext_csd.sectors - boot_sectors_num - 1;
> >>> +
> >>> +       return 0;
> >>> +}
> >> I suggest you move this code into the mmc core/block layer instead (it
> >> better belongs there).
> >>
> >> Additionally, let's add a new host cap, MMC_CAP_ALTERNATIVE_GPT, to
> >> let the core know when it should use the code above.
> > Couldn't a generic "alternative GPT" mean pretty much anything? As far
> > as I know this is very specific to a series of Tegra chips and firmware
> > running on them. On some of these devices you can even replace the OEM
> > firmware by something custom that's less quirky.
> > 
> > I'm not aware of anyone else employing this kind of quirk, so I don't
> > want anyone to get any ideas that this is a good thing. Putting it into
> > the core runs the risk of legitimizing this.
> 
> I also think it's better to keep it internal to Tegra. Ulf, could you
> please clarify why do you want to have it moved into the core? Are you
> aware of any other platforms that want exactly the same quirk? Thierry
> should be correct that it's relevant only to Tegra SoCs.
> 
> Regarding the 'legitimizing', it's not a bad thing to me at all. If we
> want to run more devices with a mainline kernel, then such quirks are
> inevitable.

That's not what I meant. What I meant to say is that putting it into the
core might give somebody else the idea that this is actually a good
thing and therefore they might end up implementing a similar quirk. That
is definitely not something we want to encourage.

Thierry

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [ARM Kernel]     [Linux ARM]     [Linux ARM MSM]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux