[U-Boot] [PATCH v2 5/9] AVR32: macb - Disable 100mbps if clock is slow

[Haavard Skinnemoen]

Ben Warren wrote:
> Jean-Christophe PLAGNIOL-VILLARD wrote:
> > make sense
> > so I'll put a 10Mpbs phy personnaly instead or a 10/100 that can be put in a
> > 10 mode instead to avoid to manage it in the code
> >   
> I haven't shopped for PHYs in a while, but imagine it's probably hard to 
> find one that's 10Mb only, and if so it's probably more expensive than 
> 10/100

Especially when the board really is _supposed_ to do 100Mbps just fine.

> >> No need to disable autonegotiation -- you still want to select between
> >> half an full duplex, for example. But you'll need to limit the
> >> available options to the ones that actually work.
> >>     
> > I do not mean the autoneg but to specify to the phy, if possible, to never
> > accept the 100Mps instead of do it in the code
> >   
> That's basically why the advertise register is r/w, so you can limit 
> autonegotiation through software and don't have to allocate pins for 
> strapping.

Yeah, I thought the advertise register was the correct way of informing
the phy about what modes you support...

I suppose we could move the initialization of the advertise register to
board code, but that's going to be a lot uglier since the board code
would have to access the MACB hardware to drive the MDIO pins.

Perhaps some boards don't need any initialization at all, but then
again, isn't it safer to unconditionally write the correct value? And
when we're going to write the register _anyway_, we might as well allow
the board code to influence the value we're going to write.

The more I think of this, the more I'm convinced we should have allowed
that from the beginning. The current driver is making assumptions it
shouldn't be making.

> >> That said, I kind of like Ben's suggestion -- it's a more general
> >> solution to all sorts of board/phy/chip/whatever limitations.
> >>
> >> As for a better name, how about CONFIG_MACB_ADVERTISE?
> >>     
> > why not
> >   
> I like it too.  One of the common checkbox items, though: do any Atmel 
> chips have more than one MACB, in which case this should be 
> CONFIG_MACBx_ADVERTISE or something like that?

Yes, AT32AP7000 has two MACBs, so that's probably a good idea.

Better yet, make it CONFIG_MACB_ADVERTISE(macb) so that the board can
distinguish between various instances if it has to, and the driver
doesn't have to do a long sequence of #ifdefs to find the correct value.

Haavard