Re: [PATCH] mmc: sdhci-esdhc-imx: Enable boot partition access from DT

[Jean-Michel Hautbois]

2014-09-03 11:09 GMT+02:00 Ulf Hansson <ulf.hansson@xxxxxxxxxx>:
> On 3 September 2014 11:02, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote:
>> On 09/03/2014 11:30 AM, Ulf Hansson wrote:
>>> On 2 September 2014 17:49, Jean-Michel Hautbois
>>> <jean-michel.hautbois@xxxxxxxxxxx> wrote:
>>>> This property is useful when we don't want to access boot partitions on eMMC
>>>>
>>>> Signed-off-by: Jean-Michel Hautbois <jean-michel.hautbois@xxxxxxxxxxx>
>>>> ---
>>>>  Documentation/devicetree/bindings/mmc/mmc.txt | 1 +
>>>>  drivers/mmc/host/sdhci-esdhc-imx.c            | 8 ++++++++
>>>>  include/linux/platform_data/mmc-esdhc-imx.h   | 1 +
>>>>  3 files changed, 10 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt
>>>> index 431716e..59cc854 100644
>>>> --- a/Documentation/devicetree/bindings/mmc/mmc.txt
>>>> +++ b/Documentation/devicetree/bindings/mmc/mmc.txt
>>>> @@ -40,6 +40,7 @@ Optional properties:
>>>>  - mmc-hs200-1_2v: eMMC HS200 mode(1.2V I/O) is supported
>>>>  - mmc-hs400-1_8v: eMMC HS400 mode(1.8V I/O) is supported
>>>>  - mmc-hs400-1_2v: eMMC HS400 mode(1.2V I/O) is supported
>>>> +- no-boot-part : when preset, tells to access boot partitions
>>>>
>>>>  *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers line
>>>>  polarity properties, we have to fix the meaning of the "normal" and "inverted"
>>>> diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
>>>> index ccec0e3..439e663 100644
>>>> --- a/drivers/mmc/host/sdhci-esdhc-imx.c
>>>> +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
>>>> @@ -942,6 +942,11 @@ sdhci_esdhc_imx_probe_dt(struct platform_device *pdev,
>>>>         if (of_property_read_u32(np, "fsl,delay-line", &boarddata->delay_line))
>>>>                 boarddata->delay_line = 0;
>>>>
>>>> +       if (of_find_property(np, "no-boot-part", NULL))
>>>> +               boarddata->access_boot_part = false;
>>>> +       else
>>>> +               boarddata->access_boot_part = true;
>>>> +
>>>>         return 0;
>>>>  }
>>>>  #else
>>>> @@ -1119,6 +1124,9 @@ static int sdhci_esdhc_imx_probe(struct platform_device *pdev)
>>>>                 host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
>>>>         }
>>>>
>>>> +       if (!boarddata->access_boot_part)
>>>> +               host->mmc->caps2 |= MMC_CAP2_BOOTPART_NOACC;
>>>> +
>>>
>>> Hmm, I don't think MMC_CAP2_BOOTPART_NOACC should have a DT binding.
>>> Does it describe the hardware in some form?
>>>
>>> Actually I would like to question why MMC_CAP2_BOOTPART_NOACC exists
>>> at all. If there are cards that don't supports the BOOT area,
>>> shouldn't we have a card quirk for it instead of a host cap? Maybe
>>> Adrian Hunter, how originally wrote the patch for adding
>>> MMC_CAP2_BOOTPART_NOACC, could help me understand the reasons behind
>>> it!?
>>
>> It was added because platform firmware was able to prevent access to the
>> boot partitions (for security I think), so attempts to access them would
>> fail messily.  It was not related to any specific card.
>
> Adrian, appreciate your clarification. After all it seems like adding
> a DT binding for it should be appropriate.
>
> Kind regards
> Uffe

Thanks Adrian :).
Well, there is boot partitions and rpmb partition, and maybe should we
have a binding to prevent access to both of them ?
Something else came to my mind, when you want to boot on eMMC, do you
need to write u-boot in boot partitions or is it written at the
logical adress 0 which is what fdisk uses as start ?
Because, if this is not usuable but just scanned I can't see why we
bother doing it... ?

Thanks,
JM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/