On Tue, 2011-01-04 at 13:23 -0600, Scott Wood wrote: > On Tue, 4 Jan 2011 10:58:35 -0800 > <bruce_leon...@selinc.com> wrote: > > > Hi all, > > > > I'm working on a project with an MPC8347 and three ethernet ports. Because > > of end of life issues we've had to replace the part we're using for the > > third ethernet port and we decided rather than rely on a vendor who would > > pull a part out from under us every two to three years we would do our own > > MAC in an FPGA. In order to reduce driver work it was decided that we > > would use the same hardware interface as the TSEC in the 8347 so we could > > reuse the gianfar driver. > > Making a faithful clone of any reasonably complex device strikes me as > more work than writing a new ethernet driver. > > The last thing you want to end up doing is... > > > And for speed sake it would go on the PCI bus. > > (So much for letting HW make decisions regarding SW :) ) > > ...hacking up the existing driver to deal with the quirks of the clone, > and having to maintain those hacks. :-)
I definitely agree. You're up for more work and problems than just doing a new design or getting an existing one off opencores or even buying an IP block with its own driver. > > So now I'm stuck with hacking the gianfar driver to work on PCI. However, > > I think it would be a lot more elegant if I could wrap the gianfar driver > > with a PCI interface. After all the idea is sound, with a HW interface > > that looks like the TSEC I should be able to reuse the gianfar driver. But > > the gianfar driver is an open firmware driver registered with a call to > > of_register_platform_driver() and depending on the order in which the > > busses are walked the PCI bus may not be enumerated and available when the > > onboard TSECS are detected and the gianfar driver claims them. > > It shouldn't matter -- the way buses work in Linux, you should be able > to add a platform device at any time, and the driver will receive a > probe() callback. The driver never actively searches for devices to > claim. Cheers, Ben. > -Scott > > _______________________________________________ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
