Jason, Sorry, I meant to get back to this earlier and it slipped off of my plate. :(
On Fri, May 24, 2013 at 11:33:06AM -0600, Jason Gunthorpe wrote: > On Fri, May 24, 2013 at 12:46:36PM -0400, Jason Cooper wrote: > > > > Why are you not keen on this? It seems like normal device driver > > > practice, that is what the data field of of_device_id is typically > > > used for.. > > > > I'm not keen on it because we don't have a document saying "All kirkwood > > SoCs need PSC1 set to X after reset." We know it, but have we tested > > the 6282? > > I disagree. The manul is very clear how PSC1 must be set for proper > operation. Clk125BypassEn bit is used only for loopback testing, it > should never set for driver operation. Similarly PortReset must be > cleared for driver operation. > > It is always safe for the driver to clear these bits, if it knows they > are available. In fact, I would argue the driver should always clear > these bits so that the bootloader isn't relied on to do it. It doesn't > matter if the SOC errantly sets the bit or not, it can *always* be > safely cleared. Great! > Further, I compared my 88F6282/88F6283 manual against the public > 88F6180/88F619x/88F6281 spec and confirmed that the PSC1 layout is the > same. Even better. > So all of these SOC's can share a driver compatible string. Ok, "marvell,kirkwood-eth" works for me then. I think Sebastian already has patches for that. > AFAICT the only reason the driver doesn't touch PSC1 today is because > the PSC1 was introduced in a later IP revision and its presence isn't > auto-detectable. Makes sense. > The last bit of the puzzle to get bootloader independence on kirkwood > is to encode the phy interface type (GMII/RGMII/BASE-X) in the DT so > the entire PSC1 can be set by the driver.. Hmm, let's work on that separately, and later. I've snowballed this attempt enough ;-) Thanks for digging into this for us, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
