[U-Boot] [PATCH] ARM: board: cm-fx6: fix mmc for old revisions of utilite

[Christopher Spinrath]

Hi Igor,

On 06/16/2016 11:05 AM, Igor Grinberg wrote:
> Hi Christopher,
> 
> On 06/15/2016 06:38 PM, Christopher Spinrath wrote:
>> Hi Nikita,
>>
>> On 06/15/2016 05:15 PM, Nikita Kiryanov wrote:
>>> Hi CHristopher,
>>>
>>> On Wed, Jun 08, 2016 at 09:02:36PM +0200, Christopher Spinrath wrote:
>>>> Old revisions of Utilite (based on cmfx6) do not have a dedicated
>>>> card detect pin. But the card is removable by the user and card
>>>> detection can be realized with polling (e.g. supported by Linux).
>>>>
>>>> Add the broken-cd property to the mmc device tree instead of the
>>>> non-removable property to make card detection possible if polling
>>>> is supported.
>>>
>>> Acked-by: Nikita Kiryanov <nikita at compulab.co.il>
>>
>> How is this patch (and, in general, patches for Utilite/cm-fx6) supposed
>> to be merged?
> 
> Well, you've done this almost correctly. You just need to add
> Stefano Babic <sbabic at denx.de>
> (who is the maintainer of imx) to "cc" or "to" list.
> Added now.
> 

Thanks!

>> Due to get_maintainers your are (the only) maintainer
>> related to the cm-fx6 board.
> 
> That is a separate discussion (e.g. how boards of a specific vendor, but
> different architectures/platforms should be listed in the MAINTAINERS files).
>

I expected the output of get_maintainers to be complete. But ok, now I
know it's not.

>> Do you want me to resend the patch (without
>> the Fixes: tag)?
>>
>>> One nit-pick below:
>>>
>>>>
>>>> Fixes: 41855186afd3 ("arm: mx6: cm-fx6: modify device tree for old revisions of utilite")
>>>
>>> This isn't technically a fix; you're enabling new functionality. The
>>> original behavior wasn't buggy, it just lacked the card detect feature.
>>>
>> Well, the card is clearly removable. So IMHO adding the non-removable
>> property is wrong and this patch corrects/fixes it. But I'm fine either way.
> 
> Just a little explanation...
> Mechanically the card _is_ removable, but for revisions < 1.3, it will
> result in errors on the bus as no removal event will be sent to the
> subsystem. Moreover, if I'm not mistaken, you have the PRO model, right?
> In PRO model, you have internal storage (e.g. SSD) which makes the SD card
> an additional and sensibly removable device...
> There are additional Utilite models which have the SD card as the only
> storage device and those models have the rootfs on the SD card.
> In such case, IMO, it is much more appropriate to state that it should be
> non-removable.
> 
With the broken-cd property the driver/subsystem knows that the card may
have been removed and checks that if an (false positive) error occurs.

Indeed, I have the Pro model but even for the other models there are use
cases where the card may be removed. For instance, you can use netboot
(think of thin clients) or boot from usb storage. So IMO the broken-cd
property is a better choice for all models.

Cheers,
Christopher