On Tue, Jul 25, 2017 at 10:26:41AM -0700, Tony Lindgren wrote:
> * Sebastian Reichel <sebastian.reichel@xxxxxxxxxxxxxxx> [170725 09:52]:
> > 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.
I agree that this disabled strings are't really nice and also a little
bit missleading. But I like the idea with removing the node somehow.
Because removing the node would mean this address range does not exist
which implies that no driver can touch it.
We would then have 3 states:
use the device and load the driver -> okay
must be disabled, because it could be on -> disabled
don't touch the memory at all -> remove the node
I don't know how common it is to use /delete-node/. I only saw it in
some imx6 and rk3288 devicetree files and I don't know the "real"
meaning there.
Regards,
Stefan
--
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
