On 08/07/2016 at 12:40:44 +0200, Arnd Bergmann wrote :
On Friday, July 8, 2016 12:01:50 PM CEST Alexandre Belloni wrote:
On 08/07/2016 at 11:45:19 +0200, Arnd Bergmann wrote :
On Thursday, July 7, 2016 3:18:55 PM CEST Kevin Hilman wrote:
Well, by default, kernel CI will try to boot boards if it finds a DTB built for that build, but we do have support for blacklisting.
But...
IMO, the much better fix is for the kernel build not to build DTBs that can't possibly boot for that defconfig in the first place. That way other automated build infrastrucutre doesn't have to duplicate the kernelCI blacklisting.
I see mach-at91/Kconfig alrady has CONFIG_SOC_SAM_V7 and CONFIG_SOC_SAM_V4_V5, and those are already used in arch/arm/boot/dts/Makefile to select which DTs are actually compiled.
IMO, that approach should be expanded so that the DT files are not created for builds that can't possibly boot them.
Sounds good. Alexandre, does the change below look right to you?
Yes, that is what I had.
Ok. Are you sending this along with your next pull requests for 4.8?
Well, if it is still time, I'd like to send an ultimate pull request for 4.8 with that fix and some of the dtc warning fixed. I think the PMC ones will have to wait 4.9.
If you think it is too late in the cycle, feel free to submit your patch and take it directly through arm-soc.
Still, I was wondering whether we should split SOC_SAM_V7 using SOC_SAMA5D2, SOC_SAMA5D3 and SOC_SAMA5D4. We don't have any configuration enabling one without the others yet and I don't expect we will.
We are not consistent there, but I think the platforms that split it up are in the majority.
You could also ask the reverse question whether it makes sense to have three separate options instead of just SOC_SAMA5 to cover all of them. The differences seem very minimal from the kernel's perspective:
SOC_SAMA5D2 selects HAVE_AT91_GENERATED_CLK and PINCTRL_AT91PIO4 but not HAVE_AT91_SMD and PINCTRL_AT91 SOC_SAMA5D3 does not select CACHE_L2X0 or HAVE_AT91_H32MX
CACHE_L2X0 has some noticeable impact but is already user-selectable, the other options have no effect other than kernel size when enabled but unused, and the total difference for the five options is less than 20kb.
Well, the size was the main reason. I'm not sure it is worth changing now but it is easy enough to do if necessary.