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

[Andy Fleming <afleming@freescale.com>]

On Jun 29, 2006, at 13:51, Vitaly Bordug wrote:

> On Thu, 29 Jun 2006 13:03:23 -0500
> Andy Fleming wrote:
>
> [snip]
> > > > > +	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?
>
> I am sort of against the unconditional trigger of the ethernet- 
> specific stuff,
> dependless if UCC eth is really wanted in specific configuration.
>
> For stuff like that I'd make a function (to setup low-level stuff),  
> and pass it
> via platform_info to the eth driver, so that really driver-specific  
> things happen in driver context only.
>
> Yes this is board specific file, and virtually everything needed  
> for the board can take place here.
> But usually BCSR acts as a toggle for a several things, and IOW, I  
> see it more correct to trigger those stuff from the respective  
> drivers (using a callback passed through platform_info)


Callbacks are fairly evil.  And the driver most certainly cannot know  
about the BCSR, since there may or may not even *be* a BCSR on any  
given board with a QE.  The PHY only needs to be reset once, during  
initialization.  On some boards, there is no need to trigger some  
sort of reset, or enable any PHYs.  I'm still not sure why this  
should be the domain of the device driver, since it's a board option.

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