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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
