On Tue, Oct 28, 2014 at 01:07:49PM +0000, Suravee Suthikulanit wrote: > On 10/27/2014 6:25 PM, Alexander Graf wrote: > > > > > > On 27.10.14 15:29, Suravee Suthikulanit wrote: > >> On 10/26/2014 9:08 AM, Alexander Graf wrote: > >>>>> This option doesn't exist in upstream kernels, does it? Why not just > >>>>>>> make it dtb-y? > >>>>> > >>>>> CONFIG_ARCH_SEATTLE is being added one hunk above.:) > >>> Oops:). > >>> > >>> I'm not convinced we need a config option just for the sake of > >>> compiling a device tree though. > >>> > >>> > >>> Alex > >>> > >> > >> Eventually, we would add other device driver selections when > >> CONFIG_ARCH_SEATTLE=y. At this point, those drivers are still not ready. > > > > Could you please give me some examples of drivers that would depend on > > CONFIG_ARCH_SEATTLE? I like the current way things work without the need > > for such an option, where everything's implemented purely as drivers you > > can opt in our out of. > > > > You don't have a CONFIG_ARCH_SB7XX on x86 either, right? ;) > > > > > > Alex > > > > I am not saying that device drivers need to depend on > CONFIG_ARCH_SEATTLE. I am thinking along the line of an easy way to > enable SOC without having to manually select each of the required > drivers to support the SOC. An example is the "ARCH_VEXPRESS".
ARCH_VEXPRESS is an historical artifact and we have discussed a few times internally in ARM to remove it as it brings no value until some other platform can't work with the default options comes in. I agree with Alexander here, I think the device tree should be compiled in regardless. One reason for it is because it will make it easier to dis-entangle the .dt{s,b} files from the tree in the future and have them hosted in a different place. Best regards, Liviu > > Suravee > > -- ==================== | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --------------- ¯\_(ツ)_/¯ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/