On Tue, 2007-07-17 at 02:59 +0200, Arnd Bergmann wrote:
> On Monday 16 July 2007, Mark Zhan wrote:
>
> > @@ -96,7 +94,7 @@
> > pvid = mfspr(SPRN_PVR);
> > svid = mfspr(SPRN_SVR);
> >
> > - seq_printf(m, "Vendor\t\t: Freescale Semiconductor\n");
> > + seq_printf(m, "Vendor\t\t: %s\n", CPUINFO_VENDOR);
> > seq_printf(m, "Machine\t\t: %s\n", CPUINFO_MACHINE);
> > seq_printf(m, "PVR\t\t: 0x%x\n", pvid);
> > seq_printf(m, "SVR\t\t: 0x%x\n", svid);
>
> This is a step in the wrong direction. CPUINFO_{VENDOR,MACHINE}
> comes from a platform specific header file, so you can not
> use these definitions in platform independent code without
> breaking multiplatform kernels.
>
> One possible solution would be a platform specific show_cpuinfo()
> function that calls a generic 82xx version and passes in the
> two values. Even better would be to just dump whatever string
> you find in the /model property in the device tree.
>
OK, Got what you said. I will fix it.
> > +
> > +#define RMR_CSRE 0x00000001
> > +
> > +void mpc82xx_restart(char *cmd)
> > +{
> > + __volatile__ unsigned char dummy;
> > +
> > + local_irq_disable();
> > + ((cpm2_map_t *) cpm2_immr)->im_clkrst.car_rmr |= RMR_CSRE;
> > +
> > + /* Clear the ME,EE,IR & DR bits in MSR to cause checkstop */
> > + mtmsr(mfmsr() & ~(MSR_ME | MSR_EE | MSR_IR | MSR_DR));
> > + dummy = ((cpm2_map_t *) cpm2_immr)->im_clkrst.res[0];
> > + printk("Restart failed\n");
> > + while (1) ;
> > +}
>
> I know you're just moving that code, but it looks horribly wrong
> nonetheless. cpm2_immr is an __iomem variable, so you must not
> dereference it but instead should use the in_8() macro to
> access it.
>
> Once you get that right, you don't need the volatile variable
> any more.
OK. will fix it.
>
> > +void mpc82xx_halt(void)
> > +{
> > + local_irq_disable();
> > + while (1) ;
> > +}
>
> Here, as in the function above, there should at least be a cpu_relax()
> in the final loop. If the CPU has a nap functionality or something
> similar, that would be even better.
Not sure if mpc82xx has such kind of functionality. Based on the current
definition of cpu_relax(), it is only meaningful for ppc64.
>
> Arnd <><
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
