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

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20181207/2632c9a8/attachment.sig>