[U-Boot] [PATCH] MMC: Do not write to mmc_uclass_priv if it was not allocated

[Matt Corallo <linux@bluematt.me>]

Sorry, this was related to https://patchwork.ozlabs.org/patch/624614/,
not dragonboard, and yes, is the same issue that was addressed by the
patch you linked.

With this patch the MMC worked fine, but, indeed, as with dragonboard,
its better to assign mmc instead of removing this (this seems to be the
only place where mmc is actually used during boot for me, so maybe not?).

Matt

On 06/30/16 19:28, Simon Glass wrote:
> Hi Meteusz,
> 
> On 30 June 2016 at 12:18, Mateusz Kulikowski
> <mateusz.kulikowski@gmail.com> wrote:
>> On 29.06.2016 05:27, Simon Glass wrote:
>>> Hi Matt,
>>>
>>> On 25 June 2016 at 14:57, Matt Corallo <linux@bluematt.me> wrote:
>>>> Signed-off-by: Matt Corallo <git@bluematt.me>
>>>> ---
>>>>  drivers/mmc/mmc.c | 3 ++-
>>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
>>>> index aabfc71..eba20f0 100644
>>>> --- a/drivers/mmc/mmc.c
>>>> +++ b/drivers/mmc/mmc.c
>>>> @@ -1734,7 +1734,8 @@ int mmc_init(struct mmc *mmc)
>>>>  #ifdef CONFIG_DM_MMC
>>>>         struct mmc_uclass_priv *upriv = dev_get_uclass_priv(mmc->dev);
>>>>
>>>> -       upriv->mmc = mmc;
>>>> +       if (upriv)
>>>> +               upriv->mmc = mmc;
>>>>  #endif
>>>>         if (mmc->has_init)
>>>>                 return 0;
>>>> --
>>>> 2.1.4
>>>
>>> Can you please add a commit message explaining why this is needed and
>>> what it fixes?  How can mmc_init() be called before the MMC device is
>>> there? Is this related to this patch?
>>>
>>> http://patchwork.ozlabs.org/patch/640735/
>>
>> It's related in a way that it fixed crash of dragonboard before I submitted my patch :)
>>
>> Not sure if it meant to fix dragonboard or some other board.
>>
>> Although - imho - it's nice to make check like that.. or at least some kind of assert.
> 
> An assert() would be fine with me.
> 
> Regards,
> Simon
>