[U-Boot] [PATCH V2] Allow PHY addresses on kirkwood egiga to be non continuous.

[Tor Krill]

On Thu, 2010-06-24 at 14:26 +0200, Prafulla Wadaskar wrote:
> 
> > -----Original Message-----
> > From: Tor Krill [mailto:tor at excito.com] 
> > Sent: Thursday, June 24, 2010 5:05 PM
> > To: Prafulla Wadaskar
> > Cc: u-boot at lists.denx.de
> > Subject: RE: [PATCH V2] Allow PHY addresses on kirkwood egiga 
> > to be non continuous.
> > 
> > 
> > Hi Prafulla,
> > 
> > On Thu, 2010-06-24 at 13:22 +0200, Prafulla Wadaskar wrote:
> > > 
> > > > -----Original Message-----
> > > > From: Tor Krill [mailto:tor at excito.com] 
> > > > Sent: Thursday, June 24, 2010 3:02 PM
> > > > To: u-boot at lists.denx.de
> > > > Cc: Prafulla Wadaskar; Tor Krill
> > > > Subject: [PATCH V2] Allow PHY addresses on kirkwood egiga to 
> > > > be non continuous.
> > > > 
> > > > Changing its configuration from PHY_BASE_ADR single value to use
> > > > CONFIG_PHY_BASE_ADDRS as an array with adresses.
> > > > 
> > > > Updated in version 2:
> > > > 
> > > > Merged board updates to single patch.
> > > 
> > > These two lines should go as changelog for v2 below (after ---)
> > 
> > Sorry, there seems to be no end on my mistakes :(
> > 
> > > > 
> > > > Signed-off-by: Tor Krill <tor at excito.com>
> > > > ---
> > > i.e. here..
> > > 
> > > >  board/keymile/km_arm/km_arm.c |    3 ++-
> > > >  drivers/net/kirkwood_egiga.c  |    3 ++-
> > > >  drivers/net/kirkwood_egiga.h  |    8 ++++----
> > > >  include/configs/guruplug.h    |    2 +-
> > > >  include/configs/km_arm.h      |    2 +-
> > > >  include/configs/openrd_base.h |    2 +-
> > > >  include/configs/rd6281a.h     |    2 +-
> > > >  include/configs/sheevaplug.h  |    2 +-
> > > >  8 files changed, 13 insertions(+), 11 deletions(-)
> > > 
> > > Hi Tom
> > > I understood your problem.
> > > But all of the Kirkwood boards so far have similar 
> > implementation which is standard practice.
> > > How does your board design differed in this case?
> > > 
> > > Instead of fixing it here for all other boards,
> > > can't you simply align PHY address on your board?
> > > I think this will be much easier.
> > 
> > We use both ethernet interfaces by default in our design, with the phy
> > addresses 0x08 and 0x18, and unfortunately we have already started the
> > manufacturing of these units which makes it expensive and hard to
> > reverse this design decision :(
> 
> Do you think this will be corrected in next h/w version?
> If yes, then you can keep this patch private to yourself.

We will unfortunately not change this, what we know of now. If it had
only been moving some resistors mounted or not it could perhaps have
been fixable before mass production. But as it is now this would involve
us changing the the design as well. 

> > 
> > But if we turn this around if the hardware allows this then 
> > why not let
> > this be configurable in u-boot as well? Do this have any technical
> > implications on the other boards?
> 
> Overall 
>
> 1. This patch increases u-boot binary size by 20 bytes. (may be
>  critical issue on low footprint boards like mv88f6281gtw_ge). 

Ok, i only get this to ~4 bytes but thats a valid point.

> 2. For the boards using single port will also need to configure PHY address
>  for other port, which is meaningless, unnecessary and confusing.

Sure you had to put something there to be on the safe side. But is that
really that confusing, the SOC really have two ports, them being used or
not? 

This is the exact same mechanism that is used for
CONFIG_KIRKWOOD_EGIGA_PORTS which is implemented as an array telling the
driver if it should initialize the port or not.

> Technically no implications, but we need to keep code simple, small and standard.

And again, i think the flexibility is worth the "small" prize. I know
that fx the TK71 devkit have non consecutive PHY addresses (Even though
it not being present in mainline u-boot) 

If you are able to set the addresses "freely", why limit this in
software?

The alternative, as i see it, would be to have defines for each port and
then ifdef each init. Would that be an alternative?

Regards,

/Tor