* Sebastian Reichel <sebastian.reichel@xxxxxxxxxxxxxxx> [170725 09:52]:
> Hi,
>
> On Tue, Jul 25, 2017 at 09:15:39AM -0700, Tony Lindgren wrote:
> > > We describe all modules in the top level SoC dtsi and mark many as disabled and
> > > then mark them enabled in the board files as appropriate, so that's just the
> > > default state of most of the modules we use unless explicitly changed in the
> > > board file.
> >
> > That is something that TI started doing, and it's clearly not the policy
> > for the mainline kernel. And that is a wrong thing to do and also bloats
> > up the dts files with tons of pointless strings :p
>
> I tend to disagree. All of the mainline and non-mainline imx boards
> I recently had a look at for work used this style and a simple grep
> suggests, that its pretty common to disable most modules and enable
> them on demand:
>
> $ git grep -c disabled arch/arm/boot/dts/*.dtsi | \
> awk -F: '{ print $2 " " $1 }' | sort -rh | head -n 20
> 73 arch/arm/boot/dts/dra7.dtsi
> 68 arch/arm/boot/dts/tegra124.dtsi
> 66 arch/arm/boot/dts/am4372.dtsi
> 62 arch/arm/boot/dts/stm32f429.dtsi
> 62 arch/arm/boot/dts/r8a7791.dtsi
> 60 arch/arm/boot/dts/exynos4.dtsi
> 57 arch/arm/boot/dts/r8a7790.dtsi
> 52 arch/arm/boot/dts/r8a7794.dtsi
> 52 arch/arm/boot/dts/imx6sx.dtsi
> 49 arch/arm/boot/dts/sun7i-a20.dtsi
> 49 arch/arm/boot/dts/r8a7793.dtsi
> 45 arch/arm/boot/dts/vfxxx.dtsi
> 45 arch/arm/boot/dts/imx6qdl.dtsi
> 45 arch/arm/boot/dts/exynos3250.dtsi
> 44 arch/arm/boot/dts/tegra30.dtsi
> 44 arch/arm/boot/dts/sun4i-a10.dtsi
> 44 arch/arm/boot/dts/rk3288.dtsi
> 44 arch/arm/boot/dts/imx6ul.dtsi
> 43 arch/arm/boot/dts/imx28.dtsi
> 40 arch/arm/boot/dts/exynos5420.dtsi
OK so the pointless "disabled" strings are now all over the place :(
Anyways, for omap variants there really should be no need for
doing that. And we do have a kernel bug where we don't properly
respect the "disabled" property but instead attempt to tinker
with the device.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
