Adding devicetree list. Thread starts at http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/354459.html On 11/5/2015 8:17 AM, Tony Lindgren wrote: > * Pali Rohár <pali.rohar@xxxxxxxxx> [151105 03:41]: >> On Tuesday 13 October 2015 16:37:46 Pali Rohár wrote: >>> On Monday 12 October 2015 13:45:09 Tony Lindgren wrote: >>>> * Pali Rohár <pali.rohar@xxxxxxxxx> [151012 13:29]: >>>>> On Monday 12 October 2015 22:16:40 Tony Lindgren wrote: >>>>>> >>>>>> Pali, any news on posting an updated series with the comments >>>>>> addressed in this thread? It seems that we all pretty much agree >>>>>> what needs to be done. I'm not real happy with the concept of patches 4 and 5 in this series. My concern is that those two patches are using the FDT as a transport mechanism for a binary blob (the atags object). Patches 1 and 2 do follow the spirit of atags_to_fdt() since an atags kernel already may set system_rev from an atag. -Frank >>>>> >>>>> Tony, I'm not really sure what to do. Just wrap 4 and 5 patches into >>>>> CONFIG_KEXEC? Or something more? >>>> >>>> Well for most part your patches are fine, I think there were some >>>> minor comments on the series. >>>> >>>> For the CONFIG_KEXEC dependency, we should just keep the existing >>>> behavior and keep /proc/atags behind CONFIG_KEXEC. That's all >>>> I believe :) >>>> >>>> Regards, >>>> >>>> Tony >>>> >>>> >>> >>> Ok. I will add CONFIG_KEXEC into atag patches. >>> >>> And there is missing documentation for these two new DT properties >>> (marked as TODO in commit messages). Where to put them? >>> >> >> Tony (or somebody else) ^^^ > > How about Documentation/devicetree/bindings/arm/atags.txt? > > Regards, > > Tony > -- > 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/ > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
