Re: [PATCH 0/3] of: add update device node status via cmdline feature

[Shawn Guo]

The device tree mailing list is changed to devicetree@xxxxxxxxxxxxxxxx

On Fri, Aug 23, 2013 at 03:09:08PM +0800, Dong Aisheng wrote:
> I tried the uboot way with fdt command to change the node status, it can work.
> However, it seems using fdt command is much complicated than the way i did with kernel
> command line and it also does not support enable/disable multi nodes at the same time.
> e.g, in order to enable ecspi1 and uart3 and disable gpmi:
> with uboot fdt command:
> U-Boot > fdt addr ${dtbaddr}
> U-Boot > fdt set /soc/aips-bus@02000000/spba-bus@02000000/ecspi@02008000 status "okay"
> U-Boot > fdt set /soc/aips-bus@02100000/serial@021e8000 status "okay"
> U-Boot > fdt set /soc/gpmi-nand@00112000 status "disabled"

Oh, you can use the U-Boot environment and scripting function to make
it even easier than your kernel cmdline approach to use.

> with kernel cmdline:
> fdt.enable=ecspi@02008000,serial@021e8000 fdt.disable=gpmi-nand@00112000
> So from the using perspective, kernel command line is much more simple and easy than uboot.

NAK.

It's not about simple or easy.  The approach completely defects the
point of the whole device tree project - moving stuff that kernel does
not care out of kernel.  Choosing device from mutually exclusive ones
(due to pin conflict of board design) should NOT be something that
kernel cares.

Kernel gets device tree blob from firmware/bootloader and instantiates
drivers for devices found in device tree.  That's all what kernel should
do, nothing more.  Asking kernel to manipulate the device availability
property in device tree is plainly wrong to me.

If your board is designed with so many pin conflicts between devices,
you have to do whatever you can do to get the decision made in device
tree blob, before it gets passed to kernel.  Kernel does NOT care about
that decision making.

Shawn

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/