Re: [PATCH 1/7] powerpc: Add mpc8360epb platform support

[Andy Fleming]

On Jun 29, 2006, at 04:28, Li Yang-r58472 wrote:

> > > +config MPC8360E_PB
> > > +	bool "Freescale MPC8360E PB"
> > > +	select DEFAULT_UIMAGE
> > > +	select QUICC_ENGINE
> > > +	help
> > > +	  This option enables support for the MPC836x EMDS Processor  
> > > Board.
> > > +
> > >  endchoice
> >
> > I don't think this is really required option. I guess 836x +  
> > QUICC_ENGINE should
> > be enough (with a proviso that 8360 won't boot without qe.
>
> We select a board and the board implies cpu family and soc  
> feature.  That will be better for users rather than expecting them  
> to know the very detail.


Yeah, this seems fine to me.  In order to eliminate this option, we'd  
need to merge 8360 PB support with the existing board support for  
83xx.  A laudable goal, but not what the 83xx maintainer has  
currently requested.



> > > diff --git a/arch/powerpc/platforms/83xx/mpc8360e_pb.c
> > b/arch/powerpc/platforms/83xx/mpc8360e_pb.c
> > > new file mode 100644
> > > index 0000000..b4ddb0a
> > > --- /dev/null
> > > +++ b/arch/powerpc/platforms/83xx/mpc8360e_pb.c
> > > @@ -0,0 +1,213 @@
> > > +/*
> > > + * Copyright (C) Freescale Semicondutor, Inc. 2006. All rights  
> > > reserved.
> > > + *
> > > + * Author: Li Yang <LeoLi@xxxxxxxxxxxxx>
> > > + *	   Yin Olivia <Hong-hua.Yin@xxxxxxxxxxxxx>
> > > + *
> > > + * Description:
> > > + * MPC8360E MDS PB board specific routines.
> > > + *
> > > + * Changelog:
> > > + * Jun 21, 2006	Initial version
> > > + *
> > No changelog entries for new files please... git tracks it good  
> > enough.
>
> This is Freescale protocol.  If it is not welcomed, we will change it.


Yeah, this is one of the problems with the protocol.



> > > +#ifdef CONFIG_QUICC_ENGINE
> > > +	qe_reset();
> > > +
> > > +	for (np = NULL; (np = of_find_node_by_name(np, "ucc")) != NULL;)
> > > +		par_io_of_config(np);
> > > +
> > > +	/* Reset the Ethernet PHY */
> > > +	bcsr_regs = (u8 *) ioremap(BCSR_PHYS_ADDR, BCSR_SIZE);
> > > +	bcsr_regs[9] &= ~0x20;
> > > +	udelay(1000);
> > > +	bcsr_regs[9] |= 0x20;
> > > +	iounmap(bcsr_regs);
> > > +
> > And if we have a design, which do not contain real ethernet UCC  
> > usage? Or UCC
> > geth is disabled somehow explicitly? Stuff like that normally goes  
> > to the
> > callback that is going to be triggered upon Etherbet init.
> I will move it.


Wait...no.  I don't understand Vitaly's objection.  If someone  
creates a board with an 8360 that doesn't use the UCC ethernet, they  
can create a separate board file.  This is the board-specific code,  
and it is perfectly acceptable for it to reset the PHY like this.   
What ethernet callback could be used?

Andy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/