On Wed, 14 Dec 2011, Russell King - ARM Linux wrote: > On Wed, Dec 14, 2011 at 12:32:44PM +0000, Will Deacon wrote: > > On Wed, Dec 14, 2011 at 04:57:10AM +0000, Axel Lin wrote: > > > I got below build error on linux-next 20111213. > > > > > > CC arch/arm/kernel/process.o > > > In file included from arch/arm/mach-s5p64x0/include/mach/system.h:16, > > > from arch/arm/kernel/process.c:64: > > > arch/arm/plat-samsung/include/plat/system-reset.h:19:2: error: #error Fix me up > > > make[1]: *** [arch/arm/kernel/process.o] Error 1 > > > make: *** [arch/arm/kernel] Error 2 > > > > The clue is in the commit message: > > > > commit d0f7e2beabe6a116152ccc31959b6654b6ef0071 > > Author: Russell King <rmk+kernel@xxxxxxxxxxxxxxxx> > > Date: Tue Dec 6 12:57:02 2011 +0000 > > > > ARM: restart: Temporary #error to persuade platform maintainers to take the restart changes seriously > > > > Force builds to fail to ensure that platform maintainers take the > > restart changes seriously, and sort out fixing their code before the > > next merge window. > > > > Signed-off-by: Russell King <rmk+kernel@xxxxxxxxxxxxxxxx> > > Indeed, and note the date, and how long its taken for just one of the > platforms to be noticed. > > It seems to me that no one really cares about whether six of the seven > platforms which have the #error build or don't build, so I really think > there's a simple solution to this at the next merge window - delete any > platform which hasn't _at_ _least_ responded with a proposed patch to > this. > > The platform maintainers have had _enough_ notice of this - by not > responding, they're quite simply an obstacle to further consolidation, > and we're not going to go through months of waiting for their response > time and time again. > > I've posted the patches to the mailing list, I've copied them asking > for help, I've chased them several times, and now they have a #error > to deal with. If none of this gets their attention (it seems it > doesn't), then frankly their platform is unmaintained, it will be > broken at the next merge window, and therefore _should_ be deleted. > > So... unless things change, we can expect Gemini, almost all Samsung > stuff, shmobile, vt8500, and Telechips TCC8k to be at least broken at > the next merge window. Let me add to this by pointing to this piece of code in arch/arm/include/asm/pgtable.h: |/* This is a temporary hack until shmobile's DMA area size is sorted out */ |#ifdef CONFIG_ARCH_SHMOBILE |#warning "SH-Mobile's consistent DMA size conflicts with VMALLOC_END by 144MB" |#undef VMALLOC_END |#define VMALLOC_END 0xF6000000UL |#endif Again, the reason for this is in the commit message. My hope was that, by the central nature of this header file, the build would be sufficiently overwhelmed with #warning noise that the maintainers would manifest themselves and come forth with the needed fix. After repeated inquiries to the listed maintainers in the MAINTAINERS file, I still didn't receive any feedback at this point, and I still can't find a reason for the current state of things either by looking at the concerned code or the related Git commit logs. So if no one cares about this platform then I propose to delete it for v3.3 as well. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |