[U-Boot] [PATCH v2] rockchip: rk3288-evb: dts: remove 'vmmc' from emmc node

[Philipp Tomsich]

> On 12.12.2018, at 10:05, Kever Yang <kever.yang at rock-chips.com> wrote:
> 
> 
> 
> On 12/11/2018 02:20 AM, Tom Rini wrote:
>> On Sat, Dec 08, 2018 at 12:27:42PM +0800, Kever Yang wrote:
>>> Hi Tom,
>>> 
>>> 
>>> On 12/07/2018 10:13 PM, Tom Rini wrote:
>>>> On Fri, Dec 07, 2018 at 02:24:22PM +0100, Philipp Tomsich wrote:
>>>>> Kever,
>>>>> 
>>>>>> On 07.12.2018, at 02:39, Kever Yang <kever.yang at rock-chips.com> wrote:
>>>>>> 
>>>>>> Hi Philipp,
>>>>>> 
>>>>>> On 12/06/2018 09:50 PM, Philipp Tomsich wrote:
>>>>>>> +Tom
>>>>>>> 
>>>>>>>> On 05.12.2018, at 03:25, Kever Yang <kever.yang at rock-chips.com> wrote:
>>>>>>>> 
>>>>>>>> The U-Boot eMMC does not need to care about the power for Rockchip
>>>>>>>> SoC, because if the board is using eMMC, the power will default on
>>>>>>>> (for bootrom), and we do not do power management for it like kernel,
>>>>>>>> so the 'vmmc', 'vqmmc' is only useful for SD in U-Boot.
>>>>>>>> 
>>>>>>>> This make U-Boot can boot into kernel even if the pmic driver is
>>>>>>>> broken.
>>>>>>> If the PMIC driver is broken, we should fix the PMIC driver.
>>>>>>> I would feel more comfortable w/o this statement.
>>>>>>> 
>>>>>>>> The rk3288-evb dts may be used in many boards using rockchip reference
>>>>>>>> schematic but with little change, so we hope it can be more robust to
>>>>>>>> boot into next stage.
>>>>>>> Again, this is not how the DTS should be used.  I believe that Heiko, Fabio and
>>>>>>> I had already highlighted this in comments to the earlier thread.
>>>>>>    Not sure if you have read my previous mail for answer all your comments,
>>>>>> 
>>>>>> I do agree DTS should represent the hardware, but please note that the DTS
>>>>>> is no kind of standard, and people always choose what they need and add
>>>>>> those part in there dts, but not always add all the property and
>>>>>> everyone use the same model. I would say there are many boards does not have this
>>>>>> 'vmmc-supply’ in there emmc node.
>>>>> That is exactly the reason why I bumped the decision up the stairs (to Tom and/or
>>>>> Simon): what you are saying makes sense to me (viewed through your eyes and 
>>>>> from your specific usecase), but it directly contradicts how the DTS usage is intended.
>>>>> 
>>>>> In other words: Tom (as the top-level decision maker) or Simon (who owns the 
>>>>> device-model and therefore will also have an opinion on DTS usage) should make
>>>>> the final call.
>>>> My answer is that I would strongly suspect that over in linux "we have N
>>>> different close-enough boards using this one DTS" isn't acceptable.  You
>>>> make a dtsi and include it from the board and things that aren't common
>>>> don't go into the dtsi.  And yes, when starting off everyone (myself
>>>> included) copies the reference platform dts and then changes it as
>>>> needed, and sometimes misses a thing or two.  But no, I don't think we
>>>> want a wrong dts and I'm pretty sure the kernel really wouldn't want
>>>> wrong dts files and the general goal is that excluding the -u-boot.dtsi
>>>> files, ours are copies of the kernel.
>>> I don't think this is a "wrong dts" after my patch, these two nodes are
>>> not mark
>>> as required property in kernel, so many dts emmc node does not have it.
>>> I check the latest kernel dtsi in arch/arm/boot/dts/rk3288-evb.dtsi [1],
>>> the emmc node do not have 'vmmc' and 'vqmmc' while the SD node have, which
>>> just like description in my commit message.
>> OK.  So this would fall into the category of "sync with upstream dts"
>> then, right?  That is what we want.
> 
> OK, Got it, 'sync with upstream dts' is a good and acceptable commit
> message
> rather than the real reason why we need the patch.
> 
> Philipp,
>     Do you need me to send out a patch with update the commit message?

If you do it, you’ll save me work and the history on the list is 1:1 identical
with what I apply …

If you absolutely don’t have time, I’ll change the commit message as I process
this for my end-of-week pull-request.

Thanks,
Philipp.