On Thu, 15 Oct 2009, David Daney wrote:
> > > @@ -1406,6 +1424,7 @@ void __cpuinit build_tlb_refill_handler(void)
> > > case CPU_TX3912:
> > > case CPU_TX3922:
> > > case CPU_TX3927:
> > > +#ifndef CONFIG_MIPS_PGD_C0_CONTEXT
> > > build_r3000_tlb_refill_handler();
> > > if (!run_once) {
> > > build_r3000_tlb_load_handler();
> > > @@ -1413,6 +1432,9 @@ void __cpuinit build_tlb_refill_handler(void)
> > > build_r3000_tlb_modify_handler();
> > > run_once++;
> > > }
> > > +#else
> > > + panic("No R3000 TLB refill handler");
> > > +#endif
> > > break;
> > > case CPU_R6000:
> >
> > Shouldn't this be #error or suchlike instead?
> >
>
> I don't think so. It is a runtime check. The kernel was configured in such a
> manner that those CPUs cannot be supported. By the time the problem is
> detected, the preprocessor (and compiler in general) have already been run.
Hmm, you are right -- somehow I've assumed this piece of code is built
conditionally.
We know beforehand that CPU_R3000 precludes both of 64BIT and CPU_MIPSR2.
And we do not support generic builds that would support multiple CPU types
(even though there are places where it would work straight away). So we
can know at the build time that it is an invalid configuration; probably a
Kconfig breakage.
I guess this is not a problem to be solved with your change though. And
thanks for thinking about putting in some diagnostics at all for this
"impossible" case. :)
Maciej
