Le dimanche 23 mars 2014, 02:16:27 Maciej W. Rozycki a écrit : > On Tue, 21 Jan 2014, Florian Fainelli wrote: > > When support for the DECStation is enabled, it will default to use a > > MIPS R3000 class processor. This will cause an intentional build failure > > to popup because MIPS_L1_CACHE_SHIFT and cpu_dcache_line_size() > > disagree. Fix this by selecting MIPS_L1_CACHE_SHIFT_2 when we build > > targetting a MIPS R3000 CPU to fix that build failure and satisfy all > > requirements. > > Thanks for your contribution. However I just built a pristine ToT LMO > kernel for an R3000 DECstation and that went fine, I got no error. Can > you provide me with a way to reproduce the problem? The build failure was only transient, in conjunction wit this patch applied: http://www.linux-mips.org/archives/linux-mips/2014-01/msg00183.html which was then reverted. > > I am not opposed to your change per se, it may make sense regardless. > However using a value of MIPS_L1_CACHE_SHIFT that is too high results in > wasting some memory, but should otherwise be safe I believe, so I'm not > really convinced adding this config infrastructure is going to pay off. Not quite sure what "infrastructure" you are referring to here. MIPS_L1_CACHE_SHIFT_<N> is just a bunch of Kconfig symbols that platform can select, to avoid an ever-growing list of: default 5 if MIPS_FOO && MIPS_BAR && MIPS_BAZ I think that this patch is still applicable as it makes it more accurate which L1_CACHE_SHIFT_SIZE is really required for a given CPU configuration DECSstation, and will avoid overbooking that value when R3000 CPUs are configured/used specifically here. -- Florian
